Bug 525237

Message when installing this way:

Device md0 not handled

Script /lib/mkinitrd/setup/72-block.sh failed!

Is this BUG any important or is this way of installing too "exotic"?

By the way to be more specific, a /boot partition was separate as a primary partition (ext2).

i've a similar scenario.

/boot on /dev/md0, RAID-1

VG backed on /dev/md1, RAID-1
   swap             |
   /root            | LVMs on VG
   other ...        |

on OS 11.1, no problems installing/booting/upgrading, or exec of mkinitrd.

run zypper-based upgrade (today) from OS 11.1 -> Factory, fail (as above) at kernel install.

'ignore' fail, complete install (no other errors), then attempt,

mkinitrd -v

 Kernel image:   /boot/vmlinuz-2.6.31-rc5-git3-2-default
 Initrd image:   /boot/initrd-2.6.31-rc5-git3-2-default
 Root device:	/dev/root (mounted on / as ext3)
 Device md1 not handled
 Script /lib/mkinitrd/setup/72-block.sh failed!

 Kernel image:   /boot/vmlinuz-2.6.31-rc5-git3-2-xen
 Initrd image:   /boot/initrd-2.6.31-rc5-git3-2-xen
 Root device:	/dev/root (mounted on / as ext3)
 Device md1 not handled
 Script /lib/mkinitrd/setup/72-block.sh failed!

fyi, saw similar issue on 11.1/Factory @,
 https://bugzilla.novell.com/show_bug.cgi?id=421379

since 'mkinitrd -v' doesn't seem to be any more verbose than just 'mkinitrd', here's the (relevant?) output with "set -x",

...
++ blockminor=1
+++ block_driver 9
+++ sed -n '/^Block devices:/{n;: n;s/^[ ]*9 \(.*\)/\1/p;n;b n}'
++ blockdriver=md
++ '[' '!' md ']'
++ '[' md = device-mapper ']'
++ false
+++ majorminor2blockdev 9 1
+++ local major=9 minor=1
+++ '[' '!' 1 ']'
+++ '[' 9 -lt 0 ']'
++++ cat /proc/partitions
++++ egrep '^[ ]*9[ ]*1 '
+++ local 'retval=   9     1  243987048 md1'
+++ echo /dev/md1
++ blkpart=/dev/md1
++ '[' /dev/md1 ']'
+++ echo md1
+++ sed 's./.!.g'
++ blkpart=md1
+++ echo md1
+++ sed 's/\([a-z]\)[0-9]*$/\1/;s/p$//'
++ blkdev=md
++ '[' -d /sys/block/md/md1 ']'
+++ update_list /dev/md1
+++ local elem=/dev/md1
+++ shift
+++ case " $@ " in
+++ echo ' /dev/md1'
++ blockpart_blockdev=' /dev/md1'
++ blockdev=' /dev/md1'
+ '[' 0 -ne 0 ']'
+ for setupfile in '$INITRD_PATH/setup/*.sh'
+ '[' -d /dev/shm/mkinitramfs.53DRvf/mnt ']'
+ cd /dev/shm/mkinitramfs.53DRvf/mnt
+ '[' '!' -d /lib/mkinitrd/setup/72-block.sh ']'
+ curscript=block.sh
+ source /lib/mkinitrd/setup/72-block.sh
++ '[' '' ']'
++ all_libata_modules_included=0
++ for bd in '$blockdev'
++ case $bd in
++ update_blockdev /dev/md1
++ local curblockdev=/dev/md1
++ '[' /dev/md1 ']'
++ '[' /dev/md1 ']'
++ blockmajor=-1
++ blockminor=-1
++ '[' -e /dev/md1 ']'
+++ devnumber /dev/md1
++++ ls -lL /dev/md1
+++ set -- brw-rw---- 1 root disk 9, 1 2009-03-17 16:21 /dev/md1
+++ mkdevn 9 1
+++ local major=9 minor=1
+++ echo 9437185
++ blockdevn=9437185
+++ devmajor 9437185
+++ local devn=9437185
+++ echo 9
++ blockmajor=9
++ '[' '!' 9 ']'
+++ devminor 9437185
+++ local devn=9437185
+++ echo 1
++ blockminor=1
+++ block_driver 9
+++ sed -n '/^Block devices:/{n;: n;s/^[ ]*9 \(.*\)/\1/p;n;b n}'
++ blockdriver=md
++ '[' '!' md ']'
++ '[' md = device-mapper ']'
++ false
++ get_devmodule md1 curmodule
++ local result=
+++ echo md1
+++ sed 's./.!.g'
++ local blkdev=md1
++ '[' '!' -d /sys/block/md1 ']'
++ case "$blkdev" in
++ '[' '!' -d /sys/block/md1/device ']'
++ echo 'Device md1 not handled'
Device md1 not handled
++ return 1
++ '[' 1 -eq 0 ']'
++ return 1
+ '[' 1 -ne 0 ']'
+ oops 1 'Script /lib/mkinitrd/setup/72-block.sh failed!'
+ echo 'Script /lib/mkinitrd/setup/72-block.sh failed!'
Script /lib/mkinitrd/setup/72-block.sh failed!
+ cleanup
+ rm -f /dev/shm/mkinitramfs.53DRvf/initrd /dev/shm/mkinitramfs.53DRvf/initrd.gz
+ '[' -d /dev/shm/mkinitramfs.53DRvf/mnt ']'
+ rm -rf /dev/shm/mkinitramfs.53DRvf/mnt
+ initrd_bins=()
+ exit_code=1
+ exit 1
+ exit_code=1
+ '[' -e /dev/shm/mkinitramfs.53DRvf/error ']'
+ (( i++ ))
+ (( 1<2  ))
+ echo
...
++ echo 'Device md1 not handled'
Device md1 not handled
++ return 1
++ '[' 1 -eq 0 ']'
++ return 1
+ '[' 1 -ne 0 ']'
+ oops 1 'Script /lib/mkinitrd/setup/72-block.sh failed!'
+ echo 'Script /lib/mkinitrd/setup/72-block.sh failed!'
Script /lib/mkinitrd/setup/72-block.sh failed!
+ cleanup
+ rm -f /dev/shm/mkinitramfs.53DRvf/initrd /dev/shm/mkinitramfs.53DRvf/initrd.gz
+ '[' -d /dev/shm/mkinitramfs.53DRvf/mnt ']'
+ rm -rf /dev/shm/mkinitramfs.53DRvf/mnt
+ initrd_bins=()
+ exit_code=1
+ exit 1
+ exit_code=1
+ '[' -e /dev/shm/mkinitramfs.53DRvf/error ']'
+ (( i++ ))
+ (( 2<2  ))
+ cleanup_finish
+ umount_proc
+ '[' '' ']'
+ mounted_proc=
+ '[' '' ']'
+ mounted_sys=
+ '[' '' ']'
+ mounted_usr=
+ '[' -d /dev/shm/mkinitramfs.53DRvf ']'
+ rm -rf /dev/shm/mkinitramfs.53DRvf
+ '[' '!' -x /sbin/update-bootloader ']'
+ '[' 1 -eq 0 ']'
+ exit 1

