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
#12

I wonder, if there are currently any plans to make systemd a default, and only init system in GoboLinux?

#13

Greetings, @azarens. Yes, I’d like to see this happening on the next release, if possible.

#14

Hello @lucasvr. Considering the real issues highlighted at e.g. http://nosystemd.org/, how is that aim being motivated? Has there been a discussion about this before?

I also have concerns about the use of dbus in systemd, and specifically the set of issues listed at Rethinking the D-Bus Message Bus.

#15

It’s more about the convenience of packaging programs, easing the maintenance + bootstrapping of new releases, and running packages from other distros. It’s a whole lot of work to make things work out of the box when we’re not following the footsteps of the big distros.

I’ve been running GoboLinux on my personal and work-related computers for almost 20 years now. It wasn’t until very recently that it became a nightmare to run corporate-level programs that rely on systemd tools and services. I’m not willing to move away from GoboLinux, so the natural choice for me is to embrace that change and stay productive (as opposed to spending countless hours reverse engineering such programs to understand what they’re demanding from my system and then writing wrappers as needed).

I’ve talked about this topic before with several users and developers, and nobody really opposed to the idea. We could have some input from @hisham and @mwh, if they feel like saying something about this. Also, we’re aware of the criticism against systemd, but frankly many of the issues raised before are normal bugs in the life cycle of a software. Personally speaking, I’m not in love with neither systemd nor with our current boot system but, as long as we can have a way to keep our boot themes around, I guess everyone will be happy with whatever decision we take moving forward.

#16

I don’t think patching everything to remove its growing default-dependence on systemd is a worthwhile investment, and it sounds like moving to use it is fairly straightforward (and already done?!). The current init system is not really a core feature that anybody is keen to maintain, as far as I know. I don’t see any reason not to make this move at this point.

If I’m completely honest, getting GoboLinux off lists of “distributions without systemd” is a net positive to me, even though I don’t really care about the init system itself.

2 Likes
#17

May I ask, which software is dependent upon systemd? I have a working desktop system built with pkgsrc that doesn’t need either systemd or dbus.

I wonder, if virtualization may be an option for those special packages that rely on systemd? What about a lean implementation of systemd? I’m aware that in case of Android, there exists a project called microG that serves a similar purpose (of replacing huge Google’s services with lean open-source versions).

#18

There are distributions, like Void, that don’t use systemd, and rely instead on runit. The impression that I have been getting so far is that they’re not particularly challenged about that.

#19

Given that the bulk of work has already been done to support the de facto default system, I can’t see any reason to pick something esoteric, which would make for more integration work here.

I don’t think we want to care about the init system, though I understand that there are people who do want to.

#20

I’m not even married to the idea of keeping the boot themes (especially if we could slap some graphical boot on top of the boot progress — I’d be happy to work on the visuals).

For instance, a bunch of third-party enterprise and banking software which are hard to virtualize. Most software, OSS included, that ships with boot-time services ships with systemd files by default nowadays. Supporting anything else involves extra work.

That would be a huge maintenance burden. I don’t think anyone involved in Gobo wants to maintain an alternative implementation of systemd — the whole point of switching to it is to reduce maintenance burden.

I don’t mind dbus. It’s so seamless nowadays that I actually had to double-check whether I was using it or not (I am, probably due to pulseaudio?). So no concerns on the systemd switch from my part, if it works as well as the pulseaudio switch worked. :+1:

1 Like