Closed Biosias closed 1 month ago
With the amount of changes scheduled for the next version. I'll designate it as v2.0 I think it deserves to be a major version.
Works well on my end 👍
One small problem I noticed:
efibootmgr: ** Warning ** : Boot0200 has same label UMC 6.9.7-gentoo-dist on EFI system partition
This happens when you have both an UKI and a plain kernel image of the same kernel version on the same partition.
In
app-emulation/virt-firmware
this problem is resolved by appending(UKI)
or(plain)
to the label, maybe we can do something similar here?
Are UKIs somehow marked by installkernel? So I have a way to distinguish them from each other
Are UKIs somehow marked by installkernel? So I have a way to distinguish them from each other
UKIs are installed in the EFI/Linux
directory. Plain kernel images are in EFI/$(cat /etc/os-release | grep NAME)
.
It is possible to identify them with e.g. objdump as well, but it's not straightforward and probably fragile so I think it is better to determine type simply from the directory it is in (Linux
or something else).
Are UKIs somehow marked by installkernel? So I have a way to distinguish them from each other
UKIs are installed in the
EFI/Linux
directory. Plain kernel images are inEFI/$(cat /etc/os-release | grep NAME)
.It is possible to identify them with e.g. objdump as well, but it's not straightforward and probably fragile so I think it is better to determine type simply from the directory it is in (
Linux
or something else).
Hmmm, that is a shame. Wouldn't it be possible for installkernel to mention it in the name of the efi file ? Of course I can distinguish it by its location but I don't like doing it this way. The script would just blindly trust that everything in that directory is a UKI
Wouldn't it be possible for installkernel to mention it in the name of the efi file ?
Not without changing things in eclean-kernel as well.
The script would just blindly trust that everything in that directory is a UKI
Yes, but there is an official specification that reserves this directory exclusively for UKIs, so if something would put something else in there then that application is misbehaving and would need fixing. Besides it only changes the label so even if this goes wrong it is not critical.
Another option is to forget about UKI's vs non-UKI's and mention in the label simply the sub-directory that this EFI file is in. This may be a good alternative that would also make the multi-distro support here a bit better. Consider for example /EFI/Gentoo/vmlinux-x.y.z.efi
and /EFI/Fedora/vmlinux-x.y.z.efi
, this would currently also cause a double label.
Yes, but there is an official specification that reserves this directory exclusively for UKIs
Ahhh, ok sorry didn't know about this. In that case, of course no problem.
Another option is to forget about UKI's vs non-UKI's and mention in the label simply the sub-directory that this EFI file is in. This may be a good alternative that would also make the multi-distro support here a bit better. Consider for example
/EFI/Gentoo/vmlinux-x.y.z.efi
and/EFI/Fedora/vmlinux-x.y.z.efi
, this would currently also cause a double label.
However I think this is a way to do it exactly because of the reasons you mentioned.
Ok for know this is all for changes for the new version. If you notice something let me know, otherwise I'll merge it and will make a new version and ebuild for it.
I thought about this a lot and I think it would be better just to refuse to continue if no configuration is found.
Using /proc/cmdline can do more damage than it is helpful. Not to mention availability of /proc/cmdline can be turned of in kernel configuration.
Fixed problems reported in issues #9 #10 #11 and made some performance optimizations.