Beiträge von hjs

Im eigentlichen Sys ja, der Host bauts mit Prefix /usr und hat's bisher dann nach /bin verschoben

https://www.linuxfromscratch.o…pment/chapter06/bash.html

irgendwann seit Umbenennung von SVN zu 10.1-r[xy] nicht mehr

Grmpf

Aus unbekanntem Grund, meinen die Jungs jetzt, das Verschieben von /usr/bin/bash nach /bin/bash sei nicht mehr nötig ....

Welcher Art Massnahmen willste denn da ergreifen?

Kontrolle der angelieferten codes via Stichwortsuche?

Die "Forscher" hätten auch einen lokalen Branch patchen können, um potentielle Auswirkungen zu "erforschen"

Das Projekt Linux in dieser Form zu torpedieren ist ein Verhalten, das mich an deren Intelligenz und Integrität zweifeln lässt.

Klar 😉

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

Du meinst -j1 ?!

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

Zitat von 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"

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

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

Ein erstes VDR Script ist dabei.

Kopiert die Libs allerdings noch nicht.

HJS

Nö, wo hätte ich?

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

GUID?

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

Zitat von 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

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

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

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

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, nach Exkurs über setzen der UUID schon beim formatieren der Platte, dem Anpassen der PARTUUID (da der Kernel numal nix mit der FSUUID anfangen kann), sich auch PARTLABEL mittels sfdisk auf einer Partition auf der aktuellen Root-Pladde setzen lässt, dem Vorteil der sich halt so ergibt, wenn FS Label und PARTLABEL identisch sind (refind zeigt FS Label) und der Feststellung das auch in der fstab "PARTLABEL=" zum gewünschten Erfolg führt, bin ich nu wieder beim Partlabel angekommen.

mit "root=PARTLABEL=<MyLabel> [rootwait]" als Kernelcommandline und "PARTLABEL=<MyLabel> ext4 default 1 1" in der fstab, isses schnurz wie oft ich welche pladde wohin schieb, entferne, dazusteck, von USB boote ... ES KLAPPT!

HJS

Zitat von 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.

Grmpf - boot von /EFI/hjslfs-1.7.42.x/hjslfs.efi macht er, /EFI/hjslfs/hjslfs.1.7.42.x.efi macht er nicht.

Ist die Anzahl der Punkte in FAT32 limitiert oder ist nur das UEFI auf der Maschine etwas buggy?

Naja - HP ist der Meinung einen neuen Eintrag zu erstellen sei ja noch OK, aber wenn man will, dass der auch tatsächlich vorne in der Bootfolge steht, muss man das schon via deren Setup einstellen ... mag ja am NB noch sinnig sein, da hats keinen Mastereset um das "unbootbare" wieder zu reanimieren.

Immerhin klappt ja noch bootnext

HJS