staging.inyokaproject.org

Hej,

kann jemand bestätigen, daß grub 2.04 einen solchen Eintrag

### BEGIN /etc/grub.d/40_custom ###
# 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 "focal-desktop-amd64" {
   insmod part_gpt
   insmod ntfs
   insmod fat
   insmod loopback
   set root=(hd0,2)
   loopback loop /focal-desktop-amd64.iso
   linux (loop)/casper/vmlinuz boot=casper ramdisk_size=2097152 root=/dev/ram rw locale=de_DE bootkbd=de console-setup/layoutcode=de iso-scan/filename=/focal-desktop-amd64.iso
   initrd (loop)/casper/initrd 
}
### END /etc/grub.d/40_custom ###

eben nicht gebootet bekommt, wenn der PC im EFI Modus läuft?

(im "legacy" Modus funktioniert das sehr wohl)

Gruß black tencate

Hi

Kann ich so nicht bestätigen, ich habe die Live CD wie folgt eingebunden: /etc/grub.d/15_isoboot

#!/bin/sh -e

iso="/ubuntu-mate-20.04-desktop-amd64.iso"
echo "Füge \"$iso\" hinzu" >&2
cat << EOF
menuentry 'Ubuntu Mate 20.04 Live CD' {
    insmod part_gpt
    insmod ext2
    insmod iso9660
    search --no-floppy --fs-uuid --set=root af3ebde8-f5dd-4873-8768-ae3100063b37
    loopback loop $iso
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$iso nosplash locale=de_DE bootkbd=de console-setup/layoutcode=de --
    initrd (loop)/casper/initrd
}
EOF

Das habe ich seit 18.04 so laufen, auch nach Upgrade auf 20.04 startet diese im EFI Mode. Was passiert bei dir? Bootet das gar nicht?

Gruß TNT

Also ein .iso hab ich wie folgt ins Grub-Menü via 40_custom eingebunden:

menuentry "Lubuntu 20.04-64-Bit-ISO" { 
 insmod part_msdos 
 insmod ext2 
 insmod lzopio
 insmod gzio
 gfxpayload=$linux_gfx_mode 
 set isofile=/boot/lubuntu/focal-desktop-amd64.iso
 loopback loop (hd0,6)$isofile
 linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject 
 initrd (loop)/casper/initrd
 }
 

Das war die Entwicklerversion von Lubuntu 20.04 → ich hab das seinerzeit erst zum Booten überreden können, als ich es nach /boot verschoben hatte, unabhängig von UEFI oder BIOS.

black_tencate schrieb:

[…] kann jemand bestätigen, daß grub 2.04 einen solchen Eintrag […]

Hast Du insmod iso9660 versucht?

Hej,

Frieder108 schrieb:

... Entwicklerversion von Lubuntu 20.04 → ich hab das seinerzeit erst zum Booten überreden können, als ich es nach /boot verschoben hatte, unabhängig von UEFI oder BIOS.

hmm, was sollte das für einen Unterschied machen, aber ich werd 's mal testen

TNTMaster schrieb:

... Das habe ich seit 18.04 so laufen, auch nach Upgrade auf 20.04 startet diese im EFI Mode.

und Du bist sicher, auch grub geupdatetet zu haben auf 2.04 (nur mal so gefragt, sieht man im grubmenu ganz oben)

Was passiert bei dir? Bootet das gar nicht?

im EFI Modus bekomme ich einen "stillstehenden" cursor oben links, ich probier mal noch mit mehr Geduld. Im "legacy" Modus blinkt der cursor, und nach einer gefühlten EWIGKEIT habe ich dann Ubuntu 20.04. Das sieht fast so aus, als wollte grub die ewiglangdauernde Startzeit und anschließende ENDLOSEN (nicht abschaltbaren?) checks aller Dateien "verheimlichen"?!

kB schrieb:

... Hast Du insmod iso9660 versucht?

Gegenfrage: Hast Du einen Hinweis für mich parat, wo ich die Bedeutung der ganzen *.mod nachlesen kann? Der eine oder andere ist ja selbsterklärend, andere aber eben (für mich) nicht.

Aber: Kein einziges "insmod" wird bei mir verwendet unter grub 2.02, funktioniert trotzdem.

Gruß black tencate

und Du bist sicher, auch grub geupdatetet zu haben auf 2.04 (nur mal so gefragt, sieht man im grubmenu ganz oben)

Yep, da steht: "GNU GRUB Version 2.04", das Paket hat Version 2.04-1ubuntu26

im EFI Modus bekomme ich einen "stillstehenden" cursor oben links, ich probier mal noch mit mehr Geduld. Im "legacy" Modus blinkt der cursor, und nach einer gefühlten EWIGKEIT habe ich dann Ubuntu 20.04. Das sieht fast so aus, als wollte grub die ewiglangdauernde Startzeit und anschließende ENDLOSEN (nicht abschaltbaren?) checks aller Dateien "verheimlichen"?!

Was mir jetzt noch einfällt, ich wollte mal ein iso im EFI Mode booten, das auf einer Platte mit msdos Partitionsschema in einer ext4 Partition lag. Das startete tatsächlich nicht, insmod part_msdos habe ich natürlich hinzugefügt. Wenn ich mich recht erinnere, kam da aber ne Meldung wie xy.iso NOT found. Hab dann aber nicht länger rumprobiert und das iso auf eine GPT partitionierte Platte kopiert, das funktionierte dann. Kann das auch nicht mehr nachstellen, da jetzt alle Platten auf GPT sind.

black_tencate schrieb:

[…] kB schrieb:

... Hast Du insmod iso9660 versucht?

Gegenfrage: Hast Du einen Hinweis für mich parat, wo ich die Bedeutung der ganzen *.mod nachlesen kann?

Ich kenne nur: https://www.gnu.org/software/grub/ Oft hilfreich, aber auch da wird nicht alles erklärt.

Zu insmod iso9660 ist meine Meinung: Grub kann nicht von sich aus jedes Dateisystem lesen. Die Unterstützung für bestimmte Dateisysteme kann bei der Installation in die Datei /boot/grub/*/core.img (das Programm, welches beim Rechnerstart als GRUB gestartet wird) eingebunden werden oder vom gestarteten GRUB über den insmod-Befehl nachgeladen werden. Jedenfalls kann GRUB erst dann ein Dateisystem lesen, wenn die jeweilige Dateisystemunterstützung geladen ist. Dies gilt ähnlich auch für die Unterstützung von Partitionsschemata.

Aber: Kein einziges "insmod" wird bei mir verwendet unter grub 2.02, funktioniert trotzdem.

Wenn bei der Installation die Module bereits in core.img eingebunden wurden, ist ein Nachladen ja auch nicht erforderlich. Das kann aber durchaus von der Grub-Version und von der Situation des Rechners abhängen, auf dem GRUB installiert wurde. Bei der Installation von GRUB kann man angeben, welche Module man eingebunden haben möchte. Man sollte nicht einfach alle angeben, weil es eine Obergrenze für die Dateigröße von core.img gibt.

core.img ist also individuell. Ich habe mir angewöhnt, immer explizit das Partitionsschema und das Dateisystem als Grub-Modul zu laden, bevor ich es in GRUB verwende. Schaden, abgesehen vom minimalen Zeitverlust, kann das m.E. nicht verursachen.

Aber: Kein einziges "insmod" wird bei mir verwendet unter grub 2.02, funktioniert trotzdem.

Einige Module werden ja in der grub.cfg global geladen und müssen dann nicht mehr für jedes menuentry angegeben werden, so z.B.

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2

Hej kB,

kB schrieb:

... core.img ist also individuell.

hmm, woher soll es das denn "wissen", auf welchem Dateisytem das ganze abläuft. core.img liegt entweder (BIOS) auf dem Bereich hinter dem MBR, vor der ersten Partition, oder, im Falle EFI - bei dem stand-alone grub jedenfalls - auf der FAT32 esp

Anmerkung: Vielleicht hätte ich sagen sollen, daß es (eigentlich) um einen stand-alone grub geht, also ganz ohne Linux/Ubuntu.

Mit 2.02 hatte ich bisher wie gesagt kein einziges Modul nachladen müssen, außer für die Grafikdarstellung (s. auch → Universal stand-alone grub für BIOS und EFI auf USB flashkey und internen HDD und SSD

Was ich jetzt mal "probiert" habe zwecks Fehlereingrenzung:

• PC im EFI Modus

• grub Konsole (Taste C )

• dann set root=(hdx,y) gefolgt von

• loopback loop /Pfad/*.iso-file

  • das hängt, passiert nichts, auf verschiedenen Rechnern

Gruß black tencate

black_tencate schrieb:

[…] woher soll es das denn "wissen", auf welchem Dateisytem das ganze abläuft.

Es weiß das nicht und es muss das auch nicht wissen.

core.img liegt entweder (BIOS) auf dem Bereich hinter dem MBR, vor der ersten Partition, oder, im Falle EFI - bei dem stand-alone grub jedenfalls - auf der FAT32 esp

core.img liegt:

1. Entweder außerhalb eines jeden Dateisystems, vorzugsweise dann auf der Platte anschließend an den MBR (= erster Sektor = LBA 0) im LBA 1. Man benutzt dann die Bios-Boot-Methode. Im MBR gibt es ein kleines Programm, welches weiß, in welchem Sektor es den Anfang von core.img findet. Dieser Sektor wird geladen und gestartet. Alles weitere macht core.img selber.

2. Oder als Datei innerhalb eines Dateisystems „eingebettet“. Dann gibt es bei der Bios-Boot-Methode mehrere Varianten:

   1. Direkt: Das kleine Programm im MBR benutzt vorstehende Methode 1, nur mit einem anderen Anfangssektor als LBA 1). core.img wird also am Dateisystem vorbei geladen.

   2. Chainload: Das kleine Programm im MBR startet den ersten Sektor einer Partition, also einen PBR. In diesem befindet sich ein kleines Programm, welches wie bei 2.1 vorgeht.

core.img wird also bei der Bios-Boot-Methode als Blockliste immer am Dateisystem vorbei geladen. core.img weiß aber aus dem Installationsprozess, wo seine Konfigurationsdatei grub.cfg liegt und die Unterstützung für den benötigten Dateisystemtyp wurde ihm eingeimpft. Daher kann core.img seine Konfigurationsdatei lesen und abarbeiten. Ein solcher GRUB, auf einem Linux gebaut, kann in der Regel ext2 lesen, aber nicht notwendigerweise VFAT oder ISO9660.

Bei der EFI-Boot-Methode liegt dagegen core.img immer als Datei in einem VFAT-Dateisystem. Das UEFI-Bios kan das Dateisystem VFAT lesen, lädt also core.img als Datei und starte es. Ein solcher GRUB kann VFAT lesen, aber nicht notwendigerweise ext2 oder ISO9660.

Du kannst natürlich beim Bau von core.img Deinem GRUB weitere Fähigkeiten mitgeben. Aber alles, was es nicht kann, kann und muss es sich über die grub.cfg als Modul laden.

Anmerkung: Vielleicht hätte ich sagen sollen, daß es (eigentlich) um einen stand-alone grub geht, also ganz ohne Linux/Ubuntu.

Das war mir schon klar. Es ist hier aber unerheblich.

Mit 2.02 hatte ich bisher wie gesagt kein einziges Modul nachladen müssen […]

Was ein bestimmter GRUB kann, hängt davon ab, in welcher Umgebung er erstellt wurde. Und verschiedene Versionen verhalten sich oft unterschiedlich.

[…] loopback loop /Pfad/*.iso-file

loopback ist auch so ein Modul, welches entweder bei der Installation mit eingebunden oder über grub.cfg geladen werden muss.

Das trifft übrigens auch auf chainload zu. Und der Start einer ISO ist eine Art von Chainload, welche unter EFI prinzipbedingt nicht funktioniert. Möglicherweise ist das die Ursache Deines Problems, aber jetzt betrete ich das unbekannte Land der Spekulationen.

Hej kB

kB schrieb:

... loopback ist auch so ein Modul, welches entweder bei der Installation mit eingebunden

weder mit

sudo grub-install --target=x86_64-efi --recheck --removable --efi-directory=/mnt --boot-directory=/mnt/boot 

für EFI sehe ich da etwas von Modulladen, noch

oder über grub.cfg geladen werden muss.

tue ich das hinterher, trotzdem funktioniert es. Dto bei MBR/MPT

Das trifft übrigens auch auf chainload zu. Und der Start einer ISO ist eine Art von Chainload, welche unter EFI prinzipbedingt nicht funktioniert.

na, das halte ich doch glatt für ein "Gerücht", eine iso auf einem EFI PC mittels loopback zu starten, ist hier mein "täglich Brot", nur unter grub 2.04 will das nicht mehr, hier jedenfalls, bei Frieder108 TNTMaster scheint es ja doch zu funktionieren.

Im Anhang mal meine stand-alone grub Konfiguration auf 2 Platten verteilt, auf sda alles, was grub ist, auf sdb dann die O/Sen. Da sind keinerlei Module (außer für Grafik und Bilder) geladen.

Und im "legacy" Modus kannst Du die grub-Dateien auf alle möglichen Dateisysteme pflanzen (FAT, ntfs, ext4, andere habe ich nicht probiert), und wo dann ein iso-file liegt, ist auch wumpe.

Zieh Dir so ein EWMS.img, streiche alles Beiwerk heraus und teste es auf einem Stick.

Ich teste z.Z. mit grub 2.04 auf GPT, da funktioniert alles soweit im "legacy" Modus (auch, wenn das Booten "schweinelange" dauert), nur eben im EFI Modus nicht. Die 'einfachere' Variante mit msdos Partitionierung muß ich jetzt doch mal zum Vergleich noch nachholen.

Gruß black tencate

black_tencate schrieb:

[…]

Was soll das?

Ich habe Dir nur einen Hinweis gegeben auf etwas, was bei Deinem Problem eine Rolle spielen könnte. Du hättest es einfach ausprobieren können. Statt dessen fängst Du einen Glaubenskrieg an über etwas, was nach Deiner Meinung nicht sein kann.

Ich habe kein Bock auf diesen Bullshit!

Ich bedaure durch meinen Hinweis versucht zu haben, Dir zu helfen. Ich bedaure auch, versucht zu haben, Dir die Zusammenhänge zu erklären. Bitte vergesse das alles.

Im Gegenzug verspreche ich Dir für die Zukunft zu vergessen, Dir helfen zu wollen.

kB schrieb:

black_tencate schrieb:

[…]

Was soll das?

krieg Dich bitte wieder ein

Ich habe Dir nur einen Hinweis gegeben...Du hättest es einfach ausprobieren können.

genau, und den habe ich natürlich ausprobiert, und 'ne ganze Reihe anderer gleich mit.

 menuentry "focal-desktop-amd64" {
insmod iso9660
insmod part_msdos
insmod ext2
   insmod part_gpt
   insmod ntfs
   insmod fat
   insmod loopback
   set root=(hd0,2)
   loopback loop /boot/focal-desktop-amd64.iso
   linux (loop)/casper/vmlinuz boot=casper  iso-scan/filename=/focal-desktop-amd64.iso
   initrd (loop)/casper/initrd 
}

Leider ohne Erfolg

...Glaubenskrieg an über etwas, was nach Deiner Meinung nicht sein kann.

ich habe lediglich Deiner Behauptung
kB schrieb:

... Das trifft übrigens auch auf chainload zu. Und der Start einer ISO ist eine Art von Chainload, welche unter EFI prinzipbedingt nicht funktioniert. Möglicherweise ist das die Ursache Deines Problems, aber jetzt betrete ich das unbekannte Land der Spekulationen.

man könne auf einem EFI System ein iso-file NICHT starten, widersprochen. Da wird nichts spekuliert, das funktioniert tadellos bis grub 2.02. Bei grub 2.04 mit einem GPT Partitionsschema und EFI aus irgendeinem Grund auf meinen PCs nicht.

[...]

den Rest kannst du dir schenken.

black_tencate schrieb:

… nur unter grub 2.04 will das nicht mehr, hier jedenfalls, bei Frieder108 TNTMaster scheint es ja doch zu funktionieren.

(Zitat von mir angepasst)

Ich hätte richtig lesen sollen - ich hab das unter 18.04 eingerichtet, also mit Grub 2.02 → ja sorry, ein 20.04 als Verwaltungssysten hab ich noch nicht → bin dann erst mal raus, aber lese weiterhin interessiert mit. 😉

Schönes Wochenende und bleibt gesund. 👍

Hej,

ufff, Fehler gefunden: 1851311 → #51

rmmod tpm

Gruß black tencate