Bug 848576

Created attachment 565798 [details]
Screen photo of error

No place for attachments in simple bug entry...

Created attachment 565799 [details]
/boot/grub/menu.lst from prior system

Created attachment 565800 [details]
menu.lst after performing update

In other words, the problem is that system switched from by-id to devices. Any idea about the reason, like e.g. setting the DEVICE_NAMES variable in /etc/sysconfig/storage? What does the value say?

Current value:

gwb@gidney:~> grep DEVICE /etc/sysconfig/storage 
DEVICE_NAMES="id"

I wouldn't mind it using devices names, if it used the correct one.  Only one HDD, so no sdb.  And why only for root= ?

Well, when you have a USB stick inserted, you instantly have two HDDs. And it can differ between boots which one is sda and sdb when you boot with a different initrd (which is the case - installation initrd differs from the one the installation creates.

Please attach /var/log/YaST2/ and /var/log/pbl.log.

Created attachment 566569 [details]
tar of /var/log/YaST2/  as requested

Created attachment 566570 [details]
/var/log/pbl.log    as requested

The problem is that Storage::GetMountPoints() returns /dev/sdb7 for '/' even though fstab has the correct /dev/disk/by-id/ata-ST9250315AS_6VCLFYMY-part7.

Cf. 'Storage.rb:5397' in y2log-1.

Storage::GetMountPoints() returns the device name by design. The bootloader
code even converts the result to a more useful value depending on the
mountby method. Unfortunately RootPart.rb sets that to `device for /.

modules/RootPart.rb:183 Setting partition data: Device: /dev/sdb7, MountPoint: /
modules/Storage.rb:5414 SetPartitionData device=/dev/sdb7 key=mount value=/
modules/Storage.rb:5414 SetPartitionData device=/dev/sdb7 key=mountby value=`device

There are apparently two issues:

1) yast2-storage for some reason says to use by-device for sdb7
2) yast2-bootloader doesn't use by-id even if yast2-storage said so

But fortunately this normally doesn't matter because the first kernel install
will fix menu.lst. RC1 -> RC2 didn't have a kernel update, so the bug became
visible.

The reason for point 1 is the update code as explained in comment #11.
But bootloader must be fixed anyway, thus assigning to Steffen.

I check code in bootloader and in fact it do exactly what storage want. It found that device /dev/sdb7 is mounted by :device and not by :id .
Arvin see e.g. line 3210 so bootloader (sdb7 => mountby => :device) code works as expected.

And yast2-storage returns the data yast2-update sets, see comment #11.

arvin - it is handled in this code https://github.com/yast/yast-update/blob/master/src/modules/RootPart.rb#L193

From log:
3122 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/RootPart.rb:183 Setting partition data: Device: /dev/disk/by-id/ata-ST9250315AS_6VCLFYMY-part8, MountPoint: /home
3123 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/Storage.rb:5414 SetPartitionData device=/dev/disk/by-id/ata-ST9250315AS_6VCLFYMY-part8 key=mount value=/home
3124 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/Storage.rb:5414 SetPartitionData device=/dev/disk/by-id/ata-ST9250315AS_6VCLFYMY-part8 key=mountby value=`id
3125 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/RootPart.rb:183 Setting partition data: Device: proc, MountPoint: /proc
3126 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/Storage.rb:5414 SetPartitionData device=proc key=mount value=/proc
3127 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/Storage.rb:5414 SetPartitionData device=proc key=mountby value=`label
3128 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/RootPart.rb:183 Setting partition data: Device: sysfs, MountPoint: /sys
3129 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/Storage.rb:5414 SetPartitionData device=sysfs key=mount value=/sys
3130 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/Storage.rb:5414 SetPartitionData device=sysfs key=mountby value=`label
3131 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/RootPart.rb:183 Setting partition data: Device: /dev/sdb7, MountPoint: /
3132 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/Storage.rb:5414 SetPartitionData device=/dev/sdb7 key=mount value=/
3133 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/Storage.rb:5414 SetPartitionData device=/dev/sdb7 key=mountby value=`device
3134 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/RootPart.rb:224 Setting swap partition data: Device: /dev/disk/by-id/ata-ST9250315AS_6VCLFYMY-part6
3135 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/Storage.rb:5414 SetPartitionData device=/dev/disk/by-id/ata-ST9250315AS_6VCLFYMY-part6 key=mount value=swap
3136 2013-10-31 16:15:06 <1> linux(2569) [Ruby] modules/Storage.rb:5414 SetPartitionData device=/dev/disk/by-id/ata-ST9250315AS_6VCLFYMY-part6 key=mountby value=`id 

so as you can see for /dev/sdb7 it returns in target map :device /dev/sdb7
but for rest it return correct by-id device like /dev/disk/by-id/ata-ST9250315AS_6VCLFYMY-part8 for /home.

So do you have idea why it return different device? ( beside that code in update is really quite stupid and fragile from my POV)

The values are taken from @activated (which is logged).

AFAIS the code goes through all potential devices (using kernel device
names), mounts them and looks for a fstab. The root device is then added
to @activated while the other devices and takes from the found fstab.
Thus the root device uses the kernel device name.

The code seems indeed fragile and broken, e.g. the mount-by detection
in AddToTargetMap does not handle by-path or by-uuid. I suppose the code
only gets a bug fix once in a while but otherwise no attention.

Possible fix would be:

...
the code goes through all potential devices (using kernel device
names), mounts them and looks for a fstab. The root device is then added
to @activated
...

Root device should be taken from the fstab found, so instead of using
/dev/sd... anything found in fstab with mountpoint "/" would be used.

I'll have a look.

But this is low-prio now, sorry.

we no longer support grub1. so sorry, we do not find time for it till it is obsoleted.