[Schon wieder! 5.4.0-3]Testing Update: Linux - Headers 5.4 ohne Kernel ???

[rockyracoon]

@willy4711: Thx.

[willy4711]

Heute morgen wurde nachgeliefert. Bekam natürlich erstmal einen riesigen Schreck, da dkms nicht tätig wurde .
Gleich mal die /var/log/apt/term.log durchgesehen, und beruhigt festgestellt, dass die Kernelmudule schon gestern ohne
Kernel mit den Headern gebaut wurden. Grub auf neuen Kernel umgestellt ----> Neustart mit Herzklopfen ---> Alles gut
Ich liebe Testing, ich liebe Debian ---> Spannung gratis zum Betriebssystem

Code: Alles auswählen

uname -a
Linux XFCE 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux

[kalle123]

Nur die

Code: Alles auswählen

depmod: ERROR: ....

Meldungen rasselten wieder massiv durch.

cu KH

[willy4711]

Nur die

Code: Alles auswählen

depmod: ERROR: ....

Meldungen rasselten wieder massiv durch.

cu KH

Habs nicht gezählt aber bei mir waren das 2 oder drei Tausend Zeilen
Extrem ätzend, wenn man was sucht

[KP97]

Das läßt sich abstellen, bis zum offiziellen Patch.

Als root das Script mkinitramfs in /usr/sbin aufrufen
und dann die alte Zeile
for x in modules.builtin modules.order; do
überschreiben mit
for x in modules.builtin modules.builtin.bin modules.order; do
Anschließend noch ein update-mkinitramfs -u -k all
und der Spuk ist vorbei.

[willy4711]

@KP97 --- Danke für den Tipp Nur um sicher zu gehen:
Diesen Absatz

Code: Alles auswählen

# Copy in modules.builtin and modules.order (not generated by depmod)
for x in modules.builtin modules.order; do
	if [ -f "${MODULESDIR}/${x}" ]; then
		cp -p "${MODULESDIR}/${x}" "${DESTDIR}${MODULESDIR}/${x}"
	fi
done

Ändern in:

Code: Alles auswählen

# Copy in modules.builtin and modules.order (not generated by depmod)
for x in modules.builtin modules.builtin.bin modules.order; do
	if [ -f "${MODULESDIR}/${x}" ]; then
		cp -p "${MODULESDIR}/${x}" "${DESTDIR}${MODULESDIR}/${x}"
	fi
done

Frag mich bloß, warum so was so viele Upgrades und Tage übersteht.
Oder muss das erstmal das QM-System bei Debian durchlaufen?

[KP97]

Ja, so ersetzen wie geschrieben.
Tja, auch in meinem Sid ist noch nichts, wahrscheinlich wird das als unwichtig angesehen.
Da ich meine Kernel selbst kompiliere, stört mich das schon sehr. Auch wenn es keine Fehler produziert, ist es doch mehr als reine Kosmetik.

[kalle123]

Danke KP97!

Im vbox Testing geändert, werde mir das die nächsten Tage anschauen. Beim 'Alten' und beim TP werde ich noch mal warten

Gruß KH

[willy4711]

Anschließend noch ein update-mkinitramfs -u -k all

du meinst doch sicher:

Code: Alles auswählen

update-initramfs -u -k all

denn

Code: Alles auswählen

root@XFCE:~# update-mkinitramfs -u -k all
-bash: update-mkinitramfs: Kommando nicht gefunden.

[KP97]

ja klar, Freudsche Fehlleistung, sorry...

[kalle123]

Wenn ich das richtig sehe, steh die im
https://bugs.debian.org/cgi-bin/bugrepo ... bug=948257

Severity: normal

Kann also dauern.

cu KH

[willy4711]

Kurze Erfolgsmeldung:
Grad ein mini- Update durchlaufen lassen ---> ohne das ätzende depmod: ERROR: ....
THX- für den Tipp

[kalle123]

Auch hier sauber.

Frage: Muss das Script 'mkinitramfs' irgendwann wieder zurückgesetzt werden?

cu KH

[MaGe]

Kurze Erfolgsmeldung:
Grad ein mini- Update durchlaufen lassen ---> ohne das ätzende depmod: ERROR: ....

