#1056151 fai-client: Diversion makes /usr/sbin/init vanish in /usr-move conditions

#1056151#5
Date:
2023-11-17 19:54:29 UTC
From:
To:
Hello Thomas,

you will have noticed that systemd 255 moves its files from / to /usr.
This includes /sbin/init.

Now a problem arises, when:
- I use a basefile tar.gz, made with an old systemd (say, it uses
  testing as of today)
- During baseupdate, systemd gets updated and moves its file (say, I'm
  actually installing unstable)

What happens is this:
- base image gets unpacked, /sbin is a symlink to /usr/sbin,
  /sbin/init is actually /usr/sbin/init
- baseupdate diverts /sbin/init to /sbin/init.distrib (and using
  symlinks, /usr/sbin/init became /usr/sbin/init.distrib)
- baseupdate updates systemd, dpkg 'moves' /sbin/init to /usr/sbin/init,
  but the divert stays in place for /sbin/init.
  At this time, dpkg will have overwritten /usr/sbin/init with the new
  file(!)
- fai-divert -R runs, removes /sbin/init, and removes the divert of
  /sbin/init.
  But: at this point /sbin/init was already the new /usr/sbin/init,
  which is now lost.

As a result /usr/sbin/init is missing, and the system does not boot.

I would suggest dropping all the fai-divert calls in baseupdate.

Chris

#1056151#10
Date:
2023-11-17 22:49:49 UTC
From:
To:
Hi Chris,

    > Now a problem arises, when:
    > - I use a basefile tar.gz, made with an old systemd (say, it uses
    >   testing as of today)
    > - During baseupdate, systemd gets updated and moves its file (say, I'm
    >   actually installing unstable)
Mmm, I do not know if it's possible to catch this.
Using an old system which is then updated may always cause strange
problems.

Does this problem also arises when you use a basefile from unstable?
This is the main question I have.

fai-client 5.11? I do not know this version. I guess it's some
other version.

#1056151#15
Date:
2023-11-20 14:08:16 UTC
From:
To:
* Chris Hofstaedtler [Fri Nov 17, 2023 at 08:54:29PM +0100]:

Thanks for the great analysis, Chris.

It seems that
https://github.com/faiproject/fai/commit/7294b415ab2982f84b293900a9610eab49184201
works around the issue, at least for my use case (though the commit
message sadly isn't really verbose and doesn't say what the
underlying reason for the change was).

The change didn't make it into any fai release yet, though.

regards
-mika-

#1056151#20
Date:
2023-11-20 16:30:35 UTC
From:
To:
* Thomas Lange <lange@cs.uni-koeln.de> [231117 23:50]:


No, because then there is no systemd-sysv upgrade happening as part
of updatebase. But then updatebase is kinda supposed to handle
exactly such things, no?

I can't say what the version we saw this originally really is, but
it reproduces on 6.0.5.

Best,
Chris

#1056151#27
Date:
2023-11-28 11:34:08 UTC
From:
To:
Hi Mika,

the additional test before calling fai-divert was added because in
the next FAI release, we will move from sysv to systemd by default.

I think I will not drop the code for sysv support immediately.

#1056151#30
Date:
2023-11-28 11:34:08 UTC
From:
To:
Hi Mika,

the additional test before calling fai-divert was added because in
the next FAI release, we will move from sysv to systemd by default.

I think I will not drop the code for sysv support immediately.

#1056151#35
Date:
2023-11-28 20:52:38 UTC
From:
To:
The comment in lib/updatebase explains why the diversion for
/sbin/init was added:

    # if libc is upgraded init u is called in chroot environment and
    # then init will eat up much cpu time

This was a rare case in the past and maybe we can remove this
diversion? What do you think?

#1056151#38
Date:
2023-11-28 20:52:38 UTC
From:
To:
The comment in lib/updatebase explains why the diversion for
/sbin/init was added:

    # if libc is upgraded init u is called in chroot environment and
    # then init will eat up much cpu time

This was a rare case in the past and maybe we can remove this
diversion? What do you think?

#1056151#43
Date:
2024-02-28 21:40:13 UTC
From:
To:
Hi,

