On Tue, Jan 27, 2015 at 10:58 PM, Felix Miata <mrma...@earthlink.net> wrote: > Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): > >> Felix Miata wrote: > >>> Both. When they occur during init they repeat during shutdown. Even when I >>> let init complete and succeed to fix the typo or oversight, the init failure >>> gets remembered and repeated at shutdown. Often the start job is on account >>> of a volume label that has been replaced, usually along with a UUID, because >>> the clone is a partition on the same HD. Fedora is particularly frustrating >>> by embedding dependent root volume label and not obeying root= on cmdline >>> (openSUSE obeys root=). Those typos usually have to be fixed by chroot to >>> run >>> dracut. > >> Hmm, Fedora doesn't obey root=? That sounds like a bug.
I'm not sure what it means, Fedora doesn't obey root=. Since a long time it uses root=UUID= and this has worked for me. > > I think it's only a problem due to Fedora's configuration of its Dracut > hostonly option used by default. AFAICR, its rescue initrds have always > worked. The problem(s) with Fedora rescue initramfs: 1. It behaves differently depending on whether its /lib/modules have been deleted because the originally installed kernel has been removed due to yum.conf installonly_limit=3 being reached. If deleted, user gets dropped to a dracut prompt. And if not they get a complete boot to a login prompt. It's better than a kernel panic, but the inconsistency is not a good UX. 2. "rescue" is a generic term, but this nohostonly initramfs is really meant to get a close to full boot when changing hardware such that the hostonly initramfs does't work. So the use case is not really rescue. 3. A user might think "rescue" is for fsck or something basic. But that can be done with rd.break=cmdline it doesn't require the rescue initramfs. 4. Confusion with rescue.target and emergency.target. Both of which require a root password, and Fedora now doesn't require a root password at install or setup time, so the user can actually get stuck being unable to access rdsosreport.txt because they can't login. So... it's slightly ickey right now for these edge cases. Anyway, room for improvement. -- Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel