[systemd-devel] root= ignored (was: failing boot start jobs delay reboot)

Chris Murphy lists at colorremedies.com
Tue Jan 27 22:29:46 PST 2015


On Tue, Jan 27, 2015 at 10:58 PM, Felix Miata <mrmazda at 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


More information about the systemd-devel mailing list