hjslfs-1.7.57.2 ist offline

Quote from wirbel

Für EFI muss auch die Partitionierung passen. Geprüft?

Habe nur die Version vom .efi zum Verzeichnis "geschubst", wie oben beschrieben, alle anderen vars identisch - langes Verzeichnis geht, langes efi nicht

so gehts:

mk_efiboot() { mkdir -pv /boot/efi/EFI/{,hjslfs-${var[41]}} ; cp /boot/bzImage /boot/efi/EFI/hjslfs-${var[41]}/hjslfs.efi ; efibootmgr -c -d ${var[19]} -l \\EFI\\hjslfs-${var[41]}\\hjslfs.efi -L "${var[3]} auf ${var[0]}" ; }

so nicht:

mk_efiboot() { mkdir -pv /boot/efi/EFI/{,hjslfs} ; cp /boot/bzImage /boot/efi/EFI/hjslfs/hjslfs-${var[41]}.efi ; efibootmgr -c -d ${var[19]} -l \\EFI\\hjslfs\\hjslfs-${var[41]}.efi -L "${var[3]} auf ${var[0]}" ; }

HJS

Edit: Wobei die 41 die Kernelversion ( aktuell 5.10.15) und die 19 selbstverfreilich die UEFI Partition ist.

Beides erzeugt die jeweiligen Verzeichnisse und .efi, sowie den Eintrag, der Erste führt zum erfolgreichen Boot, der Zeite bootet den nächsten Eintrag aus der Liste.

So - hab extra nochmal gecheckt

- Name=$(date +%d%m%y%H%M) ist Format 10.3 (mit dem .efi) und bootet den nächsten Eintrag der Liste.

- Name=$(date +%d%m%y%H) ist Format 8.3 und bootet den gewünschten Eintrag.

Der Defaultname bootx64.efi liess ja was in der Art auch schon vermuten ...

HJS

Sodele - die 1.7.45.8 sollte alles was sie anbietet auch können

Momentan gibts 3 Buildscript-"Familien".

[B]LFS-10 , [B]LFS-SVN und n "Zwischending" mit LFS vom 16.1.21, BLFS Dev.

Die 10 ist für die "Konservativen" das Zwischending für modern aber moderates Buildrisiko, und SVN/DEV für die "Alles-oder-Nichts"

Seitdem auf binutils >=2.36 gewechselt wurde, erleb ich ganz merkwürdige Fehler.

- binutils-pass2 geht inne Büx, Kernel baut nicht, binutils-pass2 ein zweites Mal geht, Kernel trotzdem nich - whyever

- baut alles weitestgehend fehlerfrei, login nicht möglich ([Wirk-]Ursache vermutlich beim shadowbuild)

Da ich genug andere Baustellen hab, gibbet halt besagte drei Familien

Mittlerweile steht für die Bootconfig refind (jetzt auch erfolgreich ), gebauter Kernel auf UEFI Partition, Default als bootx64.efi oder per efibootmgr Eintrag.

Grub weigert sich, seine .cfg zu finden - spätere Baustelle.

Hat man sich einen Tarball des Builds erstellen lassen, kann man den dann beim erneuten Anstossen der Scripte bleistiftsweise auf einen Stick bootfähig installieren - der Kernel wird nochmal gebaut - da das Resultat des ursprünglichen Builds ja im Tarball ist, geht das recht zügig - sofern man nicht manigfaltige Änderungen vorgenommen hat.

Erforderliche Änderung ist in der Kernel-Cmdline "bootwait" für USB hinter den root-Eintrag.

Partlabel wird jetzt in fstab und Kernel verwendet - dachte mir, wenn UUID geht (nich im Kernel, nur fstab), muss auch PARTLABEL gehen - jo

HJS

Naja - tendenziell stimme ich Dir zu - der Fehler ist fast immer ein "Kopfhörer-Fehler".

Aber hab grad den Build mit den Scripten der "A"-Version von heute laufen lassen - alles picobello.

Bootet den richtigen Kernel, login funzt ... obwohl weder config-scripts noch Parser irgendeine Änderung erfahren haben

Ein Problem der Maschine halte ich auch mal für unwahrscheinlich - wenn ich in der Vergangenheit dem Proz zuviele Hertzen bei zuwenig Spannung (für die Hertzen) abverlangt hab, kackte der typischerweise sehr früh schon in gcc-pass1 ab.

Zu strenges Timing beim RAM führte bisher IMMER zu "Segmentation Fault" - beides war bei den o.g. Fehlern nicht der Fall ...

However - werds schon rausfinden.

HJS

PS LFS vom 2.3., BLFS von heute

Das Kriegsbeil zwischen mir und grub2 scheint begraben.

Mittlerweile bring ihn den Jung sogar dazu, im BIOS und im UEFI Mode zu booten

Selbstverfreilich nur entoderweder

HJS

Quote from hjs

Das Kriegsbeil zwischen mir und grub2 scheint begraben.

Die Betonung liegt auf "scheint.

UEFI Variante is gut, BIOS Variante (i386-pc) führt mit dem gleichen Kernel zum Laden des Kernels und irgendwo bleibt er dann mit grünem Screen hängen.

Besonders innovativ fand ich die Message am 64Bit-BIOS system:

Grub Rescue erschien auf der Bildfläche mit dem Kommentar, "Versuch Sektoren von hd0 zu lesen/schreiben, die ausserhalb der Reichweite sind"

Wo schreibt sich grub in BIOS Version hin, dass er diese Sektoren auf nem alten Sys plötzlich nicht mehr finden kann - wenn man bedenkt, dass er auf ner BiosBoot Partition am Anfang der Platte sitzt?

Was macht n aktueller SATA3 Controller anders als n alter SATA1? (Platte Exos X16 14TB)

HJS

Yep, sonst krieg ich ja keine partition > 2TB hin

Nö, wo hätte ich?

Ist sda1, bios-boot, Kennung sollte also automatisch passen, 16 MB, Nicht formatiert, nicht gemountet

GUID?

Ein erstes VDR Script ist dabei.

Kopiert die Libs allerdings noch nicht.

HJS

Hm - die Jungs haben mal wieder die "Dareichungsform" geändert.

Inner knappen Stunde weiss ich, ob der Parser erfolgreich angepasst ist 😁

Quote from hjs

Die Betonung liegt auf "scheint.

UEFI Variante is gut, BIOS Variante (i386-pc) führt mit dem gleichen Kernel zum Laden des Kernels und irgendwo bleibt er dann mit grünem Screen hängen.

In diesem Punkt bin ich nu n Stück weiter.

Sieht sehr danach aus, als wenn ein Kernel, der direkt durchs EFI oder einen EFI-Loader geladen werden kann, entweder durch grub-pc nicht sauber geladen/reloziert wird oder sich in irgendeiner Form selbst ein Bein stellt.

Config um den EFI(-stub) Teil erleichtert und der Kernel fährt sauber hoch.

Leider bedeutet das, dass man keinen Allrounder bauen kann 🥴

HJS

PS Die Buildscipts sind wieder "sauber"

Sodele, die 1.7.52.3 mit Scripts vom 9.5 löppt durch, sowohl mit den Buildscripts für 10.0 als auch 10.1

Die Jungs haben den Fehler in Binutils offensichtlich auch gefunden - der Workaround reduziert den Install auf singlecore.

HJS

Du meinst -j1 ?!

Klar 😉

Schön, dass ich keinen Fehler eingebaut habe, der kommt und geht, wie es ihm beliebt 🙄