Re: f27, hostname changes from former to current during boot
On Sun, Nov 12, 2017 at 1:29 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Sat, Nov 11, 2017 at 09:05:48PM -0700, Chris Murphy wrote:
> Nov 11 20:37:26 f26s.localdomain systemd[1]: Reached target Switch Root.
> Nov 11 20:37:26 f26s.localdomain systemd[1]: Starting Switch Root...
> Nov 11 20:37:26 f26s.localdomain systemd[1]: Switching root.
> Nov 11 20:37:26 f26s.localdomain systemd-journald[200]: Journal stopped
> Nov 11 20:37:32 f27s.localdomain systemd-journald[200]: Received
> SIGTERM from PID 1 (systemd).
> Nov 11 20:37:32 f27s.localdomain kernel: systemd: 17 output lines
> suppressed due to ratelimiting
>
>
> I'm not sure what component's bug this is. All I've done after dnf
> system-upgrade from F26 to F27 is 'hostnamectl set-hostname
> f27s.localdomain' but every reboot, it looks like initramfs stuff has
> the old hostname and then after switchroot and journal stopping and
> starting up again, it gets the new hostname. It's unexpected, I don't
> remember this behavior with F25 to F26.
>
> So... systemd or dracut?
>
> If I do dracut -f, the problem is fixed. But storing the hostname in
> the initramfs doesn't seem like a good idea just for this reason, get
> a stale one polluting the log every boot and maybe there are other
> effects.
This is a well known limitation of no-hostonly dracut images: the
initramfs contains local configuration and has to be rebuilt when that
changes. Alas, rebuilding the initramfs (initramfs-es actually) is
considered too risky to do automatically on something as trivial as
hostname change. So your choices are either to stop using hostonly
images (in which case you'll get the default hostname) or to rebuild
any images after changing the hostname.
I expect that in F25 you didn't have a host-only image, so you didn't
see this.
Or maybe I didn't notice it before a new kernel, and hence new
initramfs, was created.
Thanks for the explanation.
--
Chris Murphy