setting the hostname is not persistent accross reboots

My theory for this is behavior is:
- /etc/hostname is a overlay in /writable/system-data/etc/writable/hostname
- on boot our initramfs hook prepares the /etc/fstab that contains the mount for /etc/hostname but does not mount it (this is for systemd) so /etc/hostname contains "localhost"
- when systemd runs it calls hostname_setup() in main.c:1563, the olverlay is not mounted yet so it uses the old "localhost"
- and then runs into its main loop where it executes the units to mount the overlay

I think Michael is correct - since /etc/hostname is mounted from /etc/writable, if you do the following, you'll see the original version of the file:

$ cat /etc/hostname
foo
$ sudo umount /etc/writable
$ cat /etc/hostname
localhost.localdomain

One solution would be to have a systemd unit reset the hostname after processing the fstab entries (or delay hostnamed from starting until all the mounts have completed).

> One solution would be to have a systemd unit reset the hostname after
> processing the fstab entries (or delay hostnamed from starting until all
> the mounts have completed).

Yes, one or the other is definitely what should be done here.

For the record, I'd prefer mounting everything in /etc from the initramfs. That's its purpose after all -- prepare the root file system. Anything else is racy and involves doing more work during boot.

Well, the initrd as a minimum needs to mount the rootfs r/o (which of course we are doing).

I understand the concern, but if we pile everthing into the initramfs, we increase the likelihood of a system failing to boot (either due to a buggy code path, or maybe something like an fsck failing [or even just taking a very long time to complete]). For IoT devices, that sort of failure scenario just isn't an option. We might be able to partially mitigate it through careful and thorough testing, but I think we'd end up having to implement things that userland already provides.

By keeping the initrd sleek and minimal, we get to leverage all the features in userspace that aren't available to the initrd.

I think this needs a lot of further discussion as there are good arguments on both sides. Maybe we're getting to the point where we need to consider: http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/...?

The current plan is to create a system unit that contains essentially:

__________

[Unit]
Description=Set the hostname to the value stored on the writable partition
After=etc-writable.mount
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/bin/hostname -F /etc/hostname
__________

That will set the hostname (again) to the correct value by using the hostname file from the writable partition.

RISK: There is admittedly the possibility that if a service starts before all the mounts have been handled, that it will see the hostname as "localhost.localdomain".

On Fri, Feb 27, 2015 at 03:47:31PM -0000, James Hunt wrote:
> The current plan is to create a system unit that contains essentially:

> [Unit]
> Description=Set the hostname to the value stored on the writable partition
> After=etc-writable.mount
> DefaultDependencies=no

<snip>

> That will set the hostname (again) to the correct value by using the
> hostname file from the writable partition.

> RISK: There is admittedly the possibility that if a service starts
> before all the mounts have been handled, that it will see the hostname
> as "localhost.localdomain".

Where does systemd currently do the setting of the hostname? I would have
expected this unit to include a 'Before=hostnamery' rule to enforce the
sequencing of etc-writable.mount and initial hostname setting, instead of
re-setting the hostname. But maybe the hostname is handled entirely
internally to systemd, and we have no way to insert a sequence point there?

Steve Langasek [2015-02-27 19:52 -0000]:
> Where does systemd currently do the setting of the hostname?

It's not a unit, it's done right in the daemon before starting units.
It's more or less just sethostname(/etc/hostname).

> we have no way to insert a sequence point there?

James' unit is pretty much such a sequence point, i. e. the same way
we handle it in upstart (externally with an explicit job). So in
principle we get the same race condition as under upstart, but I
suppose it's not a practical problem if you do it early enough.

Any idea when the merge will be accepted? Looks great to me!

james, let us know what is blocking; if not lets land it...

I believe we're waiting for an ack on the current approach.

I'm not sure if you are blocking on me (I wasn't aware of that), but I commented on the MP just in case.