On Thu, Sep 1, 2016 at 8:32 AM, Richard Ryniker <ryniker@xxxxxxxxxxxx> wrote: > 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. 3 isn't even a kernel parameter, most things now on the kernel parameter line isn't even meant for the kernel, there is no way to infer what will parse it or what it does. It's a simple hack, and therefore it means the user has to, you know, know what the fuck they're doing when they use boot params. What you're basically saying is, 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. Sorry. > 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!) The last one wins. The last one is the 3 because that's what you set at boot time. By doing that, you're asking for multi-user.target which is exactly what you get. You do not ever get default.target. and since /system-update symlink causes default.target to mean system-update.target, you don't get that. > > In this case, "dnf system-upgrade reboot" is an explicit command to > perform an offline system update. Followed 10 seconds later by your 3. Last one wins. >That is what should happen, > regardless of the (default) target. Any target specification should > apply after the offline update. You overrode that. That's what you're asking for when you set 3 in the bootloader configuration. If you don't like that, stop doing things wrong, and start doing them correctly. > 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? I don't have answers to your questions because I refuse the premise by which they even arise. I only use 3 when I'm editing a particular boot menu entry, non-persistently. If I wanted it persistent I'd change what default.target points to. That's the correct way to make persistent changes. Boot parameters make the OS less portable also. And I foresee the day when Fedora cannot be booted from another OS's bootloader because of this. > 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. Request denied. > 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". My expectation is that any runlevel specified as a boot parameter will inhibit use of default.target and inhibit the offline update. Explicitly stating the runlevel at boot time means don't use default.target. -- Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
