personalisiertes Stretch klonen und von USB booten

[fischig]

Wenn du zweistellige GB am Stück überträgst, kann es gerade bei billigen Sticks schon mal vorkommen, dass deren Controller wegen Überhitzung austeigt (und vielleicht nicht wiederkommt).

Hmm, mit sowas habe ich nun überhaupt nicht gerechnet. Ich habe das Kommando jetzt kurzerhand mit Strg+c abgebrochen und neu gestartet (mit --progress): Er kopiert einstweilen weiter munter vor sich hin.

[fischig]

So, die Kopierorgie scheint letztlich fehlerfrei durchgelaufen zu sein. Welche Bootreihenfolge müsste denn jetzt im Bios für Thinkpad X61 eingestellt werden, um den Stick zu booten? Zur Auswahl von Einträgen, in denen „USB“ vorkommt, stehen: USB FDD, USB CD, -USB HDD.

USB FDD steht momentan an erster Stelle - warum auch immer.

[fischig]

Ich habe jetzt folgendes probiert:
USB FDD an erster Stelle im Bios belassen
/dev/sdb1 für / und /dev/sdb2 für swap in /etc/fstab eingetragen

boot=sdb
und root=sdb1 in lilo eingetragen. lilo im gechrooteten System ausgeführt.

Nach Neustart kommt die Maschine bis LIL dazu lese ich hier:

LIL Der zweite Teil des Bootloaders wurde gestartet, kann aber die Beschreibungstabelle des map-files nicht laden. Typischerweise ein Medien-Fehler (Oberflächenbeschädigung) oder unpassende Plattengeometrie.

keine Ahnung, ob ich da was machen kann/soll.

Dann habe ich -USB HDD im Bios an die erste Stelle geschrieben.
Das Lilo-Bootmenü erscheint mit den für das stretch erwarteten Einträgen, aber der Bootprozess bleibt hängen.

[grubenlicht]

Welche Bootreihenfolge müsste denn jetzt im Bios für Thinkpad X61 eingestellt werden, um den Stick zu booten? Zur Auswahl von Einträgen, in denen „USB“ vorkommt, stehen: USB FDD, USB CD, -USB HDD.

das dürfte USB-HDD sein müssen. Allerdings, booten tut das ja jetzt so nach dem Kopiervorgang noch lange nicht, da muß ja erstmal der Bootloader eingerichtet/wieder hergestellt werden.
Welches Bootverfahren wird denn an dem "von außen zugänglich zu machenden Rechner" verwendet? CSM oder EFI?

USB FDD steht momentan an erster Stelle - warum auch immer.

spielt in sofern keine Rolle (und wird übergangen), solange wie dort kein bootfähiges device vorhanden ist.

Mal grundsätzlich zu deinem Vorhaben

Wichtig wäre mir, dass ich die Maschine (auf der im Dauerbetrieb längst ein aktuelles bookworm auf der internen Platte läuft) mit dem vorhandenen stretch „von außen“ bei Bedarf booten kann und dafür nicht jedes mal die Systemplatte austauschen muss.

Dafür gibt es imho geeignetere Methoden, z. B.

1. Ventoy mit Persistenz und aktueller Live-iso
2. @smutberts Notfallsystem
3. stand-alone grub ähnlich wie #2, (nur für 64 bit EFI und CSM)

EDIT: hat sich überschnitten, zu LiLo kann ich nichts beitragen.

[fischig]

Warum steht vor der Bios-Bezeichnung USB HDD ein Minus, also „-USB HDD“?
Könnte gelingen und könnte es etwas bringen, auf dem vorhandenen Stretch einen aktuellen grub zu installieren. Was ich sehr ungern machte, weil ich damit das originale System (erheblich?) verändern müsste. Ich weiß, wie ich immer noch lilo reaktivieren könnte, aber ob das funktioniert? Dann wäre mein originales (und funktionierendes!) Stretch unwiderruflich hinüber.

zu grubenlicht:
Die Maschine: Thinkpad X61, s.o., hat kein EFI. Der Begriff CSM ist mir unbekannt.
grubenlichts Links Nr. 1+2 gehen von Voraussetzungen aus, die nicht mit meinem Vorhaben vereinbar sind:
aktuelle Live-iso, bzw Selbstbau eines (neuen) Systems via chroot.

[grubenlicht]

Warum steht vor der Bios-Bezeichnung USB HDD ein Minus, also „-USB HDD“?

das wirst du den firmware Hersteller fragen müssen.

Könnte gelingen und könnte es etwas bringen, auf dem vorhandenen Stretch einen aktuellen grub zu installieren. Was ich sehr ungern machte, weil ich damit das originale System (erheblich?) verändern müsste. Ich weiß, wie ich immer noch lilo reaktivieren könnte, aber ob das funktioniert? Dann wäre mein originales (und funktionierendes!) Stretch unwiderruflich hinüber.

