Re: F42 Change Proposal: Enable Drm Panic (system-wide)
Hi, > > > Do you expect to see the rest of the drivers supported by the time > > > Fedora 42 rolls around? Because if it only works with nouveau, it's > > > probably not worth enabling. > > > > I think it's a bit of a chicken and egg problem. If no distro enables > > it, there will be little incentive for the drivers to add support. > > > > Also, on all hardware, simpledrm is used at boot, so common kernel panic > > like "unable to mount /", or "failed to execute /init", will use drm_panic. > > > > FYI, I opened an issue for amdgpu here: > > https://gitlab.freedesktop.org/drm/amd/-/issues/3340 > > > > And for i915 here: > > https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10954 > > Forgive me for the potentially dumb question, but why does every > driver have to individually implement support for it? DRM is a > framework, right? So how come it's not implemented in a way such that > all DRM drivers get it "for free"? The hard problem is that at panic time you have no idea what state the system is in. So ideally you bring the message to the screen without taking any locks, to avoid being stopped by a deadlock. A generic solution which goes through drm interfaces (like generic fbdev emulation does) simply can't do that. take care, Gerd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Tue, Apr 09, 2024 at 05:02:00PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Apr 09, 2024 at 03:38:07PM +0200, Gerd Hoffmann wrote:
> > > In particular:
> > > - local builds work, I do them all the time, with 'fedpkg local' or
> > > through an srpm.
> >
> > Using rpmbuild directly needs some adaption though:
> >
> > (1) Use 'rpmautospec calculate-release' to figure what the release
> > number is.
> > (2) Pass that to rpmbuild using --define "_rpmautospec_release_number $nr".
>
> I don't use rpmbuild directly very often, but:
> fedpgk srpm
> fedpkg local
> work fine both when there are uncommitted modifications and when not.
> I actually use "fedpkg srpm && mock $options $(ls -1tr *.src.rpm|tail -n1)"
> all the time, and that also works with and without uncommitted modifications.
>
> What goes wrong if _rpmautospec_release_number is not difined?
I've hacked my build script to always set it ...
if grep -q autorelease "$SRCDIR/$specfile"; then
autorelease="$(rpmautospec calculate-release)"
autorelease="${autorelease##* }"
echo "autorelease is $autorelease ..."
else
autorelease="99"
fi
rpmbuild \
--define "_rpmautospec_release_number $autorelease" \
$more_args
... because something broke, but I don't remember what exactly it was.
Maybe just that the numbering differed from koji/copr builds.
take care,
Gerd
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
> In particular: > - local builds work, I do them all the time, with 'fedpkg local' or > through an srpm. Using rpmbuild directly needs some adaption though: (1) Use 'rpmautospec calculate-release' to figure what the release number is. (2) Pass that to rpmbuild using --define "_rpmautospec_release_number $nr". take care, Gerd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, > > > This is IMHO a mistake, the systemd-boot and UKI paths are the perfect > > > time > > > to break with shim and require some form of actual fedora/whatever secure > > > boot key enrollment on the machine. > > > > This is not going to fly. There are too many cases where you simply > > can't enroll fedora keys, so booting on machines with the MS 3rd party > > certificate enrolled IMHO must continue to work. > > I agree solving this for every possible machine combination is an > intractable problem at the moment. But, the UKI use case, as I understand > it, is a handful of hyperscalers and machines. Well, that is the main focus for now. At the end of the day I think using UKIs is good for all hardware. There are a number of roadblocks to be solved before they will actually work in more complex setups though. For the simple cases (no multiboot, ...) and standard storage (ahci/nvme) the virt UKI does also boot on physical hardware, I have a thinkpad running with it. But even when limiting things to the hyperscalers it doesn't work everywhere. On AWS you can bring your own uefi variable store, with whatever you want in 'db' etc. On Azure you can't. > I'm talking about removing shim from the boot flow. That is not a goal of this change proposal, and it's not up for debate for phase #2. Maybe an option in a later phase, once we have a signed systemd-boot (see below). > The UKI would be signed with the fedora key same as would be done with > shim in the boot path. The fedora public key is itself enrolled in the > UEFI key db alongside the assortment of existing db entries, and the > boot path would be UEFI->UKI. If the 'enroll fedora public key in db' part would be *that* simple shim would not exist in the first place. > > Problem #2 is we don't have a signed system-boot binary. Switching over > > to use systemd-boot when this has changed should be easy. The UKIs are > > already placed in $ESP/EFI/Linux, according to the boot loader spec, > > where systemd-boot would look for them. So the kernel-install workflow > > would need only minor changes. > > I'm not sure that is strictly needed. It'll be useful for multiple reasons, especially if you want make shim optional in the boot chain: (1) systemd-boot already supports secure boot key enrollment in case the machine is in setup mode. (2) It will remove the dependency on shim's fallback.efi (to create BDS entries for the UKIs on first boot). take care, Gerd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
On Fri, Dec 15, 2023 at 02:03:27PM -0600, Jeremy Linton wrote: > Hi, > > > Phase 2 goals > > > > * Add support for booting UKIs directly. > > ** Boot path is shim.efi -> UKI, without any boot loader (grub, > > sd-boot) involved. > > This is IMHO a mistake, the systemd-boot and UKI paths are the perfect time > to break with shim and require some form of actual fedora/whatever secure > boot key enrollment on the machine. This is not going to fly. There are too many cases where you simply can't enroll fedora keys, so booting on machines with the MS 3rd party certificate enrolled IMHO must continue to work. I agree that depending on MS signing exclusively is a problem. I'd love to see fedora signing as an option. Given that EFI binaries can have multiple signatures we could have shim.efi signed by both microsoft and fedora. Which would allow to enroll the fedora keys instead of the microsoft keys (in case your platform offers that option) and everything works as it did before, except that the machine would only accept fedora-signed EFI binaries. Problem #1 is we don't have that in fedora today. Which btw is different from rhel/centos, where we actually have a second, distro-signed shim binary. Not as useful as one binary with two signatures, but better than nothing. Problem #2 is we don't have a signed system-boot binary. Switching over to use systemd-boot when this has changed should be easy. The UKIs are already placed in $ESP/EFI/Linux, according to the boot loader spec, where systemd-boot would look for them. So the kernel-install workflow would need only minor changes. Problem #3 is that apparently everything touching fedora secure boot signing takes ages to make any progress. One ticket I've looked at recently (IIRC the one to enable secure boot signing for aarch64) was roughly five years (!) old. So I'm not going to make my change proposals depend on any progress there. But I'll happily file a Phase #3 proposal once the problems outlined above are solved. > whole UKI concept works at all. Put another way, there isn't really an > answer to a generic boots everywhere UKI at the movement unless one is > willing to create GB+ UKIs with every boot critical driver in existence, Well, CoreOS actually does that. They don't use UKIs specifically, but they ship a generic initrd created on fedora infrastructure instead of generating an host-specific initrd on the installed machine (with only the drivers needed on the host included). Last time I looked it was ~80 MB in size. > at which point its probably worth revisiting the entire initramfs boot > method. That is *way* beyond the scope of this change proposal ... take care, Gerd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, > Does that mean that the Linux EFI boot code knows how to call back to > shim to get the certificates instead of reading the firmware directly? No. The linux efi stub doesn't need that. shim.efi does: (a) Set efi variables, where the linux kernel can read the certificates from. This works the same way for both traditional kernels and UKIs. (b) provide an efi protocol for bootloaders, which can be called by grub and systemd-boot to verify the signature for binaries they load (typically the linux kernel, but could also be fwupd.efi). take care, Gerd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, > What is the point of using shim in this path? We're not having UKIs > signed by Microsoft, and unless the Linux kernel knows how to call > shim for certificates, I don't see how this is supposed to be useful > for the Microsoft->Fedora->OS boot chain. Booting without shim.efi would work only if you enroll the fedora secure boot CA in your firmware's security database. That is not the default, and not all virtualization environments offer the option to do that. So, on a typical setup with the microsoft keys enrolled the firmware wouldn't load the UKI, exactly because it is not signed by microsoft. shim.efi is needed for everything signed with the fedora keys, be it grub.efi, fwupd.efi, traditional kernels or UKIs. Also note that fallback.efi (comes with shim and runs in case there is no UEFI boot configuration) will create only uefi boot entries including shim in the boot path, so there is no easy way to exclude shim. Ideally we would have shim.efi signed with both microsoft and fedora keys. In that case the firmware -> shim.efi -> fedora-signed.efi boot path would work in both cases (fedora keys / microsoft keys enrolled). take care, Gerd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
On Tue, Dec 05, 2023 at 03:01:04PM -0600, Chris Adams wrote: > Once upon a time, Aoife Moloney said: > > * UKIs need this to find the root filesystem without root=... on the > > kernel command line. > > How does this work in system with more than one Linux install? Or any > more-complicated disk setup (e.g. SW RAID)? Does this also lock users > out from ALL kernel command-line options? Using UKIs is optional, if they don't work for your use case just continue using traditional kernels. Our main focus is virtualization use cases and cloud images, where you usually have a simple disk setup. Independent from that work is being done (mostly in systemd) to allow configure the command line for UKIs in a secure way. New in systemd v254 are addon images which can extend the command line. See "man systemd-stub" for details. take care, Gerd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Possible deprecation/removal of Initial Setup from Fedora
On Fri, Nov 24, 2023 at 01:38:27PM +0100, Jiri Konecny wrote: > Hi, > > I wonder, I thought that the server images are usually using Anaconda to > create a user during installation. Am I missing something? Well, if you boot the install.iso and go through an anaconda install, then yes, users are created as part of that. But that is not the only way to deploy servers, there are also ready-to-use qcow2 + raw images which you can just boot without going through the anaconda install process. take care, Gerd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Possible deprecation/removal of Initial Setup from Fedora
On Tue, Nov 21, 2023 at 08:07:06AM -0800, Davide Cavalca wrote: > On 2023-11-21 04:34, Jiri Konecny wrote: > > Is Anaconda Initial Setup important for your project or workflow? What > > functionality is absolutely necessary for you? Do you use the text > > mode or the graphical mode? Are you aware of any alternatives? Is > > there anything that would prevent you from migrating to one of the > > proposed alternatives? Also please feel free to share this mail to any > > relevant groups. > > The Fedora Asahi Remix uses initial-setup (in text mode) for our Server and > Minimal variants. I think this is used by *all* server images. It offers to set the root password and add users, so without that you simply can't login ... take care, Gerd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
> == Detailed Description == > As a first pass, the 'inst.sdboot' option already in anaconda should > work. As it stands, that replaces grub+shim with the systemd-boot > loader, and moves the kernel + initrd to the EFI system partition > (ESP). It doesn't attempt to create unified kernel images, so the > existing `dnf update`, `kdumpctl`, and `make install` in a kernel > source directory should all work. What is the plan for existing UKIs, for example kernel-uki-virt.rpm? I'd expect they should work fine without extra work (i.e. try a kickstart file with '-kernel' + '-kernel-core' + 'kernel-uki-virt' in the file list). [ Side node: Right now the kernel-uki-virt %postinstall just does a copy to /boot/efi/EFI/Linux where systemd-boot should find them just fine. After systemd v254 release we which brings some kernel-install improvements for UKIs we should be able to switch over to use kernel-install instead ]. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)
On Wed, May 31, 2023 at 03:32:09PM +0200, Vitaly Zaitsev via devel wrote: > On 31/05/2023 14:53, Jiri Vanek wrote: > > It is built from sources of course! > > What make you think it is not? > > For double ensurenes, see the fesco ticket in proposal. > > IMO, repackaging prebuilt RPM packages is not building from sources. The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't see how that violates the 'build from source' requirement. We do similar things in other cases, see for example shim-unsigned.rpm + shim.rpm take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: U-Boot for x86 BIOS systems
Hi, > But could we use U-Boot to fill in this gap so these systems still > work? We'd then treat x86 like ARM (if no UEFI, use U-Boot UEFI). How does u-boot handle EFI variables in that case? How does u-boot do storage access in that case? Go call BIOS INT13h? Or use its own device drivers? Last time I checked there have been a few gaps, no virtio-scsi driver for example. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
> > /boot/efi is clearly not ideal for a number of reasons, but this is what > > we have today and changing this opens up another can of worms. For > > starters this will stop working: > > > > # rpm -ql shim-x64 > > /boot/efi/EFI/BOOT/BOOTX64.EFI > > /boot/efi/EFI/BOOT/fbx64.efi > > /boot/efi/EFI/fedora/BOOTX64.CSV > > That's actually an anti-feature that needs to go. Packages should not > use rpm to put files directly in /boot. Systemd doesn't do this, the > kernel doesn't do this (except for %ghost files). grub2 does some > directories, but thankfully no files, Nope: # rpm -ql grub2-efi-x64 | grep EFI /boot/efi/EFI/fedora/grub.cfg /boot/efi/EFI/fedora/grubx64.efi Only systemd-boot gets this right today, with files packaged in /usr and bootctl updating the ESP. Oh, and fwupd handles it correctly too. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
Hi, > > And install kernels to /boot/efi in case /boot is not a XBOOTLDR > > filesystem? > > If /boot is not a XBOOTLDR, then we only have one file system which is > the ESP. It could be mounted on /boot or on /efi or maybe even /boot/efi (*). > The kernels would then go to /boot/EFI/Linux, /efi/EFI/Linux, or > /boot/efi/EFI/Linux, > respectively. (When you write /boot/efi, it's not clear what exactly you > mean. The duplication of "efi" and "EFI" on on case-insensitive system > is confusing.) I meant ESP mounted at /boot/efi (and therefore UKIs in /boot/efi/EFI/Linux). > (*) This is actually something that'd need to be figure out. > /boot/efi is the worst choice; either /boot or /efi would be OK, > but something needs to be chosen. /boot/efi is clearly not ideal for a number of reasons, but this is what we have today and changing this opens up another can of worms. For starters this will stop working: # rpm -ql shim-x64 /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/fbx64.efi /boot/efi/EFI/fedora/BOOTX64.CSV [ ... ] If we are going to change this the only option which makes sense to me is to go for the systemd default: ESP (if present) mounted at /efi, XBOOTLDR (if present) mounted at /boot. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
Hi, > If we want to change the default here, let's do some proper cleanup: > 1. the split between ESP and XBOOTLDR is only useful in the case where >ESP already existed and was small. If the installer is *creating* >an ESP, it should just make it large enough. And install kernels to /boot/efi in case /boot is not a XBOOTLDR filesystem? > 2. having a second partition with a second (different) file system >implementation just increases the footprint and attack surface for >no gain. If we create XBOOTLDR, make it like the ESP (i.e. VFAT >in almost all realistic scenarios). While being at it also give the XBOOTLDR the correct type uuid according to the discoverable partitions spec. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: mkosi-initrd (Self-Contained Change proposal)
Hi, > Would it be possible to build bootable images using mkosi-initrd in > koji? Then these could be booted in openQA directly and catch simple > regressions like unbootable images quite easily. You might want have a look at kernel-uki-virt.rpm, which ships an UKI you can boot directly (that is built using dracut not mkosi-initrd though). take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Porting Fedora for the LoongArch architecture.
On Wed, Jan 11, 2023 at 05:26:33PM +0800, Robin Lee wrote: > EDK2 support is also upstreamed but Fedora does not catch up. There is no cross compiler (yet) in Fedora so I can hardly build edk2 firmware binaries ... I expect that will change when the gcc-13 update lands in rawhide. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Thu, Jan 05, 2023 at 12:56:31AM -0800, Luya Tshimbalanga wrote: > An issue with the testing method from the proposal: secure boot prevents the > resulting unsigned unified kernel to boot. It is signed, but with the test key. You can get the x509 ca cert for that using: certutil -L -d /etc/pki/pesign-rh-test -n "Red Hat Test CA" -a After enrolling the cert the kernel should boot fine. Doing that on a non-test system is a bad idea though. The qemu test images (https://www.kraxel.org/fedora-uki/) come with a edk2 vars file which has secure boot enabled and the test key enrolled. > It will be great to obtain a > scratch-build from koji for users running with enabled secured boot. scratch builds would get a test key signature only too I think. HTH, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, > > While being at it: anaconda seems to explicitly call dracut to > > generate > > the initrd (according to the messages it prints). What is the reason > > for this? Shouldn't this already happen as part of the rpm > > transaction, > > when the kernel install scripts are running? > IIRC the main reason is the esentially random package installation > order during the RPM transaction. Current kernel.spec runs dracut in %posttrans, probably exactly to make sure it only runs after everything is actually installed. > One concrete issue this caused was that users would use specific > characters in their LUKS password, Anaconda would make sure the given > package containing the layout is installed, but it would come after the > kernel package in the transaction & the layout would be missing from > the initrd. As a result, the user would not be able to type their > password. Ok. > In any case, this situation is sub-optimal, as we currently run dracut > at least twice - once via the kernel RPM script trigger and then again > when Anaconda triggers it. We really need to finally reach out to the > kernel package maintainers and device some mechanism that tells the > kernel package to skip the dracut run during the installation. Hmm, that is somehow the wrong direction. IMHO we should fix package dependencies (assuming this is a problem still) to make sure the initrd is always generated correctly during package installation instead of having anaconda workaround broken dependencies. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: UEFI HTTP boot (was: Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal))
On Mon, Jan 02, 2023 at 04:06:29PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote: > [...] > > Note that uefi http boot can also work with iso images, i.e. you can > > have the dhcp server hand out URLs to the fedora netboot iso. The > > firmware will fetch the iso, create a ramdisk, add a acpi table for > > it so the OS finds it too, then go boot as it would be a physical > > cdrom all the way up to anaconda. > > That sounds very interesting. Could you describe how to set this up > and/or provide some links to documentation? On uefi http boot: https://www.redhat.com/sysadmin/uefi-http-boot-libvirt To boot iso images you essentially have to just replace http://server/path/binary.efi with http://server/path/netboot.iso HTH & take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote: > Hi all, > > > == Benefit to Fedora == > > * Better secure boot support (specifically the initrd is covered by > > the signature). > > * Better confidential computing support (measurements are much more > > useful if we know what hashes to expect for the initrd). > > * More robust boot process (generating the initrd on the installed > > system is fragile, root cause for kernel bugs reported is simply a > > broken initrd sometimes). > Just want to add Anaconda installation environment is also fighting with the > second point. Third point I assume, i.e. initrd generation problems being reported as anaconda bugs? While being at it: anaconda seems to explicitly call dracut to generate the initrd (according to the messages it prints). What is the reason for this? Shouldn't this already happen as part of the rpm transaction, when the kernel install scripts are running? > Thanks to the PXE boot it's maybe even more fragile > environment. Yep. I'd highly recommend to use uefi http boot whenever possible. Note that uefi http boot can also work with iso images, i.e. you can have the dhcp server hand out URLs to the fedora netboot iso. The firmware will fetch the iso, create a ramdisk, add a acpi table for it so the OS finds it too, then go boot as it would be a physical cdrom all the way up to anaconda. BTW: Having some way other than the kernel command line to pass config options to anaconda would make this much more useful. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Fri, Dec 23, 2022 at 09:01:52AM +0100, Vitaly Zaitsev via devel wrote: > I doubt that Fedora's shim+grub2 can boot Ubuntu kernels in Secure Boot mode > and vice versa. Needs installing the signing keys to the shim key database using mokutil, but should otherwise work just fine. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, > A much better approach is to install a TPM-generated key in the TPM’s > NVRAM, with a policy that only allows the key to be used once a trusted > operating system has booted. That can be used as a trust anchor even > without support from buggy UEFI firmware. Side note: measuring kernel + initrd happens using UEFI firmware services. (once the kernel is up'n'running it will use its own tpm drivers instead of depending on the firmware services). > Furthermore, measured boot allows tying e.g. LUKS keys to a > combination of the actual OS booted and a passphrase needed to unlock > the TPM. This allows the TPM’s protection against brute-force attacks > to be used. You also want protect the initrd against modifications to make sure an attacker can't sniff your passphrase. Unified kernels help here too because the initrd for a given kernel has a fixed and known hash. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Thu, Dec 22, 2022 at 02:49:37PM +, Daniel P. Berrangé wrote: > > There are at three ways that are used: 'dracut --uefi', systemd's ukify, > > and a > > manual objcopy invocation. The first two are wrappers around objcopy. I'm > > biased > > because I wrote 'ukify', but I think that's the way to go. What dracut does > > is > > somewhat primitive and doesn't get the offsets right. Obviously it could be > > improved, but putting the code to generate UKIs inside of an initrd > > generator is > > a historical accident, and bash is not the nicest language to do offset > > calculations. Thus I hope we can standarize on ukify instead. > > When you say it dooesn't get the offsets right, can you elaborate ? > We've been using dracut --uefi to build the UKIs in koji and they > appear to work as expected. Are the offsets only incorrect in > certain circumstances. When the kernel binary happens to be too big things break because the end of the kernel will overlap with the start of the initrd due to the fixed offsets used and thus the fixes space being available for the kernel binary (and the other things being added to the uki, except initrd which comes last). Which is not the case right now with fedora kernels, so everything works fine. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Thu, Dec 22, 2022 at 10:52:05AM -0500, Neal Gompa wrote: > On Thu, Dec 22, 2022 at 10:46 AM Lennart Poettering > wrote: > > > > BTW, you keep talking of "these" problems, and are extremely vague > > about those. I think I understood that you hit the NVRAM size limits > > before, by enrolling private certs? > > Yes. Physical hardware or virtual machines? For virtual machines: Fedora uses for historical reasons 2M builds of OVMF, which have not much NVRAM space. Alternative 4M builds which have much more space are available in /usr/share/edk2/ovmf-4m. Using these needs manual work right now, hashing out a plan to use these by default for new VMs without changing/breaking existing VMs is not (yet) done. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, > Hmm, the updated Change is mostly okay. I disagree that you have any > real security benefits since all the Secure Boot stuff in Linux is > still in a bad place. It's a step into the right direction, but I agree, it alone doesn't improve the situation much. I think we need to overthink the whole secure boot signing process in Fedora. For starters we need to use different signing keys for UKI and non-UKI kernels, so it is possible (for the user if he chooses so) to disable booting non-UKI kernels to really plug the unsigned initrd hole. shim project planning to move from compiled-in certificates to signed certificates in separate files should make it easier to manage this. But all that is probably worth a separate change proposal and a separate discussion. > I would like the Change document to be updated > to include feedback about Secure Boot in there to further justify how > restricted the scope will remain for Phase 1. > > Additionally, "discoverable partitions" fixes nothing for Fedora right > now. There are two problems here: > * We don't have a discoverable subvolume specification for Btrfs > * Discoverable partition specification falls over dead with snapshots. > > Don't plan on using systemd-boot. I've said why before in other > threads, so I'm not repeating it again. > > Drop locking out modified kernel command lines. That's pretty much a > non-starter. > > If you want to pursue a Fedora Cloud image with UKIs, please bring it > up with the Cloud SIG, keeping in mind the feedback I listed. Noted. I'll rework the Change proposal early next year, I'm almost off into my xmas holidays. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, > > If something is proposed for bare metal in the future, then raise > > the problems at that point. It is unreasonable to demand that we > > fix problems for a use case that is not in scope for what is being > > proposed. Anything related to bare metal was explicitly out of > > scope, precisely because it will massively increase the complexity > > of what needs to be addressed, making the task infeasible. We need > > an incremental path where we can tackle individual practical tasks > > rather than trying to solve everything in one go. > > Yeah, and what happens when it gets punted again when that happens? I > do not think it's unreasonable to bring these objections up front when > this is clearly marked as a "phase 1" Change that implies UKIs will be > used in more and more scenarios over time. I want UKIs becoming an option in more and more use cases. I don't expect non-UKIs disappearing anytime soon though. From the updated Change page: long term plan: Phase 1: Get the basic building blocks into place, so it is possible to work with and develop for UKIs in virtual machines. Phase 2+: Expand UKI support, tackling the use cases which depend on a host-specific initrd or command line (see below) one by one. Phase X: Once UKIs have feature parity with non-UKI kernels discuss whenever they should be used by default everywhere (specific use cases like cloud images might switch earlier). NOT planed: remove support for non-UKI kernels. I think at the end of the day this will be somewhat simliar to the Xorg -> Wayland transition. First get basic support there, so it is possible to try out stuff, figure what works, figure what needs changes etc. Then a (probably long) phase adapting software, fixing bugs found etc, making more more use cases being able to work with the new stuff. Then at some point eventually flip the default. One notable difference is that with UKIs there isn't something simliar to Xwayland, so flipping the default requires really everything being able to work with UKIs. And flipping the default can only happen for new installs, I don't think trying to migrate existing installs to UKIs automatically is a sane idea. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if > > the way Linux/shim/mokutil implement the cert db is done the way it is > > currently done. Well, UEFI *not* defining some standard way to enroll user certificates actually is part of the problem. It is one of reasons why shim+mokutil exist in the first place. > Frankly, I'm aggravated by the increased reliance on UEFI features > without fixing Linux's problems with UEFI features. If we stopped > relying on UEFI for the cert store, a lot of my issues would go away, > because then we can design better workflows for managing certificates. Ignoring the UEFI cert store is just not possible, that is the only one available and used initially. For booting the bootloader to have to work with the capabilities provided by the firmware. Doing something simliar for ppc would likewise depend on ppc-specific firmware features. Once shim is loaded both uefi and shim cert stores are available. Once the kernel is loaded that expands to uefi + shim + kernel. > It makes automation possible, it makes management possible, and it > opens the doors to experiment with how to do layered images for boot > (e.g. UKIs + system extension images) without bricking people's > computers. system extensions are verified after the kernel is loaded, so you are not limited to the uefi/shim cert stores for them. > That also has the side effect of us having half a chance of being able > to port this security capability to non-UEFI platforms where we use > fake UEFI implementations to bootstrap our boot process, because the > amount of coverage required for fake UEFI implementations is > considerably lower now. Yep. Because it's a standard. Having u-boot (assuming this is what you are referring to) provide standard UEFI protocols, then use standard efi boot process is much less work because there is only one piece in the boot process which needs to know the hardware specifics. Which is u-boot (playing the firmware role on many SBCs). > More generally, relying on UEFI-specific security features when most > platforms are not being brought up with UEFI is foolish. ARM is almost > entirely non-UEFI (except the tiny proportion of servers that almost > no one has) Any aarch64 server I boot in some cloud is UEFI. aarch64 virtual machines use UEFI. UEFI implementations exist for RPI 3+4. > and RISC-V is not a UEFI platform either. https://github.com/tianocore/edk2-platforms/tree/master/Platform/RISC-V/PlatformPkg > You *need* to think about these problems when designing this stuff. > You can't take a myopic x86-only view to this. I have not heard of > anything about UKI security for non-x86 because it seems to all be > tied up in UEFI stuff. Booting UKIs in BIOS mode works with a patched grub (needed for hybrid bios/uefi cloud images). Of course that doesn't improve security because the bios lacks the features needed for that. You can still get the other advantages UKIs have like a more robust kernel update process. ppc uses grub too, so being able to boot UKIs on ppc too should be doable without too much effort when the platform maintainers think it is useful. > > Nah. UKIs + sysext are ultimately something that is simpler and much > > better to test than the current mess. Yeah, for a while we'll have to > > add complexity because to mechanisms will have to be supported, but > > eventually things are going to be simple and easier to test. > > Maybe. It's not super intuitive from where I'm standing, and I know > how all this stuff works. Because today fedora doesn't use sysexts and doesn't provide much tooling. Ideally the packages which drop some dracut module to /usr/lib/dracut/modules.d/ today will also drop a sysext to the correct place in the future. No manual steps needed. Users don't even need to know how this works under the hood. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Wed, Dec 21, 2022 at 05:44:36PM +0100, Lennart Poettering wrote: > > I mean, sure, if you use the Fedora supplied vanilla signed UKI > without anything else then it won't boot from a network, because that > would be a security hole. But I see no reason why a network boot UKI > couldn't be build that maybe be booted via PXE and derives root fs > info from DHCP alone. I expect that is an area where we have to research how we want build stuff in the future. The UKI for virtual machines / cloud images is simple and static enough that we can just build that as part of the kernel build process. For other use cases that might not be the best approach though. Also note that UKIs can be booted without an bootloader. It's an EFI binary the firmware can handle on its own. That actually simplifies network booting, your dhcp server can hand out URLs to the UKI. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > Without an initrd we immediately have the following limitations: > > - all kernel modules needed to mount root must be compiled in > > - all that code is always loaded and remains in unswappable memory > > - root= syntax is limited to what the kernel understands, i.e. > > no root=UUID=… o root=/dev/disk/by-path/… or other udev links, > > no encryption or dm-verity. > > - no bluetooth keyboards or other fancy peripherals > > - recovery is pretty hard > > Also, the security lock-down for the kernel command line means: > - no network root filesystem > - no boot-time-only kernel/module configuration > > The idea of switching from grub2 to sd-boot would also drop network boot > and BIOS support. Supporting boot loaders seems to be a bit of a issue > sometimes, so trying to support multiple boot loaders seems like a bad > idea to me. The switch to BootLoaderSpec made switching boot loaders *much* easier. The actual boot loader config is fixed and never touched, kernel updates add/remove BLS config snippets, and all boot loaders handle that just fine. You can even have *two* bootloaders, sd-boot for efi mode and grub2 for bios mode. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Wed, Dec 21, 2022 at 12:53:05PM +0100, Vitaly Zaitsev via devel wrote: > On 21/12/2022 12:38, Daniel P. Berrangé wrote: > > Why shouldn't FAT be used for /boot. In an EFI world, /boot > > is used for the same functional pupose as the ESP, which is > > already going to use FAT. > > Doesn't support links, lournaling and ACLs. Is that something you need in /boot? And journaling actually is more a problem than a solution due to firmware (or grub) filesystem drivers often not having full support for the journal. Luckily this is rarely a problem in practice because /boot is rarely written to. > Everyone can do whatever they want with the files, Hmm? From the booted system: No, depends on the configuration and usually it's mounted to be only writable by root. When you plug the disk elsewhere: Yes, but all other filesystems have the same problem then. With physical access to the disk only encryption can prevent that. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, > But why start doing UKI without first fixing the need of host specific > initrd and commandline. We are trying to tackle that in parallel. At least when generating virtual machine images we can temporarily workaround that with short %post scripts in kickstart files. > I am sure even non-UEFI users will be better of of not having a host > specific initrd. We should first start working on shipping initrd on > dedora as an rpm with atleast one use which can be extended by sysext > or someother mechanism without the need of UKI first. We'll have to continue support kernel + host-generated initrd for the foreseeable future. UKIs are a second option. Adding kernel + shipped initrd as third option IMHO just adds complexity for no real benefit. > Once That is possible that UKI can be easily be intgrated and > tested. We will be also provide a subset of benefits to the non-UEFI > users(for example on other arches). We have experimental grub patches which can boot unified kernel on bios systems. Intended use case: hybrid bios/uefi cloud images with UKIs. Extending that to ppc is probably possible too should the ppc arch maintainers be interested. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote: > On Tue, 2022-12-20 at 20:42 +0100, Björn Persson wrote: > > I note that taking away the kernel command line is indeed a clearly > > stated goal, which will limit Fedora to simple, appliance-like uses. > > And if you chose your HW carefully you may even be able to register > your own public keys, generate and sign your own built UKIs and re- > enable SecureBoot after that... your choice! And when your hardware doesn't allow that you can still add your own keys with mokutil so shim.efi will accept your self-signed UKIs. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote: > > Main motivation for this move is to make the distro more robust and more > > secure. > > Improving security would be great, but it must be done in a way that > allows the sysadmin to configure and repair the system and authorize > the new configuration. > > > Switching the whole distro over to unified kernels quickly is not > > realistic though. Too many features are depending on the current > > workflow with a host-specific initrd (and host-specific kernel command > > line), which is fundamentally incompatible with unified kernels where > > everybody will have the same initrd and command line. Thats why there > > is 'Phase 1' in title, so we can have more Phases in future releases > > 😃 > > Whew! So usable kernels won't go away in F38. I only have to worry > about being forced to build my own kernels in some unspecified future > phase. Doom is still coming but no one knows when. That's *such* a > relief. Note the proposal talks about adding support for ukis, not about removing support for current separate kernel+initrd setup. It surely is the goal to incrementally improve uki support to cover more use cases. I expect it will take quite some time to have ukis reach feature parity, and only then it makes sense to start thinking/discussing about eventually dropping support for non-uki kernels. Which may very well never happen, for starters switching existing installs automatically is a rather hard problem because the local generated initrd may have unknown customizations. > > A host-specific initrd / command line is needed today for: > [...] > > * configuration being specified on the kernel command line. > > ** root filesystem being the most important one. > > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > > allow to remove this. > > Why link to a page that only contains a link to another page? Why not > link directly to > https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Oh, it moved. Didn't notice that yet, will update the link. > > Phase 2/3 goals (longer-term stuff which is not realistic to complete for > > F38). > > > > * Move away from using the kernel command line for configuration. > > I note that taking away the kernel command line is indeed a clearly > stated goal, which will limit Fedora to simple, appliance-like uses. Ok, looks like I should clarify that. I want fedora not depend on the kernel command line for configuration, so a unified kernel with the compiled-in default command line boots the system fine without needing any customization. If you want change the command line you surely can do that (assuming secure boot is disabled, otherwise systemd-stub ignores the command line). take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, > * Enhance parted/libparted to support arbitrary GUIDs and enhance blivet to > understand the full listing of GUIDs? Or parted is done, blivet still todo. https://bugzilla.redhat.com/show_bug.cgi?id=1075288#c7 > the CLI tool seems not to support it but maybe fdisk does. sfdisk supports it. The workaround mentioned in the change page looks like this: # setup discoverable partitions /usr/sbin/sfdisk --part-type /dev/sda 3 4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 # Linux root (x86-64) > > * Add proper systemd-boot support to installers. > > Great. The gotcha though is this in effect requires a change in the > file system currently mounted at /boot, which is ext4. And ext4 isn't > supported by sd-boot or UEFI firmware. So if you're going to support > sd-boot, the installer needs to be aware that either the ESP is big > enough to be used as /boot, or if it's not big enough then it will be > mounted on /efi *and* a new partition XBOOTLDR formatted as FAT will > be used as /boot. Well, for the virtual machine use case isn't a problem, you can just make the ESP big enough and even drop the separate /boot filesystem then. For the general case we need some other option. Could be just stick to grub2 for those cases (we'll continue to need grub2 anyway for bios boot and ppc64le). Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers, for example this one: https://github.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg > > * Better secure boot support (specifically the initrd is covered by > > the signature). > > We need to solve the glaring hole that is the initrd. There's no > question about it. I can't really assess if this feature is the best > way to do that. Or if it would be adequate for dracut to self-sign > every locally generated initrd with a unique key pair and throw away > the private key after each initrd is generated. The private key management problem unfortunately isn't solved that easily ... When using distro signatures you don't have the key management problem in the first place. > Or if we could do enough strict standardization in the boot chain with > a possibly larger kernel to avoid needing an initrd, i.e. get to > sysroot mount faster thereby obviating the need for a large initrd. The initrd does more than carrying drivers. Finding the root filesystem for example. The kernel's builtin feaure set for root= is small compared to what a dracut initrd is able to do. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Wed, Dec 21, 2022 at 03:06:26AM +0100, Kevin Kofler via devel wrote: > Daniel P. Berrangé wrote: > > That is not correct. There are a number of benefits of UKIs. > > > > The most critical is that the initrd content and cmdline is > > covered by the SecureBoot signature. > > From an end user point of view, having more stuff covered by Restricted Boot > is not a benefit. It's an option for those who care. If you don't just turn off secure boot. Nobody forces anything on users. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, > I think UKIs are fundamentally flawed and are an idea that came out of > a group that doesn't really interact with real users enough to > understand how much of a problem they actually are. I realize that > this Change is only about VMs, but since it explicitly talks about it > being "phase 1", the implication is that future Changes are coming to > switch fully over. Consequently, I'm going to provide much more > holistic feedback instead of just nitpicking on this case. That is correct, although I expect we'll support both ukis and traditional initrds in parallel for quite a while and the day where all use cases can be handled with ukis is far away. Too many use cases depend on todays host-generated initrd workflow. > In the Fedora case, things are simpler right up until we hit graphics > drivers. This is also a problem for VMs too, because GPU passthrough > is a common case for scientific and gaming workloads. As long as the > NVIDIA driver remains dominant in Linux, UKIs cannot work because by > design you cannot load anything that isn't part of the kernel image. > For bare metal, we *need* these drivers in early boot, though. No. The graphics drivers don't need be part of the initrd. Booting on vgacon or efifb until the root filesystem is mounted and drivers can be loaded from there works just fine. > And that's another problem: no third-party early boot drivers. Even if > you solve the signing issue, you need to introduce some kind of > two-stage OS boot process so we can bring up the bare minimum to load > a second image containing all the remaining drivers. And at that > point, you've defeated the purpose of UKIs. I've heard from some > people that system extensions (sysexts) would be a way to solve this, > and maybe it is. Yes, that problem is not solved yet. And, yes, sysexts are the IMHO most promising option to handle that. I suspect using them requires putting dracut upside down or replace dracut with something else, so I expect that will take a while to sort out (disclaimer: I don't have much insight into the inner workings of dracut). > But again, we've eliminated the value of UKIs by doing so. No. sysexts can be signed. > Speaking more broadly, there are also problems that will be introduced > as this trickles down from Fedora into prominent downstreams (assuming > this is accepted). In the RHEL case, you've basically broken driver > disks completely. Hmm? A driver disk could provide a sysext ... > The crux of the problem here is *signing*. All of this is tied up in > Secure Boot and TPM, which is the wrong place to actually handle this. sysext signatures are independent from secure boot. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi, > With my FESCo hat on, I immediately have the following comment: > please narrow down the scope to things that we can actually approve > for F38. E.g. the parts related to replacing grub2 by sd-boot > are IMHO not realistic for F38 (*). sd-boot actually replacing grub2 in anaconda installs or cloud images: Yes, that is unrealistic. Building images which use sd-boot with a custom kickstart file (doing 'bootctl install' in %post): That works already. > And if we use grub2, then also the > pre-calculation of TPM PCR values is not realistic, since they are > too volatile with grub2... I think that those are all very interesting > research tangents, but the stuff that gets a stamp of approval as a > Fedora Change needs to be down-to-earth and users-know-what-to-expect > and > you-can-pretty-much-figure-out-how-things-will-look-from-the-change-description. Suggestions how to deal with those best? The reason this stuff is in there is that I want also outline the longer-term goal behind this. I could create a "Phase 2" change page and move over stuff ... thanks & take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
> > == Detailed Description == > > The goal is to move away from initrd images being generated on the > > installed machine. They are generated while building the kernel > > package instead, then shipped as part of a unified kernel image. > > > > A unified kernel image is an all-in-one efi binary containing kernel, > > initrd, cmdline and signature. The secure boot signature covers > > everything, specifically the initrd is included which is not the case > > when the initrd gets loaded as separate file from /boot. > > What platforms are going to be affected? Is it x86-64 only or does it > include aarch64 (as it's also using UEFI)? x86_64 is the primary target. aarch64 possibly too. Secure boot isn't a factor there so it's less important, but having a more robust initrd build and kernel update process is nice to have ... > Are ppc64le and s390x out of the current scope? Yes. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Thu, Dec 08, 2022 at 11:49:16AM -0800, Adam Williamson wrote: > On Thu, 2022-12-08 at 20:23 +0100, drago01 wrote: > > The problem I see here is not the presence of the firmware on the > > image, > > but the fact that it seems to be loaded into memory despite not being > > used. > > This is the direction Daniel was thinking down. I'm waiting for someone > with more expertise to reply, but I suspect the reply is going to be > along the lines of "yes, we *can* do that, but it's somewhat tricky > work that involves thinking about lots of paths that aren't obvious, > and somebody would need to dedicate their time to working on that". Split install.img into install.img + firmware.img? I think we already have support for multiple images (I see requests for updates.img when watching httpd logs while doing network installs), so the split should be easy. The somewhat more tricky part is probably to figure whenever we need the firmware or not. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Grub menu with 3 kernels by default
Hi, > > Thus any attempt to validate the the grub.conf PCR eventlog, as it > > exists in typical distro deployments today, is going to be both > > complex and fragile, which is a bad combination. > > But this is only a problem if you're assuming grub2-mkconfig is > nondeterministic, which just isn't the case. I'll grant that the event > log isn't terse, but what's valid isn't be hard to precompute. It might be workable on the installed system, by running grub.cfg through grub shell or something like that. But even that has its challenges, see below. It's next to impossible for a third party though. > On generally identical systems, what will differ is uuids and > partition numbers... Would be nice if it would be that simple. Unfortunately it is not. For starters naming grub.cfg "configuration" is wrong. It's a script language. So grub2 does not measure the configuration, it measures the control flow. Now several features are implemented using the grub script language. Selecting the next kernel to boot via grub2-reboot for example. Also boot counting. So the control flow can be different from boot to boot, depending on how the kernel was picked and what value the boot counter has, leading to different measurements. Also the same config file can lead to different measurements with different grub versions, when the menu entries generated by blscfg change. > Glibly, if you don't want a config change, don't run grub2-mkconfig :) > We don't run mkconfig on the system after install because it doesn't > change - it only get run to change something. So installed systems can have different config files. When the default grub config changes a Fedora N install upgraded to Fedora N+1 will differ from a fresh Fedora N+1 install. > And if you update configuration, you'd want to know that things > changed - that's the whole point of logging it. Depends. Some things clearly matter (root uuid, ...). Some things not so much (menu timeout, menu hidden/shown, ...). take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Dev] Check out the Fedora Packager Dashboard!
Hi, > With various filtering options. Is it also possible to sort packages? For example to have my own packages listed first and any group packages later? take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: future of dual booting Windows and Fedora, redux
Hi, > But they also say this: > > | The default state of Secure Boot has a wide circle of trust which can > | result in customers trusting boot components they may not need. Since > | the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for > | all Linux distributions, trusting the Microsoft 3rd Party UEFI CA > | signature in the UEFI database increase[]s the attack surface of > | systems. A customer who intended to only trust and boot a single Linux > | distribution will trust all distributions–much more than their desired > | configuration. > > And this is an accurate description of the situation. Yea. And on top of that there is no standard way to manage secure boot keys. Try to kick out the microsoft windows signing keys because you don't trust the windows boot loader and want use linux anyway. You can go into the efi setup and with luck you find options to manage keys. But some standard way for a OS to request that and the firmware asking the user on next boot to ack or nack that action is just not there. Same for adding linux distro keys. This is why we ended up with shim + mokutil in the first place ... > The second stage boot loader > can have a long-term distribution-specific key embedded in it and is > also supposed to be minimal, so that distribution upgrades do not > require re-enrollment of the per-distribution boot loader. I'd love to have the distro CA cert on iso images and ESP, preferably in some standard location. Then people have at least the chance to easily enroll the distro keys (assuming the firmware setup offers that). For virtual machines we could even do that automatically. RHEL can actually be be booted with only distro keys enrolled, even though it requires inconvenient manual configuration due to having two shim.efi binaries with one signature each instead of one binary with two signatures. Fedora secure boot signing is rather messy though. Booting without microsoft cert doesn't work: https://bugzilla.redhat.com/show_bug.cgi?id=2108083 And the fedora distro secure boot certificate is broken: https://bugzilla.redhat.com/show_bug.cgi?id=2107982 take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Suggestion: Use a unified kernel image by default in the future.
On Tue, Jul 19, 2022 at 11:02:32AM -0400, Colin Walters wrote: > > > On Tue, Jul 19, 2022, at 10:15 AM, Gerd Hoffmann wrote: > > > > That is the big if. If you have the initrds. > > > > I've hacked up the kernel rpm to also build a initrd (targeting virtual > > machines for starters) and shipping that as (optional) sub-rpm ... > > FWIW, every rpm-ostree based system defaults to shipping a server side > generated initramfs today. Noticed that (and I guess this is the reason for dracut scripts already checking whenever /lib/modules/$version/initrd exists). Where does that build happen? Must be outside the kernel rpm build process, so probably when generating the ostree? Any plans for switching to unified kernel images, to have the initrd covered by secure boot signing? take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mon, Jul 18, 2022 at 05:03:53PM +0200, Lennart Poettering wrote: > On Mo, 18.07.22 14:52, Gerd Hoffmann (kra...@redhat.com) wrote: > > > Problem with measuring the initrd is that we don't have fixed hashes for > > a given kernel version (due to generating the initrd on the installed > > system). > > The very newest kernels measure all initrds on their own into PCR 9 > these days. It should be the only thing measured into PCR 9, hence you > can pre-calculate what you are going to see in the PCR easily if you > have the initrds. That is the big if. If you have the initrds. I've hacked up the kernel rpm to also build a initrd (targeting virtual machines for starters) and shipping that as (optional) sub-rpm ... https://src.fedoraproject.org/fork/kraxel/rpms/kernel/commits/initrd (proof-of-concept local builds only so far, probably needs fixes for build dependencies to actually work in koji). ... exactly to address that. Known initrd with known hashes, to allow pre-calculating the PCR values. > at build time (or at install time in case of dynamic initrds), without At build time is much better IMHO. It's more robust. It's easier to manage. The PCR values are useful for third parties (for example remote attestation services) because all machines with a given kernel version run the same initrd. > Moreover, this allows us to implemented TPM policies that bind to > signatures of PCR hashes, instead of the literal hash values. That > makes the measurements a *million* times more useful, since we loose > the brittleness on updates: if the expected PCR values can be > pre-calculated by the vendor, and then be signed, then an update won't > invalidate the policies anymore. Another case which requires creating initrds at build time. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Fri, Jul 15, 2022 at 10:33:03AM -, Francois Rigault wrote:
> Another idea is to measure the initrd and the boot configuration, for
> example taking a hash of the grub configuration and initrd and
> extending a PCR register.
That is already happening.
Problem with measuring the initrd is that we don't have fixed hashes for
a given kernel version (due to generating the initrd on the installed
system).
Problem with grub config measurements is that grub measures every config
file line it processes, which is quite messy:
root@fedora ~# tpm2 eventlog /sys/kernel/security/tpm0/binary_bios_measurements
| grep grub_cmd
grub_cmd: search --no-floppy --fs-uuid --set=dev
5cc83bf9-c040-42d9-819e-99a16462d518
grub_cmd: set prefix=(hd0,gpt2)/grub2
grub_cmd: export (hd0,gpt2)/grub2
grub_cmd: configfile (hd0,gpt2)/grub2/grub.cfg
grub_cmd: set pager=1
grub_cmd: [ -f (hd0,gpt2)/grub2/grubenv ]
grub_cmd: load_env -f (hd0,gpt2)/grub2/grubenv
grub_cmd: [ ]
grub_cmd: set
default=47c4701d41c0470992ce27741da89d4a-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64
grub_cmd: [ xy = xy ]
grub_cmd: menuentry_id_option=--id
grub_cmd: export menuentry_id_option
grub_cmd: [ ]
grub_cmd: serial --speed=115200
grub_cmd: terminal_input serial console
grub_cmd: terminal_output serial console
grub_cmd: [ xy = xy ]
grub_cmd: set timeout_style=menu
grub_cmd: set timeout=5
grub_cmd: [ -f (hd0,gpt2)/grub2/user.cfg ]
grub_cmd: insmod increment
grub_cmd: [ -n -a 1 = 0 ]
grub_cmd: insmod part_gpt
grub_cmd: insmod xfs
grub_cmd: set root=hd0,gpt2
grub_cmd: [ xy = xy ]
grub_cmd: search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
5cc83bf9-c040-42d9-819e-99a16462d518
grub_cmd: insmod part_gpt
grub_cmd: insmod fat
grub_cmd: set boot=hd0,gpt1
grub_cmd: [ xy = xy ]
grub_cmd: search --no-floppy --fs-uuid --set=boot --hint-bios=hd0,gpt1
--hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 8C55-9DE2
grub_cmd: [ -z ]
grub_cmd: set kernelopts=root=UUID=cb3e8fe8-2e6c-4f12-bd3b-f76fc1448bd8
ro rootflags=subvol=root console=ttyS0,115200
grub_cmd: insmod blscfg
grub_cmd: blscfg
grub_cmd: [ 1 = 1 -o 0 = 1 ]
grub_cmd: set menu_hide_ok=1
grub_cmd: [ 1 = 1 ]
grub_cmd: set boot_indeterminate=0
grub_cmd: set boot_success=0
grub_cmd: save_env boot_success boot_indeterminate
grub_cmd: [ xy = xy ]
grub_cmd: [ ]
grub_cmd: [ efi = efi ]
grub_cmd: menuentry UEFI Firmware Settings --id uefi-firmware {
grub_cmd: [ -f (hd0,gpt2)/grub2/custom.cfg ]
grub_cmd: source (hd0,gpt2)/grub2/custom.cfg
grub_cmd: [ efi = efi ]
grub_cmd: menuentry systemd boot loader {
grub_cmd: load_video
grub_cmd: [ xy = xy ]
grub_cmd: insmod all_video
grub_cmd: set gfxpayload=keep
grub_cmd: insmod gzio
grub_cmd: linux
(hd0,gpt2)/vmlinuz-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64
root=UUID=cb3e8fe8-2e6c-4f12-bd3b-f76fc1448bd8 ro rootflags=subvol=root
console=ttyS0,115200
grub_cmd: initrd
(hd0,gpt2)/initramfs-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64.img
root@fedora ~#
take care,
Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Wed, Jul 06, 2022 at 05:12:20PM +0200, Lennart Poettering wrote: > On Mi, 06.07.22 16:13, Gerd Hoffmann (kra...@redhat.com) wrote: > > > grub2 doesn't find it. Support not implemented? > > afics grub2 upstream has no native support for boot loader spec > stuff. (or has that changed?) Nope. Which is a PITA when you want hack something in upstream grub because it wouldn't boot fedora without hacks. > The fedora version of grub2 implements a flavour of type #1 boot loader spec > entries (i.e. .conf entries), but not type #2 (i.e. unified kernels), iirc. Suspected that. > > systemd-boot doesn't find it either. Double-checking. ESP mounted at > > /boot/efi. Directory looks fine to me: > > > > root@fedora ~/mkosi-initrd (main)# ll /boot/efi/EFI/Linux > > total 77832 > > -rwx--. 1 root root 79698816 Jul 6 15:36 > > unified-5.18.9-200.fc36.x86_64.efi > > > > Any clues? > > I am not a grub guy, haven't used it in a long time. But my educated > guess is this: I think grub might load the chainloaded binary into > memory itself, and then execute it from there, instead of invoking it > directly from the ESP file system. This matters because if sd-boot is > invoked from a synthetic file in memory we cannot derive the directory > tree of the ESP from it, and thus not find boot loader entries. Adding a boot entry to the firmware to load sd-boot directly and take grub out of the chain doesn't change the situation. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
>
> Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like
> being at proof-of-concept state. mkosi going fetch stuff from the
> internet to generate the initrd is clearly a non-starter (maybe not that
> much of a problem when doing it in koji where the next fedora repo is
> only one network hop away).
A few experiments later. Using 'mkosi --use-host-repositories' greatly
improves the situation. mkosi picks up the local repo config then and
fetches stuff from my local mirror.
Going build unified kernel image (using 'man systemd-stub'
instructions):
# build unified kernel
echo "Unified Linux Kernel ${KVER}" > os-release
objcopy --add-section .osrel=os-release \
--add-section .cmdline=/proc/cmdline \
--add-section .linux=/boot/vmlinuz-${KVER} \
--add-section .initrd=initrd_${KVER}.cpio.zstd \
\
--change-section-vma .osrel=0x2 \
--change-section-vma .cmdline=0x3 \
--change-section-vma .linux=0x200 \
--change-section-vma .initrd=0x300 \
\
/usr/lib/systemd/boot/efi/linuxx64.efi.stub \
/boot/efi/EFI/Linux/unified-${KVER}.efi
Booting that directly from the ovmf firmware menu works fine.
Progress!
grub2 doesn't find it. Support not implemented?
Ok, lets try systemd-boot instead. Install.
Chainload from grub for now:
root@fedora ~/mkosi-initrd (main)# cat /boot/grub2/custom.cfg
if [ "$grub_platform" = "efi" ]; then
menuentry 'systemd boot loader' {
chainloader (hd0,gpt1)/efi/systemd/systemd-bootx64.efi
}
fi
systemd-boot doesn't find it either. Double-checking. ESP mounted at
/boot/efi. Directory looks fine to me:
root@fedora ~/mkosi-initrd (main)# ll /boot/efi/EFI/Linux
total 77832
-rwx--. 1 root root 79698816 Jul 6 15:36 unified-5.18.9-200.fc36.x86_64.efi
Any clues?
thanks,
Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mon, Jul 04, 2022 at 07:20:32PM -, Sharpened Blade via devel wrote: > With virtual machines, nothing can actually be verified completely, > the host running the vm can, 1) Modify the firmware to intercept > anything the attacker wants, or 2) directly intercept things at the > cpu level. With SEV-SNP (amd) or TDX (intel) cpu extensions you can avoid that. You get launch measurement: Basically the cpu calculates a hash of the initial VM state and this can be verified later to make sure the system actually runs the firmware you want it run. The host also is not allowed to modify (or even see) guest state. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mon, Jul 04, 2022 at 07:24:28PM -, Sharpened Blade via devel wrote: > > My expectation would be that by default we'd just use the GPT auto > discovery stuff > > Existing Fedora installations do not follow the GPT auto discovery > spec. Also, I think the existing system for the root device can still > work, it is passed in the command line, not the initrd. command line is only slightly better than being baked into the initrd when it comes to using the TPM. The command line gets measured, so when each machine needs its individual root=UUID= each machine has a different PCR value ... root=LABEL= is slightly better because it's the same for all machines, but labels are collected from all disks which are present on the system whereas auto discovery looks only at the disk the system booted from. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Mon, Jul 04, 2022 at 10:25:05PM +0100, Richard W.M. Jones wrote: > On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf > > > > Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like > > being at proof-of-concept state. mkosi going fetch stuff from the > > internet to generate the initrd is clearly a non-starter (maybe not that > > much of a problem when doing it in koji where the next fedora repo is > > only one network hop away). > > supermin has solved this problem for over a decade. Can supermin replace dracut? take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Hi, > > > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf > > we tried to make rh image builder people inetreested in that, but they > weren't interested in that at all. For initrd building or for cloud image building? > > I don't think mkosi is a hard requirement for unified kernel images > > though. > > No, it's not. mkosi is just a python script gluing all the dnf, > gpt, fdisk, verity, signing stuff together. You can reimplement that. > > > Once the local configuration issues are solved it should be > > possible to run "dracut --no-hostonly" in koji + ship results instead > > of doing it on the installed host, no? > > We want to build initrds from RPM, to make the reasonably reproducible > and follow proper deps. It's a major facet of the project. magic build > scripts trying to magically determine deps from ELF and config and > whatnot is kind what we want to get away from. Sure, that totally makes sense longer-term. But I'm also trying to figure how far we can get without putting the initrd build process upside-down. Something along the lines of an (for starters optional) kernel-initrd subpackage with a "dracut --no-hostonly" generated initrd in it. When that is present on the installed system just use it instead of running dracut to build one. > But why not just fix the cloud images to just use descriptive type > uuids? that has no drawbacks, just benefits. Yea, need to figure how to do that. I guess step #1 is getting anaconda or blivet or whatever other tool anaconda uses for partitioning fixed. And I also guess it'll take a while given we have a 7 year old bug asking for that ... take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Hi,
> https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like
being at proof-of-concept state. mkosi going fetch stuff from the
internet to generate the initrd is clearly a non-starter (maybe not that
much of a problem when doing it in koji where the next fedora repo is
only one network hop away).
I don't think mkosi is a hard requirement for unified kernel images
though. Once the local configuration issues are solved it should be
possible to run "dracut --no-hostonly" in koji + ship results instead
of doing it on the installed host, no?
> An alternative is to use the systemd credential logic for this (this
> stuff: https://systemd.io/CREDENTIALS/). It allows encrypting and
> signing small blobs of info (so called "credentials") with the local
> TPM. They can then safely be stored on an untrusted medium (such as a
> ESP/boot partition), and are verified/decrypted on access. The
> "systemd-stub" EFI stub can automatically pick up such encrypted
> credentials from the ESP too, similar to the extension initrd images
> mentioned earlier in this thread.
("man systemd-stub" has details on the efi stub btw).
> The credentials logic can also be used to for example pass a root pw
> for the initrd in a safe way.
Does systemd-cryptenroll use this?
When getting the credentials for the encrypted root filesystem (or
something else) from somewhere else, i.e. some attestation server such
as https://keylime.dev/, how could that be integrated with systemd-creds
best? Simply have the agent write to /run/credentials?
> My expectation would be that by default we'd just use the GPT auto
> discovery stuff and for "pet" systems maybe also encode the root
> device with a credntial, but for "cattle" systems not bother.
Yep.
Is there some fallback mechanism btw? Most cloud images have just four
partitions: bios-boot, efi esp, boot and root. And the root filesystem
is simply the largest partition ...
take care,
Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
Hi, > We have been working on building tools and filling gaps to make that > workable reasonably in systemd upstream, and with a focus on > Fedora. The difficulty is in both being able to prebuild everything > but also keeping things somewhat modular and parameterizable. Because > right now those are the primary reasons initrds are built on the > installed host instead of Fedora: they contain local configuration and > drivers. If we prebuild everything we must have model to > replace these parts, without compromising security, and that's not > rivial. Is all this this discussed somewhere in public? systemd-devel list maybe? For virtual machines we need some way to make sure they actually run the software we want them run, and it seems the options we have are: (1) finally plug that initrd hole, or (2) use encrypted /boot ... where (2) feels more like a workaround for the unsigned initrd problem and it also opens another can of worms like requiring luks support in the boot loader. I guess you already have a list of the "local configuration" bits which must be tackled? Obvious #1 is finding the root filesystem. Should be solvable with discoverable partitions. A few days back I've found a 7 (!) year old bug[1] of yours truly asking to support that in anaconda, still in NEW state :( take care, Gerd [1] https://bugzilla.redhat.com/show_bug.cgi?id=1075288 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Fri, Jul 01, 2022 at 08:30:21AM +0200, Gerd Hoffmann wrote: > On Fri, Jul 01, 2022 at 06:39:41AM +1000, David Airlie wrote: > > I do wonder if it's possible to use multiple initrds, and maybe have > > the firmware in a separate initrd shared between all installed kernels > > if we go down this route. > > grub supports multiple initrds just fine. According to > https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub > supports multiple initrd files also with bls. That seems to be a > derivation from the original boot loader spec though, so not sure this > works with systemd-boot too. > > When going for multiple initrds the best approach is probably to simply > split out the kernel modules into a version-specific initrd and store > everything else in another, shared initrd. That doesn't help much though if we want have a unified kernel image (aka single efi binary with kernel + initrd) to get the initrd signed that way. Hmm. Are there any existing approaches to sign initrds? grub seems to support detached gpg signatures. Doesn't look that attractive given that the whole secure boot process uses x509 instead so using gpg would require maintaining yet another key ... take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Fri, Jul 01, 2022 at 06:39:41AM +1000, David Airlie wrote: > On Mon, Jun 27, 2022 at 6:33 PM Gerd Hoffmann wrote: > > > > On Sun, Jun 19, 2022 at 08:54:51PM -, Sharpened Blade via devel wrote: > > > Use unified kernel images by default for new releases. This can allow > > > for the local installation to sign the kernel and the initrd, so the > > > boot chain can be verified until after the uefi. Currently, the initrd > > > can be modified by attackers, so even if the / partition is encrypted, > > > the systems data can be read on the next boot. If the kernel image, > > > which includes the command line, and the initrd, is signed then it is > > > harder to comprimise the system. The system can still be comprimised > > > if the uefi is modified. > > > > > > If this was used, then the kernel could no longer be signed in the > > > package by the fedora infrastructure. > > > > I'd rather have fedora ship a unified + signed kernel image with a > > generic (aka 'dracut --no-hostonly') initrd instead of generating one > > on the local system. > > I think the issue with this is the initrd side blows out a lot, you > include all the firmware for all the modules in the system and then > you have 3 of them in /boot. > > I do wonder if it's possible to use multiple initrds, and maybe have > the firmware in a separate initrd shared between all installed kernels > if we go down this route. grub supports multiple initrds just fine. According to https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub supports multiple initrd files also with bls. That seems to be a derivation from the original boot loader spec though, so not sure this works with systemd-boot too. When going for multiple initrds the best approach is probably to simply split out the kernel modules into a version-specific initrd and store everything else in another, shared initrd. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Suggestion: Use a unified kernel image by default in the future.
On Sun, Jun 19, 2022 at 08:54:51PM -, Sharpened Blade via devel wrote: > Use unified kernel images by default for new releases. This can allow > for the local installation to sign the kernel and the initrd, so the > boot chain can be verified until after the uefi. Currently, the initrd > can be modified by attackers, so even if the / partition is encrypted, > the systems data can be read on the next boot. If the kernel image, > which includes the command line, and the initrd, is signed then it is > harder to comprimise the system. The system can still be comprimised > if the uefi is modified. > > If this was used, then the kernel could no longer be signed in the > package by the fedora infrastructure. I'd rather have fedora ship a unified + signed kernel image with a generic (aka 'dracut --no-hostonly') initrd instead of generating one on the local system. That'll avoid all the hassle of local signing, key management and the private key being an attractive target for attackers. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> == Benefit to Fedora == > This simplifies our default code path by using the same partitioning > scheme as UEFI systems and aligns us more to how Fedora variants that > are delivered as disk images, which all use a similar setup. It also > paves the way to implement hybrid BIOS+UEFI boot for legacy BIOS > installs to enable future conversion to UEFI boot or emulated UEFI > boot on legacy BIOS. Any reasons to not go straight to a hybrid BIOS+UEFI setup? As far I know anaconda already has support for that as it is needed to build cloud images, so it probably isn't that difficuilt. Additional benefit: It is possible to switch between BIOS and UEFI mode without reinstall. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Wed, Apr 06, 2022 at 12:19:40PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 05 April 2022 at 16:52, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS > > > > == Summary == > > Make UEFI a hardware requirement for new Fedora installations on > > platforms that support it (x86_64). Legacy BIOS support is not > > removed, but new non-UEFI installation is not supported on those > > platforms. This is a first step toward eventually removing legacy > > BIOS support entirely. > > How is making new installs (and thus re-installs) not removing support > entirely? The summary is misleading. It also opens up the question how we'll go QA bios support when you can't install F37 in bios mode. IMHO we should either drop support for BIOS, or continue full support for BIOS (including installs). Claiming BIOS still being supported while you can't install the system in BIOS mode is bullshit IMHO. I fully expect we will actually drop BIOS support at some point, the world is clearly shifting towards UEFI. Targeting F37 feels a bit over-eager though. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Hi, > On the cloud side, it's been very difficult to articulate any benefits > for supporting UEFI when the majority of the consumers of Fedora Cloud > don't have any pressing need to do it and things like hibernation and > snapshotting are non-functional. Last year, I changed Fedora Cloud to > hybrid boot[6] so that our image artifacts support both boot modes. Any chance for regular anaconda installs doing a hybrid boot setup too? The installed systems will look pretty much the same (gpt with both bios-boot and efi-esp partition) no matter how they where installed, and it'll be trivial to switch from BIOS to UEFI without reinstalling the system. We can fade out some stuff already (mbr support), and painless switching to UEFI for systems which where installed in BIOS mode for whatever reason should also help UEFI adaption. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FESCo wants to know what you use i686 packages for
Hi, > > +1 on cross-compilation. Native compilation on 32-bit is a dead end. > > Cross-compilation isn't really practical for RPMs the way we do things > now. We would have to go all-in the way OpenSUSE has done, but that's > a huge change. cross builds is a thing for kernel and firmware though and will continue to be. Those are freestanding though and don't need much beyond cross-gcc and cross-binutils (and in i686 case not even that, -m32 will do). take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'
Hi, > > However edk2 has other problems revealed probably by GCC 12, see: > > https://kojipkgs.fedoraproject.org//work/tasks/4195/81484195/build.log > > A valid warning, perhaps slightly overzealous depending on how Error is > defined: > > GenSec.c:1065:5: error: pointer used after 'fclose' [-Werror=use-after-free] > 1065 | Error(NULL, 0, 4001, "Resource", "memory cannot be allocated of > %s", InFileHandle); > | > ^~~ > GenSec.c:1064:5: note: call to 'fclose' here > 1064 | fclose (InFileHandle); > | ^ > > But it seems more likely that the bug is real. Maybe that %s should be %p, > or the function call is bogus in some other way. Yep, it is. > > openbios has a segfault somewhere during the FORTH bootstrap: > > https://kojipkgs.fedoraproject.org//work/tasks/6090/81556090/build.log > > I was not able to reproduce this one locally. > > I would try reproducing with -O0 first. It might be a dup of the QEMU bug > https://gcc.gnu.org/PR104067, even. It's a problem with loop optimizations, > so it could be the kind of thing that can wreak havoc on a FORTH interpreter! > Once the fix for PR104067 hits Fedora, if it's not fixed I can take a look. A few errors later I get that one: In function ‘SetDevicePathEndNode’, inlined from ‘FileDevicePath’ at DevicePathUtilities.c:857:5: DevicePathUtilities.c:321:3: error: writing 4 bytes into a region of size 1 [-Werror=stringop-overflow=] 321 | memcpy (Node, &mUefiDevicePathLibEndDevicePath, sizeof (mUefiDevicePathLibEndDevicePath)); | ^ In file included from UefiDevicePathLib.h:22, from DevicePathUtilities.c:16: ../Include/Protocol/DevicePath.h: In function ‘FileDevicePath’: ../Include/Protocol/DevicePath.h:51:9: note: destination object ‘Type’ of size 1 51 | UINT8 Type; ///< 0x01 Hardware Device Path. | ^~~~ cc1: all warnings being treated as errors Hmm, mUefiDevicePathLibEndDevicePath is a 4-byte struct with 1-byte "Type" being the first struct field. Node is a void ptr. So the code looks perfectly fine to me. Did I miss something, or is that another case of a gcc bug? take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora minimum hardware requirements
Hi, > So in short the best current scenario is Anaconda booted in text mode > from a USB stick or via PXE with NFS installation source - that should > require the least amount of RAM at installation time. > > Still even then, especially with kickstart installations that have > elaborate post scripts (that need RAM to run as well!) or install > tons of packages (depsolving as well as elaborate RPM scriptlets need > RAM!) can still throw a wrench into the works. Also install with just the server repo. The repodata needs memory too, so when adding the "everything" and "updates" repos RAM requirements go up too. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: I think we should stop building i686 packages we're not shipping
On Wed, Sep 01, 2021 at 10:47:05AM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 01 September 2021 at 10:01, Vitaly Zaitsev via devel wrote: > > On 31/08/2021 18:53, Matthew Miller wrote: > > > This is an off-shoot thought of the 32-bit ARM conversation. Right now, we > > > build stuff like libreoffice for i686, but then (mostly) don't ship it. > > > This seems like a waste of resources and time. > > > > +1. We should only build selected packages for multilib support (Steam, > > Wine). > > That's not enough. As mentioned elsewhere in the thread, we need the > whole build environment built for i686, including all BuildRequires:. That is probably still a small number of packages compared to the complete fedora package set. So I'd expect "give koji a whitelist" will work better than "blacklist in specfiles". > Also, there are tons of old closed-source i686-only games that depend on > i686 libraries other than Wine or Steam. That should be a rather small set of packages too, probably not much beyond SDL and maybe mesa for the newer ones. Anything which does *not* go that route to display stuff and tries to talk directly to the hardware (hello svgalib) will most likely not work anyway on modern hardware ... take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: x86_64-v2 in Fedora
Hi, > The problems with this is that we are taking a fairly fuzzy data set > and making it much easier to track individual users in ways seen as > problematic by various laws and regulations. Well, depends on how you store the data. You can store one record per machine (with all properties in there), or you can store one record per property per machine. With the latter you basically kill query on subgroups (like "how many x86_64-v3 machines use UEFI?") because that grouping information is gone if you store each end every little piece of information in its own record. But it'll also much harder to do fingerprinting on such a data base ... Standard disclaimer: IANAL. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Support using a GPT partition table in Kickstart (System-Wide Change proposal)
Hi, > I don't know why we all missed it. Butt that appears to be the case. > > However, the end goal is to create hybrid BIOS+UEFI cloud images via > kickstart. (Maybe down the road it could be generally useful, if/when the > existing bootloader UI bits go away.) https://git.kraxel.org/cgit/imagefish/tree/kickstart/el8.ks (for rhel8/centos8, probably wouldn't work as-is in f34+ because the unified grub feature changed the grub cfg file arrangements). take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Wayland and basic graphics mode
Hi, > Do we want to support a "basic graphics mode"? If so (which I think we > do), are there any alternatives to disabling KMS entirely that we > could use? Perhaps vkms[2] is an option? If not, what do we do about > it? Hopefully we can ignore just fbdev soon ... https://patchwork.freedesktop.org/series/78817/ [ drm driver for firmware framebuffers ] take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: 32bit arm builder issues
Hi, > I'm now trying (in staging) moving them back to direct boot from uefi. > If that doesn't work on f33, It should do. Starting with f33 kernel + grub2 are working just fine. You an use a regular anaconda install and shouldn't see much of a difference between aarch64 and armhfp in uefi mode. HTH, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 virt-install + ks has some problem switching root
Hi, > An additional problem is I cannot find any way to debug the problem. > Something (systemd? dracut?) asks for a root password in order to get > to the emergency shell, and I can find no way around this nor any > password which works. I wish there was a "stop asking for a password" > option on the kernel command line. Trapped into the same thing a few days ago. dracut uses sulogin now. Run dracut with --no-hostonly. Adding dracut-config-generic to the kickstart package list should have the same effect (not tested though). That'll disable the root login in the initramfs and sulogin gives you a shell when you tap enter. HTH, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)
On Thu, Dec 31, 2020 at 06:28:22PM +0800, Qiyu Yan wrote: > Vitaly Zaitsev via devel > 于2020年12月31日周四 下午6:12写道： > > > > On 30.12.2020 20:53, Ben Cotton wrote: > > > This change makes the GRUB configuration files layout to be consistent > > > across all the supported architectures. Currently EFI is a special > > > case since the GRUB configuration file and environment variables block > > > are stored in the EFI System Partition (ESP) instead of the boot > > > partition (or `/boot` directory if no boot partition is used). > > > > Why not switch from the ancient GRUB2 to the modern systemd-boot? > iirc systemd-boot don't support legacy BIOS system. You can install systemd-boot and grub2-pc side-by-side, sharing the bls boot configuration, and have a system bootable in both uefi and bios mode. We don't have systemd-boot on !x86 though. aarch64 didn't work last time I tried. armhfp seems to not be supported (at least the fedora rpm hasn't binaries). s390x and ppc are not efi platforms. So if we want cross-platform consistency grub2 is the best option we have. The config file is ugly, but thanks to bls you can largely ignore that now. No need to touch it for kernel updates etc. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Delta RPMs in Fedora 34
Hi, > we aren't making very many, which makes them even less useful. Plus, we're > only making them between updates and for packages where those updates are > frequent, that means you need to keep on top of things, which may be best > practice but is most difficult for low-bandwidth users who might most > benefit in the first place. I'm a low bandwidth user. And my setup basically is: (1) route all updates though a squid caching proxy. (2) configure all fedora machines to use the same fixed mirror. (3) disable drpms. (4) disable zchunk. There are always cases where you need the full rpm anyway (for example fresh installs with update repo enabled), so just loading (+caching!) the full rpms and don't bother with drpms works better overall. The problem with zchunk is that it isn't cache-friendly. squid can't cache range requests. And even in case of a full download (fresh install) I've seen zchunk metadata being re-downloaded when requested again ... take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packaging rules for build from source vs BPF byte code ?
Hi, > QEMU ships various keymap data files which are auto-generated from data > provided by X11, but none of these are built "from source", because the > generated data files are considered the preferred source form. Well, the actual reason is the X11 dependency. qemu needs those files also on non-X11 platforms like Windows, but generating them on non-X11 platforms doesn't work. Also note that if we could easily gather the data needed to generate those keymap files on all platforms we would not need them in the first place ;) BTW: Starting with qemu 5.2 those files will be regenerated during the build if the required dependency (xkbcommon-devel) is available at build time. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)
Hi, > > That's curious, when I mount the server dvd ISO, those files have > > different inode numbers. > > Sorry for the late reply on this, yet, they are hardlinked. Well, iso9660 is pretty simple. File data is basically referenced as "offset,length". So hardlinked files can be trivially be made referencing the same data blocks. There isn't something like a link count field in the directory listing, so this is *not* visible with "ls". The only way to figure the link count is scanning the whole file system and see whenever there are other files with the same offset, and as far I know nobody goes that extra mile just to figure the link count for "ls". take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
Hi, > For example, if I have my laptop in my home wifi, connected to RH VPN, > then there are some names resolvable only via the local > DNS. Specifically: my router's, my printer's and my NAS' address. And > there are other names only resolvable via RH VPN. systemd-resolved for > the first time gives me a chance for this to just work: it will send > requests to both the RH DNS servers and the local ones, and uses the > first successful reply, or the last failed reply. And that's quite > frankly awesome, because that *never* worked before. Sorry, but that is not correct. NetworkManager can handle split-dns just fine, by using dnsmasq and reconfiguring it via dbus when vpn connections come and go. I can easily add more servers + zones by dropping a config file snippet into the /etc/NetworkManager/dnsmasq.d/ directory, for example to resolve the hostnames for my kvm guests on the libvirt network. That works for ages on my RHEL-7 workstation where systemd-resolved doesn't even exist ... > So sending the requests to all available DNS servers in absence of > better routing info is a great enabler: I fail to see why sending queries to all servers is a good plan. The redhat vpn dns servers surely can't resolve the hostnames for my local lan, and frankly they shouldn't even know which hosts I try to access. Likewise my ISP shouldn't know which non-public RH servers I try to access. > Key, take-away here: > > 1. Ideally we'd just route company DNS traffic to VPN, and everything >else to local LAN DNS. But that requires explicit routing info to >be configured, we cannot auto-detect this info (beyond some minor >inference from the search domains) Well, if auto-detect doesn't work we should (a) fix the vpn protocols/implementations and (b) fallback to manually configuring things until this is done. >VPN use, then sending to everything in parallel and taking the >first positive reply and the last negative one is the best chance >to make things "just work". At the expense of leaking information, which I don't consider a good trade-off. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > are not. Which makes sense to me. Why would you encrypt /boot? The > > files you can find there are public anyway, you can download them from > > the fedora servers. Encrypting /boot would make the boot process more > > fragile for no benefit. > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > encrypt /boot to ensure that your boot images have not been tampered with, Well, if that is your concern the answer is secure boot. That will not only prevent tampering with /boot files, but also prevent tampering with the bootloader itself. > or config files haven't been read by somebody other than the end > user. Hmm, typically that is pretty standard stuff and very simliar on all fedora installs. Only the root filesystem uuid differs, and possibly local tweaks like configuring a serial console. I can't see how reading that is of much concern. > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > filesystems. > > Is there a notable benefit to using that over GRUB2, which already has > support on both UEFI and BIOS? Well, for my day-to-day work it doesn't make much of a difference. Both get the job done. I generally dislike the grub2 config file format. I'm not going to repeat all the arguments here which have been mentioned numerous times already. With BLS support things became a bit better because for the most part I can just ignore grub.cfg after install. I suspect the grub2 maintainers have a different view on this. They have to deal with the mess to make sure I don't have to. And on top of that getting changes merged upstream to grub2 seems to be a PITA, leading to a huge stack of patches in the fedora grub2 rpm ... take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 06, 2020 at 03:45:45PM +0200, Nicolas Mailhot via devel wrote:
> Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit :
> > Â Â Hi,
> >
> > See above. sd-boot allows to edit the kernel command line too. Same
> > hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
> > actually listed if you hit '?' or 'h'.
>
> Given the mess boot input and display are on a lot of systems, any
> keypress should pause the boot and display boot options (including
> editing the boot CLI).
Sure. All bootloaders I have seen in recent years (including sd-boot)
behave that way. Even if a key has no specific function attached
pressing it will at least stop the timeout countdown. So I'm not sure
why you are bringing that up and what you are trying to say ...
take care,
Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Hi,
> > default entry highlighted, a few seconds timeout with countdown. Both
> > support editing boot entries.
> Anecdata, but I definitely never (maybe once 15 years ago?) had grub
> install issue, but plenty of dracut reconfiguration/upgrade failures
> over the years and the ability to edit the command line has been a life
> sacver.
See above. sd-boot allows to edit the kernel command line too. Same
hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one is
actually listed if you hit '?' or 'h'.
take care,
Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Hi,
> My real problem with grub2 is not that it's complex, but the fact that
> it exposes its complexities to the user.
The config file syntax is a mess indeed. The fact that you need a
config generator tool in the first place speaks volumes ...
But note that grub config files don't have to be as complex as the
grub2-mkconfig generated ones.
> I'm willing to try systemd-boot on a virtual machine, to see if it
> makes things easier, but the fact it doesn't support BIOS makes it not
> very usable for me.
https://www.kraxel.org/repos/images/fedora-31-efi-systemd-x86_64.qcow2.xz
Image boots in both uefi (sd-boot) and bios (grub2) mode, and the config
file for the latter is so short that I can include it here without
hitting the mailing list size limit ;)
-- cut here --
function load_video {
insmod all_video
}
insmod part_gpt
insmod fat
insmod serial
insmod terminal
insmod blscfg
serial --unit=0 --speed=115200
terminal_output console serial
terminal_input console serial
set boot='hd0,gpt2'
set timeout=3
blscfg
-- cut here --
take care,
Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Mon, Jul 06, 2020 at 08:08:48AM -0400, Stephen John Smoogen wrote: > On Mon, 6 Jul 2020 at 07:38, Gerd Hoffmann wrote: > > > > Hi, > > > > > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep > > > > "w" pressed down it will automatically boot into windows, similar if > > > > you keep "l" pressed down it will automaticall boot into linux, "a" > > > > will boot into macos, all without showing any UI at all. This means > > > > the boot menu can be hidden entirely during boot with a zero timeout, > > > > but you can still boot into a specific boot entry. > > > > > > That's actually awful, in my opinion, > > > > Why? It's nice to have them and I can't see any downsides. > > > > It isn't that you put the keyboard strokes, it is that you are saying > you can do a zero-timeout without problems. Ah, ok. I meant specifically the hotkey existing. I clearly can see that hiding the boot menu has its downsides and in fact most of my machines are configured to show it (and I think server actually defaults to menu=on, only workstatiion has menu=off by default). That is doesn't matter much for the uefi/bios and grub2/sd-boot discussion though, both boot loaders can be configured to whatever timeout you like. > 4. Screen flickering and paused screens. The lenovos I have do weird > things when attached to external monitors. Screens will stick on > monitors during the boot up sequence sometimes.. or they will do sync > tests which drop the entire video for 3-5 seconds at a time. I have a 4k monitor connected to a intel nuc, and grub has a 30s timeout there because it takes *ages* for the screen to sync. And even with the 30s timeout I don't see the menu now and then. The other extreme are laptop panels which typically sync within the fraction of a second where all this is not a problem at all. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Sun, Jul 05, 2020 at 01:11:08AM -0700, John M. Harris Jr wrote: > On Sunday, July 5, 2020 1:03:34 AM MST Luya Tshimbalanga wrote: > > It would be great that the installer, Anaconda, enables sd-boot for > > users running on UEFI system. The method was done before with both LILO > > and Grub decades ago and it was very surprising very few thought of that > > process especially for a distribution aiming to use latest technology. > > > > The question is for contributors running on legacy BIOS if they are > > willing to maintain it while the installer can focus to effectively use > > sd-boot. > > systemd-boot isn't really an option. It doesn't have the features that are > necessary for Fedora systems to actually be able to boot. It'd work on > Workstation, maybe, if they think their users will never need to know they're > even using a bootloader, and won't put /boot on LVM or LUKs encrypt it. Default fedora disk layout in UEFI mode is partitions for ESP, /boot and LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot are not. Which makes sense to me. Why would you encrypt /boot? The files you can find there are public anyway, you can download them from the fedora servers. Encrypting /boot would make the boot process more fragile for no benefit. sd-boot still wouldn't work out-of-the-box though, due to /boot being xfs not vfat and firmware typically not shipping with xfs drivers. We could that by using vfat for /boot. Or by shipping & using xfs.efi, simliar to how apple ships & uses apfs.efi to boot macOS from apfs filesystems. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Hi, > I have no problem with GRUB2 or sd-boot. I have much more problems > with refind and their ilk. While things can look pretty, that's fine, > as soon as it gets in my way when I try to get things done it stops > being fine. "getting into the way" IMO includes "doesn't show up on the serial console". Both sd-boot and grub2 are doing fine here, the standard uefi text console works on both vga and serial line. Anything doing something fancy on the framebuffer is problematic here ... take care, Gerd PS: yes, you can configure grub2 to do fancy graphics, but fedora doesn't do that by default. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Hi, > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep > > "w" pressed down it will automatically boot into windows, similar if > > you keep "l" pressed down it will automaticall boot into linux, "a" > > will boot into macos, all without showing any UI at all. This means > > the boot menu can be hidden entirely during boot with a zero timeout, > > but you can still boot into a specific boot entry. > > That's actually awful, in my opinion, Why? It's nice to have them and I can't see any downsides. > and objectively undiscoverable.. Indeed. Would be nice to show these hotkeys somewhere. Extend the help line which is shown when you press '?' for example. > If you'd like to see how it should be done, boot a VM with GRUB2 as > the bootloader. For a short period of time, you'll see a list of > options, with the default option highlighted. If you don't pick > something different, or don't need to enter a prompt to recover your > device, it'll automatically boot. Well, seems you have never actually used sd-boot ... There actually isn't much of a difference between grub2 and systemd-boot here. Both can be configured to show or not show a menu. The menu screen doesn't look fundamentally different either: List of boot entries for the kernels installed, entry to boot into firmware setup, default entry highlighted, a few seconds timeout with countdown. Both support editing boot entries. Yes, unlike grub2 sd-boot has no command prompt. I have not missed that so far. The vast majority of cases where I've actually needed the grub2 prompt have been grub2 install problems, like grub2 failing to find its config file for some reason. That is clearly not something I account in favor of grub2 ... > GRUB2 is nice in that it's powerful enough for those that need it, but > simple enough for those who don't want the complex features. Well, alot of the complex grub features are dragged forward from the BIOS world to the UEFI world and are somewhat awkward there. The BIOS provides block device access at sector level, so the boot loader has little choice but implementing drivers for all kinds of stuff. Or use fragile block lists like lilo did in the last century. With UEFI much more functionality is provided by the firmware and there is little reason for a bootloader to have tons of drivers. With the exception of filesystem drivers in case you want boot from something != vfat. But even that should ideally be implemented as uefi driver not as grub2 module. If you insist on comparing bloat it will be grub2 which is bloated, and it comes from being stuck in its own world and carrying its own implementation for everything instead of using firmware services. -rwxr-xr-x. 1 root root 93803 Jun 2 08:19 systemd-bootx64.efi -rwx--. 1 root root 2513224 Jun 19 18:24 grubx64.efi (binaries as shipped by fedora 32). take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Hi, > Also note that this entails a lot more work then just maintaining sd-boot, > anaconda will need to be adjusted, kernel-install scripts will need to > be adjusted, etc. And what about upgrades, if upgrades stick with using grub2 > then now we have 3 bootloader configs, including things like documentation on > how to change kernel commandline options, to maintain instead of 2. It is all there and working, except for the anaconda bits (as far I know there is no way to ask anaconda install sd-boot instead of grub2). If you wanna play with it qemu images (f31 only, no time yet for f32) are here: https://www.kraxel.org/repos/images/ The '-systemd' variants use sd-boot. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
> > One problem with sd-boot is that the kernels must stay on the ESP, which > > can be a problem for dual-boot installs (where Fedora has to run with > > the existing ESP and can't just create one which is big enouth). > > Nah, that's not true. Hasn't been for quite a while. > > sd-boot checks for kernels in the ESP first, and then on a second > partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR > partition is simply a partition with type UUID > bc13c2ff-59e6-4262-a352-b275fd6f7172. Ah, this is news to me. XBOOTLDR must be formated with a filesystem the uefi firmware can read (i.e. vfat in practice) I assume? > > Another problem is that grub2 covers more architectures than sd-boot. > > What is the plan for armhfp, ppc64, s390x? > > sd-boot is uefi only, but it should work fine with any arch that is > supported by uefi. Seems it isn't built for armhfp in Fedora (/usr/lib/systemd/boot/efi doesn't exist ...). > > IMHO a better preparation for deprecating BIOS would be to make new > > installs bootable with both BIOS and UEFI. Which isn't hard at least > > for the "[x] use all space" case where Fedora can partition the disk as > > it pleases: Use gpt. Create a bios boot partition, install grun-pc > > there. Create a ESP partition, install grub-efi there. Create a > > partition for the /boot filesystem. Have both grubs pick up BLS config > > from /boot/loader. > > My suggestion would be: don't standardize on boot loaders, standardize > on the boot loader spec. Using the above partition scheme probably works with sd-boot (instead of grub-efi) too if you tag /boot as XBOOTLDR. The point I was tring to make is that you can install fedora in a way that the disk can be booted in both bios and uefi mode. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Hi, > > So I can't say I'm thrilled about a future that depends on EFI for > > virt, but I'm resigned to the fact this is the direction the world > > is taking. So we're not likely to have any choice and will have to > > work to mitigate any downsides it brings. > > Right. > > Preferably the installer should detect and setup the system either with > sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI ) I have my doubts that building on sd-boot and drop grub2 is going to fly. One problem with sd-boot is that the kernels must stay on the ESP, which can be a problem for dual-boot installs (where Fedora has to run with the existing ESP and can't just create one which is big enouth). Another problem is that grub2 covers more architectures than sd-boot. What is the plan for armhfp, ppc64, s390x? IMHO a better preparation for deprecating BIOS would be to make new installs bootable with both BIOS and UEFI. Which isn't hard at least for the "[x] use all space" case where Fedora can partition the disk as it pleases: Use gpt. Create a bios boot partition, install grun-pc there. Create a ESP partition, install grub-efi there. Create a partition for the /boot filesystem. Have both grubs pick up BLS config from /boot/loader. take care, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to convert from GRUB to systemd-boot?
On Thu, Jun 04, 2020 at 08:04:42AM -0500, Richard Shaw wrote: > Is there someone that can help me convert my Fedora install from GRUB to > systemd-boot and actually get it where kernel updates won't break it? You can try fedora-31-efi-systemd-x86_64.qcow2.xz from https://www.kraxel.org/repos/images/ (sorry, no f32 images yet). unxz, use qemu-img to convert to raw, dd to a usb stick, set a root password with virt-customize, plug-in the stick & boot. HTH, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Mon, Dec 16, 2019 at 09:00:11AM -0800, Adam Williamson wrote: > On Mon, 2019-12-16 at 10:49 +0100, Gerd Hoffmann wrote: > > > > Wishlist item: Can we just have cdn.fedoraproject.org download urls > > please? > > If you mean 'a URL that redirects you to a mirror that carries the > file', that's what download.fedoraproject.org is. Well, a redirect does't solve the squid caching issue from my previous mail (which you've snipped) as the proxy would still see the different mirror hostnames and re-download things when download.fedoraproject.org picks another mirror for some reason. cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
Hi, > Soon after release, weeks, this first update payload is easily the > size of the Workstation Live ISO. Is it typical to setup a local > mirror to mitigate this problem? If it were easier to setup a local > mirror, or locally mirror a subset of the RPMs in a release, would > that help make netinstall more viable in addition to making it easier > to provide up to date installations? /me has a local Server mirror for VM installs. Mirroring the Everything and updates repos is too much data. Mirroring a subset of the RPMs is too much work (maintaining the subset you need is a PITA because it constantly changes). What works best is downloading though a caching proxy. Needs tweaking the repofiles though: Comment out metalink, add baseurl with a fixed mirror instead, otherwise you'll end up re-downloading unmodified repodata and packages just because yum/dnf picked another mirror this time. Wishlist item: Can we just have cdn.fedoraproject.org download urls please? cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL8 and Mageia7 available in Copr
Hi, > rhelbeta-8-x86_64 CRB repo is missing here. cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead
On Sat, Nov 17, 2018 at 02:43:23PM -0600, Chris Adams wrote: > Once upon a time, Jonathan Dieter said: > > The benefit of zchunked rpms is that, when downloading an updated rpm, > > you would only need to download the chunks that have changed from > > what's on your system. > > How well do web servers and caches handle range requests? web servers: not much of a problem. caches: doesn't look so good. squid can't store chunks of a file. So the options you have are: (a) configure squid to pass through range requests to the original server. Which kills any caching. (b) configure squid to fetch the whole file no matter what. Subsequent requests (including range requests) will be served from cache then, but zchunked rpms wouldn't save any bandwidth then. cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F29 System Wide Change: uEFI for ARMv7
Hi, > Gerd Hoffman has a nightly edk2 repo which builds arm32 images. If > someone can figure out the magic qemu incantation to get those working > with Fedora, similar to how aarch64 works, I can do the rest > > https://www.kraxel.org/repos/ Yes, it is pretty much identical to aarch64. My 32bit guest (on 64bit host) config looks like this: [ ... ] hvm /usr/share/edk2.git/arm/QEMU_EFI-pflash.raw /var/lib/libvirt/qemu/nvram/arm-b32_VARS.fd host [ ... ] HTH, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/46SU6MXFRURL2EVBR55RASEQSWZITYQF/
Re: F29 System Wide Change: Make BootLoaderSpec the default
Hi, > (f) The scheme should function without UEFI. There are plenty of > non-UEFI systems out there. This means that the bootloader might need > to live in a BIOS boot partition, or in flash, or in ROM, or in other > strange places. > Now let's think this through. You're proposing that $BOOT be the ESP. > This fails (f) entirely. Well, no. You can have both ESP and bios boot partitions, and configure grub-pc to read the BLS config from the ESP ... cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OFWLR3DO6RS6T7KIYJAFO3I3FWINFVCM/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Mon, Jun 25, 2018 at 12:14:36PM +0200, Lennart Poettering wrote: > On Fr, 22.06.18 13:35, Chris Murphy (li...@colorremedies.com) wrote: > > > $BOOT being non-vfat is a fairly substantial departure from either > > BootLoaderSpec, the original requires $BOOT be vfat, the mjg59 version > > require $BOOT be firmware readable. That is not a complaint, I'm just > > making an observation of the consequences. I'm personally on the fence > > when it comes to the merit of a shared $BOOT. It sounds like a good > > idea, but maybe it's specious? > > BTW, I think we should actually relax the wording in the spec, and > move towards matthew's version on this: instead of saying "must be > vfat" to say "must be firmware readable" essentially means the same, > but is friendlier towards MacOS of course. Would also allow "we drop a ext2.efi driver to BSP to access $BOOT" I guess? cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QTAGOWS3GCR6FZYCELGVGHLZHT33BYAC/
Re: F29 System Wide Change: Make BootLoaderSpec the default
Hi, > > > Which file system do you have in mind even for this? > > > > Unspecified for now. i.e. no change. It would remain ext4 by default I > > expect, but ultimately whatever anaconda allows. IMHO the only thing which is reasonable here would be something simple with posix semantics, which is unlikely to change on-disk format anytime soon. So symlinks are working (which appears to be used by atomic / ostree), which is something vfat can't support. ext2 looks like a good pick here. Simple, posix, no journal replay issues, and drivers for non-linux systems are relatively widespread. cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E6YKIZOZ5EMNF4566AQ3MQPBG65F2XYW/
Re: F29 System Wide Change: Make BootLoaderSpec the default
On Thu, Jun 21, 2018 at 10:04:03AM -0400, Colin Walters wrote: > > > On Thu, Jun 21, 2018, at 9:41 AM, Gerd Hoffmann wrote: > > > > Well, as *additional* variant it doesn't provide that much value. More > > interesting would be to create all x86 cloud images that way, so they > > boot just fine on both bios and efi, and we don't have to bother > > creating two image variants. > > We aren't creating two[1] image variants today. Why would we? Who > would use them and why? Well, sooner or later we will have to make the switch to uefi in virtualization, following the trend on physical hardware which ships with uefi firmware since years. And having cloud images which work fine with both bios and uefi will make the transition easier ... cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AMHRLHKX6FXKYFI4PFKNHPURUROMPTQ2/
Re: F29 System Wide Change: Make BootLoaderSpec the default
Hi, > From my perspective (Fedora CoreOS developer) that straddles > both physical and cloud for the server case, the problem is that > the virtualized case, and in particular public cloud, and really > specifically EC2 - no one really cares about EFI to boot their VMs. Indeed. And it sucks. > > Device Start End Sectors Size Type > > /dev/sda1 2048 1023981924M BIOS boot > > /dev/sda210240 1058815 1048576 512M EFI System > > I wouldn't *oppose* that; in fact if you (or someone else) > wanted to push for that with e.g. Fedora CoreOS, I'd be happy > to discuss it. But it's not like it has a truly compelling advantage > over what we ship today - it'd just be *another* weird variant > of things in the end right? Well, as *additional* variant it doesn't provide that much value. More interesting would be to create all x86 cloud images that way, so they boot just fine on both bios and efi, and we don't have to bother creating two image variants. > And the fact that FAT has no ability to do atomic replacement bothers > me a lot. (A wrinkle here is that ostree implements an atomic swap of > /boot/loader - you can today boot FAH/Silverblue and just ls -al /boot > to see it) Why do you need that? Wouldn't FAH just drop a new file for the new version into /boot/loader/entries on updates? So you have old and new version listed in the boot menu and can easily rollback to the old version if needed? But anyway: The scheme works with and without separate /boot. cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L4Q7ILZRWGWGVH77UCVMWG52FMATLR5X/
Re: F29 System Wide Change: Make BootLoaderSpec the default
Hi, > Therefore, Option #2 will be extremely common. What percent of Fedora > users dual boot? I have no empirical data. I'd guess 1/2. Sure? I would expect in the age of virtualization people prefer virtual machines, because you can run fedora and $someotheros at the same time then. The installer must be able to handle this even if it is 10% only, so the numbers don't change much on the fundamental issue. I'm just curious ... cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GZPZAAH5YPXJK7GZXPIKQNPOIKWN3LLU/
Re: F29 System Wide Change: Make BootLoaderSpec the default
Hi, > And in my opinion, it's not simple to say: OK if you have this size > ESP to start, you get this layout, and if it's bigger you get this > other layout, and if it's BIOS you have this 3rd layout. Well, for fresh installs[1] there is no reason to have efi and bios use different layouts. You can just do this: [root@ibm-p8-kvm-03-guest-02 ~]# fdisk -l /dev/sda Disk /dev/sda: 4 GiB, 4294967296 bytes, 8388608 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 92035660-BEFD-45D5-9883-B2B91EC429D1 Device Start End Sectors Size Type /dev/sda1 2048 1023981924M BIOS boot /dev/sda210240 1058815 1048576 512M EFI System /dev/sda3 1058816 2107391 1048576 512M Linux swap /dev/sda4 2107392 8386560 62791693G Linux root (x86-64) systemd-boot plus bootloader config plus kernels goes to /dev/sda2. grub2 (bios version, with BLS patches) goes to /dev/sda1. Short, fixed config snippet instructs grub2 to read the bls config from /dev/sda2. That image can be booted in both efi mode and bios mode[2]. And because they use the very same bls configuration the bios/efi configs can't go out of sync on kernel updates. Oh, and systemd-nspawn can boot the image too. cheers, Gerd PS: The idea still works if you add a separate /boot partition, even though I can't see a compelling reason to do so if you have a fresh hard drive and can partition it as you like. And you have to use grub2-efi instead of systemd-boot then. [1] Dual boot installs obviously have to deal with whatever mess they find on the harddrive ... [2] Well, needs some manual editing due to some extra spaces. https://bugzilla.redhat.com//show_bug.cgi?id=1588184 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QTL4WZ4ZDL7AOVTAHSIFRDLE57BGI5YJ/
Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64
Hi, > > effort, and nobody outside of Fedora cares about non-SSE2 anymore. Even > > distros that claim to support non-SSE2 hardware just ship QtWebEngine as > > SSE2 only. I haven't seen any other distro even picking up my patch, let > > alone working on it. The Fedora Chromium, V8 and Node.js packagers also do > > not care. > > I suspect Firefox may also be sse2-only, at least indirectly from Rust. > I just checked the rustc target spec for i686-unknown-linux-gnu, and by > default it's targeting "pentium4". There is an i585-unknown-linux-gnu > which targets only "pentium" though. > > But Firefox has been building with Rust on all arches for over a year > now, and apparently, nobody has noticed this in practice... Probably modern web browsers simply don't run with reasonable performance any more on hardware that old, so nobody is doing that. Same for most/all other software requiring sse2. Most pre-sse2 hardware still in use is probably a headless machine sitting in some corner, running sshd / apache / samba / cups / whatelse, but no desktop workload. If someone wants keep 32bit fedora alive for pre-sse2 hardware I think the only reasonable thing would be to undust the i586 target, then go build software which requires sse2 as --target i686 and everything else as --target i586, i.e. basically stop the effort to patch software for non-sse2 hardware. pre-sse2 hardware would have the i586 packages available only. But I somehow doubt that even that is worth the effort ... cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N4L46UR55TY3F5XBY7EGSLHVPVGRY5IT/
