Re: UEFI secure boot issue

[Bhasker C V]

On Thu, Jun 20, 2024 at 3:57 PM Jeffrey Walton  wrote:
>
> On Thu, Jun 20, 2024 at 9:23 AM Bhasker C V  wrote:
> >
> > I generated a pr/pk pair and the kernel is signed. Placed them in the
> > kernel tree and compiled the kernel.
>
> I don't think you are supposed to check-in/compile-in the private key.
> It is usually supposed to stay private.
>
> > Could someone tell me what am I doing wrong please ?
> >
> > Below is the status (I am using loader.efi from linuxfoundation)
> > When i boot debian stock kernel signed, i see that the secure boot
> > gets enabled (hence bios and everything else seems to be fine with the
> > same UEFI loader).
> > However, when I boot the compiled kernel I get
> >
> > $ dmesg | grep -i secure
> > [0.007085] Secure boot could not be determined
> >
> >
> > $ sbverify --list bootx64.efi
> > warning: data remaining[91472 vs 101160]: gaps between PE/COFF sections?
> > signature 1
> > image signature issuers:
> >  - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft
> > Corporation UEFI CA 2011
> > image signature certificates:
> >  - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
> > Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
> >issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft
> > Corporation/CN=Microsoft Corporation UEFI CA 2011
> >  - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
> > Corporation/CN=Microsoft Corporation UEFI CA 2011
> >issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft
> > Corporation/CN=Microsoft Corporation Third Party Marketplace Root
> > $ sbverify  --list ./loader.efi
> > signature 1
> > image signature issuers:
> >  - /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> > image signature certificates:
> >  - subject: /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> >issuer:  /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> > $ sbverify  --list ../../linux/k.bcv
> > signature 1
> > image signature issuers:
> >  - /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> > image signature certificates:
> >  - subject: /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> >issuer:  /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
>
>
> Have a look at , and the use of
> the Machine Owner Key (MOK).

Thanks Jeff. I did follow this.
Like I had mentioned before, the stock kernel still works in
locked-down mode with secure boot whereas the kernel I have compiled
and signed does not.
Is there a way to debug this on why exactly does this not work ?

>
> Jeff

Re: UEFI secure boot issue

[Jeffrey Walton]

On Thu, Jun 20, 2024 at 9:23 AM Bhasker C V  wrote:
>
> I generated a pr/pk pair and the kernel is signed. Placed them in the
> kernel tree and compiled the kernel.

I don't think you are supposed to check-in/compile-in the private key.
It is usually supposed to stay private.

> Could someone tell me what am I doing wrong please ?
>
> Below is the status (I am using loader.efi from linuxfoundation)
> When i boot debian stock kernel signed, i see that the secure boot
> gets enabled (hence bios and everything else seems to be fine with the
> same UEFI loader).
> However, when I boot the compiled kernel I get
>
> $ dmesg | grep -i secure
> [0.007085] Secure boot could not be determined
>
>
> $ sbverify --list bootx64.efi
> warning: data remaining[91472 vs 101160]: gaps between PE/COFF sections?
> signature 1
> image signature issuers:
>  - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft
> Corporation UEFI CA 2011
> image signature certificates:
>  - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
> Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
>issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft
> Corporation/CN=Microsoft Corporation UEFI CA 2011
>  - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
> Corporation/CN=Microsoft Corporation UEFI CA 2011
>issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft
> Corporation/CN=Microsoft Corporation Third Party Marketplace Root
> $ sbverify  --list ./loader.efi
> signature 1
> image signature issuers:
>  - /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> image signature certificates:
>  - subject: /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
>issuer:  /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> $ sbverify  --list ../../linux/k.bcv
> signature 1
> image signature issuers:
>  - /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
> image signature certificates:
>  - subject: /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv
>issuer:  /C=GB/ST=England/L=London/O=BHASKER/CN=bcvm.bcvm.bcv


Have a look at , and the use of
the Machine Owner Key (MOK).

Jeff

Re: UEFI op servers, of niet?

[Wouter Verhelst]

On Tue, Aug 22, 2023 at 10:45:10AM +0200, Dennis van Dok wrote:
> On 15-08-2023 12:13, Paul van der Vlis wrote:
> > Het feit dat er vrij automatisch firmware wordt geïnstalleerd van de
> > fabrikant vind ik niet prettig. Maar dit is vast uit te zetten ;-)
> 
> Welke systemen doen dit? Wij moeten altijd zelf onze firmware bijhouden.
> Hoewel $VENDOR1 een systeem biedt om dat te automatiseren gebruiken wij dat
> liever niet want dan zit je daaraan vast, terwijl we ook spullen van
> $VENDOR2 willen kunnen kopen en gebruiken.
> 
> Het enige voorbeeld wat me te binnen schiet zijn de 'intelligente' lampen
> die je met een app kunt dimmen. Die deden het niet meer toen ik hun
> internettoegang uitschakelde.

Dit is even iets heel anders, maar:

Als je een standaard "smart" lamp oid koopt, dan is de kans heel groot
dat je inderdaad Internettoegang nodig hebt om het te kunnen gebruiken.
Rommel. Gelukkig is dat niet het geval met alle fabrikanten.

https://www.home-assistant.io/integrations/shelly/

Smart switches en smart bulbs van het merk "shelly" werken *standaard*
met een Internet-verbinding, maar alle generaties van dat merk kunnen
geconfigureerd worden om dat niet te doen. Je kan dan met iets als
home-assistant (echte aanrader trouwens, dat ding) lokaal alles
aansturen, zonder Internet-verbinding (hoewel dat ook mogelijk is,
optioneel, als je dat wilt).

Producten op https://shelly.cloud/; ik ga eind volgende maand (of begin
Oktober, afhankelijk van hoe lang het duurt voor de bestelling er is) een resem
van die dingen thuis installeren.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: UEFI op servers, of niet?

[Wouter Verhelst]

On Thu, Aug 17, 2023 at 10:21:38AM +0200, Paul van der Vlis wrote:
> > > vind ik niet prettig.
> > 
> > Als je dat die "auto firmware update by firmware" kunt aantonen,
> > ga dan ingesprek met je leverancier.
> Het is een "feature" van UEFI.

Niet echt.

UEFI heeft een standaard manier om firmware-updates te distribueren. Ze
dan ook installeren heeft wat meer nodig:

wouter@pc220518:~$ efibootmgr
BootCurrent: 0008
Timeout: 5 seconds
BootOrder: 0008,0001,0002,0003,
Boot* Linux Firmware Updater
Boot0001* ONBOARD NIC (IPV4)
Boot0002* ONBOARD NIC (IPV6)
Boot0003* UEFI HTTPs Boot
Boot0008* debian

"Boot0008" is Debian. Dat start normaal op.
"Boot" is de "Linux Firmware Updater". Dat is een component van
fwupd, /boot/efi/EFI/debian/fwupdx64.efi.

Daarnaast ben ik persoonlijk ook heel blij met /boot/efi/EFI/Dell/logs
-- als mijn firmware problemen vindt met de hardware, dan komt dat daar
mooi te staan.

> De firmware updated niet de firmware, dat
> doet bijvoorbeeld: https://packages.debian.org/bullseye/fwupd
> Dit wordt standaard geïnstalleerd door Debian volgens mij.
> De leverancier stopt het in: https://fwupd.org/
> 
> > De betere leverancier is ook al eerder aanspreekbaar.
> 
> Dit heeft niet zoveel met de leverancier te maken, ik vind het goed dat ze
> de firmware uploaden. Ik vind dat het alleen nogal automatisch gebeurd
> allemaal.

Het gnome-firmware pakket wordt inderdaad standaard geïnstalleerd op een
desktop-machine, en die zal ook standaard popups tonen als er een update
is voor je firmware met een simpele "Installeer deze update" knop waar
je makkelijk op kunt klikken.

Als je gnome-firmware (of equivalente dingen) niet installeert, dan heb
je dat niet, en dan moet je het manueel doen. Daarvoor kan je dingen
doen als "fwupdmgr get-updates" (denk "apt-get update"), "fwupdmgr
update" (om ze te installeren), "fwupdmgr verify" (controleren dat je
firmware correct geïnstalleerd is), en zelfs "fwupdmgr downgrade"
(hoewel dat in sommige gevallen niet ondersteund is). Het lijkt me dat
dat iets is wat je op een server wel zou prefereren, dan.

> Vroeger was het motto: "vervang firmware alleen als er een
> probleem is".

Sommige problemen zijn niet meteen zichtbaar, maar dat maakt ze niet
minder problematisch. Firmware-updates kunnen security issues fixen
(spectre/meltdown en dergelijke, maar ook gelijkaardige problemen in
chipsets), kunnen performantie-problemen oplossen, en nog veel meer.

Maar als je dat niet wilt, dan laat "fwupdmgr inhibit" je toe om alle
automatische updates te verbieden.

Of je kan fwupd ook van je systeem verwijderen, natuurlijk.

[...]
-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: UEFI op servers, of niet?

[Wouter Verhelst]

On Tue, Aug 15, 2023 at 12:13:54PM +0200, Paul van der Vlis wrote:
> Hallo,
> 
> Wat is jullie mening over UEFI?  Ik vind het nogal een complex gebeuren
> waarbij aardig wat dingen mee mis kunnen gaan. En wellicht ook minder veilig
> dan "legacy".

Dat lijkt me net het omgekeerde. UEFI laat toe om signed boots te
ondersteunen; BIOS niet.

(Je kan natuurlijk argumenteren dat je geen signed boot wilt want
"Microsoft", maar het principe is an sich wel zinvol en geeft je een
veiliger systeem)

> Het feit dat er vrij automatisch firmware wordt geïnstalleerd van de
> fabrikant vind ik niet prettig. Maar dit is vast uit te zetten ;-)

Wat is daar mis mee?

Via lvfs en fwupd heb ik al een aantal buggy systemen kunnen updaten.
Helaas is nog niet alles op die manier beschikbaar.

> Ik wil graag dat alles op RAID1 komt (mdadm, maar ook alternatieven zijn
> bespreekbaar), en het liefst ook op LVM of soortgelijk.

Persoonlijk grote fan van ZFS, wat de twee een beetje combineert.

Lastig owv licenties, maar het is allemaal vrije software, dus ik lig er
niet zo wakker van.

> Ik heb nog geen ervaring om de EFI partitie op mdadm RAID1 te zetten, maar
> misschien dat het wel kan.  Wat ik in de praktijk doe is de partitie
> kopiëren naar de andere disk met dd.

Denk niet dat dat mogelijk is, maar je kan het wel uitproberen? Als het
niet werkt is het snel en eenvoudig op te lossen met een rescue disk...

Je kan eventueel wel een scriptje toevoegen aan /etc/grub.d wat de EFI
partitie van je eerste schijf kopiëert naar de tweede schijf (op
filesystem-niveau of met dd). Dan is je systeem altijd in sync na de
meest recente "update-grub".

> Ook grote disks kunnen ook zonder EFI, maar dan is er een BIOS BOOT partitie
> nodig. Ik weet niet goed of dat op RAID1 kan.

Dat is zeker geen probleem. Heb het in het verleden al gedaan.

> Ik zag overigens ook iemand die mdadm gebruikte op de hele schijf, dus niet
> op partities. Ik had problemen om in de rescue-mode van de debian-installer
> de RAID5 te maken (er was een disk defect). Wat vinden jullie van deze
> constructie?  Zal dit ook b.v. de boot-sector en partitie-tabel automatisch
> in de RAID opnemen?

Neen. Zo'n constructie werkt alleen met BIOS boot, en alleen met Linux.
Je moet dan je MBR volledig bootable maken, en er voor zorgen dat je
boot loader je partities kan lezen (i.e., geen RAID5).

Ben niet van mening dat het een goed idee is.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: UEFI op servers, of niet?

[Paul van der Vlis]

Op 22-08-2023 om 23:01 schreef Paul van der Vlis:


Oh ja, ook om te checken of er een voeding is.


Ik bedoelde:  om te checken of er een voeding defect is.

De computers die ik gebruik hebben een dubbele voeding, als er eentje 
defect is moet je dat wel weten om hem te kunnen vervangen.


Groet,
Paul

--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: UEFI op servers, of niet?

[Paul van der Vlis]

Hoi Dennis, en anderen natuurlijk,

Op 22-08-2023 om 12:22 schreef Dennis van Dok:

On 22-08-2023 11:54, Paul van der Vlis wrote:

Hallo Dennis en anderen,

Op 22-08-2023 om 10:45 schreef Dennis van Dok:

On 15-08-2023 12:13, Paul van der Vlis wrote:


We zijn (bij Nikhef, plusminus 500 systemen) al een paar jaar 
helemaal over op EFI boot aangezien de nieuwere systemen legacy 
helemaal niet meer ondersteunen. 


Daar heb ik nog geen last van bij servers, bij welke fabrikanten zie 
je dat?


IIRC Dell en Lenovo, in combinatie met ondersteuning voor PXE boot en 
grote NVMe drives.


Hebben ze dan helemaal geen "legacy" meer?  Of wordt dat steeds beperkter?

Welke systemen doen dit? Wij moeten altijd zelf onze firmware bijhouden. 


Ik ken dit eigenlijk alleen van kleinere systemen om eerlijk te zijn, 
bijvoorbeeld van Dell. Maar qua 19" systemen gebruik ik Supermicro en 
dat doet nog niet mee.  Dit is wat ik bedoel:

https://packages.debian.org/bullseye/fwupd
https://fwupd.org/


Ik ga daar nog wel eens naar kijken want het lijkt me toch wel handig om 
te automatiseren (als dat kan). En natuurlijk altijd met de Bewuste 
Keuze™ welke updates je doorvoert!


Het punt is dat het nogal automatisch gaat, ik heb het nog niet helemaal 
onder controle. Dit komt ook omdat de hardware die ikzelf gebruik het 
niet ondersteund.


Ik gebruik in de praktijk geen software van de fabrikant, het is 
allemaal Debian.


DELL heeft racadm en dat werkt nog vrij aardig standalone, maar we 
stappen meer en meer over op redfish.


Dat kende ik nog niet, ik vond hier wel wat informatie:
https://en.wikipedia.org/wiki/Redfish_(specification)

Maar helemaal duidelijk is het me nog niet wat het doet.

Ik gebruik IPMI en serial-over-lan:
https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
Maar daar staat: "The successor to the IPMI is Redfish" Dus wellicht 
moet ik er wel naar gaan kijken.


Zijn er OSS tools voor om bijvoorbeeld het bootproces en de bios remote 
te bekijken?  Dat is eigenlijk het enige waar ik het voor gebruik.

Oh ja, ook om te checken of er een voeding is.

Ik heb altijd met software RAID gewerkt en zie niet veel voordelen aan 
hardware RAID. Er zijn wel voordelen, maar ook nadelen.


Voordelen van software RAID vind ik:
- Het is heel generiek, een disk past zo in een andere machine zonder 
dat die ook zo'n kaart nodig heeft.


Doe je dat dan vaak, schijven uitwisselen tussen apparaten?


Nee, maar het is toch wel belangrijk als nood-scenario, en om te 
migreren naar nieuwe hardware.


Er zou maar een moederbord kapot gaan, dat is me weleens gebeurd. Ik zet 
er dan een andere machine neer, en zet de disks over. Ik heb reserve 
machines (oudere machines die het nog doen).



- De RAID kaart kan kapot gaan, je moet eigenlijk een spare hebben.


Dit is nou een van de componenten die ik zelden tot nooit heb zien falen.


Toch is mij altijd geleerd dat je zo'n kaart op voorraad moet hebben, 
anders kun je je disks niet meer lezen, ook niet met een andere machine.


Wellicht hebben jullie vele machines met dezelfde RAID kaarten, dan 
speelt dat minder.



- Tools zijn vaak closed source, en complex.


We configgen die meuk direct vanuit het BIOS (of laten dat vooraf doen 
door de leverancier) of anders is het Megaraid storcli (ja, beetje 
ingewikkeld wel).


Je moet het toch monitoren, je wilt weten dat er een disk kapot is. En 
ik wil met opensource software werken. Dat geheel maakt het wel lastig.


- Volgens mij moet je bij hardware RAID rebooten als je een disk wilt 
vervangen. (En misschien zelfs wachten tijdens het rebuilden.)


Al onze storage systemen doen hot-swapping dus misschien moet je een 
ander merk uitkiezen?


Misschien is het inderdaad simpel. Ik heb ooit ergens een disk 
verwisseld waar het toch een gedoe was. Maar weinig ervaring met 
hardware raid eigenlijk.



- Je zit directer op de disk, er zit geen kaart tussen


En wat is daarvan nou het specifieke voordeel?


Ik stel het me zo voor dat als je bijvoorbeeld SMART tools gebruikt, je 
niet direct bij de disk kunt.



- Reuze veel mogelijkheden


Ben ook benieuwd!


https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm

Kun jij bijvoorbeeld disks vervangen door grotere, de partities en het 
filesystemen vergroten, terwijl alles gewoon doordraait? Ik wel.



Nadelen van software RAID vind ik:


- Niet geschikt voor systemen met heel veel disks (in elk geval was 
dat vroeger zo).


Ik weet dat we ook wel eens een wat grotere software raid setup hebben 
gedraaid (in de speeltuin) en dat werkte ook prima.


Het had te maken met het feit dat het meer dataverkeer gaf op de PCI 
bus, want elke disk moest apart worden aangestuurd. En bij hardware RAID 
moest alleen de RAID kaart worden aangestuurd. Maar dit kan ondertussen 
alweer anders zijn.


Voor zover ik weet is het een niet echt sneller dan het ander, maar 
misschien vergis ik me daarin.


Nee, dat zal ook niet het argument zijn. Er zijn trouwens behoorlijke 

Re: UEFI op servers, of niet?

[Dennis van Dok]

On 22-08-2023 11:54, Paul van der Vlis wrote:

Hallo Dennis en anderen,

Op 22-08-2023 om 10:45 schreef Dennis van Dok:

On 15-08-2023 12:13, Paul van der Vlis wrote:


We zijn (bij Nikhef, plusminus 500 systemen) al een paar jaar helemaal 
over op EFI boot aangezien de nieuwere systemen legacy helemaal niet 
meer ondersteunen. 


Daar heb ik nog geen last van bij servers, bij welke fabrikanten zie je 
dat?


IIRC Dell en Lenovo, in combinatie met ondersteuning voor PXE boot en 
grote NVMe drives.


Welke systemen doen dit? Wij moeten altijd zelf onze firmware bijhouden. 


Ik ken dit eigenlijk alleen van kleinere systemen om eerlijk te zijn, 
bijvoorbeeld van Dell. Maar qua 19" systemen gebruik ik Supermicro en 
dat doet nog niet mee.  Dit is wat ik bedoel:

https://packages.debian.org/bullseye/fwupd
https://fwupd.org/


Ik ga daar nog wel eens naar kijken want het lijkt me toch wel handig om 
te automatiseren (als dat kan). En natuurlijk altijd met de Bewuste 
Keuze™ welke updates je doorvoert!


Ik gebruik in de praktijk geen software van de fabrikant, het is 
allemaal Debian.


DELL heeft racadm en dat werkt nog vrij aardig standalone, maar we 
stappen meer en meer over op redfish.


Ik heb altijd met software RAID gewerkt en zie niet veel voordelen aan 
hardware RAID. Er zijn wel voordelen, maar ook nadelen.


Voordelen van software RAID vind ik:
- Het is heel generiek, een disk past zo in een andere machine zonder 
dat die ook zo'n kaart nodig heeft.


Doe je dat dan vaak, schijven uitwisselen tussen apparaten?


- De RAID kaart kan kapot gaan, je moet eigenlijk een spare hebben.


Dit is nou een van de componenten die ik zelden tot nooit heb zien falen.


- Tools zijn vaak closed source, en complex.


We configgen die meuk direct vanuit het BIOS (of laten dat vooraf doen 
door de leverancier) of anders is het Megaraid storcli (ja, beetje 
ingewikkeld wel).


- Volgens mij moet je bij hardware RAID rebooten als je een disk wilt 
vervangen. (En misschien zelfs wachten tijdens het rebuilden.)


Al onze storage systemen doen hot-swapping dus misschien moet je een 
ander merk uitkiezen?



- Je zit directer op de disk, er zit geen kaart tussen


En wat is daarvan nou het specifieke voordeel?


- Reuze veel mogelijkheden


Ben ook benieuwd!


Nadelen van software RAID vind ik:


- Niet geschikt voor systemen met heel veel disks (in elk geval was dat 
vroeger zo).


Ik weet dat we ook wel eens een wat grotere software raid setup hebben 
gedraaid (in de speeltuin) en dat werkte ook prima.



Voor zover ik weet is het een niet echt sneller dan het ander, maar 
misschien vergis ik me daarin.


Nee, dat zal ook niet het argument zijn. Er zijn trouwens behoorlijke 
kwaliteitsverschillen in hardware raid.


De EFI partitie moet leesbaar zijn voor de firmware. Met hardware RAID 
is dat volgens mij geen probleem, maar het komt me voor dat de BIOS 
niet snapt wat een software raid partitie is. 


Dat snappen ze inderdaad niet, maar ze kunnen het volgens mij wel gewoon 
lezen en booten. Dat doen ze dan van de individule disk, niet van de RAID.


Ja, legacy boot van een bootsector zal wel gaan denk ik. En misschien is 
een moderne grub ook al software raid aware?


