Re: "Bug" in Debian Installer?
On Fri 21 Apr 2023 at 23:05:53 (+0700), Max Nikulin wrote:
> On 21/04/2023 11:26, David Wright wrote:
> > On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote:
> >
> > > Opt-out variant for ESP sounds reasonable for me. However I am unsure
> > > if it is possible to complete installation with no ESP at all.
> >
> > If you mean: to install Grub but not write to the ESP,
>
> No, I did not go so far. I wrote about partitioning screen.
Understood; I wasn't sure.
> It is
> possible to select ESP partition and mark it "Do not use". My
> expectation is that it should prevent installing grub to ESP. However
> it is easy to forget about the "K" flag (partition will be used by
> installer).
I haven't tried removing all the flags to see what warning might result,
and whether there would even be any attempt to install grub-* (the
packages called grub-*, not writing grub.cfg or placing Grub code in
NVRAM). It does help to have the grub packages available to make
changes later.
> My point is that if a partition is marked for usage as ESP then it is
> not "without explicit notification and permission".
Agreed: it reinforces/confirms the point that the user asked the d-i
to install a Debian system.
> > ┌─────────────────┤ [!] Install the GRUB boot loader ├──────────────────┐
>
> Is it shown in the case of default debconf priority or it is necessary
> to switch to "low"?
IDK. As I said, "I think you can …", which I wrote because I think I
did just that. (I was doing something very similar to what the OP was
doing, using a PC with dual-booting Windows/Debian to install Debian
onto a portable drive, without screwing up the dual-boot.
> Frankly speaking, from this text it is unclear for me if the question
> is related to putting files to EFI/debian or to creation of new
> BootXXXX NVRAM variable with possible modification of BootOrder.
Sure. I was hacking, and keeping a close eye on VC4. (Using more is
hard work compared with less.)
> > │ The following other operating systems have been detected on this │
> > │ computer: Debian GNU/Linux 11 (bullseye) │
> > │ │
> > │ If all of your operating systems are listed above, then it should be │
> > │ safe to install the boot loader to your primary drive (UEFI │
> > │ partition/boot record).
>
> Side note. I do not think it is safe to install *Debian* boot loader
> when another *Debian* is detected. It will overwrite
> EFI/debian/grub.cfg and so will make earlier installed debian not
> bootable. Either I missed something or it is fragile to manage grub
> configuration shared by 2 independent debian (or other linux
> distributions) systems.
That's why I wrote about "playing tricks" below. Felix mentioned
using GRUB_DISTRIBUTOR to avoid having the same name used twice.
> > Bullseye had a misfeature where it would, even on a BIOS machine,
> > solicit installing to the fallback location.
>
> Do you mean installing grub to EFI/BOOT (layout for removable
> storage)?
Yes. The nomenclature is very confusing IMO.
> I have an almost 10 years old HP laptop with buggy firmware.
> The easiest way to make linux bootable is to put grub into EFI/BOOT
> (and remove fbx64.efi fallback binary that attempts to adjust BootXXXX
> and ignored BootOrder on each boot). It is possible to select any boot
> entry from F9 menu, but by default it boots from EFI/BOOT/bootx64.efi.
But this was a BIOS machine, so there's no UEFI/EFI. The buster d-i
seemed not to realise that, even though it knew it had an MBR:
┌───────────┤ [!] Install the GRUB boot loader on a hard disk ├───────────┐
│ │
│ You need to make the newly installed system bootable, by installing │
│ the GRUB boot loader on a bootable device. The usual way to do this │
│ is to install GRUB on the master boot record of your first hard │
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
│ drive. If you prefer, you can install GRUB elsewhere on the drive, or │
│ to another drive, or even to a floppy. │
│ │
│ Device for boot loader installation: │
┌──────────┤ [.] Install the GRUB boot loader on a hard disk ├──────────┐
│ │
│ It seems that this computer is configured to boot via EFI, but maybe │
↑↑↑↑↑↑↑↑↑↑↑↑
│ that configuration will not work for booting from the hard drive. │
│ Some EFI firmware implementations do not meet the EFI specification │
│ (i.e. they are buggy!) and do not support proper configuration of │
│ boot options from system hard drives. │
│ │
│ A workaround for this problem is to install an extra copy of the EFI │
│ version of the GRUB boot loader to a fallback location, the │
┌│ "removable media path". Almost all EFI systems, no matter how buggy, │
││ will boot GRUB that way. │
││ │
││ Warning: If the installer failed to detect another operating system │
││ that is present on your computer that also depends on this fallback, │
││ installing GRUB there will make that operating system temporarily │
└│ unbootable. GRUB can be manually configured later to boot it if │
│ necessary. │
│ │
│ Force GRUB installation to the EFI removable media path? │
> > > 2. On a laptop having ESP partitions on 2 disks, both ones are marked
> > > for usage as ESP. I am unsure if it causes installation error later or
> > > grub is installed on both ones (taking into account single /boot/efi
> > > mount point).
> >
> > I would assume not, as people complain about this as a single point of
> > failure in UEFI booting. I haven't tried repeating "Install the GRUB
> > boot loader" from the Main Menu, but I don't see why it shouldn't
> > work. But I don't think that that would get you two entries in NVRAM
> > without playing some tricks.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
> On that HP laptop I manually installed grub to second ESP. The result
> is 2 indistinguishable entries in F9 boot menu. The text is taken from
> shim/BOOTX64.CSV, no other hints displayed.
AIUI the desired outcome from that situation would be that the system
would choose one entry pointing to one ESP, and if that failed to
boot, automatically try the other. Fewer single points of failure.
Obviously, that doesn't happen.
Cheers,
David.
Reply to: