Bug 6692 - Dracut generates useless initrd when the root partition is btrfs
Summary: Dracut generates useless initrd when the root partition is btrfs
Status: RESOLVED DUPLICATE of bug 5659
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 2
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
Depends on:
Reported: 2012-07-04 21:29 CEST by Jaromír Cápík
Modified: 2012-07-16 13:02 CEST (History)
1 user (show)

See Also:
Source RPM: dracut-017-16.mga2.src.rpm
Status comment:


Description Jaromír Cápík 2012-07-04 21:29:00 CEST
Description of problem:
I just finished a migration of my Mandriva 2010.2 system to Mageia 2. The system doesn't boot now (still dropping me to the debug shell). I tried the previous kernel/initrd pair, but got just a "kernel too old" message. I tried to install Mageia2 to a second free btrfs partition and got the same result even when the installation was successful. I consider this a regression, because the previous versions of mkinitrd (non-dracut) had no problems with rootfs formated as btrfs.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start the installer
2. Create separate /boot partition formatted as ext4
3. Create / partition formated as btrfs
4. Install the system
5. Try to boot
Jaromír Cápík 2012-07-04 21:38:28 CEST

Hardware: i586 => All

Comment 1 Manuel Hiebel 2012-07-09 19:34:48 CEST

should be fixed, 
Have you more info ? 

(with removing the 'splash quiet' on the grub for the launch or in the file /root/drakx/ddebug.log for the install/upgrade)
Comment 2 Jaromír Cápík 2012-07-11 18:41:35 CEST
Hi Manuel.

The issue is pretty well reproducible and installation in any virtual machine takes just few minutes. It would be easier to reproduce it locally and collect any debug info than ask me for any additional info. Anyway, I'm willing to do that even if I don't consider it the best approach.
Please, let me know.

Comment 3 Jaromír Cápík 2012-07-11 18:47:37 CEST
And ... I've read the previous bugs and the issue looks more like #5659. Sebastian Blaziak states, that the M2RC network works for him. I did a network install from the latest 64-bit boot.iso and the issue is still present for me.
Comment 4 Manuel Hiebel 2012-07-12 19:25:42 CEST

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

Resolution: (none) => DUPLICATE

Comment 5 Colin Guthrie 2012-07-12 21:03:15 CEST
I've done several network installs on btrfs roots and never had this problem, tho' I do accept others did... it's a bit of a Heisenbug :s

Can you give exact steps to reproduce and I'll try again. This would include the VM system used (I prefer virtualbox or kvm) it's configuration and the exact steps (which boot iso, what options selected etc) taken in the installer.

Many thanks.

CC: (none) => mageia

Comment 6 Jaromír Cápík 2012-07-14 11:46:04 CEST
Hi Colin.

Ok ... I'll try to give you a detailed reproduction scenario ....
Comment 7 Jaromír Cápík 2012-07-14 13:51:48 CEST
It seems to be really pretty reproducible with any configuration I tried, but here are the exact settings and detailed steps:

1.) Download Mageia 2 x86_64 boot ISO
wget ftp://mageia.mirror.dkm.cz/pub/mageia/distrib/2/x86_64/install/images/boot.iso
[ MD5SUM = 7355af37254e07186ef2104b1cf89d0d ]

2.) Prepare the following virtual machine
VirtualBox OSE 4.1.12_OSE r77245
Operating System : Linux
Version : Mandriva (64 bit)
Base Memory: 1897 MB
Chipset : PIIX3
Extended Features : Enable IO APIC
Processor(s) : 1
Hardware Virtualization : Enable VT-x/AMD-V, Enable Nested Paging
Storage : IDE Controller (Type PIIX4, Use host I/O cache)
-HDD : test.vdi (Virtual size 2.90 GB, Dynamically allocated storage)
-CD : boot.iso

3.) Start the installer

4.) Installation method : HTTP server

5.) Connection type : DHCP

6.) Hostname : test

7.) Domain : local

8.) Leave HTTP proxy host and port empty

9.) Medium : Mageia 2

10.) Mirror : ftp.fi.muni.cz

11.) .... confirm HTTP server and directory .....

12.) Language : English (American)

13.) Accept the license

14.) Keyboard : US keyboard

15.) Partitioning : Custom disk partitioning (expert mode)
sda1 - 320MB, ext4  [ /boot ]
sda5 - 288MB, swap [ swap ]
sda6 - 2.2GB, btrfs [ / ]

16.) Package group selection : Console Tools, Documentation, Configuration (573 / 2111 MB)

