Debian Sid auf UEFI umstellen

[Marco Moock]

Hallo zusammen,

ich habe ein neues Mainboard, das kann nur UEFI.
Ich muss ein Debian Sid umstellen. Der Plattencontroller für die
Systemplatte kann nicht per UEFI booten, ergo muss der Kram auf die
am MoBo angeschlossene SATA-Platte. Ich hatte damals eine GPT erstellt.
Drauf sind 2 Partitionen, /boot und ein LUKS-Container (ohne LVM) für /.

Was muss nun genau gemacht werden, damit das klappt?
Reicht es, die ESP auf die SATA-Platte anzulegen?
Die bios_grub-Partition braucht man nicht, oder?

Hat das wer unter Debian schonmal gemacht und kennt die
Schritte/Fallstricke?

Für Ubuntu gibt es
https://wiki.ubuntuusers.de/GRUB_2_von_BIOS_nach_EFI_umstellen/
Funktioniert das so auch bei Debian?

--
Gruß
Marco

[Gerald E¡scher]

Marco Moock schrieb am 26/1/2023 22:07:

> ich habe ein neues Mainboard, das kann nur UEFI.
> Ich muss ein Debian Sid umstellen. Der Plattencontroller für die
> Systemplatte kann nicht per UEFI booten, ergo muss der Kram auf die
> am MoBo angeschlossene SATA-Platte. Ich hatte damals eine GPT erstellt.
> Drauf sind 2 Partitionen, /boot und ein LUKS-Container (ohne LVM) für /.
>
> Was muss nun genau gemacht werden, damit das klappt?

Habe ich hier am 13.4.2021 unter dem Subject "(X)ubuntu von BIOS/MBR auf
UEFI/GPT umziehen" gepostet. MID kann ich leider keine nennen, XPN
archiviert die anscheinend nicht. Daher bitte auf Gurgel Groups
suchen.

> Reicht es, die ESP auf die SATA-Platte anzulegen?

Reicht nicht.

> Die bios_grub-Partition braucht man nicht, oder?

Nein, was ist das?

> Hat das wer unter Debian schonmal gemacht und kennt die
> Schritte/Fallstricke?

Unter Xubuntu, sollte bei Debian aber nicht anders laufen.

> Für Ubuntu gibt es
> https://wiki.ubuntuusers.de/GRUB_2_von_BIOS_nach_EFI_umstellen/

Die EFI-Partition habe ich per kunstvollem Aufruf von grub-install
mit einem Rattenschwanz an Parametern eingerichtet. Anscheinend geht das
in einer chroot-Umgebung einfacher.

--
Gerald

[Gerald E¡scher]

Gerald E¡scher 'Ingrid' schrieb am 27/1/2023 00:23:

> Marco Moock schrieb am 26/1/2023 22:07:
>
>> Was muss nun genau gemacht werden, damit das klappt?
>
> Habe ich hier am 13.4.2021 unter dem Subject "(X)ubuntu von BIOS/MBR auf
> UEFI/GPT umziehen" gepostet.

War nicht hier sondern in dcoulm.

--
Gerald

[Friedemann Stoyan]

Marco Moock wrote:


> Was muss nun genau gemacht werden, damit das klappt?
> Reicht es, die ESP auf die SATA-Platte anzulegen?
> Die bios_grub-Partition braucht man nicht, oder?

Du brauchst eine ESP Partition. Die kann auch ganz klein sein, da da im
Prinzip nur eine kleine Datei (vom Grub) liegt:

$ sudo tree -h /boot/efi/
/boot/efi/
└── [2.0K] EFI
└── [2.0K] debian
└── [140K] grubx64.efi

Natürlich brauchst Du auch /boot. Da liegen die Grub-Module, Config und
Kernel+Initrd. Ich hatte erst kürzlich einen Fall, da war die ESP "weg/leer".
Die Schritte zur Reparatur habe ich mir da aufgeschrieben:

* Notfallsystem (SystemRescue) booten
* Filesysteme mounten:

mkdir /debian
mount /dev/mapper/rvg-root /debian
mount /dev/nvme1n1p2 /debian/boot
mount /dev/nvme1n1p1 /debian/boot/efi
mount /dev/mapper/rvg-usr /debian/usr

(Ob man /usr braucht weiss ich nicht genau. Ich habe es mal mit gemountet.)

Ebenso Spezialfilesysteme mounten:

mount --bind /sys /debian/sys
mount --bind /proc /debian/proc
mount --bind /dev /debian/dev
mount --bind /dev/pts /debian/dev/pts
mount --bind /sys/firmware/efi/efivars /debian/sys/firmware/efi/efivars

* Chrooten
chroot /debian

* Grub neu installieren:
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Debian

* EFI Variablen checken:
efibootmgr -v

* Filesystem UUID checken und ggf. in der /etc/fstab anpassen:
lsblk -f

* umounten:
umount -R /debian

Hat bei mir genau so geklappt.

mfg Friedemann

[Marco Moock]

Am 26.01.2023 23:23 schrieb Gerald E¡scher:

> Marco Moock schrieb am 26/1/2023 22:07:
>
> > ich habe ein neues Mainboard, das kann nur UEFI.
> > Ich muss ein Debian Sid umstellen. Der Plattencontroller für die
> > Systemplatte kann nicht per UEFI booten, ergo muss der Kram auf die
> > am MoBo angeschlossene SATA-Platte. Ich hatte damals eine GPT
> > erstellt. Drauf sind 2 Partitionen, /boot und ein LUKS-Container
> > (ohne LVM) für /.
> >
> > Was muss nun genau gemacht werden, damit das klappt?
>
> Habe ich hier am 13.4.2021 unter dem Subject "(X)ubuntu von BIOS/MBR
> auf UEFI/GPT umziehen" gepostet. MID kann ich leider keine nennen, XPN
> archiviert die anscheinend nicht. Daher bitte auf Gurgel Groups
> suchen.

Da war ich noch nicht im Usenet, habe das daher nicht mitbekommen.
https://de.comp.os.unix.linux.misc.narkive.com/gFudaVpY/x-ubuntu-von-bios-mbr-auf-uefi-gpt-umziehen

> > Reicht es, die ESP auf die SATA-Platte anzulegen?
>
> Reicht nicht.

Sie ist nun angelegt mit passendem Type. Ist das das gleiche wie die
EFI-Partition?

> > Die bios_grub-Partition braucht man nicht, oder?
>
> Nein, was ist das?

Partition, um von ner GPT-Platte auf einem BIOS zu booten.
https://de.wikipedia.org/wiki/BIOS-Bootpartition

> > Hat das wer unter Debian schonmal gemacht und kennt die
> > Schritte/Fallstricke?
>
> Unter Xubuntu, sollte bei Debian aber nicht anders laufen.
>
> > Für Ubuntu gibt es
> > https://wiki.ubuntuusers.de/GRUB_2_von_BIOS_nach_EFI_umstellen/
>
> Die EFI-Partition habe ich per kunstvollem Aufruf von grub-install
> mit einem Rattenschwanz an Parametern eingerichtet. Anscheinend geht
> das in einer chroot-Umgebung einfacher.

Ich schaue heute, was für nen Inhalt die hat.
Zwischenstand von gestern:
EFI-Eintrag von debian ist da, aber der landet in der GRUB-Shell.
Ich habe eine separate boot-Partition, um den LUKS-Container zu öffnen.

Was ist hier schief gelaufen?

[Gerald E¡scher]

Marco Moock schrieb am 27/1/2023 07:00:

> Am 26.01.2023 23:23 schrieb Gerald E¡scher:
>
>> Marco Moock schrieb am 26/1/2023 22:07:
>>
>> > Reicht es, die ESP auf die SATA-Platte anzulegen?
>>
>> Reicht nicht.
>
> Sie ist nun angelegt mit passendem Type.

Parted sollte als Markierung "boot, esp" anzeigen.

> Ist das das gleiche wie die
> EFI-Partition?

Ist die gleiche. *E*FI *S*ystem *P*artition.

>> > Die bios_grub-Partition braucht man nicht, oder?
>>
>> Nein, was ist das?
>
> Partition, um von ner GPT-Platte auf einem BIOS zu booten.
> https://de.wikipedia.org/wiki/BIOS-Bootpartition

Achso, ich erinnere mich. Die habe ich einmal auf einer bootfähigen
USB-Platte eingerichtet. Ist bei einem Rechner, der eh nur UEFI kann,
nicht nötig.

>> > Für Ubuntu gibt es
>> > https://wiki.ubuntuusers.de/GRUB_2_von_BIOS_nach_EFI_umstellen/
>>
>> Die EFI-Partition habe ich per kunstvollem Aufruf von grub-install
>> mit einem Rattenschwanz an Parametern eingerichtet. Anscheinend geht
>> das in einer chroot-Umgebung einfacher.
>
> Ich schaue heute, was für nen Inhalt die hat.

Auf der EFI-Partition sollten zumindest /EFI/BOOT und
/EFI/$BETRÜBSSYSTEM vorhanden sein.

> Zwischenstand von gestern:
> EFI-Eintrag von debian ist da, aber der landet in der GRUB-Shell.
> Ich habe eine separate boot-Partition, um den LUKS-Container zu öffnen.

Mit LUKS hast du wohl eine Komplikation mehr.

> Was ist hier schief gelaufen?

Weiß ich nicht. Parameter '--boot-directory=' von grub-install enthielt
nicht das boot-Verzeichnis auf der boot-Partion?

--
Gerald

[Marco Moock]

Am 27.01.2023 schrieb Gerald E¡scher <Spa...@fahr-zur-Hoelle.org>:

> Auf der EFI-Partition sollten zumindest /EFI/BOOT und
> /EFI/$BETRÜBSSYSTEM vorhanden sein.

Schaue ich heute Abend nach.

> > Zwischenstand von gestern:
> > EFI-Eintrag von debian ist da, aber der landet in der GRUB-Shell.
> > Ich habe eine separate boot-Partition, um den LUKS-Container zu
> > öffnen.
>
> Mit LUKS hast du wohl eine Komplikation mehr.

Könnte sein, aber so weit kommt es gar nicht, denn der braucht erst die
/boot, dann fragt der nach dem LUKS-Kram.

> > Was ist hier schief gelaufen?
>
> Weiß ich nicht. Parameter '--boot-directory=' von grub-install
> enthielt nicht das boot-Verzeichnis auf der boot-Partion?

Habe ich nicht angegeben, soll wohl nicht zwingend sein.

Ich habe es aber heute in VBox getestet. Da kam ich auch bis in die
GRUB-Shell. Dann hat sich rausgestellt:
Ich hatte "update-grub" vergessen, sodass der GRUB zwar in der
EFI-Partition samt Eintrag im NVRAM installiert war, er selbst aber
nicht passend für das System konfiguriert war. Sowas endet dann in der
GRUB-Shell. Nach "update-grub" ging natürlich alles.

Ich habe es in der VBox aber über einen komfortableren Weg gemacht:
SuperGrub2-Disk. Diese gibt es als Hybrid- bzw. UEFI-Version. Davon
im EFI-Modus gebootet, dann dann das installierte OS mit MBR gewählt.
Dann bootet das alte System, in dem man komfortabel arbeiten kann. Dort
habe ich dann den GRUB-Kram gemacht, fstab editiert usw.

Ist jedenfalls wesentlich angenehmer gewesen als das Geschiss mit dem
Debian-Rettungsmodus, wo man nur ein Terminal hat, keinen Browser (der
Klo-Laptop daneben stattdessen), Netzwerk manuell konfigurieren muss
usw.

Wenn man aber genutzte Partitionen verkleinern muss, muss man ein
Livesystem nehmen (hier dann Debian Live mit gparted) für diesen
Vorgang. Sobald aber die EFI-Partition in der Partitionstabelle
existiert, kann man mit dem alten System fortfahren und da den Rest
erledigen.

[Marco Moock]

Am 27.01.2023 um 13:24:50 Uhr schrieb Marco Moock:

> Am 27.01.2023 schrieb Gerald E¡scher <Spa...@fahr-zur-Hoelle.org>:
>
> > Auf der EFI-Partition sollten zumindest /EFI/BOOT und
> > /EFI/$BETRÜBSSYSTEM vorhanden sein.
>
> Schaue ich heute Abend nach.

War schon da.

> > > Zwischenstand von gestern:
> > > EFI-Eintrag von debian ist da, aber der landet in der GRUB-Shell.
> > > Ich habe eine separate boot-Partition, um den LUKS-Container zu
> > > öffnen.
> >
> > Mit LUKS hast du wohl eine Komplikation mehr.
>
> Könnte sein, aber so weit kommt es gar nicht, denn der braucht erst
> die /boot, dann fragt der nach dem LUKS-Kram.

Da lag der Hase im Pfeffer.
/boot war zwar eingebunden und konnte im Livesystem gelesen werden
(daher auch keine Fehler bei der GRUB-Installation), aber nicht von
GRUB beim Booten. Das liegt am dummen IDE-controller. Auch die
SuperGRUb2-Disk konnte kein Chainloading von der IDE-Platte (man sollte
im BIOS-Kompatibilitätsmodus booten). In VirtualBox ging das, weil da
der Plattencontroller EFI kann. Meiner von JMicron kann es nicht. Daher
kann man von dem Teil nicht booten und /boot als auch /boot/efi (ESP)
können nicht auf dieser Platte sein. Ergo wurde die /boot auf die
SATA-Platte verschoben. Dann die fstab angepasst. Anschließend
eingebunden, GRUB installiert. System konnte dann problemlos booten.

Gekauft hatte ich den Controller 2018...

[Gerald E¡scher]

Marco Moock schrieb am 27/1/2023 18:47:

> Am 27.01.2023 um 13:24:50 Uhr schrieb Marco Moock:
>
>> Könnte sein, aber so weit kommt es gar nicht, denn der braucht erst
>> die /boot, dann fragt der nach dem LUKS-Kram.
>
> Da lag der Hase im Pfeffer.
> /boot war zwar eingebunden und konnte im Livesystem gelesen werden
> (daher auch keine Fehler bei der GRUB-Installation), aber nicht von
> GRUB beim Booten. Das liegt am dummen IDE-controller.

Nein, das liegt am Nutzer, der nicht weiß, dass ein BIOS vom
Motherboard nicht von IDE-Controllern auf PCI(e)-Karten booten kann, es
sei denn, die PCI(e)-Karte enthält eine BIOS-Erweiterung :-P
Wenn im BIOS-Setup die IDE-Platte nicht auftaucht, kann beim
Boot-Vorgang nicht darauf zugegriffen werden.
GRUB verwendet zum Zugriff auf die Platten BIOS- bzw. UEFI-Routinen.

> Auch die
> SuperGRUb2-Disk konnte kein Chainloading von der IDE-Platte (man sollte
> im BIOS-Kompatibilitätsmodus booten). In VirtualBox ging das, weil da
> der Plattencontroller EFI kann.

Ich glaube eher, das ging weil die EFI-Firmware von VirtualBox die
virtuellen IDE-Controller kennt. Die befinden sich schließlich am
virtuellen Motherboard und nicht auf einer PCI-Karte.

Die IDE-Treiber der Betriebssyteme sind in der Hinsicht wesentlich
flexibler, die finden auch IDE-Controller auf PCI-Karten.

> Gekauft hatte ich den Controller 2018...

Da hättest du einen bootfähigen IDE-Controller nehmen müssen. Jene die
RAID können, müssten mMn bootfähig sein, habe aber keine Erfahrung
damit.

--
Gerald

[Marco Moock]

Am 27.01.2023 20:55 schrieb Gerald E¡scher:

> Marco Moock schrieb am 27/1/2023 18:47:
>
> > Am 27.01.2023 um 13:24:50 Uhr schrieb Marco Moock:
> >
> >> Könnte sein, aber so weit kommt es gar nicht, denn der braucht erst
> >> die /boot, dann fragt der nach dem LUKS-Kram.
> >
> > Da lag der Hase im Pfeffer.
> > /boot war zwar eingebunden und konnte im Livesystem gelesen werden
> > (daher auch keine Fehler bei der GRUB-Installation), aber nicht von
> > GRUB beim Booten. Das liegt am dummen IDE-controller.
>
> Nein, das liegt am Nutzer, der nicht weiß, dass ein BIOS vom
> Motherboard nicht von IDE-Controllern auf PCI(e)-Karten booten kann,
> es sei denn, die PCI(e)-Karte enthält eine BIOS-Erweiterung :-P

Diese Karte hat eine BIOS-Erweiterung. Die funktioniert aber nur auf
einem BIOS bzw. einem UEFI mit aktivem CSM. Ich habe aber kein CSM,
ergo kann man nicht von booten.

> Wenn im BIOS-Setup die IDE-Platte nicht auftaucht, kann beim
> Boot-Vorgang nicht darauf zugegriffen werden.

Das war mir klar, daher habe ich die ESP, die das UEFI lesen muss, auf
ne andere Platte direkt am Motherboard-SATA-Controller angeschlossen.

> GRUB verwendet zum Zugriff auf die Platten BIOS- bzw. UEFI-Routinen.

Das war mir unbekannt und erklärt, warum GRUB /boot nicht finden
konnte, aber beim update-grub alles ok war.
Sie SG2D kann chainloading mit GRUB2 auch nur über die
BIOS/UEFI-Routinen, weißt aber immerhin drauf hin.

> > Auch die
> > SuperGRUb2-Disk konnte kein Chainloading von der IDE-Platte (man
> > sollte im BIOS-Kompatibilitätsmodus booten). In VirtualBox ging
> > das, weil da der Plattencontroller EFI kann.
>
> Ich glaube eher, das ging weil die EFI-Firmware von VirtualBox die
> virtuellen IDE-Controller kennt. Die befinden sich schließlich am
> virtuellen Motherboard und nicht auf einer PCI-Karte.

Richtig.

> Die IDE-Treiber der Betriebssyteme sind in der Hinsicht wesentlich
> flexibler, die finden auch IDE-Controller auf PCI-Karten.
>
> > Gekauft hatte ich den Controller 2018...
>
> Da hättest du einen bootfähigen IDE-Controller nehmen müssen. Jene die
> RAID können, müssten mMn bootfähig sein, habe aber keine Erfahrung
> damit.

Der kann FakeRAID - reicht das?

[Gerald E¡scher]

Marco Moock schrieb am 28/1/2023 08:30:

> Am 27.01.2023 20:55 schrieb Gerald E¡scher:
>
>> Nein, das liegt am Nutzer, der nicht weiß, dass ein BIOS vom
>> Motherboard nicht von IDE-Controllern auf PCI(e)-Karten booten kann,
>> es sei denn, die PCI(e)-Karte enthält eine BIOS-Erweiterung :-P
>
> Diese Karte hat eine BIOS-Erweiterung. Die funktioniert aber nur auf
> einem BIOS bzw. einem UEFI mit aktivem CSM. Ich habe aber kein CSM,
> ergo kann man nicht von booten.

Es gibt Rechner ohne CSM? Damit kann man doch ältere RAID-Controller
und Grafikkarten ohne UEFI-tauglicher Firmware nur eingeschränkt
bis gar nicht benutzen?
Gibt es im Setup vom MB keine Option, um CSM einzuschalten?

>> Da hättest du einen bootfähigen IDE-Controller nehmen müssen. Jene die
>> RAID können, müssten mMn bootfähig sein, habe aber keine Erfahrung
>> damit.
>
> Der kann FakeRAID - reicht das?

Weiß ich nicht. (IDE-)RAID-Controller sind üblicherweise bootfähig,
worauf es in deinem Fall ankäme, wenn dein MB CSM könnte, die daran
hängenden Festplatten können häufig aber auch ganz normal ohne RAID
betrieben werden[1]. Dann hat man im Prinzip einen bootfähigen
IDE-Controller.


[1] Es gibt jedenfalls ältere SAS/SATA-Controller mit LSI-Chip, die nur
als RAID betrieben werden können. Aber gut zu wissen, dass die in
Rechnern ohne CSM vermutlich nicht funktionieren.


--
Gerald

[Marco Moock]

Am 28.01.2023 um 19:46:44 Uhr schrieb Gerald E¡scher:

> Marco Moock schrieb am 28/1/2023 08:30:
>
> > Am 27.01.2023 20:55 schrieb Gerald E¡scher:
> >
> >> Nein, das liegt am Nutzer, der nicht weiß, dass ein BIOS vom
> >> Motherboard nicht von IDE-Controllern auf PCI(e)-Karten booten
> >> kann, es sei denn, die PCI(e)-Karte enthält eine BIOS-Erweiterung
> >> :-P
> >
> > Diese Karte hat eine BIOS-Erweiterung. Die funktioniert aber nur auf
> > einem BIOS bzw. einem UEFI mit aktivem CSM. Ich habe aber kein CSM,
> > ergo kann man nicht von booten.
>
> Es gibt Rechner ohne CSM?

Ja, Intel hat das 2017 abgekündigt.
https://www.heise.de/newsticker/meldung/Intel-UEFI-BIOS-verliert-2020-die-BIOS-Kompatibilitaet-3890747.html

Damit wurde auch der BIOS OptionROM abgekündigt, der Kram muss UEFI
können. Bereits 2019 wurden Mainboards ohne CSM ausgeliefert.

> Damit kann man doch ältere RAID-Controller
> und Grafikkarten ohne UEFI-tauglicher Firmware nur eingeschränkt
> bis gar nicht benutzen?

Richtig, Booten davon geht nicht, im System später nutzen schon. Bei
GraKas müsste ich mal testen.

> Gibt es im Setup vom MB keine Option, um CSM einzuschalten?

Nein.

> >> Da hättest du einen bootfähigen IDE-Controller nehmen müssen. Jene
> >> die RAID können, müssten mMn bootfähig sein, habe aber keine
> >> Erfahrung damit.
> >
> > Der kann FakeRAID - reicht das?
>
> Weiß ich nicht. (IDE-)RAID-Controller sind üblicherweise bootfähig,
> worauf es in deinem Fall ankäme, wenn dein MB CSM könnte, die daran
> hängenden Festplatten können häufig aber auch ganz normal ohne RAID
> betrieben werden[1]. Dann hat man im Prinzip einen bootfähigen
> IDE-Controller.

Ich hatte das FakeRAID da nie genutzt. Der kann aber nur im CSM/BIOS
davon booten, was mein neues Mainboard aber nicht hat.

> [1] Es gibt jedenfalls ältere SAS/SATA-Controller mit LSI-Chip, die
> nur als RAID betrieben werden können. Aber gut zu wissen, dass die in
> Rechnern ohne CSM vermutlich nicht funktionieren.

Sie funktionieren, aber man kann nicht davon booten. GRUB kann ebenso
nicht auf diese zugreifen. Für reine Datenplatten kann man die aber
problemlos weiterbenutzen.

[Ulli Horlacher]

Gerald E¡scher <Spa...@fahr-zur-hoelle.org> wrote:

> Es gibt Rechner ohne CSM?

Alle Thinkpads seit 2020.


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Gerald E¡scher]

Ulli Horlacher schrieb am 28/1/2023 21:13:

> Gerald E¡scher <Spa...@fahr-zur-hoelle.org> wrote:
>
>> Es gibt Rechner ohne CSM?
>
> Alle Thinkpads seit 2020.

In die kann man eh keine RAID-Controller rein stecken.

--
Gerald

[Marc Haber]

Marco Moock <mo...@posteo.de> wrote:
>ich habe ein neues Mainboard, das kann nur UEFI.
>Ich muss ein Debian Sid umstellen. Der Plattencontroller für die
>Systemplatte kann nicht per UEFI booten, ergo muss der Kram auf die
>am MoBo angeschlossene SATA-Platte. Ich hatte damals eine GPT erstellt.
>Drauf sind 2 Partitionen, /boot und ein LUKS-Container (ohne LVM) für /.
>
>Was muss nun genau gemacht werden, damit das klappt?
>Reicht es, die ESP auf die SATA-Platte anzulegen?
>Die bios_grub-Partition braucht man nicht, oder?
>
>Hat das wer unter Debian schonmal gemacht und kennt die
>Schritte/Fallstricke?

Ich habe das vor ein paar Monaten gemacht. War eigentlich
straightforward, ich erinnere mich kaum an irgendwelche Probleme.

Mein Tipp wäre: mach die EFI-Partition nicht zu klein, da will der
fwupdmgr die Updates hinlegen die beim nächsten Boot installiert
werden, und vielleicht willst Du da auch mal ein grml.iso oder einen
direkt ohne Bootmanager zu bootenden Kernel hinterlegen. Ich hab das 2
GB groß gemacht, unter anderem weil ein grml64-small auch schon knapp
500 MB groß ist.

Ich habe das Board auf UEFI only umgestellt, dann ein grml gebootet,
das System unter /mnt eingehängt (/boot und /boot/efi nicht vergessen)
und mit chroot da hinein gewechselt. Dann grub-efi-amd64 installiert,
die Konfiguration gesichert und dann grub-pc gepurget. Das killt die
Konfiguration, die zwei Dateien wieder zurückkopieren. grub-install,
update-grub, und das war's iirc auch schon.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marco Moock]

Am 29.01.2023 um 10:24:13 Uhr schrieb Marc Haber:

> Ich habe das Board auf UEFI only umgestellt, dann ein grml gebootet,
> das System unter /mnt eingehängt (/boot und /boot/efi nicht vergessen)
> und mit chroot da hinein gewechselt.

In einer VBox habe ich einfach das installierte OS mit der SG2D
gebootet und da alles gemacht bis auf die Partitionierung.

> Dann grub-efi-amd64 installiert, die Konfiguration gesichert und dann
> grub-pc gepurget.

Muss man das unbedingt purgen?
Ich habe es auch so gemacht, aber muss es denn wirklich sein?

> Das killt die Konfiguration, die zwei Dateien
> wieder zurückkopieren. grub-install, update-grub, und das war's iirc
> auch schon.

Bei mir nicht ganz wegen des PCIe-Plattencontrollers, siehe
Message-ID: <tr2iub$24iun$1...@dont-email.me>

[Marc Haber]

Marco Moock <mo...@posteo.de> wrote:
>Am 29.01.2023 um 10:24:13 Uhr schrieb Marc Haber:
>> Dann grub-efi-amd64 installiert, die Konfiguration gesichert und dann
>> grub-pc gepurget.
>
>Muss man das unbedingt purgen?
>Ich habe es auch so gemacht, aber muss es denn wirklich sein?

Sonst hast Du den halt auf Ewig mit Status rc in der Paketliste.