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

[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?

[cronoik]

Habe im Moment das gleiche Problem mit Kernel linux-image-5.4.0-0.bpo.3 aus buster-backports.
...
Weiß Jemand aus Erfahrung, wie lange es ungefähr dauert bis die signierte Version im Repo verfügbar ist?

Ich verstehe den ganzen Thread nicht ganz. Ist das irgendwie wichtig, dass die neusten headers mit dem neusten signierten Kernel released werden? Die Alternative waere ja, dass die Headers zurueckgehalten werden bis der signierte Kernel auch paketiert ist.

[KP97]

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?

Nein, es gibt keine Einschränkungen. Der signierte ist doch nur dafür gedacht, wenn man mit Secureboot starten will. Das hast Du doch gar nicht eingestellt.
Ich backe zwar für mein Sid den Kernel selbst, habe aber noch nie einen signierten verwendet, eben aus diesem Grund. Secureboot ist im UEFI ausgeschaltet, dann braucht es auch keinen signierten.

[MaGe]

Habe im Moment das gleiche Problem mit Kernel linux-image-5.4.0-0.bpo.3 aus buster-backports.[...]

und bei mir Kernel linux-image-5.5.0-rc5 ( experimental )

Debian GNU/Linux bullseye/sid ( unstable )

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

und neue firmware.
update-initramfs: Generating /boot/initrd.img-5.5.0-rc5-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169

Alte
update-initramfs: Generating /boot/initrd.img-5.4.0-3-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169


gruss MaGe

[ingo2]

Nein, es gibt keine Einschränkungen. Der signierte ist doch nur dafür gedacht, wenn man mit Secureboot starten will. Das hast Du doch gar nicht eingestellt.

Danke. 5.4.0-0.bpo.3-amd64-unsigned läuft schon
Ingo

[KBDCALLS]

Ich hab mir mal die Sourcen zu dem Signierten Kernel vorgenommen. Erst wird der unsignierte Kernel gebaut und der wird dann signiert soweit das daraus ersichtlich war.

• http://snapshot.debian.org/package/linu ... .4.13%2B1/