I am unhappy with the suggestion that the semantics of kernel parameters may depend on some notion about how "temporary" they are. If a kernel parameter is specified, it is present; if not specified, it is absent. It is proper to design parameter syntax and default values to favor common usage. There also have to be mechanisms to handle different specifications for the same parameter (first or last wins...) and use of incompatible parameters (pick one, ignore both... but always log the choice!) In this case, "dnf system-upgrade reboot" is an explicit command to perform an offline system update. That is what should happen, regardless of the (default) target. Any target specification should apply after the offline update. Are you concerned about the possibility "dnf system-upgrade reboot" was ordered, then immediately decided it was wrong? How many times do you want to ask "Do you really mean this?" Why should specification of boot target 3 as a kernel parameter pretermit the offline update - but possibly leave it waiting to occur unexpectedly during a subsequent boot? Your explanation of how systemd implements offline update using a symlink offers an escape: boot from a different root file system (a live image, if necessary) and remove the offline update symlink. If you think that is too esoteric or awkward, implement a new kernel parameter such as "cancel-offline-update" that does this. What is the relation between run level 1 and offline update? Does run level 1 stop the init process before offline update? If yes, then that is an easy escape: boot to run level 1, remove the offline update symlink, then "systemctl default". -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
