You are not logged in.
Pages: 1
The Devuan 3 Beowulf Release Notes says: "Edit /etc/os-release to show ID=devuan or edit /etc/default/grub to GRUB_DISTRIBUTOR="Devuan"."
I understand the change in /etc/default/grub, but why editing /etc/os-release? Grub doesn't seem to read that file, does it?
The Release Notes continues: "If you're booting UEFI mode, you will also need to remove grub-efi-amd64-signed and just use grub-efi-amd64."
Could someone please explain what exactly needs to be done? Why not simply run update-grub to generate a new boot menu?
If I am not wrong, the label "debian" in the UEFI boot menu can easily be changed to "Devuan" afterwards with efibootmgr, or am I missing something?
Offline
I dont use uefi, but i think you can just change the following line in /etc/default/grub
from
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
to
GRUB_DISTRIBUTOR=`lsb_release -d -s`
then sudo update-grub
Offline
To answer your question better i think lsb_release -i -s reads from the file /etc/os-release. So you could prbably just change the ID in /etc/os-release as well. There is probably a more technical issue why this is so but i have no idea.
Last edited by HevyDevy (2020-06-09 12:30:31)
Offline
To answer your question better i think lsb_release -i -s reads from the file /etc/os-release.
Nope, it reads from /etc/lsb-release.
Offline
HevyDevy wrote:To answer your question better i think lsb_release -i -s reads from the file /etc/os-release.
Nope, it reads from /etc/lsb-release.
That is strange because i dont have that file /etc/lsb-release on my installation of beowulf.
Last edited by HevyDevy (2020-06-09 12:49:55)
Offline
Could someone please explain what exactly needs to be done?
Probably not, but I'll try. I think the behavior of grub has changed since that was tested for the release notes. To change it in the boot menu, you can either change it in /etc/default/grub or /etc/os-release and re-run update-grub.
Like this works:
GRUB_DISTRIBUTOR=Devuan
Changing the 'ID=' line in /etc/os-release will also change the name of the bootloader created by 'grub-install'. I don't think /etc/default/grub will do that. Correct me if you find otherwise.
Changing it in /etc/lsb-release works, too, but you won't have that file unless you created it. Or maybe I created it for you, if you're running Refracta.
If you have secure boot enabled, I don't know what will happen. Some time ago, the bootloader directory on the efi partition needed to be named 'debian' if you were using the signed version of grub-efi-amd64, even without secure boot enabled. That appears to have changed in chimaera. Either that or my motherboard is lying to me about secure boot. That's a distinct possibility, since manufacturers can seem to agree on uefi implementations.
Offline
Just some off hand info here.
Devuan system im currently using was installed to a usb stick first using devuan installer then i proceeded to reinstall system from usb stick to ssd laptop using the usb stick via refractainstaller.
So if i just change GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
to
GRUB_DISTRIBUTOR=`lsb_release -d -s`
i get below for a grub boot menu
Devuan GNU/Linux 3 (beowulf)
Offline
Changing the 'ID=' line in /etc/os-release will also change the name of the bootloader created by 'grub-install'.
Correction:
With ID=mydevuan, grub-install creates a bootloader at /boot/efi/EFI/mydevuan
With ID=devuan, it does not. It just went back to using /boot/efi/EFI/debian.
So, like I said before, I probably can't explain it.
Offline
GRUB_DISTRIBUTOR=`lsb_release -d -s`
i get below for a grub boot menu
Devuan GNU/Linux 3 (beowulf)
This is not surprising, since grub undoubtedly makes use of GRUB_DISTRIBUTOR and lsb_release -d provides the description.
It is not and was not the question that a change to GRUB_DISTRIBUTOR will have an effect. The question was whether /etc/os-release would have any effect at all.
Changing the 'ID=' line in /etc/os-release will also change the name of the bootloader created by 'grub-install'.
Correction:
With ID=mydevuan, grub-install creates a bootloader at /boot/efi/EFI/mydevuan
With ID=devuan, it does not. It just went back to using /boot/efi/EFI/debian.So, like I said before, I probably can't explain it.
This is strange, because there is no reference to /etc/os-release in any grub source (genuine, debian, devuan) I could find. Actually, /etc/os-release seems to come from systemd and grub-install definitively reads the bootloader id from GRUB_DISTRIBUTOR in /etc/default/grub (unless given by option bootloader-id or setting it as environment variable).
Offline
There might be a difference in the files between people who were running Beta then upgraded and those that just installed the Release version. For the record, I upgraded from Beta, I don't have a /etc/lsb-release, and lsb_release -i -s reports 'Debian' unless I change the ID=Debian line in /etc/os-release whereupon the lsb_release -i -s reports 'Devuan' immediately.
Offline
There might be a difference in the files between people who were running Beta then upgraded and those that just installed the Release version. For the record, I upgraded from Beta, I don't have a /etc/lsb-release, and lsb_release -i -s reports 'Debian' unless I change the ID=Debian line in /etc/os-release whereupon the lsb_release -i -s reports 'Devuan' immediately.
I installed a minimal system with netinstall and have neither /etc/lsb-release nor lsb_release.
I can't find any reference to /etc/os-release in the lsb source from https://git.devuan.org/devuan-packages/lsb. So why is your lsb_release reading /etc/os-release?
So probably https://git.devuan.org/devuan-packages/lsb isn't the place that holds the actual Devuan sources?
Offline
lsb-base and lsb-release in ascii are devuanized packages. You can tell because 'devuan' is in the version. In beowulf, chimaera and ceres, we're using the unchanged debian versions.
The code you're looking for might be here: https://salsa.debian.org/debian/lsb
Offline
HevyDevy wrote:To answer your question better i think lsb_release -i -s reads from the file /etc/os-release.
Nope, it reads from /etc/lsb-release.
HevyDevy, you are right.
The first part of my problem is solved. The Debian/Devuan version of lsb is modified and reads - unlike the genuine lsb_release, which reads from /etc/lsb-release - /etc/os-release instead.
So the release notes should read more precisely: "Edit /etc/os-release to show ID=devuan and edit /etc/default/grub so that GRUB_DISTRIBUTOR ends with 'echo Devuan' instead of 'echo Debian' (in case lsb_release isn't installed)".
I still don't get "If you're booting UEFI mode, you will also need to remove grub-efi-amd64-signed and just use grub-efi-amd64.", though. Any explanation what to do or what is meant appreciated.
Last edited by jdev (2020-06-09 22:40:15)
Offline
I still don't get "If you're booting UEFI mode, you will also need to remove grub-efi-amd64-signed and just use grub-efi-amd64.", though. Any explanation what to do or what is meant appreciated.
Are you using secure boot?
Are you unable to boot your os?
If your answer to the second question is 'yes' then you will need to do something. We will help you figure that out. Otherwise, you can ignore it.
In previous testing, the bootloader had to be named 'debian' if you used the signed grub package. Otherwise, it could not find the bootloader, because $prefix was hard-coded as EFI/debian. I don't know if that's still true in beowulf.
Offline
Are you using secure boot?
No.
I disabled "secure boot" prior to the installation, because it stopped the netinstall usb stick from booting (and I don't want secure boot anyway).
Nevertheless, the signed boot loader was installed.
Are you unable to boot your os?
No.
But I'd like to change the boot menu entry from "Debian" to "Devuan" and because I can't use the signed boot loader then anyway, I wonder what "remove grub-efi-amd64-signed and just use grub-efi-amd64" means, respectively what exactly has to be done (to make sure it still will boot afterwards).
Offline
Hi
It means that the signed one will boot with secure boot enabled (and also without). The other only without secure boot disabled. But to my knowledge (in this case limited) there is no reason not to use the signed kernel anyway.
Have a nice day
Lars H
Last edited by larsH (2020-06-10 19:56:28)
Offline
For those of you who, like me, want to understand in more detail why renaming Debian to Devuan affects secure boot, here is what I have found out so far and what I think to understand:
The signed boot loader shimx64.efi, which is necessary for secure boot, was taken unchanged from Debian. The EFI directory, where the files necessary for booting must be located, is in Debian - of course - defined as boot/efi/EFI/debian. Grub on the other hand takes the definition in GRUB_DISTRIBUTOR as the directory where to install grubx64.efi. So in order for shimx64.efi to load grubx64.efi (probably only within the same directory), grub must also select "debian". If you change this in /etc/default/grub, grubx64.efi will end up in a directory without shimx64.efi.
But the shim sources apparently allow the creation of a signed boot loader with a canonical certificate for other distributions. For Ubuntu this is already part of the rules (dpkg-vendor --is ubuntu), so Devuan would only have to add this for itself, compile and provide shim as an own package.
Offline
And now, to finally solve the last part of my problem, a step by step description of what actually to do:
sudo apt autoremove --purge grub-efi-amd64-signed shim-signed
Edit /etc/os-release and /etc/default/grub as mentioned above.
Remove the old (debian) EFI boot menu entry:
sudo efibootmgr -v and look for the line saying Bootxxxx* debian, where xxxx is something like 0001 or 0002 or so.
Delete the entry:
sudo efibootmgr -b xxxx -B, where xxxx is the value from above.
Install a new boot loader:
sudo grub-install
Optionally, delete the old (debian) secure boot loader:
sudo rm -r /boot/efi/EFI/debian
Reboot.
Be happy!
It worked for me after a netinstall, but do it at your own risk.
Offline
Pages: 1