I seem to have touched a sore spot on Mr. Murphy, and apologize if I
have unintentionally irritated him. 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.
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 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:
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.
The offline update has a stale set of package files. These were
downloaded days, weeks, perhaps even longer in the past. During
this time, newer packages are installed in the system. After the
delayed offline update completes, the new system has old packages,
not current ones.
Perhaps, despite Mr. Murphy's explanation about how offline update
works, I misunderstand the process and the problems I describe above
cannot occur. I should be pleased to learn this is so.
If I am substantially correct, here are some suggestions for
improvement.
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."
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
