Using nonfree boot.iso to install Mga6. Install is done MBR. Partitions are /, swap, /usr /home All partitions, exept swap, are btrfs formatted. The installation was trouble free bootloader also installed with out error or complaint. On re-boot the normal grub2 menu appears. After selecting menu entry error appears in the centered black box: error: sparse file not found Press any key to continue Press enter and wait a while as boot entries scroll by. After about 5 min, maybe even longer, I did not watch it full time. It ends at a dracut prompt. Just prior to the prompt there is an entry that UUID <Foo>187b1a1 does not exist. Using the same drive / ext4, /usr, and /home btrfs, the system boots to a working desktop. Again using the same drive having only / and /home both btrfs Still get the 'error: sparse file not found' but then the boot continues to a working desktop.
If this is an installer bug, then /root/drakx/report.bug.xz is needed. Please be as kind as to attach it ;-)
Keywords: (none) => NEEDINFOCC: (none) => marja11Assignee: bugsquad => thierry.vignaudSummary: Boot fails if / and /usr are on separate btrfs partitions => Boot fails if / and /usr are on separate btrfs partitions (error: sparse file not found)
and /boot/grub2/grub.cfg, too :-)
CC: (none) => zen25000
grub.cfg is already in report.bug.xz...
(The error also appears when boot doesn't fail, so removing it from the summary)
Summary: Boot fails if / and /usr are on separate btrfs partitions (error: sparse file not found) => Boot fails if / and /usr are on separate btrfs partitions
(In reply to Marja van Waes from comment #4) > (The error also appears when boot doesn't fail, so removing it from the > summary) Yes, that message may be ignored - it's not an issue.
I do not have any of the requested reports available. There have been at least 4 other test installs done on that drive since that failed boot. The original problem with the boot failing was sent to the dev list by Thomas Spuhler. I simply tested his issue and then made the bug report. On my latest test install to that drive all partitions were created and formatted using gparted. / /usr swap /home all were formatted as primary and btrfs. This install had no problem re-booting to a working desktop. I'll try the install again this weekend, creating the partitions during the install and get reports to attach in case it still fails on re-boot.
Created attachment 7967 [details] bug report from non-bootable install I ran the install again on the working bootable drive partitioned by gparted but on this occasion I allowed the installer to format both / sdb1, and /usr sdb2. On boot after the install the boot again only makes it to a dracut prompt. I think I now know what is causing this but have no idea on a fix. When running the installer probe finds /dev/sdb1 UUID=A and /dev/sdb2 UUID=B. When the partition are formatted they are changed: /dev/sdb1 UUID=aa and /dev/sdb2 UUID=bb. There is some important file or something that does get updated with the /dev/sdb2 UUID change. Boot will now fail as it searches for UUID=B which no longer exist.
OK it looks like there's a bug when using "Use existing partitions" and not checking in one of the existing partitions
Status: NEW => ASSIGNEDSummary: Boot fails if / and /usr are on separate btrfs partitions => Boot fails due to extra entry in /etc/fstab when choosing "Use existing partitions" and not checking in one of the partsSource RPM: drakx-installer-stage2 => drakx-installer-stage2, grub2
Source RPM: drakx-installer-stage2, grub2 => drakx-installer-stage2
Did some more test installs this morning. All test were done using nonfree boot.is from Jun 11 5:42:00am Stage2 was version 17.36 and using existing partitions. *Test 1 Allowed installer to format / and /usr After installation compelted 1st boot still get spurious UUID error and boot fails. *Test 2 Allowed installer to format / and /usr Here I re-booted and re-started the installation Set mount points for / /usr /home DID NOT format any partition and completed the install. On 1st boot system boots to a working desktop.
Can you still reproduce as of drakx 17.41?
Yes it's still happens. With btrfs / and /usr on mbr install to gpt disk a UUID is missing during boot. I will test again tomorrow using msdos disk and also test using EFI install and see how they perform when / and /usr already exist. Also need to see if it occurs with all fs types are only btrfs.
Tried the MBR install on gpt drive with / and /usr both ext4. There was no issue during the install and after there was No issue booting to a working desktop. At this point it is my opinion the this "bug" will only occur if partitions are btrfs. If there is a listing, as such, I would have no problem if the this were set as "Later".
(In reply to Charles Edwards from comment #7) The thing is for now we cannot keep the UUID when re-formating btrfs: - btrfstune needs to answer "y" - mkfs.btrfs fails with non unique UUID (as it detected the fs we're formatting has the same...)
CC: (none) => pterjan, tmb
Though I've a patch for that
commit 3d24a1eb51fd57b0025d997002202cf6b3ce5678 Author: Thierry Vignaud <thierry.vignaud@...> Date: Fri Jun 24 13:00:14 2016 +0200 keep UUID when formating btrfs (mga#18673) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=3d24a1eb51fd57b0025d997002202cf6b3ce5678
Can you confirm its fixed with drakx v17.45 when it lands on your favorite mirror? You can do a net install using install/images/boot-nonfree.iso You can check stage2 is up to date on your mirror by checking install/stage2/VERSION eg: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/install/images/boot-nonfree.iso http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/install/stage2/VERSION
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
I can confirm that the issue is now resolved. / and /usr btrfs and install to existing partition. Resulting system boots to a working desktop.