Bug 483136

Hi, root=LABEL=something is bad syntax, correct is root=/dev/disk/by-label/something ... I cannot reproduce it if I install 11.1 and mount by label...could you please specify what you do? or please attach yast logs, maybe it still have logs about this change. Thanks

(In reply to comment #1)
> Hi, root=LABEL=something is bad syntax

If this is "bad syntax", it is a recent regression. It should remain an alternate syntax. During the late stages of 11.1 development it continued to work as it did in 11.0, 10.3, 10.2 & probably before then. I have been using this syntax for booting all my Linux distros (*buntu, Mandriva, Fedora, openSUSE) for two years or more:

00srv:~ $ cat /etc/SuSE-release
openSUSE 11.0 (i586)
VERSION = 11.0
00srv:~ $ uname -r
2.6.27.7-10-pae
00srv:~ $ cat /proc/cmdline
root=LABEL=08-suse110 noresume splash=off vga=0x305 3
00srv:~ $ tune2fs -l /dev/sda8| grep ume
Filesystem volume name: 08-suse110

FWIW, some months ago I stopped booting from the Grub installed by the selected distro. I install Grub to the / partition, but but boot from a primary partition that does not bet mounted to /boot. The menu.lst on the real boot partition., which by convention I mount to /disks/boot, I manage myself. Until now, everything has been booting using root=LABEL= syntax.

> correct is
> root=/dev/disk/by-label/something ... 

That may be what the installer does now, but at least as recently as November's Factory YaST was still using root=LABEL= syntax here. Long strings may be fine for GUI puter applets to manage, but they're not so good for normal human brains or for fitting on a single viewport-length line while editing a config file.

> I cannot reproduce it if I install 11.1
> and mount by label...could you please specify what you do?

I've done no fresh installs in many months, waiting for a post-2.6.27 installation kernel so that I can install on libata onto whichever partition up to #63 I please. Other than specifying to mount by label to my pre-existing and pre-labeled partitions during installation, I don't remember doing anything more than written above that deviates from defaults.

>or please attach
> yast logs, maybe it still have logs about this change. Thanks

Most of my updating gets done via cmdline zypper. If you think any of the following will help, specify, and I will attach:
    4943 Jun  5  2008 config_diff_2008_06_05.log
     632 Jun  5  2008 y2logmkinitrd
     760 Jun  5  2008 y2log_bootloader
       0 Jun  5  2008 y2logMount
     977 Jun  5  2008 volume_info
    6124 Jun  5  2008 macro_inst_initial.ycp
     974 Jun  5  2008 disk_sda
    4256 Jun  5  2008 y2start.log
 6926800 Jun  5  2008 y2log-1
    6967 Sep 30 16:23 config_diff_2008_09_30.log
    2040 Oct  2 18:14 config_diff_2008_10_02.log
  328761 Oct  2 18:25 y2logRPM
    1077 Nov 30 00:38 config_diff_2008_11_30.log
 5033281 Feb 26 13:19 y2log
    4039 Feb 26 15:14 config_diff_2009_02_26.log
    2962 Mar  5 14:51 config_diff_2009_03_05.log
   91501 Mar  6 01:14 mkinitrd.log
15880749 Mar  6 01:16 perl-BL-standalone-log

OK, then it looks like problem of kernel (and not perl-Bootloader). Reassign it to kernel guys.

root=LABEL=<label> should still work, but it's not a kernel issue. That's handled in the initrd.

Milan, could you have a look here?

*** Bug 512695 has been marked as a duplicate of this bug. ***

Ping.

Just FYI - have just installed 11.2M8, and I can confirm Felix' findings that booting with root=LABEL=<something> on the cmdline does not work.

*** Bug 548642 has been marked as a duplicate of this bug. ***

Created attachment 324348 [details]
/lib/mkinitrd/scripts/setup-storage.sh with root=LABEL= syntax enabled

The problem is in /lib/mkinitrd/scripts/setup-storage.sh
Try the attached one.

I tried comment 10 attachment with my comment 0 system. It had no apparent impact with either 2.6.31-10-pae or 2.6.31-10-desktop. I didn't try booting older kernels.

the following patch works for me (but is ugly;)

--- /lib/mkinitrd/scripts/boot-storage.sh.orig      2009-08-11 11:59:50.000000000 +0200
+++ /lib/mkinitrd/scripts/boot-storage.sh   2009-10-29 10:07:17.000000000 +0100
@@ -49,6 +49,7 @@
         LABEL=*)
             label=${rootdev#LABEL=}
             echo "ENV{ID_FS_USAGE}==\"filesystem|other\", ENV{ID_FS_LABEL_SAFE}==\"$label\", SYMLINK+=\"root\"" > /etc/udev/rules.d/99-mkinitrd-label.rules
+           [ -e /dev/root ] || ln -s /dev/disk/by-label/$label /dev/root
             rootdev=/dev/root
             ;;
         UUID=*)

