Waar heen met de EFI partitie?

[Zalmanman]

Mijn Fedora is aardig op de hobbel. Nemo openen duurt een minuut, steeds weer vastlopers... Het is tijd voor een verse installatie. Zo gepiept, toch? cp -r ~ [wherever] en gaan met die banaan. Normaal wel, maar mijn partitietabel is een beetje screwed.
Allereerst even de schijven die ik heb:

• sda: 4TB draaiend roest, 3.5TB NTFS, 0.5TB EXT4
• sdb: W10, 525GB
• sdb1: Windows 10, sdb2: Recovery 1, sdb3: Recovery 2
• sdb3 lijkt de 'up to date' variant te zijn: Windows RE location: \\?\GLOBALROOT\device\harddisk1\partition3\Recovery\WindowsRE
• sdc: Fedora, 275GB

Dan komt nu het probleem: de 3 partities op sdc. De eerste partitie is de EFI-systeempartitie, maar dat is sdc2 in de partitietabel. De tweede partitie is voor /, maar dat is /dev/sdc1 in de partitietabel. Achteraan staat nog een overgebleven swap, die is wel netjes /dev/sdc3.

Het ding is dus: Als ik er een verse Linux op zet, heb ik het liefste /dev/sdc1 als eerste partitie, sdc2 als tweede. Dat betekent dus dat ik een nieuwe partitietabel moet maken. Wat doe ik dan met de EFI partitie? Ik hou Windows 10 natuurlijk wel het liefste opstartbaar, maar deze volgorde van partities is ook niets. Kan ik gewoon een nieuwe EFI partitie maken, of moet alles echt ergens anders heen. Zo ja, kan ik daar de niet-gebruikte W10 recovery partitie voor gebruiken o.i.d.? Ik hoor jullie input graag!

[neeroeter]

Doe wellicht even een

code:

 sudo fdisk -l

en evt vanaf een live cd/usb

en gebruik code tags, dan krijg je ws meer respons

[Zalmanman]

neeroeter schreef op woensdag 23 september 2020 @ 10:40:
Doe wellicht even een

code:

 sudo fdisk -l

en evt vanaf een live cd/usb

en gebruik code tags, dan krijg je ws meer respons

Dat is wel een heel goed punt, ja. Ik dacht dat het wel redelijk te doen zou zijn zo in list-form, maar nu ik er nog eens naar kijk... Goed, een fdisk vanuit de geïnstalleerde Fedora:

code:

Disk /dev/sda: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EZRZ-00W
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: knip

Device          Start        End    Sectors   Size Type
/dev/sda1        2048 6837473272 6837471225   3.2T Microsoft basic data
/dev/sda2  6837473280 7814035455  976562176 465.7G Microsoft basic data


Disk /dev/sdb: 489.5 GiB, 525112713216 bytes, 1025610768 sectors
Disk model: Crucial_CT525MX3
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: knip

Device          Start        End    Sectors   Size Type
/dev/sdb1        2048      34815      32768    16M Microsoft reserved
/dev/sdb2       34816 1022868616 1022833801 487.7G Microsoft basic data
/dev/sdb3  1022869504 1023987711    1118208   546M Windows recovery environment
/dev/sdb4  1023989760 1025607679    1617920   790M Windows recovery environment


Disk /dev/sdc: 256.18 GiB, 275064201216 bytes, 537234768 sectors
Disk model: Crucial_CT275MX3
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: knip

Device         Start       End   Sectors   Size Type
/dev/sdc1    1050624 520452095 519401472 247.7G Linux filesystem
/dev/sdc2         34   1050623   1050590   513M EFI System
/dev/sdc3  520452096 537229311  16777216     8G Linux swap

Partition table entries are not in disk order.

Zoals jullie kunnen zien staan er twee Windows Recovery Environments op mijn /dev/sdb schijf, waarvan, als ik alles goed begrepen heb, alleen sdb3 actief is, sdb4 niet. Wat 'ie daar dan ook doet...? Overigens is /dev/sda2 Ext4, niet helemaal zeker waarom daar MS Basic Data staat.

En dan dus /dev/sdc. Zoals jullie kunnen zien: "Partition table entries are not in disk order." Dat is precies wat ik wil verhelpen. Daarmee zou dus inderdaad de partitietabel van /dev/sdc opnieuw opgesteld moeten worden, wat in essentie een verlies van de EFI-partitie betekent.

Ik hoop dat deze extra info in ieder geval wat verduidelijking brengt

[Hero of Time]

Trek de sdc los en kijk wat je kan met de Windows installatie media en of deze de Windows installatie herkend. Doet die dan, dan kan je gewoon je sdc opnieuw indelen zonder morren. Na de herinrichting start je weer die Windows installatie op en herstel je het boot gedeelte.

Andere optie is een backup maken van de bestanden op de ESP. Zo spannend is het niet, je wilt voornamelijk de Microsoft map hebben met de Windows EFI loader. Als je dan de schijf opnieuw hebt ingericht, zet je de MS map terug op de ESP en registreer je deze weer bij EFI. Controleer of je 'm ziet in het boot menu van je moederbord, probeer Windows er mee op te starten en als dat lukt, veel plezier. Lukt het niet, dan heb je die installatie media nog om het laatste stukje te herstellen.

[Zalmanman]

Daar had je een hele goede suggestie: Even sdc 'loshalen'. Gewoon in het BIOS die sata poort uitgezet, makkelijker dan de PC openhalen
Enfin, er startte inderdaad niet meer op, hij defaultte naar het UEFI. Dus wat ik nu heb gedaan is het volgende:
/dev/sdb4 is verwijderd en teruggeschaald naar 512MiB. De vrijgekomen ruimte is gebruikt om /dev/sdc3 op te schalen.

/dev/sdb4 is nu ingesteld als EFI partitie via Windows - in essentie heb ik nu dus twee EFI partities. Eentje die me de Grub presenteert en eentje die Windows opstart.

Dan kan ik binnenkort Ubuntu Cinnamon of zo erop zetten met /dev/sdb4 als mount point voor /boot/efi en dan moet het wel goed komen. Bedankt voor alle hulp!

[Hero of Time]

Weet je 100% zeker dat die sdb4 werkt? Want er staat mij iets bij dat de ESP de eerste partitie op de schijf moet zijn. Dat is waar UEFI standaard zoekt voor een bootloader.

Nou moet ik er ook bij zeggen dat ik een bootable USB stick heb waarbij de Windows 10 installatie op de eerste partitie staat (met EFI loader) en Grub-efi met vereiste bestanden op de tweede partitie en beide gebruikt kunnen worden.

[Zalmanman]

Weet ik het 100% zeker? Nee, maar dat is ook deels omdat ik het opstartsysteem van (U)EFI niet 100% begrijp. Wat ik zeker weet is het volgende:
> In de "originele" configuratie was de bootpartitie gezet op /dev/sdc2
> Na het uitzetten van die sata-poort kon ik niet meer opstarten in Windows, alhoewel ik in het bootmenu nog wel de entry "Windows Boot Loader" of "Windows Boot Manager" zag staan, leidde dit direct terug naar het EFI. Conclusie: /dev/sdc2 is oprecht nodig.
> sata-poort weer aangezet en herstart, Grub was terug. Toen heb ik Fedora opgestart en de eerder vermelde werkzaamheden uitgevoerd.
> Nogmaals opnieuw opgestart en de sata-poort van sdc uitgezet. Hij boot nu zonder Grub default naar Windows 10.

Dat is voor mij voldoende bewijs dat ik zeker weet dat sdb4 op de huidige manier werkt. Disk Management noemt het ook een "Healthy (EFI System Partition)".
Wat de ESP op de eerste partitie betreft: Dat stond deze ook niet op sdc, op een manier. Qua blocks wel inderdaad, maar niet qua partitietabel.

[Hero of Time]

Als het zonder sdc start, is dat an sich wel voldoende. Dat zou je 100% kunnen noemen.

Heb je met Fedora die tweede MSP geformatteerd naar FAT32 en via fdisk het de ESP marker gegeven en daarna de data erop gezet van sdc2?

[HollowGamer]

Hero of Time schreef op donderdag 24 september 2020 @ 21:27:
Weet je 100% zeker dat die sdb4 werkt? Want er staat mij iets bij dat de ESP de eerste partitie op de schijf moet zijn. Dat is waar UEFI standaard zoekt voor een bootloader.

Nou moet ik er ook bij zeggen dat ik een bootable USB stick heb waarbij de Windows 10 installatie op de eerste partitie staat (met EFI loader) en Grub-efi met vereiste bestanden op de tweede partitie en beide gebruikt kunnen worden.

Volgensmij hoeft dat niet perse de eerste partitie te zijn. Als ik het goed hebt maakt Windows ook één partitie aan voor de EFI partitie, die wordt dan dacht ik gebruikt voor recovery/BitLocker.

Het is wel het beste, zeker één met 512mb. Helaas gaat Windows 10 niet altijd goed om met dual boot, al zouden ze nu niet meer grub moeten overschrijven.

[Hero of Time]

HollowGamer schreef op donderdag 24 september 2020 @ 21:57:
Het is wel het beste, zeker één met 512mb. Helaas gaat Windows 10 niet altijd goed om met dual boot, al zouden ze nu niet meer grub moeten overschrijven.

Wat ik relatief recent nog heb gehoord (dacht zelfs hier op GoT), is dat met de 2004 release van W10 het toch nog de ESP leeg heeft gegooid en Grub.efi niet meer te vinden was. Dus als het niet meer zou moeten gebeuren, zal dat met de komende 2010 versie moeten zijn.

