Comment # 1 on bug 970268 from Stefan Dirsch

Stefan Dirsch:
Hmm. Don't know how to reproduce that issue on SLED12. I removed all fglrx.ko
files below /lib/modules (well, there was only one), shut down the machine
hard. Then booted into runlevel 3. When finished, fglrx.ko has been created
again. Apparently during boot process. /var/log appears to be a btrfs subvolume
on that machine, yes.

Reporter:
If it is a plain SLED12 never seen a rollback, it will, as written, of course
work.
You need a fresh installation of SLES12 SP1/SLED12 SP1 or you need to do a
rollback of SLES12/SLED12.
But I cannot say, if this is the only requirement, since I don't now and
understand why the init script cannot write to /var/log in this situation.

To be more precise: boot.fglrxrebuild is running before the rest of the
filesystem is mounted, /var/log is not yet mounted. 
But I don't understand the "Permission denied", if the root filesystem is still
read-only, it should be a read-only filesystem error message?

Stefan Dirsch:
I don't see how this is related to a rollback. It's an old fashioned
/etc/init.d/boot.<something> script, which rebuilds the kernel module if there
isn't an appropriate one available for the running kernel. This usually happens
when the kernel has been updated and machine got rebooted. It may also be
triggered by a rollback (kernel downgrade?). The script creates a logfile,
which is also parsed for errors, etc. You can easily force this rebuild by
removing the module and reboot the machine, which is what I did and worked for
me.

Reporter:
(In reply to Stefan Dirsch from comment #4)
> I don't see how this is related to a rollback. It's an old fashioned
> /etc/init.d/boot.<something> script, which rebuilds the kernel module if
> there isn't an appropriate one available for the running kernel. This
> usually happens when the kernel has been updated and machine got rebooted.
Yes, because you are still using your plain vanilla SLED12, where this
directory will be auto-mounted by btrfs itself. This is not done in case of a
rollback or if you do a fresh SLE12 SP1 installation. In this case, the
directory is mounted by the standard startup scripts. And this scripts are
running on my machine after boot.fglrxrebuild runs.

> You can easily
> force this rebuild by removing the module and reboot the machine, which is
> what I did and worked for me.
And this does not work for me, because boot.fglrxrebuild runs before the
filesystem will be mounted.
Bootup is done in parallel and it looks like, we have a race here. You cannot
prove that there is no race because it works on one machine by accident ;)

Stefan Dirsch:
Thanks for mentioning boot in parallel and race condition. This helps. Not sure
how to fix this now though. Waiting in the script until /var/log/ can be
written sounds silly and simply wrong to me. I guess it would be better to
depend on a systemd mount service having finisehed before. Not sure how this
can be achieved.

A commenter:
Created attachment 667906 [details]
systemV init script

To find a resolution here:

The fglrx build and install scripts come from an openSUSE user. They can be
found on his web site:
https://www.sebastian-siebert.de/
The latest version of the central install script can be downloaded directly
from:
https://www.sebastian-siebert.de/downloads/makerpm-amd-15.11.sh
This downloads another tar archive which contains the boot.fglrxrebuild
sysv-init rc script (latest version):
https://www.sebastian-siebert.de/downloads/amd-15.11-packaging-script.tar.bz2
The boot.fglrxrebuild is attached for convenience.

The systemV init script contains an LSB header:
### BEGIN INIT INFO
# Provides:          boot.fglrxrebuild
# Required-Start:    $local_fs
# Should-Start:
# Required-Stop:     $null
# Should-Stop:
# Default-Start:     B
# Default-Stop:
# Short-Description: Automatically rebuild the fglrx kernel module
# Description:       A service to build a fglrx kernel module for new kernels
### END INIT INFO

The directive:
   'Required-Start:    $local_fs' 
should make it depend in any local file systems being mounted [1][2].
However the systemd-sysv-generator doesn't seem to honour the $local_fs naem
facility [3] - maybe as systemV init scripts are all ordered after 
basic.target which might include the local-fs.target.
Currently there are reasons, why one may not want to convert the systemV init
script to a systemd service.

It is not clear if the culprit is really within the boot.fglrxrebuild script.
We'd need some advice by systemd experts how to proceed here.

[1]
http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
[2]
http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/facilname.html
[3]
https://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html#

systemd commenter:
(In reply to ... from comment #8)
> The directive:
>    'Required-Start:    $local_fs' 
> should make it depend in any local file systems being mounted [1][2].
> However the systemd-sysv-generator doesn't seem to honour the $local_fs naem
> facility [3] - maybe as systemV init scripts are all ordered after 
> basic.target which might include the local-fs.target.
> Currently there are reasons, why one may not want to convert the systemV
> init script to a systemd service.

Well, it's unfortunately more complicated than it should.

boot.fglrxrebuild is part of /etc/init.d/boot.d and is therefore handled
differently (it's a Suse specific behavior): fglrxrebuild has
WantedBy=sysinit.target and Before=sysinit.target type deps.

You can check it with 'systemct show -pAfter -PWantedBy fglrxrebuild'.

And I guess the 'Required-Start: $local_fs' is simply ignored because normally
all sys scripts are ordered after basic.target which implies the local_fs
target.

> 
> It is not clear if the culprit is really within the boot.fglrxrebuild script.
> We'd need some advice by systemd experts how to proceed here.
> 

Well we have probably an issue in the Suse specific code.

However that would be nice if we could get rid of those sysv scripts.

Couldn't we at least wrap this rebuild script in a native unit file ?

Also I'm not sure to understand why the sysv init script needs to be run so
early.

Another systemd commenter:
(In reply to ... from comment #9)

Indeed the insserv-generator as well as the systemd-sysv-install do not know
about SuSE/Debian(as well!) specfic boot scripts.  The map of the $local_fs
facility isn't know here.  To handle this for Lepa and SLES12 I suggest to
replace the $local_fs with boot.cleanup as this will mapped to
systemd-tmpfiles-setup.service

Another systemd commenter:
(In reply to ... from comment #10)
> (In reply to ... from comment #9)
> 
> Indeed the insserv-generator as well as the systemd-sysv-install do not know
> about SuSE/Debian(as well!) specfic boot scripts.  The map of the $local_fs
> facility isn't know here.  To handle this for Lepa and SLES12 I suggest to
> replace the $local_fs with boot.cleanup as this will mapped to
> systemd-tmpfiles-setup.service

hmm why not simply wrapping the sysv script in a systemd native unit file ?

That would be a step towards the removal of sysv support even if the path is
still long.

A commenter:
..., thank you for your helpful input!
We will try Werner's suggestion and see if the sysv init script can be fixed up
accordingly!