Code: Alles auswählen
# ruft das configfile des installierten Systems auf dem device auf
Code: Alles auswählen
# ruft das configfile des installierten Systems auf dem device auf
Code: Alles auswählen
#!/bin/sh
exec tail -n +3 $0
# 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 "stretch2" {
search --no-floppy --fs-uuid --set=root 7f94c57f-3707-4ec0-b6ab-3d48c7d51fdd # hier die UUID der "/" auf dem Datenträger, ist besser/sicherer als die device Bezeichnung
linux /boot/vmlinuz40935x61.0a root=UUID=7f94c57f-3707-4ec0-b6ab-3d48c7d51fdd # die Position und der Name für vmlinuz muß entsprechend gesetzt werden
}
Gerätedatei? Du meinst sicherlich Konfigurationdatei (grub.cfg)fischig hat geschrieben:29.10.2024 08:17:26Gemeint ist die Gerätedatei des Klons?Code: Alles auswählen
# ruft das configfile des installierten Systems auf dem device auf
normal schon – hab' nicht probiert, ob in einem System ohne installiertem grub (mit nur den grub Dateien) mittels grub-mkconfig -o DATEI eine passende grub.cfg erzeugt werden kann.Dazu müsste grub auch auf dem Klon installiert werden - richtig?
ja, mindestensfischig hat geschrieben:29.10.2024 10:37:09Na ja, da scheint ja noch einiges mehr zu beachten zu sein.
Code: Alles auswählen
intrd /boot/initrd.img # dto. für initrd.img
das bezieht sich ja wohl lediglich auf schreib das, was du brauchst, einfach hier ans Ende. Sagt nichts über die Komplexität der grub-Verscripterei bzw. den Programmcode mit seinen Schaltern.tut nichts zur Sache, will ich aber trotzdem mal loswerden:
„simply“, wenn ich das Wort im Zusammenhang mit IT schon lese!!! Verarschen kann ich mich selbst.
sorry, habe ich übersehen.fischig hat geschrieben:29.10.2024 20:59:22Ich benutze Eigenbaukerne von kernel.org und keine initrd. Und wie ich schon mehrfach sagte: EFI gibt's hier nicht.
Gegenfrage (um mal zu resumieren)grub.cfg (gemeint ist /boot/grub/grub.cfg - richtig?) setzt die Installation von grub voraus - denke ich. Die Frage ist also, auf welcher Platte (die Debian über Gerätedateien, also /dev/sda, sdb, etc. anspricht) dieser grub und damit grub.cfg dann sitzen soll?
dann bleibt meine o.g. Zusatzfrage dazu: Wie ist der installiert? Von "außen", wie auf den früheren post verlinkt? Oder hast du dich in strecht gechrootet und dann grub-install /dev/sdX?fischig hat geschrieben:30.10.2024 15:57:06Zu 1:
Momentan ist grub auf beiden Platten (bookworm und stretch) installiert.
Code: Alles auswählen
menuentry "stretch2" {
set root=hdx,y # Platten zählen mit "0" beginnend (für sda also hd0)
linux /boot/vmlinuz40935x61.0a root=/dev/sdx,y # Partitionen zählen mit 1 beginnend
}
Auf der internen Platte (bookworm) wurde der installiert via grub-install, auf der externen Platte (stretch) via grub-install im chroot. Ich fürchte, das führt nicht weiter, weil ich die Konfiguration des stretch-grubs nie zu Gesicht bekomme. Deswegen werde ich die 40_custom auf dem bookworm auch wieder bereinigen. Die bootet die externe Stretch-Platte jedenfalls nicht. Als noch lilo darauf war (auf dem Stretch), hat sich dieser loader auch gemeldet. Jedenfalls nehme ich anhand der angebotenen Kerne (die verständlicherweise andere sind als die im bookworm-System) an, dass ich das lilo auf der externen Platte gesehen habe. Nur leider hat der dann nicht durchgebootet. Ich könnte dank unames Hinweis auf das stretch-Archiv noch versuchen, einen Standard-Kern dort zu installieren, ob das was änderte, bezweifle ich - da das System ja funktioniert - wenn intern angeschlossen.Zusatzfrage dazu: Wie ist der installiert? Von "außen", wie auf den früheren post verlinkt? Oder hast du dich in strecht gechrootet und dann grub-install /dev/sdX?
dann muß dort in /boot/grub eine grub.cfg stehen, die alles beinhalt. Einfach mal zeigen, interessant ist halt der Abschnitt 010fischig hat geschrieben:30.10.2024 17:30:05auf der externen Platte (stretch) via grub-install im chroot.
ja, sorry, hätte "10_linux" seien sollen, also dieser Abschnittfischig hat geschrieben:31.10.2024 10:14:07Hier ist die Datei: 42246 Einen Bezeichner 010 findet featherpad darin nicht.
Code: Alles auswählen
### BEGIN /etc/grub.d/10_linux ###
function ...
[...]
linux /boot/vmlinuz-4.1.45 root=/dev/sdb6 ro quiet
}
Code: Alles auswählen
vmlinuz40935x61.0a
Code: Alles auswählen
menuentry "stretch2" {
set root=hd1,6
linux /boot/vmlinuz40935x61.0a root=/dev/sdb6
}
Code: Alles auswählen
### 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.
### END /etc/grub.d/40_custom ###
Hat mich auch gewundert. Im „Original“ (und mit lilo) benutze ich eigentlich nur einen 4.9er und einen 4.19er. Aber egal „autonom“ findet grub hier/auf meinen Maschinen meistens eh nicht alle bootbaren Kerne. Aber das ist dann wohl eine neue Baustelle.grubenlicht hat geschrieben:31.10.2024 10:55:15dieser kernel sieht mir aber nicht nach einem Selbstbau aus, (und dann gibt es hier auch kein initrd?!)
Welche Überlegung (?) steckt hinter dem Beharren auf stretch? Dieses release ist tot, unsupportet und hat sein letztes security update am 18 July 2020 bekommen. Wäre es nicht sinnvoll (wenn du nicht das Originalsystem hochziehen willst) erstmal einen clone auf HDD anzulegen und diesen hochzuziehen auf irgendetwas was noch supportet ist?
Um Nostalgie geht's mir ganz gewiss nicht.Welche Überlegung (?) steckt hinter dem Beharren auf stretch?
Code: Alles auswählen
grub-install --target=i386-pc --boot-directory=/mnt/boot /dev/sdX
sorry, aber "das System" ? ? ? (die ext. Platte mit stretch?)fischig hat geschrieben:31.10.2024 17:53:22edit: Gerade nochmal ausprobiert: im chroot fstab und reaktiviertes lilo auf sda und sda6 gesetzt, bootet das System mit intern angeschlossener Platte. Gerade schreibe ich hier damit.
Ich sagte doch: Intern angeschlossen. Das ging an michaa7, der ja die Sinnhaftigkeit der Verwendung von stretch im Jahre des Herrn 2024 anzweifelt, um ihm zu zeigen, dass mein personalisiertes stretch als solches durchaus funktioniert - mit lilo und „normal“, also intern, angeschlossen.sorry, aber "das System" ? ? ? (die ext. Platte mit stretch?)
Michaa7 hat's wohl interessiert.Was interessiert es denn, ob das unter anderen Bedingungen läuft?
das ist die von mir gepostete grub.cfg. Ein Menü erkenne ich da nicht. Wenn ich recht erinnere, startet grub defaultmäßig ohne Menü. Wär' mir erst mal auch egal, wenn er denn überhaupt startete und ich irgendwie nachvollziehen könnte, was er denn startet.kriegst du denn überhaupt das grub Menü zu sehen?
Zumindest wird kein Menü angezeigt, wennfischig hat geschrieben:31.10.2024 23:37:59Ein Menü erkenne ich da nicht. Wenn ich recht erinnere, startet grub defaultmäßig ohne Menü.
Code: Alles auswählen
set timeout=0
ja, ja, aber dieser Nebenschauplatz lenkt doch nur von der Problemlösung ab!fischig hat geschrieben:31.10.2024 23:37:59Michaa7 hat's wohl interessiert.Was interessiert es denn, ob das unter anderen Bedingungen läuft?
Da frage ich mich, woran du das erkennst. In der grub.cfg steht jedenfalls kein Eintrag mit deinem kernel.das ist die von mir gepostete grub.cfg. Ein Menü erkenne ich da nicht.
Code: Alles auswählen
GRUB_TIMEOUT_STYLE=menu
Ob denn grub überhaupt und was und von wo da gebootet wird, kannst du ggf. mit dem https://github.com/arvidjaar/bootinfoscript herausfinden.Wär' mir erst mal auch egal, wenn er denn überhaupt startete und ich irgendwie nachvollziehen könnte, was er denn startet.
deine Entscheidung, ich lasse für Gewöhnlich solange keine Ruhe, bis das Problem (booten von ext. Platte) dann auch (irgendwie) gelöst ist.Ich denke, wir lassen es.
Das hast jetzt DU gesagt, darüber kann ich mir kein Urteil erlauben. Aber auch grub ist kein Hexenwerk, lediglich ziemlich komplex.Ich bin wohl zu dumm für grub und dich.
Wage ich zu bezweifeln. Wenn da falsche Angaben für die Systempartition drinstehen, wird das System nicht durchbooten - meine Erfahrungen, zumindest mit lilo. Ob das für grub nicht gilt, weiß ich nicht.grubenlicht hat geschrieben:die (fstab) hat doch mit dem Bootvorgang überhaupt nichts zu tun.
Code: Alles auswählen
grub2_2.02~beta3-5+deb9u2_amd64.deb
grub2-common_2.02~beta3-5+deb9u2_amd64.deb
grub-common_2.02~beta3-5+deb9u2_amd64.deb
grub-pc_2.02~beta3-5+deb9u2_amd64.deb
grub-pc-bin_2.02~beta3-5+deb9u2_amd64.deb
also… Daß in der fstab natürlich die richtige UUID (oder /dev) für die aufgeführten zum jeweiligen System gehörenden Partitionen stehen müssen, ist außer Frage. Wenn du also einmal einen Klon erstellt hast auf einer anderen Platte mit dort eingerichteten Partitionen (und dann z.B. mit rsync die Dateien überspielt hast), dann mußt du natürlich die fstab anpassen. Das ist aber ein einmaliger Vorgang, der mit dem Bootvorgang nichts zu tun hat.fischig hat geschrieben:01.11.2024 15:02:27Wage ich zu bezweifeln. Wenn da falsche Angaben für die Systempartition drinstehen, wird das System nicht durchbooten - meine Erfahrungen, zumindest mit lilo. Ob das für grub nicht gilt, weiß ich nicht.die (fstab) hat doch mit dem Bootvorgang überhaupt nichts zu tun.
Code: Alles auswählen
GRUB_TIMEOUT_STYLE
Code: Alles auswählen
GRUB_TIMEOUT=0
Code: Alles auswählen
deb http://archive.debian.org/debian/ stretch main contrib non-free
deb http://archive.debian.org/debian/ stretch-proposed-updates main contrib non-free
deb http://archive.debian.org/debian-security stretch/updates main contrib non-free
dann empfehle ich dir einen Blick in das Ubuntu Wiki
¹⁾Die Erstellung der GRUB-2-Konfigurationsdatei, aus der GRUB 2 die Einstellungen für die Darstellung des GRUB-Auswahl-Menüs während des Systemstarts bezieht, ist standardmäßig vollständig automatisiert.
...
Wer als Anwender ohne weitergehende Computer-Kenntnisse bei "eigens dafür entwickelten Skriptsprache" bereits Panik bekommt, kennt nun bereits einen Grund, warum die GRUB-Macher das Erstellen dieser Konfigurationsdatei standardmäßig automatisiert haben: Man erspart dem Benutzer damit, sich mit dieser Skriptsprache auskennen zu müssen.