I just did a 'zypper dup' from factory-snapshot on a 11.1.rc2 ICH4 system running piix rather than ata_piix, which gave it both default and pae 2.6.31.5 kernels. Neither root=LABEL= nor root=/dev/hdX## syntax nor root=/dev/sdX## syntax work with either kernel. root=/dev/disk/by-path/pci* syntax does work, as does just as well absolutely no root= parameter whatsoever.

If I exit the Grub menu all the way to the Grub shell instead of choosing from menu.lst selections, then /dev/sdX## syntax works, but root=LABEL= syntax does not, while in oS11.1 final both work.

Created openSUSE Build Service request ID 26331 to merge the suggested fix from comment #12.

If it works for Factory I suggest to merge it to openSUSE 11.2 as well.

In http://lists.opensuse.org/opensuse/2009-12/msg00804.html Felix wrote:

### Felix begin
On 2009/12/09 02:04 (GMT-0500) Bob S composed:

> Any further instruction/guidance is certainly appreciated.

A reread of https://bugzilla.novell.com/show_bug.cgi?id=483136#c13 gave me
another idea to try: remove the whole root= string from the Grub kernel line
and see what happens.
### Felix end

If that works then we have a much simpler solution to address this issue.

> If that works then we have a much simpler solution to address this issue.

that's no solution if I have multiple root partitions which I'd like to distingish/select/boot (and I do have more than one rootfs on my notebook).
even if yast won't create those grub entries, they are valid and they worked in older versions, so there is no reason to break them now (esp. since it's not hard to fix...)

Filed a new submit request (26621) to be non conflicting with the recent mkinitrd change.

  + [ -e /dev/root ] || ln -s /dev/disk/by-label/$label /dev/root

We do not want to do nasty hacks like this. :) The real issue should be fixed instead of creating hacks like this. If nothing else is broken, I guess ID_FS_LABEL_SAFE should just be ID_FS_LABEL_ENC.

Created attachment 336838 [details]
patch as suggested by Kay's comment #18.

@Felix and anyone else using this feature: please test if this works for you too.

Created request id 29761 to merge the tested patch from comment 18 + 19.

Created attachment 336860 [details]
Add patch fitting to the gitorious.org/opensuse/mkinitrd requirements.

Comment on attachment 336838 [details]
patch as suggested by Kay's comment #18.

Obsoleted by attachment 336860 [details]

Comment on attachment 336838 [details]
patch as suggested by Kay's comment #18.

This patch is still valid for straight testing in a system.

Revoked the openSUSE Build Service request from comment #20.

Tried on one ICH4 machine on both 11.2 and Factory. Worked on both. :-)

