system failed to start due to systemd upgrade!

[hendrikL]

@hendrikL
At first thanks for the hint.
After adding testing in source.list and starting apt as you adviced apt wants to install the new 256~rc3-3 Version of systemd again, no change.
For today I can work with it.
Is it a security problem using rw for the grub starting command.

Did you run

Code Select Expand


apt update && apt install  systemd/testing --no-strict-pinning

?

Code Select Expand


~$ LANG=C apt install  systemd/testing --no-strict-pinning -s
NOTE: This is only a simulation!
      apt needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!

systemd is already the newest version (256~rc3-2).
Selected version '256~rc3-2' (Debian:testing [amd64]) for 'systemd'
Selected version '1.5.3-7' (Debian:unstable, Debian:testing [amd64]) for 'libpam0g' because of 'systemd'
Summary:                   
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 13
Notice: Automatically enabled --solver 3.0 for --no-strict-pinning


Code Select Expand


LANG=C apt policy systemd
systemd:
  Installed: 256~rc3-2
  Candidate: 256~rc3-4
  Version table:
     256~rc3-4 500
        500 https://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages
     256~rc3-3 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
        500 https://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages
*** 256~rc3-2 500
        500 https://deb.debian.org/debian testing/main amd64 Packages
        100 /var/lib/dpkg/status


Btw. 256rc3-4 has the same problem, I don't know what is causing that issue!

[Fellfrosch]

@charlyheinz
If everything runs again like expected, I would suggest thinking about using timeshift in future. This lets you look in a more relaxed way on such problems. You can restore your system with just a few clicks, even if it refuses to boot.

[unklarer]

Ich habe seit heute morgen insgesamt 5 Systeme mit D-U aktualisiert.

Jetzt komme ich in's Forum und sehe die Warnung. Alle haben

Code Select Expand

apt policy systemd
systemd:
  Installiert:           256~rc3-3
  Installationskandidat: 256~rc3-3
  Versionstabelle:
*** 256~rc3-3 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status

und alle starten, wie immer .       Extra jetzt überprüft.

Allerdings war mir mit apt-listchanges das hier aufgefallen (übersetzt):

Code Select Expand


apt-listchanges: Neuigkeiten
----------------------------
systemd (256~rc2-3) unstable; dringlichkeit=medium

  - /tmp/ ist nun standardmäßig ein tmpfs, und zwar über die vorgelagerte Unit tmp.mount.
    Die vorherige Einstellung kann beibehalten werden, indem man die Unit lokal mit maskiert:

    systemctl mask tmp.mount

    oder:

    touch /etc/systemd/system/tmp.mount

  - /run/lock/ wird nicht mehr mit einem Patch vor dem Start der Units erstellt, sondern durch
    eine standardmäßige early-boot run-lock.mount Einheit, die vor
    local-fs.target. Jeder Dienst, der /run/lock/ verwenden muss und vor
    sysinit.target läuft (d.h. sie definieren wahrscheinlich DefaultDependencies=no), muss
    explizit mit After=run-lock.mount bestellt werden. Die beiden bekannten Fälle
    wo dies im Archiv passiert, wurde bereits ein Bug+MR eingereicht.

  - Bei neuen Installationen bereinigt tmpfiles.d nun standardmäßig /tmp/ alle
    10 Tage, und /var/tmp/ alle 30 Tage. Das alte Verhalten kann konfiguriert werden
    mit einer lokalen Überschreibung konfiguriert werden, falls erforderlich:

    echo 'D /tmp 1777' > /etc/tmpfiles.d/tmp.conf

    Diese Überschreibung wird automatisch für Upgrades von bestehenden
    Systemen von früheren Versionen auf Trixie. Zur Erinnerung, einzelne
    Dateien und Verzeichnisse für den Ausschluss von Bereinigungen markiert werden
    der Konfigurationszeile vom Typ 'x', wie in der tmpfiles.d-Manpage beschrieben,
    zum Beispiel:

    echo 'x /tmp/my-precious' > /etc/tmpfiles.d/precious.conf

  - Coredumps werden nun standardmäßig über Konfigurationsdateien deaktiviert, anstatt
    ein Out-of-Tree-Patch (die Installation des optionalen Pakets systemd-coredump
    wird sie wie bisher aktivieren). Wie immer ist ein Überschreiben über lokale Drop-ins
    möglich, falls gewünscht. Die Konfigurationsdateien, die sich jeweils auf
    die systemd-Instanz, die systemd-Instanzen der Benutzer und die PAM-Sitzungen
    sind:

    /usr/lib/systemd/system.conf.d/10-coredump-debian.conf
    /usr/lib/systemd/user.conf.d/10-coredump-debian.conf
    /usr/lib/sysctl.d/10-coredump-debian.conf
    /etc/security/limits.d/10-coredump-debian.conf

-- Luca Boccassi <bluca@debian.org> Tue, 28 May 2024 00:07:57 +0100

...
systemd (256~rc3-3) wird eingerichtet ...
/usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.
...


[hendrikL]

My system boots now without problems.

I was checking my fstab, and I knew that I mount my tmp as tmpfs!

Code Select Expand


~$ cat /etc/fstab
# Neue Partition                              none                defaults            0 0 # /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=385C-E2B7                              /boot/efi   vfat    umask=0077          0 2
UUID=009a5764-2ac7-41d0-9a9f-f80285bfb34e   /           ext4    noatime             0 1
tmpfs                                       /tmp        tmpfs   noatime,mode=1777   0 0
UUID=6134a4d8-1a1b-46e2-99da-4263c146ef57   /ablage     ext4    noatime             0 1
UUID=41a8bbb8-076c-49bf-9e0e-e05102319636   /speicher   ext4    defaults,noatime    0 1


But, look at the topline, "neue Partition" / "New partition" ! Wtf!

I commented it out and run an apt full-upgrade, rebooted and everything is ok!

Where does that first line came from?

[unklarer]

systemd wurde soeben auf 256~rc3-4 aktualisiert

Code Select Expand

systemd (256~rc3-4) wird eingerichtet ...
Unit tmp.mount does not exist, proceeding anyway.
Created symlink '/run/systemd/system/tmp.mount' → '/dev/null'.
/usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.
systemd-timesyncd (256~rc3-4) wird eingerichtet ...


Hier ist immer noch kein Fehler mit systemd beim Neustart vorhanden. Also, neues D_U   

[Fellfrosch]

Ich hab mir nun mal mein Surface Go als unrelevantesten Rechner hergenommen. Per nala upgrade upgedated inklusive systemd 256~rc3-4. Neustart und das Teil hängt. Nu kann ich entweder per Timeshift zurück oder die Pakete downgraden, oder einfach mal abwarten. Die neuere Systemd Version scheint aber nicht der Heilsbringer zu sein.

Meine fstab sieht aber unverändert und für mich völlig OK aus - allzu viel steht da eh nicht drin:

Code Select Expand

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>            <pass>
UUID=D1BA-0A70                            /boot/efi      vfat umask=0077                  0 2
UUID=6b732649-6f66-4cf6-93f5-e165b7dbd4a2 /              ext4 defaults,noatime            0 1
UUID=eef0a3b3-2c30-488c-ae5e-151bfd9dc437 swap           swap defaults,noatime            0 0
tmpfs                                     /tmp           tmpfs defaults,noatime,mode=1777 0 0

[charlyheinz]

Here still the same. I just did a DU while the new systemd rc was installed with the effect like befor, that my system stops booting. With changing the rw option for grub the system is starting!
I also checked my fstab. Nothing changed in it.  tmpfs = /tmp and no new entry on top of it!

apt policy systemd
systemd:
  Installiert:           256~rc3-4
  Installationskandidat: 256~rc3-4

[Fellfrosch]

Strange! Ich hab jetzt auch mal meine Hauptmaschine neu gestartet. Wie zu Erwarten hing auch die. Hab dann mit Option rw gestartet und war dann etwas sprachlos. Meine fstab war zwar unverändert, aber sie wurde in weiten Teilen einfach ignoriert. Sämtliche Partitionen, die mit der Option nofail vermerkt sind, wurden nicht eingehängt.

Code Select Expand

# <file system> <mount point> <type> <options> <dump> <pass>

UUID=E77B-D732 /boot/efi vfat umask=0077 0 2
UUID=a5c66fc1-d6ae-429e-895d-f8caaf57962f / ext4 defaults,noatime 0 1
UUID=5a7f9898-e98e-4c83-8d34-c61f5d30ea82 /home ext4 defaults,noatime 0 2
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
UUID=159ac537-428c-482d-b510-9e6cd0819302   none    swap    sw  0   0
UUID=bc860344-b048-4d13-bf1c-d5ea78a4c064 /media/Bilder ext4 defaults,noatime,discard,nofail 0 2
UUID=fcd041ed-d818-495c-aa13-cfbe895da4a7 /media/Musik ext4 defaults,noatime,discard,nofail 0 2
UUID=44f3673f-b742-4385-8743-55251f4eba16 /media/Video ext4 defaults,noatime,discard,nofail 0 2
UUID=b082c72a-9326-4990-a959-b71593d85f8b /media/Sicherung ext4 defaults,noatime,discard,nofail 0 2

Bin jetzt erstmal via timeshift auf den Stand von gestern zurückgekehrt und bleib da erstmal, bis Entwarnung gegeben wird.

[micspabo]

Nach D-U bootete Siduction bei mir auch nicht mehr. 

Im Boot-Menü auf dem aktuellen Boot-Eintrag 'e' drücken und unten ro gegen rw ändern,- mit F10 dann booten. Ist bei mir erfolgreich und ich komme wieder in mein System.
@hendrikL: Danke! 

Das Paket systemd läuft mit Version 256~rc3-4

Die apt-listchanges zu systemd (256~rc3-3) hatte ich zwar gelesen, aber nicht erwartet, das mir das beim Reboot um die Ohren fliegt.

Meine /etc/fstab hat sich seit Februar nicht geändert.
Da hab ich die Transition von t64 überlebt, und heute dumm aus der Wäsche geschaut als mein reboot klemmte.

[hendrikL]

First. I don't think that it is a good idea to always boot by changing the command line. Please downgrade!
charlyheinz please do it, all other too!
Then try to find the reason why this happens, there must be something wrong/ not right on your system.
When you boot without changing the command line, you can always login by changing to getty 2 or 3 or ...  then start searching for the error by reading for example dmesg or journalctl, try startx and so on, you can akso try the mount command, ..., there are many ways to check and search...!

But please downgrade, or start a rollback, always boot with changing ro to rw is the last thing you should do!

[charlyheinz]

After DU this morning evrything still the same, my system is not booting. With changing the grub-bootentry to rw it works, but as hendrikLmeant it is for shure not a solution. Still try to find the reason for this behavior with my small experience.

apt policy systemd
systemd:
  Installiert:           256~rc3-5
  Installationskandidat: 256~rc3-5

[hendrikL]

charlyheinz, what are you doing is the best way to shoot in your feed!

[hendrikL]

mount ro but to init 3 if you try to find the reason why, than try 'mount a -- rw,' than startx as user, getty is still working!

on the command line, type a 3 at the end. then you are booting to init 3 directly and start searching.

[charlyheinz]

Danke hendrikL
Ich denke es ist mal wieder an der Zeit mein System frisch aufzusetzen. Timeshift kannte ich bis jetzt noch nicht. (klasse!)
Gibt es Bedenken hinsichtlich der System-Sicherheit beim Umstellen des Booteintrags auf rw?
Selbstverständlich ist das keine Lösung. Ausgerechnet diese Woche habe ich keine Zeit für Experimente.

Wird es eigentlich demnächst ein neues Release geben?

Danke an alle Beteiligten!!

[hendrikL]

wenn plasma 6, bzw. kf6 in debian unstable aufschläg und funktionsfähig ist, dann neues offizielles ISO, bis dahin gibt es aktuelle Test-ISOs. Ab und an halt.

Gerade gibt es ein neues kde, zum Testen, ohne Garantie!