Boot-code tce=LABEL not working

[sm8ps]

Hello all! I am at loss with the problem mentioned on a fresh install of dCore-xenial (12-Aug-2017 19:38). I have followed the install guide from the wiki more or less to the point and it seems to work well but the tce-directory always is located under '/tmp'.

The boot stanza contains tce=LABEL="dCORE" and I do know that the label is correct because it does work for "home" and "opt". After boot, I can issue ''tce-setdrive'' but that is no real solution.

Just what am I overlooking?!

[sm8ps]

Things are even worse! After issueing ''tce-setdrive'', ''sce-load wireless'' chokes:

Code: [Select]

/usr/bin/sce-load line 475: can't create /tmp/.installed. Permission deniedThat same message is repeated but this time with"usr/bin/sce-load" being prepended by "crda", "debconf", "debianutils", ..., all kinds of libs and finally "zilb1g".

The file in question is owned by root:root with permissions 644; so it does make sense that is cannot be written to by the standard user. There is another file '/tmp/.debinstalled' owned by user:root with permissions 644.

Does that make any sense?!

[sm8ps]

Just to make it clear: it is not the LABEL-part being faulty but the full boot-code does not work, even with ''tce=sdaX''.

One thought: There is another dCore installation present on a different partition but that is exactly why one would use the boot-codes tce, opt and home. -- Very strange! I would be glad for any comments, also about working fresh installations.

[Jason W]

I boot with tce=UUID, which always works, and just now tested my dCore-xenial install using the LABEL option and no problems here. Below is the boot codes:

Code: [Select]

jason@box:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-xenial quiet tce=LABEL=dCore/tceimport-xenial showapps user=jason nozswap desktop=icewm
jason@box:~$

I will test tce-setdrive later today.

[Jason W]

I booted dCore-xenial with the "base" option, and used tce-setdrive to set up /mnt/sdb1/tce as my TCE directory and I was able to sce-import and sce-load as expected.  I will look into the tce= code and see what may be causing error.

[sm8ps]

Many thanks for double-checking, Jason! I have always been using those boot-codes without any trouble, too.

Another thought: the laptop sports an Intel Pentium M processor. Could it be that the kernel does not support it? I recall quite some discussions about PAE. But then I would expect the machine going bonkers way more dramatically.

The Grub2 boot-stanza reads

Code: [Select]

menuentry "ub-dC sm" {
search --no-floppy --label --set=root "dC"
linux /boot/vmlinuz-trusty blacklist=pcspkr tce=LABEL="dC" home=LABEL="dC" opt=
LABEL="dC" user=sm host=fjsa lang="de_CH.UTF-8" tz=CET-1CEST,M3.5.0,M10.5.0/3 m
ultivt syslog showapps desktop=openbox resume=/dev/sda7 laptop
initrd /boot/dCore-trusty.gz
}
I copied it basically verbatim from the existing dCore-trusty installation:

Code: [Select]

menuentry "ub-dCore" {
search --no-floppy --label --set=root "dCORE"
linux /boot/vmlinuz-xenial blacklist=pcspkr tce=LABEL="dCORE" home=LABEL="dCORE
" opt=LABEL="dCORE" host=fjs lang="de_CH.UTF-8" tz=CET-1CEST,M3.5.0,M
10.5.0/3 multivt syslog showapps desktop=openbox resume=LABEL="SWAP" laptop
initrd /boot/dCore-xenial.gz
}The only noticable change regards the use of "LABEL" in the boot-code "resume". Yet that should be irrelevant for the boot-up if there is no resume image available (double-checked).

''blkid'' gives

Code: [Select]

/dev/sda1: LABEL="SYSTEM" UUID="DA76EE3976EE1653" TYPE="ntfs"
/dev/sda5: LABEL="ROOT" UUID="2b05e3fe-295b-47fb-9f65-c6f33261afe1" TYPE="ext4"
/dev/sda6: LABEL="HOME" UUID="10aa76a6-d5d0-4d99-ac00-5ded978f9493" TYPE="ext4"
/dev/sda7: LABEL="SWAP" UUID="fd6d2f55-b8c0-466f-ba89-7f38e8199b73" TYPE="swap"
/dev/sda8: LABEL="dC" UUID="9fa1b78d-ead6-45c8-90e0-8b406c0690cf" TYPE="ext4"
/dev/sda9: LABEL="dCORE" UUID="e51b6b98-7a47-4f44-8255-f1a9bb963bf6" TYPE="ext4"
''mount'' shows '/dev/sda9' mounted on '/mnt/sda9', '/home' and '/opt' but not on '/etc/sysconfig/tce-dir'.

[sm8ps]

I must be overlooking something terribly obvious! I tested with kernel and initrd from the Trusty installation copied to the same location as the new Xenial kernel (sda9=dCORE). Even then the tec-directory points to '/tmp/tce'. So things do not seem to behave normally here.

After issueing ''tce-setdrive'' and ''sce-load wireless'', I get segmentation faults in busybox. Is my harddisk failing? Though, Busybox should not be affected by such a problem, or should it? The MD5-sums of kernel and initRD were OK. SMART-values of the disk are OK.

I suspect that I have to search for the cause of the error somewhere outside. So in case anybody has some clue on what to check then I would be grateful.

[sm8ps]

I have found a solution but one that should not be needed! Exchanging "=LABEL=dCORE" with "sda9" everywhere in the boot stanza makes dCore-xenial behave as expected. The persistent tce-directory is detected and ''sce-load'' works flawlessly.

Now I would be glad to understand why this is so. -- Anybody?

[Rich]

Hi sm8ps
Do you have more than one partition labeled  dCORE ? Are you sure you didn't label it  dCore ? Are labels case sensitive?

[sm8ps]

Thanks for your thoughts, Rich! The list of labels as seen by ''blkid'' is printed out above. I have double- and triple-checked it. The only thing I could imagine is that "dC" is mistaken for "dCORE" as it starts with the same letters. Though that seems quite absurd, doesn't it?

[Rich]

Hi sm8ps

The only noticable change regards the use of "LABEL" in the boot-code "resume".

Other differences I notice are there is no  user=  and the  host=  has a different name. I point this out on the chance you have a
backup or script that relies on them. I guess only changing  resume  to  /dev/sda7  wouldn't fix it?

[sm8ps]

I guess only changing  resume  to  /dev/sda7  wouldn't fix it?

RIGHT ON THE SPOT! It seems to be the case that the boot-code "resume" does not accept disk labels and this must have messed things up quite badly.

Thank you very, very much for helping to solve this mistery. I have noticed by now that "resume" is a kernel boot-code and as such may well behave differently than the *Core boot-codes. I shall take a mental note of this!

[Rich]

Hi sm8ps

RIGHT ON THE SPOT! It seems to be the case that the boot-code "resume" does not accept disk labels and this must have messed things up quite badly.

Labels and UUIDs are handled by the  find_mountpoint  function in  /etc/init.d/tc-functions.

[sm8ps]

In addition to the mental note, I have also added a short section to the wiki.