17.) Root password : test

18.) Login name : test

19.) Password : test

20.) Bootloader : GRUB with text menu

21.) Finish the installation and reboot


Result : 
mount: unknown filesystem type 'btrfs'
umount: /sysroot: not mounted

dracut Warning: Can't mount root filesystem

Dropping to debug shell.

sh: 0: can't access tty; job control turned off
Comment 8 Colin Guthrie 2012-07-14 15:11:49 CEST
OK, I was able to reproduce.

The cause is clear, but I'm not sure how this is a problem.

Basically the initrd is generated when the kernel is installed. Sadly the kernel is installed prior to btrfs-progs. As this latter package is needed to make btrfs work in the initrd (several of the binaries in it are copied to the initird), it fails.

What is odd however, is that the initrd should be regenerated later during the bootloader stage. In my install, this stage seemed to not even be presented (it just flashed very quickly on screen but didn't actually do any initrd generation) which is very odd (your instructions clearly show it as being part of the process, but I'm guessing the "Preparing bootloader" bit just flashed by for you too?).

Anyway, before rebooting, I can flip to tty2, "chroot /mnt /bin/bash" and run "dracut -f /boot/initrd-3.3.6-desktop-2.mga2.img 3.3.6-desktop-2.mga2", exit. And then flip back to tty7 and click the "Reboot" button and all boots fine.

So the main question here is: why isn't the initrd regenerated at the end of the process?
Comment 9 Jaromír Cápík 2012-07-14 16:58:46 CEST
Hmmm .... maybe we're mixing two issues together. In my case even manual initrd creation doesn't work (but probably only on that laptop upgraded from Mandriva 2010).
Comment 10 Colin Guthrie 2012-07-14 17:52:34 CEST
I'm pretty certain this is the issue you're experiencing during install. As I said I could reproduce it quite easily (I saved snapshots during install process so I could replay it and I did just that several times)

Manual initrd creation works fine when generated from the correct environment, but you have to keep in mind that you have to generate the initrd carefully and from a "good" environment such as that provided by the installer before it reboots.

We now use dracut for initrd generation and it makes extensive use of udev metadata. This means that when you chroot into a system you have to ensure that relevant folders are bind mounted (namely /run/udev and /run/initrd) into the chroot such that dracut can access the udev metadata.

So I'm sure that if you do the same as myself above during the install and regenerate the initrd before rebooting, that you'll get a working boot.

When upgrading (via urpmi) then the initrd is created in a "non-hostonly" mode whereby it includes a *lot* more stuff that is typically not useful and things are somewhat different, but should still work also.

It is also still possible to boot via a different system, mount all the drives, chroot and then generate an initrd but you will have to ensure that proper udev metadata is available when doing so as mentioned above.

So again, the configuration does work in principle, it's just our installer (and maybe the upgrade) that messes up.
Comment 11 Colin Guthrie 2012-07-14 20:57:30 CEST
I can also confirm that simply switching to tty2 while at the user password screen and doing: "rm -f /mnt/boot/initrd-3*.img" will allow for the bootloader to be regenerated properly as part of the installer process.
Comment 12 Colin Guthrie 2012-07-15 01:12:03 CEST
OK, I've found the problem. It's actually in the mageia-theme-Default package. It's post install scripts incorrectly generate an initrd when it is installed (which happens to be before then btrfs-progs package). This then generates an incomplete initrd and it is not subsequently regenerated later.

Fingers crossed we will be able to issue an update soon that will prevent this happening (assuming online media is used - sadly we cannot fix the install ISOs).
Comment 13 Jaromír Cápík 2012-07-16 11:34:48 CEST
Why can't we fix the ISOs? We just need to create new ones (suffixed with "rev2" or something).
Comment 14 Colin Guthrie 2012-07-16 13:02:30 CEST
(In reply to comment #13)
> Why can't we fix the ISOs? We just need to create new ones (suffixed with
> "rev2" or something).

Well that's an awful lot of QA and effort to go to. We have already done it once for a license problem, but I'm not sure there is going to be much in the way of motivation for people to spend a couple days doing tests for just this one issue.

btrfs is only really of interest to a select few users (and in actually fact it's still got major issues relating to startup speed that make it totally impractical even for seasoned hackers - see various posts by e.g. Auke Kok relating to his issues).

While I will mention it, I suspect the effort required is simply too high to regenerate ISOs.

Can you confirm that the simple "rm" step outlined in comment 11 works for you too?

Note You need to log in before you can comment on or make changes to this bug.