Description of problem: Here is the partitionning scheme I have: /boot 256 MB raid 0: 2x 60 GB LVM on raid / on logical volume, btrfs filesystem When I boot with the dracut initrd I don't get my / mounted. Instead, after a while plymouth disappears and I get the following message, repeated all over the screen: modprobe: FATAL: Error inserting btrfs (/lib/modules/3.1.0-desktop-0.rc10.1.mga2/kernel/fs/btrfs/btrfs.ko.gz) Unknown symbol in module, or unknown parameter (see dmesg) When I run dmesg|less: Everything is fine until my logical volumes are active and then I get this message repeated over and over: dracut: Checking, if btrfs device complete and in the middle of this flood I get this: scanning for all btrfs devices failed to open /dev/btrfs_control skipping device registration scanning devices md0 for LVM volume groups Reading all physical volumes. This may take a while Found volume group "kaze" using metadata type lvm2 Partial mode. Incomplete volumes will be processed 5 logical volume(s) in volume group "kaze" now active Autoassembling MDRaid. and in the end I get: dracut: Warning: no root device "block:/dev/kaze/cauldron" found So, to me the problem is neither raid nor LVM but btrfs Version-Release number of selected component (if applicable): dracut: dracut-013-2.mga2 btrfsprogs: btrfs-progs-0.19-1.20111027.1.mga2 kernel: kernel-desktop-3.1.0-0.rc10.1.mga2-1-1.mga2 and kernel-desktop-3.1.0-1.mga2-1-1.mga2 How reproducible: always Steps to Reproduce: 1. install a cauldron system (via boot.iso or all.img) with /boot (ext2) and / (btrfs) 2. install dracut 3. move your old initrd: mv /boot/initrd-3.1.0-desktop-1.mga2.img /boot/initrd-old.img 4. run the following command: /sbin/installkernel -N 3.1.0-desktop-1.mga2 5. reboot 6. it fails to mount /, probably because of this /dev/btrfs_control file missing
Created attachment 1020 [details] lsinitrd /boot/initrd-3.1.0-desktop-0.rc10.1.mga2.img generated by dracut
Bug assigned to the package maintainer.
Assignee: bugsquad => mageia
Created attachment 1021 [details] content of init here is what I have in the init contained in my initrd
Created attachment 1022 [details] content of old init (
in case it might be useful, my version/release of udev is 173-3.mga2
Created attachment 1023 [details] content of /etc/dracut.conf
some additional info, in case it might be interesting. I tried to load the btrfs module in the dracut shell, by issuing a modprobe btrfs. Seems like the module canât be loaded, but I also get an error with the zlib_deflate module, though I can load this module individually. Any idea ?
I've just updated dracut to latest git master. Can you take it for a spin?
Keywords: (none) => NEEDINFO, Triaged
I also found a bug that could be related to incorrect root device calculations when the *any* btrfs partitions are found. Please test the 013-7.mga2 version of the package just submitted and let me know if things behave better now.
I just tested it and it still occurs (kernel 3.1.4 boots fine, 3.1.6 does not)
CC: (none) => Kicer86
Can you give some debug output from then it does not boot? You should be dumped to a shell where you can issue various commands and inspect previous command output. One of the commands is failing (presumably one related to fsck in some capacity. Please give us some info on this!
it's the same issue as Rémy's: module btrfs could not be loaded because zlib_deflate cannot be loaded
OK, so getting somewhere... As described here: https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/715835 the problem is the lack of a hard dep on a crc32 implementation (btrfs itself just requires the libcrc32 module). So, it's trivial to fix dracut to ensure that crc32c is included (add it to the instmods line in 90btrfs/module-setup.sh) However when doing this, it still fails to boot when using a root=UUID=nnn syntax. I think dracut is someone extracting certain things from either blkid or udev incorrectly. If you use root=/dev/sda1 etc. it'll work fine. Anyway I'll try and work on a full fix shortly.
Status: NEW => ASSIGNED
Hmm, actually it's the resume= bit that seems to break things (which I think is covered in another bug (or at least it was on my mental list), and deleting the resume= bits from the kernel command line allows it to boot fine even with a UUID= type syntax. Job's a good 'un.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
works indeed, thx