depmod: ERROR:
habe ich nur wenn update-initramfs das von APT (oder dpkg ?)
aufgerufen wird, wenn ein Kernel oder Treiber aktualisiert wird.
normales apt full-upgrade läuft ohne Fehlermeldung durch.


gruss MaGe

[KP97]

Frage: Muss das Script 'mkinitramfs' irgendwann wieder zurückgesetzt werden?

Unwahrscheinlich, der Patch wird das von uns manuell Eingetragene überschreiben.
Aber ein bak vom Script kann nicht schaden.
Zu MaGe's Hinweis kann ich nichts sagen, ich installiere meine Kernel mit dpkg, Standardkernel nutze ich nicht.
Beim nächsten Update weiß man mehr.

[MaGe]

Frage: Muss das Script 'mkkalle123initramfs' irgendwann wieder zurückgesetzt werden?

depmod: ERROR: .. Es hat sich einiges getan!
Die folgenden Pakete werden aktualisiert (Upgrade):
initramfs-tools initramfs-tools-core


gruss MaGe

[kalle123]

depmod: ERROR: .. Es hat sich einiges getan!
Die folgenden Pakete werden aktualisiert (Upgrade):
initramfs-tools initramfs-tools-core

Hi, wie hab ich das jetzt zu interpretieren?

Gruß KH

[KP97]

@MaGe meinte, daß der Bugfix heute im Sid eingetroffen ist..;-)

[MaGe]

@MaGe meinte, daß der Bugfix heute im Sid eingetroffen ist..

gruss MaGe

[willy4711]

Scheint ja so weiter zugehen:
Gerade Eben:

Code: Alles auswählen

Aptitude 0.8.12: log report
Fri, Jan 24 2020 10:01:09 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 71 packages, and remove 0 packages.
64.1 MB of disk space will be used
========================================
[INSTALL, DEPENDENCIES] libegl-dev:amd64 1.3.0-7
[INSTALL, DEPENDENCIES] libgl-dev:amd64 1.3.0-7
[INSTALL, DEPENDENCIES] libgles-dev:amd64 1.3.0-7
[INSTALL, DEPENDENCIES] libglx-dev:amd64 1.3.0-7
[INSTALL, DEPENDENCIES] linux-headers-5.4.0-3-amd64:amd64 5.4.13-1
[INSTALL, DEPENDENCIES] linux-headers-5.4.0-3-common:amd64 5.4.13-1

Hmm - Was für Abhängigkeiten könnten denn Headers ohne den dazugehörigen Kernel haben ?

Ist das jetzt ein neues Verfahren? So nach dem Motto : Leute zieht den Kopf ein gleich kommt eine neuer Kernel

[MaGe]

Ist das jetzt ein neues Verfahren? So nach dem Motto : Leute zieht den Kopf ein gleich kommt eine neuer Kernel

Code: Alles auswählen

 lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
Codename:       sid 

Bei mir am 20.01.2020: kernel 5.4.0-3 wieder depmod: ERROR

Der scheint sich aber vom Fehler 948350 zu unterscheiden.
Alt:

depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_jwtQGu/lib/modules/5.4.0-2-amd64/modules.builtin.bin'

Da der Pfad nicht dasselbe ist!
Neu:

depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-3-amd64/modules.builtin.bin'

aber er tut es!
kernel: Linux version 5.4.0-3-amd64


gruss MaGe

[willy4711]

Da der Pfad nicht dasselbe ist!
Neu:

Ist bei mir genauso.

Sehr produktiv: 3566 Zeilen

Bleibt die Frage: Warum kommen die Header neuerdings 1 Tag vor dem Kernel ??
Sind doch ohne Kernel ziemlich nutzlos. Oder täusche ich mich

[KBDCALLS]

Das Problem ist das der signierte Kernel hinterhinkt , der unsignierte Kernel ist höufig vorher da.

