Posts by hjs

    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

    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"

    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 :rolleyes:


    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 :gap


    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 :gap ), 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 ... :rolleyes:


    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

    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:

    Code
    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:

    Code
    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