Mailing List Archive

On Sun, Mar 1, 2015 at 7:48 AM, Marc Joliet <marcec@gmx.de> wrote:
>
> The problem with conditions (as they exist in systemd currently) is the same as
> with dependencies: the unit does not wait until the condition is met, but
> immediately stops (only that it doesn't enter a failed state). I mean, this is
> what conditions in systemd are *supposed* to do, and they do they're
> designated job, but I would like the timer to wait until the condition is met
> and *then* run the job. I.e., I want a *delay*.

The timer keeps running if you set the dependency on the service. So,
next time the timer runs, it will try again. You might want to just
set an hourly job and have it check for a successful run in the last
day or whatever.

I don't know if restart=on-failure or on-abnormal applies if the
service fails to run in the first place. You might try setting that
with a suitable restartsec=### setting. That might be a better way to
get the behavior you want if it works.

--
Rich

Am Sun, 1 Mar 2015 08:34:19 -0500
schrieb Rich Freeman <rich0@gentoo.org>:

> On Sun, Mar 1, 2015 at 7:48 AM, Marc Joliet <marcec@gmx.de> wrote:
> >
> > The problem with conditions (as they exist in systemd currently) is the same as
> > with dependencies: the unit does not wait until the condition is met, but
> > immediately stops (only that it doesn't enter a failed state). I mean, this is
> > what conditions in systemd are *supposed* to do, and they do they're
> > designated job, but I would like the timer to wait until the condition is met
> > and *then* run the job. I.e., I want a *delay*.
>
> The timer keeps running if you set the dependency on the service. So,
> next time the timer runs, it will try again. You might want to just
> set an hourly job and have it check for a successful run in the last
> day or whatever.
>
> I don't know if restart=on-failure or on-abnormal applies if the
> service fails to run in the first place. You might try setting that
> with a suitable restartsec=### setting. That might be a better way to
> get the behavior you want if it works.

I think I tried that (with a Requisite dependency, because I didn't want the
drive to be mounted automatically by the service). I'm certain that it did not
work, and that it could not. Specifically, what I remember seeing is the unit
trying to start and immediately failing due to the missing dependency.

Which makes sense, because Restart= applies to the program being executed
(i.e., processes started by Exec*), not the service unit itself. If the failure
happens before that (e.g., a required dependency is not met) then it doesn't
even get to the point where it can check a return code, so it *cannot* apply.

So the way I'm using Restart= is about as good as it gets.

But actually, while putting off finishing this email, I came to the realisation
that I could of course use WantedBy= in [Install], and following that idea I
ended up with the following [Unit] and [Install] sections:

[Unit]
Description=Run hourly backups (timer)
Requisite=media-MARCEC_BACKUP.mount
BindsTo=media-MARCEC_BACKUP.mount
After=media-MARCEC_BACKUP.mount

[Install]
WantedBy=timers.target
WantedBy=media-MARCEC_BACKUP.mount

So the mount point and the timer both depend on each other (with the mount unit
starting first), so the mount tries to start the timer and vice versa, but only
the timer fails if the mount point doesn't exist. And the BindsTo sees to it
that the timer disappears if the mount does. Preliminary tests show that it
works: unmounting with udiskie shows that the backup timer disappears, and it
re-appears after mounting the file system again.

I'll have to see what the behaviour is during a cold boot. The Requisite
dependency on the mount point *should* make the Restart line in the
corresponding service obsolete, since the WantedBy should make the timer start
once the mount point shows up. I could probably alternatively use
ConditionPathIsMountPoint instead, but I think I prefer the timer failing.

I also have to admit here that I am still not sure *what* I want (sorry), so I
think I'll just have stop fiddling with this for now and see how this works out
in practice.

Regardless: thoughts?

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

On Sun, Mar 1, 2015 at 1:20 PM, Marc Joliet <marcec@gmx.de> wrote:
>
> Regardless: thoughts?

I'd probably just do this:
> Am Sun, 1 Mar 2015 08:34:19 -0500
> schrieb Rich Freeman <rich0@gentoo.org>:
>>
>> The timer keeps running if you set the dependency on the service. So,
>> next time the timer runs, it will try again. You might want to just
>> set an hourly job and have it check for a successful run in the last
>> day or whatever.
>>

You could of course trigger this from either the mount or hourly.
Anytime you mount the drive or every hour systemd will run the
service, and the service will see if it managed to do a backup/etc in
the last day/week/whatever, and then run if appropriate.

--
Rich

Rich Freeman posted on Sun, 01 Mar 2015 14:13:53 -0500 as excerpted:

> On Sun, Mar 1, 2015 at 1:20 PM, Marc Joliet <marcec@gmx.de> wrote:
>>
>> Regardless: thoughts?
>
> I'd probably just do this:
>> Am Sun, 1 Mar 2015 08:34:19 -0500 schrieb Rich Freeman
>> <rich0@gentoo.org>:
>>>
>>> The timer keeps running if you set the dependency on the service. So,
>>> next time the timer runs, it will try again. You might want to just
>>> set an hourly job and have it check for a successful run in the last
>>> day or whatever.
>>>
> You could of course trigger this from either the mount or hourly.
> Anytime you mount the drive or every hour systemd will run the service,
> and the service will see if it managed to do a backup/etc in the last
> day/week/whatever, and then run if appropriate.

This is actually how I setup several former cron-jobs as systemd timers,
here, based on an hourly check somewhat similar to what most crons
(including gentoo's for over 10 years now and mandrake's before that) are
actually setup to do to get around the fact that cron won't on-its-own
trigger after restart if the machine was down or cron not running when
the configured time for a job ran.

Here's how I have it setup here. Note that my initials are jed, and I
use them regularly as a prefix/suffix to denote custom configs (here,
systemd units) I've created myself, as opposed to those shipped in
whatever package.


/etc/systemd/system/jed.hourly.timer:

[Unit]
Description=JED Hourly timer

[Timer]
OnBootSec=10min
OnUnitActiveSec=1h
Unit=jed.hourly.target

[Install]
WantedBy=timers.target


timers.target is a systemd default target with the purpose of starting
all the various timers. The install entry says to install a symlink
pointing to jed.hourly.timer in the timers.target.wants subdir, which
will of course cause timers.target to start it.

The 10 minute OnBootSec setting says wait 10 minutes after boot before
activating this timer the first time. The 1h OnUnitActiveSec setting
says reactivate it every hour after its first activation. Thus, we have
an hourly timer, except that its first run is offset from boot by only 10
minutes, not a full hour.

Meanwhile, what it actually does when it runs is activate
jed.hourly.target -- that's the Unit= line.


/etc/systemd/system/jed.hourly.target:

[Unit]
Description=JED Hourly target
StopWhenUnneeded=yes


This one, like most targets, is pretty simple, its only purpose being a
synchronization point, activating a bunch of services and/or other units,
generally those with symlinks installed in the corresponding
jed.hourly.target.wants subdir, at once.

Note the StopWhenUnneeded=yes setting. The sole purpose of activating
this thing is to trigger all its wants deps to run, and as soon as it has
done that, it can stop again. This lets the target "rest" between hourly
triggerings.


Symlinks in /etc/systemd/jed.hourly.target.wants/:

jed.hourly.timestamp.service


That's it, just the one. With just it there it would have in fact been
just as easy for me to set jed.hourly.timer's
Unit=jed.hourly.timestamp.service, and omitted jed.hourly.target
entirely. However, using the target is MUCH more flexible, as it allows
me to add new services I want triggered hourly to the same target, as I
decide I want/need them.

If you're familiar with the usual cron setup, in particular, the usual
/etc/crond.hourly/ (or whatever it was, that's from memory as I replaced
my cronjobs with timers and don't even have a cron installed, these
days), that's EXACTLY the function /etc/systemd/jed.hourly.target.wants
ends up filling, with the minor exception being that as I set it up, it
triggers hourly, starting 10 minutes after boot, instead of hourly, at
some arbitrary minute of the hour. That actually suits my purposes
better than an arbitrary time of the hour would, but if people really
wanted more-cron-line specific minutes of the hour, that would be set
using OnCalendar= instead of the boot+10min and hourly thereafter, that I
used.


/etc/systemd/jed.hourly.timestamp.service:

[Unit]
Description=JED Hourly timestamp updater

[Service]
Type=oneshot
ExecStart=/etc/systemd/local-scripts/jed.hourly.timestamp

[Install]
WantedBy=jed.hourly.target


This service simply runs the script named in execstart, oneshot, meaning
it runs until its done, then stops. Which is what we want, since we're
triggering it once per hour via the timers above.

The install section simply tells systemd where to put that symlink
mentioned above, in the appropriate target.wants subdir, when the service
is "installed".


/etc/systemd/local-scripts/jed.hourly.timestamp:

#!/bin/bash

stampfile=/var/log/jed.hourly.day.stamp

# if stamp is old or doesn't exist, update stampfile and run...
doit(){
touch $stampfile
systemctl start jed.daily.target
exit
}

[[ -f stampfile ]] || doit

yesterday=$(date -d yesterday +"%Y%m%d%H%M")

stamp=$(date -r "$stampfile" +"%Y%m%d%H%M")

[[ $stamp ]] || doit

[[ $stamp -lt $yesterday ]] && doit

exit 0


This is where the custom magic happens and the real work gets done. If
you're familiar with the usual cronjob runscripts setup, this will look
similar. Basically, systemd timers, etc, magic above only sets up an
hourly systemd timer, not a daily, weekly, etc. This script actually
sets up a daily trigger, based on a daily timestamp that's checked every
hour to see if it has been 24 hours or longer since the last run, updated
if so, and the daily trigger triggered.

As I said, the idea is very similar to that used with a standard cronjob
runscripts setup, since that's exactly where I got it from. =:^) Like
the cronjob setup, if the system was down the hour the daily would have
otherwise triggered, this script ensures that it's triggered the next
time the hourly timer is run... which will normally be 10 minutes after
boot due to the 24 hours elapsing when the system was down, and the boot
+10min setting in that first unit, jed.hourly.timer, above.

OK, so what does this script trigger? systemctl start jed.daily.target

Again, I /could/ have setup a daily timer much like the hourly timer, and
handled it that way. Instead, I chose to use the hourly time to activate
a service to run this script, handling the daily mechanism that way.

(FWIW I put the stampfile itself in /var/log primarily because that's a
conveniently writable place to put it. My /, including much of /var, is
mounted read-only by default, while /var/log obviously must be writable.
And thought about from a particular viewpoint, that timestamp /is/ a log
in some fashion, since it effectively logs the last time the daily jobs
should have run.)

OK, we're almost there now. =:^) But tying up loose ends...


/etc/systemd/system/jed.daily.target:

[Unit]
Description=JED Daily Target
StopWhenUnneeded=yes


Pretty much identical to the hourly target as the functionality is the
same, just with a different name, reflecting the different timing.


Symlinks in /etc/systemd/system/jed.daily.target.wants:

jed.daily.logrotate.service.


For the moment that's it. I haven't needed weekly, monthly, etc,
scheduling, so I've not created it. But having done the hourly to daily
thing, I could easily copy and convert that to weekly or whatever,
triggered by the daily, just as daily is triggered by the hourly.

And to tie up the final loose end before I apply the above to the case of
this thread, as well as to supply a sample logrotate systemd service for
anyone else wanting to switch to systemd timer based triggering and get
rid of cron's triggering (while noting that the systemd way to do it
would be to use tmpfiles.d settings, but I still find logrotate useful
for doing actual log rotation, thus keeping those settings separate from
systemd's config)...


/etc/systemd/system/jed.daily.logrotate.service:

[Unit]
Description=JED daily logrotate

[Service]
Type=oneshot
Nice=10
ExecStart=/usr/sbin/logrotate --state /var/log/logrotate.state /etc/
logrotate.conf

[Install]
WantedBy=jed.daily.target


(Note the wrap of the execstart line...)

###################

OK, so how does all that apply to the case of this thread? =:^)

Simple enough. Where I threw in that jed.hourly.timestamp.service systemd
unit file (that is, symlinked into the hourly target.wants subdir) and
jed.hourly.timestamp script that it called, you'd throw in another
service, either in addition to the timestamp one I used, or if you don't
want to use my daily solution, in place of it.


The key thing to understand here is that once you've setup a service to
run a script you create yourself, you can have it do literally whatever
you want it too, just as you would with any other script -- it's NO
LONGER limited to the strict declarative style and options systemd
provides -- you're ONLY using systemd to /start/ it. =:^)

So... suppose you want it to check hourly to see if it can and should
trigger something else, but only run once a day... the timer and
timestamp-script-based framework I have above already does the hourly
check part, as well as the only running once a day part.

If you prefer that it check every 10 minutes, it's simple enough to
change that hourly thing to 10 minutes. If you like it hourly but want
it to ALWAYS be hourly, including not checking the first time until an
hour after boot, that's simple enough as well. Similarly, if you want
the final action to run only every two days, or twice a day, or
whatever. It's simple enough to change the timestamp mechanism to make
that happen.

Meanwhile, with the basic framework already there, it should also be
simple enough to plugin some conditional logic testing to see if the
partition device-files are showing up or not. If not, simply quit
without updating the timestamp and wait for the next hourly or whatever
check to roll around. If so, and the timestamp is also expired, then run
the scripted backup or whatever else you were wanting it to do.

... And of course you can rename them from jed.* to your own name of
choice, too. Jed.* is fine for my own usage, but it would look a bit
ridiculous, and could well defeat its site-specific-id purpose if someone
actually decided to ship it as part of some package, if that jed.* naming
pattern remained as installed out of my own control. But be sure to
change the names /in/ the files too, not just the names /of/ the files,
or systemd will be complaining about the stupid admin trying to give it
nonsensical unit files to run. =:^P

Also, one last caution. I chose to retype most of the above files
manually, getting back into what they did and how as I did so, instead of
copy/pasting them and then sitting there studying them to remember how
they worked. Not so boring that way, but there's possibly a few typos I
missed. They should be reasonably obvious and easy to fix, tho, if I did
miss some...

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Am Sun, 1 Mar 2015 14:13:53 -0500
schrieb Rich Freeman <rich0@gentoo.org>:

> On Sun, Mar 1, 2015 at 1:20 PM, Marc Joliet <marcec@gmx.de> wrote:
> >
> > Regardless: thoughts?
>
> I'd probably just do this:
> > Am Sun, 1 Mar 2015 08:34:19 -0500
> > schrieb Rich Freeman <rich0@gentoo.org>:
> >>
> >> The timer keeps running if you set the dependency on the service. So,
> >> next time the timer runs, it will try again. You might want to just
> >> set an hourly job and have it check for a successful run in the last
> >> day or whatever.
> >>
>
> You could of course trigger this from either the mount or hourly.
> Anytime you mount the drive or every hour systemd will run the
> service, and the service will see if it managed to do a backup/etc in
> the last day/week/whatever, and then run if appropriate.

As you might have noticed via my thread on gentoo-user, I am trying to solve the
underlying problem first before revisiting this.

Just as a summary for those not following gentoo-user: initially, the external
HDD is incorrectly detected as having 512 byte logical blocks. After
unplugging it and plugging it back in, it is detected as having 4096 byte
logical blocks, after which it can be mounted. See the thread here:
http://archives.gentoo.org/gentoo-user/message/5677e2044aba73c5ac046a2a634f801a.

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

Am Sun, 1 Mar 2015 19:20:02 +0100
schrieb Marc Joliet <marcec@gmx.de>:

[...]
> But actually, while putting off finishing this email, I came to the realisation
> that I could of course use WantedBy= in [Install], and following that idea I
> ended up with the following [Unit] and [Install] sections:
>
> [Unit]
> Description=Run hourly backups (timer)
> Requisite=media-MARCEC_BACKUP.mount
> BindsTo=media-MARCEC_BACKUP.mount
> After=media-MARCEC_BACKUP.mount
>
> [Install]
> WantedBy=timers.target
> WantedBy=media-MARCEC_BACKUP.mount
>
> So the mount point and the timer both depend on each other (with the mount unit
> starting first), so the mount tries to start the timer and vice versa, but only
> the timer fails if the mount point doesn't exist. And the BindsTo sees to it
> that the timer disappears if the mount does. Preliminary tests show that it
> works: unmounting with udiskie shows that the backup timer disappears, and it
> re-appears after mounting the file system again.
>
> I'll have to see what the behaviour is during a cold boot. The Requisite
> dependency on the mount point *should* make the Restart line in the
> corresponding service obsolete, since the WantedBy should make the timer start
> once the mount point shows up. I could probably alternatively use
> ConditionPathIsMountPoint instead, but I think I prefer the timer failing.
[...]

Just FYI: I undid that fairly quickly since BindsTo is a superset of Requires,
thus systemd waits for 1m30s for the mount point to show up. Ouch.

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

Am Mon, 2 Mar 2015 05:13:26 +0000 (UTC)
schrieb Duncan <1i5t5.duncan@cox.net>:

> Rich Freeman posted on Sun, 01 Mar 2015 14:13:53 -0500 as excerpted:
>
> > On Sun, Mar 1, 2015 at 1:20 PM, Marc Joliet <marcec@gmx.de> wrote:
> >>
> >> Regardless: thoughts?
> >
> > I'd probably just do this:
> >> Am Sun, 1 Mar 2015 08:34:19 -0500 schrieb Rich Freeman
> >> <rich0@gentoo.org>:
> >>>
> >>> The timer keeps running if you set the dependency on the service. So,
> >>> next time the timer runs, it will try again. You might want to just
> >>> set an hourly job and have it check for a successful run in the last
> >>> day or whatever.
> >>>
> > You could of course trigger this from either the mount or hourly.
> > Anytime you mount the drive or every hour systemd will run the service,
> > and the service will see if it managed to do a backup/etc in the last
> > day/week/whatever, and then run if appropriate.
>
> This is actually how I setup several former cron-jobs as systemd timers,
> here, based on an hourly check somewhat similar to what most crons
> (including gentoo's for over 10 years now and mandrake's before that) are
> actually setup to do to get around the fact that cron won't on-its-own
> trigger after restart if the machine was down or cron not running when
> the configured time for a job ran.
>
> Here's how I have it setup here. Note that my initials are jed, and I
> use them regularly as a prefix/suffix to denote custom configs (here,
> systemd units) I've created myself, as opposed to those shipped in
> whatever package.
>
[GIGASNIP thorough explanation ;) ]

