[gelöst] preseed-Install: unknown symbol in module

[csar]

Hallo Forum,

Ich habe lange Zeit Debian Jessie auf meinem X200 verwendet, ohne Probleme. Jetzt steht eine Neu-Installation an (SSD defekt), und ich wollte diese automatisiert vornehmen.
Dazu habe ich auf meinem Zweit-System eine preseed.cfg-Datei erstellt und so angepasst, dass eine Debian-Installation zu Testzwecken in einer VM (libvirt) wunderbar durchlief über Netzwerk-Boot (PXE).

Als ich mit genau der gleichen config dann die Installation auf dem Thinkpad X200 startete, blieb der Installer hängen, weil er das root-Dateisystem nach dem Erstellen nicht mounten konnte.
Der Fehler war, dass er das Modul btrfs nicht laden konnte, wegen "unknown symbol setattr_prepare" und "unknown symbol posix_acl_update_mode". Ein Umschalten auf ext4 half auch nichts, auch beim Laden des ext4-Moduls kam das gleiche Problem.

Eine google-Suche nach "unknown symbol setattr_prepare" hilft nicht, hier werden nur Fälle besprochen, wo wohl ein Neustart nach einem Kernel-Update gefehlt hat.


Ich weiß, das ist ein ziemlicher Nischen-Anwendungsfall, kann mir hier trotzdem jemand weiterhelfen?

Edit:
Wenn ich statt PXE-boot von einer debian Install-CD boote, und exakt die gleiche preseed.cfg per "auto url=http://server/preseed.cfg" verwende, läuft die Installation durch.
Scheint also etwas mit dem PXE-Boot zu tun zu haben.

[nschroeter]

Hallo,

den Bug kann ich bestätigen. Er tritt reproduzierbar auf mehrfach vorhandener, baugleichen Hardware auf.
Interessant daran ist, dass letzten Freitag (13.01) die Installation nachweislich noch funktionierte - der Bug muss also
übers Wochenende eingeführt worden sein...

[scientific]

Ich kann dazu leider nix sagen, hätt aber eine Bitte...
Magst du ev. Deine preseed.cfg teilen? Ich blick bei der Thematik noch nicht ganz durch und würd gern etwas dazulernen.

Lg scientific

[csar]

Hier meine preseed.cfg:
https://gist.github.com/csarn/a7b23e27a ... 15740fe094
Entstanden durch copy&paste aus verschiedenen Quellen... funktioniert, wie sie ist, ausschließlich bei mir, da ich einen lokalen
Server verwende (als apt-cacher, und um ein post-install skript zur Verfügung zu stellen).
Die entsprechenden Stellen sind kommentiert.
Für eine libvirt-basiert VM-Installation muss /dev/sda noch durch /dev/vda erstetzt werden.

@nschroeter:
Wenn der Bug neu ist, dann muss das Kernel-Modul fürs Dateisystem wohl auch übers Netzwerk kommen? Ich hätte gedacht, dass die in der initrd mit drin liegen.
Ich probier das nochmal in einer VM aus, ob dort der Bug jetzt auch auftritt.

[mbrqsvt]

Als ich mit genau der gleichen config dann die Installation auf dem Thinkpad X200 startete, blieb der Installer hängen, weil er das root-Dateisystem nach dem Erstellen nicht mounten konnte.
Der Fehler war, dass er das Modul btrfs nicht laden konnte, wegen "unknown symbol setattr_prepare" und "unknown symbol posix_acl_update_mode". Ein Umschalten auf ext4 half auch nichts, auch beim Laden des ext4-Moduls kam das gleiche Problem.

Hilft eine Aktualisierung der per TFTP verteilten Dateien?

http://ftp.de.debian.org/debian/dists/j ... s/netboot/

Wir hatten heute das gleiche Problem, scheinbar passen die Module, die vom Installer nachgeladen werden, seit dem letzten Point-Release auf 8.7 nicht mehr zum netboot-Kernel.

[csar]

Ja, danke, das hat geholfen!
Jetzt läuft die Installation...

[hikaru]

Ich kenne mich mit Preseed nicht aus, aber es gab ein (eher kosmetisches) Problem mit den 8.7.0-Images. Daher hat sich das CD-Team entschlossen, Images mit der Version 8.7.1 zu veröffentlichen und die 8.7.0-Images wohl wieder offline genommen. [1]
Falls Preseed auf diese Images zugreift oder irgendwie von der exakten Versionsnummer abhängt, dann könnte das möglicherweise die Probleme erklären.

[1] http://cdimage.debian.org/debian-cd/8.7.1/

[csar]

Danke für die Info!
Für die Netzwerkinstallation ist die Versionsnummer auf den CDs aber nicht relevant.

Das Problem hat sich ja bereits gelöst, es lag daran, dass ich den netboot-Installer von Debian 8.6 verwendet habe, und kurz nach meinem ersten erfolgreichen Test Debian 8.7 released wurde,
mit einem neueren Kernel. Da hat sich dann mein alter netboot-kernel aus dem Netz Module für den neueren Kernel gezogen, und die waren natürlich nicht kompatibel.

Da ich zufälligerweise vor dem 8.7-Release auf einer VM getestet hatte, und nach dem Release es auf echter Hardware versucht habe, dachte ich, der Fehler würde
mit der Hardware zusammenhängen. War aber nur reiner Zufall.

[scientific]

Vielen Dank für deine preseed.cfg!

Eine Frage... weißt du, ob ich mittels preseeding zuerst eine btrfs-Partition anlegen, in dieser dann einen rudimentären Verzeichnisbaum erstellen und in diesem dann btrfs-Subvolumes erstellen kann, BEVOR das Grundsystem installiert wird?

Ich habe nämlich die Befürchtung, dass dies der Debian-Installer so nicht zulässt. Da fehlt ein Hook zwischen Partman und der Grundsysteminstallation...

Müsst ich eventuell in einem Skript vor Partman einhängen... oder?

lg scientific

[csar]

Den Gedanken hatte ich auch schon. Vor partman würde aber nicht helfen, weil dir partman ja alles wieder überschreibt.
Ich würde mal ein partman/late_command probieren, ob da schon /target gemounted ist, weiß ich nicht.

Noch ein Punkt zu btrfs: Für die preseed-Installation braucht man, bei btrfs-Verwendung, zumindest nach meinem Verständnis zwingend eine
nicht-btrfs boot-partition. Der Grund ist, dass grub mit btrfs-Unterstützung mehr Platz braucht als vor der ersten Partition vorhanden ist.
Bei manueller Partitionierung kann man die erste Partition einfach weiter hinten anfangen lassen, aber per preseed geht das nicht.

[scientific]

Den Gedanken hatte ich auch schon. Vor partman würde aber nicht helfen, weil dir partman ja alles wieder überschreibt.
Ich würde mal ein partman/late_command probieren, ob da schon /target gemounted ist, weiß ich nicht.

Noch ein Punkt zu btrfs: Für die preseed-Installation braucht man, bei btrfs-Verwendung, zumindest nach meinem Verständnis zwingend eine
nicht-btrfs boot-partition. Der Grund ist, dass grub mit btrfs-Unterstützung mehr Platz braucht als vor der ersten Partition vorhanden ist.
Bei manueller Partitionierung kann man die erste Partition einfach weiter hinten anfangen lassen, aber per preseed geht das nicht.

Ja genau das ist der Punkt. Wenn ich es vor Partman mache, geht alles wieder kaputt. Und direkt nach Partman hab ich bisher noch keinen passenden Hook gefunden...
Was ich auch noch nicht behirnt habe... Angenommen, mir gelingt ein hook nach Partman, wo ich über ein Skript den Verzeichnisbaum mit den Subvolumes mit btrfs erstellen kann, dann hab ich noch ein Problem. Ich habe zwei "Mainsubvolumes".
@debian und __ALWAYSCURRENT__
unter __ALWAYSCURRENT__ finden sich dann Verzeichnisse wie usr-local-bin oder var-spool, welche in @debian/usr/local/bin und @debian/var/spool gemountet werden, bevor die Installation des Grundsystems stattfindet. Ich erstelle also den Verzeichnisbaum, mounte die entsprechenden Subvolumes... landen die dann automatisch in der fstab? Oder muss diese dann auch noch manuell befüllt werden?

lg scientific

PS: Sorry, wenn ich deinen Thread grad ein wenig entführe... Wenn es dich stört, mach ich einen eigenen auf.

[csar]

Das Thema könnte man schon in einen eigenen Thread verschieben, aber hier hört meine Kenntnis eh auf.
So komplizierte Subvolume-Strukturen hätte ich nicht verwendet, ich überlege nur, /home als subvolume zu haben.
Was spricht dagegen, /usr/local/bin als subvolume zu haben, und /var/spool auch?
Wenn die Subvolumes am richtigen Ort liegen, muss man die nicht extra mounten.

Wie die fstab befüllt wird, weiß ich nicht. Aber wenn ich raten müsste, würde ich sagen, dass das nicht automatisch richtig wird, wenn du in einem Hook
noch weitere subvolumes mountest. Ansonsten: probieren geht über studieren Du kannst ja in einem hook versuchen, eine interaktive shell zu starten, und
dann herumforschen.

[scientific]

Die "komplizierte" Struktur mit Subvolumes, die gemountet werden, hat einen simplen Grund...
Ich hab mir das von der SuSe abgeschaut.

Wenn du alles mit Subvolumes unter einem einzigen Subvolume organisierst (z.B. um Quotas auf Subvolumes setzen zu können), und du rollst auf einen früheren Snapshot zurück, weil z.B. ein Systemupgrade fehlgeschlagen ist und dein System kaputt gemacht hat, dann verlierst du alles was du seit dem Snapshot gearbeitet hast, alle deine neuen Mails seither... Läuft ein Webshop, oder eine Datenbank, wird diese auch auf den früheren Zustand zurückgesetzt.

Sind die entsprechenden Verzeichnisse in einem zweiten Subvolume ausgelagert, und werden entsprechend im System-Subvolume gemountet, bleiben die Nutzerdaten immer aktuell, auch wenn du dein System auf einen früheren Zeitpunkt zurückrollst.

Und für ein Systemupgrade machst du dann auch nur vom Systemvolume einen snapshot (kann man bei apt einhängen), was wesentlich schneller geht, als 100te GB an Daten (bzw. die Metadaten) zu snapshoten. Auf einer langsamen HD hält das nämlich durchaus auch mit btrfs das System auf...

Und aus diesem Grund hätt ich das gerne in die Installationsroutine verpackt...

Am Besten überhaupt so, dass ich mir mit Partman eine btrfs-Partition per preseeding anlegen lasse, in welche ich dann vor der Installation des Grundsystems die Struktur erzeuge, die Subvolumes mounte und dann erst mit der Installation beginne...

Aber ich weiß nicht recht, wo ich brauchbare Informationen dazu finde. Deine preseed.cfg war jedenfalls schon mal sehr aufschlussreich für mich.

lg scientific

[csar]

Schau mal, was ich grade gefunden habe:
https://github.com/bfritz/remote-script-partitioner

das sieht so aus, als könnte es deine Probleme lösen.

[scientific]

Ah danke. Werd ich mir ansehen!