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.
&g
> 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
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
>
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
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.
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
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
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
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
> == 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,
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
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?
> > /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
> >
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,
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
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
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,
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
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
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
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
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,
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
> > == 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
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
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
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
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
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
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 in
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
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
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. mk
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.
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
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. N
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
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
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
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
&g
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 a
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
> == 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
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
> >
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
>
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
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'
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
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
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
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.)
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 ...
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
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"
>
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
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
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
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
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
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 encryp
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 unl
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
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
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" presse
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
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
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
>
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
> > 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
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
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
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 mir
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
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:
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
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
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
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
> >
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
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,
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.
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
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.
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
Hi,
> Side note, android's 'reboot' cmd can take an argument, like 'reboot
> fastboot' or 'reboot recovery'.. that might be one of the few features
> from android worth copying ;-)
I'm still missing something simliar to "lilo -R " in the world
of modern boot loaders. This used to set the lilo
1 - 100 of 174 matches
Mail list logo