I pretty much thought that's what Rich was alluding to, but thanks for showing
that it's not *that* much extra complication (and how one can use a target unit
for this). I never really looked at how these things are done by run-crons (and
similar).

Just for completeness: I use fcron instead of vixie-cron, so some of the stuff
systemd timers can do was already known to me. For example, in fcron, lines
can start with "@" to denote that they run relative to system startup (e.g, "@
5" for "every five minutes after boot). The "first" option specifies how long
to wait before starting an entry for the first time, analogous to "OnBootSec".

Anyway, like I mentioned before, I'll revisit this once I've solved the HDD
problem (or not, if it turns out to be a firmware issue).

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

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@gmx.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

Marc Joliet posted on Wed, 20 May 2015 10:01:13 +0200 as excerpted:

> 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.

I don't recall whether you mentioned whether you're running stable or
~arch, and I didn't see mention of the version of systemd you're running
now, but FWIW...

I'm ~arch, but am still on systemd-218 (-r3), while 219 is latest ~arch.
This is for two reasons you may find interesting, one of which pertains
to networkd and thus to the quoted bit, above:

Networkd: 219's networkd apparently breaks at least some (maybe static-IP-
only?) IPv4 only setups. There's a complaint about lack of IPv6 support
(duh! it's disabled on purpose as I don't use it, to avoid having to
worry about securing it!), and the interface is not brought up. The
upstream bug (filed by someone else, with another report as well before
mine, making me the third person reporting being affected) and gentoo bug
(mine) are:

https://bugs.freedesktop.org/show_bug.cgi?id=90103

https://bugs.gentoo.org/show_bug.cgi?id=548380

So far no comment from upstream, but at least I know others are seeing it
too. The original reporter had disabled IPv6 with a kernel boot
parameter, which hints at a more mainstream distro with a prebuilt binary
kernel and modules shipped, while I have CONFIG_IPV6 unset in my of
course custom-configured-and-built kernel here on gentoo.

So contrary to your wondering, IPv4 support in the present and near-
future may actually be a rather more pressing concern than IPv6 in the
longer-term future. =:^(

Hopefully that bug will be fixed for 220, as broken network connectivity
is rather critical, but the lack of even a developer comment in the month
since filing isn't particularly encouraging. But I have a static IP
assigned and since I switched to systemd a version or two before the
introduction of networkd, and was using a simple custom network.service
unit at that time (not too difficult and easily enough googled, with a
static IP), I figure worst-case, I simply dig that up again... Tho I
really can't imagine them leaving IPv4 broken, even if it's only for
people who don't have IPv6 enabled.

One reporter did say he was able to bring up his network manually. I
didn't try that; I simply reverted to 218 and have masked succeeding 219+
versions after trying them and not finding a fix. But that does indicate
that my alternative network.service approach should work.


Meanwhile, the second bug affecting me in systemd-219...

Btrfs and tmpfiles.d: systemd-219 was supposed to add better btrfs
support, since btrfs and in particular its subvolume support figures so
strongly in the systemd "big picture" plan. Unfortunately, systemd's
first rollout of btrfs specific features has a few bugs, the one I ran
across involving the new tmpfiles.d btrfs specific features.

In 219, systemd/tmpfiles.d introduces support for a new type key-letter,
"v". On "legacy" filesystems, "v" is supposed to act just like "d",
create the given directory if it doesn't exist yet. On btrfs, however,
"v" creates a subvolume at that location instead, relying on the fact
that btrfs subvolumes normally function much like directories, except
with a few btrfs-specific features that normal directories don't have.

And 219 ships a couple tmpfiles.d dropin files that make use of "v" in
place of "d", creating subvolumes on new btrfs where they (or
directories) don't already exist, while it creates directories on
"legacy" filesystems.

The problem? An attempted directory-create of an existing directory, on
a read-only filesystem (my / is kept read-only by default, I only mount
it read-write to update it), succeeds. An attempted subvolume create,
where there's an existing (normal) directory, on a read-only (btrfs)
filesystem, fails.

With that failure, systemd-tmpfiles-setup.service, run at boot (pulled in
by sysinit.target), fails.

https://bugs.freedesktop.org/show_bug.cgi?id=90281

Status: resolved/fixed, with the git commit listed/linked, less than two
weeks after filing. =:^) Tho of course a release with the fix hasn't yet
been made, and a fix in under two weeks there without even a comment in
over a month on the IPv4-only bug doesn't bode so well for the latter.
=:^(

Of course a quick edit of the affected tmpfiles.d files, turning "v" to
"d" where appropriate, would work around this issue, and now there's a
patch-fix I could apply pretty easily as well, but I haven't bothered due
to the above networkd bug. I've simply masked each new 219+ ebuild after
trying it to see if the two bugs are fixed yet, and thus remain on 218
for now.

So while 218 worked well for me, 219 has been rough and remains masked,
here. We'll see how 220 turns out, when it's released and a gentoo ebuild
for it becomes available...

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Wed, May 20, 2015 at 6:44 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>
> Status: resolved/fixed, with the git commit listed/linked, less than two
> weeks after filing. =:^) Tho of course a release with the fix hasn't yet
> been made, and a fix in under two weeks there without even a comment in
> over a month on the IPv4-only bug doesn't bode so well for the latter.