Als ze erop schrijven (ik weet niet zeker of ze dat weleens doen), 
zullen ze ook op de disk schrijven en niet op de RAID.


Dat zouden ze nooit moeten doen!



Misschien is een los klein SSD'tje dan een idee? Een andere 
mogelijkheid is om op één schijf de EFI partitie te maken en op de 
andere dezelfde ruimte te benutten als swap ofzo. Dan houd je de 
geometrie op de resterende ruimte over voor software raid 1.


Mijn punt is dat dit een single point of failure is. Bij software RAID 
kan ik met IPMI in het bios de bootdisk wijzigen, en dan boot hij weer. 
Of fysiek de disks wisselen.


De vraag is of je gaat voor data security (dus hoe belangrijk vind je 
het dat je geen data verliest) of voor uptime (hoe belangrijk is het om 
beschikbaar te zijn). Voor beide kun je plannen maar het prijskaartje 
wordt natuurlijk ook steeds hoger.

Re: UEFI op servers, of niet?

[Paul van der Vlis]

Hallo Dennis en anderen,

Op 22-08-2023 om 10:45 schreef Dennis van Dok:

On 15-08-2023 12:13, Paul van der Vlis wrote:

Hallo,

Wat is jullie mening over UEFI?  Ik vind het nogal een complex 
gebeuren waarbij aardig wat dingen mee mis kunnen gaan. En wellicht 
ook minder veilig dan "legacy".


Niet per se, maar moderne systemen hebben steeds meer management aan 
boord die op zich weer een aanvalsvector kan vormen. Het beangstigendste 
daarbij is hoezeer deze verweven zijn met het systeem, onder het OS 
niveau. Dus aanvallen om private keys uit het geheugen te vissen zonder 
dat je dat in het OS in de gaten hebt bijvoorbeeld.


Inderdaad.

We zijn (bij Nikhef, plusminus 500 systemen) al een paar jaar helemaal 
over op EFI boot aangezien de nieuwere systemen legacy helemaal niet 
meer ondersteunen. 


Daar heb ik nog geen last van bij servers, bij welke fabrikanten zie je dat?

Met netboot en grub-efi werkt bijna alles als 
voorheen, en ik zie de boot manager zelfs wel as een pre. Maar inderdaad 
is het vooral een kwestie van de kernel booten en dat is het.


Het feit dat er vrij automatisch firmware wordt geïnstalleerd van de 
fabrikant vind ik niet prettig. Maar dit is vast uit te zetten ;-)


Welke systemen doen dit? Wij moeten altijd zelf onze firmware bijhouden. 


Ik ken dit eigenlijk alleen van kleinere systemen om eerlijk te zijn, 
bijvoorbeeld van Dell. Maar qua 19" systemen gebruik ik Supermicro en 
dat doet nog niet mee.  Dit is wat ik bedoel:

https://packages.debian.org/bullseye/fwupd
https://fwupd.org/

Hoewel $VENDOR1 een systeem biedt om dat te automatiseren gebruiken wij 
dat liever niet want dan zit je daaraan vast, terwijl we ook spullen van 
$VENDOR2 willen kunnen kopen en gebruiken.


Ik gebruik in de praktijk geen software van de fabrikant, het is 
allemaal Debian.


Het enige voorbeeld wat me te binnen schiet zijn de 'intelligente' 
lampen die je met een app kunt dimmen. Die deden het niet meer toen ik 
hun internettoegang uitschakelde.


Dat soort dingen heb ik graag lokaal geregeld ;-)

Ik wil graag dat alles op RAID1 komt (mdadm, maar ook alternatieven 
zijn bespreekbaar), en het liefst ook op LVM of soortgelijk.


Wees dapper en die RAID0 all the way. (geintje). Volgens mij ondersteund 
de Debian installer dit wel. Als je een redelijke RAID kaart hebt kun je 
het beter aan de hardware overlaten, lijkt me.


Ik heb altijd met software RAID gewerkt en zie niet veel voordelen aan 
hardware RAID. Er zijn wel voordelen, maar ook nadelen.


Voordelen van software RAID vind ik:
- Het is heel generiek, een disk past zo in een andere machine zonder 
dat die ook zo'n kaart nodig heeft.

- De RAID kaart kan kapot gaan, je moet eigenlijk een spare hebben.
- Tools zijn vaak closed source, en complex.
- Volgens mij moet je bij hardware RAID rebooten als je een disk wilt 
vervangen. (En misschien zelfs wachten tijdens het rebuilden.)

- Je zit directer op de disk, er zit geen kaart tussen
- Reuze veel mogelijkheden

Nadelen van software RAID vind ik:
- Defecte disk verwisselen is iets lastiger
- Als de boot-disk defect is, wil het systeem soms niet meer booten 
zonder andere actie zoals het bios aanpassen of disks verwisselen
- Inrichten (en wellicht bijhouden) is ingewikkelder, je moet 
bijvoorbeeld Grub twee keer installeren, en wellicht EFI kopieren.
- Niet geschikt voor systemen met heel veel disks (in elk geval was dat 
vroeger zo).


Voor zover ik weet is het een niet echt sneller dan het ander, maar 
misschien vergis ik me daarin.


Als je veel systemen hebt met allemaal dezelfde hardware RAID, ziet het 
plaatje er misschien iets anders uit.


Ik heb nog geen ervaring om de EFI partitie op mdadm RAID1 te zetten, 
maar misschien dat het wel kan.  Wat ik in de praktijk doe is de 
partitie kopiëren naar de andere disk met dd.


De EFI partitie moet leesbaar zijn voor de firmware. Met hardware RAID 
is dat volgens mij geen probleem, maar het komt me voor dat de BIOS niet 
snapt wat een software raid partitie is. 


Dat snappen ze inderdaad niet, maar ze kunnen het volgens mij wel gewoon 
lezen en booten. Dat doen ze dan van de individule disk, niet van de RAID.


Als ze erop schrijven (ik weet niet zeker of ze dat weleens doen), 
zullen ze ook op de disk schrijven en niet op de RAID.


Misschien is een los klein 
SSD'tje dan een idee? Een andere mogelijkheid is om op één schijf de EFI 
partitie te maken en op de andere dezelfde ruimte te benutten als swap 
ofzo. Dan houd je de geometrie op de resterende ruimte over voor 
software raid 1.


Mijn punt is dat dit een single point of failure is. Bij software RAID 
kan ik met IPMI in het bios de bootdisk wijzigen, en dan boot hij weer. 
Of fysiek de disks wisselen.


Dit is overigens wel complexer dan bij hardware RAID. Jammer dat er geen 
biossen zijn (voor zover ik weet) die dit netjes oplossen (zonder fakeraid).



Ik denk dat LVM het native ook kan maar dat heb ik nooit geprobeerd.



Ook grote disks kunnen ook zonder EFI, maar dan is er een 

Re: UEFI op servers, of niet?

[Dennis van Dok]

On 15-08-2023 12:13, Paul van der Vlis wrote:

Hallo,

Wat is jullie mening over UEFI?  Ik vind het nogal een complex gebeuren 
waarbij aardig wat dingen mee mis kunnen gaan. En wellicht ook minder 
veilig dan "legacy".


Niet per se, maar moderne systemen hebben steeds meer management aan 
boord die op zich weer een aanvalsvector kan vormen. Het beangstigendste 
daarbij is hoezeer deze verweven zijn met het systeem, onder het OS 
niveau. Dus aanvallen om private keys uit het geheugen te vissen zonder 
dat je dat in het OS in de gaten hebt bijvoorbeeld.


We zijn (bij Nikhef, plusminus 500 systemen) al een paar jaar helemaal 
over op EFI boot aangezien de nieuwere systemen legacy helemaal niet 
meer ondersteunen. Met netboot en grub-efi werkt bijna alles als 
voorheen, en ik zie de boot manager zelfs wel as een pre. Maar inderdaad 
is het vooral een kwestie van de kernel booten en dat is het.


Het feit dat er vrij automatisch firmware wordt geïnstalleerd van de 
fabrikant vind ik niet prettig. Maar dit is vast uit te zetten ;-)


Welke systemen doen dit? Wij moeten altijd zelf onze firmware bijhouden. 
Hoewel $VENDOR1 een systeem biedt om dat te automatiseren gebruiken wij 
dat liever niet want dan zit je daaraan vast, terwijl we ook spullen van 
$VENDOR2 willen kunnen kopen en gebruiken.


Het enige voorbeeld wat me te binnen schiet zijn de 'intelligente' 
lampen die je met een app kunt dimmen. Die deden het niet meer toen ik 
hun internettoegang uitschakelde.


Ik wil graag dat alles op RAID1 komt (mdadm, maar ook alternatieven zijn 
bespreekbaar), en het liefst ook op LVM of soortgelijk.


Wees dapper en die RAID0 all the way. (geintje). Volgens mij ondersteund 
de Debian installer dit wel. Als je een redelijke RAID kaart hebt kun je 
het beter aan de hardware overlaten, lijkt me.


Ik heb nog geen ervaring om de EFI partitie op mdadm RAID1 te zetten, 
maar misschien dat het wel kan.  Wat ik in de praktijk doe is de 
partitie kopiëren naar de andere disk met dd.


De EFI partitie moet leesbaar zijn voor de firmware. Met hardware RAID 
is dat volgens mij geen probleem, maar het komt me voor dat de BIOS niet 
snapt wat een software raid partitie is. Misschien is een los klein 
SSD'tje dan een idee? Een andere mogelijkheid is om op één schijf de EFI 
partitie te maken en op de andere dezelfde ruimte te benutten als swap 
ofzo. Dan houd je de geometrie op de resterende ruimte over voor 
software raid 1.


Ik denk dat LVM het native ook kan maar dat heb ik nooit geprobeerd.


Ook grote disks kunnen ook zonder EFI, maar dan is er een BIOS BOOT 
partitie nodig. Ik weet niet goed of dat op RAID1 kan.


Nee om dezelfde reden als hierboven (tenzij hardware RAID).

Ik zag overigens ook iemand die mdadm gebruikte op de hele schijf, dus 
niet op partities. Ik had problemen om in de rescue-mode van de 
debian-installer de RAID5 te maken (er was een disk defect). Wat vinden 
jullie van deze constructie?  Zal dit ook b.v. de boot-sector en 
partitie-tabel automatisch in de RAID opnemen?


We hebben voor storage systemen eigenlijk altijd een losse SSD voor het 
OS. Het klinkt als een nodeloos ingewikkelde constructie en vragen om 
moeilijkheden.


Dennis

Re: UEFI op servers, of niet?

[Paul van der Vlis]

Hallo Geert en anderen,

Op 16-08-2023 om 22:26 schreef Geert Stappers:

On Tue, Aug 15, 2023 at 12:13:54PM +0200, Paul van der Vlis wrote:

Hallo,

Wat is jullie mening over UEFI?


Het is vooral een "bootloader"


Ik gebruik GRUB als bootloader, maar wellicht is dit een wat vaag 
begrip. Ik geloof dat UEFI ook een Linux kernel kan laden, maar dit weet 
ik niet precies.


Dit komt van Wikipedia:

UEFI is a specification that defines the architecture of the platform 
firmware used for booting and its interface for interaction with the 
operating system.




Ik vind het nogal een complex gebeuren waarbij aardig wat dingen mee
mis kunnen gaan.  En wellicht ook minder veilig dan "legacy".


Ik vind belangrijk dat een bootloader  bootloader-dingen doet.
En ook niet veel meer dan dat.


UEFI is volgens mij bijna een operating system.
GRUB overigens ook.


Het feit dat er vrij automatisch firmware
wordt geïnstalleerd van de fabrikant


Nog niet mee gemaakt.


Niet elke fabrikant doet er aan mee.


vind ik niet prettig.


Als je dat die "auto firmware update by firmware" kunt aantonen,
ga dan ingesprek met je leverancier.
Het is een "feature" van UEFI. De firmware updated niet de firmware, dat 
doet bijvoorbeeld: https://packages.debian.org/bullseye/fwupd

Dit wordt standaard geïnstalleerd door Debian volgens mij.
De leverancier stopt het in: https://fwupd.org/


De betere leverancier is ook al eerder aanspreekbaar.


Dit heeft niet zoveel met de leverancier te maken, ik vind het goed dat 
ze de firmware uploaden. Ik vind dat het alleen nogal automatisch 
gebeurd allemaal. Vroeger was het motto: "vervang firmware alleen als er 
een probleem is".


Een vriendin zei ooit: "alles wat in software kan, kan ook in hardware. 
Hardware is alleen wat minder flexibel". Die updates zorgen voor meer 
flexibele hardware, waar ik niet perse voor ben. Want veelal draait er 
in de praktijk closed source firmware op, die steeds belangrijker wordt.



Maar dit is vast uit te zetten ;-)


Read the fine manual   ;-)


Inderdaad, nu ja, soms staat die "f" ook weleens voor wat anders...

Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: UEFI op servers, of niet?

[Geert Stappers]

On Tue, Aug 15, 2023 at 12:13:54PM +0200, Paul van der Vlis wrote:
> Hallo,
> 
> Wat is jullie mening over UEFI?

Het is vooral een "bootloader"


> Ik vind het nogal een complex gebeuren waarbij aardig wat dingen mee
> mis kunnen gaan.  En wellicht ook minder veilig dan "legacy".

Ik vind belangrijk dat een bootloader  bootloader-dingen doet.
En ook niet veel meer dan dat.
 
> Het feit dat er vrij automatisch firmware
> wordt geïnstalleerd van de fabrikant

Nog niet mee gemaakt.


> vind ik niet prettig.

Als je dat die "auto firmware update by firmware" kunt aantonen,
ga dan ingesprek met je leverancier.
De betere leverancier is ook al eerder aanspreekbaar.


> Maar dit is vast uit te zetten ;-)

Read the fine manual   ;-)



Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: UEFI refusing NVRAM writes, breaking GRUB install and upgrade

[vinceh121]

Thanks a lot, this is very useful!

 - vinceh121

On 9/18/22 13:42, Steve McIntyre wrote:

On Sat, Sep 17, 2022 at 03:07:29AM +0200, vinceh121 wrote:

Thanks, this works!

Is there a way to set this option during installation on a netinst image?


Yes! You can switch to expert mode for installation and then
grub-efi-$ARCH will ask you these questions. Or you can add these
options using a preseed, tweaking the following settings to change
from the default answers.

### Description: Force extra installation to the EFI removable media path?
#   Some EFI-based systems are buggy and do not handle new bootloaders 
correctly.
#   If you force an extra installation of GRUB to the EFI removable media path,
#   this should ensure that this system will boot Debian correctly despite such 
a
#   problem. However, it may remove the ability to boot any other operating
#   systems that also depend on this path. If so, you will need to make sure 
that
#   GRUB is configured successfully to be able to boot any other OS 
installations
#   correctly.
# d-i grub2/force_efi_extra_removable boolean false

### Description: Update NVRAM variables to automatically boot into Debian?
#   GRUB can configure your platform's NVRAM variables so that it boots into
#   Debian automatically when powered on. However, you may prefer to disable
#   this behavior and avoid changes to your boot configuration. For example,
#   if your NVRAM variables have been set up such that your system contacts a
#   PXE server on every boot, this would preserve that behavior.
# d-i grub2/update_nvram boolean true



OpenPGP_signature
Description: OpenPGP digital signature

Re: UEFI refusing NVRAM writes, breaking GRUB install and upgrade

[Steve McIntyre]

On Sat, Sep 17, 2022 at 03:07:29AM +0200, vinceh121 wrote:
>Thanks, this works!
>
>Is there a way to set this option during installation on a netinst image?

Yes! You can switch to expert mode for installation and then
grub-efi-$ARCH will ask you these questions. Or you can add these
options using a preseed, tweaking the following settings to change
from the default answers.

### Description: Force extra installation to the EFI removable media path?
#   Some EFI-based systems are buggy and do not handle new bootloaders 
correctly.
#   If you force an extra installation of GRUB to the EFI removable media path,
#   this should ensure that this system will boot Debian correctly despite such 
a
#   problem. However, it may remove the ability to boot any other operating
#   systems that also depend on this path. If so, you will need to make sure 
that
#   GRUB is configured successfully to be able to boot any other OS 
installations
#   correctly.
# d-i grub2/force_efi_extra_removable boolean false

### Description: Update NVRAM variables to automatically boot into Debian?
#   GRUB can configure your platform's NVRAM variables so that it boots into
#   Debian automatically when powered on. However, you may prefer to disable
#   this behavior and avoid changes to your boot configuration. For example,
#   if your NVRAM variables have been set up such that your system contacts a
#   PXE server on every boot, this would preserve that behavior.
# d-i grub2/update_nvram boolean true

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

Re: UEFI refusing NVRAM writes, breaking GRUB install and upgrade

[vinceh121]

Thanks, this works!

Is there a way to set this option during installation on a netinst image?
 - vinceh121


On 9/17/22 00:03, Steve McIntyre wrote:

vinceh121 wrote:


Southern French government is handing out laptops (HP ProBook x360 G1
EE) to students, whom a lot of want to install a Linux distro on.

However, many distros installs are broken by grub-install either safely
failing, or making the kernel hang while trying to write NVRAM boot
options. I've confirmed this on Debian Buster and Bullseye.

This causes the netinst images to give us a mostly working installation,
except for a config-less GRUB. For now, we've gone around this by
manually booting with the GRUB CLI, and then running grub-install with
the --no-nvram option.

However, the problem reappears when running apt upgrade.

Is there a way to mitigate this problem? Maybe a way to tell
grub-install to always use --no-nvram?


Yup. See 
https://wiki.debian.org/UEFI#Firmware_does_not_support_setting_boot_variables



OpenPGP_signature
Description: OpenPGP digital signature

Re: UEFI refusing NVRAM writes, breaking GRUB install and upgrade

[Steve McIntyre]

vinceh121 wrote:
>
>Southern French government is handing out laptops (HP ProBook x360 G1 
>EE) to students, whom a lot of want to install a Linux distro on.
>
>However, many distros installs are broken by grub-install either safely 
>failing, or making the kernel hang while trying to write NVRAM boot 
>options. I've confirmed this on Debian Buster and Bullseye.
>
>This causes the netinst images to give us a mostly working installation, 
>except for a config-less GRUB. For now, we've gone around this by 
>manually booting with the GRUB CLI, and then running grub-install with 
>the --no-nvram option.
>
>However, the problem reappears when running apt upgrade.
>
>Is there a way to mitigate this problem? Maybe a way to tell 
>grub-install to always use --no-nvram?

Yup. See 
https://wiki.debian.org/UEFI#Firmware_does_not_support_setting_boot_variables

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Re: UEFI refusing NVRAM writes, breaking GRUB install and upgrade

[DdB]

Am 16.09.2022 um 20:19 schrieb vinceh121:
> Is there a way to mitigate this problem?

Apart from the plan, you seem to be favoring, i would like to introduce
another option to you:
(BTW: I used it myself, and still do, while i was learning to
reconfigure to UEFI-Booting)

There is a sort of boot manager, that is perfectly independant from
grub, but can use grub, if desired. i am thinking of refind (is in
debian repos and also available from website by the author of gdisk).

I suggest you take a look as it *might* be able to start independantly
without the necessity to use NVRAM.

just my 2 cents
DdB

Re: UEFI + LEGACY op USB

[Wouter Verhelst]

On Mon, Sep 20, 2021 at 10:00:35PM +0200, Paul van der Vlis wrote:
> Op 20-09-2021 om 10:10 schreef Wouter Verhelst:
> > Hoi Paul,
> > 
> > On Fri, Sep 17, 2021 at 01:43:10PM +0200, Paul van der Vlis wrote:
> > > Hallo,
> > > 
> > > Ik gebruik een USB-naar-SATA adapter en daaraan hang ik dan een SSD waarop
> > > ik Debian installeer. En van daar wil ik booten.
> > > 
> > > Die SSD zou ik graag zowel bootbaar hebben met UEFI, als via de oude 
> > > legacy
> > > methode. Dus dat het werkt onafhankelijk van de instelling van het BIOS.
> > 
> > Dat is redelijk complex om te doen.
> > 
> > Debian-installer krijgt dat klaar via een paar hacks die in xorriso
> > geïmplementeerd zijn. Het genereert een image met een paar "rare" bytes
> > op speciale offsets waardoor het voor zowel UEFI als BIOS lijkt te
> > werken.
> > 
> > Zie
> > https://salsa.debian.org/installer-team/debian-installer/-/blob/master/build/config/x86.cfg#L341-351
> > voor details.
> > 
> > Merk op dat er naast de "xorriso" calls nog andere dingen zijn die
> > nodig zijn om het te laten werken. Ik heb er nooit in detail naar
> > gekeken; maar dat is de code die het doet werken, dus als je het aan de
> > praat wilt krijgen dan zal je daar naar moeten kijken...
> 
> Bedankt!
> 
> Het lijkt echter wel erg voor isolinux te zijn, 

Nee hoor. Debian-installer gebruikt ook grub, tegenwoordig.

> en dat wou ik eigenlijk niet gebruiken... Wellicht is wat ik wil te lastig.

Ik vrees daarvoor, ja.

> Ik lees wel: "Can activate ISOLINUX and GRUB boot equipment by El Torito
> boot record, MBR code for BIOS, or EFI System Partition."
> https://www.gnu.org/software/xorriso/

Exact.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: UEFI + LEGACY op USB

[Paul van der Vlis]

Op 20-09-2021 om 10:10 schreef Wouter Verhelst:

Hoi Paul,

On Fri, Sep 17, 2021 at 01:43:10PM +0200, Paul van der Vlis wrote:

Hallo,

Ik gebruik een USB-naar-SATA adapter en daaraan hang ik dan een SSD waarop
ik Debian installeer. En van daar wil ik booten.

Die SSD zou ik graag zowel bootbaar hebben met UEFI, als via de oude legacy
methode. Dus dat het werkt onafhankelijk van de instelling van het BIOS.


Dat is redelijk complex om te doen.

Debian-installer krijgt dat klaar via een paar hacks die in xorriso
geïmplementeerd zijn. Het genereert een image met een paar "rare" bytes
op speciale offsets waardoor het voor zowel UEFI als BIOS lijkt te
werken.

Zie
https://salsa.debian.org/installer-team/debian-installer/-/blob/master/build/config/x86.cfg#L341-351
voor details.

Merk op dat er naast de "xorriso" calls nog andere dingen zijn die
nodig zijn om het te laten werken. Ik heb er nooit in detail naar
gekeken; maar dat is de code die het doet werken, dus als je het aan de
praat wilt krijgen dan zal je daar naar moeten kijken...


Bedankt!

Het lijkt echter wel erg voor isolinux te zijn, en dat wou ik eigenlijk 
niet gebruiken... Wellicht is wat ik wil te lastig.


Ik lees wel: "Can activate ISOLINUX and GRUB boot equipment by El Torito 
boot record, MBR code for BIOS, or EFI System Partition."

https://www.gnu.org/software/xorriso/

Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: UEFI + LEGACY op USB

[Wouter Verhelst]

Hoi Paul,

On Fri, Sep 17, 2021 at 01:43:10PM +0200, Paul van der Vlis wrote:
> Hallo,
> 
> Ik gebruik een USB-naar-SATA adapter en daaraan hang ik dan een SSD waarop
> ik Debian installeer. En van daar wil ik booten.
> 
> Die SSD zou ik graag zowel bootbaar hebben met UEFI, als via de oude legacy
> methode. Dus dat het werkt onafhankelijk van de instelling van het BIOS.

Dat is redelijk complex om te doen.

Debian-installer krijgt dat klaar via een paar hacks die in xorriso
geïmplementeerd zijn. Het genereert een image met een paar "rare" bytes
op speciale offsets waardoor het voor zowel UEFI als BIOS lijkt te
werken.

Zie
https://salsa.debian.org/installer-team/debian-installer/-/blob/master/build/config/x86.cfg#L341-351
voor details.

Merk op dat er naast de "xorriso" calls nog andere dingen zijn die
nodig zijn om het te laten werken. Ik heb er nooit in detail naar
gekeken; maar dat is de code die het doet werken, dus als je het aan de
praat wilt krijgen dan zal je daar naar moeten kijken...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: UEFI + LEGACY op USB

[Paul van der Vlis]

Hoi Roland, en anderen,

Op 18-09-2021 om 09:44 schreef Roland Clobus:

Hallo Paul,

On 17/09/2021 13:43, Paul van der Vlis wrote:

Ik gebruik een USB-naar-SATA adapter en daaraan hang ik dan een SSD
waarop ik Debian installeer. En van daar wil ik booten.

Die SSD zou ik graag zowel bootbaar hebben met UEFI, als via de oude
legacy methode. Dus dat het werkt onafhankelijk van de instelling van
het BIOS.

De Debian USB-sticks kunnen dit, weet iemand hier hoe je dat ook zelf
kunt realiseren?


Je zou kunnen kijken naar het pakket 'live-build'. Hiermee kun je zelf
live images maken (NB op een net iets andere manier dan de officiële
live images van Debian).


Het nadeel van live-images vind ik, dat ik er niets blijvend aan kan 
veranderen. Na een reboot zijn mijn wijzigingen weer weg. Daarom kan er 
veel niet.


Wat ik daarom doe is een echte installatie op een extern medium. Het 
lukt me echter tot nu toe niet om die zo te maken dat het zowel werkt 
met UEFI als met Legacy.


Bedankt voor je verhaal over live-images, ik moet er weer eens naar 
kijken want ze zijn ook leuk voor bepaalde toepassingen. Maar toch, ik 
gebruik veel vaker een echte installatie.


Groet,
Paul

--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: UEFI + LEGACY op USB

[Paul van der Vlis]

Hoi Geert en anderen,

Op 18-09-2021 om 09:13 schreef Geert Stappers:

On Fri, Sep 17, 2021 at 01:43:10PM +0200, Paul van der Vlis wrote:

Hallo,

Ik gebruik een USB-naar-SATA adapter en daaraan hang ik dan een SSD waarop
ik Debian installeer. En van daar wil ik booten.

Die SSD zou ik graag zowel bootbaar hebben met UEFI, als via de oude legacy
methode. Dus dat het werkt onafhankelijk van de instelling van het BIOS.

De Debian USB-sticks kunnen dit, weet iemand hier hoe je dat ook zelf kunt
realiseren?



Interresante uitdaging.

Wild idee:

De SSD voorzien met Debian-Installer plus een preseed-file.


Ik heb meerdere USB-poorten. Wat ik normaal zou doen is booten vanaf een 
USB-stick met de Debian installer, en als target de SSD gebruiken.


Omdat er maar 1 iets gemaakt wordt, lijkt me een preseed file overdreven.


In die preseed-file ook aanroep van aanvullende scripts.

Bij de eerste boot moet er dan dit gebeuren:

* Debian-Installer wordt gestart
* preseed file wordt gevonden
* inhoud van preseed file wordt gebruikt
* automatisch verloop van de installatie
   hierbij wordt de SSD overschreven
* Reboot


Hmm, kan dat niet handiger, directer?

Misschien mis ik iets.

Groeten,
Paul




--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: UEFI + LEGACY op USB

[Roland Clobus]

Hallo Paul,

On 17/09/2021 13:43, Paul van der Vlis wrote:
> Ik gebruik een USB-naar-SATA adapter en daaraan hang ik dan een SSD
> waarop ik Debian installeer. En van daar wil ik booten.
> 
> Die SSD zou ik graag zowel bootbaar hebben met UEFI, als via de oude
> legacy methode. Dus dat het werkt onafhankelijk van de instelling van
> het BIOS.
> 
> De Debian USB-sticks kunnen dit, weet iemand hier hoe je dat ook zelf
> kunt realiseren?

Je zou kunnen kijken naar het pakket 'live-build'. Hiermee kun je zelf
live images maken (NB op een net iets andere manier dan de officiële
live images van Debian).

Images gemaakt met live-build kun je zowel met UEFI als legacy starten.
De scripten van live-build installeren zowel een UEFI map als een
isolinux map in de gebouwde images.

De algemene handleiding voor live images is hier:
https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html

Live-build is hier:
https://packages.debian.org/bullseye/live-build

Met vriendelijke groeten,
Roland Clobus

PS: Als je live-images wilt gaan maken, kijk dan ook eens op
https://wiki.debian.org/ReproducibleInstalls/LiveImages. Daar heb ik een
beschrijving geschreven die het mogelijk maakt om met relatief weinig
netwerkverkeer te experimenteren bij het bouwen van zulke images.
PS2: Disclaimer: ik ben een contributor voor live-build



OpenPGP_signature
Description: OpenPGP digital signature

Re: UEFI + LEGACY op USB

[Geert Stappers]

On Fri, Sep 17, 2021 at 01:43:10PM +0200, Paul van der Vlis wrote:
> Hallo,
> 
> Ik gebruik een USB-naar-SATA adapter en daaraan hang ik dan een SSD waarop
> ik Debian installeer. En van daar wil ik booten.
> 
> Die SSD zou ik graag zowel bootbaar hebben met UEFI, als via de oude legacy
> methode. Dus dat het werkt onafhankelijk van de instelling van het BIOS.
> 
> De Debian USB-sticks kunnen dit, weet iemand hier hoe je dat ook zelf kunt
> realiseren?


Interresante uitdaging.

Wild idee:

De SSD voorzien met Debian-Installer plus een preseed-file.
In die preseed-file ook aanroep van aanvullende scripts.

Bij de eerste boot moet er dan dit gebeuren:

* Debian-Installer wordt gestart
* preseed file wordt gevonden
* inhoud van preseed file wordt gebruikt
* automatisch verloop van de installatie
  hierbij wordt de SSD overschreven
* Reboot



Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: UEFI and legacy MBR

[mick crane]

On 2020-11-21 11:29, mick crane wrote:

hello,
I'm having a bit of bother trying to install windows and Bullseye on 
PC.


never mind it all seems to be working
mick

--
Key ID4BFEBB31

[Résolu] Re: UEFI Bios : Disque système ne boot plus

[Alain Vaugham]

Le Sun, 31 May 2020 17:45:07 +0200,
Alain Vaugham  a écrit :

> Je me pose donc aujourd'hui la question si c'est normal qu'un disque
> sous Debian ne soit plus accepté par un BIOS-UEFI après qu'il ait été
> simplement démonté/remonté.

Je me réponds à moi-même.
Le BIOS-UEFI AMD 2.16.1240 sur la carte ASUS que j'utilise est
probablement buggé comme c'est suggéré sur :
https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path

Ce que qui m'a dépanné c'est que pour qu'un disque Debian puisse
rebooter sur ce BIOS-UEFI après multiples
démontages/remontages/permutations de disques UEFI Debian/MS Windows, la
seule configuration qui a fonctionné c'est que la Debian soit installée
avec l'option BIOS-UEFI: Démarrage/Compatibilité Support Module=[Auto].
Avec une telle configuration, Netinst ne propose plus l'installation
UEFI mais BIOS.


-- 
Alain Vaugham
Clef GPG : 0xDB77E054673ECFD2

Re: uefi boot install and disk partitions

[Cindy Sue Causey]

On 1/5/20, to...@tuxteam.de  wrote:
> On Sun, Jan 05, 2020 at 10:47:52AM +0100, Pascal Hambourg wrote:
>> Le 04/01/2020 à 20:47, Sven Joachim a écrit :
>
> [FAT, hard links]
>
>> >a feature that is crucial for dpkg.
>>
>> I vaguely remember this, but not when and why dpkg needs to create
>> additional hard links. Can you refresh my memories ?
>
> My search engine is lucky today (no, Goog, no cookies for you today ;-)
>
>
> https://unix.stackexchange.com/questions/208073/dpkg-replacing-files-on-a-fat-filesystem
>
> I'd be more worried about whatever packagers do in their post-install
> scripts. After all, hard links are pretty handy when trying to do
> atomic operations on file systems. If there's no policy explicitly
> banning hard links, I'd expect them to be used...


DISCLAIMER: HOPEFULLY I'm understanding the use of "hard links" here
such as has been my understanding of that topic for *many* years.. :)

For the most part, I thought about the only problem with hard links
was that whatever was using them had to exit an entire hierarchy to
then dig back in from the top to find its target. That comes from my
earliest days of creating anchor links in web design where you're
trying to help your webpages load as fast as possible for the end
user.

As I was sitting pondering this, two thoughts keep floating in my head...

1) Maybe this, primarily the "fat" part of it, somehow explains why
rsync flat out refused to copy a limited number of files over to a USB
for me a few ago. Happened a couple times in different situations. I
can't remember how to recreate it to say yay or nay on it having been
about this topic.

2) A couple years ago, my linux-image installations on debootstraps
were creating "hard" /vmlinuz and /initrd.img links. At some point in
my decades' old perennial newbie-ness, I accidentally stumbled on a
usage case where that very detrimentally linked out of my chroot
somehow... and was targeting my host's /boot directory, i.e. NOT the
intended /mnt/deboostrap/boot directory which it SHOULD have been
seeking, instead...

To this day to fix it, one of my early-on debootstrap checklist points
is to consciously verify that /vmlinuz and /initrd.img symlinks are
being used instead of hard links immediately after apt/apt-get is
finished installing linux-image. Apparently a Developer at some point
noticed the same on some level because I haven't had to create new
links there in a LONG time now.

In wondering how I would have caught that major whoa, maybe it was
that the hard link was reflecting the different kernel version. That
sounds like the most likely way a User would catch that kind of
[anomaly].

Maybe "fat" is trying to (intelligently, proactively) protect us
from the rare occasion something like my experience might occur??

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with... a... seriously... more backup modems... NOW. Because
weather-util says another thunderstorm is in the queue this week.
*

Re: uefi boot install and disk partitions

[Pascal Hambourg]

Le 05/01/2020 à 11:00, to...@tuxteam.de a écrit :

On Sun, Jan 05, 2020 at 10:47:52AM +0100, Pascal Hambourg wrote:

Le 04/01/2020 à 20:47, Sven Joachim a écrit :


[FAT, hard links]


a feature that is crucial for dpkg.


I vaguely remember this, but not when and why dpkg needs to create
additional hard links. Can you refresh my memories ?


   
https://unix.stackexchange.com/questions/208073/dpkg-replacing-files-on-a-fat-filesystem


Thanks. I would be very careful when using a hard link to back up a file 
before replacing it, because it depends on the method used to replace 
the original file with the new file. For example plain 'cp' or shell 
redirection does not break the link and overwrites the contents of the 
original file (and of the hard link), whereas 'cp -d' breaks the link 
and creates a new file.



I'd be more worried about whatever packagers do in their post-install
scripts. After all, hard links are pretty handy when trying to do
atomic operations on file systems.


What kind of atomic operations ?

Re: uefi boot install and disk partitions

[tomas]

On Sun, Jan 05, 2020 at 10:47:52AM +0100, Pascal Hambourg wrote:
> Le 04/01/2020 à 20:47, Sven Joachim a écrit :

[FAT, hard links]

> >a feature that is crucial for dpkg.
> 
> I vaguely remember this, but not when and why dpkg needs to create
> additional hard links. Can you refresh my memories ?

My search engine is lucky today (no, Goog, no cookies for you today ;-)

  
https://unix.stackexchange.com/questions/208073/dpkg-replacing-files-on-a-fat-filesystem

I'd be more worried about whatever packagers do in their post-install
scripts. After all, hard links are pretty handy when trying to do
atomic operations on file systems. If there's no policy explicitly
banning hard links, I'd expect them to be used...

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: uefi boot install and disk partitions

[Pascal Hambourg]

Le 04/01/2020 à 20:47, Sven Joachim a écrit :

On 2020-01-04 13:38 +0100, Pascal Hambourg wrote:


Some new boot specification mounts the EFI partition on /boot


Citation needed, which specification is that?


Freedesktop/systemd's Boot Loader Specification.

now 

Also mentionned in the Discoverable Partitions Specification.




but Debian does not follow it (yet) and still
mounts the EFI partition on /boot/efi.


There are good reasons for not mounting the EFI system partition on
/boot, the most important one is that FAT filesystems do not support
files with multiple hard links,


You mean that FAT filesystems do not support hard links at all. The 
concept of hard link requires some level of indirection between a 
directory entry and a file. In common Unix-like filesystems such as 
ext*, this is provided by inodes structures which contain the file 
metadata. FAT filesystems do not have such indirection and the file 
metadata are contained in the directory entry instead.



a feature that is crucial for dpkg.


I vaguely remember this, but not when and why dpkg needs to create 
additional hard links. Can you refresh my memories ?

Re: uefi boot install and disk partitions

[Sven Joachim]

On 2020-01-04 13:38 +0100, Pascal Hambourg wrote:

> Le 04/01/2020 à 11:25, Bonno Bloksma a écrit :
>
>> If I had not created that /boot partition would those files be in
>> /boot folder on the / (root) partition or would /boot then be on the
>> EFI partition?
>
> On the root partition. Some new boot specification mounts the EFI
> partition on /boot

Citation needed, which specification is that?

> but Debian does not follow it (yet) and still
> mounts the EFI partition on /boot/efi.

There are good reasons for not mounting the EFI system partition on
/boot, the most important one is that FAT filesystems do not support
files with multiple hard links, a feature that is crucial for dpkg.

Cheers,
   Sven

Re: uefi boot install and disk partitions

[Harry Putnam]

Bonno Bloksma  writes:

> Hi,
>
>
>
> I have been creating a small (300MB) primary /boot partition at the
> beginning of the disk for as long as I can remember... That is after
> disks got to be too big for the BIOS to reach all of the disk to be
> able to boot from a file anywhere on the disk.
>
> So far so good, that still works but do I still need that
> partition when I create an EFI System Partition (ESP) to boot using
> UEFI?
>

[...]

First off, I'm pretty sure that Pascal is far more knowledgeable than I
but I just had some experience with setting up  Uefi.  Still working
on it so not tested yet.

It is on a zfs-on-root-linux install so that might be different. But
the part of preparing the disk for booting seems to be the same.

I used `gsdisk' which is in the package `gdisk' in the debian repo.

There are detailed direction by Richard Laager:

I'm quoting a small bit from URL:

https://github.com/zfsonlinux/zfs/wiki/Debian-Buster-Root-on-ZFS

2.3 Partition your disk(s):

  [...] section on non efi boot snipped

   Run this for UEFI booting (for use now or in the future):

   sgdisk -n2:1M:+512M   -t2:EF00 $DISK

   Run this for the boot pool:

   sgdisk -n3:0:+1G  -t3:BF01 $DISK

He's taking about a zpool setup but I think Its the same far as
preparing the disk for uefi booting.

There are more details further on concerning actually installing the
boot code on the disk where booting will occur.  You probably want to
read this part:

   4.8b Install GRUB for UEFI booting 

Re: uefi boot install and disk partitions

[Pascal Hambourg]

Le 04/01/2020 à 11:25, Bonno Bloksma a écrit :


I have been creating a small (300MB) primary /boot partition at the beginning 
of the disk for as long as I can remember... That is after disks got to be too 
big for the BIOS to reach all of the disk to be able to boot from a file 
anywhere on the disk.

So far so good, that still works but do I still need that partition when I 
create an EFI System Partition (ESP) to boot using UEFI?


A separate /boot is required only if GRUB cannot read the root 
filesystem. Possible reasons include :

- root device not supported by the firmware
- root filesystem type not supported by GRUB
- root device type not supported by GRUB (e.g. RAID linear, maybe some 
LVM volume types)

- encrypted root device


If I had not created that /boot partition would those files be in /boot folder 
on the / (root) partition or would /boot then be on the EFI partition?


On the root partition. Some new boot specification mounts the EFI 
partition on /boot but Debian does not follow it (yet) and still mounts 
the EFI partition on /boot/efi.



Do I still need that /boot partition now that the ESP has the boot flag set?


The EFI partition has no boot flag. If you are using parted or Gparted, 
the boot flag is only a virtual representation of the EFI partition type.



Do I still want it?


You may still want a separate plain /boot partition for safety when the 
root uses some complex setup such as LVM even though it is supported by 
GRUB.

Re: UEFI Secure Boot lockdown effects (Was: Installation suitability for Dell laptop)

[Étienne Mollier]

Didier Gaumet, on 2019-09-17:
> Le mardi 17 septembre 2019 22:00:05 UTC+2, Étienne Mollier a écrit :
> [...]
> > I am seriously considering sticking to UEFI
> > Secure Boot, not exactly for security, mostly to have a general
> > idea of how things work, by practice.
> [...]
>
> I have not tested it myself (only KVM/Ovmf but without
> SecureBoot) but in case it could of interest to you, apparently
> one can simulate a SecureBoot environment in KVM/Qemu with Ovmf,
> albeit the beast does not react entirely like the real thing:
>  https://github.com/puiterwijk/qemu-ovmf-secureboot
>  http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt

Thanks, that should be a nice addition to my todo list.
Kind Regards,  :)
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d



signature.asc
Description: OpenPGP digital signature

Re: UEFI Secure Boot lockdown effects (Was: Installation suitability for Dell laptop)

[didier . gaumet]

Le mardi 17 septembre 2019 22:00:05 UTC+2, Étienne Mollier a écrit :
[...]
> I am seriously considering sticking to UEFI
> Secure Boot, not exactly for security, mostly to have a general
> idea of how things work, by practice.
[...]

I have not tested it myself (only KVM/Ovmf but without SecureBoot) but in case 
it could of interest to you, apparently one can simulate a SecureBoot 
environment in KVM/Qemu with Ovmf, albeit the beast does not react entirely 
like the real thing:
 https://github.com/puiterwijk/qemu-ovmf-secureboot
 http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt

Re: UEFI beginner questions

[duh]

OOPS I apparently replied directly to tuulen. I am now trying to copy
that reply to the list. Sorry for

the confusion.

===

[OOOPS! I am replying to you directly and not to the list. At this point
I will try to send a second copy

to the list so you might end up with two copies. DUH!!!]


No promises but a thought.

You might look at rEFInd.

The danger in a suggestion like this is if it does not work out for you
in your particular situation, you may have wasted a lot of time.

On the other hand, even if that is the case you might learn stuff but
based on how you described you original problem, you just

want to get to a usable system. (I happen to favor keeping it simple and
just get it to work).