changing severity, as the machine's unbootable in this state ...

just fyi,

upgrading mkinitrd to,

  http://download.opensuse.org/repositories/home:/thomasbiege:/branches:/Base:/System/openSUSE_Factory/x86_64/mkinitrd-2.5.10-25.1.x86_64.rpm


does NOT solve the problem ...

Please read http://en.opensuse.org/Bugs/Definitions#Blocker

(In reply to comment #8)
> Please read http://en.opensuse.org/Bugs/Definitions#Blocker


I *DID* read it:

"Blocker

    * Prevents developers or testers from performing their jobs. Impacts the development process. "


we ARE doing 'development or testing' -- not just _of_ Factory , but of our own products/services.

this bug, and the inability to boot as a result, DOES prevent our folks from doing their jobs, and DOES impact the development process.

the *specific* examples given for 'Blocker' severity are,

    * Unable to login
    * Unable to perform certification tests
    * Unable to update system 

all three of which are tru in in this case.

if you have different definitions of the criteria, or suggest that it's only relevant for *suse's developers/tester, then that should be clearly stated in the docs you reference.  in the meantime ...

Mr. Pgnet (or Mr. Dev?):

What is impossible here is to have /boot on md, not installation per se, i.e. a workaround exists. This makes it IMO not suitable as a blocker. YMMV, but we have to work on this.

Yast folks: IIRC RAID-0 is not suited for /boot, unless it maps perfectly to a BIOS fake RAID. RAID-1 might work. LVM does not.

What strikes me from the log pasted above is the line
 md = device-mapper 

So please make boot setup/initrd creation consistent with the installation scenario offered initially.

The first please attach YaST logs.

Next if you play with md raid it is possible boot only from MBR. There is problem with kernel caching and it is not possible boot from /boot (or "/") partition if it is on md raid. I mean scenario (which doesn't work): 
* write generic boot code to MBR
* set boot flag on /boot (or "/") partition on md raid
* write GRUB stage1 to /boot (or "/") partition on md raid

I am sure that if you use only md raid yast propose boot from MBR (resp. write GRUB to MBR) I am not sure about LVM on md raid but I see same problem like only with md raid and finally if you want to use LVM you HAVE TO separate /boot partition out of LVM and in this case out of md raid!

(In reply to comment #11)
> The first please attach YaST logs.
> 
> Next if you play with md raid it is possible boot only from MBR. There is
> problem with kernel caching and it is not possible boot from /boot (or "/")
> partition if it is on md raid. I mean scenario (which doesn't work): 
> * write generic boot code to MBR
> * set boot flag on /boot (or "/") partition on md raid
> * write GRUB stage1 to /boot (or "/") partition on md raid
> 
> I am sure that if you use only md raid yast propose boot from MBR (resp. write
> GRUB to MBR) I am not sure about LVM on md raid but I see same problem like
> only with md raid and finally if you want to use LVM you HAVE TO separate /boot
> partition out of LVM and in this case out of md raid!

Tell me what logs and how can i get them. I ALWAYS have separate /boot since GRUB can't understand LVM? 

What i did is i created a RAID-0 stripe (software linux kernel RAID) made of two partitions marked as RAID. Then after YaST created that stripe i created an LVM group on that stripe. /boot was separate as i said.

Nevermind, i will test both M4 and M5 with that scenario.

"What is impossible here is to have /boot on md"?

as i said,

  /boot on /dev/md0, RAID-1
  VG backed on /dev/md1, RAID-1
     swap             |
     /root            | LVMs on VG
     other ...        |

works just fine on OS 11.1, and has been on production systems, ... no workarounds required.  just follow the instructions @ http://en.opensuse.org/How_to_install_SUSE_Linux_on_software_RAID.

as for the severity -- clearly a non-bootable system is not a concern to others.  i happen to disagree ...

Piotrek, if you're interested in this scenario, my suggestion is 'back to 11.1'.  which is exactly what i'm doing ...

Well to be honest you misinterpreted my bug report. I reported that the system fails to build initrd when the / is on on an LVM which is on a RAID-0. From what i've heard /boot on RAID-1 is fine but not on RAID-0. My scenario involves creating a RAID-0 stripe with separate /boot partition and on top of that RAID-0 stripe (which is not formatted as suggested normally) is a LVM group in which i create / root partition.

Created attachment 312726 [details]
Yast 2 Log

Here comes the yast log made on VirtualBox with the same setup as on my main machine (i guess it isn't hardware related since it happened on both VirtualBox and my main machine?)

Piotrek, thanks for yast logs.

I know there is little bit misunderstanding of terminology. I am sorry for it. I try to use complete desription of boot settings instead of names of checkbox from y2-bootloader. ;-)

OK lets start:

comment#12:
==========
* Please take a fact that GRUB doesn't know to boot from LVM you need separate /boot partition out of LVM (yast2-storage should warning you during creating LVM that you need separate /boot partition)

* Boot from raid0 is not possible if it is software raid. GRUB works with physical partitions not with sw raid partitions and in this case it is not possible use physical partitions because raid0 doesn't dulicate(mirroring) data on physical partitions but use only part from each physical partition. It means GRUB hasn't chance to read from (for example) /dev/sda1 (/dev/sda1 is one of physical partition from raid0) content of /boot directory. But basic problem is that GRUB has not code for using software raids and it means it doesn't know to use software raid partitions.

comment#14:
==========

I am sorry I wrote it wrong. You can have /boot partition or if you haven't separate /boot partition you can have "/" and there /boot directory on md raid (but only raid1)

Next it is mandatory to write GRUB in to MBR other scenarios where is uses "write generic boot code" to MBR doesn't work as I wrote it before (comment#11). 

Yes your link is valid but for older openSUSE somebody change kernel caching and it doesn't allow to use other scenario of booting than write GRUB to MBR. y2-bootloader propose write GRUB to MBR during installation. Please doesn't ask me about details. It is kernel problem.

comment#15:
==========
 I see in bugzilla problem with mkinitrd and LVM maybe it is solved now. The bug will be reassign to maintainer of mkinitrd.

Finally:
========

I hope that now it is clear for everybody how GRUB works with md raids and LVM

Milan could you look at the problem please?

Jozef, i am aware that GRUB can't boot from /boot which is on RAID-0 thus this /boot was "separate" and NOT on this RAID stripe. It was simple primary partition. I created three partitions, one primary for /boot and two for RAID-0.

I'm sorry I'm out for two weeks.

Any news on that now?

I am fiddeling with M7 right now: /dev/sda1 /boot (ext3), /dev/sda2 type fd, /dev/sdb1 (not used), /dev/sdb2 type fd
Both fd's are a raid1. /dev/md0 is member of LVM vg system, lv /dev/system/root is /

Installation is not able to create a initrd.

Updating a working system from 11.1 to 11.2M7 with this configuration also renders the system unbootable.

Creating an initrd from rescue system with 'mkinitrd -f md' also give non-bootable system, as the md is not started, hence the LVM vg is not found and started.

Hello, my scenario:

1)
/boot on md0 RAID1, yes, it works!! I use this system for servel years now and if you say it is not working for grub, thats not true. Nonetheless I startet this years ago with lilo. It may be that it is not possible to install suche a soulution now, But for upgraded systems it is definitvly a blocker since it takes upgraded systems into an unbootable state.

2)
/ on lvm2 on md1

To say so: 
linux:/ # mkinitrd

Kernel image:   /boot/vmlinuz-2.6.31-rc9-7-default
Initrd image:   /boot/initrd-2.6.31-rc9-7-default
Root device:    /dev/vg00/root (mounted on / as xfs)
Device md1 not handled
Script /lib/mkinitrd/setup/72-block.sh failed!

Kernel image:   /boot/vmlinuz-2.6.31-rc9-7-trace
Initrd image:   /boot/initrd-2.6.31-rc9-7-trace
Root device:    /dev/vg00/root (mounted on / as xfs)
Device md1 not handled
Script /lib/mkinitrd/setup/72-block.sh failed!

I tried the workaround with rootdev I found in the mailinglist, but then the only thing that happens is:
linux:/ # mkinitrd -d /dev/md1

Kernel image:   /boot/vmlinuz-2.6.31-rc9-7-default
Initrd image:   /boot/initrd-2.6.31-rc9-7-default
node name not found
Could not find the filesystem type for root device /dev/md1

Currently available -d parameters are:
        Block devices   /dev/<device>
        NFS             <server>:<path>
        URL             <protocol>://<path>

Ok, hear is what I discoverd:
linux:/ # diff /lib/mkinitrd/setup/62-dm.sh /lib/mkinitrd/setup/62-lvm2.sh
linux:/ #

linux:/ # ls -l /lib/mkinitrd/setup/62-dm.sh /lib/mkinitrd/setup/62-lvm2.sh
lrwxrwxrwx 1 root root 22 Sep 25 16:53 /lib/mkinitrd/setup/62-dm.sh -> ../scripts/setup-dm.sh
lrwxrwxrwx 1 root root 24 Sep 25 16:53 /lib/mkinitrd/setup/62-lvm2.sh -> ../scripts/setup-lvm2.sh
linux:/ #


I certainly think that this is an error. ../scripts/setup-lvm2.sh is just a copy of ../scripts/setup-dm.sh. Therfor /md1 (in my case) is not handled as lvm2.

I also think that this is an error because of this:
http://www.novell.com/products/linuxpackages/opensuse/mkinitrd.html
848 Sep 19 14:28 /lib/mkinitrd/scripts/setup-dm.sh
1093 Sep 19 14:28 /lib/mkinitrd/scripts/setup-lvm2.sh

Sometimes between 10.3 and now someone seems to have copied  ../scripts/setup-dm.sh over ../scripts/setup-lvm2.sh.

The other side is this:
http://www.novell.com/products/linuxpackages/opensuse11.1/mkinitrd.html

There are no such scripts noticed.

Well, 
a) It is back again
b) It's leftover from old installations

If its back again, than it seems to be a package error
If it is a leftover, than it seems such also, because it was not deleted and is now interfering with the new package

I bootet into the livefilesystem opensuse 11.2 factory, mounted all needed filesystemsm copied /dev to /mnt/dev, mountet sys, devpts and proc and did a chroot. Thats my rescuebasis at the moment.

regards,
anniyka

Sorry, just saw that here is raid 0 discussion, nonetheless I think its all relateted ...

linux:/ # rpm -qf /lib/mkinitrd/scripts/setup-dm.sh
device-mapper-1.02.31-7.6.x86_64
linux:/ # rpm -qf /lib/mkinitrd/scripts/setup-lvm2.sh
lvm2-2.02.45-8.1.x86_64
linux:/ # rpm -qf /lib/mkinitrd/scripts/setup-dm.sh
device-mapper-1.02.31-7.6.x86_64

Well ...

Ok, I mad an initrd by putting all needed (I think so) and more modules into /etc/sysconfig/kernel:

INITRD_MODULES="processor thermal fan xfs raid456 async_xor async_memcpy async_tx raid6_pq xor sr_mod amd74xx pata_amd sata_nv ata_generic sg ide_core ide_gd_mod ide_cd_mod ide_pci_generic dm_mod edd raid1"

Than I put in another line in /lib/mkinitrd/scripts/setup-block.sh, I added 

            md*)
                echo dm_mod
                ;;

in function get_devmodule() ( easy to see where ;) )

Then I run mkinitrd:
linux:/ # mkinitrd -d /dev/vg00/root

Kernel image:   /boot/vmlinuz-2.6.31-rc9-7-default
Initrd image:   /boot/initrd-2.6.31-rc9-7-default
Root device:    /dev/vg00/root (mounted on / as xfs)
WARNING: no dependencies for kernel module 'usbcore' found.
WARNING: no dependencies for kernel module 'ohci_hcd' found.
WARNING: no dependencies for kernel module 'uhci-hcd' found.
WARNING: no dependencies for kernel module 'ehci_hcd' found.
WARNING: no dependencies for kernel module 'usbhid' found.
Kernel Modules: thermal_sys processor thermal fan exportfs xfs xor async_tx async_memcpy async_xor raid6_pq raid456 cdrom sr_mod ide-core amd74xx pata_amd sata_nv ata_generic sg ide-gd_mod ide-cd_mod ide-pci-generic dm-mod edd raid1 dm-snapshot
Features:       dm lvm2 block usb resume.userspace resume.kernel
Bootsplash:     openSUSE (1280x1024)
27854 blocks

Kernel image:   /boot/vmlinuz-2.6.31-rc9-7-trace
Initrd image:   /boot/initrd-2.6.31-rc9-7-trace
Root device:    /dev/vg00/root (mounted on / as xfs)
WARNING: no dependencies for kernel module 'usbcore' found.
WARNING: no dependencies for kernel module 'ohci_hcd' found.
WARNING: no dependencies for kernel module 'uhci-hcd' found.
WARNING: no dependencies for kernel module 'ehci_hcd' found.
WARNING: no dependencies for kernel module 'usbhid' found.
Kernel Modules: thermal_sys processor thermal fan exportfs xfs xor async_tx async_memcpy async_xor raid6_pq raid456 cdrom sr_mod ide-core amd74xx pata_amd sata_nv ata_generic sg ide-gd_mod ide-cd_mod ide-pci-generic dm-mod edd raid1 dm-snapshot
Features:       dm lvm2 block usb resume.userspace resume.kernel
Bootsplash:     openSUSE (1280x1024)
28206 blocks
mdadm: cannot open /dev/md/1: No such file or directory
2009-09-25 18:49:28 WARNING: GRUB::GrubDev2UnixDev: No partition found for /dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J10L405647 with 2.
2009-09-25 18:49:28 WARNING: GRUB::GrubDev2UnixDev: No partition found for /dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J10L405647 with 2.
2009-09-25 18:49:28 WARNING: GRUB::GrubDev2UnixDev: No partition found for /dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J10L405647 with 2.
2009-09-25 18:49:28 WARNING: GRUB::GrubDev2UnixDev: No partition found for /dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J10L405647 with 2.
2009-09-25 18:49:28 WARNING: GRUB::GrubDev2UnixDev: No partition found for /dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J10L405647 with 2.
linux:/ # ls /dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J10L405647 -l
lrwxrwxrwx 1 root root 9 Sep 25 18:48 /dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J10L405647 -> ../../sda
linux:/ # ls /dev/disk/by-id/../../sda
/dev/disk/by-id/../../sda
linux:/ # ls /dev/md*
/dev/md0   /dev/md11  /dev/md14  /dev/md17  /dev/md2   /dev/md22  /dev/md25  /dev/md28  /dev/md30  /dev/md5  /dev/md8
/dev/md1   /dev/md12  /dev/md15  /dev/md18  /dev/md20  /dev/md23  /dev/md26  /dev/md29  /dev/md31  /dev/md6  /dev/md9
/dev/md10  /dev/md13  /dev/md16  /dev/md19  /dev/md21  /dev/md24  /dev/md27  /dev/md3   /dev/md4   /dev/md7
linux:/ #

Nonetheless I tried to boot and run into the annoying fact that no lvm was started (so no rootdevice) .. I think this ist something that should be in /lib/mkinitrd/scripts/setup-lvm2.sh?

regards,
anniyka