ein in eine weitere Partiton (und den MBR) installierter stand-alone grub läßt die vorhandene Installation/Kopie vollkommen unberührt.

zu grubenlicht:
Die Maschine: Thinkpad X61, s.o., hat kein EFI. Der Begriff CSM ist mir unbekannt.

bedeutet "Compatibility Support Module" und stellt unter UEFI quasi die Funktionalität eines alten BIOS zur Verfügung.

grubenlichts Links Nr. 1+2 gehen von Voraussetzungen aus, die nicht mit meinem Vorhaben vereinbar sind:
aktuelle Live-iso, bzw Selbstbau eines (neuen) Systems via chroot.

verstehe ich nicht! (stretch ǂ aktuelle Live-iso; Selbstbau eines (neuen) Systems via chroot? Auf einem LiveSystem ist doch ein Installer, mit dem du ein neues System bauen kanst?!)

[fischig]

Hat jemand andere Ideen, warum das stretch auf dem Stick mit „-USB HDD “nicht „durch“bootet (siehe meinen drittletzten Beitrag)?

stretch ǂ aktuelle Live-iso

Eben. Ich will ein ziemlich altes, personalisiertes stretch, kein andernorts vorgefertigtes Live-Iso (Ventoy-Link) booten.
Der Inhalt des Ubuntu-Links zu stand alone grub ist mir „zu hoch“.

[grubenlicht]

Der Inhalt des Ubuntu-Links zu stand alone grub ist mir „zu hoch“.

einen (eigenständigen) grub "legacy" installieren ist nicht schwer:

• 1 kleine Partition – 50M ext4 – freischaufeln/anlegen, Ort beliebig
• vom LiveSystem aus diese Partition mounten
• als "root"

  Code: Alles auswählen

  grub-install --target=i386-pc --recheck --removable --boot-directory=/<mountpoint>/boot /dev/sdX

• eine grub.cfg erzeugen in /<mountpoint>/boot/grub
• Inhalt der grub.cfg

  Code: Alles auswählen

  menuentry "stretch auf USB" {
   search --no-floppy --fs-uuid --set=root <uuid der "/">
   linux /boot/vmlinuz-x.yy… root=UUID=<uuid>
   initrd /boot/initrd.img-x.yy
  }

[fischig]

Ich will erst mal warten, ob jemand eine Idee hat, warum lilo nicht durchbootet. Mit /dev/sda auf dem Original tut das ja.

[fischig]

Kann es sein, dass die Maschine nicht von dev/sdbX booten kann?
Immerhin habe ich jetzt als letztes diese Fehlermeldung:

Code: Alles auswählen

unable to mount root fs on unknown-block (8,17)

[fischig]

Hmmm,

woran ich als Laie nicht gedacht habe: Kann es sein, dass der USB-Boot daran scheitert, dass ausschließlich Eigenbaukerne benutzt werden und keine initrd vorhanden ist?

[fischig]

Den Versuch, einen Stick zu booten, habe ich mittlerweile zurückgestellt. Der Klon sitzt jetzt auf einer HHD. fstab und lilo.conf habe ich im chroot angepasst. lilo ist klaglos durchgelaufen, aber als einzigen Datenträger in der Maschine eingebaut, kommt das System mit der letzten Fehlermeldung nicht hoch. Das System sitzt auf sda6. In der Spalte 'driver' bietet mir der Boot-Vorgang statt der verwendeten UUID eine andere Zahlenkombination an: 63e16945-06. Lässt sich damit was anfangen und wenn ja wie?

[rhHeini]

63e16945-06 liest sich wie eine 8-stellige UUID eines USB-Sticks mit FAT gefolgt von einem 06 für die 6te Partition sda6.

[grubenlicht]

63e16945-06 liest sich wie eine 8-stellige UUID eines USB-Sticks mit FAT gefolgt von einem 06 für die 6te Partition sda6.

eher nicht, bei mir jedenfalls sehen alle so aus

Code: Alles auswählen

~$ lsblk /dev/sdd -o name,uuid,fstype
NAME   UUID                                 FSTYPE
sdd                                         
└─sdd1 DFC0-92AC                            vfat

Code: Alles auswählen

~$ sudo fdisk -l /dev/sdd
Festplatte /dev/sdd: 3,73 GiB, 4009754624 Bytes, 7831552 Sektoren
Festplattenmodell: USB DISK        
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 941DC7E9-5DDD-4283-AEAC-CF300AE22E9E

Gerät      Anfang    Ende Sektoren Größe Typ
/dev/sdd1    2048 7829503  7827456  3,7G Microsoft Basisdaten

[fischig]

Ich habe meinen letzten Beitrag nochmal editiert: „lilo“ durch „Boot-Vorgang“ ersetzt.
Ok, probier ich mal, die von blkid gezeigte UUID zu ersetzen.

[grubenlicht]

Ich habe meinen letzten Beitrag nochmal editiert: „lilo“ durch „Boot-Vorgang“ ersetzt.