I don't think systemd has any kind of stable release strategy, and I
think that is going to become a problem. There are a lot of cases
where there are dramatic behavior changes or big feature changes, and
they're mixed in with fixes.

So, you can't use 219 because it lacks fixes to some bugs.
Systemd-220 will probably fix those, and change who-knows-what else.

They're relying on distros to backport fixes for them, essentially.
Gentoo has been doing just that, but this just means that Gentoo's
stable version of systemd is different from Debian or Arch's, and so
on.

For such a critical piece of software they really ought to start some
fixes branches with minor releases. They don't necessarily need to
have 5-year LTS releases (though I'm sure they'd be appreciated
considering the nature of the software), but having some minor
releases for the last major version or two certainly wouldn't hurt.

--
Rich

Rich Freeman posted on Wed, 20 May 2015 07:22:39 -0400 as excerpted:

> I don't think systemd has any kind of stable release strategy, and I
> think that is going to become a problem. There are a lot of cases where
> there are dramatic behavior changes or big feature changes, and they're
> mixed in with fixes.

You are AFAIK correct, and I believe it's deliberate, as it is known to
be with the binary journal format, for instance.

That bothered me too, so much so that I had originally thought that while
I'd eventually switch to systemd, I'd sit out until the featuritis slowed
down and the product stabilized to some degree... tho as some would argue
happened to pulse-audio (I'm on the sidelines on that one as I've never
had it installed, here, as I've simply never found I needed it strongly
enough to do the research necessary to be comfortable installing and
properly configuring it), that may not happen until Lenart loses interest
and finds some other project to disrupt the Linux ecosystem with.

But at some point I realized that I was on live-git openrc-9999 in
ordered to properly follow individual git commits (I had problems earlier
when I had been on standard ~arch, because the changelog wasn't detailed
enough to properly trace any problems I had and it was thus much more
work than it should have been, and than it was once I switched to live-
git openrc), and regardless of how unstable systemd's releases turned out
to be, at least they were releases... and if I had to do so for similar
reasons, I could go live-git systemd-9999 as well.

Between that (#1), and once I started experimenting (when I had both
installed for a time and could switch between them from grub2 with init=
on the kernel commandline), (2) being /very/ impressed with the level of
documentation systemd has in general, (3) being /very/ impressed with
what it did to boot times, even compared to openrc's parallel-init
option, and (4) finding once I actually got into it that I actually liked
systemd's declarative style config default, in part because despite a
declarative config style default, there was still the flexibility to call
scripts from a unit if it was actually found to be necessary, I decided
to keep systemd, and ultimately, to unmerge openrc, as I was simply no
longer keeping up with its config, such that even if I /did/ find I
needed it, I'd be afraid to run it for fear of what running untested
updates would now do to the system. (And anyway, I can always boot to
the emergency or rescue targets directly, just as one would previously
boot to initlevel 1/single, and failing that, I could still boot
init=/bin/bash, which in fact I have a grub2 menu entry for.)

So while systemd's failure to have a decent stable/unstable releases
policy, as well as the continued featuritis, continues to bother me,
because gentoo /does/ keep older versions around for awhile (and because
being gentoo, if old versions are removed from the tree, I can always
dredge the old version from the installed package database or from my
binpkgs, and put it in my overlay), it's not the problem it might
otherwise be. In fact, this whole incident actually supports that...
because it's gentoo, I actually /have/ 218 (and older versions) still
available to me, despite the fact that 219 is current-latest ~arch.

So in reality systemd hasn't been any worse than openrc was for me, and
in a number of ways (including documented config, real speed, cross-
distro standardization so google's more effective, /and/ not signficantly
more and possibly less show-stopping bugs than openrc), it has actually
been better, /despite/ the lack of a coherent stable/unstable release
plan.

Which doesn't mean it wouldn't be better still, if they'd adopt such a
coherent stable/unstable release plan... nor does it mean I won't at some
point decide I need to be on live-git to get better commit-level
granularity on bugs when I see 'em, the better to track them down and
exterminate them, just as I was for openrc.

There are, however, two other concerns I have about systemd, one in a
purely practical openrc context, one in a much more general "system
knowledge bootstrapping ability" context:

1) (openrc context): Given my experience running live-git openrc, and
the fact that judging from the bugs filed against it, at least during
part of the time I ran it, I was the only one (beyond the openrc devs
themselves) doing so, or at least the only one doing so and filing
bugs... my having switched to systemd certainly could not have had a good
effect on openrc pre-release live-git testing and thus bug squashing
before they ever hit a release at all.

Oh, well... it's an "SEP", "somebody else's problem", now... (And to be
fair, it /did/ appear that toward the end, there was an uptick in openrc
live-git bugs filed by others too, so others were evidently running it by
the time I quit. But still, it was only a handful, say five or so, in
which case a loss of just one is a loss of 20% of your pre-release
testing coverage!)

2) (larger philosophical/practical context): Back in 2001/2002 when I
got serious about and switched to Linux, I read a couple books, but I
actually got my practical hands-on shell experience by rewriting several
of the Mandrake init-scripts, including the core sysinitrc (or whatever
it was called, that was nearly a decade and a half again, after all!).

I can't believe I was the only one.

As a result, one of the nagging fears I have about systemd, despite all
the improvements I believe it does bring, is that this early gateway to
practical shell knowledge and experience is literally disappearing before
our eyes, and people trying to become Linux CLI/shell literate today are
going to have a much harder time than people of my Linux generation did,
because there's far less shell scripting actually available for them to
work on, and it's far less prominently placed, making it much harder to
simply stumble upon, as I basically did.

Between that, and the transparency of a shell-based system init that
they're losing as well, today's newbies may well find it far harder to
get in as deeply, as quickly, as I did, and the wonders of system bootup
may as a result remain as practically opaque to them as an MS Windows
boot.

That would be, and is, a sad thing. But of course I know the Linux boot
process pretty well now, the more so since I now have the experience of a
sysv/shell-script-based init from multiple distros, AND the far different
systemd-based init, too. And sad philosophical/practical concern or not,
being in the knowledge clase now, it's not going to keep me away from the
faster and more efficiently configured systemd boot. =:^\

(Meanwhile, FWIW, back in the day I knew my way around an MS Windows boot
too, and in the day hacked solutions to a couple MS Windows driver
issues, etc. But never in the decade I was on MS, both DOS and Windows,
did I know its boot process to the degree that I knew that of Mandrake
Linux, just a year after switching, and that too was just scratching the
surface, compared to what I knew six months after installing Gentoo from
stage-1, tho of course in the decade since I've learned far more still.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Am Wed, 20 May 2015 10:44:58 +0000 (UTC)
schrieb Duncan <1i5t5.duncan@cox.net>:

> Marc Joliet posted on Wed, 20 May 2015 10:01:13 +0200 as excerpted:
>
> > 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.
>
> I don't recall whether you mentioned whether you're running stable or
> ~arch, and I didn't see mention of the version of systemd you're running
> now, but FWIW...

I'm arch, so running systemd-218.

> I'm ~arch, but am still on systemd-218 (-r3), while 219 is latest ~arch.
> This is for two reasons you may find interesting, one of which pertains
> to networkd and thus to the quoted bit, above:
>
[Snip two bug descriptions]

Damn, that sounds bad. However, I'm running stable, so won't be affected.

I do agree with both you and Rich, though, that systemd really ought to have a
stable branch. Their release workflow appears to me to be much like that of
the linux kernel, only without the stable trees. Honestly, I would be
surprised if they didn't have the developer resources to provide this.

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

Am Thu, 21 May 2015 09:36:28 +0000 (UTC)
schrieb Duncan <1i5t5.duncan@cox.net>:

> Rich Freeman posted on Wed, 20 May 2015 07:22:39 -0400 as excerpted:
[...]
> So while systemd's failure to have a decent stable/unstable releases
> policy, as well as the continued featuritis, continues to bother me,
> because gentoo /does/ keep older versions around for awhile (and because
> being gentoo, if old versions are removed from the tree, I can always
> dredge the old version from the installed package database or from my
> binpkgs, and put it in my overlay), it's not the problem it might
> otherwise be. In fact, this whole incident actually supports that...
> because it's gentoo, I actually /have/ 218 (and older versions) still
> available to me, despite the fact that 219 is current-latest ~arch.
>
> So in reality systemd hasn't been any worse than openrc was for me, and
> in a number of ways (including documented config, real speed, cross-
> distro standardization so google's more effective, /and/ not signficantly
> more and possibly less show-stopping bugs than openrc), it has actually
> been better, /despite/ the lack of a coherent stable/unstable release
> plan.

I agree, though I've only used two systemd releases till now (216 and 218).

[...]
> 2) (larger philosophical/practical context): Back in 2001/2002 when I
> got serious about and switched to Linux, I read a couple books, but I
> actually got my practical hands-on shell experience by rewriting several
> of the Mandrake init-scripts, including the core sysinitrc (or whatever
> it was called, that was nearly a decade and a half again, after all!).
>
> I can't believe I was the only one.
>
> As a result, one of the nagging fears I have about systemd, despite all
> the improvements I believe it does bring, is that this early gateway to
> practical shell knowledge and experience is literally disappearing before
> our eyes, and people trying to become Linux CLI/shell literate today are
> going to have a much harder time than people of my Linux generation did,
> because there's far less shell scripting actually available for them to
> work on, and it's far less prominently placed, making it much harder to
> simply stumble upon, as I basically did.

I don't know... I learned basically all of my shell scripting from trying to
solve problems I was seeing and simply because I wanted to try out something.
I didn't touch init scripts until I had to (for work), and by then OpenRC
supported its own declarative style (see openrc-run(8)), so the amount of
shell *scripting* involved was minimal (and then we switched that computer to
Fedora, and hence to systemd).

Anyway, it seems to me that "scratching your own itch" was the more basic
motivation you had for learning shell scripting via init scripts.

> Between that, and the transparency of a shell-based system init that
> they're losing as well, today's newbies may well find it far harder to
> get in as deeply, as quickly, as I did, and the wonders of system bootup
> may as a result remain as practically opaque to them as an MS Windows
> boot.

I would argue that in this case people at least have the source code. But more
importantly, the *principal* of what happens is still not very different:
commands get executed with particular arguments and a particular environment.
For me, personally, the latter is the least transparent, I suppose, but then
again, "systemd show" shows you all the properties of a unit, which (in
combination with the systemd documentation) gives you pretty much all of the
information you need to learn what *exactly* is going on.

(Of course, this is just me trying to show an alternative view point, not
trying to make it look like this isn't a potential issue, even though from my
perspective it isn't.)

[...]

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

Rich Freeman posted on Wed, 20 May 2015 07:22:39 -0400 as excerpted:

> So, you can't use 219 because it lacks fixes to some bugs. Systemd-220
> will probably fix those, and change who-knows-what else.

FWIW, systemd-220 is out upstream now, but there's not an in-tree gentoo
ebuild for it yet (well, as of a bit under a day ago when I last updated).

Here's a link to the article where I found out about it (it was on the
lxer feed I subscribe to via claws-mail's feed-reader addon, but that was
just a redirect to the below article, which I'm linking directly instead):

http://www.itrunsonlinux.com/desktopos/systemd-v220-released/

The article pastes in the 220 changelog, apparently verbatim (minus the
"contributors to this version" paragraph systemd normally puts at the end
of each version's changelog).

That should have the patch for my btrfs tmpfiles.d "v" vs. "d" bug, as it
was committed before the 220 release, tho I've obviously not tested it
yet.

And while there's still no developer comment on the upstream IPv4 bug I'm
CCed on, and as stated, no gentoo 220 yet, there's a patch from upstream
for me to try on the gentoo IPv4 only bug I filed. Presumably, if it's
from upstream, that should be in 220 as well, and if it works...

Off for a 1 AM sync and some testing, now... if I don't get too sleepy to
think straight first. Still 219 with those patches applied if 220 isn't
in-tree yet when I sync. I'll post back when I have some results.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Am Thu, 21 May 2015 09:36:28 +0000 (UTC)
schrieb Duncan <1i5t5.duncan@cox.net>:

[...]
> I decided
> to keep systemd, and ultimately, to unmerge openrc
[...]

I forgot to ask about this: how did you go about doing that? I'm still waiting
for the following two bugs to be resolved:

https://bugs.gentoo.org/show_bug.cgi?id=504116
https://bugs.gentoo.org/show_bug.cgi?id=511500

Do you have none of the affected packages installed, or...?

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

Am Sat, 23 May 2015 10:49:07 +0200
schrieb Marc Joliet <marcec@gmx.de>:

> Am Thu, 21 May 2015 09:36:28 +0000 (UTC)
> schrieb Duncan <1i5t5.duncan@cox.net>:
>
> [...]
> > I decided
> > to keep systemd, and ultimately, to unmerge openrc
> [...]
>
> I forgot to ask about this: how did you go about doing that? I'm still waiting
> for the following two bugs to be resolved:
>
> https://bugs.gentoo.org/show_bug.cgi?id=504116
> https://bugs.gentoo.org/show_bug.cgi?id=511500
>
> Do you have none of the affected packages installed, or...?

Partially answering this myself: you must be using gcc-config-1.8-r1, and have
none of the other still affected packages installed (e.g., java, hence no
java-config-wrapper).

Following bug #549508, I could put java-config-wrapper in package.provided and
unmask gcc-config-1.8-r1. Then I should be able to put openrc in
package.provided and finally depclean it. This should work as a temporary
solution until bugs #504116 and #511500 are resolved.

Does that sound sane?

The only two scary looking bugs I found on gcc-config are 547586 and 547962.
Bug #547586 is apparently completely benign (whitespace differences in "make
check" output), whereas bug #547962 caused gcc-config-1.8-r1 to be hard masked.
However, the underlying bug in gentoo-functions has apparently been fixed [0]
(according to its ChangeLog this was done in version 0.8, which is arch), so it
seems to me that the hard mask can be lifted.

[0] https://bugs.gentoo.org/show_bug.cgi?id=547962#c5

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

Marc Joliet posted on Sat, 23 May 2015 10:49:07 +0200 as excerpted:

> Am Thu, 21 May 2015 09:36:28 +0000 (UTC)
> schrieb Duncan <1i5t5.duncan@cox.net>:
>
> [...]
>> I decided to keep systemd, and ultimately, to unmerge openrc
> [...]
>
> I forgot to ask about this: how did you go about doing that? I'm still
> waiting for the following two bugs to be resolved:
>
> https://bugs.gentoo.org/show_bug.cgi?id=504116
> https://bugs.gentoo.org/show_bug.cgi?id=511500
>
> Do you have none of the affected packages installed, or...?

Good question!

Answer: "or..." Very definitely "or...", as you will see below. =:^)

functions.sh is easy enough to fix, if you're willing to create a single
symlink, manually.

$ equery belongs functions.sh
sys-apps/gentoo-functions-0.10 (/lib/gentoo/functions.sh)

The package gentoo-functions is /supposed/ to replace a couple gentoo-
specific files formerly found in openrc, thereby making openrc optional
for those using other init systems (like systemd). One of those files is
functions.sh[1].

But the old /etc/init.d/functions.sh location was hardcoded into a lot of
gentoo utilities over the years, some of which don't get updated very
often especially for stable, and the new /lib/gentoo/functions.sh
location, while more appropriate, still can't be found by some of these
apps. That's what the first bug is about.

Simple enough fix -- ensure the gentoo-functions package is installed (it
should be as it's a dependency of enough stuff, including current glibc
packages!), and do a manual symlink from the old location to the new
one. Viola! No openrc needed for THAT any more, and because the new
location's file is still packaged, any updates to it should occur
normally and will be simply picked up by anything still using the old
location, since it's a symlink! =:^)


The other bug deals with the base-profile placing openrc in @system,
since until the functions.sh bug is finally resolved, it really is a
system dependency of a sort as it provides the old-location functions.sh,
even if you're using something else as init system.

First let me caution that the below specific action is rather "out there"
and cannot be expected to be supported by gentoo, tho that said, it
hasn't caused /me/ any issues, running it for I'd guess a couple years
now... and for sufficiently experienced gentooers it's not really as
unreasonable as it might sound...

Warning out of the way...

What I've done here, actually quite some time before I switched to
systemd, is negate my entire @system, so it's entirely empty. I actually
get a pretty dire looking warning about the empty @system when I run
emerge --depclean, but when I negated @system, I did so one package at a
time, and added packages to my @world list as necessary, where I really
did need (or want) them and nothing else depended on them.

Of course this only works for gentooers with enough experience to tell
what @system packages that would be removed when it's empty, are really
needed after all. I obviously had the required experience as I've been
running @system-less for quite some time now, but it's obviously not for
everyone.

Obviously for things like virtual/editor, I already had my editor of
choice in @world, and thus could simply negate the virtual entirely. In
other cases, something else in @world has a dep on the @system package,
so I didn't need to put that package in @world when I took it out of
@system, at all.

And things like busybox... aren't really necessary at all. In fact, I've
actually never had it installed in the over a decade I've been on gentoo,
as for whatever reason it wouldn't build when I originally installed, so
I temporarily bypassed it as I knew it was an emergency thing, and that
temporary thing just got longer and longer, until I decided I didn't need
it at all.

Instead of something like busybox, I keep (at least) two root partitions
available, my working copy and my backup. The two partitions are the
same size, and contain pretty much everything installed by portage (with
a small exception for some state files in /var, since I keep root mounted
read-only by default and they need to be writable). Periodically, when
the system seems to be stable, I'll blow away the backup root with a
fresh mkfs, and then copy everything back onto it, creating a new backup
that's a copy of the same working system setup that I'm using at that
moment. Of course a good sysadmin never considers a backup done until
it's tested, so then I test-boot to it to ensure it works.

Meanwhile, in grub2, I have a menu entry that sets a variable used in the
root= entry on the kernel commandline. By default, that var points at
the working root, but if I invoke that menu entry, it changes the var to
point at the backup root instead, thus letting me boot either working or
backup root, by just selecting an entry in the grub2 menu before I load
the kernel, if I want to boot the backup.

So I don't need something like busybox, because in the event I screw up
the working root and can't boot it, I can boot the backup, which is a
copy of the very same working config I was using when I took it. So
while it might be a bit old if I haven't updated the backup in awhile,
it's tested to boot properly, when I made the backup.

And actually, my working system and primary backup are on dual SSDs in
btrfs raid1 mode, with a partition each for the working and primary
backup, and I have another backup on my old spinning rust drive as well,
on reiserfs in case btrfs bugs out on me and the working and primary
backup are thus unusable, with yet another grub menu entry to set it up
for boot. Meanwhile, I have a separate grub installation and separate
/boot, on all three drives, so as long as all three drives don't go out
at once...

And of course ssh, still part of @system altho people running local
systems really don't need it as part of @system, works just fine in
@world, if you actually do want/need it.

Just some examples...

OK, but how does this @system negation actually /work/?

Simple enough. The portage (5) manpage has the documentation, but
briefly, profiles dirs can have packages files. In these files are
entries like this:

*sys-apps/busybox
*>=sys-apps/baselayout-2

The * indicates that this package should be added to the @system set.
(In new enough portage and profiles there's also @profile set entries,
see the manpage, but they haven't bothered me yet, here.)

And critically, in cascading profiles, which pretty much all profiles are
these days, -* indicates a *REMOVAL* from the @system set.

Two additional missing pieces:

/etc/portage/profile/packages... is where you put your installation-
specific things, and where I put my negations.

Note the versioned baselayout-2 entry above. These versioned entries
must be negated with the identical version, or they don't end up
negated. So that baselayout entry would be negated like this:

-*>=sys-apps/baselayout-2


As I said, with a clean emerge --depclean --pretend, I negated one or a
small handful at a time, then did an emerge --depclean --pretend and
noted what the new @system removals had now cleared for removal as
nothing else depended on them. Some, such as virtual/editor, I already
had an appropriate editor in @world for and thus removal of the virtual
was fine. Others, such as sys-apps/busybox, I never had installed in the
first place. Others, including sys-apps/man-pages, I added to @world,
and still others, including sys-fs/e2fsprogs, were deps of something else
and thus didn't need a specific @world entry to keep depclean from
removing them.

And of course, the two that triggered the subthread, openrc and
baselayout. Openrc I originally kept in @world as I was using it for init
when I did the @system negation. Since it was then in @world, not in
@system, when I switched to systemd for init, it was easy enough to
unmerge it, just as I would anything else in @world.

Meanwhile, systemd itself depends on baselayout, and I'd guess openrc
does as well altho I don't remember for sure and am lazy to look ATM, so
it stays on the system even tho it's not in @system any longer.


Finally, one additional thing to note about @system, that's different
when you don't have it. If you try to unmerge a package in @system, you
get a dire warning. Obviously, if your @system is empty and the same
package is simply listed in @world or a dep of something in @world, you
won't get that same kind of dire warning trying to unmerge it. For
experienced gentooers that should be no big deal, as they wouldn't think
of trying to unmerge really critical stuff like glibc anyway. But for
less experienced gentooers, those dire warnings might save their *** once
in awhile, making them useful to have. If you're at all unsure whether
you need such "safety railings", emptying @system entirely probably isn't
something you should be considering.


But, just because you aren't emptying @system entirely, doesn't mean you
can't negate specific @system package entries, if you're sure you don't
need them. For systemd users who don't want/need the fallback to openrc
in case systemd fails to boot, or where the openrc config is getting
dangerously outdated due to lack of use such that even if systemd breaks,
they'd be afraid to simply set init to run openrc instead, lest it break
their system further with an unconfigured and untested boot, and who have
or will take care of that /etc/init.d/functions.sh file via manual
symlink, openrc may well be one such entry to consider negating.


....

So you see why I said "or..." DEFINITELY "or...", above! =:^)

---
[1] gentoo-functions file replacements: In addition to functions.sh, the
other is consoletype, executable and manpage, see the results of equery
files gentoo-functions.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Am Sat, 23 May 2015 10:41:03 +0000 (UTC)
schrieb Duncan <1i5t5.duncan@cox.net>:

> Marc Joliet posted on Sat, 23 May 2015 10:49:07 +0200 as excerpted:
>
> > Am Thu, 21 May 2015 09:36:28 +0000 (UTC)
> > schrieb Duncan <1i5t5.duncan@cox.net>:
> >
> > [...]
> >> I decided to keep systemd, and ultimately, to unmerge openrc
> > [...]
> >
> > I forgot to ask about this: how did you go about doing that? I'm still
> > waiting for the following two bugs to be resolved:
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=504116
> > https://bugs.gentoo.org/show_bug.cgi?id=511500
> >
> > Do you have none of the affected packages installed, or...?
>
> Good question!
>
> Answer: "or..." Very definitely "or...", as you will see below. =:^)
>
> functions.sh is easy enough to fix, if you're willing to create a single
> symlink, manually.
>
> $ equery belongs functions.sh
> sys-apps/gentoo-functions-0.10 (/lib/gentoo/functions.sh)
>
> The package gentoo-functions is /supposed/ to replace a couple gentoo-
> specific files formerly found in openrc, thereby making openrc optional
> for those using other init systems (like systemd). One of those files is
> functions.sh[1].
>
> But the old /etc/init.d/functions.sh location was hardcoded into a lot of
> gentoo utilities over the years, some of which don't get updated very
> often especially for stable, and the new /lib/gentoo/functions.sh
> location, while more appropriate, still can't be found by some of these
> apps. That's what the first bug is about.
>
> Simple enough fix -- ensure the gentoo-functions package is installed (it
> should be as it's a dependency of enough stuff, including current glibc
> packages!), and do a manual symlink from the old location to the new
> one. Viola! No openrc needed for THAT any more, and because the new
> location's file is still packaged, any updates to it should occur
> normally and will be simply picked up by anything still using the old
> location, since it's a symlink! =:^)
[...]