On the plus side (you can call this anecdotal if you want to downplay
the value of the suggestion to use rEFInd or if you like the idea

you can refer to my suggestion as the result of a case study -- my
limited but successful use of rEFInd when I was very frustrated

by the EFI/UEFI interface of an un-named computer manfacturer whose name
has an uncanny resembelance to the name you

mentioned in your post, but maybe it was just me being a bit dense or
worse in understanding what was needed.

Anyways, a URL that might get your foot in the door is:

    http://www.rodsbooks.com/refind/

FWIW, rEFInd is also mentioned on Wikipedia. The URL for that is:

    https://en.wikipedia.org/wiki/REFInd

The official website makes it clear that donations are appreciated but
that is not a requirement as I understand it.

Good luck. Let us know if you decide to explore this possibility or if
going down this path is to much of

a distraction of what seems to be your objective to simply can Linux
running on -- what was that brand name again? --

computer.





==
On 06/07/2019 10:46 PM, tuulen wrote:

Hi,
I am an ordinary GUI and mouse computer user, not a command line
user.  But I want to get away from both Apple and Microsoft.  I spent
a lot of time looking into Linux, Unix, BSD, and eventually I
discovered Debian.  And because I like to know the details of what I
am doing I also discovered that I just naturally like Debian, too, as
Debian is built upon explanations, fine with me!

I was in the process of partitioning my hard drive to install Debian
when I encountered a couple of UEFI complications.  My HP Laptop with
Windows 10 does not offer a way to disable the "secure boot" feature
of UEFI, so that makes Debian off limits.  Then I went to the HP
website but almost all of the available HP desktops and laptops have
Windows 10, with presumably the same useless UEFI that I now have, and
I did not see any Linux-compatible HP computers as available.  I am
aware that there are other computer makers and manufacturers but I am
wondering what computers the Debian community prefers.  Fortunately my
needs are small bandwidth-wise, no gaming, no movies, nothing bigger
than an occasional news clip or YouTube clip, so I do not need a big,
powerful computer.  I can continue to use Apple and Microsoft
computers for ordinary day-to-day uses but there are some uses, like
banking and financial matters including credit card use, etc., for
which I would very much appreciate a more secure computer and for
different reasons I have come to distrust both Apple and Microsoft. 
OK, so there is a steep learning curve to using Debian, but I think I
can handle learning how to do what I need to do. Any computer model
suggestions?
Thanks!  Best regards, Doug

Re: UEFI beginner questions

[Joe]

On Fri, 7 Jun 2019 22:46:02 -0400
tuulen  wrote:

> Hi,
> I am an ordinary GUI and mouse computer user, not a command line
> user.  But I want to get away from both Apple and Microsoft.  I spent
> a lot of time looking into Linux, Unix, BSD, and eventually I
> discovered Debian.  And because I like to know the details of what I
> am doing I also discovered that I just naturally like Debian, too, as
> Debian is built upon explanations, fine with me!
> 
> I was in the process of partitioning my hard drive to install Debian
> when I encountered a couple of UEFI complications.  My HP Laptop with
> Windows 10 does not offer a way to disable the "secure boot" feature
> of UEFI, so that makes Debian off limits.  Then I went to the HP
> website but almost all of the available HP desktops and laptops have
> Windows 10, with presumably the same useless UEFI that I now have,
> and I did not see any Linux-compatible HP computers as available.

I bought an Acer netbook about eight months ago, with Win10 installed.
It is UEFI only, no legacy boot. The standard Debian stable netinstall
image booted fine, and installed a dual boot system alongside Win10. The
current Debian stable can use UEFI. I saw no reference to secure boot,
though I've no doubt it will be enforced in another year or two.

-- 
Joe

Re: UEFI beginner questions

[Pascal Hambourg]

Le 08/06/2019 à 04:46, tuulen a écrit :


I was in the process of partitioning my hard drive to install Debian when I
encountered a couple of UEFI complications.  My HP Laptop with Windows 10
does not offer a way to disable the "secure boot" feature of UEFI, so that
makes Debian off limits.


I am surprised that the firmware does not offer a way to disable secure 
boot (sometimes the procedure is rather tedious). This means that legacy 
boot is not supported either.


Note that Buster, the next Debian version which is expected to be 
released soon, supports UEFI secure boot.

Re: UEFI beginner questions

[Felix Miata]

tuulen composed on 2019-06-07 22:46 (UTC-0400):

> Any computer model suggestions? 

"Model" has a peculiar mix of meanings among PC manufacturers and users. The 
major
brands seem to like confusing users by providing multiple submodels of the same
model and calling the submodels models. The submodels number in the thousands.

So, along the same line as David Christensen's response, I suggest any x86
compatible PC capable of supporting at least 4GB of RAM, and which was designed 
at
least one year before release of the Debian version you intend to use should be
adequate to task. I find the motherboard chipset and the gfxchip tend to be far
more important than the brand of CPU or manufacturer. Make sure your PC has a
chipset from AMD or Intel, and a gfxchip from Intel, AMD/ATI or NVidia, and you
should be good. NVidia gfxchips tend to be capable of better performance at cost
of being more finicky. DDX drivers for its hardware are made primarily by 
reverse
engineering. If you wish to stick with FOSS from Debian, avoiding proprietary
software from NVidia, then best to stick with AMD/ATI or Intel for video.

I use mostly Intel CPUs. Those I have that are not are 12 or more years old. 
GPUs
I use are mostly from all three major brands. Drivers for others apparently 
don't
get much developer testing, so if available at all, tend to be less reliable
and/or flexible for use with modern widescreen displays.

UEFI BIOS are somewhat like people - each seems to be unique, and some are
friendlier than others. The older ones were less mature, so tend to be more
aggravating than more recent ones. I own 3 motherboards with UEFI BIOS. Only on 
my
two newer ones (2-3 years old) do I use UEFI. On the first, I simply wasn't 
ready
to tackle learning the new stuff.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: UEFI beginner questions

[David Christensen]

On 6/7/19 7:46 PM, tuulen wrote:

Hi,
I am an ordinary GUI and mouse computer user, not a command line user.  But
I want to get away from both Apple and Microsoft.  I spent a lot of time
looking into Linux, Unix, BSD, and eventually I discovered Debian.  And
because I like to know the details of what I am doing I also discovered
that I just naturally like Debian, too, as Debian is built upon
explanations, fine with me!


What "explanations" you are referring to?


I often find FOSS online documents to be outdated, incomplete, and 
inaccurate.  And, there is a huge pile of conflicting information called 
the WWW...



Back in the day, there was:

https://www.pearson.com/us/higher-education/program/Bach-Design-of-the-UNIX-Operating-System/PGM81513.html


FreeBSD has a current equivalent:

https://www.pearson.com/us/higher-education/program/Mc-Kusick-Design-and-Implementation-of-the-Free-BSD-Operating-System-The-2nd-Edition/PGM224032.html


A current "hands-on" book that includes coverage for Debian is:

https://www.pearson.com/us/higher-education/program/Nemeth-UNIX-and-Linux-System-Administration-Handbook-5th-Edition/PGM143215.html


Lucas writes excellent "hands-on" books for BSD and other Unix topics:

https://mwl.io/nonfiction/os

https://mwl.io/nonfiction/networking

https://mwl.io/nonfiction/tools



I was in the process of partitioning my hard drive to install Debian when I
encountered a couple of UEFI complications.  My HP Laptop with Windows 10
does not offer a way to disable the "secure boot" feature of UEFI, so that
makes Debian off limits.  Then I went to the HP website but almost all of
the available HP desktops and laptops have Windows 10, with presumably the
same useless UEFI that I now have, and I did not see any Linux-compatible
HP computers as available.  I am aware that there are other computer makers
and manufacturers but I am wondering what computers the Debian community
prefers. 


Typically, whatever people already own.


Determining if a given make and model of computer is fully supported by 
Debian from specifications, surfing the WWW, etc., is tough.  If a 
physical specimen is available, one option is to try a Debian Live CD or 
USB flash drive.



If you buy a commercial product that comes with Debian pre-installed, it 
should work:


https://www.debian.org/distrib/pre-installed



Fortunately my needs are small bandwidth-wise, no gaming, no
movies, nothing bigger than an occasional news clip or YouTube clip, so I
do not need a big, powerful computer. 


My oldest running machines have Intel 2+ GHz dual-core 64-bit processors 
and 945G chipsets, and are comfortable with video up to 720x480, maybe 
720p.  I use my Intel i7-2600S/ Q67 machine for 1080p.




I can continue to use Apple and
Microsoft computers for ordinary day-to-day uses but there are some uses,
like banking and financial matters including credit card use, etc., 


My retired Pentium 4 machines with 32-bit Debian, Xfce, and Firefox 
could do that.  I recycled my Pentium III and older machines because of 
RAM limitations.




for
which I would very much appreciate a more secure computer and for different
reasons I have come to distrust both Apple and Microsoft. 


I believe desktop security is primarily determined by user behavior. 
Exploits exist for Windows, macOS, and GNU/Linux, and the many common 
applications that run on those platforms.  An ignorant or reckless user 
will be quickly "pwn3d" no matter what computer they use.




OK, so there is
a steep learning curve to using Debian, but I think I can handle learning
how to do what I need to do. 


I suggest starting with this book:

http://shop.oreilly.com/product/9780596002619.do



Any computer model suggestions?


Install Debian Stable (Stretch) into a 64-bit virtual machine on your 
Windows 10 laptop.



Get the debian-9.9.0-amd64-xfce-CD-1.iso download:

https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/


I have used VirtualBox on Windows, macOS, and Debian:

https://www.virtualbox.org/


Some editions of Windows 10 will run Hyper-V on supported platforms:

https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/hyper-v-technology-overview

https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v


If you want real hardware, most of us started with used desktop 
computers.  In this case, older is often better (3+ years or older), as 
the newest hardware often is not supported by Debian Stable.  You will 
want to write your ISO to a USB flash drive:


https://www.debian.org/releases/stable/amd64/ch04s03.html.en#usb-copy-isohybrid

https://sourceforge.net/projects/win32diskimager/



Thanks!  Best regards, Doug


Enjoy!

David

Re: UEFI beginner questions

[deloptes]

tuulen wrote:

> Hi,
> I am an ordinary GUI and mouse computer user, not a command line user. 
> But I want to get away from both Apple and Microsoft.  I spent a lot of
> time looking into Linux, Unix, BSD, and eventually I discovered Debian. 
> And because I like to know the details of what I am doing I also
> discovered that I just naturally like Debian, too, as Debian is built upon
> explanations, fine with me!
> 

Welcome to the community! I really hope you will enjoy it. I came across
Debian in 2002 and also fell in love with it.

> I was in the process of partitioning my hard drive to install Debian when
> I encountered a couple of UEFI complications.  My HP Laptop with Windows
> 10 does not offer a way to disable the "secure boot" feature of UEFI, so
> that makes Debian off limits.  Then I went to the HP website but almost
> all of the available HP desktops and laptops have Windows 10, with
> presumably the same useless UEFI that I now have, and I did not see any
> Linux-compatible HP computers as available.  I am aware that there are
> other computer makers and manufacturers but I am wondering what computers
> the Debian community prefers.  Fortunately my needs are small
> bandwidth-wise, no gaming, no movies, nothing bigger than an occasional
> news clip or YouTube clip, so I do not need a big, powerful computer.  I
> can continue to use Apple and Microsoft computers for ordinary day-to-day
> uses but there are some uses, like banking and financial matters including
> credit card use, etc., for which I would very much appreciate a more
> secure computer and for different reasons I have come to distrust both
> Apple and Microsoft.  OK, so there is a steep learning curve to using
> Debian, but I think I can handle learning how to do what I need to do. 
> Any computer model suggestions? Thanks!  Best regards, Doug

I have two HP notebooks one with Win7 and one with Win10. I am not sure
about the Win10, if I booted Debian on it, but I think yes. Most of them
support LEGACY BOOT - this will automatically disable the secure boot. If
your does not it will be interesting to know what model you have (as David
mentioned).

As of machine recommendations: https://wiki.debian.org/Hardware
I've been using the business class notebooks and desktops from Dell, Fujitsu
and HP, also some industrial boards and last but not least the legendary
Nokia N9.

Next thing would be to choose the proper Desktop I guess :)

regards

Re: UEFI beginner questions

[David]

On Sat, 8 Jun 2019 at 13:03, tuulen  wrote:
>
> My HP Laptop with Windows 10 does not offer a way to disable the "secure 
> boot" feature of UEFI

Hi, more information from you might produce more useful replies :)

If you state the specific model of your laptop and BIOS version, it
would create a possibility that someone could assist you further to
install Debian.

And what is your goal for that laptop? Do you hope for a boot-manager
that allows you to boot either Windows 10 or Debian off different
partitions on the same hard disk drive? Or something different? Do you
need secure boot? Do you need UEFI boot? What options does the BIOS
offer?

Re: UEFI beginner questions

[Peter Ehlert]

HP works, I have 5 HP machines at this time, all running Debian.
"secure boot" does not exist on any of them.
I do Not use UEFI, only Legacy Boot.
Never figured it out or saw an urgent need to use it.
BIOS/UEFI menus are all different, even on similar models and makes.

there are a number of articles on UEFI and boot loaders in the Debian Wiki.

On 6/7/19 7:46 PM, tuulen wrote:

Hi,
I am an ordinary GUI and mouse computer user, not a command line 
user.  But I want to get away from both Apple and Microsoft.  I spent 
a lot of time looking into Linux, Unix, BSD, and eventually I 
discovered Debian.  And because I like to know the details of what I 
am doing I also discovered that I just naturally like Debian, too, as 
Debian is built upon explanations, fine with me!


I was in the process of partitioning my hard drive to install Debian 
when I encountered a couple of UEFI complications.  My HP Laptop with 
Windows 10 does not offer a way to disable the "secure boot" feature 
of UEFI, so that makes Debian off limits.  Then I went to the HP 
website but almost all of the available HP desktops and laptops have 
Windows 10, with presumably the same useless UEFI that I now have, and 
I did not see any Linux-compatible HP computers as available.  I am 
aware that there are other computer makers and manufacturers but I am 
wondering what computers the Debian community prefers.  Fortunately my 
needs are small bandwidth-wise, no gaming, no movies, nothing bigger 
than an occasional news clip or YouTube clip, so I do not need a big, 
powerful computer.  I can continue to use Apple and Microsoft 
computers for ordinary day-to-day uses but there are some uses, like 
banking and financial matters including credit card use, etc., for 
which I would very much appreciate a more secure computer and for 
different reasons I have come to distrust both Apple and Microsoft.  
OK, so there is a steep learning curve to using Debian, but I think I 
can handle learning how to do what I need to do. Any computer model 
suggestions?

Thanks!  Best regards, Doug

Re: UEFI/"BIOS" booting

[David Wright]

On Wed 16 May 2018 at 00:23:43 (+0200), Pascal Hambourg wrote:
> Le 15/05/2018 à 03:37, David Wright a écrit :
> >
> >>But GRUB is not the only available bootloader.
> >
> >No.
> >
> >It's difficult to divine which bootloaders the author is familiar with.
> >My own experience of the last twenty years is limited to Lilo and Grub.
> 
> Same here. I would not trust LILO any more now because it uses
> hardcoded blocklists to read files, just like GRUB does when
> embedding is not possible, which is considered unreliable.
> 
> >I remember reading about coreboot some years ago, but I doubt I'm ever
> >going to meet it. Are you suggesting others?
> 
> AFAIK, Coreboot is a replacement for platform firmware (BIOS),

Yes, that interested me because at the time I had a lot of
(unpowerful) PCs dotted around, some relatively inaccessible.
One of the attractions of coreboot was not having to sit in
front of each machine editing CMOS screens. But AIUI it was
designed for farms of the sort of PCs that were out of my league.

> not an installable boot loader.

I read somewhere that it could directly load linux instead of,
say, Grub, but I don't know anything about the technicalities.

> I have never used it, but it seems that syslinux supports GPT and EFI.

I haven't knowingly used that since I had PCs that booted into
DOS first, back in the last millennium.

> Also I have read positive reports about rEFInd for EFI boot.

One for the future, when I get my very own machine that's UEFI. At
the moment my newest PCs are a 2008 BIOS laptop and a couple of 2006
desktops. The latter boot GPT disks fine. The laptop will have to live
out the rest of its days configured as is, running jessie and wheezy;
too much of it is broken for anything else to be installed.

Cheers,
David.

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[David Wright]

On Wed 16 May 2018 at 00:35:33 (+0200), Pascal Hambourg wrote:
> Le 15/05/2018 à 03:23, David Wright a écrit :
> >
> >In this particular instance (the Lenovo), its PDF says:
> (...)
> > The default boot mode for your computer is UEFI mode. If you need to
> > install a legacy operating system, such as Windows (that is, any 
> > operating
> > system before Windows 8)
> 
> This is so wrong. Windows has supported EFI since Vista.

I offer no defence of what Lenovo choose to write. What I do know is
that in order to make this laptop available to myself, I had to be
able to install linux without disturbing the Windows/GPT/UEFI setup
already present.

Reading the page at
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
would have been most discouraging, so I'm glad I didn't chance upon
it and, in the light of my experience, I consider some of *it* to be
garbage, a word it's happy to use to condemn 95% of what's written
about UEFI elsewhere on the internet.

But then, I also chose to ignore what's written in the Debian
Installation Guide §3.6.3:
"Booting from a disk with GPT is only possible in native UEFI mode".

> >AIUI what's unspecified is what you choose to put in the code section
> >of the MBR. In my case, and probably for most people here, it will be
> >Stage 1 of Grub.
> 
> Note : "stage 1" is a GRUB legacy thing. GRUB 2 calls it "boot image".

I wasn't aware that the "Stage 1" name was eliminated. I don't find
"boot image" adding any clarity to the process. Anyway, someone needs
to tell https://en.wikipedia.org/wiki/GNU_GRUB which says:

  Version 2 (GRUB)
Stage 1: boot.img is stored in the master boot record (MBR) or
optionally in any of the volume boot records (VBRs), and addresses
the next stage by an LBA48 address (thus, the 1024-cylinder
limitation of GRUB legacy is avoided); at installation time it is
configured to load the first sector of core.img.

> >And if one has any sense, that will be pointing to a
> >BIOS boot partition, which is one of the first things I set up on a
> >GPT disk so that I can use it in my old BIOS machines. It makes things
> >far more bullet-proof if Grub knows there's a safe place to put its
> >later Stages. I suspect that systems without ones are likely to be the
> >ones causes much of the reported trouble.
> 
> Moreover, GRUB BIOS cannot be installed without embedding (in a BIOS
> boot partition or any other suitable location) when the /boot
> filesystem is anywhere else than a plain partition (LVM, RAID,
> crypto...) or a filesystem type which may move block around such as
> btrfs, defeating the hardcoded blocklists.

Agreed: that's why I'm making sure I add a BIOS boot partition to
any disk I convert from MBR to GPT, allowing it to be a candidate
for booting from.

Cheers,
David.

Re: UEFI/"BIOS" booting

[Thomas Schmitt]

Hi,

i wrote:
> > - Compromise is to set the boot flag on a dummy partition of type 0x00.
> >    This is barely UEFI-compliant because the specs say that a partition of
> >    type 0x00 shall be regarded as non-existent.

Pascal Hambourg wrote:
> - I had to use the old fdisk version from Wheezy because newer versions and
> other partition editors would not allow to set the boot flag on an empty
> partition entry.

You never know what kind of user-friendly abstraction a partition editor will
apply. So portable and future-safe is only the manipulation on byte level.

The layout of the MBR partition table can be learned from
  https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout
  "Structure of a classical generic MBR" 
  https://en.wikipedia.org/wiki/Master_boot_record#Partition_table_entries

Partition entries are 16 bytes of size and number 1 begins at offset 446.
The boot/active flag sits in the first byte of the partition entry.
The value of this byte is either 0 or 128 (= 0x80 in hex). We want 128.
Further we need to write values for partition start and size.

  # Choose target disk or image file
  disk=/dev/sdX

  # Make a backup of your MBR by
  backup_path="$HOME"/mbr_backup_of_"$(basename "$disk")"
  dd if="$disk" bs=512 count=1 conv=notrunc of="$backup_path"

  # Restore the backup to $disk would be done like this:
  #   dd if="$backup_path" bs=512 count=1 conv=notrunc of="$disk"
  # If $disk is the system disk: Have a rescue system ready which can
  # access the backup file and the system disk.

  # Choose partition and compute start of its entry
  partno=2
  offset=$(expr 430 + "$partno" '*' 16)

  # First set the partition entry to all zeros. So we can just hop over
  # those bytes which shall stay 0. This spares us the plight to handle
  # 0-bytes by shell commands.
  dd if=/dev/zero bs=1 count=16 conv=notrunc seek="$offset" of="$disk"

  # The boot/active flag
  # (The gesture $'\xHH' is described in man bash section QUOTING.)
  echo -n $'\x80' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

  # Start C/H/S = 0/0/1
  offset=$(expr "$offset" + 2)
  echo -n $'\x01' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

  # End C/H/S = 0/0/1
  offset=$(expr "$offset" + 4)
  echo -n $'\x01' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

  # Sector count = 1 (start LBA is 0)
  offset=$(expr "$offset" + 6)
  echo -n $'\x01' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

The task would also be a good execercise for Programmer's First C Program.


Have a nice day :)

Thomas

Re: UEFI/"BIOS" booting

[Pascal Hambourg]

Le 16/05/2018 à 00:10, Pascal Hambourg a écrit :

Le 15/05/2018 à 08:51, Thomas Schmitt a écrit :


Summary:
- Boot flag on MBR partition of type 0xEE is bad on several EFI
   implementations.
- No MBR partition with boot flag is bad on some very few BIOS
   implementations.


Not so few in my experience.


- Compromise is to set the boot flag on a dummy partition of type 0x00.
   This is barely UEFI-compliant because the specs say that a 
partition of

   type 0x00 shall be regarded as non-existent.


I never thought about this. It may be a workaround with my old UEFI 
motherboard. Thanks for the tip, I will try it and report.


The trick indeed worked with my old motherboard ! Good to know, thanks.

However there are some caveats :
- I had to use the old fdisk version from Wheezy because newer versions 
and other partition editors would not allow to set the boot flag on an 
empty partition entry.
- parted silently erased the flag when I used it to edit the GPT table. 
I expected it, because parted had already reset a hybrid MBR I had set 
up with gdisk to a standard protective MBR.

Re: UEFI/"BIOS" booting

[mess-mate]

On 16-May-18 00:23, Pascal Hambourg wrote:

Le 15/05/2018 à 03:37, David Wright a écrit :



But GRUB is not the only available bootloader.


No.

It's difficult to divine which bootloaders the author is familiar with.
My own experience of the last twenty years is limited to Lilo and Grub.


Same here. I would not trust LILO any more now because it uses 
hardcoded blocklists to read files, just like GRUB does when embedding 
is not possible, which is considered unreliable.



I remember reading about coreboot some years ago, but I doubt I'm ever
going to meet it. Are you suggesting others?


AFAIK, Coreboot is a replacement for platform firmware (BIOS), not an 
installable boot loader.


I have never used it, but it seems that syslinux supports GPT and EFI.
Also I have read positive reports about rEFInd for EFI boot.


Your're right.
I've installed windows 10first a mont ago, after that last debian and 
rEFIND.

All run smootless without any problem and at the first install.
Of course, partitions on GPT and UEFI.

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[Pascal Hambourg]

Le 15/05/2018 à 03:23, David Wright a écrit :


In this particular instance (the Lenovo), its PDF says:

(...)

 The default boot mode for your computer is UEFI mode. If you need to
 install a legacy operating system, such as Windows (that is, any operating
 system before Windows 8)


This is so wrong. Windows has supported EFI since Vista.


AIUI what's unspecified is what you choose to put in the code section
of the MBR. In my case, and probably for most people here, it will be
Stage 1 of Grub.


Note : "stage 1" is a GRUB legacy thing. GRUB 2 calls it "boot image".


And if one has any sense, that will be pointing to a
BIOS boot partition, which is one of the first things I set up on a
GPT disk so that I can use it in my old BIOS machines. It makes things
far more bullet-proof if Grub knows there's a safe place to put its
later Stages. I suspect that systems without ones are likely to be the
ones causes much of the reported trouble.


Moreover, GRUB BIOS cannot be installed without embedding (in a BIOS 
boot partition or any other suitable location) when the /boot filesystem 
is anywhere else than a plain partition (LVM, RAID, crypto...) or a 
filesystem type which may move block around such as btrfs, defeating the 
hardcoded blocklists.

Re: UEFI/"BIOS" booting

[Pascal Hambourg]

Le 15/05/2018 à 03:37, David Wright a écrit :



But GRUB is not the only available bootloader.


No.

It's difficult to divine which bootloaders the author is familiar with.
My own experience of the last twenty years is limited to Lilo and Grub.


Same here. I would not trust LILO any more now because it uses hardcoded 
blocklists to read files, just like GRUB does when embedding is not 
possible, which is considered unreliable.



I remember reading about coreboot some years ago, but I doubt I'm ever
going to meet it. Are you suggesting others?


AFAIK, Coreboot is a replacement for platform firmware (BIOS), not an 
installable boot loader.


I have never used it, but it seems that syslinux supports GPT and EFI.
Also I have read positive reports about rEFInd for EFI boot.

Re: UEFI/"BIOS" booting

[Pascal Hambourg]

Le 15/05/2018 à 08:51, Thomas Schmitt a écrit :


Summary:
- Boot flag on MBR partition of type 0xEE is bad on several EFI
   implementations.
- No MBR partition with boot flag is bad on some very few BIOS
   implementations.


Not so few in my experience.


- Compromise is to set the boot flag on a dummy partition of type 0x00.
   This is barely UEFI-compliant because the specs say that a partition of
   type 0x00 shall be regarded as non-existent.


I never thought about this. It may be a workaround with my old UEFI 
motherboard. Thanks for the tip, I will try it and report.

Re: UEFI/"BIOS" booting

[Thomas Schmitt]

Hi,

i wrote:
> > And as said previously, BIOS does not expect any partitions.

Pascal Hambourg wrote:
> experience taught me that many BIOS implementations wrongly
> expect an MBR partition entry with the boot flag set in order to boot from
> the disk.

You are right (and those firmwares are wrong).

I had to introduce a special option in xorriso in order to cater for this:
  https://savannah.gnu.org/bugs/?46716
  http://lists.gnu.org/archive/html/bug-xorriso/2015-12/threads.html
with the final conclusion described in
  https://lists.gnu.org/archive/html/bug-grub/2016-03/msg00087.html

Summary:
- Boot flag on MBR partition of type 0xEE is bad on several EFI
  implementations.
- No MBR partition with boot flag is bad on some very few BIOS
  implementations.
- Compromise is to set the boot flag on a dummy partition of type 0x00.
  This is barely UEFI-compliant because the specs say that a partition of
  type 0x00 shall be regarded as non-existent.

Debian isohybrids for BIOS do not have this problem because MBR partition 1
has the boot flag set, anyway. But grub-mkrescue ISOs might be in need of
xorrisofs option
  --mbr-force-bootable
if the owner suffers from one of those rare BIOSes.
(It was decided that from the view of GRUB this is a workaround for a
 specs violation by the firmware. iSo --mbr-force-bootable is not applied
 by default.)


Have a nice day :)

Thomas

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[David Wright]

On Mon 14 May 2018 at 23:29:43 (+0200), Pascal Hambourg wrote:
> Le 14/05/2018 à 02:02, David Wright a écrit :
> >On Sun 13 May 2018 at 19:08:48 (+0200), Pascal Hambourg wrote:
> >>
> >>Most of my early experience with UEFI boot comes from a rather old
> >>Intel motherboard. Beside crippled UEFI support (no UEFI boot from
> >>USB or SATA in AHCI mode), it had a couple of annoying requirements :
> >>- boot in legacy mode only if the MBR contains a partition entry
> >>with the boot flag set, regardless of whether the disk has a MSDOS
> >>or GPT partition table. This behaviour is beyond any common BIOS
> >>standard, but I have observed it on many other systems, mostly Dell
> >>and HP ;
> >
> >In the case of GPT, I assume the partition entry with the boot flag set
> >is the protective MBR.
> 
> Yes, as the protective GPT partition entry is the only non-empty entry.
> 
> >>- boot in EFI mode from GPT only if the protective partition entry
> >>in the MBR has the boot flag unset. I admit this requirement is part
> >>of the GPT specification, but really do not see the point in
> >>enforcing such a minor detail.
> >>
> >>Anyway, these two requirements put together make it impossible to
> >>boot in both legacy and EFI mode from the same GPT disk with this
> >>motherboard. However they allow to boot in both modes from the same
> >>MSDOS disk. But who still wants to use MSDOS format nowadays ?
> >
> >Is it impossible, then, to change the boot flag in a protective MBR?
> 
> Of cours not, but it is even less convenient than switching the boot
> mode in the firmware setup : boot the system, switch the boot flag,
> reboot the system...

Sorry, I thought impossible meant not possible. I agree that booting
up a system (that happens to be set to the wrong state) just to change
the boot flag and then reboot is a lot less convenient than the
process I use (which always lets you boot into the correct system
first time, and only requires action when you want to change over).

But the fact that you've experienced a crippled mobo does not IMHO
mean that some of the scenarios you could use on less crippled systems
shouldn't be discussed—nay, be treated as near impossible—in a web
page that's meant to be throwing light on the matter. As written, the
author just pours special magic sauce around, whatever that is.

Cheers,
David.

Re: UEFI/"BIOS" booting

[David Wright]

On Mon 14 May 2018 at 23:39:06 (+0200), Pascal Hambourg wrote:
> Le 14/05/2018 à 16:33, David Wright a écrit :
> >
> > "Don’t do UEFI-native installs to MBR-formatted disks, or BIOS
> > compatibility installs to GPT-formatted disks (an exception to the
> > latter is if your disk is, IIRC, 2.2+TB in size, because the MBR
> > format can’t handle disks that big – if you want to do a BIOS
> > compatibility install to a disk that big, you’re kinda stuck with
> > the BIOS+GPT combination, which works but is a bit wonky and
> > involves the infamous ‘BIOS Boot partition’ you may recall from
> > Fedora 17).
> >
> >I haven't been able to find anything infamous about the BIOS Boot
> >partition but it sounds as if the author had a bad experience at
> >sometime in the past which has affected their ability to view the
> >topic objectively.
> 
> AFAICS the BIOS boot partition is a rather widely unknown topic.

I'm happy to publicise it a little, then, and without using terms
like infamous and wonky.

> Actually a BIOS boot partition is not required for BIOS boot on GPT.
> It is only recommended or required in order to install GRUB in some
> situations. But GRUB is not the only available bootloader.

No.

It's difficult to divine which bootloaders the author is familiar with.
My own experience of the last twenty years is limited to Lilo and Grub.
I remember reading about coreboot some years ago, but I doubt I'm ever
going to meet it. Are you suggesting others?

Cheers,
David.

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[David Wright]

On Mon 14 May 2018 at 11:56:11 (-0400), Stefan Monnier wrote:
> > Yes, documentation of firmware is almost unknown in my experience
> > (since probably 30 years ago). That's why I took the least invasive
> 
> It's documented to the extent that it says "implements UEFI" and that
> UEFI is documented.

I can only speak for machines that I have access to. The earliest PCs
I remember came with booklets that had illustrations of the various
CMOS screens. Since then, I've usually had to transcribe the settings
manually into files that I archive (in case of battery failure etc.)

In this particular instance (the Lenovo), its PDF says:

  How can I change the boot mode?
There are two boot modes: UEFI and Legacy Support. To change the boot
mode, start the BIOS setup utility and set boot mode to UEFI or Legacy
support on the boot menu.

and that's it, apart from implying that the Legacy mode is useful:

  When do I need to change the boot mode?
The default boot mode for your computer is UEFI mode. If you need to
install a legacy operating system, such as Windows (that is, any operating
system before Windows 8), Linux or DOS, etc on your computer, you must
change the boot mode to Legacy support. The legacy operating system,
such as Windows, Linux or DOS, etc cannot be installed if you don't
change the boot mode.

> >> Same here (basically for the same reason: the behavior of the firmware
> >> and OS when faced with a disk that has both a GPT and an MBR partitions
> >> is largely unspecified and will vary depending on your system).
> > Eh? I've yet to see a GPT disk that didn't have a protective MBR.
> 
> Exactly: what happens when a GPT disk has a real MBR (rather than a
> protective MBR) is "you're on your own".

As Thomas has just pointed out, there's no such thing. I didn't try
to read anything into your non-idiomatic use of the plural in "a disk
that has both a GPT and an MBR partitions". There will be any number
of partitions in the GPT, and just one in the MBR's partition table.

AIUI what's unspecified is what you choose to put in the code section
of the MBR. In my case, and probably for most people here, it will be
Stage 1 of Grub. And if one has any sense, that will be pointing to a
BIOS boot partition, which is one of the first things I set up on a
GPT disk so that I can use it in my old BIOS machines. It makes things
far more bullet-proof if Grub knows there's a safe place to put its
later Stages. I suspect that systems without ones are likely to be the
ones causes much of the reported trouble.

Where's the author's discussion of all this? My beef is that these
aspects are obfuscated with talk of magic code, magic space, magic
locations and "special sauce". That's the kind of stuff I'm placing in
*their* garbage, even if it doesn't make up 95%.

> >> It's easy to reconcile: he doesn't say your setup is impossible or can't
> >> work, he just recommends not to do that because you may encounter
> >> unexpected difficulties.  E.g. in theory an upgrade to your firmware or
> >> to one of your OSes could break it, tho in practice you're probably OK
> >> at least until you move that setup to another machine with
> >> a different firmware.
> > Not sure what you mean here. It's a laptop: nowt's going nowhere.
> 
> Take the disk out, put it in another machine (laptop or desktop, it
> doesn't matter).

At that point, I would assume windows is dead because it's not
licenced for its new home. At which point, a decision could be made
on the basis of whether the new machine could boot Grub through the
MBR. If that's not the case, then obviously one is going to have to
boot with UEFI from, say, a stick and grub-install in UEFI mode.

If that change is made correctly, the disk should be bootable in its new
location. In addition, if it were moved back to its original location,
it should now be possible to boot both windows and linux using EUFI mode.

But these are the issues I have been keen to avoid (successfully)
by booting in different modes for the two OSes. As I stated, there
was to be no disturbance of the windows system.

Cheers,
David.

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[songbird]

Chris Ramsden wrote:
> On 2018-05-14 01:21, songbird wrote:
>> Pascal Hambourg wrote:
>> ...
>>> I agree with the author. If you want to keep the existing EFI Windows 
>>> installation and have a convenient dual boot with GRUB, you'll have to 
>>> set up your favourite distribution to boot in EFI mode. If you want to 
>>> go back to legacy boot, including for Windows, you'll have to 
>>> repartition the disk to MSDOS format and reinstall Windows.
>>   all i know is that if your bios doesn't boot in
>> UEFI mode and you don't know anything about what this
>> means you can end up installing Debian without UEFI
>> support and then it can be rather fun to get it back.
>>
>>   i managed to have grub do an install to a stable
>> partition without UEFI and i messed up the testing
>> setup i had.  it took me some while to figure out
>> what went wrong and how to fix it.  if you don't
>> really understand grub rescue commands and there
>> isn't a working system you can use to connect and
>> find help for the commands you need to enter it's
>> very frustrating.
>>
>>   the Debian UEFI pages helped a great deal but 
>> there were other things i had to figure out coming in
>> cold to UEFI.
>>
>>   how to create a /boot/efi partition, what goes in 
>> it, mounting it, clearing and putting in new efibootmgr 
>> entries, etc.
>>
>>   refind was useful and at least it does what i expect
>> it to do.  grub, i dislike how it assumed things i
>> didn't want to do.  alas, i didn't know how different
>> UEFI was from bios mode.
>>
>>   i still haven't redone my efibootmgr entries but
>> refind doesn't care, i can create custom entries in
>> that config file and they work that is all i really
>> need at this point.
>>
>>
>>   songbird
>>
> Hmm, do you have any useful references?

  https://wiki.debian.org/UEFI
  https://wiki.debian.org/GrubEFIReinstall

  and

  http://www.rodsbooks.com/refind/


> I got a new Dell computer, shrunk the existing partitions down and
> successfully installed grub2 and got a windows10/Linux multi boot using
> grub. Then later I tried to upgrade my Linux and soon found that I was
> getting error messages about grub not being able to find necessary
> features on the boot device.

  yep.  do not install stable after testing is all i
can recommend at this point (based upon my experience)
and of course keep a working/verified netinst image 
handy.


> I tried to rebuild it with a clean install of Windows 10, reasoning that
> if I could get it back to the original configuration, I could repeat the
> original exercise. But alas, no, it remains stubbornly unable to install
> grub2 alongside the windows bootloader. I got it to a state where I
> could use the BIOS POST boot screen to choose a boot option, but this
> wasn't the original successful arrangement where grub offered me the
> Linux/windows loader choice.
>
> I gave up, wiped windows and went through with a clean Linux install. I
> don't really want windows that much, but it irks me that I haven't been
> able to fathom out how to return to the original state in which it was
> shipped. Your words hint at many things I became vaguely aware of but
> totally failed to grasp. The other posters to this thread have at least
> reassured me that it isn't easy or trivial to get right.

  i was rather surprised by it all but i'd been living
in the dark ages for years anyways.


  songbird

Re: UEFI/"BIOS" booting

[Pascal Hambourg]

Le 14/05/2018 à 17:50, Thomas Schmitt a écrit :


And as said previously, BIOS does not expect any partitions.


In theory. All it should expect is the MBR signature 0xAA55. But as said 
previously, experience taught me that many BIOS implementations wrongly 
expect an MBR partition entry with the boot flag set in order to boot 
from the disk.

Re: UEFI/"BIOS" booting

[Pascal Hambourg]

Le 14/05/2018 à 16:33, David Wright a écrit :


 "Don’t do UEFI-native installs to MBR-formatted disks, or BIOS
 compatibility installs to GPT-formatted disks (an exception to the
 latter is if your disk is, IIRC, 2.2+TB in size, because the MBR
 format can’t handle disks that big – if you want to do a BIOS
 compatibility install to a disk that big, you’re kinda stuck with
 the BIOS+GPT combination, which works but is a bit wonky and
 involves the infamous ‘BIOS Boot partition’ you may recall from
 Fedora 17).

I haven't been able to find anything infamous about the BIOS Boot
partition but it sounds as if the author had a bad experience at
sometime in the past which has affected their ability to view the
topic objectively.


AFAICS the BIOS boot partition is a rather widely unknown topic. 
Actually a BIOS boot partition is not required for BIOS boot on GPT. It 
is only recommended or required in order to install GRUB in some 
situations. But GRUB is not the only available bootloader.

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[Pascal Hambourg]

Le 14/05/2018 à 02:02, David Wright a écrit :

On Sun 13 May 2018 at 19:08:48 (+0200), Pascal Hambourg wrote:


Most of my early experience with UEFI boot comes from a rather old
Intel motherboard. Beside crippled UEFI support (no UEFI boot from
USB or SATA in AHCI mode), it had a couple of annoying requirements :
- boot in legacy mode only if the MBR contains a partition entry
with the boot flag set, regardless of whether the disk has a MSDOS
or GPT partition table. This behaviour is beyond any common BIOS
standard, but I have observed it on many other systems, mostly Dell
and HP ;


In the case of GPT, I assume the partition entry with the boot flag set
is the protective MBR.


Yes, as the protective GPT partition entry is the only non-empty entry.


- boot in EFI mode from GPT only if the protective partition entry
in the MBR has the boot flag unset. I admit this requirement is part
of the GPT specification, but really do not see the point in
enforcing such a minor detail.

Anyway, these two requirements put together make it impossible to
boot in both legacy and EFI mode from the same GPT disk with this
motherboard. However they allow to boot in both modes from the same
MSDOS disk. But who still wants to use MSDOS format nowadays ?


Is it impossible, then, to change the boot flag in a protective MBR?


Of cours not, but it is even less convenient than switching the boot 
mode in the firmware setup : boot the system, switch the boot flag, 
reboot the system...

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[Stefan Monnier]

> Yes, documentation of firmware is almost unknown in my experience
> (since probably 30 years ago). That's why I took the least invasive

It's documented to the extent that it says "implements UEFI" and that
UEFI is documented.

>> Same here (basically for the same reason: the behavior of the firmware
>> and OS when faced with a disk that has both a GPT and an MBR partitions
>> is largely unspecified and will vary depending on your system).
> Eh? I've yet to see a GPT disk that didn't have a protective MBR.

Exactly: what happens when a GPT disk has a real MBR (rather than a
protective MBR) is "you're on your own".

>> It's easy to reconcile: he doesn't say your setup is impossible or can't
>> work, he just recommends not to do that because you may encounter
>> unexpected difficulties.  E.g. in theory an upgrade to your firmware or
>> to one of your OSes could break it, tho in practice you're probably OK
>> at least until you move that setup to another machine with
>> a different firmware.
> Not sure what you mean here. It's a laptop: nowt's going nowhere.

Take the disk out, put it in another machine (laptop or desktop, it
doesn't matter).


Stefan

Re: UEFI/"BIOS" booting

[Thomas Schmitt]

Hi,

Stefan Monnier wrote:
> > the behavior of the firmware
> > and OS when faced with a disk that has both a GPT and an MBR partitions
> > is largely unspecified and will vary depending on your system).

David Wright wrote:
> I've yet to see a GPT disk that didn't have a protective MBR.
> I thought that's the reason why GPT starts at block 1 and not
> block 0: an MBR was designed into GPT from the start (no pun intended).

Indeed. The byte format of GPT is specified in UEFI. The Protective MBR is
the magic number of GPT. This implies that one cannot have a valid GPT and
MBR partitions with payload on the same disk.

But the code area of the Protective MBR can well be used to boot via BIOS.
EFI explicitely specifies that these bytes shall be ignored by EFI.
And as said previously, BIOS does not expect any partitions. Such expectation
could be in the MBR code, though. Most probably such code won't work with
GPT because of no bootable/active MBR partition.


Quotes from UEFI 2.4:

  5 GUID Partition Table (GPT) Disk Layout
  [...]

  5.2 LBA 0 Format
  LBA 0 (i.e. the first logical block) of the hard disk contains either
  • a legacy Master Boot Record (MBR) (see Section 5.2.1)
  • or a protective MBR (see Section 5.2.2 [actually 5.2.3]).

  5.2.1 Legacy Master Boot Record (MBR)
  A legacy MBR may be located at LBA 0 (i.e. the first logical block) of
  the disk if it is not using the GPT disk layout (i.e., if it is using
  the MBR disk layout).
  [...]

  5.2.2 OS Types
  Unique types [of MBR partitions] defined by this specification (other
  values are not defined by this specification):
  • 0xEF (i.e., UEFI System Partition) defines a UEFI system partition.
  • 0xEE (i.e., GPT Protective) is used by a protective MBR (see 5.2.2)
to define a fake partition covering the entire disk.

  5.2.3 Protective MBR
  A Protective MBR may be located at LBA 0 (i.e. the first logical block)
  of the disk if it is using the GPT disk layout. The Protective MBR
  precedes the GUID Partition Table Header to maintain compatibility with
  existing tools that do not understand GPT partition structures.

  Table 15. Protective MBR
  Mnemonic | Byte   | Byte   | Content
   | Offset | Length |
  ---
  Boot Code| 0  | 440| Unused by UEFI systems.
  Unique MBR Signature | 440| 4  | Unused. Set to zero.
  Unknown  | 444| 2  | Unused. Set to zero.
  Partition Record | 446| 16*4   | [partition table]
  Signature| 510| 2  | Set to 0xAA55 [...]

The MBR partition table is described in table 15 as
  Array of four MBR partition records. Contains:
  • one partition record as defined Table 16; and
  • three partition records each set to zero.

Table 16 then states

  Protective MBR Partition Record protecting the entire disk
  [...]
  Mnemonic |Byte  |Byte  | Description
   |Offset|Length|
  
  BootIndicator| 0| 1| Set to 0x00 to indicate a non-bootable
   |  |  | partition. [...]
  StartingCHS  | 1| 3| Set to 0x000200 [...]
  OSType   | 4| 1| Set to 0xEE (i.e., GPT Protective)
  EndingCHS| 5| 3| Set to the CHS address of the last logical
   |  |  | block on the disk. Set to 0xFF if it is
   |  |  | not possible to represent the value in this
   |  |  | field.
  StartingLBA  | 8| 4| Set to 0x0001 (i.e., the LBA of the GPT
   |  |  | Partition Header).
  SizeInLBA| 12   | 4| Set to the size of the disk minus one. Set to
   |  |  | 0x if the size of the disk is too
   |  |  | large to be represented in this field.




Have a nice day :)

Thomas

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[Chris Ramsden]

On 2018-05-14 14:55, David Wright wrote:
> Would I be correct in thinking that the BIOS POST boot screen is
> what you get when you hit F12 sufficiently quickly after switch-on?
> So are you choosing between UEFI and Legacy (compatibility) mode.
> (I would like to know how Dell handles what I've been reporting on
> with this Lenovo.)
Yes. F12. Then you get to choose between the various bootable devices
and partitions. But this is BIOS or firmware (not Grub) doing it for you.
>> I gave up, wiped windows and went through with a clean Linux install. I
>> don't really want windows that much, but it irks me that I haven't been
>> able to fathom out how to return to the original state in which it was
>> shipped. Your words hint at many things I became vaguely aware of but
>> totally failed to grasp. The other posters to this thread have at least
>> reassured me that it isn't easy or trivial to get right.
> This is the scenario I was trying to avoid. As far as windows was
> concerned, my mantra was Failure Is Not An Option.
>
> Cheers,
> David.
-- 
Chris

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[David Wright]

On Mon 14 May 2018 at 09:14:23 (-0400), Stefan Monnier wrote:
> > That said, there are other statements that are odd:
> 
> Not sure what you find odd about them:
> 
> > "I really can’t recommend strongly enough that you do not attempt
> > to mix UEFI-native and BIOS-compatible booting of
> > permanently-installed operating systems on the same computer, and
> > especially not on the same disk. It is a terrible terrible idea
> > and will cause you heartache and pain. If you decide to do it,
> > don’t come crying to me." (under "UEFI booting: background").
> 
> Here he's just saying that there's a good chance you'll encounter
> difficulties if you try that, and indeed in my experience the behavior
> of such a config will depend on undocumented details.

Yes, documentation of firmware is almost unknown in my experience
(since probably 30 years ago). That's why I took the least invasive
method that I could. Using a UEFI/UEFI approach means that you have
to explore the manufacturer's undocumented implementation of UEFI.
Plenty of horror stories there, including Pascal's.

> > "Disk formats (MBR vs. GPT)
> >
> >   Here’s another very important consideration:
> >
> >   If you want to do a ‘BIOS compatibility’ type installation, you
> > probably want to install to an MBR formatted disk. If you want to
> > do a UEFI native installation, you probably want to install to a
> > GPT formatted disk."
> 
> Same here (basically for the same reason: the behavior of the firmware
> and OS when faced with a disk that has both a GPT and an MBR partitions
> is largely unspecified and will vary depending on your system).

Eh? I've yet to see a GPT disk that didn't have a protective MBR.
I thought that's the reason why GPT starts at block 1 and not
block 0: an MBR was designed into GPT from the start (no pun intended).

> > I can't reconcile that with the system here, a Windows 8→10 UEFI laptop
> > and GPT disk running linux in BIOS compatibility mode (here called
> > Legacy mode by Lenovo) booting from an MBR on an ATA disk:
> 
> It's easy to reconcile: he doesn't say your setup is impossible or can't
> work, he just recommends not to do that because you may encounter
> unexpected difficulties.  E.g. in theory an upgrade to your firmware or
> to one of your OSes could break it, tho in practice you're probably OK
> at least until you move that setup to another machine with
> a different firmware.

Not sure what you mean here. It's a laptop: nowt's going nowhere.

But in a page as long as this one is, I think the author is rather
dismissive of using Legacy mode at all. Perhaps the clue is here:

"Don’t do UEFI-native installs to MBR-formatted disks, or BIOS
compatibility installs to GPT-formatted disks (an exception to the
latter is if your disk is, IIRC, 2.2+TB in size, because the MBR
format can’t handle disks that big – if you want to do a BIOS
compatibility install to a disk that big, you’re kinda stuck with
the BIOS+GPT combination, which works but is a bit wonky and
involves the infamous ‘BIOS Boot partition’ you may recall from
Fedora 17).

I haven't been able to find anything infamous about the BIOS Boot
partition but it sounds as if the author had a bad experience at
sometime in the past which has affected their ability to view the
topic objectively.

Cheers,
David.

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[David Wright]

On Mon 14 May 2018 at 13:28:56 (+0100), Chris Ramsden wrote:
> On 2018-05-14 01:21, songbird wrote:
> > Pascal Hambourg wrote:
> > ...
> >> I agree with the author. If you want to keep the existing EFI Windows 
> >> installation and have a convenient dual boot with GRUB, you'll have to 
> >> set up your favourite distribution to boot in EFI mode. If you want to 
> >> go back to legacy boot, including for Windows, you'll have to 
> >> repartition the disk to MSDOS format and reinstall Windows.
> >   all i know is that if your bios doesn't boot in
> > UEFI mode and you don't know anything about what this
> > means you can end up installing Debian without UEFI
> > support and then it can be rather fun to get it back.
> >
> >   i managed to have grub do an install to a stable
> > partition without UEFI and i messed up the testing
> > setup i had.  it took me some while to figure out
> > what went wrong and how to fix it.  if you don't
> > really understand grub rescue commands and there
> > isn't a working system you can use to connect and
> > find help for the commands you need to enter it's
> > very frustrating.
> >
> >   the Debian UEFI pages helped a great deal but 
> > there were other things i had to figure out coming in
> > cold to UEFI.
> >
> >   how to create a /boot/efi partition, what goes in 
> > it, mounting it, clearing and putting in new efibootmgr 
> > entries, etc.
> >
> >   refind was useful and at least it does what i expect
> > it to do.  grub, i dislike how it assumed things i
> > didn't want to do.  alas, i didn't know how different
> > UEFI was from bios mode.
> >
> >   i still haven't redone my efibootmgr entries but
> > refind doesn't care, i can create custom entries in
> > that config file and they work that is all i really
> > need at this point.
> >
> >
> >   songbird
> >
> Hmm, do you have any useful references?
> 
> I got a new Dell computer, shrunk the existing partitions down and
> successfully installed grub2 and got a windows10/Linux multi boot using
> grub. Then later I tried to upgrade my Linux and soon found that I was
> getting error messages about grub not being able to find necessary
> features on the boot device.
> 
> I tried to rebuild it with a clean install of Windows 10, reasoning that
> if I could get it back to the original configuration, I could repeat the
> original exercise. But alas, no, it remains stubbornly unable to install
> grub2 alongside the windows bootloader. I got it to a state where I
> could use the BIOS POST boot screen to choose a boot option, but this
> wasn't the original successful arrangement where grub offered me the
> Linux/windows loader choice.

Would I be correct in thinking that the BIOS POST boot screen is
what you get when you hit F12 sufficiently quickly after switch-on?
So are you choosing between UEFI and Legacy (compatibility) mode.
(I would like to know how Dell handles what I've been reporting on
with this Lenovo.)

> I gave up, wiped windows and went through with a clean Linux install. I
> don't really want windows that much, but it irks me that I haven't been
> able to fathom out how to return to the original state in which it was
> shipped. Your words hint at many things I became vaguely aware of but
> totally failed to grasp. The other posters to this thread have at least
> reassured me that it isn't easy or trivial to get right.

This is the scenario I was trying to avoid. As far as windows was
concerned, my mantra was Failure Is Not An Option.

Cheers,
David.

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[Stefan Monnier]

> That said, there are other statements that are odd:

Not sure what you find odd about them:

> "I really can’t recommend strongly enough that you do not attempt
> to mix UEFI-native and BIOS-compatible booting of
> permanently-installed operating systems on the same computer, and
> especially not on the same disk. It is a terrible terrible idea
> and will cause you heartache and pain. If you decide to do it,
> don’t come crying to me." (under "UEFI booting: background").

Here he's just saying that there's a good chance you'll encounter
difficulties if you try that, and indeed in my experience the behavior
of such a config will depend on undocumented details.

> "Disk formats (MBR vs. GPT)
>
>   Here’s another very important consideration:
>
>   If you want to do a ‘BIOS compatibility’ type installation, you
> probably want to install to an MBR formatted disk. If you want to
> do a UEFI native installation, you probably want to install to a
> GPT formatted disk."

Same here (basically for the same reason: the behavior of the firmware
and OS when faced with a disk that has both a GPT and an MBR partitions
is largely unspecified and will vary depending on your system).

> I can't reconcile that with the system here, a Windows 8→10 UEFI laptop
> and GPT disk running linux in BIOS compatibility mode (here called
> Legacy mode by Lenovo) booting from an MBR on an ATA disk:

It's easy to reconcile: he doesn't say your setup is impossible or can't
work, he just recommends not to do that because you may encounter
unexpected difficulties.  E.g. in theory an upgrade to your firmware or
to one of your OSes could break it, tho in practice you're probably OK
at least until you move that setup to another machine with
a different firmware.


Stefan

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[Chris Ramsden]

On 2018-05-14 01:21, songbird wrote:
> Pascal Hambourg wrote:
> ...
>> I agree with the author. If you want to keep the existing EFI Windows 
>> installation and have a convenient dual boot with GRUB, you'll have to 
>> set up your favourite distribution to boot in EFI mode. If you want to 
>> go back to legacy boot, including for Windows, you'll have to 
>> repartition the disk to MSDOS format and reinstall Windows.
>   all i know is that if your bios doesn't boot in
> UEFI mode and you don't know anything about what this
> means you can end up installing Debian without UEFI
> support and then it can be rather fun to get it back.
>
>   i managed to have grub do an install to a stable
> partition without UEFI and i messed up the testing
> setup i had.  it took me some while to figure out
> what went wrong and how to fix it.  if you don't
> really understand grub rescue commands and there
> isn't a working system you can use to connect and
> find help for the commands you need to enter it's
> very frustrating.
>
>   the Debian UEFI pages helped a great deal but 
> there were other things i had to figure out coming in
> cold to UEFI.
>
>   how to create a /boot/efi partition, what goes in 
> it, mounting it, clearing and putting in new efibootmgr 
> entries, etc.
>
>   refind was useful and at least it does what i expect
> it to do.  grub, i dislike how it assumed things i
> didn't want to do.  alas, i didn't know how different
> UEFI was from bios mode.
>
>   i still haven't redone my efibootmgr entries but
> refind doesn't care, i can create custom entries in
> that config file and they work that is all i really
> need at this point.
>
>
>   songbird
>
Hmm, do you have any useful references?

I got a new Dell computer, shrunk the existing partitions down and
successfully installed grub2 and got a windows10/Linux multi boot using
grub. Then later I tried to upgrade my Linux and soon found that I was
getting error messages about grub not being able to find necessary
features on the boot device.

I tried to rebuild it with a clean install of Windows 10, reasoning that
if I could get it back to the original configuration, I could repeat the
original exercise. But alas, no, it remains stubbornly unable to install
grub2 alongside the windows bootloader. I got it to a state where I
could use the BIOS POST boot screen to choose a boot option, but this
wasn't the original successful arrangement where grub offered me the
Linux/windows loader choice.

I gave up, wiped windows and went through with a clean Linux install. I
don't really want windows that much, but it irks me that I haven't been
able to fathom out how to return to the original state in which it was
shipped. Your words hint at many things I became vaguely aware of but
totally failed to grasp. The other posters to this thread have at least
reassured me that it isn't easy or trivial to get right.

-- 
Chris

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[songbird]

Pascal Hambourg wrote:
...
> I agree with the author. If you want to keep the existing EFI Windows 
> installation and have a convenient dual boot with GRUB, you'll have to 
> set up your favourite distribution to boot in EFI mode. If you want to 
> go back to legacy boot, including for Windows, you'll have to 
> repartition the disk to MSDOS format and reinstall Windows.

  all i know is that if your bios doesn't boot in
UEFI mode and you don't know anything about what this
means you can end up installing Debian without UEFI
support and then it can be rather fun to get it back.

  i managed to have grub do an install to a stable
partition without UEFI and i messed up the testing
setup i had.  it took me some while to figure out
what went wrong and how to fix it.  if you don't
really understand grub rescue commands and there
isn't a working system you can use to connect and
find help for the commands you need to enter it's
very frustrating.

  the Debian UEFI pages helped a great deal but 
there were other things i had to figure out coming in
cold to UEFI.

  how to create a /boot/efi partition, what goes in 
it, mounting it, clearing and putting in new efibootmgr 
entries, etc.

  refind was useful and at least it does what i expect
it to do.  grub, i dislike how it assumed things i
didn't want to do.  alas, i didn't know how different
UEFI was from bios mode.

  i still haven't redone my efibootmgr entries but
refind doesn't care, i can create custom entries in
that config file and they work that is all i really
need at this point.


  songbird

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[David Wright]

On Sun 13 May 2018 at 19:08:48 (+0200), Pascal Hambourg wrote:
> Le 13/05/2018 à 17:18, David Wright a écrit :
> >On Fri 11 May 2018 at 15:13:04 (-0500), Kent West wrote:
> >>
> >>That's good to know. I guess my source material (
> >>https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/)
> >>is wrong. Or I misunderstood it.
> >
> >While a lot of the detail on that long page might be correct, there
> >are also statements there that don't seem to agree with reality.
> 
> Most of the statements you quoted agree with my (admittedly limited)
> experience with UEFI. There is a difference between the theory
> (specifications) and the reality (implementations), and some pieces
> of software may have extra requirements beyond the sole UEFI
> specification.
> 
> > "I really can’t recommend strongly enough that you do not attempt
> > to mix UEFI-native and BIOS-compatible booting of
> > permanently-installed operating systems on the same computer, and
> > especially not on the same disk. It is a terrible terrible idea
> > and will cause you heartache and pain. If you decide to do it,
> > don’t come crying to me." (under "UEFI booting: background").
> 
> I would not be as much adamant as the author, but my experience says :
> it can work, but expect trouble.
> 
> Most of my early experience with UEFI boot comes from a rather old
> Intel motherboard. Beside crippled UEFI support (no UEFI boot from
> USB or SATA in AHCI mode), it had a couple of annoying requirements :
> - boot in legacy mode only if the MBR contains a partition entry
> with the boot flag set, regardless of whether the disk has a MSDOS
> or GPT partition table. This behaviour is beyond any common BIOS
> standard, but I have observed it on many other systems, mostly Dell
> and HP ;

In the case of GPT, I assume the partition entry with the boot flag set
is the protective MBR.

> - boot in EFI mode from GPT only if the protective partition entry
> in the MBR has the boot flag unset. I admit this requirement is part
> of the GPT specification, but really do not see the point in
> enforcing such a minor detail.
> 
> Anyway, these two requirements put together make it impossible to
> boot in both legacy and EFI mode from the same GPT disk with this
> motherboard. However they allow to boot in both modes from the same
> MSDOS disk. But who still wants to use MSDOS format nowadays ?

Is it impossible, then, to change the boot flag in a protective MBR?

> > "Disk formats (MBR vs. GPT)
> >
> >   Here’s another very important consideration:
> >
> >   If you want to do a ‘BIOS compatibility’ type installation, you
> > probably want to install to an MBR formatted disk. If you want to
> > do a UEFI native installation, you probably want to install to a
> > GPT formatted disk."
> 
> I do not agree so much with this one when it comes to install
> GNU/Linux. But it is an absolute requirement when installing
> Windows.

Yes, though I assume few people install Windows. It's more likely to
be pre-installed.

> > "A specific example
> >
> > To boil down the above: if you bought a Windows 8 or later system,
> > you almost certainly have a UEFI native install of Windows to a
> > GPT-formatted disk. This means that if you want to install another
> > OS alongside that Windows install, you almost certainly want to do
> > a UEFI-native installation of your other OS. If you don’t like all
> > this UEFI nonsense and want to go back to the good old world
> > you’re familiar with, you will, I’m afraid, have to blow away the
> > UEFI-native Windows installation, and it would be a good idea to
> > reformat the disk to MBR."
> 
> I agree with the author. If you want to keep the existing EFI
> Windows installation and have a convenient dual boot with GRUB,
> you'll have to set up your favourite distribution to boot in EFI
> mode. If you want to go back to legacy boot, including for Windows,
> you'll have to repartition the disk to MSDOS format and reinstall
> Windows.

"convenient dual boot with GRUB" moves the goalposts.

> >I can't reconcile that with the system here, a Windows 8→10 UEFI laptop
> >and GPT disk running linux in BIOS compatibility mode (here called
> >Legacy mode by Lenovo) booting from an MBR on an ATA disk:
> 
> That is not very convenient, is it ? You cannot boot Windows boot
> manager from GRUB nor you can boot GRUB from Windows boot manager
> and must select the boot mode in the UEFI firmware setup whenever
> you want to switch the operating system.

It's very convenient for me. It means I haven't had to interfere with
the way windows chooses to boot, or its configuration of the disk, at all.

> >Switching over involves going through the "BIOS Setup", reached
> >by a separate button (almost recessed).
> 
> As expected.

Not by the author, who would have me reformat the disk as MBR and then
install windows…from where exactly?

Cheers,
David.

Re: UEFI/"BIOS" booting, was Re: USB Install Fails, Complains about CD-ROM

[Pascal Hambourg]

Le 13/05/2018 à 17:18, David Wright a écrit :

On Fri 11 May 2018 at 15:13:04 (-0500), Kent West wrote:


That's good to know. I guess my source material (
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/)
is wrong. Or I misunderstood it.


While a lot of the detail on that long page might be correct, there
are also statements there that don't seem to agree with reality.


Most of the statements you quoted agree with my (admittedly limited) 
experience with UEFI. There is a difference between the theory 
(specifications) and the reality (implementations), and some pieces of 
software may have extra requirements beyond the sole UEFI specification.



 "I really can’t recommend strongly enough that you do not attempt
 to mix UEFI-native and BIOS-compatible booting of
 permanently-installed operating systems on the same computer, and
 especially not on the same disk. It is a terrible terrible idea
 and will cause you heartache and pain. If you decide to do it,
 don’t come crying to me." (under "UEFI booting: background").


I would not be as much adamant as the author, but my experience says : 
it can work, but expect trouble.


Most of my early experience with UEFI boot comes from a rather old Intel 
motherboard. Beside crippled UEFI support (no UEFI boot from USB or SATA 
in AHCI mode), it had a couple of annoying requirements :
- boot in legacy mode only if the MBR contains a partition entry with 
the boot flag set, regardless of whether the disk has a MSDOS or GPT 
partition table. This behaviour is beyond any common BIOS standard, but 
I have observed it on many other systems, mostly Dell and HP ;
- boot in EFI mode from GPT only if the protective partition entry in 
the MBR has the boot flag unset. I admit this requirement is part of the 
GPT specification, but really do not see the point in enforcing such a 
minor detail.


Anyway, these two requirements put together make it impossible to boot 
in both legacy and EFI mode from the same GPT disk with this 
motherboard. However they allow to boot in both modes from the same 
MSDOS disk. But who still wants to use MSDOS format nowadays ?



 "Disk formats (MBR vs. GPT)

   Here’s another very important consideration:

   If you want to do a ‘BIOS compatibility’ type installation, you
 probably want to install to an MBR formatted disk. If you want to
 do a UEFI native installation, you probably want to install to a
 GPT formatted disk."


I do not agree so much with this one when it comes to install GNU/Linux. 
But it is an absolute requirement when installing Windows.



 "A specific example

 To boil down the above: if you bought a Windows 8 or later system,
 you almost certainly have a UEFI native install of Windows to a
 GPT-formatted disk. This means that if you want to install another
 OS alongside that Windows install, you almost certainly want to do
 a UEFI-native installation of your other OS. If you don’t like all
 this UEFI nonsense and want to go back to the good old world
 you’re familiar with, you will, I’m afraid, have to blow away the
 UEFI-native Windows installation, and it would be a good idea to
 reformat the disk to MBR."


I agree with the author. If you want to keep the existing EFI Windows 
installation and have a convenient dual boot with GRUB, you'll have to 
set up your favourite distribution to boot in EFI mode. If you want to 
go back to legacy boot, including for Windows, you'll have to 
repartition the disk to MSDOS format and reinstall Windows.



I can't reconcile that with the system here, a Windows 8→10 UEFI laptop
and GPT disk running linux in BIOS compatibility mode (here called
Legacy mode by Lenovo) booting from an MBR on an ATA disk:


That is not very convenient, is it ? You cannot boot Windows boot 
manager from GRUB nor you can boot GRUB from Windows boot manager and 
must select the boot mode in the UEFI firmware setup whenever you want 
to switch the operating system.



Switching over involves going through the "BIOS Setup", reached
by a separate button (almost recessed).


As expected.

Re: UEFI + Raid

[Pascal Hambourg]

Le 17/05/2017 à 20:07, Sam Smith a écrit :

On 05/16/2017 12:40 PM, Pascal Hambourg wrote:


Because of what I left quoted just above, I advise again using "debian"
as a sub-chain in the ID, because such entry may be deleted by a later
uncautious invocation of grub-install.


Wait, it (grub-install?) deletes anything with "debian" in it? Is that


Yes.


only when it is invoked with "debian" as the bootloader id? That seems


When it is invoked without --bootloader-id, which results in using the 
default name "debian".



troubling. What if I named it to "windows", would it then go delete all
my windows installs?


I have not tested this.

Anyway, on UEFI machines with only one boot loader (per disk if RAID), I 
don't rely on EFI boot entries (too flaky) and install GRUB in the 
"removable device path" (default EFI path) with --removable.

Re: UEFI + Raid

[Sam Smith]

On 05/16/2017 12:40 PM, Pascal Hambourg wrote:

Le 16/05/2017 à 19:12, Sam Smith a écrit :

On 05/11/2017 12:21 AM, Pascal Hambourg wrote:


Also, when using
the default ID ("debian"), it deletes any existing EFI boot entry whose
name contains "debian" (case insensitive IIRC).


I've used this now:
grub-install -v  --target=x86_64-efi  --bootloader-id=debian2
--efi-directory=/mnt/efi


Because of what I left quoted just above, I advise again using "debian"
as a sub-chain in the ID, because such entry may be deleted by a later
uncautious invocation of grub-install.




Wait, it (grub-install?) deletes anything with "debian" in it? Is that 
only when it is invoked with "debian" as the bootloader id? That seems 
troubling. What if I named it to "windows", would it then go delete all 
my windows installs? Guess I'll set the id to "deb2" and re-run



Regards,

Re: UEFI + Raid

[Pascal Hambourg]

Le 16/05/2017 à 19:40, Pascal Hambourg a écrit :

Le 16/05/2017 à 19:12, Sam Smith a écrit :

On 05/11/2017 12:21 AM, Pascal Hambourg wrote:


Also, when using
the default ID ("debian"), it deletes any existing EFI boot entry whose
name contains "debian" (case insensitive IIRC).


I've used this now:
grub-install -v  --target=x86_64-efi  --bootloader-id=debian2
--efi-directory=/mnt/efi


Because of what I left quoted just above, I advise again


Argh ! I advise *against*


using "debian"
as a sub-chain in the ID, because such entry may be deleted by a later
uncautious invocation of grub-install.

Re: UEFI + Raid

[Pascal Hambourg]

Le 16/05/2017 à 19:12, Sam Smith a écrit :

On 05/11/2017 12:21 AM, Pascal Hambourg wrote:


Also, when using
the default ID ("debian"), it deletes any existing EFI boot entry whose
name contains "debian" (case insensitive IIRC).


I've used this now:
grub-install -v  --target=x86_64-efi  --bootloader-id=debian2
--efi-directory=/mnt/efi


Because of what I left quoted just above, I advise again using "debian" 
as a sub-chain in the ID, because such entry may be deleted by a later 
uncautious invocation of grub-install.

Re: UEFI + Raid

[Sam Smith]

On 05/11/2017 12:21 AM, Pascal Hambourg wrote:

Le 11/05/2017 à 00:53, Sam Smith a écrit :

On 05/09/2017 05:44 PM, Pascal Hambourg wrote:


Or use grub-install with --removable and --efi-directory for each disk.
Or use grub-install with --efi-directory and --bootloader-id to install
a copy of GRUB wherever you want and add an EFI boot entry for it.

(...)

I tried to use "grub-install -v  --target=x86_64-efi
--bootloader-id=grub /dev/sdb"

But as far as I could tell everything was installed to the first disk
still (sda) and /boot/efi/EFI/ then had two entries, the old 'debian'
one and then new 'grub' one.


With EFI targets, grub-install ignores the specified device, because it
is irrelevant. This i why I told to use --efi-directory to indicate
which EFI partition (mounted on the specified directory instead of
/boot/efi) to install the GRUB core image on.


dd if=/dev/sda1 of=/dev/sdb1
efibootmgr -c -d /dev/sdb -p 1 -w -L 'debian backup' -l

'\EFI\debian\grubx64.efi'

And now "efibootmgr -v" shows:


Boot000E* debian backup

HD(1,GPT,96aa190b-b6c0-4753-ab6f-171ccc37b745,0x800,0x79800)/File(\EFI\debian\grubx64.efi)



Boot000F* debian

HD(1,GPT,3ec825d3-e2f7-4491-b4a5-321032b0ab8c,0x800,0x79800)/File(\EFI\debian\grubx64.efi)



Beware that using dd clones the partition, including the UUID and label.
So both the original and cloned partition have the same UUID, which will
confuse libblkid and result in either being mounted on /boot/efi.


I guess that will work, though I haven't rebooted yet. What I find weird
is that grub in legacy mode will install to all hard drives in the
system, or at least it would prompt you for what hard drives you wanted
it to be installed to. Why can't grub with efi just automatically do
that same?


Because grub-install works quite differently on EFI targets. It does not
install on a device but on an EFI system partition mount point. Also, it
requires to specify explicit IDs for multiple copies. Also, whhen using
the default ID ("debian"), it deletes any existing EFI boot entry whose
name contains "debian" (case insensitive IIRC).






Ah, this was the info I was missing. Didn't know the partition had to be 
mounted. I've used this now:
grub-install -v  --target=x86_64-efi  --bootloader-id=debian2 
--efi-directory=/mnt/efi


and I think all is well.


Regards,

Re: UEFI + Raid

[Pascal Hambourg]

Le 11/05/2017 à 00:53, Sam Smith a écrit :

On 05/09/2017 05:44 PM, Pascal Hambourg wrote:


Or use grub-install with --removable and --efi-directory for each disk.
Or use grub-install with --efi-directory and --bootloader-id to install
a copy of GRUB wherever you want and add an EFI boot entry for it.

(...)

I tried to use "grub-install -v  --target=x86_64-efi
--bootloader-id=grub /dev/sdb"

But as far as I could tell everything was installed to the first disk
still (sda) and /boot/efi/EFI/ then had two entries, the old 'debian'
one and then new 'grub' one.


With EFI targets, grub-install ignores the specified device, because it 
is irrelevant. This i why I told to use --efi-directory to indicate 
which EFI partition (mounted on the specified directory instead of 
/boot/efi) to install the GRUB core image on.



dd if=/dev/sda1 of=/dev/sdb1
efibootmgr -c -d /dev/sdb -p 1 -w -L 'debian backup' -l

'\EFI\debian\grubx64.efi'

And now "efibootmgr -v" shows:


Boot000E* debian backup

HD(1,GPT,96aa190b-b6c0-4753-ab6f-171ccc37b745,0x800,0x79800)/File(\EFI\debian\grubx64.efi)


Boot000F* debian

HD(1,GPT,3ec825d3-e2f7-4491-b4a5-321032b0ab8c,0x800,0x79800)/File(\EFI\debian\grubx64.efi)


Beware that using dd clones the partition, including the UUID and label. 
So both the original and cloned partition have the same UUID, which will 
confuse libblkid and result in either being mounted on /boot/efi.



I guess that will work, though I haven't rebooted yet. What I find weird
is that grub in legacy mode will install to all hard drives in the
system, or at least it would prompt you for what hard drives you wanted
it to be installed to. Why can't grub with efi just automatically do
that same?


Because grub-install works quite differently on EFI targets. It does not 
install on a device but on an EFI system partition mount point. Also, it 
requires to specify explicit IDs for multiple copies. Also, whhen using 
the default ID ("debian"), it deletes any existing EFI boot entry whose 
name contains "debian" (case insensitive IIRC).

Re: UEFI + Raid

[Sam Smith]

On 05/09/2017 05:44 PM, Pascal Hambourg wrote:

Le 09/05/2017 à 01:48, Sam Smith a écrit :


I have installed Debian Stretch on my first system using UEFI. I used a
two disk Raid 1 + LVM configured during install time to mount / on
(among other things).

But now I need to figure out how to add redundancy to the software raid
1 since I believe boot entries are only added to one disk during
installation time?


I did it with Wheezy and wrote a post about it in a french forum. But it
isn't very useful if you cannot read french, and it does not take into
account new fancy grub-install options available since Jessie :
--removable
--force-extra-removable
--efi-directory
--bootloader-id


According to
https://wiki.debian.org/UEFI#Missing_features there doesn't seem to be
much options. Is my only option to copy the FAT32 EFI system partition
from the first disk to the second disk and then use efibootmgr to add it
(the second disk) as a boot entry?


No, you have other options.
Manually install a copy of the GRUB EFI core image in the EFI removable
path of each disk. This location does not require to add an EFI boot
entry with efibootmgr.
Or use grub-install with --removable and --efi-directory for each disk.
Or use grub-install with --efi-directory and --bootloader to install a
copy of GRUB wherever you want and add an EFI boot entry for it.

Maybe you could also create a RAID 1 array with superblock at the end
and use it as the EFI system partition. Never tried it.


And will any subsequent kernel or
grub updates affect the system partition and thus require another
copy/sync to the second disk?


Kernel update : no, it just affects the /boot contents.
GRUB package update : yes.







Thanks for the tips.

I tried to use "grub-install -v  --target=x86_64-efi 
--bootloader-id=grub /dev/sdb"


But as far as I could tell everything was installed to the first disk 
still (sda) and /boot/efi/EFI/ then had two entries, the old 'debian' 
one and then new 'grub' one.



"efibootmgr -v" showed:

> Boot000E* grub 
HD(1,GPT,3ec825d3-e2f7-4491-b4a5-321032b0ab8c,0x800,0x79800)/File(\EFI\grub\grubx64.efi)
> Boot000F* debian 
HD(1,GPT,3ec825d3-e2f7-4491-b4a5-321032b0ab8c,0x800,0x79800)/File(\EFI\debian\grubx64.efi)



Basically on the same disk. I used "efibootmgr -b E -B" to delete the 
extra entry I had just made.


Next I just manually did

> dd if=/dev/sda1 of=/dev/sdb1
> efibootmgr -c -d /dev/sdb -p 1 -w -L 'debian backup' -l 
'\EFI\debian\grubx64.efi'


And now "efibootmgr -v" shows:

> Boot000E* debian backup 
HD(1,GPT,96aa190b-b6c0-4753-ab6f-171ccc37b745,0x800,0x79800)/File(\EFI\debian\grubx64.efi)
> Boot000F* debian 
HD(1,GPT,3ec825d3-e2f7-4491-b4a5-321032b0ab8c,0x800,0x79800)/File(\EFI\debian\grubx64.efi)



I guess that will work, though I haven't rebooted yet. What I find weird 
is that grub in legacy mode will install to all hard drives in the 
system, or at least it would prompt you for what hard drives you wanted 
it to be installed to. Why can't grub with efi just automatically do 
that same?



Regards,
Samuel Smith

Re: UEFI + Raid

[Pascal Hambourg]

Le 09/05/2017 à 01:48, Sam Smith a écrit :


I have installed Debian Stretch on my first system using UEFI. I used a
two disk Raid 1 + LVM configured during install time to mount / on
(among other things).

But now I need to figure out how to add redundancy to the software raid
1 since I believe boot entries are only added to one disk during
installation time?


I did it with Wheezy and wrote a post about it in a french forum. But it 
isn't very useful if you cannot read french, and it does not take into 
account new fancy grub-install options available since Jessie :

--removable
--force-extra-removable
--efi-directory
--bootloader-id


According to
https://wiki.debian.org/UEFI#Missing_features there doesn't seem to be
much options. Is my only option to copy the FAT32 EFI system partition
from the first disk to the second disk and then use efibootmgr to add it
(the second disk) as a boot entry?


No, you have other options.
Manually install a copy of the GRUB EFI core image in the EFI removable 
path of each disk. This location does not require to add an EFI boot 
entry with efibootmgr.

Or use grub-install with --removable and --efi-directory for each disk.
Or use grub-install with --efi-directory and --bootloader to install a 
copy of GRUB wherever you want and add an EFI boot entry for it.


Maybe you could also create a RAID 1 array with superblock at the end 
and use it as the EFI system partition. Never tried it.



And will any subsequent kernel or
grub updates affect the system partition and thus require another
copy/sync to the second disk?


Kernel update : no, it just affects the /boot contents.
GRUB package update : yes.

Re: UEFI + Raid

[Steve McIntyre]

deb...@net153.net wrote:
>Hi,
>
>I have installed Debian Stretch on my first system using UEFI. I used a 
>two disk Raid 1 + LVM configured during install time to mount / on 
>(among other things).
>
>But now I need to figure out how to add redundancy to the software raid 
>1 since I believe boot entries are only added to one disk during 
>installation time?  According to 
>https://wiki.debian.org/UEFI#Missing_features there doesn't seem to be 
>much options. Is my only option to copy the FAT32 EFI system partition 
>from the first disk to the second disk and then use efibootmgr to add it 
>(the second disk) as a boot entry? And will any subsequent kernel or 
>grub updates affect the system partition and thus require another 
>copy/sync to the second disk?

I'm afraid there's no automation for this yet. I'm hoping to find some
time to work on adding this during the Buster cycle, and the Grub
developers are apparently interested too.

For now, you'll need to do this by hand I'm afraid.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Dasmohapatra

Re: Uefi

[Antonio Trujillo Carmona]

El 19/02/17 a las 08:12, miguel angel gonzalez escribió:
> Buenas tardes,
> Tengo en un ordenador de nueva generación con la placa Gigabyte H170-H=
> D3 Socket 1151, una instalación  de Windows 10 y quiero instalar Debian
> , necesito Windows también por trabajo. Sabéis como puedo instalar los dos?
> Me trae de cabeza el tema de uefi, hago la instalación  con
> grub en el mismo disco y no me hace ni caso, ni aparece el arranque.
> Muchas gracias.
> Saludos.
>

Imagino que para intentar instalar el Debian habrás usado un "pendrive"
creado con un dd (no funciona bien si usas unetbootin)

Intenta arrancar el instalador en modo UEFI (si puedes elígelo desde la
bios) ojo podría arrancar en modo "legaci" y no te funcionaria bien.

Si arranca en modo UEFI el se encarga de crear una partición y
registrarse en la bios UEFI.

-- 

*Antonio Trujillo Carmona*

*Técnico de redes y sistemas.*

*Subdirección de Tecnologías de la Información y Comunicaciones*

Servicio Andaluz de Salud. Consejería de Salud de la Junta de Andalucía

_antonio.trujillo.sspa@juntadeandalucia.es_

Tel. +34 670947670 747670)

Re: Uefi

[miguel angel gonzalez]

Buenas,
Gracias por contestar a los dos. La partición está en Gpt, a que te
refieres con  hacerla visible en Linux?

Por más que miro en la Bios no encuentro la opción de legacy Mode, miraré
en el manual de la placa.


El 19 feb. 2017 9:52 a. m., "Ernesto Escobedo" 
escribió:

Muy buenas noches

define la particion gpt y hazla visible para el linux

ese es el truco

El 19 de febrero de 2017, 1:12, miguel angel gonzalez <
mangelgonza...@gmail.com> escribió:

>
> Buenas tardes,
> Tengo en un ordenador de nueva generación con la placa Gigabyte H170-H=
> D3 Socket 1151, una instalación  de Windows 10 y quiero instalar Debian
> , necesito Windows también por trabajo. Sabéis como puedo instalar los
> dos? Me trae de cabeza el tema de uefi, hago la instalación  con
> grub en el mismo disco y no me hace ni caso, ni aparece el arranque.
> Muchas gracias.
> Saludos.
>

Re: Uefi

[Ernesto Escobedo]

Muy buenas noches

define la particion gpt y hazla visible para el linux

ese es el truco

El 19 de febrero de 2017, 1:12, miguel angel gonzalez <
mangelgonza...@gmail.com> escribió:

>
> Buenas tardes,
> Tengo en un ordenador de nueva generación con la placa Gigabyte H170-H=
> D3 Socket 1151, una instalación  de Windows 10 y quiero instalar Debian
> , necesito Windows también por trabajo. Sabéis como puedo instalar los
> dos? Me trae de cabeza el tema de uefi, hago la instalación  con
> grub en el mismo disco y no me hace ni caso, ni aparece el arranque.
> Muchas gracias.
> Saludos.
>

Re: UEFI vs BIOS

[fred]

 
  


 un bon article sur la bébète en question
 http://linuxfr.org/news/uefi-%C3%A0-la-d%C3%A9couverte-du-nouveau-bios
 malgré la lecture duquel je n'arrive pas à comprendre ce qui est mieux !

En cette matière comme souvent, il n'y a pas d'optimum absolu. Le
mieux ne peut donc s'apprécier qu'en regard de critères définis et
pondérés.



Merci d'avoir renommé le post Pascal, ça m'a échappé..Vos avis sont les 
bienvenus, toutes et tous, merci :)Fred


   

Re: UEFI works with USB but not with HDD

[Nicolas George]

L'octidi 8 messidor, an CCXXIII, Dan a écrit :
 As suggested I typed efibootmgr -v and everything seems to be fine. I get

How do you know everything seems fine? Can you read this output in details?

 BootCurrent: 0001
 Timeout: 1 seconds
 BootOrder ,0001

 Boot0001* UEFI: SanDisk Cruzer Blade 1.27
 HD(1,f8c,340,1876769c)File(EFI\boot\bootx64.efi)..B0

Can you confirm that you booted from an USB stick of brand SanDisk Cruzer
Blade to get that output?

 Boot* debian Vendor(99e27e7-75a0-4b37-a2e6-c5385e6c00cb,)

If so, then this is supposed the entry for the Debian bootloader. It does
not match any syntax I know. AFAIK, the entry for an installed bootloader
should look like that:

Boot0001* NAME 
HD(1,GPT,01234567-89ab-cdef-0123-456789abcdef,0x??,0x?)/File(\EFI\debian\grubx64.efi)

 How do I tell UEFI the parameters or how to boot?

man efibootmgr

Something like:

efibootmgr -c -d /dev/sdX -l '\EFI\grub\grubia32.efi'

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: UEFI works with USB but not with HDD

[Dan]

On Fri, Jun 26, 2015 at 4:29 PM, Steve McIntyre st...@einval.com wrote:
 Dan wrote:

I just bought a desktop (Dell T5810). I tried to install Jessie with
UEFI. The USB installation (netinst) works perfectly. I installed the
whole system and I can see it in the UEFI/BIOS menu. Surprisingly when
I try to boot the system I get No bootable devices found

I tried all the options of the BIOS but it does not work. I already
installed Debian with UEFI in another system and it worked fine. Would
that mean that I have a buggy BIOS? What surprises me the most is that
the USB/UEFI works but not the HDD/UEFI.

 Unfortunately, it's not that uncommon. Lots of UEFI implementations
 are really bad so far - testing seems to be essentially does it work
 with Windows? and nothing more.

 As already suggested, try running efibootmgr -v on the system and
 see what it says. If needs be, use the installer in Rescue mode to get
 there. With Jessie, I also added an option in Rescue mode to add a
 removable media boot entry on your hard disk so that even really
 brain-dead UEFI setups should still boot...


Hi Steve,
As you suggested I use the option Force Grub installation to the EFI
removable media path and it works :)
Is there any disadvantage using this option? What is the difference
between this option and the regular UEFI boot?

Thanks,
Dan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak00fo+mcp4h-l7ieshw89-cvt4kx66vgkrjixwnw6w7vy2...@mail.gmail.com

Re: UEFI works with USB but not with HDD

[Steve McIntyre]

Dan wrote:

I just bought a desktop (Dell T5810). I tried to install Jessie with
UEFI. The USB installation (netinst) works perfectly. I installed the
whole system and I can see it in the UEFI/BIOS menu. Surprisingly when
I try to boot the system I get No bootable devices found

I tried all the options of the BIOS but it does not work. I already
installed Debian with UEFI in another system and it worked fine. Would
that mean that I have a buggy BIOS? What surprises me the most is that
the USB/UEFI works but not the HDD/UEFI.

Unfortunately, it's not that uncommon. Lots of UEFI implementations
are really bad so far - testing seems to be essentially does it work
with Windows? and nothing more.

As already suggested, try running efibootmgr -v on the system and
see what it says. If needs be, use the installer in Rescue mode to get
there. With Jessie, I also added an option in Rescue mode to add a
removable media boot entry on your hard disk so that even really
brain-dead UEFI setups should still boot...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast.
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1z8udi-0001jr...@mail.einval.com

Re: UEFI works with USB but not with HDD

[Dan]

