Bug 444378 - Kernel upgrade problems with devices
Summary: Kernel upgrade problems with devices
Status: RESOLVED DUPLICATE of bug 441384
Alias: None
Product: openSUSE 11.1
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Factory
Hardware: x86-64 Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Kay Sievers
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-12 21:05 UTC by Luis Medinas
Modified: 2008-11-28 16:36 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
fstab (438 bytes, application/octet-stream)
2008-11-13 19:56 UTC, Luis Medinas
Details
grub conf (3.50 KB, application/octet-stream)
2008-11-13 19:57 UTC, Luis Medinas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luis Medinas 2008-11-12 21:05:09 UTC
Since i upgraded to 11.1 (around beta2) i have some problems with initrd, grub and fstab.

On my fstab i list my disks partitions as /dev/dm-x
grub and initrd uses /dev/mapper/sil_agaecedfccfb_part1

but when i boot kernel it falls back to /dev/disk/by-id/ata-Maxtor_6V250F0_V596HXEG-part1

and the funny part is df -h shows
Filesystem Size Used Avail Use% Mounted on
/dev/dm-1 97G 74G 18G 81% /


This make my latest factory kernel unbootable.

Shouldn't kernel upgrades test or attribute the real devices ? I suspect something goes wrong with udev.
Comment 1 Alexander Orlovskyy 2008-11-13 14:08:41 UTC
Reassign to kernel-maintainers.
Comment 2 Kay Sievers 2008-11-13 16:05:49 UTC
(In reply to comment #0 from Luis Medinas)
> Since i upgraded to 11.1 (around beta2) i have some problems with initrd, grub
> and fstab.
> 
> On my fstab i list my disks partitions as /dev/dm-x
> grub and initrd uses /dev/mapper/sil_agaecedfccfb_part1
> 
> but when i boot kernel it falls back to
> /dev/disk/by-id/ata-Maxtor_6V250F0_V596HXEG-part1

What means "falls back"? It waits for that at bootup?

> and the funny part is df -h shows
> Filesystem Size Used Avail Use% Mounted on
> /dev/dm-1 97G 74G 18G 81% /

What do you mean?

> This make my latest factory kernel unbootable.
> 
> Shouldn't kernel upgrades test or attribute the real devices ? I suspect
> something goes wrong with udev.

Please attach:
  /etc/fstab
and
  /boot/grub/menu.lst
and the output of:
  cat /proc/cmdline
of the working kernel.
Comment 3 Luis Medinas 2008-11-13 19:56:28 UTC
Created attachment 252027 [details]
fstab
Comment 4 Luis Medinas 2008-11-13 19:57:45 UTC
Created attachment 252029 [details]
grub conf
Comment 5 Luis Medinas 2008-11-13 20:00:03 UTC
cat /proc/cmdline
root=/dev/mapper/sil_agaecedfccfb_part1 resume=/dev/mapper/sil_agaecedfccfb_part2 splash=silent vga=0x31a

During the boot it waits for /dev/mapper/sil_agaecedfccfb_part1 but then goes to 
/dev/disk/by-id/ata-Maxtor_6V250F0_V596HXEG-part1

So the devices are really messed up, this shouldn't happen on upgrades.
Comment 6 Kay Sievers 2008-11-13 20:02:39 UTC
Hmm, no idea where the other string is coming from.

Did you run "mkinitrd" to rebuild the initramfs image? What does it print when you run it?
Comment 7 Luis Medinas 2008-11-13 20:07:11 UTC
Yes i run everytime i upgrade the kernel.

mkinitrd

Kernel image:   /boot/vmlinuz-2.6.27.4-10-default
Initrd image:   /boot/initrd-2.6.27.4-10-default
Root device:	/dev/disk/by-id/ata-Maxtor_6V250F0_V596HXEG-part1 (/dev/sda1) (mounted on / as ext3)
Kernel Modules:	hwmon thermal_sys processor thermal dock scsi_mod libata pata_marvell ata_piix fan jbd mbcache ext3 edd crc-t10dif sd_mod usbcore ohci-hcd uhci-hcd ehci-hcd ff-memless hid usbhid 
Features:       block usb resume.userspace resume.kernel
Bootsplash:	openSUSE (1280x1024)
48403 blocks
2008-11-13 20:05:32 WARNING: GRUB::GrubDev2UnixDev: No partition found for /dev/mapper/sil_agaecedfccfb with 1.

Comment 8 Kay Sievers 2008-11-13 20:15:59 UTC
(In reply to comment #7 from Luis Medinas)
> Yes i run everytime i upgrade the kernel.

> Root device:    /dev/disk/by-id/ata-Maxtor_6V250F0_V596HXEG-part1 (/dev/sda1)

Hmm, mkinitrd uses this as your root for some reason.

What does:
  cat /proc/mounts
on the running system print?

What does:
  mountpoint -d /
on the running system print?

You can also try to override the root device for mkinitrd with:
  mkinitrd -d <root device>
Comment 9 Luis Medinas 2008-11-13 20:31:23 UTC
cat /proc/mounts
rootfs / rootfs rw 0 0
udev /dev tmpfs rw,mode=755 0 0
/dev/sda1 / ext3 rw,errors=continue,user_xattr,acl,barrier=1,data=ordered 0 0
/proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
debugfs /sys/kernel/debug debugfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
securityfs /sys/kernel/security securityfs rw 0 0
/dev/sda3 /media/windows fuseblk rw,user_id=0,group_id=0,allow_other,blksize=4096 0 0
gvfs-fuse-daemon /home/metalgod/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,user_id=1000,group_id=100 0 0

mountpoint -d /
8:1

Now the question is: what root device should i use to generate the new initrd ?

Thanks for being so helpful and responsive.
Comment 10 Kay Sievers 2008-11-13 20:39:42 UTC
(In reply to comment #9 from Luis Medinas)
> cat /proc/mounts

> /dev/sda1 / ext3 rw,errors=continue,user_xattr,acl,barrier=1,data=ordered 0 0

mkinitrd seems right, you do not use the dm device as the root filesystem, but boot from the "plain" partition.

> mountpoint -d /
> 8:1

Same here, this is the device number of sda1, not a dm device.

> Now the question is: what root device should i use to generate the new initrd ?

The root= string in the grub conf, the line for "/" in /etc/fstab and the root for mkinitrd should all be the same to work as expected.

If you want to boot from the dm device, you should try passing the same string as you currently have in grub.conf and fstab to mkinitrd. I can not tell if that will work though.

The other option, if you do not want to use device mapper as your root filesystem, is to use /dev/disk/by-id/ata-Maxtor_6V250F0_V596HXEG-part1 in the grub.conf, fstab.
Comment 11 Luis Medinas 2008-11-17 01:09:32 UTC
ok the problem is fixed for me.
The problem was device.map and grub.conf wasn't updated after devices changed. Should this pointed to grub maintainers ?
Comment 12 Kay Sievers 2008-11-17 01:24:25 UTC
Seems it is all caused by this bug:
  https://bugzilla.novell.com/show_bug.cgi?id=441384
which is hopefully already fixed. Device names should not change like it did in your case.
Comment 13 Kay Sievers 2008-11-28 16:36:16 UTC

*** This bug has been marked as a duplicate of bug 441384 ***