Description of problem: This already happened multiple times. A user installed Mageia 4 from a flash drive, and afterwards he needed to figure out why it doesn't boot properly, only drops to recovery console. It only booted when the flash drive was plugged. Turned out that the installer added the install media to /etc/fstab: # Entry for /dev/sdb1 : UUID=92F7-1AA6 /mnt/hd vfat umask=000,iocharset=utf8 0 0 Cannot think of any commonly used scenario where adding normal installation media to /etc/fstab would not be harmful. The other bug in here is that installer never uses nofail option for anything it adds to fstab which is not critical to Mageia - as for NTFS partitions. Why should Mageia boot fail when some windows partition cannot be mounted or when their UUID changed because they have been formatted? No impact on Mageia. Same for this bug: Even if it's useless to add an entry for installation media, would the installer have used nofail, the entry would still be wrong altogether bug the boot would have succeeded. Please fix. Reproducible: Steps to Reproduce:
Created attachment 4948 [details] /root/drakx/report.bug.xz from the affected system /root/drakx/report.bug.xz from the affected system
CC: (none) => doktor5000
Assignee: bugsquad => thierry.vignaud
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=4042
FWIW, here are some of the occurences I've seen so far: https://forums.mageia.org/en/viewtopic.php?f=15&t=4810 https://forums.mageia.org/de/viewtopic.php?f=7&t=1976 https://forums.mageia.org/en/viewtopic.php?f=7&t=6920 This prevents users from testing and obviously using Mageia, marking as release_blocker for 5.
Target Milestone: --- => Mageia 5Priority: Normal => release_blockerVersion: 4 => CauldronSeverity: major => critical
Also FWIW, this seems to be an issue that has been around since MGA2 in various incarnations. Looks like the following three bugs are related to this https://bugs.mageia.org/show_bug.cgi?id=9317 https://bugs.mageia.org/show_bug.cgi?id=3550 https://bugs.mageia.org/show_bug.cgi?id=11869
CC: (none) => dpremy
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=10179
*** Bug 11869 has been marked as a duplicate of this bug. ***
CC: (none) => pf
*** Bug 13463 has been marked as a duplicate of this bug. ***
Blocks: (none) => 14069
How can earlier bugs by duplicates of a later bug? and that none of those are resolved, as they report themselves to be. Anyway, this is far more than simply an installer bug. The bug is that the system hangs if anything in fstab is unmountable. An external drive, a partition whose uuid has been renumbered. The problem is that systemd refuses to proceed if there are any errors in the mount process. While not being able to mount / or /usr is obviously a showstopper, not mounting /wigglesworth should NOT be a showstopper. And simply putting a nofail into the fstab line so the lack of mounting is not reported is not a fix, it is a poor bandaid, and means the user is never actually informed that some of his partitions have not mounted.
CC: (none) => unruh
(In reply to w unruh from comment #6) > How can earlier bugs by duplicates of a later bug? and that none of those > are resolved, as they report themselves to be. Duplicates are automatically linked to the "master" bug and set to RESOLVED DUPLICATE - that's how it works. For explanation see https://bugs.mageia.org/page.cgi?id=fields.html#status Mostly the master bug is the one with the most information. > And simply putting a nofail into the fstab line so the lack of mounting is > not reported is not a fix, it is a poor bandaid, and means the user is never > actually informed that some of his partitions have not mounted. This bug is about the installer adding removable media to fstab, which should not happen. There are other bugs for similar issues for a running system (UUID change, or network filesystem not marked as _netdev or nofail) What do you propose to fix _this_ installer bug, or prevent this from happening? For your described issue check https://bugs.mageia.org/show_bug.cgi?id=10179 and/or https://bugs.mageia.org/show_bug.cgi?id=12305 for those issues.
They are all part and parcel of the same bug in systemd (I think)-- namely that it demands that all partitions in /etc/fstab be mountable for the system to complete the boot. If that overarching bug were not there, then having the installation medium in fstab, having a uuid break on a partition, or any of the other problems would not be a boot problem, but a problem that could be fixed from within a running system. One can band-aid every subsidiary problem that that bug causes, "fixing" things here or there, or one can fix the real bug. Ie, without the real bug, having the installer add removable media to fstab might still be a bug, but it would be a minor one, with virtually no consequences, rather than a show-stopper. Regarding the "duplicate" I just found it strange that an early bug would be marked as duplicate of a late bug, rather than the other way around. It does not really matter much, except the earliest one claimed that this bug (adding installation media into fstab) was solved 3 years ago, yet here it still is.
(In reply to w unruh from comment #8) > They are all part and parcel of the same bug in systemd (I think)-- namely > that it demands that all partitions in /etc/fstab be mountable for the > system to complete the boot. If you don't specify any options, that would be correct and also expected behaviour. Although it could fail much more gracefully in simply skipping non-system mounts if they fail. But _this bug_ is the wrong place to discuss this. The problem is known and existent, if you want to improve that fact send in patches to fix it, and attach them to the other bugs. > If that overarching bug were not there, then having the installation medium > in fstab, having a uuid break on a partition, or any of the other problems > would not be a boot problem, but a problem that could be fixed from within a > running system. Those are still two different bugs. The installer should never put any removable media in fstab, that is just harmful - even for older non-systemd installations.
Note that when I recently installed Mageia 4.1 from a usb stick, the usb stick was not added to /etc/fstab. Does that mean that this problem (installation medium added to fstab) has been solved, or was I just lucky? The installation medium WAS still added to /etc/urpmi/urpmi.conf which is only a bit sensible, but at least does not cause boot problems.
Is this bug still valid for last isos?
CC: (none) => ennael1
(In reply to Anne Nicolas from comment #11) > Is this bug still valid for last isos? Did not occur again, but I've not installed a lot of systems in between.
Status: NEW => RESOLVEDResolution: (none) => FIXED
I have this problem again in Mageia 5 Beta 3. It's on a UEFI system (Asrock Z97 Extreme 4, UEFI version P1.80). I copied the classic installation media with isodumper onto a USB stick (FAT32 with UEFI setting). After the installation in UEFI mode the system has the USB stick listed in its fstab and the "storage scan" waits for the timeout duration of 1min 30sec during boot. When I manually remove the entry from the fstab or keep the USB media inserted the boot process has no delay.
Status: RESOLVED => REOPENEDCC: (none) => Michael.RissResolution: FIXED => (none)
*** Bug 15378 has been marked as a duplicate of this bug. ***
CC: (none) => tarazed25
This should be fixed now in current RC ISO builds. http://gitweb.mageia.org/software/drakx/commit/?id=745849cdace7ed86ce12a9a7564bffb42edf0ef3 Closing again, but please reopen if you still experience the problem with the RC when its released.
CC: (none) => remi
Actually I think this one got fixed by: http://gitweb.mageia.org/software/drakx/commit/mdk-stage1/NEWS?id=d590e8727f7274119df1f9e98adc11aca6aafaaa (after beta 3). Really closing
Status: REOPENED => RESOLVEDResolution: (none) => FIXED