• Code: Alles auswählen

  p   linux-image-5.4.0-3-amd64                            - Linux 5.4 for 64-bit PCs (signed)                             
  p   linux-image-5.4.0-3-amd64-dbg                        - Debug symbols for linux-image-5.4.0-3-amd64                   
  p   linux-image-5.4.0-3-amd64-unsigned                   - Linux 5.4 for 64-bit PCs                                      
  p   linux-image-5.4.0-3-cloud-amd64                      - Linux 5.4 for x86-64 cloud (signed)                           
  p   linux-image-5.4.0-3-cloud-amd64-dbg                  - Debug symbols for linux-image-5.4.0-3-cloud-amd64             
  p   linux-image-5.4.0-3-cloud-amd64-unsigned             - Linux 5.4 for x86-64 cloud                                    
  p   linux-image-5.4.0-3-rt-amd64                         - Linux 5.4 for 64-bit PCs, PREEMPT_RT (signed)                 
  p   linux-image-5.4.0-3-rt-amd64-dbg                     - Debug symbols for linux-image-5.4.0-3-rt-amd64                
  p   linux-image-5.4.0-3-rt-amd64-unsigned                - Linux 5.4 for 64-bit PCs, PREEMPT_RT

• Code: Alles auswählen

  linux-image-5.4.0-3-amd64-unsigned_5.4.13-1_amd64.deb
      Seen in debian on 2020-01-19 21:16:03 in /pool/main/l/linux.
      Size: 48164172 

• Code: Alles auswählen

  linux-image-5.4.0-3-amd64_5.4.13-1_amd64.deb
      Seen in debian on 2020-01-20 03:22:58 in /pool/main/l/linux-signed-amd64.
      Size: 49178528
  

[willy4711]

Naja dann könnte man doch auch die Headers einen Tag später liefern, und dann alles zusammen.
Oder verstehe ich da was falsch ? Gibt es denn Abhängigkeiten von kernellosen Headern ?
P.s.:
Wusste gar nicht, dass ich jetzt signiert bin

Code: Alles auswählen

$ dpkg -l linux-image*|grep ii
ii  linux-image-5.4.0-2-amd64          5.4.8-1      amd64        Linux 5.4 for 64-bit PCs (signed)
ii  linux-image-5.4.0-3-amd64          5.4.13-1     amd64        Linux 5.4 for 64-bit PCs (signed)
ii  linux-image-amd64                  5.4.13-1     amd64        Linux for 64-bit PCs (meta-package)

Na ja- letztendlich ist es ja auch egal, ein (vermeintlich) nutzloses Paket mehr oder weniger, spielt keine Rolle.

[ingo2]

Das Problem ist das der signierte Kernel hinterhinkt , der unsignierte Kernel ist höufig vorher da.

Habe im Moment das gleiche Problem mit Kernel linux-image-5.4.0-0.bpo.3 aus buster-backports.
Da wurden die Header, usw. schon gestern installiert:

Code: Alles auswählen

[INSTALL, DEPENDENCIES] linux-headers-5.4.0-0.bpo.3-amd64:amd64 5.4.13-1~bpo10+1
[INSTALL, DEPENDENCIES] linux-headers-5.4.0-0.bpo.3-common:amd64 5.4.13-1~bpo10+1
[UPGRADE] libpq5:amd64 11.6-0+deb10u1 -> 11.7-0+deb10u1
[UPGRADE] linux-headers-amd64:amd64 5.4.8-1~bpo10+1 -> 5.4.13-1~bpo10+1
[UPGRADE] linux-kbuild-5.4:amd64 5.4.8-1~bpo10+1 -> 5.4.13-1~bpo10+1

aber der Kernel fehlt noch.

Vorhanden im Repo ist nur der zugehörige unsignierte Kernel

Code: Alles auswählen

linux-image-5.4.0-0.bpo.3-amd64-unsigned

.

Weiß Jemand aus Erfahrung, wie lange es ungefähr dauert bis die signierte Version im Repo verfügbar ist?
Da ich den Kernel für 7 Jahre alte Hardware viewtopic.php?f=2&t=176342, die auch per BIOS (neudeutsch CSM) bootet, könnte ich evtl. auch den unsignierten Kernel nutzen, oder sind da Einschränkungen z.B. bei VirtualBox oder anderen Kernel-Modulen zu erwarten?