?
hast du jetzt "lilo" durch einen anderen Bootloader ersetzt?

[fischig]

hast du jetzt "lilo" durch einen anderen Bootloader ersetzt?

Nein, aber ich weiß nicht so recht, wer für die Bootmeldungen im jetzigen Stadium verantwortlich ist. Deswegen habe ich vorsichtshalber nicht lilo, sondern eben den „Boot-Vorgang“ als Urheber der Meldungen genannt. (Das geklonte System ist z.Z. das einzig vorhandene in der Maschine.

[fischig]

Die im Boot-Vorgang angebotene „UUID“ funktioniert leider nicht. Nehme ich dagegen den traditionellen Bezeichner /dev/sda6, dann bootet der Klon einwandfrei durch. Nutzt mir leider nix, wenn später via USB gebootet werden soll. Werd' ich vielleicht doch mal grub probieren müssen.

[grubenlicht]

ich wüßte auch nicht, daß lilo mit UUID umgehen kann (zugegeben, von lilo weiß ich so gut wie gar nichts)

[fischig]

Doch, kann er, zumindest was die UUID der System-Partition betrifft, wenn ich recht erinnere. Ich habe aber bis heute immer die traditionellen Bezeichner genommen (sda uns sdaX). Beim MBR (also der Platte als solche) funktioniert das nicht. Ob man da mit PARTUUID weiterkommt, habe ich nie probiert.

So, auf meinem aktuellen Arbeitssystem (bookworm) ist jetzt lilo durch grub ersetzt.

[grubenlicht]

also…
die Suche im Netz bringt z.B. dies zu Tage:

image = /boot/vmlinuz
append = "root=UUID=2cc11aaf-f838-4474-9d9a-f3881569f97c"
label = Linux
read-only

[fischig]

Oha! Dass man die Root-Partition für lilo in einen append-Parameter packen kann, noch dazu in einem Kernelabschnitt, hatte ich nicht erwartet. Funktioniert aber auch nicht.

Wenn ich den Lilo-Ausgangsbildschirm richtig interpretiere, dann greift der bootloader zu auf /dev/sdb, jedenfalls wirft das Kommando lilo im chroot nur eine Warnung: „root ist nicht auf der ersten Platte“, sinngemäß. Aber aufgeführt werden im Eröffnungsbildschirm nur die alten auf dem stretch laufenden Kerne. Der Bootvorgang bricht aber nach wie vor ab wegen nicht gefundener root-Partition.

[ernohl]

Mein (altes) Gedächtnis trügte mich: Hier stand Unsinn zu lilo.

[fischig]

Vielleicht ist ein Grundfehler meinerseits, dass ich darauf fixiert bin, dass der bootloader auf demselben Datenträger (nicht Partition!) sitzt, auf dem auch das Sysem sitzt. Ich kenne nur MBR und was anderes ist für mich auch z.Z. uninteressant. EFI-Maschinen besitze ich keine, ergo auch keine NOTWENDIGKEIT für GPT.

Auf der „eigentlichen“ Platte, also /dev/sda, werkelt mittlerweile grub2 im MBR. Kann ich auch das benutzen, um eine via USB angeschlossene externe Platte (oder Stick) zu booten?

[grubenlicht]

EFI-Maschinen besitze ich keine, ergo auch keine NOTWENDIGKEIT für GPT.

mal zur Info:
– Unter Linux besteht zwischen Partitionsschema msdos/GPT einerseits und BootModus "legacy"(CSM, BIOS)/EFI kein Zusammenhang.
– anders bei Windows, hier gilt: Partitionschema/Bootmodus -> msdos/"legacy" oder EFI/GPT

...grub2 im MBR. Kann ich auch das benutzen, um eine via USB angeschlossene externe Platte (oder Stick) zu booten?

na klar, dafür einen Eintrag in der /etc/grub.d/40_custom in etwa so (zwei Beispiele mit dem gleichen Ergebnis, wenn UUID von hd1,0 (sdb1) ≡ 425a672c-ca45-4e7a-8a63-faac759bdf22, einmal wird als Zwischenschritt das zugh. grub Menü aufgerufen, im anderen wird das System direkt gebootet)

Code: Alles auswählen

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "mein System auf USB " {
set root=(hd1,0)                                                                                    # hier die device Bezeichnung des Sticks
configfile /boot/grub/grub.cfg                                                                      # ruft das configfile des installierten Systems auf dem device auf
}
menuentry "mein System auf USB" {
 search --no-floppy --fs-uuid --set=root 425a672c-ca45-4e7a-8a63-faac759bdf22                       # hier die UUID der "/" auf dem Datenträger, ist besser/sicherer als die device Bezeichnung 
linux /boot/vmlinuz root=UUID=425a672c-ca45-4e7a-8a63-faac759bdf22                                  # die Position und der Name für vmlinuz muß entsprechend gesetzt werden
intrd /boot/initrd.img                                                                              # dto. für initrd.img
}

Anschließend ein update-grub.