linux:~/cpio # find | grep -e dm -e lvm -e md | grep -v amd
./lib/udev/collect_lvm
./lib/udev/rules.d/64-md-raid.rules
./lib/udev/rules.d/64-lvm2.rules
./lib/udev/idedma.sh
./lib/modules/2.6.31-rc9-7-default/kernel/drivers/md
./lib/modules/2.6.31-rc9-7-default/kernel/drivers/md/raid6_pq.ko
./lib/modules/2.6.31-rc9-7-default/kernel/drivers/md/raid456.ko
./lib/modules/2.6.31-rc9-7-default/kernel/drivers/md/raid1.ko
./lib/modules/2.6.31-rc9-7-default/kernel/drivers/md/dm-snapshot.ko
./lib/modules/2.6.31-rc9-7-default/kernel/drivers/md/dm-mod.ko
./boot/03-lvm2.sh
./boot/03-dm.sh
./config/dm.sh
./config/lvm2.sh
./sbin/lvm
./sbin/udevadm
./sbin/dmsetup
linux:~/cpio # diff ./config/dm.sh ./config/lvm2.sh
linux:~/cpio #

Shoulden`t there something to set up MDs or LVs? Well, if the scripts (notet in previous comment) are the same maybe thats the reason? ...

clearing queue

I am not really sure, why this bug has been close, allthough there is no solution in sight.
Can someone please clarify?

It's annoying ...

I copied /lib/mkinitrd/scripts/setup-lvm2.sh and /lib/mkinitrd/scripts/ boot-lvm2.sh from an 11.1 system to my 11.2M7 system and it fixed this problem.  You need to send the bug to the maintainer of the lvm2 rpm.

Tried this to but it didn't worked. It's always the same as in my last comment in Bug 505670

I'm having a similar problem, tried copying setup-lvm.sh/boot-lvm2.sh as outlined above - no joy!

my configuration is LVM2 on top of software raid1, /boot is /dev/md0 (raid1/ext3) and / is a lvm2 partition on top of /dev/md1(raid1/PV). 

I don't claim to understand the initrd process but tracing linuxrc it looks as if this may be a sequencing problem looking at the run_all.sh script on the generated initrd it executes

02-start
03-dm
03-rtc
03-storage
04-udev
........
51-md
61-lvm2

udev times out waiting for the root device but as yet the md and lvm2 initialization hasn't occurred so the root device is not visible. Also in the initial install of 11.2M7 failed during initrd creatation in 72-block.sh as md* isn't recognized as a block device.

I'm having a similar problem, tried copying setup-lvm.sh/boot-lvm2.sh as outlined above - no joy!

my configuration is LVM2 on top of software raid1, /boot is /dev/md0 (raid1/ext3) and / is a lvm2 partition on top of /dev/md1(raid1/PV). 

I don't claim to understand the initrd process but tracing linuxrc it looks as if this may be a sequencing problem looking at the run_all.sh script on the generated initrd it executes

02-start
03-dm
03-rtc
03-storage
04-udev
........
51-md
61-lvm2

udev times out waiting for the root device but as yet the md and lvm2 initialization hasn't occurred so the root device is not visible. Also in the initial install of 11.2M7 failed during initrd creatation in 72-block.sh as md* isn't recognized as a block device.

Also to answer Piotrek in comment #2, in my experience LVM on top of software raid (typically raid1) is a common install scenario.

I just installed M8 on LVM2 over software raid1, initrd problem still
encountered.
reports error creating initrd (2 distinct errors)

1: cp cannot stat /etc/scsi_id.config

2: Script /lib/mkinitrd/setup/72-block.sh failed
   Device md1 not handled

This is identical to the error I got trying to install M7

Hardware config is core I7 12Gb ram 2x500Gb disk as a mirrored pair. 

partition 1 /dev/md0 ext4 for /boot 200mb
partition 2 /dev/md1 remainder of disk as physical volume
            /dev/sys/dom0 10G LVM2 partition ext4 for /
            /dev/sys/dom0swap 1G for swap

fixed 1 by copying file from 11.1
fixed 2 or at least bypassed the problem by adding

md*)
   result = "dm-mod raid1"
   ;;

to the case statement in the get module subroutine

regenerated initrd, failed to boot waiting for /dev/sys/dom0 to appear

I believe the problem is LVM setup and udev run before md setup has occurred
hence the volume group is not accessible

I was able to get the system to boot using the following procedure

Unpack initrd to a directory
edit run_all.sh before the call to 03-lvm as follows: 

define (mknod) sda,sda1,sda2,sdb,sdb1,sdb2,md0,md1 manually
assemble raid devices md0/md1 manually
vgchange to bring the lvm devices online.

repack initrd & reboot.

I'm having the same issue as described. See the 2 errors as defined by Ray Sutton. 

I'm trying to install 11.2 M8 as a new install using autoYast. /boot on md1 and / on lvm. This is working fine for the same install with 11.1.

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

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

I can confirm the solution from Petri Asikainen from Bug 540522, but the lvm2
package from 11.2M8 differs greatly from the one from factory - which Petri
used and modified. The factory lvm2 seems to be more like the one from 11.1.

Can we have the lvm2 from factory with the trivial fix for 11.2?

(In reply to comment #40)
> I can confirm the solution from Petri Asikainen from Bug 540522, but the lvm2
> package from 11.2M8 differs greatly from the one from factory - which Petri
> used and modified. The factory lvm2 seems to be more like the one from 11.1.
> 
> Can we have the lvm2 from factory with the trivial fix for 11.2?

I've submitted the related patch to factory already.
pending for acceptance now

Ok, are these the packages?
Different errors now.

linux:/ # for i in mkinitrd lvm2; do rpm -q $i; rpm -qi $i | grep "Build Date"; done ; mkinitrd ; mkinitrd -A; ls -l /boot/init*
mkinitrd-2.5.10-3.5.x86_64
Release     : 3.5                           Build Date: Wed Oct  7 05:08:56 2009
lvm2-2.02.45-9.1.x86_64
Release     : 9.1                           Build Date: Sat Oct  3 06:42:58 2009

Kernel image:   /boot/vmlinuz-2.6.31-10-default
Initrd image:   /boot/initrd-2.6.31-10-default
Root device:    /dev/vg00/root (mounted on / as xfs)
mkdir: cannot create directory `etc/sysconfig': File exists
/lib/mkinitrd/setup/62-dm.sh: line 32: etc/sysconfig/kernel: Not a directory
mkdir: cannot create directory `/dev/shm/mkinitramfs.HpH1ov/mnt/etc/sysconfig': File exists
/lib/mkinitrd/setup/91-clock.sh: line 19: /dev/shm/mkinitramfs.HpH1ov/mnt/etc/sysconfig/clock: Not a directory
Script /lib/mkinitrd/setup/91-clock.sh failed!

Kernel image:   /boot/vmlinuz-2.6.31-10-trace
Initrd image:   /boot/initrd-2.6.31-10-trace
Root device:    /dev/vg00/root (mounted on / as xfs)
mkdir: cannot create directory `etc/sysconfig': File exists
/lib/mkinitrd/setup/62-dm.sh: line 32: etc/sysconfig/kernel: Not a directory
mkdir: cannot create directory `/dev/shm/mkinitramfs.HpH1ov/mnt/etc/sysconfig': File exists
/lib/mkinitrd/setup/91-clock.sh: line 19: /dev/shm/mkinitramfs.HpH1ov/mnt/etc/sysconfig/clock: Not a directory
Script /lib/mkinitrd/setup/91-clock.sh failed!

Kernel image:   /boot/vmlinuz-2.6.31-10-default
Initrd image:   /boot/initrd-2.6.31-10-default
Root device:    /dev/vg00/root (mounted on / as xfs)
mkdir: cannot create directory `etc/sysconfig': File exists
/lib/mkinitrd/setup/62-dm.sh: line 32: etc/sysconfig/kernel: Not a directory
mkdir: cannot create directory `/dev/shm/mkinitramfs.EvM2xq/mnt/etc/sysconfig': File exists
/lib/mkinitrd/setup/91-clock.sh: line 19: /dev/shm/mkinitramfs.EvM2xq/mnt/etc/sysconfig/clock: Not a directory
Script /lib/mkinitrd/setup/91-clock.sh failed!

Kernel image:   /boot/vmlinuz-2.6.31-10-trace
Initrd image:   /boot/initrd-2.6.31-10-trace
Root device:    /dev/vg00/root (mounted on / as xfs)
mkdir: cannot create directory `etc/sysconfig': File exists
/lib/mkinitrd/setup/62-dm.sh: line 32: etc/sysconfig/kernel: Not a directory
mkdir: cannot create directory `/dev/shm/mkinitramfs.EvM2xq/mnt/etc/sysconfig': File exists
/lib/mkinitrd/setup/91-clock.sh: line 19: /dev/shm/mkinitramfs.EvM2xq/mnt/etc/sysconfig/clock: Not a directory
Script /lib/mkinitrd/setup/91-clock.sh failed!
lrwxrwxrwx 1 root root 24 Oct 13 15:20 /boot/initrd -> initrd-2.6.31-10-default

mkinitrd -A is not working anymore.

linux:/ # rpm -qf `find /lib/mkinitrd/` | sort | uniq | grep -v "not owned by any package"
bootsplash-3.3-146.112.x86_64
cifs-mount-3.4.1-1.7.x86_64
cryptsetup-1.0.7-9.1.x86_64
device-mapper-1.02.31-9.1.x86_64
dmraid-1.0.0.rc15-8.1.x86_64
kpartx-0.4.8-43.2.x86_64
lvm2-2.02.45-9.1.x86_64
mdadm-3.0.2-1.1.x86_64
mkinitrd-2.5.10-3.5.x86_64
multipath-tools-0.4.8-43.2.x86_64
nfs-client-1.1.3-20.1.x86_64
splashy-0.3.13-2.23.x86_64
suspend-0.80.20081103-2.17.x86_64
sysvinit-2.86-214.1.x86_64

No modified scripts:
linux:/ # touch /lib/mkinitrd/setup/test~
linux:/ # rpm -qf `find /lib/mkinitrd/ | grep "~"` | sort | uniq
file /lib/mkinitrd/setup/test~ is not owned by any package

Well:

linux:/lib/mkinitrd/setup # for i in  01-prepare.sh 01-splashy.sh 02-start.sh 03-udev.sh 03-usb.sh 11-storage.sh  21-luks.sh 31-lvm2.sh ; do grep -H sysconfig $i; done | grep -v "#"
02-start.sh:    . $root_dir/etc/sysconfig/kernel
02-start.sh:    . $root_dir/etc/sysconfig/kernel
31-lvm2.sh:     cp -a /etc/sysconfig/lvm $tmp_mnt/etc/sysconfig

Without a directory sysconfig ...

(In reply to comment #43)
> Well:
> 
> linux:/lib/mkinitrd/setup # for i in  01-prepare.sh 01-splashy.sh 02-start.sh
> 03-udev.sh 03-usb.sh 11-storage.sh  21-luks.sh 31-lvm2.sh ; do grep -H
> sysconfig $i; done | grep -v "#"
> 02-start.sh:    . $root_dir/etc/sysconfig/kernel
> 02-start.sh:    . $root_dir/etc/sysconfig/kernel
> 31-lvm2.sh:     cp -a /etc/sysconfig/lvm $tmp_mnt/etc/sysconfig
> 
> Without a directory sysconfig ...

It's not the updated package yet.
It has be accepted 12 hours ago, but don't know how long it takes to hit the downloadable area.

Thanks for testing.

Well, you can check this patch if you could still need it. With this I could build my initrd:


linux:/lib/mkinitrd/scripts # diff -cB setup-prepare.sh setup-prepare.sh~
*** setup-prepare.sh    Tue Oct 13 16:51:59 2009
--- setup-prepare.sh~   Tue Aug 11 11:59:50 2009
***************
*** 137,143 ****
  cp $INITRD_PATH/bin/linuxrc $linuxrc
  mkdir "$tmp_mnt/boot"

! mkdir -p $tmp_mnt/{sbin,bin,etc,dev,proc,sys,root,config,etc/sysconfig}

  mkdir -p -m 4777 $tmp_mnt/tmp

--- 137,143 ----
  cp $INITRD_PATH/bin/linuxrc $linuxrc
  mkdir "$tmp_mnt/boot"

! mkdir -p $tmp_mnt/{sbin,bin,etc,dev,proc,sys,root,config}

  mkdir -p -m 4777 $tmp_mnt/tmp

It booted :) The packages I mentioned above and the patch I send did it.

Now I do have some other problems ;)

I just did a test installation of Build327 with LVM and mkinitrd works fine. I hope it's ok to close the bug

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

I hope you do NOT.   I had no problems with M8, did a factory zyp dup to what appears to be labled RC1 and it would not boot...Fortunately, Grub had saved M8 and I could get it to boot from there.

It was waiting on MD0.

My system has a separate /boot on a separate partition,

/ is on a Software raid MD0 which is 20G and excludes /home and a couple of other directories like /srv

/home and /srv are on a LVM across 4 drives grabbing bits and pieces of otherwise unused space totalling about 700G.   This works, works well in M8, with NO changes other than the upgrade mentioned, RC1 fails during boot while waiting for MD0, falls back to MD0 and waits until I reset the machine.   Remember, this is a separate PRIMARY partion for the /boot, 2 identical drives with primary partitions dedicated to a RAID1 MD0 and the rest of the drive partitions are allocated to the LVM for home, etc.   This worked fine in M5 on to 8.   Prior to that, I didn't use RAID or LVM as I wasn't testing that aspect yet on that machine.

But is your / on an LVM which sits on top of a RAID stripe?? Or do you have ONLY RAID stripe set and / on it?

we need more data than what Richard's setup. Is the new package working for everyone else? (please remember to call mkinitrd explicitly if you do zypper dup).

The Packages I mentiond in Comment #42

-----------
mkinitrd-2.5.10-3.5.x86_64
Release     : 3.5                           Build Date: Wed Oct  7 05:08:56
2009
lvm2-2.02.45-9.1.x86_64
Release     : 9.1                           Build Date: Sat Oct  3 06:42:58
2009
-----------

Together with my patch in Comment #45 did it for me, but not your packages alone! In the meaning of your question: No, it worked not. If there is a newer package available now I will try it this evening.

What, if any additional information would you need from me?   I believe this bug came closest to describing the problem I experienced, ie, it is not about LVM,or RAID specifically, it is about mkinitrd when either or both of those are used to store all or part of the root of the file system.   In my case, / is on a RAID 1, but /boot is on a normal primary partition, not part of either a LVM or a RAId, but directories needed for building a new module or load image certainly reside on (in my case) a RAID or LVM or possibly both in my case because /usr is on the LVM for instance, however, at the time things are being updated or being built, this tree is (or should be) fully available as the system hasn't been rebooted yet as it is still being updated by the update scripts and fwiw, the failure also fails when run from YAST as opposed to zypper dup.   Previous updates have not failed using YAST (update all with newer) (only factory enabled) (from M8 to RC1) and with zypper dup as an effort to repair the failure as a last resort with no positive effect.

I hope this does not become a pissing match about technicalities about raid version or lvm vs raid, It is a failure of mkinitrd when using one or both of those in some or any combination that causes a failure that needs to be identified and I will do my best to help identify the cause if you remember, I am NOT a technical person (anymore), I am a stroke victim that USED to be a systems engineer/programmer that hasn't programmed in 'modern' low level languages in many years.

I would like to add that I created a VM running under VirtualBox (SUN) without a LVM or RAID and the update from M8 to RC1 went perfectly and even fixed a problem with VLC that had been plaguing all instances of 11.2 factory that I had previously tried much to my great pleasure, so the RAID/LVM/mkinitrd problem is (to me) a major problem but is isolated to those that use RAID/LVM as part of their container holding their root partition, or so it would seem.   This probably is because of mkinitrd not being able to get at everything it needs when it needs it?

:-/ ...

Did zypper dup just a minute ago (well, it finished a minute ago):

anniys:~ # mkinitrd

Kernel image:   /boot/vmlinuz-2.6.31.3-1-default
Initrd image:   /boot/initrd-2.6.31.3-1-default
Root device:    /dev/vg00/root (mounted on / as xfs)
Resume device:  /dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J10L405647-part1 (/dev/hda1)
setup-md.sh: md1 found multiple times
Kernel Modules: thermal_sys processor thermal fan exportfs xfs xor async_tx async_memcpy async_xor raid6_pq raid456 cdrom sr_mod ide-core amd74xx pata_amd sata_nv ata_generic sg ide-gd_mod ide-cd_mod ide-pci-generic dm-mod edd raid1 dm-snapshot pata_acpi raid0 linear
Features:       dm block usb md lvm2 resume.userspace resume.kernel
Bootsplash:     openSUSE (1280x1024)
30689 blocks

Kernel image:   /boot/vmlinuz-2.6.31.3-1-trace
Initrd image:   /boot/initrd-2.6.31.3-1-trace
Root device:    /dev/vg00/root (mounted on / as xfs)
Resume device:  /dev/disk/by-id/ata-SAMSUNG_SP2014N_S088J10L405647-part1 (/dev/hda1)
setup-md.sh: md1 found multiple times
Kernel Modules: thermal_sys processor thermal fan exportfs xfs xor async_tx async_memcpy async_xor raid6_pq raid456 cdrom sr_mod ide-core amd74xx pata_amd sata_nv ata_generic sg ide-gd_mod ide-cd_mod ide-pci-generic dm-mod edd raid1 dm-snapshot pata_acpi raid0 linear
Features:       dm block usb md lvm2 resume.userspace resume.kernel
Bootsplash:     openSUSE (1280x1024)
31048 blocks


What the heck is this:
setup-md.sh: md1 found multiple times

At least it build the initrd, I will try if it boots up ...

Created attachment 322553 [details]
Directory listing of MC listings of /boot and /grub showing that initrd and menu.lst were created after M8 was updated to RC1

Despite the apparant correctness of the directory, once reboot occurred, infinite waiting on MD to appear occurred and answering either yes or no to shall I default to /dev/mdX results in infinite wait.   Entering a CTRL-C will drop to a $ shell and cd /var/log shows NO ENTRIES of any kind, eg, no files, no messages, no logs.  Same for any other directories I log to.   There are 3 directories in /proc, /dev etc mounted.   If I reboot to the M8 version, It boots with no problem normally and with no reported errors, of course, with a different kernel flavor, but has no problems with the new versions of programs that end up running.

Suppose the volume group of the root volume is called 'system'. What should be the output of the following command?
# vgs --noheadings --options pv_name system

For lvm on top of raid it's /dev/md0 on 11.1 and /dev/dm-0 on 11.2 AFAICT.

Forget what I said, I can't reproduce without LUKS involved. Even a config with /boot on raid works. So the bug here seems to be fixed indeed. The message 'md1 found multiple times' is harmless.

Due to lack of better knowledge my advice for anyone still having problems would be to post a screenshot of the graph displayed by the yast2 partitioner. Also uncomment the line
echo "[$curscript] $blockdev"
around line 454 in /sbin/mkinitrd before posting the output of mkinitrd. That helps to understand what devices are considered by mkinitrd.

Created attachment 322652 [details]
disk layout with root on lvm on raid and boot on raid works with Build0334

anniys:~ # vgs --noheadings --options pv_name vg00
  /dev/md1

And yes, it boots now.

Mostly works for me :-)

Configuration /boot on  /dev/md0 (raid1/ext4)
              /     on  /dev/sys/dom0 (ext4 on LVM2 on raid1)

RC1 (Build 334 X86_64) installed no problem, reboot fine after install to desktop mode, rebooting to dom0 under xen failed on switching to runlevel 5 (system locked)

Regenerated initrd as a test, reported the missing scsi_config file but this didn't prevent initrd being recreated.

On reboot desktop mode worked fine but xen-dom0 crapped out switching to run level 5, this time I was able to recover to runlevel 3.

The initrd problem is resolved for me, I just need to go beat up (gently of course) the x-windows or xen guys (probably the latter).

Thanks to everybody who had time to work this problem!

Created attachment 322777 [details]
Partition Layout of test machine

Test machine layout showing /boot as physical partition, root on MD1 and most of the rest of the machine on an LVM

My comment associated with attachment of comment 63 didn't seem to take:  I downloaded the ISO for RC1 and created the DVD and installed it as an update successfully on the test machine using the configuration  as shown in the above attachment.   It installed successfully with the exception that GRUB did not update properly.   It left the old RC1, the non-bootable version marked as the default even though it added the new kernel into the menu but did not mark it as the default and when it rebooted, of course, it went into the  old waiting game for MD1, which of course never occured.   When I rebooted manually, I noticed the menu was not 'right' in that the default was the 2nd set of RC1 choices, so I manually selected the top set of RC1 default flavor and it booted.   I then went into grub and selected that first (top) menu item as default, deleted the bottom two items from the menu (the old pae flavor) and then rebooted just to be sure it would do so without intervention from a power off reboot, and it did.   I would say that aside from grub messing up, the initrd problem with LVM and RAID is fixed and this bug from my perspective at least could be marked as closed.

Richard

This is with 11.2 Milestone 8.
Have tried fresh installs twice with same result. 

With 2 identical 320 GB hard drives in HP dv9000 laptop with LVM on top of RAID1 with /dev/system/home running LUKS.

/dev/sda1 = FAT 1GB
/dev/sda2 = NTFS 100MB (Windows 7 RTM auto-created for "system" requirements)
/dev/sda3 = NTFS 73.24GB (Windows 7 RTM)
/dev/sda4 = extended 223.74GB
/dev/sda5 = ext2 1GB /boot
/dev/sda6 = swap 1.25GB
/dev/sda7 = raid part 1 of md0 221.48GB


/dev/sdb1 = FAT 1GB
/dev/sdb2 = NTFS 100MB (Windows 7 RTM)
/dev/sdb3 = NTFS 73.24GB (Windows 7 RTM)
/dev/sdb4 = extended 223.74GB
/dev/sdb5 = ext2 1GB /boot2
/dev/sdb6 = swap 1.25GB
/dev/sdab7 = raid part 2 of md0 221.48GB

lvm = volume: system =   GB
/dev/system/root = ext4   GB
/dev/system/home = ext3 with crypto  GB


After installation nearly complete, final line of error popup is:

"script /lib/mkinitrd/setup/72-block.sh failed"

Other than the more complex partitioning with LVM on top of RAID1, the installation is default software automatic configuration (including laptop package pattern already selected by default), with KDE desktop.

I see that 11.2 RC1 is now out. I am downloading that, and will see how that behaves with the same setup on the same system.

I have now tested it under RC1, same exact setup, and it worked just fine. LUKS encrypted /home partition via LVM on top of RAID1, all working fine now, when through install fine. At least from what I can tell on my end, all fixed in RC1. So can reclose?

So closing it again as reports indicate that bug is fixed in RC1.

Thank you all for participating in testing and resolving this issue!

And appears to remain fixed in RC2 (just tested it). ;-)