Zelf geen ervaring mee, ik doe niet aan dual boot.

[neeroeter]

Slechts een idee en iets dat mij blij verrast heeft. Ik heb onlangs Windows 10 geinstalleerd op een nieuwe SSD naast twee andere schijven, een met linux, een met generieke data. Ik gebruik op die bak rEfind als boot manager. Ik heb windows op die nieuwe schijf gewoon zijn ding laten doen.
Ik heb dus de 'boot-zooi' van Windows en mijn Linux /boot partitie.
rEfind heeft dus de slimmigheid dat het je schijven afzoekt op boot bestanden, en na installeren van Windows verscheen er een keurig icoontje in rEfind (is grafisch) naast mijn pinguin icoontjes en Windows start nu keurig op. rEfind is een bootmanager en geen bootloader.
Ik zit op Arch en weet niet of het bij de Ubuntu's van deze wereld mogelijk is om geen Grub te gebruiken echter...
De Arch wiki is wel een goede bron van info, mocht je geinteresseerd zijn.

https://wiki.archlinux.org/index.php/Category:Boot_loaders

[Zalmanman]

Hero of Time schreef op donderdag 24 september 2020 @ 21:57:
Als het zonder sdc start, is dat an sich wel voldoende. Dat zou je 100% kunnen noemen.

Heb je met Fedora die tweede MSP geformatteerd naar FAT32 en via fdisk het de ESP marker gegeven en daarna de data erop gezet van sdc2?

Nee, sdc zet ik pas weer "aan" als ik het verse OS erop ga zetten om dit soort problemen te voorkomen. Via diskpart is de partitie al als ESP geflagd, dus ik neem aan dat het genoeg is. Fedora hoeft ook niet per se meer op te starten, er is toch een backup gemaakt. Bij de nieuwe Linux-installatie zal ik sdb4 aanmerken als EFI partitie en/of mounten op /boot/efi/. Dan zal de GRUB zichzelf daar wel neerzetten, vermoed ik.
Eigenlijk wel een goeie, nu ik er zo over nadenk. De grub.efi komt natuurlijk op /boot/efi te staan (sdb4), maar betekent dat dan ook dat ik de GRUB op /dev/sdb4 installer, of komt deze nog steeds in de MBR(?) van sdc te staan, om daarna door te verwijzen naar sdb4? Of hoort de GRUB naar de harde schijf te gaan waar de ESP op staat? Of maak het allemaal geen suikerbiet uit?

Hero of Time schreef op donderdag 24 september 2020 @ 22:02:
[...]

Wat ik relatief recent nog heb gehoord (dacht zelfs hier op GoT), is dat met de 2004 release van W10 het toch nog de ESP leeg heeft gegooid en Grub.efi niet meer te vinden was. Dus als het niet meer zou moeten gebeuren, zal dat met de komende 2010 versie moeten zijn.

Zelf geen ervaring mee, ik doe niet aan dual boot.

Gelukkig zit ik al op 2004, dus dat zou voor nu goed moeten blijven gaan En Windows is niet mijn favoriete OS, maar het heeft zo z'n nuttigheden, vooral met games en soms met iTues voor m'n iPod Classics. Linux heeft nog altijd de voorkeur voor dingen als LaTeX/Mathematica/R. Dus vandaar dat ik toch de voorkeur geef aan een dual-bootje.

neeroeter schreef op vrijdag 25 september 2020 @ 07:00:
Slechts een idee en iets dat mij blij verrast heeft. Ik heb onlangs Windows 10 geinstalleerd op een nieuwe SSD naast twee andere schijven, een met linux, een met generieke data. Ik gebruik op die bak rEfind als boot manager. Ik heb windows op die nieuwe schijf gewoon zijn ding laten doen.
Ik heb dus de 'boot-zooi' van Windows en mijn Linux /boot partitie.
rEfind heeft dus de slimmigheid dat het je schijven afzoekt op boot bestanden, en na installeren van Windows verscheen er een keurig icoontje in rEfind (is grafisch) naast mijn pinguin icoontjes en Windows start nu keurig op. rEfind is een bootmanager en geen bootloader.
Ik zit op Arch en weet niet of het bij de Ubuntu's van deze wereld mogelijk is om geen Grub te gebruiken echter...
De Arch wiki is wel een goede bron van info, mocht je geinteresseerd zijn.

https://wiki.archlinux.org/index.php/Category:Boot_loaders

Dat klinkt heel tof! Ik ga me er zeker eens in verdiepen. Ik weet dat de GRUB te vervangen is, ooit eens gedaan met een grafische versie genaamd BURG, maar die was er alleen voor GRUB1, niet voor 2. Als ik het zo lees is het in Ubuntu add repo, update, install, configure. Niet écht het meest moeilijke klusje ooit.

