hjslfs-1.7.45.8 ist online Buildscripts v. 06.03.21& [B]LFS-10

  • 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
    1. 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
    1. 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 ... :rolleyes:


    HJS

  • 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

  • Dein Problem mit den binutils ist wirklich seltsam. Irgendwas liegt an deinen Scripten, nicht an binutils.


    Ich habe diese Woche LFS-dev plus fast das komplette BLFS-dev für meinen VDR (x86_64) gebaut, auch mit scripts. Dito auf RPi-4 arm64, nur ohne den multimedia Kram. Dort compilieren die coreutils auf arm64 nicht, und die git Version zu bauen ist nervig wegen dependencies.


    Alles lief glatt Kernel 5.11 bootet auf Anhieb, LFS-dev absolut glatt. Bei BLFS hakte es ein wenig bei libcairo*, wo Links nicht korrekt gesetzt wurde, Firefox mag keine HW-Beschleunigung von nvidia-460 und FFmpeg war schon immer erin harter Brocken, wenn man alles rauskitzeln möchte..

  • 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