EFI directory name clash

gera · 2024-01-25 18:10:53

I have been trying to set up a multiboot system with both Debian (cli only) and Bunsenlabs Beryllium. I can get it to work, but every time I install one of these after the other, the boot time for the first distro installed becomes very long. This seems to be a result of both installations using the same directory name in the EFI partition, ("debian"). I have tried on my laptop and in multiple virtual images, always with the same results.

I can install multiple instances of Linux with no issues as long as each distro creates a somewhat unique directory in the EFI partition. For example, Sparky Linux, another Debian based distro, creates an EFI directory named "sparky", not "debian", therefore does not clash with a Debian or Bunsenlabs installation.

On my laptop with a fast SSD, Debian boot time to the CLI was about 8 seconds before I installed Bunsenlabs. After Bunsenlabs is installed, it takes about 40 seconds for Debian to boot each and every time, but only about 25 seconds for BL to get to the login screen. If I install in the reverse order, BL takes a long time to boot and Debian is back to about 8 seconds. I don't know if it's related, but grub would not find the Debian installation without some work, but would find any other distro (with a different EFI directory name) installed when installing Bunsenlabs. When Debian is installed first, and I hibernate Bunsenlabs just one time, Debian takes even longer to boot from then on (about 40 seconds). Yes, I know you must resume the exact same instance that was hibernated.

I would try to modify installer myself (as a learning experience), but I don't have anywhere near the skill or knowledge to attempt something like that.

So, to my suggestion: I would like to suggest that the Bunsenlabs installer create an EFI partition directory called something other than "debian", like, well, "bunsenlabs". Obviously, this is possible since Sparky Linux can and it's installer appears to be almost exactly the same and the Debian and Bunsenlabs installers.

Thanks for listening!

r.chaffee53 · 2024-01-25 20:20:34

I would suggest it has to do with the swap partition. The newest install has overwritten the swap and the original install times out during the boot looking for it; 1-1½ minutes.

If you'll post the output of

$ sudo lsblk

It would give us a place to start.

HTH,
Bob

PS One of the capable forum monitors will be along
shortly to move this thread to it's rightful place.

Last edited by r.chaffee53 (2024-01-25 20:56:04)

gera · 2024-01-25 21:07:42

Thanks Bob. I have tried without swap partitions (I have 16GB of memory in the laptop) and there is still a long boot time for the first distro installed. After some investigation, you are probably right about the swap causing additional delay after a hibernation. I did install with a swap partition initially, but no swap the last 2 times I tried on the laptop. BTW, every time I try this I start with a clean partition table. With so many installations and wipes, to reduce wear and tear on my laptop SSD, I've been working on this in virtual machines from a hard disk on my Windows PC without making swap partitions.

Edit: I'm not asking for help, just making a suggestion for a change in how the installation works. I'll get it figured out eventually even if I have to use some other CLI only distro that creates it's own folder (like Sparky Linux). As I've said, some Debian based distros do use "unique" names for the EFI folder, some don't. Same for Arch based distros. In fact, using the Arch installation guide, you don't even create a separate folder for the EFI files, but some distros based on Arch do create a their own folder. It seems to be that one that does would be "better behaved" than one that does not.

Last edited by gera (2024-01-25 21:14:21)

r.chaffee53 · 2024-01-25 21:18:51

That's way above my pay grade.
Welcome to the forum.

Bob

Last edited by r.chaffee53 (2024-01-25 21:33:51)

johnraff · 2024-01-26 07:53:38

Hi gera, thanks for the feedback. I'm afraid you've run into the consequence of enabling Secure Boot in our installer. The system has to be installed as Debian - which it is in fact - and after SB has been set up the package bunsen-os-release is installed to provide an appropriate name for things like the grub boot menu. That makes it impossible to install both BL and Debian on the same machine.

Unfortunately the result of using a separately named EFI directory would be that Secure Boot no longer worked, and we chose the option which seemed likely to benefit more users. Some day, maybe it will be possible to generate signed files for derivatives to use Secure Boot...

Meanwhile if you don't need SB, it should be possible to install bunsen-os-release earlier, before grub is installed, which would make an EFI directory named "bunsenlabs", and clashes with Debian would end. I haven't tested this procedure, but if you have a spare machine to try it on:

To get the installer to pause between actions you'll need to use Expert Mode.
At the point in the install process after "Configure the package manager" but before "Install the GRUB boot loader", press Ctrl+Alt+F2 to get a shell, and run:

apt-install bunsen-os-release bunsen-python-apt-template

Then Ctrl+Alt+F1 to go back to the regular installer interface and continue the installation.
That should result in an EFI directory named bunsenlabs, and allow Debian to be installed side-by-side.
I think SB should still work for Debian, but no longer for BL.

If that works for you, we should think about how to provide that option in the installer for people who don't mind sacrificing Secure Boot to allow co-existence with a Debian system. Up till now we've used the Debian installer pretty much as-is so it will need some work.

But thanks for raising the issue!

Last edited by johnraff (2024-01-27 07:58:34)

gera · 2024-01-26 14:35:25

Thank you! That makes sense. I'll give your suggestions a try and report back.

johnraff · 2024-01-27 11:51:17

^^I played with that a bit in a VM this afternoon and it looks as if it might not be so simple.

But I had another thought - you are of course installing Debian and BL on different partitions, right? On this machine I have BL Beryllium, Lithium and Helium each in their own partition and I can boot any of them from my grub efi menu. But the mapping from OS to directory name doesn't look simple:

john@beryllium:~$ sudo ls /boot/efi/EFI
boot  Boot-orig  bunsenlabs  debian  Microsoft

(There's a WIN 10 there too, which I never use.)

john@beryllium:~$ efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0007,0001,0002,0003,0008,0004,0005,0006,0009,000A
Boot0000* bunsenlabs
Boot0001* DTO UEFI USB Floppy/CD
Boot0002* DTO UEFI USB Hard Drive
Boot0003* DTO UEFI ATAPI CD-ROM Drive
Boot0004* Windows Boot Manager
Boot0005* DTO Legacy USB Floppy/CD
Boot0006* Hard Drive
Boot0007* debian
Boot0008* ST2000DM001-1CH164
Boot0009* IBA GE Slot 00C8 v1550
Boot000A* CD/DVD Drive

Surely it's possible to have multiple installs of Debian in separate partitions? Won't all of them be using an EFI directory named "debian"?

gera · 2024-01-27 15:49:07

I am using separate partitions. I haven't had any time to work with this (in the middle of painting several rooms in the house), but I would not be installing multiple copies of the same distro. AFAIK, you can install multiple instances of the same Debian distro, and they would use the same folder , but it could slow down booting for one or more of those distros. The only way around this would be to have the ability name the folder of each distro differently ("debian1", "debian2", etc.). I would not expect that to be an option in any distro. There is only so much that can be done with the current structure of EFI.

More research indicates that the slow booting of some installations when they use the same folder could be a result of the particular EFI implementation on a given computer. Some Asus laptops apparently fall into this category and is probably what is affecting mine. The EFI implementation in VirtualBox may have the same issue.

I hope to have some time this weekend to try out your suggestions in post #5.

Thanks

johnraff · 2024-01-30 05:04:26

gera wrote:

I hope to have some time this weekend to try out your suggestions in post #5.

johnraff wrote:

That should result in an EFI directory named bunsenlabs, and allow Debian to be installed side-by-side.
I think SB should still work for Debian, but no longer for BL.

My tests on a VM suggest it's not so easy.
After I followed my own suggestion to install bunsen-os-release before grub, on reboot the system threw up a grub shell.
To get it to boot required some work there:

ls

(get the drive names)

ls (hd0,2)/

(try the different partitions till you get the one with the filesystem, including /boot/grub)
(in this case it was (hd0,2) )

set prefix=(hd0,2)/boot/grub
set root=(hd0,2)
insmod linux
insmod normal
normal

This was enough on my VM to get BL to boot.
https://unix.stackexchange.com/a/330852

To make it persistent, we have to use the debian efi directory anyway, on the booted BL system:

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian
sudo update-grub

Secure Boot still works. Set bootloader-id to bunsenlabs and it won't even boot because debian is hard-coded somewhere in the boot chain.

So for now, having BL present intself to Debian Installer as debian seems like the only way to go, ie what the BL iso currently does.

( See also Debian Bug 908200: https://bugs.debian.org/cgi-bin/bugrepo … bug=908200 )

Last edited by johnraff (2024-01-30 07:13:06)

gera · 2024-01-31 00:02:04

I use VirtualBox, so my issues were probably a little different than yours. I installed Bunsenlabs then Debian in one VM then reversed the order installing them in another VM installing bunsen-os-release before grub both times. I do have SB turned off in the VMs. On the laptop I will eventually be using I'm not worried about not having SB, either.

I could not get the Debian installer to run (graphical or text) until I remembered that Debian does not like the way paravirtualization works (built with some proprietary components) in VirtualBox (does not apply to VMware). I found that if I turn off paravirtualization just during the Debian installation, then set it back to "default" which is KVM for Linux, after installation, it seems to run fine. It doesn't seem to make much performance difference, so it problems arise, I can always turn it off again.

With Bunsenlabs installed first then Debian, everything went well except as noted above. Grub finds and lists both in the boot menu.

Installing Debian first made it a little trickier. I went through the motions for installing Bunsenlabs, but upon reboot, it did not show up in the grub menu and running os-prober/update-grub did not help. I had to edit the Debian /etc/default/grub to include GRUB_DISABLE_OS_PROBE=false (it is true by default in Debian), then run update-grub. Afterwards, both show up in the grub menu.

#1 2024-01-25 18:10:53

EFI directory name clash

#2 2024-01-25 20:20:34

Re: EFI directory name clash

#3 2024-01-25 21:07:42

Re: EFI directory name clash

#4 2024-01-25 21:18:51

Re: EFI directory name clash

#5 2024-01-26 07:53:38

Re: EFI directory name clash

#6 2024-01-26 14:35:25

Re: EFI directory name clash

#7 2024-01-27 11:51:17

Re: EFI directory name clash

#8 2024-01-27 15:49:07

Re: EFI directory name clash

#9 2024-01-30 05:04:26

Re: EFI directory name clash

#10 2024-01-31 00:02:04

Re: EFI directory name clash

Board footer