On Sat, Sep 3, 2016 at 1:47 PM, Richard Ryniker <ryniker@xxxxxxxxxxxx> 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 > original poster. 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 line argument. > > 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 > happen: 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. It's expected. 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 it > 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 > reboot" > > Document the interaction between offline update and old style run > level numbers. Resources such as > > https://fedoraproject.org/wiki/DNF_system_upgrade > > 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. -- Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
