# [SOLVED] systemd and localectl error

## AchilleTalon

I am in the process to upgrade to systemd and I ran into this problem.

I am getting the following error while trying to show the current setup.

```
myhost etc # localectl

Could not get properties: Input/output error
```

I checked and the /etc/locale.conf file exists.

```
myhost etc # ls -l /etc/locale.conf

-rw-r--r-- 1 root root 19 Oct  6  2011 /etc/locale.conf
```

Any hints?

P.S.: I should add I am using the following instructions and at the Post-installation phase it says to start three background processes: systemd-localed, systemd-timedated and systemd-hostnamed. None of these processes stays active and I get no error message on termination except for systemd-timedated which returns immediately with the message: Failed to determine whether NTP is enabled: Input/output error

----------

## eccerr0r

Just some "oops" checks here, is systemd running when you run localectl?

----------

## AchilleTalon

 *eccerr0r wrote:*   

> Just some "oops" checks here, is systemd running when you run localectl?

 

Accordingly to the instructions above, nowhere we are instructed to start the systemd daemon. In fact, these three commands are requested to be executed manually specifically because the systemd daemon is not yet active.

Here again the URL to the instructions on how to move to systemd

----------

## wraeth

 *AchilleTalon wrote:*   

> these three commands are requested to be executed manually specifically because the systemd daemon is not yet active

 

I've never been able to get these processes running during an install when I'm chrooted into the environment - I've always had to finish up what I could until I was in a reboot-ready state, reboot and start with init=/usr/lib/systemd/systemd; then set the appropriate environment configuration then, generally rebooting once they're set so I'm starting from a clean "configured" environment.

The alternative to this is, if using a LiveCD environment that uses systemd, do your initial chroot to update the system and install systemd; then exit the chroot and enter it again with `systemd-nspawn -bD /mnt/gentoo`; which will both chroot into the environment, and start an isolated instance of systemd as if the system was actually booted.

----------

## AchilleTalon

 *wraeth wrote:*   

>  *AchilleTalon wrote:*   these three commands are requested to be executed manually specifically because the systemd daemon is not yet active 
> 
> I've never been able to get these processes running during an install when I'm chrooted into the environment 

 

These instructions are for an update, not a fresh new install in a chrooted environment.

 *wraeth wrote:*   

> - I've always had to finish up what I could until I was in a reboot-ready state, reboot and start with init=/usr/lib/systemd/systemd; then set the appropriate environment configuration then, generally rebooting once they're set so I'm starting from a clean "configured" environment.

 

Your comment suggest the update instructions on the official referred Wiki page are incorrect. However, since you have confused the update with a fresh new install I would like to have other comments on this from people who actually did the update process. The reason I install systemd is because it is required for the upgrade from my old Gnome desktop to the latest 3.8 version. And the instructions for the Gnome update refer to the instructions for the systemd saying I must complete the systemd update before proceeding with remaining steps for the Gnome update. I suspect nobody actually have completed the full update using these instructions to the letter and checking them. It is a real shame when the installation instructions are buggy themselves. I have spent days so far in this update and I still haven't a working system. I am about to move away from Gentoo for this sole reason that you either keep your system current, which imply unstable since you continually update things, either you spend a week updating your system when you have many major changes to do because old versions are no longer in the portage tree. This is a major investment of time and I am no longer sure it worth it.

 *wraeth wrote:*   

> The alternative to this is, if using a LiveCD environment that uses systemd, do your initial chroot to update the system and install systemd; then exit the chroot and enter it again with `systemd-nspawn -bD /mnt/gentoo`; which will both chroot into the environment, and start an isolated instance of systemd as if the system was actually booted.

 

As stated above, this is not about a new install, I am updating a working system.

----------

## wraeth

 *AchilleTalon wrote:*   

> These instructions are for an update, not a fresh new install in a chrooted environment.

 

My  apologies if I misunderstood - I thought this was a case where systemd wasn't running and didn't realise it was for an existing installation of systemd.

In that case, can you try seeing if there are any failed units with `systemctl --failed`, or possibly see if there's any error output in `journalctl -mn50` immediately after you've tried running localectl?

----------

## AchilleTalon

 *wraeth wrote:*   

> My  apologies if I misunderstood - I thought this was a case where systemd wasn't running and didn't realise it was for an existing installation of systemd.

 

No, no, it is not an existing installation of systemd. It is a switch from openrc to systemd on an existing and running system. This is what the referred link is about: http://wiki.gentoo.org/wiki/Systemd

You are right on the point there is no systemd running yet. But since I am not following the instructions for a brand-new install I cannot say if the upgrade process is identical on these matters.

----------

## wraeth

 *AchilleTalon wrote:*   

> But since I am not following the instructions for a brand-new install I cannot say if the upgrade process is identical on these matters.

 

Okay, well as I said I've never been able to get systemd-localed, systemd-timedated or systemd-hostnamed to run when systemd itself wasn't running, and I believe it's specifically because systemd isn't running; I just haven't had the opportunity to fully play around with this because it's always been on live systems that I was working on (and I always get distracted before being able to set up a suitable environment to test in).

Theoretically, the process is the same whether it's for an existing live system or for a new installation, since in both you are installing systemd and, at this point, it's not running.

Whenever I've been in this situation, I've just rebooted with systemd as the init system (you should be able to tell from the boot process, but you can also check with `cat /proc/1/comm`), set the environment (hostname, time/date, and locale), and rebooted again.

Alternatively, if you want to investigate this further, we can try and get the three daemons running before booting systemd so that your first boot has a properly configured environment (I'll spin up a VM so I can try and figure things out here, too).

----------

## AchilleTalon

 *wraeth wrote:*   

> Theoretically, the process is the same whether it's for an existing live system or for a new installation, since in both you are installing systemd and, at this point, it's not running.
> 
> Whenever I've been in this situation, I've just rebooted with systemd as the init system (you should be able to tell from the boot process, but you can also check with `cat /proc/1/comm`), set the environment (hostname, time/date, and locale), and rebooted again.

 

Okay, then I conclude the instructions for the update are flawn and a reboot instruction should be inserted to tell us to reboot before trying to setup locale, timedate, etc. As long as nothing prevent the system to boot properly.

 *wraeth wrote:*   

> Alternatively, if you want to investigate this further, we can try and get the three daemons running before booting systemd so that your first boot has a properly configured environment (I'll spin up a VM so I can try and figure things out here, too).

 

It will not be necessary as long as the reboot fix the problem. Still remain the flawn instructions.

----------

## wraeth

I do suspect that the instructions are out of date with this particular part, but because I haven't had the opportunity to properly test it out I've been reluctant to update the wiki page.

Given your experience, though, I think I'll make this a priority and try to test and update the instructions in the next couple of days.

When you reboot your system, you will notice that your hostname will likely have reverted to 'localhost' and your system time may be incorrect. Once you've booted with systemd, though, you'll be able to update these with the hostnamectl, timedatectl and localectl commands. You probably don't have to actually reboot again once you've done this, but I like to just to ensure I'm working with a clean boot.

----------

## eccerr0r

Yeah I think it should be made a bit more clear in the wiki that you need to reboot the machine (though it is somewhat implied by the ordering of having the bootloader instructions before localectl) versus doing these in a chroot setup.

And yes it seems those systemd-* helpers aren't working as described.

In any case you can defer the setup commands until after the reboot, they're not critical.

----------

## wraeth

Just a quick update, the wiki instructions at https://wiki.gentoo.org/wiki/Systemd have been updated for handling hostname, locale and time/date settings when moving to systemd.

----------

## AchilleTalon

 *wraeth wrote:*   

> Just a quick update, the wiki instructions at https://wiki.gentoo.org/wiki/Systemd have been updated for handling hostname, locale and time/date settings when moving to systemd.

 

Just to summarize, I did reboot and everything went fine after I hit another problem since my system refuses to boot and throw me into the maintenance shell. I am having my / on a regular partition and the remaining on LVM2 (except /boot). I scratched my head on this one an rebooted many times trying different things until I hit the Troubleshooting section of the systemd HowTo, the line that saved the day:

```
root # systemctl enable lvm2-monitor.service
```

One more problem remains, I have still my hostname to localhost. I have dhcpcd enabled and the hostname is provided by the dhcp server and it seems for an unknown reason the transient hostname is not updated, any hints on this one?

----------

## wraeth

Glad that you got it working  :Smile: 

I'm not certain about setting the transient hostname - Depending on your network configuration, you may need to add an explicit option into /etc/dhcpcd.conf (or other appropriate configuration file) to get the hostname from the DHCP server; or even add a hook to the DHCP client to set the transient hostname.

For /etc/dhcpcd.conf, for example:

```
option domain_name_servers, domain_name, domain_search, host_name
```

----------

## AchilleTalon

Problem solved.

First of all, since my IP addresses are static in this case, for the entries on the DHCP server side in the dhcpd.conf file for each host (group depending on your configuration) add the following line: option host-name "";

Here is a snippet of code in the configuration file:

```
host myhost {

  fixed-address myhostname.cids.ca;

  hardware ethernet XX:XX:XX:XX:XX:XX;

  option host-name "";

}
```

Where XX are replaced by the MAC address of the requesting interface. The stanza fixed-address myhostname.cids.ca; will request the IP address to assign to this host from the DNS (not a DDNS configuration here, we are not updating anything on the DNS) and the option host-name ""; is instructing the DHCP server to forward the Fully-Qualified-Domain-Name to the client since the field is empty (""). Restart the DHCP server to activate the changes.

On the client-side, I updated the the DHCP client (dhcpcd in my case) to comment the hostname entry which instructs the client to send its hostname to the DHCP server for it to update the DDNS which is not my configuration. The already existing option host_name is requesting the hostname from the DHCP server instead.

Restart the DHCP client to activate. The transient hostname is now set to the FQDN.

----------