On Fri, Jun 26, 2015 at 5:37 PM, Nicolas George geo...@nsup.org wrote:
 L'octidi 8 messidor, an CCXXIII, Dan a écrit :
 As suggested I typed efibootmgr -v and everything seems to be fine. I get

 How do you know everything seems fine? Can you read this output in details?

 BootCurrent: 0001
 Timeout: 1 seconds
 BootOrder ,0001

 Boot0001* UEFI: SanDisk Cruzer Blade 1.27
 HD(1,f8c,340,1876769c)File(EFI\boot\bootx64.efi)..B0

 Can you confirm that you booted from an USB stick of brand SanDisk Cruzer
 Blade to get that output?

Yest I booted from an the USB stick (netinst)

 Boot* debian Vendor(99e27e7-75a0-4b37-a2e6-c5385e6c00cb,)

 If so, then this is supposed the entry for the Debian bootloader. It does
 not match any syntax I know. AFAIK, the entry for an installed bootloader
 should look like that:

 Boot0001* NAME 
 HD(1,GPT,01234567-89ab-cdef-0123-456789abcdef,0x??,0x?)/File(\EFI\debian\grubx64.efi)

 How do I tell UEFI the parameters or how to boot?

 man efibootmgr

 Something like:

 efibootmgr -c -d /dev/sdX -l '\EFI\grub\grubia32.efi'

Thanks a lot, but still not working, when I add the entry as you
suggested I get another entry
Boot0002* Linux Vendor(99e00cb,)

I can add an entry with that command but I do not get something like
Boot0001* NAME 
HD(1,GPT,01234567-89ab-cdef-0123-456789abcdef,0x??,0x?)/File(\EFI\debian\grubx64.efi)


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak00folqgopo9hw4aw3zuh+u96sbr8kew2umsvcob-_iomo...@mail.gmail.com

Re: UEFI works with USB but not with HDD

[Dan]

On Fri, Jun 26, 2015 at 4:29 PM, Steve McIntyre st...@einval.com wrote:
 Dan wrote:

I just bought a desktop (Dell T5810). I tried to install Jessie with
UEFI. The USB installation (netinst) works perfectly. I installed the
whole system and I can see it in the UEFI/BIOS menu. Surprisingly when
I try to boot the system I get No bootable devices found

I tried all the options of the BIOS but it does not work. I already
installed Debian with UEFI in another system and it worked fine. Would
that mean that I have a buggy BIOS? What surprises me the most is that
the USB/UEFI works but not the HDD/UEFI.

 Unfortunately, it's not that uncommon. Lots of UEFI implementations
 are really bad so far - testing seems to be essentially does it work
 with Windows? and nothing more.

 As already suggested, try running efibootmgr -v on the system and
 see what it says. If needs be, use the installer in Rescue mode to get
 there. With Jessie, I also added an option in Rescue mode to add a
 removable media boot entry on your hard disk so that even really
 brain-dead UEFI setups should still boot...


As suggested I typed efibootmgr -v and everything seems to be fine. I get
BootCurrent: 0001
Timeout: 1 seconds
BootOrder ,0001
Boot* debian Vendor(99e27e7-75a0-4b37-a2e6-c5385e6c00cb,)
Boot0001* UEFI: SanDisk Cruzer Blade 1.27
HD(1,f8c,340,1876769c)File(EFI\boot\bootx64.efi)..B0

How do I tell UEFI the parameters or how to boot?

If I do not manage to install Debian with UEFI, I will switch to the
legacy BIOS option. Is there any adavantage using UEFI?

Thanks,
Daniel


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak00folkcjxrn_mheh3lod4yvwxynjb2rbpxezrzhsq3or-...@mail.gmail.com

Re: UEFI works with USB but not with HDD

[Steve McIntyre]

On Fri, Jun 26, 2015 at 06:16:13PM +0200, Dan wrote:
On Fri, Jun 26, 2015 at 4:29 PM, Steve McIntyre st...@einval.com wrote:
 Dan wrote:

I just bought a desktop (Dell T5810). I tried to install Jessie with
UEFI. The USB installation (netinst) works perfectly. I installed the
whole system and I can see it in the UEFI/BIOS menu. Surprisingly when
I try to boot the system I get No bootable devices found

I tried all the options of the BIOS but it does not work. I already
installed Debian with UEFI in another system and it worked fine. Would
that mean that I have a buggy BIOS? What surprises me the most is that
the USB/UEFI works but not the HDD/UEFI.

 Unfortunately, it's not that uncommon. Lots of UEFI implementations
 are really bad so far - testing seems to be essentially does it work
 with Windows? and nothing more.

 As already suggested, try running efibootmgr -v on the system and
 see what it says. If needs be, use the installer in Rescue mode to get
 there. With Jessie, I also added an option in Rescue mode to add a
 removable media boot entry on your hard disk so that even really
 brain-dead UEFI setups should still boot...


Hi Steve,
As you suggested I use the option Force Grub installation to the EFI
removable media path and it works :)

OK, cool.

Is there any disadvantage using this option? What is the difference
between this option and the regular UEFI boot?

The main disadvantage with this is that different OS installers will
fight each other to install to this location, just like the old BIOS
MBR boot block problem. That *shouldn't* cause you any problems,
unless you've got other operating systems on your hard disk that
os-prober hasn't found and added to the grub menu for you. That code
should work anyway, and give you boot options for any other OSes. If
you're not dual-booting then this can't be an issue.

Regular UEFI boot has several lists of possible boot entries, stored
in UEFI config variables (normally in NVRAM), and boot order config
variables stored alongside them. It allows for many different boot
options, and a properly-defined fallback order. In many cases, you can
even list and choose which OS / boot loader to use from the system
boot menu (similar to the boot device menu implemented in many
BIOSes). Unfortunately, a lot of UEFI implementations have got this
wrong and so don't work properly.

The correct way for this to work when booting off local disk is for a
boot variable to point to a vendor-specific bootloader program in

  \EFI\$vendor\$bootloader.efi

on the EFI System Partition (ESP). You'll see that Debian installs
grub as \EFI\debian\grubx64.efi for its EFI bootloader; grubx64.efi
contains all the bits that grub needs to work from that point. By
using separate vendor directories like this, EFI allows for clean
interoperability between vendors. If only the firmware developers were
competent... :-( Some implementations ignore the boot order
altogether, some filter it and will only run things that claim to be
Windows, etc.

Because of this incompetence, the Windows installer *also* installs to
the removable media path in the ESP (e.g. \EFI\boot\bootx64.efi for
amd64/X64 systems). *All* implentations have to use this path to be
able to run an OS installer. This means that Windows will always work
on all these broken implementations, but it also means that system
vendors can get away with shipping broken implementations. It removes
the idea of having a fallback boot path and sensible control of boot
order.

All OS installers installing things to this removable media path will
therefore conflict with any other such installers, which is bad and
wrong. That's why in Debian we *don't* do this by default and only
make this available as an option for people that need it, in the
rescue mode code you've just used.

Hope that helps!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150626172353.gn4...@einval.com

Re: UEFI works with USB but not with HDD

[Steve McIntyre]

On Fri, Jun 26, 2015 at 08:59:42PM +0200, Dan wrote:
On Fri, Jun 26, 2015 at 7:23 PM, Steve McIntyre st...@einval.com wrote:

 Hope that helps!

Thanks a lot for the great explanation!

I think it would be helpful for other users to put all this in the
Debian Wiki. Maybe you can paste your answer in a new entry in
https://wiki.debian.org/BootLoader , such as Installing Debian in a
Buggy UEFI Implementation.

Oddly, as I finished writing that text I was just pondering about
where to put it in the wiki... :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with Valor: Centurion represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150626203455.go4...@einval.com

Re: UEFI works with USB but not with HDD

[Dan]

On Fri, Jun 26, 2015 at 7:23 PM, Steve McIntyre st...@einval.com wrote:
Hi Steve,
As you suggested I use the option Force Grub installation to the EFI
removable media path and it works :)

 OK, cool.

Is there any disadvantage using this option? What is the difference
between this option and the regular UEFI boot?

 The main disadvantage with this is that different OS installers will
 fight each other to install to this location, just like the old BIOS
 MBR boot block problem. That *shouldn't* cause you any problems,
 unless you've got other operating systems on your hard disk that
 os-prober hasn't found and added to the grub menu for you. That code
 should work anyway, and give you boot options for any other OSes. If
 you're not dual-booting then this can't be an issue.

 Regular UEFI boot has several lists of possible boot entries, stored
 in UEFI config variables (normally in NVRAM), and boot order config
 variables stored alongside them. It allows for many different boot
 options, and a properly-defined fallback order. In many cases, you can
 even list and choose which OS / boot loader to use from the system
 boot menu (similar to the boot device menu implemented in many
 BIOSes). Unfortunately, a lot of UEFI implementations have got this
 wrong and so don't work properly.

 The correct way for this to work when booting off local disk is for a
 boot variable to point to a vendor-specific bootloader program in

   \EFI\$vendor\$bootloader.efi

 on the EFI System Partition (ESP). You'll see that Debian installs
 grub as \EFI\debian\grubx64.efi for its EFI bootloader; grubx64.efi
 contains all the bits that grub needs to work from that point. By
 using separate vendor directories like this, EFI allows for clean
 interoperability between vendors. If only the firmware developers were
 competent... :-( Some implementations ignore the boot order
 altogether, some filter it and will only run things that claim to be
 Windows, etc.

 Because of this incompetence, the Windows installer *also* installs to
 the removable media path in the ESP (e.g. \EFI\boot\bootx64.efi for
 amd64/X64 systems). *All* implentations have to use this path to be
 able to run an OS installer. This means that Windows will always work
 on all these broken implementations, but it also means that system
 vendors can get away with shipping broken implementations. It removes
 the idea of having a fallback boot path and sensible control of boot
 order.

 All OS installers installing things to this removable media path will
 therefore conflict with any other such installers, which is bad and
 wrong. That's why in Debian we *don't* do this by default and only
 make this available as an option for people that need it, in the
 rescue mode code you've just used.

 Hope that helps!


Thanks a lot for the great explanation!

I think it would be helpful for other users to put all this in the
Debian Wiki. Maybe you can paste your answer in a new entry in
https://wiki.debian.org/BootLoader , such as Installing Debian in a
Buggy UEFI Implementation.

Best,
Dani


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK00fOJmd9Z4gynS-F_bwxGt9hqk9+F5Z=gxjm7c9szen1q...@mail.gmail.com

Re: UEFI works with USB but not with HDD

[Nicolas George]

L'octidi 8 messidor, an CCXXIII, Dan a écrit :
 I just bought a desktop (Dell T5810). I tried to install Jessie with
 UEFI. The USB installation (netinst) works perfectly. I installed the
 whole system and I can see it in the UEFI/BIOS menu. Surprisingly when
 I try to boot the system I get No bootable devices found
 
 I tried all the options of the BIOS but it does not work. I already
 installed Debian with UEFI in another system and it worked fine. Would
 that mean that I have a buggy BIOS? What surprises me the most is that
 the USB/UEFI works but not the HDD/UEFI.

Apparently, in industry lingo, UEFI replaces BIOS, so if you have a UEFI
firmware, you can not have a BIOS firmware too, only possibly a BIOS
emulation.

And your UEFI firmware is probably bogus, because they all are.

That said, your problem can probably be solved.

There a big difference between UEFI booting from removable devices: in that
case, the UEFI firmware guesses the parameters of the bootloader. When
booting from the internal drive, it should be configured to know, not guess.

This is done with the efibootmgr tool. You should first have a careful look
at the output of efibootmgr -v. It should indicate the various boot menu
entries with their order.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: UEFI sin windows

[Camaleón]

El Sat, 30 Aug 2014 02:31:56 -0300, Pablo escribió:

 2014-08-29 11:24 GMT-03:00 Paulo Riquelme olivar...@gmail.com:
 
 No estoy seguro pero creo que te refieres a la partición de arranque,
 si es así es la primera que te mencioné, la Boot EFI

 
 Quiero agradecerles a todos por la data pasada. Ahí pude hacer un par de
 pruebas, y el tema viene mas o menos así. Encontré en la bios una opción
 para hacer arranque legacy. Teniendo eso configurado instale nuevamente
 con la diferencia de que cree una pequeña particion de unos 200 MB que
 la hice boteable. Y por suerte ahi me quedo funcionando. Muchísimas
 gracias a todos. Saludos.

Encontré este artículo¹ donde explican detalladamente qué se necesita 
para instalar un sistema linux con UEFI y que la verdad encuentro muy 
completo e ilustrativo (aunque quizá sea un poco técnico) para quienes se 
encuentran en la diatriba de UEFI o BIOS.

En breve, si el equipo sólo va a tener un único sistema operativo que se 
va a instalar desde cero (como es tu caso) yo me decantaría por usar UEFI 
antes que BIOS porque no existe ningún impedimento para hacerlo y porque 
al fin y al cabo UEFI es lo que viene. Activar el modo legacy puede ser 
conveniente cuando ya existe un sistema previamente instalado o cuando la 
placa base no es del todo estándar o falla en algún aspecto al activar 
UEFI.

Como ya te han comentado, el único requisito para UEFI es disponer de una 
partición creada para tal efecto y eso se puede hacer antes, después o 
durante la instalación de Debian. Sin embargo, esto no es necesario 
cuando se activa el modo legacy y se usa el modo emulación de BIOS.

¹http://www.rodsbooks.com/linux-uefi/

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.08.30.17.54...@gmail.com

Re: UEFI Secure Boot and enabling W8/Linux dual boot - some links/refs

[Florian Weimer]

* Steve Litt:

 I've personally disabled Secure Boot from a cold boot to the BIOS, and
 then installed Ubuntu, and had both OS's work. I've done this at least
 twice, maybe more. That being said, perhaps the reason I failed to
 install a *Debian* dual-boot was because I shut off Secure Boot from
 the BIOS instead of Windows.

I once disabled Secure Boot by swapping out the mainboard, and Windows
didn't care about that, either.  Curiously, the previous mainboard
(which had Secure Boot enabled) was bricked by a firmware update gone
wrong, precisely the thing the UEFI security architecture should
prevent (through firmware signing).  And with the new mainboard,
Secure Boot came back after a firmware update (luckily, because I
needed it for interop testing).


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761h9bueg@mid.deneb.enyo.de

Re: UEFI sin windows

[Pablo]

2014-08-28 23:42 GMT-03:00 Paulo Riquelme olivar...@gmail.com:

 William, te recomiendo reinstalar, yo viví lo que te está pasando hace 2
 semanas
 Instala Debian con UEFI activado, pero debe ser desde un cd Debian QUE
 NO SEA LIVE //por lo que vi Debian ya maneja bastante bien esto del
 UEFI.
 Cuando estés en la etapa del particionado del disco debes hacer un par
 de pasos distintos a lo tradicional, debes hacer dos particiones
 extra, estas son:
  1 partición del tipo boot EFI // 470 mb
  1 partición del tipo bios grub // 420 mb

 Los tamaños en mb. son sólo los tamaños que yo les puse, tengo
 entendido que con 250 mb. para la primera y un poco más para la
 segunda está bien.

 Con el resto del disco realizas un particionado normal, con swap,
 separas el home si quieres y obvio la raíz /

 Esto que te indiqué es la forma en como yo instalé, si todo va bien
 grub se instala correctamente y se asocia con UEFI sin problemas.
 Ojalá te sirva.

 Saludos.

 seravilO



Voy a hacer la prueba de lo que comentas. Igual mi tema pasa por que ya no
existe esa partición UEFI que venia por default. Me imagino que tendré que
ver como generar una nuevamente.



-- 
Pablo

Re: UEFI sin windows

[Paulo Riquelme]

El día 29 de agosto de 2014, 8:12, Pablo pablocar...@gmail.com escribió:



 2014-08-28 23:42 GMT-03:00 Paulo Riquelme olivar...@gmail.com:

 William, te recomiendo reinstalar, yo viví lo que te está pasando hace 2
 semanas
 Instala Debian con UEFI activado, pero debe ser desde un cd Debian QUE
 NO SEA LIVE //por lo que vi Debian ya maneja bastante bien esto del
 UEFI.
 Cuando estés en la etapa del particionado del disco debes hacer un par
 de pasos distintos a lo tradicional, debes hacer dos particiones
 extra, estas son:
  1 partición del tipo boot EFI // 470 mb
  1 partición del tipo bios grub // 420 mb

 Los tamaños en mb. son sólo los tamaños que yo les puse, tengo
 entendido que con 250 mb. para la primera y un poco más para la
 segunda está bien.

 Con el resto del disco realizas un particionado normal, con swap,
 separas el home si quieres y obvio la raíz /

 Esto que te indiqué es la forma en como yo instalé, si todo va bien
 grub se instala correctamente y se asocia con UEFI sin problemas.
 Ojalá te sirva.

 Saludos.

 seravilO



 Voy a hacer la prueba de lo que comentas. Igual mi tema pasa por que ya no
 existe esa partición UEFI que venia por default. Me imagino que tendré que
 ver como generar una nuevamente.

No estoy seguro pero creo que te refieres a la partición de arranque,
si es así es la primera que te mencioné, la Boot EFI

Saludos.

seravilO


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAJvcBJZNeGNJ8ZSra35nXp+G=L-XiE9c-ht=kr2ynew3rrt...@mail.gmail.com

Re: UEFI sin windows

[Pablo]

2014-08-29 11:24 GMT-03:00 Paulo Riquelme olivar...@gmail.com:

 No estoy seguro pero creo que te refieres a la partición de arranque,
 si es así es la primera que te mencioné, la Boot EFI

 Saludos.

 seravilO





Quiero agradecerles a todos por la data pasada. Ahí pude hacer un par de
pruebas, y el tema viene mas o menos así. Encontré en la bios una opción
para hacer arranque legacy. Teniendo eso configurado instale nuevamente con
la diferencia de que cree una pequeña particion de unos 200 MB que la hice
boteable. Y por suerte ahi me quedo funcionando. Muchísimas gracias a
todos. Saludos.


-- 
Pablo

Re: UEFI Secure Boot and enabling W8/Linux dual boot - some links/refs

[Steve Litt]

On Fri, 29 Aug 2014 10:51:19 +0100
Ron Leach ronle...@tesco.net wrote:

 3. a Use a 'trusted' bootloader, such as:
 
 http://mjg59.dreamwidth.org/20303.html
 
   or
 
 3. b Disable 'Secure Boot', which has to be done from within Windows, 
 not from a cold boot into BIOS:
 
 http://itsfoss.com/disable-uefi-secure-boot-in-windows-8/

I've personally disabled Secure Boot from a cold boot to the BIOS, and
then installed Ubuntu, and had both OS's work. I've done this at least
twice, maybe more. That being said, perhaps the reason I failed to
install a *Debian* dual-boot was because I shut off Secure Boot from
the BIOS instead of Windows.

 
 4.  Can Secure Boot be disabled on every machine?
 
 I've found no evidence yet of any machine that cannot disable Secure 
 Boot, but Red Hat is (well, actually 'was', in 2011) worried that
 some machines could have have that feature removed or disabled:

I have a million college age kids. OK, actually only three, but the way
they wear out laptops, it feels like a million. So, in the past 5
years, I've bought close to 10 laptops. On every one, I've booted
Linux, at the very least just long enough to copy the restore
partition off to a backup machine. But, one and only one of those
machines was impossible to turn off Secure Boot. In that case it didn't
matter because it was destined to be a Windows-only computer (for one
of my kids to use at college), but I *have* seen one computer on which
you could not turn off Secure Boot.

This is why I buy all my laptops at Costco. If for some reason it
doesn't run Linux, I can return it within 90 days, no questions asked,
no restocking fee. Just make sure you preserve that restore partition
so that you can give them back a working Windows computer.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140829093054.28fd6...@mydesq2.domain.cxm

Re: UEFI sin windows

[Adrià]

On Thu, Aug 28, 2014 at 07:46:49PM -0300, Pablo wrote:
Gente los molesto por un inconveniente que estoy teniendo al intentar
instalar debian 7.6 sobre una maquina con uefi. El tema es asA, borre la

[...]

muestra las opciones de arranque pero de la maquina. No me carga el grub.
Me imagino que es un problema de uefi, pero en los tutoriales que veo,
siempre dejan la bosta con la que viene de fabrica instalada, y yo eso ya
lo vole. Alguien tiene alguna idea de como hacer andar Debian solo como
unico SO en una maquina con UEFI?

Mira si esto te sirve:
https://wiki.debian.org/GrubEFIReinstall

-- 
Adrià García-Alzórriz
0x09494C14
What we need is either less corruption, or more chance to participate in it.


signature.asc
Description: Digital signature

Re: UEFI sin windows

[Pablo]

2014-08-28 20:02 GMT-03:00 Adrià ad...@fsfe.org:

 Mira si esto te sirve:
 https://wiki.debian.org/GrubEFIReinstall

 --
 Adrià García-Alzórriz
 0x09494C14
 What we need is either less corruption, or more chance to participate in
 it.





Si, eso lo había leído. El tema pasa por que ya no tiene las particiones
como venían. Borre todo el disco, y hice el esquema de particion normal
para instalar solo Debian. Eso me cambia todo.

-- 
Pablo

Re: UEFI sin windows

[Pablo]

2014-08-28 20:10 GMT-03:00 Marcos Germán Capelari marcoscapel...@gmail.com
:

 Hola,

 por casualidad usaste LVM para la instalación?






No, hice una instalación común sin LVM. Particione usando la opción manual,
y deje una particion para la swap, una para el raíz con todo el sistema y
una para la home.





-- 
Pablo