Bugzilla – Bug 567225
After "An error occurred during initrd creation" message, new install does not boot
Last modified: 2012-06-18 14:21:50 UTC
Created attachment 334232 [details] Screenshot of the error in a "Repair Installation" session User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091103 SUSE/3.5.5-1.1.2 Firefox/3.5.5 During initial installation the creation of an initrd fails with the following message: Device block!9:0 not found in sysfs The same happens when I try to "Repair Installation" Details: - I'm trying to create a new installation where the root filesystem is on a md raid1 device (/dev/md0) - My box has 3 HDs - /dev/md0 is configured with /dev/sda5 and /dev/sdc5, each partition 15GB - /dev/md0 is formatted as ext4 and seem to have the correct content - /boot is mounted from /dev/sda1 Reproducible: Always Steps to Reproduce: 1. Error message during install 2. Grub won't boot new installation 3.
See attached screenshot of the actual error
I have the same problem, with a configuration that is comparable to th OP's: - /dev/sda1 formatted with ext2, mountpoint on /boot, 1 GB - a raid-1 array from /dev/sda2 through /dev/sdd2, 10 GB, labeled 'root', mountpoint / - a raid5 array from /dev/sda3 through /dev/sdd3, each 920 GB, net appr. 2.8 TB, labeled 'home', mountpoint /home Both raid devices are mounted by label. Partitioning and creating the arrays went during install with Yast without error messages, but during install of software I saw messages Device block!9:0 not found in sysfs flying by. When it was time for Yast to create the initrd, the message Kernel image: /boot/vmlinuz-2.6.31.5-0.1-desktop Initrd image: /boot/initrd-2.6.31.5-0.1-desktop Root device: ext4-root (/dev/block/9:0) (mounted on / as ext4) Device block!9:0 not found in sysfs was given, and it appeared no initrd was created: drwxr-xr-x 4 root root 4096 jan 15 16:35 ./ drwxr-xr-x 22 root root 4096 jan 15 16:18 ../ -rw------- 1 root root 512 jan 15 16:35 backup_mbr lrwxrwxrwx 1 root root 1 jan 15 16:18 boot -> ./ -rw-r--r-- 1 root root 1236 okt 24 04:19 boot.readme -rw-r--r-- 1 root root 103289 okt 27 12:30 config-2.6.31.5-0.1-desktop drwxr-xr-x 2 root root 4096 jan 15 16:35 grub/ lrwxrwxrwx 1 root root 27 jan 15 16:20 initrd -> initrd-2.6.31.5-0.1-desktop drwx------ 2 root root 16384 jan 15 15:56 lost+found/ -rw-r--r-- 1 root root 421376 jan 15 16:35 message -rw-r--r-- 1 root root 170143 okt 27 12:32 symvers-2.6.31.5-0.1-desktop.gz -rw-r--r-- 1 root root 1907577 okt 27 11:31 System.map-2.6.31.5-0.1-desktop lrwxrwxrwx 1 root root 28 jan 15 16:20 vmlinuz -> vmlinuz-2.6.31.5-0.1-desktop -rw-r--r-- 1 root root 4104416 okt 27 11:31 vmlinuz-2.6.31.5-0.1-desktop No need to say booting this arrangement fails. After booting the system from another disk with 11.2, and assembling and mounting the raid fs'es (with goes flawlessly; here too the content seems correct), I tried to create the initrd by hand with mount /dev/md0 /mnt/root mount /dev/sda1 /mnt/root/boot mount --bind /dev /mnt/root/dev chroot /mnt/root mount /proc mount /sys mkinitrd as suggested by the mkinitrd man page. But this gives the same error, and no initrd is created in the chrooted /boot. Hardware is Gigabyte GA-MA790FXT-UD5P mobo, AMD Phenom II X4 955 / 3.2 GHz Black Edition, memory 4GB OCZ Platinum Dual Channel DDR3 1333 MHz 1.65 V
Can you run bash -vx /sbin/mkinitrd &>log in the chroot and attach the log?
I'd need to re-install the box, which can take a few days given my current schedule.
Jogchum said in comment 2 that he also saw this when running mkinitrd in chroot after the system has been installed, which is why I set needinfo to him.
Ok. That was not entirely clear.
Created attachment 338332 [details] Logfile of mkinitrd in chrooted environment
I have attached the log file. I'll be off during part of the weekend, so I'll be somewhat unresponsive. Back saterday evening regards, Jogchum
I have the same problem. Running 2 HDs as a raid1. /dev/md0 as / /dev/md1 as swap /dev/md2 as /srv I told fstab to use labels and grub uses mbr. During installation I get the error "Device block!9:0 not found in sysfs" and grub won't boot. I also tried Ext3 instead of Ext4.
Please do not touch the priority field.
Sorry, I changed it back to the last state. I tried again a new installation with my 2 HDs and software raid1 partitions. But this time I used GPD as partition table and I told fstab to use the device names instead of the device labels. And now it works. I can also do a kernel update.Strange...I think GPD has nothing do to with it. Perhabs you need to tell fstab to use the device names. The first time I tried the installation with raid1 arrays I used DOS as partition tabel and fstab used device names. The installation was fine. Then I changed fstab to use device labels and the system was fine. I tried different RAID failures and everything worked like expected. But then I did a kernel update and after reboot I got the errors. Perhaps this information is useful. I have now a working system, but I would still like to use device labels.
Hi Michal, Any progress on this one? Status is not NEEDINFO, so I take it you don't expect anything from me right now. I won't touch the priority field, but is None the accurate priority for a failing installation?
Sorry, no progress. I'm on vacation for the next week, I'll look into the mkinitrd bugs after that.
There are two bugs in there: (In reply to comment #8) > Created an attachment (id=338332) [details] > Logfile of mkinitrd in chrooted environment There are two bugs in there: 1) mkinitrd does not understand the LABEL=root entry in your fstab 2) the beautify_blockdev() function, which is used as a fallback, returns the /dev/block/9:0, which the rest of the functions can't cope with. This is due to a new udev version probably, /sbin/udevadm info -q symlink now prints this symlink as the first entry.
@Michal Marek: Hope you had a good holiday! So I take it that I should change fstab to identifying the array by its device name? Which has some risks mixing the two arrays, I understand. But i'll give it a try, of course. Will the LABEL= identifier be understood by mkinitrd in the near future? regards, Jogchum
(In reply to comment #16) > Will the LABEL= identifier be understood by mkinitrd in the near future? I very much hope so... For more than 2 years now I'm using nothing else but filesystem LABELs in /etc/fstab and /boot/grub/menu.lst. No matter how the disk layout or device names look (esp. when virtualizing), it _always_ works. Regards, Gábor
Yes, using the device name should be a workaround. I would like to fix LABEL= support, but I'm not giving any promise as to when it's going to happen.
Using device name i not a workaround. At least for my setup. I tried with different fstab options. LAbel, device name, uuid. I also tried putting /boot partition on plain normal non raid volume(sda1). Here's my to be setup: 6 HDs (sd[a,b,c,d,e,f,g]) /boot: sda1,sdb1 -> RAID1 /: {(sda2,sdb2,sdc2) RAID0 , (sdd2,sde2,sdf2)RAID0} -> RAID1 /home:{(sda3,sdb3,sdc3) RAID0 , (sdd3,sde3,sdf3)RAID0} -> RAID1 As said I tried with different setups for /boot partition. None worked. I'm using a minimal server install with some additional packages. Boot loader is installed to MBR. I have yast log files if needed.
Created attachment 351317 [details] yast logs upon install
Created attachment 351319 [details] yast logs with label fstab option
This seems to overlap or be a dupe of bug 586044. I just installed M6 where M2 had been installed previously with success, but later updated, and initrd creation for newer kernel failed. Manual initrd creation also failed with "Device block!9:X not found in sysfs". Mkinitrd succeeded when I replaced mounting of / by-label with /dev/md3, and the initrd it created results in boot success.
I believe this is fixed in 11.3 and later, please reopen if this is not the case. *** This bug has been marked as a duplicate of bug 583424 ***