(In reply to comment #15)
> remove the whole root= string from the Grub kernel line
> and see what happens.
> ### Felix end

> If that works then we have a much simpler solution to address this issue.

This is still valid. Totally removing root=whatever from the Grub kernel line does not seem to impose any obstacle to getting current Factory up and running.

(In reply to comment #15)
> A reread of https://bugzilla.novell.com/show_bug.cgi?id=483136#c13 gave me
> another idea to try: remove the whole root= string from the Grub kernel line
> and see what happens.

I'm not sure that I get you right but completely removing root= is not always an option: I do have multiple root partitions on my notebook disk (11.1, 11.2, 32/64 bit, testing, maybe again a factory system at some time...) so I have to specif root=... to tell which fs to boot ?!?

I was suggesting something is wrong if boot succeeds in the absence of root=... on cmdline. I have few systems on which fewer than several root filesystems exist.

(In reply to comment #21)
> Created an attachment (id=336860) [details]
> Add patch fitting to the gitorious.org/opensuse/mkinitrd requirements.

Thanks, applied.

On a fresh M2 install on software RAID1, both root=LABEL=10suse113 and root=/dev/md3 fail. The fallbacks don't work either. The only way I've found to boot M2 so far is root=/dev/sda10.

Are there any error messages printed besides the 
Are you able to manually assemble the array in the emergency shell?
# mdadm --assemle /dev/md3 /dev/sda10 /dev/...
can you boot with linuxrc=debug and capture the mkinird output via a serial console?
I need some more data "it fails" :).

"It fails" means the same thing here as I wrote in comment 0. Quoting comment 0: "Waiting for device /dev/root to appear ... could not find /dev/root ... want to fall back to /dev/....". With root=LABEL=10suse113 on cmdline, it's /dev/md3 that it asks to fall back to, then after answering y, it's "Waiting for
device /dev/md3 to appear ... not found -- exiting to /bin/sh; sh: cannot set terminal process group (-1): Inappropriate ioctl for device; sh: no job control in this shell; $"

'$ mdadm --assemle /dev/md3 /dev/sda10 /dev/sdb10' appears to work, with 'mount -t ext3 /dev/md3 /' also working, but I don't know what to try next, as 'init 1' next fails.

If I boot with root=/dev/sda10 on cmdline I get what appears to be a normal boot result, with /dev/md10 on /. Should I add linuxrc=debug to that and then run mkinitrd? I don't know capture via serial console process. Will /boot/log/YaST2/mkinitrd.log provide the output you want instead?

I must have typed something wrong when I tried to boot by changing from root=LABEL=10suse113 to root=/dev/md10 in the gfx Grub edit box before writing comment 29. Now when I try root=/dev/md10 I get what seems to be a normal boot with no apparent waiting for /dev/root to appear. /dev/md[0-6] are all mounted where they belong according to mount output.

If you boot with linuxrc=debug, the initrd's /init will run under set -x, i.e. print all commands as they are executed. But you'd need a second computer and a serial cable to save the output, so let's try something different.

You say that root=/dev/md10 actually works, so at least it's not a problem with the md array assembly. Can you boot into the emergency shell again and do the following:
# mount /dev/md10 /root
# rm -f /root/tmp/mkinitrd-debug
# cat /etc/udev/rules.d/99-mkinitrd-label.rules >/root/tmp/mkinitrd-debug
# udevadm info --export-db >/root/tmp/mkinitrd-debug
# umount /root
# ln -s md10 /dev/root
# exit

Hopefully the system should continue booting after creating the symlink manually. Please attach the /tmp/mkinitrd-debug afterwards.

(In reply to comment #32)
> # cat /etc/udev/rules.d/99-mkinitrd-label.rules >/root/tmp/mkinitrd-debug
> # udevadm info --export-db >/root/tmp/mkinitrd-debug

Oops, please use '>>' here instead:
# udevadm info --export-db >>/root/tmp/mkinitrd-debug

Created attachment 343797 [details]
/root/mkinitrd-debug

(In reply to comment #32)
> Can you boot into the emergency shell again and do the
> following:
> # mount /dev/md10 /root

The choices here are /dev/md3, /dev/sda10 or /dev/sdb10, the latter two of which comprise /dev/md3.

$ mount -t ext3 /dev/md3 /root
mount: special device /dev/md3 does not exist

$ mdadm --assemble /dev/md3 /dev/sda10 /dev/sdb10
$ mount -t ext3 /dev/md3 /root
$ rm -f /root/tmp/mkinitrd-debug
$ cat /etc/udev/rules.d/99-mkinitrd-label.rules >/root/root/mkinitrd-debug
$ udevadm info --export-db >/root/root/mkinitrd-debug
$ umount /root
$ ln -s md3 /dev/root
ln: creating symbolic link `/dev/root': File exists
$exit

[apparently normal init]

Ah, I'm getting it. The problem here is that the md array is not assembled if you boot with root=LABEL=, because the md script does not know that an md root is needed. I think this scenario has never worked. BTW, once the array is assembled manually, the /dev/root symlink is correctly created, so this is a differenc bug than the original 11.2 report.

Created attachment 343802 [details]
/root/mkinitrd-debug

Looks like the first try I typed udevadm info --export-db >/root/root/mkinitrd-debug instead of udevadm info --export-db >>/root/root/mkinitrd-debug. :-(

I did /root/root/... instead of /root/tmp/... because normally /dev/md0 is mounted on /tmp.

(In reply to comment #36)
> Ah, I'm getting it. The problem here is that the md array is not assembled if
> you boot with root=LABEL=, because the md script does not know that an md root
> is needed. I think this scenario has never worked.

I think it has:
# cat /etc/SuSE-release
openSUSE 11.0 (i586)
VERSION = 11.0

# uname -r
2.6.27.37-0.3-pae

# cat /proc/cmdline
root=LABEL=08suse110 noresume splash=off vga=0x305 3

# mount | grep md
/dev/md1 on / type ext3 (rw,noatime,acl,user_xattr)
/dev/md0 on /tmp type ext3 (rw,noatime,acl,user_xattr)
/dev/md4 on /pub type ext3 (rw,noatime,acl,user_xattr)
/dev/md5 on /srv type ext3 (rw,noatime,acl,user_xattr)
/dev/md6 on /home type ext3 (rw,noatime,acl,user_xattr)

(In reply to comment #36)
> BTW, once the array is
> assembled manually, the /dev/root symlink is correctly created, so this is a
> differenc bug than the original 11.2 report.

This bug does seem fixed on a different/non-RAID fresh M2 install, where I'm booted with 'cat /proc/cmdline':

root=LABEL=H16A-22factory noresume splash=verbose vga=0x305 3

Update released for: mkinitrd, mkinitrd-debuginfo, mkinitrd-debugsource
Products:
openSUSE 11.2 (debug, i586, x86_64)

(In reply to comment #36)
> once the array is
> assembled manually, the /dev/root symlink is correctly created, so this is a
> differenc bug than the original 11.2 report.

Bug 583424 filed due to above comment.

OK, let's close this one then.

This was filed against 11.2. I just updated an 11.2 system to test this. It wasn't fixed. Then I ran mkinitrd, and it still isn't fixed.

This is an autogenerated message for OBS integration:
This bug (483136) was mentioned in
https://build.opensuse.org/request/show/30010 Factory / mkinitrd