On Sat, Sep 3, 2016 at 1:47 PM, Richard Ryniker <ryniker(a)alum.mit.edu> wrote:
I seem to have touched a sore spot on Mr. Murphy, and apologize if I
have unintentionally irritated him.
What annoys me is that people want to have things two ways. Basically
they want what they want because they want it, which simply isn't good
enough reasoning because it's circular logic. SysVInit systems set
persistent runlevels in /etc/inittab, and systemd systems do it with
the /etc/systemd/system/default.target symlink. That is how it works.
If you want a certain runlevel or target to be persistent, there is a
mechanism for that and putting it on the kernel parameter line is
simply the wrong way to do it.
Apology is not required, my annoyance is not your responsibility.
If he is the designer of the
offline update mechanism, and I correctly perceive the implications of
his explanation, then I do scold him for failure to mitigate the
damage that might occur to a system in the situation reported by the
I'm not the designer. But I'll defend the design because there's X^n
ways for a user to sabotage updates, and there must be a limit on how
much testing anything does to check whether or not the user has
sabotaged the system. Adding a 3 permanently to grub.cfg is sabotage.
The user doesn't know what they're doing, because if they did, they
wouldn't modify /etc/default/grub in this manner.
And what damage? In this case dnf fails safe. It does nothing. That's
a completely reasonable outcome as a result of prior user sabotage.
The smaller problem is that there is no explanation why the offline
upgrade is not performed after "dnf system-upgrade reboot". I expect
a person with the authority to execute the dnf command knows how to
examine the system journal to seek an explanation for why it did not
happen. Mr. Miata presumably looked and could find nothing, which is
why he created the original post.
The problem here is either:
a. dnf is using a really simplistic message hand off to systemd via
the /system-update symlink while not first parsing the existing
bootloader configuration for a conflicting parameter and removing it.
b. systemd is not resolving the ambiguity of finding a "3" boot
parameter, and /system-update symlink. But how can it resolve that
ambiguity? Is it supposed to check the date stamp of grub.cfg and
/system-update and use the one with the most recent modification time?
So exactly what and where is the failure even determined? It's really
a systemd issue as near as I can tell. So I suppose systemd could not
do the offline update and just say something like "command line target
conflicts with system-update.target" while always honoring the command
The larger problem is the offline update remains pending,
indefinitely, until the old-style "run-level" number is removed from
the "kernel parameters" (or whatever name you prefer to describe this
hodgepodge collection of data.) This might happen days, even weeks,
after the "dnf system-upgrade reboot" operation. Two bad things then
There are always consequences to user sabotage. It doesn't matter if
that sabotage is innocent ignorance or willful ignorance, the computer
doesn't distinguish between them.
The boot operation, now executing the offline system update, takes
a long time: typically one hour with a rotating drive, less with a
solid state drive, longer if many extra packages are installed. If
this is expected and planned, fine. If it is unexpected, an
important service may go missing - an unplanned outage with
expensive consequences for users.
There are a couple of ways to do out of band/out of tree updates that
don't have this kind of impact and also with far reduced risk.
rpm-ostree is one possible way to do that and there's an active plan
to get Workstation to be rpm-ostree based installations.
Implement a service to check for a pending offline update and add
to the dependencies for the multi-user and graphical targets. At
the least, this service will emit a message to say there is a
pending offline update that was not executed. Even better, in my
opinion, would be to remove the symlink that triggers an offline
update and emit a message that says the pending offline update has
been canceled and can be rescheduled with "dnf system-upgrade
Document the interaction between offline update and old style run
level numbers. Resources such as
should provide enough information about this operation to avoid the
need to tell a user "You're unhappy that you have to know what the
fuck you're doing to get it to do what you want it to do."
Right, and thank you for calling me out on my bullshit. But the fact
does remain that sometimes, and this is one of those cases, the user
is expected to know what they're doing and because they don't, they
unwittingly caused the update process to be thwarted in a way that the
simplistic update mechanism doesn't itself test for. While it fails
gracefully, it doesn't have a means to recognize the desired upgrade
didn't happen and then notify the user.
What you're describing isn't simple. Maybe the simplest one would be
just systemd logging the ambiguity of conflicting command line
parameter and the existence of a /system-update symlink. But note that
by necessity that log entry would not be in the current (re)boot,
it'll be in the failed offline update boot, i.e. -b -1, which also
isn't exactly obvious for the user to look for. But better than
nothing I suppose.
So sure, try filing an RFE bug against system... might be interesting
to see what they say.