GoboLinux + systemd

Systemd
#1

Hi folks!

I just wanted to report on an experiment that I’ve conducted this week: moving away from our very simple task management system (StartTask, StopTask) towards systemd.

Compiling systemd was smooth – the recipe has already been pushed to Git. The one thing to pay attention to is that systemd comes with executables that will conflict with files from existing packages. Building it with Compile --symlink force systemd ensures that files from systemd take precedence over the ones already in place.

The runtime issues I ran into had to do mostly with the configuration of our DBus package:

  • DBus is looking for service files under /System/Settings/dbus-1/system.d only, whereas systemd installs them under /System/Index/share/dbus-1/system.d. Compatibility symlinks have worked around the problem, but that needs proper fixing.
  • The DBus package needsto be recompiled with modified flags after systemd has been installed: options --without-systemdsystemunitdir and --disable-systemd must be excluded from the recipe and replaced with --enable-systemd.

Other notes:

  • Make sure to create /System/Settings/machine-id by running systemd-machine-id-setup. That should be part of as a PostInstall script, but I haven’t taken the time to write and test that.
  • We have a bug on /etc/passwd! The user id for polkitd is missing. Please search for polkitd and replace polkitd:x::31 with polkitd:x:31:31
  • Unit files do not inherit our customized PYTHONPATH. If a task depends on modules installed under /System/Aliens, then make sure to add something along the lines of EnvironmentFile=/path/to/file under the [Service] section of the relevant unit file.
  • It helps to edit the GRUB command line and append systemd.debug-shell=1 to the boot parameters so that tty9 can be used as a recovery shell in case something goes wrong. Another useful parameter is systemd.unit=recovery.target.

Note that scripts such as DisableProgram and RemoveProgram would have to be eventually made aware of systemd so that services can be properly stopped/disabled. There may be some other hooks that may need updating, but overall the conversion has been surprisingly easy.

Cheers
Lucas

1 Like
#2

This is excellent news!

One of my biggest issues with the ootb GoboLinux install is that you need to actually log in before the network starts up, making it inconvenient to run Gobo (mostly) headless.

1 Like
#3

Welcome to the forum, @ermo!

Yes, that’s a bit inconvenient indeed – thanks for the heads up. I guess this one relates to GoboNet storing WiFi credentials on the user’s home directory; there’s no global settings, which is the reason why it doesn’t automatically connect to any networks on a fresh boot.

@hisham, would you oppose to having centralized settings for GoboNet?

#4

I use a wired DHCP setup, so credentials aren’t necessarily an issue for that use case.

Would it make sense to probe for (ethernet) interfaces and just DHCP them if they aren’t wifi-interfaces? Or is it better to actively configure them (ethernet, not WiFI) somewhere to avoid suprises?

#5

I think it would be generally easier for management to keep wifi credentials and the like in GoboNet under the user as they are, and do a simpler wired-ethernet-DHCP probe during boot as @ermo suggested.

The point of GoboNet was to be ultra-minimal to cater for the “80% case” of a personal single-user with a laptop and wifi and the occasional network cable. Adding support for the remaining 20% cases would complicate it a lot, at which point it would be best to go to any of the existing complicated solutions (all of which annoyed me immensely, leading me to write GoboNet :laughing: ).

2 Likes
#6

All right, that sounds like a good compromise!

2 Likes
#7

How might we get started on this? What’s the first thing that needs to be done for this to become a minimum viable product in the Gobo boot scripts?

Obviously, with @lucasvr 's Systemd “hack”, this becomes as easy as using the built-in systemd-network functionality.

1 Like
#8

I believe that it’s enough to add, to a 016/017-based system, the following line to /System/Settings/BootScripts/BootUp:

Exec "Connecting to the network..." BackgroundExec gobonet connect_wired

I’m not able to test that right now, though. Could you give it a shot and let us know if it does the job for you?

2 Likes
#9

Will try and then get back to you.

As an aside, this is essentially two birds with one stone in the sense that:

1./ It allows for reliable headless operation (no interactive requirement)
2./ It requires explicit initial user action (“configuration” = consciously editing /S/S/BS/BootUp)

… which neatly addresses both of my questions above. :nerd_face:

1 Like
#10

Right, it worked. This is what I added to /System/Settings/BootScripts/BootUp :

Exec "Setting wired ethernet MAC address..."    ip link set dev enp4s0 address <my mac address in ff:ff:ff:ff:ff:ff form>
Exec "Connecting to wired ethernet via DHCP..." BackgroundExec gobonet connect_wired

Setting the MAC address manually is necessary because I accidentally removed the onboard ethernet serial number (= what the card uses for its MAC address) during a BIOS flash.

I had already enabled sshd on this box, so it was just a question of trying to connect to it via ssh without having logged on to it using the console first. And as I said, it worked.

\o/

Using Runner as a sandbox during Compile runs?
#11

This is wonderful news, thanks for testing! I’ll make sure to include this mechanism in a future release :slight_smile:

1 Like