hybrid BIOS/UEFI images for cloud
Hi, Fedora Cloud SIG have a couple of related issues, create images using GPT [1] and create images supporting UEFI boot [2]. What we'd like to do is create a single set of images that are UEFI and BIOS bootable, out of the box. And I'm wondering if this is possible in Anaconda now, or if it could easily be enhanced to make it possible via kickstart? If the image creation environment is BIOS, grub2-install will populate LBA 0 and BIOS Boot partitions correctly. But I'm uncertain whether anaconda will create and mount /boot/efi, i.e. if the kickstart manually creates an ESP mounting it at /boot/efi, will anaconda resist due to the environment being BIOS? The installation of grub2-efi-* RPMs should work though. We probably don't need efibootmgr to run, we can just expect BOOTX64.EFI fallback to discover there isn't an nvram entry, and add one. And due to Fedora 34 unified grub feature, a single /boot/grub2/grub.cfg should work whether UEFI or BIOS boot. If the image creation environment is UEFI, grub2-install doesn't work, it'll detect UEFI and it'll fail. And thus no BIOS bootloader can be installed. Maybe we could do a UEFI installation, additionally creating BIOS Boot partition, and run a post install script that does `grub2-install --target=i386-pc` to add the BIOS bootloader? Thoughts? [1] https://pagure.io/cloud-sig/issue/330 [2] https://pagure.io/cloud-sig/issue/309 -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://listman.redhat.com/mailman/listinfo/anaconda-devel-list
Re: btrfs mkfs options for root filesystem?
On Tue, Feb 9, 2021 at 12:41 PM Matthew Miller wrote: > > On Tue, Feb 09, 2021 at 11:36:34AM -0700, Chris Murphy wrote: > > Anaconda requires a new subvolume for / but doesn't require a > > reformat. The Custom UI shows the / mountpoint's reformat checkbox > > grayed out and checked, which might give the impression that whole > > partition will be reformatted. It's confusing but just a cosmetic UI > > anomaly. > > Oh -- so I shouldn't have pre-created the subvolumes? I did, and assigned > them, and that's what happened. If I remember right, the subvolume > checkboxes were grayed out and not checked, but I couldn't leave the top > level volume (what do you call that?) unchecked and proceed -- I got an > invalid configuration error. Precreating the subvolumes won't matter, but you definitely can't use an existing subvolume for '/' mountpoint. One thing that matters a lot is that the partition scheme preset must be set to Btrfs (it is by default now). This might help or it might not :D depending on what already exists. But the key part is that you must use [+] button on the lower left when creating the / subvolume, and I also advise not specifying a size value. Just select / as the mountpoint without a size. That will create a new subvolume and assign it to /. Everything else can optionally be new or reused. https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: btrfs compression by default
On Tue, Feb 9, 2021 at 12:26 PM Chris Murphy wrote: > > On Tue, Feb 9, 2021 at 11:40 AM Martin Kolman wrote: > > > > On Tue, 2021-02-09 at 09:50 -0700, Chris Murphy wrote: > > > On Tue, Feb 9, 2021 at 9:15 AM Michel Alexandre Salim > > > wrote: > > > > There's a further complication: Chris just informed me that on BIOS > > > > systems, space is more of a constraint so the zstd module is not part > > > > of GRUB ... meaning we have to handle these two scenarios: > > > > > > It's available, but it's the 2nd largest GRUB module at ~100KiB. And > > > on BIOS we're space limit right now to 1 MiB MBR gap or BIOS Boot > > > partition. > > > > > > GRUB works fine with a zstd compressed /boot/ but obviously there's > > > next to no benefit compared to the added complexity since the kernel > > > and initramfs are already compressed. > > > > > > So if it's not difficult to exclude compression on /boot/ that's > > > probably preferred? > > > Are we talking about custom partitioning layouts ? > > For Fedora 34, yes. There's an idea/pre-plan for Fedora 35/36 to put > /boot/ on Btrfs by default; but it's contingent on GRUB changes needed > upstream to better support grubenv by putting it on a dedicated > partition. [1] :D [1] GRUB disallows writes to it from the pre-boot environment when grubenv is on mdadm, luks, btrfs, zfs; while GRUB allows writes to grubenv when on ext[234] and XFS the fs developers really frown on anything other than kernel code writing to a file system owned partition, even if that write is just a data block overwrite. So the idea is to stop doing it and give grubenv it's own partition sorta like BIOS Boot. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: btrfs compression by default
On Tue, Feb 9, 2021 at 11:40 AM Martin Kolman wrote: > > On Tue, 2021-02-09 at 09:50 -0700, Chris Murphy wrote: > > On Tue, Feb 9, 2021 at 9:15 AM Michel Alexandre Salim > > wrote: > > > There's a further complication: Chris just informed me that on BIOS > > > systems, space is more of a constraint so the zstd module is not part > > > of GRUB ... meaning we have to handle these two scenarios: > > > > It's available, but it's the 2nd largest GRUB module at ~100KiB. And > > on BIOS we're space limit right now to 1 MiB MBR gap or BIOS Boot > > partition. > > > > GRUB works fine with a zstd compressed /boot/ but obviously there's > > next to no benefit compared to the added complexity since the kernel > > and initramfs are already compressed. > > > > So if it's not difficult to exclude compression on /boot/ that's > > probably preferred? > Are we talking about custom partitioning layouts ? For Fedora 34, yes. There's an idea/pre-plan for Fedora 35/36 to put /boot/ on Btrfs by default; but it's contingent on GRUB changes needed upstream to better support grubenv by putting it on a dedicated partition. [1] > Because I've just booted a current Rawhide installer and it creates /boot on > a separate standard partition > formatted with EXT4 by default, with / and /home on BTRFS. Yes. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: btrfs mkfs options for root filesystem?
On Tue, Feb 9, 2021 at 10:21 AM Matthew Miller wrote: > > I wanted to use `--csum xxhash` to create the btrfs filesystem on the system > I just installed. Unfortunately, this proves to be impossible, since > Anaconda requires that / be formatted by Anaconda. It's a small performance > win (33% faster) but also twice the bits for a much smaller collision risk. > > Is there a way to select or force the options used for btrfs? Anaconda requires a new subvolume for / but doesn't require a reformat. The Custom UI shows the / mountpoint's reformat checkbox grayed out and checked, which might give the impression that whole partition will be reformatted. It's confusing but just a cosmetic UI anomaly. There is a way to do this with kickstart, btrfs --mkfsoptions https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#btrfs -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: btrfs compression by default
On Tue, Feb 9, 2021 at 9:15 AM Michel Alexandre Salim wrote: > There's a further complication: Chris just informed me that on BIOS > systems, space is more of a constraint so the zstd module is not part > of GRUB ... meaning we have to handle these two scenarios: It's available, but it's the 2nd largest GRUB module at ~100KiB. And on BIOS we're space limit right now to 1 MiB MBR gap or BIOS Boot partition. GRUB works fine with a zstd compressed /boot/ but obviously there's next to no benefit compared to the added complexity since the kernel and initramfs are already compressed. So if it's not difficult to exclude compression on /boot/ that's probably preferred? -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
btrfs compression by default
Hi, This is in regards to this Fedora 34 change: https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression#Scope The gist is to do 'mount -o compress=zstd:1' anytime Btrfs is used, whether Destination Installation>Automatic or Custom or Advanced-Custom. Apply it during the installation, and add it to /etc/fstab. Somehow I got confused thinking that autopart supports --fsoptions, and that would be the way to do this. But (a) --fsoptions isn't supported with autopart, and (b) it wouldn't be a universal approach anyway. And we want this to be consistent. Now I'm thinking it needs to go somewhere in: https://github.com/storaged-project/blivet/blob/3.4-devel/blivet/devices/btrfs.py Am I on the right track, or does it need to go somewhere else, or in addition to that? Thanks, -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Scoping out the change needed for Anaconda to support resizing Btrfs filesystems
On Thu, Nov 12, 2020 at 8:18 PM Michel Alexandre Salim wrote: > > Dear Anaconda developers, > > There's this 7 year old bug about Anaconda not being able to resize > Btrfs filesystems, despite Btrfs itself supporting resizing. > > https://bugzilla.redhat.com/show_bug.cgi?id=962143 > > Now that Fedora defaults to Btrfs on desktop variants, since Facebook > uses Fedora as its preferred desktop Linux distribution we might be > able to dedicate some manpower to working on this, but need help to > scope out this work. > > Would any change needed be limited to python-blivet, or would other > components need to be touched? > I just created this to track the various issues around Btrfs shrink and utilities that maybe/probably should support it. https://pagure.io/fedora-btrfs/project/issue/35 I think the main thing that Anaconda needs is already in libblockdev. But it's missing a minimum size check. That issue is referenced in the fedora-btrfs#35 issue. I'm not sure where it belongs, but there probably needs to be a check for number of devices and only support shrink on single device Btrfs. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
On Thu, Jul 16, 2020 at 6:41 AM Vendula Poncova wrote: > > On Thu, Jul 16, 2020 at 7:13 AM Chris Murphy wrote: >> >> I've tested some images and this is going OK for the Live ISOs, but >> the boot.iso based images like netinstallers and dvds (silverblue, >> Server DVD) for some reason do not have zram-generator-defaults on >> them. Therefore those installation environments don't have a >> swap-on-zram setup. >> >> I see the 'Recommends: zram-generator-defaults' >> https://src.fedoraproject.org/rpms/anaconda/blob/master/f/anaconda.spec#_187 >> >> Yet that's somehow not enough? Nor is it enough that >> zram-generator-defaults is in @standard, to get it onto all the >> install media? >> > > It looks like lorax doesn't install weak dependencies. I have opened a new > pull request to fix the boot.iso: > https://github.com/weldr/lorax/pull/1048 > Maybe I should add it to the anaconda-tools group? https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in#_38 -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
I've tested some images and this is going OK for the Live ISOs, but the boot.iso based images like netinstallers and dvds (silverblue, Server DVD) for some reason do not have zram-generator-defaults on them. Therefore those installation environments don't have a swap-on-zram setup. I see the 'Recommends: zram-generator-defaults' https://src.fedoraproject.org/rpms/anaconda/blob/master/f/anaconda.spec#_187 Yet that's somehow not enough? Nor is it enough that zram-generator-defaults is in @standard, to get it onto all the install media? Related PRs https://pagure.io/fedora-comps/pull-request/513 https://pagure.io/fedora-kickstarts/pull-request/658 So far the installed OS's from these do have zram-generator-defaults installed, and the swap-on-zram device is up and running OK. The one installation that doesn't have it is the 'Custom Fedora' (I think this is also known as minimal package set) installation I used when doing an Everything netinstall installation. --- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
On Mon, Jul 13, 2020 at 5:38 AM Vendula Poncova wrote: > > On Fri, Jul 10, 2020 at 6:14 PM Chris Murphy wrote: >> >> >> >> On Thu, Jul 9, 2020, 12:58 PM Chris Murphy wrote: >>> >>> Use zram-generator instead of zram >>> https://pagure.io/fedora-comps/pull-request/513 >>> >>> Replace 'zram' with 'zram-generator', and exclude Cloud edition >>> https://pagure.io/fedora-kickstarts/pull-request/658 >> >> >> >> >> Those have been accepted. Anaconda PR #2723 and #2727 can happen anytime. >> > > Ok. I've tested Fedora-Workstation-Live-x86_64-Rawhide-20200712.n.0.iso and swaponzram is activated during early boot, for both the installation environment and in the installed system. When I reduce memory to trigger activation of anaconda's implementation, it consistently fails safely. This will get quite a lot of testing in openQA, since most of their VM's are provisioned with 2GiB RAM, and there is a moderate need for swap in this configuration. > >> >> About inst.zram >> https://github.com/systemd/zram-generator/issues/42 >> >> Another possibility is to just deprecate it. If swap is really not needed, >> zram device won't be used. There's no RAM preallocated for the zram device. >> If it is needed, it gets used on demand, and prevents reclaim. Pretty much >> win win. >> >> > > I have talked about it with the team and we prefer the deprecation of the > inst.zram option. The zram-generator can always introduce its own option if > there is a demand for it. OK I'll let the upstream zram-generator folks know. Thanks! -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
On Thu, Jul 9, 2020, 12:58 PM Chris Murphy wrote: > Use zram-generator instead of zram > https://pagure.io/fedora-comps/pull-request/513 > > Replace 'zram' with 'zram-generator', and exclude Cloud edition > https://pagure.io/fedora-kickstarts/pull-request/658 Those have been accepted. Anaconda PR #2723 and #2727 can happen anytime. About inst.zram https://github.com/systemd/zram-generator/issues/42 Another possibility is to just deprecate it. If swap is really not needed, zram device won't be used. There's no RAM preallocated for the zram device. If it is needed, it gets used on demand, and prevents reclaim. Pretty much win win. --- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
Use zram-generator instead of zram https://pagure.io/fedora-comps/pull-request/513 Replace 'zram' with 'zram-generator', and exclude Cloud edition https://pagure.io/fedora-kickstarts/pull-request/658 Obsolete zram package from zram-generator-defaults https://src.fedoraproject.org/rpms/rust-zram-generator/pull-request/3# I'll report back when these have been accepted, and then this can happen: Replace the zram service https://github.com/rhinstaller/anaconda/pull/2727 Thanks, -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
On Thu, Jul 9, 2020 at 11:20 AM Brian C. Lane wrote: > > On Thu, Jul 09, 2020 at 09:21:31AM -0600, Chris Murphy wrote: > > On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy wrote: > > > > I've opened an issue with upstream zram-generator folks. Igor suggests > > they could parse for 'inst.zram' or 'inst.nozram' and inhibit the > > creation of swap-on-zram. > > > > https://github.com/systemd/zram-generator/issues/42 > > In general I don't think it's a good idea to parse the cmdline for > parameters they don't control. Anaconda has a dracut module that does > various things during early boot which seems like a better place to deal > with inst.* options. OK. Is it possible for the dracut module to 'touch /etc/systemd/zram-generator.conf' if it sees 'inst.nozram' ? The presence of an empty file there will inhibit. Since this is early boot, it might be more appropriate to have this inhibit file in /run - I think that's also possible. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy wrote: > > One item I haven't worked through yet is how 'inst.zram' should > inhibit the zram-generator. The generator runs during early boot. > > My current thinking is 'inst.zram' can just 'systemctl stop > swap-create@zram0.service' since it will exist already. In that case > it could optionally be renamed to 'inst.nozram'. What do you think? > > I think the timing of the changes isn't very critical. If the release > images have zram-generator first, it will run sooner and the Anaconda > implementation will fail (error messages in logs, but otherwise > non-fatal). Whereas if the Anaconda implementations go away first, the > lack of swap on zram in low memory situations might cause problems. I've opened an issue with upstream zram-generator folks. Igor suggests they could parse for 'inst.zram' or 'inst.nozram' and inhibit the creation of swap-on-zram. https://github.com/systemd/zram-generator/issues/42 -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
On Thu, Jul 9, 2020 at 5:33 AM Vendula Poncova wrote: > > On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy wrote: >> >> Hi, >> >> I am confused. For default partitioning, the idea is to no longr >> create a swap partition, instead there will be both zram-generator and >> zram-generator-defaults packages, which will cause a swap on >> /dev/zram0 to be created during early boot. >> >> When I look in https://pagure.io/fedora-kickstarts all of the ks files >> that contain 'autopart' also contain '--noswap'. Yet Workstation >> edition and others, do have a swap partition created. Suggestions? >> > > Hi, > > the kickstart files from fedora-kickstarts are used for Fedora release > images. They don't define the default partitioning of new installations. Is > there a problem with the partitioning on these images? > > Default partitioning of new installations is defined in Anaconda: > https://github.com/rhinstaller/anaconda/blob/master/data/anaconda.conf#L16 OK, that about sums up my confusion. :) > The change seems to be approved. Can I open a pull request for the changes in > the Anaconda configuration files? Yes please, that will certainly save me more embarrassment. One item I haven't worked through yet is how 'inst.zram' should inhibit the zram-generator. The generator runs during early boot. My current thinking is 'inst.zram' can just 'systemctl stop swap-create@zram0.service' since it will exist already. In that case it could optionally be renamed to 'inst.nozram'. What do you think? I think the timing of the changes isn't very critical. If the release images have zram-generator first, it will run sooner and the Anaconda implementation will fail (error messages in logs, but otherwise non-fatal). Whereas if the Anaconda implementations go away first, the lack of swap on zram in low memory situations might cause problems. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
Hi, I am confused. For default partitioning, the idea is to no longr create a swap partition, instead there will be both zram-generator and zram-generator-defaults packages, which will cause a swap on /dev/zram0 to be created during early boot. When I look in https://pagure.io/fedora-kickstarts all of the ks files that contain 'autopart' also contain '--noswap'. Yet Workstation edition and others, do have a swap partition created. Suggestions? Thanks, Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
Hi, This change has been approved. There are still some details to work out. What do Anaconda folks think for the custom partitioning use case where the use manually creates disk-based swap? Should and could the installer then also do: 'touch /etc/systemd/zram-generator.conf' post install? The effect is to disable the zram-generator and there'd be only disk-based swap. The alternative outcome without this is they'll have both swap-on-zram with a higher priority than the swap-on-disk they created. I'm open to suggestions. I think it's mainly a question about what you think the user expects in this situation. That's hard to answer because the user expects disk based swap as a long standing convention. And there is no convention for either swap-on-zram yet, or two swap devices, even though the kernel has supported up to 32 swap devices since forever. The best experience performance wise would be to have the two swaps. They gain from swap-on-zram at first, and perhaps mostly. Followed by the secondary use of disk based swap. But I'm not opposed to disabling zram-generator in this case. It is a more conservative option and might better square with expectations. Thanks, Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
Also, just to underscore the scope of this feature. It does propose dropping the swap partition by default for all Fedora editions and spins. It would still be possible for users to create a (regular) swap-on-disk partition, and Anaconda would still add the appropriate resume=UUID= kernel parameter. This is item #3 in the summary. https://fedoraproject.org/wiki/Changes/SwapOnZRAM Vendula Poncova explains some things in this comment that relate to the installer UI and dropping the swap-on-disk partition by default. https://pagure.io/fedora-workstation/issue/121#comment-655592 Also related, and referenced in the feature, and posted to devel@ list: "Supporting hibernation in Workstation ed., draft 2" https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md It's short, maybe two pages with references. Idea is to summarize the most central issues and the way forward. The references lead to quite a lot of conversations and additional references. Also it's likely permanently a draft because, well things are always changing, the story doesn't yet have a conclusion. But in the meantime we need to move forward the best we can. --- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
On Tue, Jun 2, 2020 at 10:13 AM Chris Murphy wrote: > > Yeah it's hard to find. In koji it's rust-zram-generator metapackage; > but the actual command to try it out is 'dnf install zram-generator'. > I should have just pointed to this: https://fedoraproject.org/wiki/Changes/SwapOnZRAM#How_To_Test Right now there's a few steps, since the default is to not install a configuration file. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
On Tue, Jun 2, 2020 at 9:47 AM Martin Kolman wrote: > > Back when ZRAM support was introduced in the installation environment the > aim was to enable installations and specially the more memory hungry graphical > installations on devices and VMs with less RAM. For devices with enough RAM > the installation could run just fine & ZRAM would be just extra overhead, so > we decided not to enable it here. > > This was quite some time ago (6/7 years ago) and things certainly changed, > making the ZRAM overhead very likely totally negligible on current systems. Upstream zram doc claims the overhead is 0.1% of the /dev/zram0 device size. e.g. ~64M/64G. In practice I haven't seen it use more than 0.04%, but perhaps it has some float as the /dev/zram0 device is actually being used, for tracking. In any case it's not much. I don't want the /dev/zram0 device to be too big by default, just in case some workloads have unexpectedly low compressibility, and I'd like to be conservative in order to ideally make it possible to apply it to upgrades. And perhaps in F34 with new clean installs, get a bit more aggressive if actual usage with F33 suggests it's a good idea. > > So I think dropping the conditions we have at the moment and simply always > enabling ZRAM > with sensible configuration (like the IoT one mentioned above) should be fine. OK cool. > > > > > - Disable or somehow deprecate the Anaconda specific implementation, > > to avoid conflict and user confusion among the implementations. > IIRC we discussed using one of the scripts packaged in Fedora > (I think it was provided by systemd ?), ideally the one used by the other > tools that are part of this system wide change. We just have not did that > just yet. Yeah it's hard to find. In koji it's rust-zram-generator metapackage; but the actual command to try it out is 'dnf install zram-generator'. https://github.com/systemd/zram-generator > So I wonder if the image wide defaults change I guess it should be enough > if we coordinate dropping of our zram setup script at the same time the image > wide change is done ? Yes, I can help coordinate. I'll be doing the kickstart change to bring zram-generator and configuration file into the ISOs. Prior testing suggests two zram devices being created isn't a big deal, in practice they get different swap priorities, so only one will be used, there's just that 0.1% (or 0.04%) overhead for the unneeded extra /dev/zram device. Also it's not a preallocation. So if that scenario were to happen, it wouldn't cause openQA tests to face plant. The openQA tests I think are the most likely impacted, if there are two zram devices, since most of those VMs use 2G RAM and thus will trigger the anaconda implementation to also create a zram device. For most everyone else doing testing, they'll have more than 2G RAM for their VM or baremetal and are unlikely to run into this. Thanks! -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: F33: preview swap-on-ZRAM using zram-generator feature change
Found this: https://github.com/rhinstaller/anaconda/blob/master/scripts/zramswapon#L52 I'm not sure where that should live, if this script is removed. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
F33: preview swap-on-ZRAM using zram-generator feature change
Hi, I'm following-up now that there's a preview of the change proposal ready: https://fedoraproject.org/wiki/Changes/SwapOnZRAM Highlights: - This is a system-wide change, for all editions and spins. And if Anaconda folks are still agreeable, it would be included on all install media where Anaconda is found: DVD/Live/netinstall. - Fedora Workstation edition will no longer create swap-on-disk by default. Instead swap-on-zram will be used. I expect to get buy-in from other editions/spins to do the same. This applies only to the default/automatic partitioning path, as previously discussed. - Tentative (proposed) defaults similar to what's used by IoT: ZRAM device is 50% RAM, with a 4GiB cap. The max size, which is configurable, is to help scale ZRAM device size for more uses cases and hopefully settle on a single default Fedora wide. This is a bit different than Anaconda's implementation, which doesn't activate above 2GiB, and uses a 1:1 ZRAM to RAM ratio. Based on my testing, even VM's with 3GiB RAM still prefer to use quite a decent amount of swap ~200MiB. If it's available. I think this adjustment is neutral to slightly better for Anaconda. And in any case the installer and installed environments will have the same configuration and implementation as a result of the change. - Disable or somehow deprecate the Anaconda specific implementation, to avoid conflict and user confusion among the implementations. - Test day will be planned Critical feedback welcome. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
The language being used by Anaconda team suggests the "Btrfs is not a priority" and should be unsupported, is a decision that has already happened. This discussion, in this thread, is about how to handle that decision in UI/Ux. When and where did this decision get made? How do outside contributors get the information they need to know their efforts are worthwhile? I have hundreds of hours invested in Anaconda testing, perhaps 1/2 not related to Btrfs, over ~8 years. I would like answers to these questions. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
On Wed, Aug 28, 2019 at 1:07 PM Josef Bacik wrote: > > On Wed, Aug 28, 2019 at 03:01:16PM -0400, Josh Boyer wrote: > > Fedora chugs along at the rate of daily upstream Linus snapshots. If > > you're hitting and fixing issues before Fedora users see them, I'm > > curious why Fedora users would ever see them. > > > > Where does the lag come from? Are the fixes queued internally? > > Staged in an upstream subsystem tree? Is there a way for interested > > btrfs people to proactively just get those fixed in Fedora before > > users hit them? > > For this particular example we saw the problem in testing and had a patch on > the > mailinglist before you hit the problem. It was in a tree and sent to Linus, > and > was merged the day after the bugzilla was reported. So yes before users see > them, unless they are subscribed to the daily snapshots, which I assume is > just > for testing right? Or were you guys going to ship 5.3-rc0? > > On one hand I understand all of the consternation around making btrfs bugs > blockers for Fedora, but on the other hand it seems a bit silly to be having > this conversation at all based on hitting a bug that went into the merge > window > and then was fixed before rc1 was even cut. Thanks, It is silly, if it's really safe to say that Btrfs won't be the default file system in any release blocking deliverable. Having blocker status was always a means to that end. But right now it's maybe three (?) automated tests that depend on Btrfs working. If Fedora Workstation defaulted to Btrfs, that's dozens or even hundreds of tests? Adam? Bug fix was merged in rc2. The patch on linux-btrfs@ 25 Jul 2019 11:27:29 +0300 which is just before kernel-5.3.0-0.rc1.git3.1.fc31, 2019-07-25 21:01:20 Plausibly it was in all rc0 and rc1 kernels. What if this deadlock were happening in ext4 for all rc0 and rc1 kernels? What questions get asked? How did the bug not get caught by xfstests before it got into linux-next? Does anyone pop a gasket on lkml? Is this just a weird sometimes it happens rarely kind of thing? I don't know the exact nature of the bug, which goes to the kernel team's point that someone who does know needs to tell them the autopsy summary so they can really assess the default fs question. And another question for QA. If it were Btrfs by default for Workstation, would you just convert all the tests that rely only on ext4 now to Btrfs? Or duplicate those tests so you can run them in parallel? How much more testing is that and what's the impact on time and resources? -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 1:02 PM David Cantrell wrote: > > On 8/27/19 2:00 PM, Chris Murphy wrote: > > The Fedora working group's technical specification states Btrfs is to > > be the default. Yet the working group has said it's uncomfortable > > taking action on this decision expressly because the Federal kernel > > team's official recommendation is to not recommend Btrfs. And I agree. > > I trust the Fedora kernel team as they've clearly stated limited > > resources and interest in Btrfs, the expectations and parameters for > > properly supporting Btrfs either as bug blocker worthy, and as a > > default file system from a user advocacy point of view. > > OK, so 8 years has gone by and the landscape around btrfs looks > different in Fedora. Given the kernel team's position, is it worth > still having the FESCo decision and kernel team's recommendation at odds? They aren't at odds. 8 years ago FESCo decision on Btrfs 5 years ago Workstation working group decision on Btrfs (their requirements and specs docs were signed off by FESCo) 3 years ago kernel team said while they don't recommend it, they acknowledged it was ultimately up to the working group to decide, and noted they were sick of having this conversation every release The Workstation working group has, correctly in my view, put their own decision in abeyance, as a result of the kernel team's official recommendation. How does the Btrfs landscape in Fedora look different to you in three years? The way the landscape looks different to me: One, the possibility of getting a kernel engineer who works on Btrfs to join the Fedora kernel team, so that the team has the capacity to support and recommend (at least as a team, not that any individual needs to give up one tiny bit of their Btrfs scepticism) is an important development. Two, that in the interim, Red Hat is where the landscape has really changed has occurred with respect to Btrfs, and I see indications of this bias being injected back into Fedora: suggesting that a Red Hat shift away from Btrfs somehow is actually a Fedora shift away from Btrfs, suggesting a do over vote in the Workstation working group, or even an undo vote by FESCo to set aside the Workstation working group vote. And to what end? All that's needed is for the Anaconda team to provided the same courtesy of clear expectations and parameters, as the kernel team has done. > > >> If it's a best effort thing, then that makes it easier for > >> projects and contributors. Going back to Adam's original list, I would > >> suggest a FESCo decision like this should require explicit opt-in by the > >> user to enable btrfs functionality in the application in question. For > >> example, in the installer that could be enabled via a boot parameter (we > >> did this initially when btrfs functionality was first enabled in anaconda). > > > > That can only be considered to be a remarkable regression, not just in > > the context of Fedora, but in the context of the top 10 linux > > distributions all of which have visible Btrfs support in their GUI > > installers. Fedora's installer being the first to make Btrfs invisible > > by default would be a remarkable first indeed. > > I'm merely offering an example scenario. > > This does illustrate a problem with expectations among users. It's > visible now, but not a priority, which leads to frustration. Just like today's kernel team, Anaconda today are not obligated to make it a priority. But qualifying what "not a priority" actually means is necessary. The question is what are the preconditions for others who will make it a priority? And whether Anaconda is going to slow walk every PR that tries to improve Btrfs support? What about simplifying the Btrfs support in Anaconda to make it easier to maintain with priority parity with other file systems? Gut all the multiple device stuff, perhaps? Btrfs can easily do quite a lot of adjustments post-install, it's one of it's most central features. Few options are mkfs only. > >> I'm not advocating one way or another for btrfs. But it seems we as a > >> project need a larger decision and policy around btrfs in general so we > >> can set expectations for users and developers. > > > > That decision and policy has already been made. Do you want it reverted? > > I guess I meant to say "FESCo needs to revisit this decision for a > potential change". I can't parse this. Which decision, and what potential change? -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
References: FESCo, make Btrfs the default https://meetbot.fedoraproject.org/fedora-meeting/2011-06-08/fesco.2011-06-08-17.30.log.html Workstation working group's technical specification, make btrfs default https://fedoraproject.org/wiki/Workstation/Technical_Specification A point of reference that when LVM thinp was made release blocking, it was stated that usability issues are to be treated as bugs to be worked out https://meetbot.fedoraproject.org/fedora-meeting/2013-07-24/fesco.2013-07-24-18.00.log.html File system choice is up to the working group https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/CXW6IYIHETPS5U7IB2P6373FJDU2UAMB/ --- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
On Tue, Aug 27, 2019 at 11:25 AM David Cantrell wrote: > > The installer team rejecting btrfs patches is going to be based on their > resources to support the functionality. I would say "btrfs in Fedora" > needs a FESCo decision to set expectations and policy for the project. > Is it something that Fedora wants to offer and if so, what does that > look like? FESCo already voted 8 years ago to make Btrfs the default file system, and then allowed that to wither and become moot rather than revert the decision. Then later when the editions were created, part of Fedora.next, the decision of default file systems was handed to the working groups to decide. And the Fedora kernel team has also said this is a working group decision. The Fedora working group's technical specification states Btrfs is to be the default. Yet the working group has said it's uncomfortable taking action on this decision expressly because the Federal kernel team's official recommendation is to not recommend Btrfs. And I agree. I trust the Fedora kernel team as they've clearly stated limited resources and interest in Btrfs, the expectations and parameters for properly supporting Btrfs either as bug blocker worthy, and as a default file system from a user advocacy point of view. > If it's a best effort thing, then that makes it easier for > projects and contributors. Going back to Adam's original list, I would > suggest a FESCo decision like this should require explicit opt-in by the > user to enable btrfs functionality in the application in question. For > example, in the installer that could be enabled via a boot parameter (we > did this initially when btrfs functionality was first enabled in anaconda). That can only be considered to be a remarkable regression, not just in the context of Fedora, but in the context of the top 10 linux distributions all of which have visible Btrfs support in their GUI installers. Fedora's installer being the first to make Btrfs invisible by default would be a remarkable first indeed. > I'm not advocating one way or another for btrfs. But it seems we as a > project need a larger decision and policy around btrfs in general so we > can set expectations for users and developers. That decision and policy has already been made. Do you want it reverted? -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
On Mon, Aug 26, 2019 at 5:16 AM wrote: > I understand them. The point is, for them and even us (the installer) > is work on BTRFS not a priority. It's something we can't benefit on > RHEL and it could be almost completely replaced by LVM + xfs solution. > However, it still giving us bugs and making our test surface bigger. > > >From the Anaconda team PoV it would make our lives easier to not > support BTRFS at all. I'm not saying that we should drop BTRFS in > Fedora, only that it would be easier for Anaconda team to be without > that on Fedora. It would also be easier if Custom and Advanced partitioning UIs were dropped entirely. Most Linux distros now support Btrfs. All the top 10 do. One, currently ranked #7 Solus, supports it via a point and shoot installer, deferring to Gparted to actually set it up. All the others have a custom interface that supports Btrfs directly. Meanwhile, #23 Parrot uses Btrfs by default for home and root. And so does openSUSE for a while now. And the idea being floated, is that Fedora shouldn't have a sense of adventure, but to maybe drop Btrfs from the installer. Fedora would be the first, if it did. It is completely reasonable for Red Hat to have maintainability concerns about Btrfs for RHEL, and it's entirely fair for Red Hat to have a bias against it. If it were true that Red Hat is, however unintentionally, injecting its Btrfs bias into Fedora, that would be troubling. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
On Fri, Aug 23, 2019 at 1:44 PM Justin Forbes wrote: > > All of this, the criteria, and the UI support for btrfs are from the > many years old proposal to make btrfs the default filesystem. In the > beginning, it was not ready, but did show promise. This proposal came > up for several releases in a row, and at the end of it, even the > upstream developers recommended against it. Josef Bacik alone pushed for it. And it was Fedora that wasn't ready for Btrfs, not the other way around. In Josef's last couple emails to devel@ he stated the decision would need to be made by others, not him. He pretty much gave up once SUSE got there first. I'm not aware of any upstream developers recommending Fedora not use it. A significant chunk of upstream are at SUSE and by this time had moved to Btrfs by default, so it'd be a little weird if they're recommending against the thing. > At this point, it is safe > to say that btrfs will not be the default. Since that time, things > have not gotten better. This is ambiguous. One possible way to read this is: no matter what resources are put into supporting it in Fedora, it's safe to say it won't be the default. Another possibility: the support resources necessary haven't materialized, therefore it won't be the default. I would like to better understand why it is "safe to say" it won't be the default. > > Yes, there is active btrfs development > upstream. It is fairly narrowly focused, and not something we can > rely upon for a supported default among the Fedora use cases. The thread is ostensibly about whether it's appropriate to block release on Btrfs related bugs, not whether it should be the default file system. But as it's been brought up, I'd like to know if there's any difference in the expected support resources between it remaining "blocker worthy" versus becoming "a default file system" somewhere in the Fedora ecosystem in a release blocking capacity (i.e. presumably a Fedora Spin could choose to make Btrfs its default file system, but that wouldn't be release blocking). > While > Fedora does enable it in the kernel, and plans to continue doing so, > it is enabled in the "if you break it, you get to keep the pieces" > method of many other options. Sure, we will be happy to bring in a > patch that is headed upstream if it fixes a bug, and someone points us > to it. No, we aren't going to spend time debugging issues with it > ourselves. There is no shortage of issues in more "core" kernel > pieces that require attention. That's understandable and reasonable. I don't think anyone uninterested in supporting Btrfs should be made to feel like they ought to. Life is short, do what you're interested in doing, no more. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Discussion: what would not blocking on btrfs look like?
On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson wrote: > So, there was recently a Thing where btrfs installs were broken, and > this got accepted as a release blocker: > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388 Summary: This bug was introduced and discovered in linux-next, it started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch appeared during rc1, and the patch was merged into 5.3.0-rc2. The bug resulted in a somewhat transient deadlock which caused installs to hang, but no corruption. The fix, 2 files changed, 12 insertions, 8 deletions (1/2 the insertions are comments). How remarkable or interesting is this bug? And in particular, exactly how much faster should it have been fixed in order to avoid worrying about it being a blocker bug? 7/25 14:27 utc bug patch was submitted to linux-btrfs@ 7/25 22:33 utc bug was first reported in Fedora bugzilla 7/26 19:20 utc I confirmed upstream's patch related to this bug with upstream and updated the Fedora bug 7/26 22:50 utc I confirmed it was merged into rc2, and updated the Fedora bug So in the context of status quo, where Btrfs is presented as an option in the installer and if there are bugs they Beta blocking, how could or should this have been fixed sooner? What about the handling should have been different? I note here that ext2 and ext3 are offered as file systems in Custom/Advanced partitioning and in this sense have parity with Btrfs. If this same bug occurred in ext2 or ext3 would or should that cause discussion to drop them from the installer, even if the bug were fixed within 24 hours of discovery and patch? What about vfat? That's literally the only truly required filesystem that must work, for the most commonly supported hardware so it can't be dropped, we'd just be stuck until it got fixed. That work would have to be done upstream, yes? -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Fedora LiveOS, journal missing ~25s of early boot
Hi, Summary: On Fedora LiveOS, e.g. Fedora-Workstation-Live-x86_64-Rawhide-20190728.n.1.iso, the journal is missing the first 20-30s of all boot/startup related messages. The reason is a bit complicated, systemd-journald appears to have a bug wanting keep_free space too high, and Fedora's lives have had shrinking free space consistently over time as the "payload" gets bigger. The result is now systemd-journald almost immediately vacuums the first journal file, deleting it, causing the loss of early boot and startup messages. Why I think Anaconda team might care: LiveOS is inherently a non-deterministic environment for the installer, and losing a bunch of early boot and startup messages like all the liveos assembly, the overlay (whether dm or overlayfs based in the future), networking, udev and other non-kernel device discovery, and dracut debug messages - don't exist in the journal and quite a lot of such messages for whatever reason do not forward to console or kmsg when using systemd.journald.forward_to_X parameters. Therefore if the journal is deleted, the messages are flat out gone and any troubleshooting and introspection is really difficult. I proposed this as a blocker bug. https://bugzilla.redhat.com/show_bug.cgi?id=1715699 It's been rejected twice, mainly because the Fedora Basic Release Criterion for system logging applies to the post-installed system. It doesn't apply to any of the installer images. So there is a proposal over on test@ list to change the location of this requirement so that it applies to installer images. And I figured installer devs might have an opinion if this is blocker worthy. https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/message/QAV3I2W6337ZW7CSYJYAU2SY3GL4KI6F/ https://fedoraproject.org/wiki/Basic_Release_Criteria#System_logging -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: "enabling zram.service on LiveOS boots"
On Wed, Jun 19, 2019 at 10:33 AM Brian C. Lane wrote:
>
> On Wed, Jun 19, 2019 at 01:24:27PM +0200, jkone...@redhat.com wrote:
> > Hi Chris,
> >
> > There has to be change in the live media creation. Anaconda don't have
> > power on what is booted on Live DVD.
> >
> > I think the Fedora kickstart used to create the DVD Live image is the
> > change target here. That kickstart should enable the service so it will
> > be auto-started during the Live DVD boot. However, if we do that then
> > the service will be also enabled on the installed system which is
> > probably not what we wanted to do...
>
> Correct. The place to enable it would be in the livesys script that the
> %post section writes. But I'm not sure if that's too late in the boot
> process for it to be useful. As long as it is just started, not enabled,
> from the script it should only run when booting the live iso and not the
> installed system.
Or can Anaconda just 'systemctl start zram.service' when it's
launched, whether on Live or netinstall?
The problems I'm seeing only in low memory situations, doesn't arise
until Anaconda launches. So it's fine if 'systemctl start
zram.service' happens late.
Looks like the change would go in
https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-base.ks
It contains this section:
110# enable swaps unless requested otherwise
111swaps=\`blkid -t TYPE=swap -o device\`
112if ! strstr "\`cat /proc/cmdline\`" noswap && [ -n "\$swaps" ] ; then
113 for s in \$swaps ; do
114action "Enabling swap partition \$s" swapon \$s
115 done
116fi
117if ! strstr "\`cat /proc/cmdline\`" noswap && [ -f
/run/initramfs/live/\${livedir}/swap.img ] ; then
118 action "Enabling swap file" swapon
/run/initramfs/live/\${livedir}/swap.img
119fi
Umm, anyone got any opinions on removing that whole thing?
a) I don't really see the point of using some legacy swap partition
that the installer has some chance of needing to turn off in order to
modify partitioning or what have you?
b) Silently activating a persistent swap is a security leak for LiveOS
users, unless testing for encryption or setting up /dev/urandom key
based encryption for it.
Also, there is a package, zram-0.3-1.fc30.noarch, which is more
recently developed and intended to be generic use. Any chance of
deprecating the anaconda zram stuff and depending on this zram package
instead?
https://src.fedoraproject.org/rpms/zram/tree/master
Last, it looks like the systemd folks want to turn all of this into
native systemd units, and get rid of the livesys script entirely.
--
Chris Murphy
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
"enabling zram.service on LiveOS boots"
Hi, Fedora Workstation WG agreed some time ago to enable zram.service when booting LiveOS, which is already the behavior for netinstalls. https://pagure.io/fedora-workstation/issue/56#comment-546837 How should this be done? On netinstall boot I see zram.service is loaded, active, and executed /usr/libexec/anaconda/zramswapon by I think anaconda itself starts this service. On LiveOS boot I see zram.service is loaded, inactive. I thought about changing zram.service to add ConditionKernelCommandLine=rd.live.image But that'd break the netinstall case. It could also be done by making only the LiveOS kernel command line include 'systemd.wants=zram.service' And still another option is I'm seeing there are two of these, at least in Rawhide Lives. [root@localhost-live ~]# systemctl list-unit-files | grep zram zram-swap.servicedisabled zram.service static [root@localhost-live ~]# zram.service is part of the anaconda package, and zram-swap.service is part of zram-0.3-1.fc30.noarch It's not yet determined if installed Workstation systems will change default behavior to swap on zram, zswap, or something else. Thanks, -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda crashes on Rawhide since December
Bug 1524700 - AttributeError: 'NoneType' object has no attribute 'name' (edit) https://bugzilla.redhat.com/show_bug.cgi?id=1524700 This is still a bug in Fedora-Workstation-Live-x86_64-Rawhide-20180204.n.0.iso, and every ISO I've tested for over a month; and this bug was filed back in December. Near as I can tell, no one's been able to do live installations of Rawhide in about two months. I can reproduce it in a clean virt-manager VM, and on baremetal. Does this bug need info to get it fixed? I'm unclear what the hold up is. Thanks, -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
logging mount assembly and bootloader install, chroot missing?
The program.log shows mount commands for assembly, followed by installation itself copying files to a path prefix /mnt/sysimage, and then bootloader setup. Isn't there a chroot happening before the bootloader setup? It's not in the log so I'm having some difficulty exactly replicating an installation environment while troubleshooting this bug: So the questions are: Is there a chroot? Is there a way to discover the command being used? And if there is a chroot, is there a way to log this command in the future? https://bugzilla.redhat.com/show_bug.cgi?id=1289752 Thanks, -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: /boot/efi size, 260MiB minimum for FAT32 ESP) -- WAS: /boot size
On Mon, Apr 18, 2016 at 12:28 PM, Bryan Smith <b.j.sm...@ieee.org> wrote: > Brian C. Lane wrote: >> It's probably worth filing a bug about. > > Yeah, I might file a bug that is a bit "more broad," especially after > Chris Murphy pointed out his [bz#1046577]. > > E.g., in addition to 1046577#c3 from Adam on the spec, even #c1 from > Rod Smith (of rEFInd et al. fame) pointed out that some uEFI > implementations take issue with various FAT32 ESP sizes that aren't at > least 512MiB too, well beyond the 4KiB logical sector requirements of > 260MiB. I'd find the missing "EFI file system" document, or confirm it doesn't exist, before planning work. The UEFI spec uses imprecise language, it doesn't say "FAT32 must be used on internal drives" it says it should be used on system partitions. Well all of these things are system partitions. Later it says the firmware should support all three FAT variants, so does it really matter if it's all mixed and matched? > So ... where do we "draw the line" on what situations Anaconda should > deal with? And how much development should I expect to sack you guys > with? Maybe mkdosfs -E just makes the proper "EFI file system" instead of pure FAT, whatever that difference is. And still takes options from something else. That something else could be storaged? I can predict people will break these ESPs beyond repair, they're mounted persistently all the time on Linux and if there's a crash they're really not crash tolerant for some time (minute? minutes?) after the last modification. > > Now add in my totally non-Linux comment that in multi-boot > configuration, where Windows is expected, Microsoft expects an 0C01h > (msftres) partition, and ideally (per OEM guides for Windows x64 > version 7, 8 and now 10), it should be after the ESP (#1 and #2, or #2 > and #3 if there is a "Tools" in #1). > > Yeah, this we'll get out-of-control if we try to accommodate every > situation, every uEFI misdesign, the uEFI spec and even multi-boot > with non-Linux. > > So ... might I have a suggestion? > And if you like it, I'll file the RFE myself, with the justification. > > How about we solve this with a checkbox ... or two? > > Suggested Checkbox One: > [ ] Other OSes (including Windows x64) will also be installed > Conditions ... (i.e., don't show checkbox unless met) > - Native 64-bit uEFI Storage Services > - Drive is being wiped w/EFI System Partition (ESP) created > Results ... > - Part 1:1-384MiB EF00h (esp) FAT32 = 383MiB (>260MiB) > - Part 2: 384-512MiB 0C01h (msftres) = 128MiB > > Suggested Checkbox Two: > [ ] Create a large EFI System Partition (ESP) > Conditions ... (i.e., don't show checkbox unless met) > - Native 64-bit uEFI Storage Services > - Drive is being wiped w/EFI System Partition (ESP) created > Results ... > - Part 1:1-640MiB EF00h (esp) FAT32 = 639MiB (>512MiB) > And if first checkbox selected, also ... > - Part 2: 640-768MiB 0C01h (msftres) = 128MiB You want to support installing Windows after Fedora? Why? I don't know what "Native 64-bit uEFI Storage Services" means or how that affects the use case. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: /boot/efi size, 260MiB minimum for FAT32 ESP) -- WAS: /boot size
On Fri, Apr 15, 2016 at 6:16 PM, Bryan Smith <b.j.sm...@ieee.org> wrote: > Ross Smith wrote: >> I don't think it will be an issue. I've already been bitten by this with a >> ~1300 efi booted desktops and would welcome the updated >> configuration. > > Speaking of which ... > > Q: Shouldn't we be using 260MiB FAT32 as a minimum EFI System > Partition (ESP) size going forward, especially as 4KiB logical blocks > become regular? Well, mkdosfs defaults to FAT16 and 4K cluster size on a 200M partition, so that should continue to work, even though the UEFI spec says to use FAT32 on system partitions. So chances are doing nothing isn't going to break anything. In practice, both Windows and OS X use FAT32, but they also use cluster sizes smaller than 4K. Presumably both of them will transition to 256+M EFI system partitions, rather than use FAT16. > > > o Just some history (detail) ... > > - For NT6.0 (Vista), Microsoft recommended (and its installers > created) a 200MiB FAT32 ESP > - This size has seemingly "stuck" with most distros, even though ... > - For NT6.1+ (7+/2008+), Microsoft recommended (and its installers > created) a 100MiB FAT32 ESP > However ... > - If the logical block size is 4KiB, the smallest FAT32 file system is 260MiB > Although ... > - The ESP can be FAT16 (just like good'ole ARC) instead of FAT32 > - Every ESP I've used, including Windows 7 and 8 x64, seems to install > fine on a FAT32 ESP > > Hence why I'm bringing it up. Just curious if there has been much > discussion on this. I did some google searches on the archives and > couldn't find anything. https://bugzilla.redhat.com/show_bug.cgi?id=1046577 https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ and maybe https://www.redhat.com/archives/anaconda-devel-list/2014-July/msg2.html Ideally there'd be an -E flag for mkdosfs to deal with this. The UEFI spec says firmware is expected to support FAT32, FAT16, and FAT12 so it probably doesn't matter that the spec also says the system partition (non-removable) should be FAT32, where only removables get FAT16 or FAT12. The other thing -E would make possible is ensuring the proper invariant "EFI file system" is what's actually being created, rather than pure FAT. -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Blocker status of RHBZ #1033778 (shrinking unknown volumes)
lt partitioning layout now in use on that OS, and then the user proceeds with resizing this unknown partition for whatever reason. Fix it whenever you want. Maybe someone beats you to it. And consider trusting QA to make it a blocker at some point if more users hit it. I don't really see a problem with that method of making it not an immediate blocker for this release. https://fedoraproject.org/wiki/Blocker_Bug_FAQ -- Chris Murphy ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
