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): 017-16.mga2 How reproducible: always 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
Hardware: i586 => All
https://bugs.mageia.org/show_bug.cgi?id=5659 https://bugs.mageia.org/show_bug.cgi?id=3214 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)
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. Regards, Jaromir.
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.
*** This bug has been marked as a duplicate of bug 5659 ***
Status: NEW => RESOLVEDResolution: (none) => DUPLICATE
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
Hi Colin. Ok ... I'll try to give you a detailed reproduction scenario ....
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
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?
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).
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.
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.
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).
Why can't we fix the ISOs? We just need to create new ones (suffixed with "rev2" or something).
(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?