This bug also broke the generation of Vagrant images for the testing
distribution. (Those images are based on a fork of
https://salsa.debian.org/cloud-team/debian-cloud-images)

I removed the divert locally as a workaround.

Lucas

#1056151#48
Date:
2024-02-29 11:21:24 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
fai, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1056151@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Thomas Lange <lange@debian.org> (supplier of updated fai package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 29 Feb 2024 11:34:09 +0100
Source: fai
Architecture: source
Version: 6.2.2
Distribution: unstable
Urgency: low
Maintainer: Thomas Lange <lange@debian.org>
Changed-By: Thomas Lange <lange@debian.org>
Closes: 1056151
Changes:
 fai (6.2.2) unstable; urgency=low
 .
   * updatebase: do not divert /sbin/init, Closes: #1056151
   * subroutines: fix variable name
   * 10-base-classes: remove class LINUX
Checksums-Sha1:
 0ae891bf597fbcde4ccdba7d94889123d358e33c 2070 fai_6.2.2.dsc
 dd8b238d82328d33da158d5f80906bd2f0e5b0f6 299364 fai_6.2.2.tar.xz
 1d2c57e6de2789b4092b3541ab6463ecdaa82fe2 16728 fai_6.2.2_amd64.buildinfo
Checksums-Sha256:
 fb9319cadccc0ee002749c97b8592c17bef45bd9916a29c9e64d18fa32cad127 2070 fai_6.2.2.dsc
 9f3487a917518b6c97b9c7748de814aa7a5e931f116fea93aa6d499d1d0a959e 299364 fai_6.2.2.tar.xz
 0dc20b2dde313d15c125870dffc7ecdcf6a98e40b4392e406222b9f06623ead5 16728 fai_6.2.2_amd64.buildinfo
Files:
 355195946b763f0dcd30b81a52ae4ce1 2070 admin optional fai_6.2.2.dsc
 db0584ef892cb9f801f10f7fa7f08e7c 299364 admin optional fai_6.2.2.tar.xz
 656cc0ce57bc1ce7384774506462be75 16728 admin optional fai_6.2.2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJFBAEBCAAvFiEEsR7jJz9rLetSjJPaK/jZ/gdLzeQFAmXgXfYRHGxhbmdlQGRl
Ymlhbi5vcmcACgkQK/jZ/gdLzeSsxw//Sd1KECTuFCIl1cJSDcDeuAdgxh/iSGBE
QsU/2ZauDoa/a6TAd7PZayFVWds9EFlYA38pqNsCuwMp85LpvQ5S3oaR5gLh61Yx
NHBcf4yjBnEPgknX/ftyZd0wN9sfk3+5Uysz+azS94MPgb2Y37E1TnCqaC0Dv2UT
jpdVEnBIAObZEemZ3WMDYcwGQc88xnuYwqMgkMfUdGSeF6MTVy55GnwWj3n7yyx5
zvAS5HF+EEW9TiUgpn/TgDuBt4G+BnBkBGYnbHCNG3TTN/7ZRh4rDHmdOrJRl1Kj
yqbunvWeg4iv88OMKA7chby6tjxqudkPWlqXyuJSWQs9Y/QQNtpnguJzYKQSUQv1
ynjUcYWzs1HrcN5geSEa50qV37ateIg2zCsD5FRpCV3XCl1TYXD3D56vFaQlh6I0
uNQxCZ8NP5JLXxYiqBH9gja5aGsjDVbk2to8iqsq2HddzZGMw/aofBTT9u/GA7/Z
/HaZ58yQmzW9Cn4B+VzW7K2jUbWC4qTkT5JNTnTd/yn5+vBfHtSfWQWJ9VT7ruSY
BGfvGjkR4E1jrfknug7F3EbY9U1qZOM5W5uk4H5s3m8RitxPa5UtSBedd/Exe0VY
4NdvdxGbRIDtyc7e+Dp2Ui+XDLQFTN4Ee1k4sBOr/3JWrPA+KtFIAPLJJ7FNtm+5
iDhI/pBWCa4=
=wGnT
-----END PGP SIGNATURE-----