That is certainly an interesting approach, since it avoids any upgrades. Then
I would only have to deal with openrc.

[snip empty @system approach]

Wow, that's certainly an interesting approach! It's definitely not for me,
though. While I appreciate the control Gentoo gives me, I don't need *that*
kind of control.

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

On Sat, May 23, 2015 at 7:11 AM, Marc Joliet <marcec@gmx.de> wrote:
> [snip empty @system approach]
>
> Wow, that's certainly an interesting approach! It's definitely not for me,
> though. While I appreciate the control Gentoo gives me, I don't need *that*
> kind of control.
>

I'd actually like to see Gentoo evolve until we reach a point where
this sort of thing is easy to do safely. Right now @system is a
mish-mash of a bunch of stuff and it is hard to pick out stuff like
openssh which is trivially removable from stuff like openrc which has
surprising reverse deps from stuff like glibc which obviously isn't
going anywhere anytime soon.

I'd really like to see a few virtuals created (perhaps nesting) that
chop this up into categories like recommend-default packages, stuff
required for POSIX, and so on. We can still give users a good default
experience, and we can still avoid having ebuilds having to list out a
laundry-list of deps, but we can also do things like allow more
parallel-building and make it easier to remove stuff.

--
Rich

Rich Freeman posted on Sat, 23 May 2015 07:37:26 -0400 as excerpted:

> I'd actually like to see Gentoo evolve until we reach a point where this
> sort of thing is easy to do safely. Right now @system is a mish-mash of
> a bunch of stuff and it is hard to pick out stuff like openssh which is
> trivially removable from stuff like openrc which has surprising reverse
> deps from stuff like glibc which obviously isn't going anywhere anytime
> soon.
>
> I'd really like to see a few virtuals created (perhaps nesting) that
> chop this up into categories like recommend-default packages, stuff
> required for POSIX, and so on. We can still give users a good default
> experience, and we can still avoid having ebuilds having to list out a
> laundry-list of deps, but we can also do things like allow more
> parallel-building and make it easier to remove stuff.

What about the new @profile vs @system stuff? I don't believe I've seen
anything move to @profile yet, tho I'm not /exactly/ sure what sort of
indication I'd get, but in theory at least, @profile was supposed to at
least avoid the parallel-build blockages that @system does for safety.

Anything practical come of the @profile/@system split yet? It didn't
turn out to be a bad solution to the problem did it? Other opinions and/
or experience on/with it?

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Duncan posted on Sat, 23 May 2015 08:17:59 +0000 as excerpted:

> Off for a 1 AM sync and some testing, now... if I don't get too sleepy
> to think straight first. Still 219 with those patches applied if 220
> isn't in-tree yet when I sync. I'll post back when I have some results.

Well, back with a mixed report... still on 219_p112 as 220 still hadn't
made it to the tree.

Upstream's patch for the tmpfiles/subvolumes/dirs thing worked perfect.
=:^)

The gentoo-bug proposed patch to get IPv4-only working again... not so
much. It addressed one complaint in the log, but that wasn't the major
problem, apparently, and networkd still doesn't bring up the network
properly.

But, while I was testing, I tested something that another poster had
noted on the upstream IPv4 bug -- networkd appears to be configuring the
interface, just not bringing it up. So a simple ifconfig <iface> up
(what I used, or equivalent IP command, which is what he used) brings the
interface up, configured as it should be. =:^)


Between the two, I think I'll stick with 219_p112 instead of reverting
back to 218-r3, for now. The tmpfiles.d thing is fixed by the upstream
patch I dropped into /etc/portage/patches/sys-apps/systemd before the
rebuild, and I can do a manual ifconfig up after reboot for now, or setup
a quick service to automate it if I get tired of doing the manual ifconfig
thing.

So mixed report, but there's progress, and a workaround for the remaining
issue, so 219_p112 with additional patches and a manual workaround it is,
for now. =:^/

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Am Sat, 23 May 2015 13:11:56 +0200
schrieb Marc Joliet <marcec@gmx.de>:

> Am Sat, 23 May 2015 10:41:03 +0000 (UTC)
> schrieb Duncan <1i5t5.duncan@cox.net>:
>
> > Marc Joliet posted on Sat, 23 May 2015 10:49:07 +0200 as excerpted:
> >
> > > Am Thu, 21 May 2015 09:36:28 +0000 (UTC)
> > > schrieb Duncan <1i5t5.duncan@cox.net>:
> > >
> > > [...]
> > >> I decided to keep systemd, and ultimately, to unmerge openrc
> > > [...]
> > >
> > > I forgot to ask about this: how did you go about doing that? I'm still
> > > waiting for the following two bugs to be resolved:
> > >
> > > https://bugs.gentoo.org/show_bug.cgi?id=504116
> > > https://bugs.gentoo.org/show_bug.cgi?id=511500
> > >
> > > Do you have none of the affected packages installed, or...?
> >
> > Good question!
> >
> > Answer: "or..." Very definitely "or...", as you will see below. =:^)
> >
> > functions.sh is easy enough to fix, if you're willing to create a single
> > symlink, manually.
> >
> > $ equery belongs functions.sh
> > sys-apps/gentoo-functions-0.10 (/lib/gentoo/functions.sh)
> >
> > The package gentoo-functions is /supposed/ to replace a couple gentoo-
> > specific files formerly found in openrc, thereby making openrc optional
> > for those using other init systems (like systemd). One of those files is
> > functions.sh[1].
> >
> > But the old /etc/init.d/functions.sh location was hardcoded into a lot of
> > gentoo utilities over the years, some of which don't get updated very
> > often especially for stable, and the new /lib/gentoo/functions.sh
> > location, while more appropriate, still can't be found by some of these
> > apps. That's what the first bug is about.
> >
> > Simple enough fix -- ensure the gentoo-functions package is installed (it
> > should be as it's a dependency of enough stuff, including current glibc
> > packages!), and do a manual symlink from the old location to the new
> > one. Viola! No openrc needed for THAT any more, and because the new
> > location's file is still packaged, any updates to it should occur
> > normally and will be simply picked up by anything still using the old
> > location, since it's a symlink! =:^)
> [...]
>
> That is certainly an interesting approach, since it avoids any upgrades. Then
> I would only have to deal with openrc.
>
> [snip empty @system approach]
>
> Wow, that's certainly an interesting approach! It's definitely not for me,
> though. While I appreciate the control Gentoo gives me, I don't need *that*
> kind of control.

Well, I did end up doing this:

% cat /etc/portage/profile/packages
-*sys-apps/openrc

and creating the symlink as suggested.

I also added java-config-wrapper to package.provided as I originally suggested,
following the declaration of obsolescence in bug #549508.

So far everything seems to be working fine (i.e., gcc-config and
java-config-2 both work).

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