[Hero of Time]

Zalmanman schreef op vrijdag 25 september 2020 @ 15:00:
Eigenlijk wel een goeie, nu ik er zo over nadenk. De grub.efi komt natuurlijk op /boot/efi te staan (sdb4), maar betekent dat dan ook dat ik de GRUB op /dev/sdb4 installer, of komt deze nog steeds in de MBR(?) van sdc te staan, om daarna door te verwijzen naar sdb4? Of hoort de GRUB naar de harde schijf te gaan waar de ESP op staat? Of maak het allemaal geen suikerbiet uit?

Er wordt met UEFI niets meer buiten de partities (tussen partitietabel en eerste partitie) op de schijf geschreven voor het opstarten. De EFI loader wordt alleen maar geregistreerd bij de UEFI firmware.

neeroeter schreef op vrijdag 25 september 2020 @ 07:00:
rEfind is een bootmanager en geen bootloader.

En dat is exact de reden waarom je Linux of Windows nooit zal kunnen starten met rEFInd. Je zal hoe dan ook een bootloader moeten hebben hiervoor. Een bootmanager maakt het alleen 'beheerbaar' en 'overzichtelijk' welke loaders er zijn en roept deze aan. Meer niet.

Je zal dus hoe dan ook iets moeten hebben dat de initrd/initramfs start om zo verder in Linux te komen. Grub2 is zoiets. Wat ik in andere topics heb vernomen maakt PopOS!, als Ubuntu afgeleidde, gebruik van systemd om te starten. Maar ik kan zo even snel geen package vinden die met 'systemd' begint en als bootloader zou kunnen fungeren in m'n Debian repo. Dus hoe ze het precies doen weet ik niet.

[neeroeter]

Hero of Time schreef op vrijdag 25 september 2020 @ 19:59:
En dat is exact de reden waarom je Linux of Windows nooit zal kunnen starten met rEFInd. Je zal hoe dan ook een bootloader moeten hebben hiervoor. Een bootmanager maakt het alleen 'beheerbaar' en 'overzichtelijk' welke loaders er zijn en roept deze aan. Meer niet.

Je zal dus hoe dan ook iets moeten hebben dat de initrd/initramfs start om zo verder in Linux te komen. Grub2 is zoiets. Wat ik in andere topics heb vernomen maakt PopOS!, als Ubuntu afgeleidde, gebruik van systemd om te starten. Maar ik kan zo even snel geen package vinden die met 'systemd' begint en als bootloader zou kunnen fungeren in m'n Debian repo. Dus hoe ze het precies doen weet ik niet.

Klopt, heb even de wiki gechekt -> de Arch kernel heeft standaard:
The Linux kernel supports EFISTUB booting which allows EFI firmware to load the kernel as an EFI executable. The option is enabled by default on Arch Linux kernels, or if compiling the kernel one can activate it by setting CONFIG_EFI_STUB=y in the Kernel configuration. See The EFI Boot Stub for more information.
En ->
rEFInd is a UEFI boot manager capable of launching EFISTUB kernels. It is a fork of the no-longer-maintained rEFIt and fixes many issues with respect to non-Mac UEFI booting. It is designed to be platform-neutral and to simplify booting multiple OSes.


Dus distro specifiek. Dit is offtopic en verder niet belangrijk voor de topic starter. Alleen nog systemd-boot hetgeen ook de kernel setting "CONFIG_EFI_STUB=y" nodig heeft:
systemd-boot, previously called gummiboot (German for: 'rubber dinghy'), is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu to be navigated via arrow-keys. It is included with systemd, which is installed on an Arch system by default.

It is simple to configure but it can only start EFI executables such as the Linux kernel EFISTUB, UEFI Shell, GRUB, or the Windows Boot Manager.

Het lijkt erop dat zonder EFISTUB aan, de keuzes buiten GRUB2 beperkt blijven.

[Jouke74]

Ik heb mijn SSD eens bekeken, dit is een dual boot Windows & Debian 10.

Onder Windows heb ik 5 blokken : EFI, Windows 10, Windows Recovery, Swap (Debian) en Debian 10.
Onder Debian 10 maakt ie er 6 partities van: EFI, Extra Windows van 17MB, Windows 10, Windows Recovery, Swap, Debian 10.

In mijn Bios kan ik kiezen tussen Grub en Windows boot. Als ik Grub kies kan ik daarna ook dual booten naar Windows, en ze leven al lange tijd met verschillende updates vrolijk naast elkaar zonder problemen.

Ik ben begonnen met Windows installeren, en heb daarna voor zover ik weet de door Windows gevormde EFI laten staan. Voor Debian alleen op het resterende deel SSD 1 Swap partitie en een Root partitie aangemaakt. De rest ging allemaal automagisch.