Re: [gentoo-amd64] Systemd migration: opinion and questions

[Marc Joliet]

Hi,

it's been a while, but there are a few things to report.  So here it goes:

Am Tue, 24 Feb 2015 21:15:45 +0100
schrieb Marc Joliet <marcec@×××.de>:

[...]
> == Network migration on my desktop ==
>
> My desktop has a somewhat more complicated network setup than the laptop (which
> uses NetworkManager).  The wan0 network device is no problem, but I also have a
> bridge with one physical device connected to it, and one dummy device.
>
> Thus, I had to migrate my netifrc based configuration.  Due to word of mouth, I
> decided on netctl.  I originally ignored systemd-networkd because I keep
> hearing that it's only for simple networks, but after looking at the man page
> it appears that it can do (almost) everything that I needed it to, although I'm
> not sure about dummy device support.  I need that for MATLAB, which stupidly
> requires the presence of an interface named eth0, whose MAC address it verifies
> during its licence check.  This became a problem after renaming my network
> devices following the news entry 2013-03-29-udev-upgrade ("Upgrading udev to
> version >=200").
>
> What surprised me was that netifrc doesn't seem to integrate dummy devices
> properly, i.e., it doesn't seem to be possible to rename them in
> /etc/conf.d/net directly.  I implemented that via an appropriate call to ip in
> an /etc/local.d file, and had "net.eth0" depend on "local".  So /etc/conf.d/net
> looked like this:
>
>     config_eth0="172.16.1.1/24"
>     mac_eth0="00:18:f3:97:17:72"
>     rc_net_eth0_provide="!net"
>     rc_net_eth0_need="local"
>
> And the local.d script executed
>
>     ip link set dev dummy0 name eth0
>
> In comparison, the netctl configuration has everything in one place:
>
>     # cat /etc/netctl/dummy
>     Description='A dummy interface (for MATLAB)'
>     Interface=eth0
>     Connection=dummy
>     IP=static
>     Address=172.16.1.1
>     IPCustom=( 'link set dev eth0 address 00:18:f3:97:17:72' )
>
> It also takes care of loading the dummy kernel module, so I don't don't need an
> /etc/modules-load.d/ entry, whereas with netifrc/OpenRC I needed to load it
> manually via /etc/conf./modules (though maybe that has changed?).

A few days ago I finally got around to giving systemd-networkd a whirl, as I
said I would in the sub-thread started by Rich.  It turns out that it fulfils
the needs of my computers just fine, and has (together with systemd-resolved)
fully replaced netctl.  The only thing I'm not sure of is how extensive IPv6
support is.  The man page suggests that only DHCPv6 is supported, but not
stateless configuration.  Not that my LAN has IPv6, but it'd be nice to know
how future proof it is.

(This was made a tiny bit easier since I recently got rid of most of the server
functionality of my desktop, i.e., it has stopped acting as a router.  So I'm
only using the built-in ethernet port now, and will remove the other soon.)

I also switched the laptop over, which was using NetworkManager, but now uses
wpa_supplicant directly with systemd-networkd on top (basically swapping out
one upper layer for another).  It required a small bit of configuration so that
wpa_gui had a socket to connect to, and so that it could save the configuration
file, but that was just two additional lines (along with two minimal *.network
files, although now that I think about it I'm not even sure whether they're
needed). It appears to work as fine as it did when running NetworkManager, so
I'm happy to be rid of NM.

One thing I noticed about systemd-networkd is that it, too, follows the theme
of being designed around dynamic changes, namely network/device
addition/removal.  This becomes apparent when you learn that you can use wild
cards to match devices.  For example, when using the new udev network device
naming scheme (aka "predictable names"), "en*" matches all ethernet ports and
"wl*" matches all wireless ports.  So that's interesting, I think, and I'm
curious to see how systemd-networkd will evolve.

I would now like to take a moment to mourn the unmerging of dhcpcd, which
fulfilled its task of configuring the IP address (and other associated tasks) of
my computers marvellously for over 8 years (first emerged on: Wed Jan 10
14:44:09 2007).

Done?  Great, now let's celebrate the unmerging of NetworkManager :-D .
*phweeee* *balloon popping* *other generic party sounds*

> == Stuff I liked ==
>
[...]
> == Questions ===
>
> === ACPID: needed or not? ===
>
> Does acpid provide anything that systemd does not, and if so, what kind of
> "conflicts" might I see?  The Gentoo Wiki page says that acpid is likely not
> needed.
>
> FWIW, I already unmerged it and have not noticed any missing functionality,
> even after over a week of regular usage.  So I'm tending towards "no, not
> needed".

I have not noticed anything amiss in the many months I have been using my
systems without acpid.  So my "tendency" has morphed into "assuredness".

> === Timers ===
>
> Can a systemd timer depend on a mount point such that it waits until the mount
> point exists before running?  Or will it fail after a timeout?  I want to
> research this myself, but haven't gotten around to it yet.
>
> The problem I have is that my external HDD does not come up properly on cold
> boot, so that I have to unplug it and plug it back in in order for the kernel
> to fully initialise it and for it to mount, which is problematic for my backup
> fcron jobs, since they have &bootrun set. This means that the backup script
> will fail, unless I'm a) fast enough at re-plugging the HDD, and b) fast enough
> at logging in (so that my automounter mounts the HDD.  I will then have to
> manually re-run it (i.e., fcrondyn -x "run <ID>") or wait for the next time
> it's supposed to run.
>
> Naturally, I would like a more robust system than that, and hope that systemd
> timers can make my life easier here.

I ended up asking specifically about the HDD problem on gentoo-user, and was
redirected to the linux-usb ML.  I already mentioned the final diagnosis on
gentoo-user, but haven't repeated it here yet:

    "After diagnosing the problem with the help of Alan Stern and Matthew
    Dharm, the conclusion was that the sector size translation must be
    triggered by some interaction between the drive and the BIOS.  The test I
    performed to determine this was:

    - unplug the drive,
    - turn on the computer,
    - plug the drive in once GRUB has started, and
    - boot the kernel,

    after which the drive worked fine.  So this does not seem to be anything
    that can be fixed in the kernel.  Perhaps if I had an EFI compatible
    mainboard, I wouldn't be seeing this problem, but I don't, so I can't even
    try it out :-/ ."

So, as sad as it is, my "solution" is to follow those four basic steps whenever
I turn my computer on, and then I don't get any problems.

[...]
> === Suspend on the desktop ===
>
> Like I mentioned above, my Desktop can *almost* suspend reliably, after trying
> it out once every year or two (it's over 8 years old).  Mostly it would just
> not wake back up.  The latest status (before systemd) was that the kernel
> crashed after waking up (but I think that was a known bug that was fixed in the
> meantime).
>
> Now with systemd, it wakes back up properly, but one of the soundcard drivers
> (ice1724) is apparently unreliable, so that sound stops working after wakeup.
> Plus, access to the soundcard was blocked by rtkit.  I believe what one would
> normally do is unload the module before suspending, but the only way I could
> find to tell systemd to do that requires creating a file in /usr (as done here,
> for example: http://forums.fedoraforum.org/showthread.php?t=294065).  Is there
> a better way?

Well, I ended up doing this, and suspend/resume *almost* works, but still not
quite: I couldn't access my USB3 HDD as a regular user anymore after resume, and
it seems that my desktop shuts itself off after a while.  Although maybe that
has to do with the empty CMOS battery? Or a failed hibernation attempt?  Just
some random ideas.

Again, I'm not pushing this, I'm just trying it out every now and then.  My
main motivation here is to waste as little electricity as is possible with this
old desktop.  What I would like to be able to do is to pause whatever I'm
doing, suspend, do something else for a while, and then resume, *without*
having to restart applications.  (Even better would be to buy a new, more energy
efficient computer, but I cannot afford that right now.)

@Duncan: it seems to me that the btrfs RAID has yet to be a problem during
resume (doesn't mean it won't be, but that's what I've seen so far).

[...]

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup