Re: dmesg restricted to root in Rawhide
On Wed, Feb 28, 2024, at 6:45 AM, Peter Robinson wrote: > On Wed, 28 Feb 2024 at 13:38, Barry Scott wrote: >> >> >> >> On 28 Feb 2024, at 10:24, Karel Zak wrote: >> >> You can restore the original behavior by using: >> >># sysctl kernel.dmesg_restrict=0 >> >> However, be aware of the security consequences ;-) >> >> >> Given I can get the same information from journalctl -k what is the >> improvement? > > I believe you need to be in the wheel group to get that info from > journalctl I'm in the wheel group as is everyone else by default installing Fedora. A vast majority of Fedora users have this peculiar UX where `journalctl -k` not not require `sudo` but `dmesg` does require it. I think that's annoying and weird. -- Chris Murphy -- ___ 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: Donate 1 minute of your time to test upgrades from F39 to F40
package "baekmuk-ttf-hline-fonts" No match for group package "mplayer-gui" No match for group package "nafees-pakistani-naskh-fonts" No match for group package "nafees-riqa-fonts" No match for group package "nafees-web-naskh-fonts" No match for group package "baekmuk-ttf-batang-fonts" No match for group package "samyak-tamil-fonts" No match for group package "samyak-devanagari-fonts" No match for group package "layla-diwani-fonts" No match for group package "layla-arcyarc-fonts" No match for group package "eosrei-emojione-fonts" No match for group package "nafees-tehreer-naskh-fonts" No match for group package "layla-basic-arabic-fonts" No match for group package "layla-digital-fonts" No match for group package "google-noto-looped-thai-fonts" No match for group package "lohit-tamil-classical-fonts" No match for group package "cdac-sakal-marathi-fonts" No match for group package "kalapi-fonts" No match for group package "lohit-malayalam-fonts" No match for group package "baekmuk-ttf-gulim-fonts" No match for group package "gstreamer1-plugins-bad-nonfree" No match for group package "multican" No match for group package "layla-boxer-fonts" No match for group package "google-noto-sans-phags-pa-fonts" No match for group package "nafees-pakistani-web-naskh-fonts" No match for group package "layla-thuluth-fonts" Error: Problem: conflicting requests - package libva-intel-media-driver-24.1.3-1.fc40.i686 from fedora conflicts with intel-media-driver provided by intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree - package libva-intel-media-driver-24.1.3-1.fc40.x86_64 from fedora conflicts with intel-media-driver provided by intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree - problem with installed package intel-media-driver-23.4.3-1.fc39.x86_64 - intel-media-driver-23.4.3-1.fc39.x86_64 from @System does not belong to a distupgrade repository (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) -- Chris Murphy -- ___ 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: Donate 1 minute of your time to test upgrades from F39 to F40
On Wed, Feb 21, 2024, at 6:47 PM, Chris Murphy wrote: > > > On Wed, Feb 21, 2024, at 12:11 AM, Miroslav Suchý wrote: >> >> >> Do you want to make Fedora 40 better? Please spend 1 minute of your time and >> try to run: >> >> # Run this only if you use default Fedora modules >> # next time you run any DNF command default modules will be enabled again >> # This is last time we should do that :) >> >> >> sudo dnf module reset '*' >> > > Uhh haha :) > > $ sudo dnf module reset '*' > Last metadata expiration check: 0:03:30 ago on Wed 21 Feb 2024 06:41:04 PM > MST. > Unable to resolve argument * > Error: Problems in request: > missing groups or modules: * OK I'm just going to ignore this since I'm not using any module profiles or streams. -- Chris Murphy -- ___ 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: Donate 1 minute of your time to test upgrades from F39 to F40
On Wed, Feb 21, 2024, at 12:11 AM, Miroslav Suchý wrote: > > Do you want to make Fedora 40 better? Please spend 1 minute of your time and > try to run: > > # Run this only if you use default Fedora modules > # next time you run any DNF command default modules will be enabled again > # This is last time we should do that :) > > sudo dnf module reset '*' > Uhh haha :) $ sudo dnf module reset '*' Last metadata expiration check: 0:03:30 ago on Wed 21 Feb 2024 06:41:04 PM MST. Unable to resolve argument * Error: Problems in request: missing groups or modules: * -- Chris Murphy -- ___ 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: Figure out what killed an app (rhbz#2253099)
On Wed, Jan 31, 2024, at 11:40 AM, Paul Grosu wrote: > > > https://github.com/facebookincubator/oomd/ > > 2) Or you can completely disable it: > > https://www.cjjackson.dev/posts/what-is-systemd-oomd-how-to-disable-it/ We need bug reports to get it fixed rather than disabling it, if it's causing things to get clobbered that shouldn't be. The kernel OOM killer is strictly concerned about kernel survival in dramatically low memory situations. It is unconcerned about user space making progress. Hence user space oom managers. I admit this is probably suboptimal in some cases. Full resource control is a better way of handling the ambiguity whether a program is incorrectly hogging resources versus simply doing its job. Resource control may not obviate a user space oom killer but I think what we really care about is giving a program all the resources it needs, up to the point that the user wants an interactive desktop - and then the kernel needs to (in effect) preempt the resource hungry processes in favor of user-desktop interactivity. Resource control can do this but we don't have everything wired up yet, more work is needed. -- Chris Murphy -- ___ 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
troff noise when grepping man page?
$ man 5 btrfs | grep enospc enospc_debug, noenospc_debug troff::870: warning: cannot select font 'C' troff::888: warning: cannot select font 'C' troff::905: warning: cannot select font 'C' troff::924: warning: cannot select font 'C' troff::962: warning: cannot select font 'C' troff::977: warning: cannot select font 'C' troff::999: warning: cannot select font 'C' troff::1013: warning: cannot select font 'C' troff::1168: warning: cannot select font 'C' troff::1184: warning: cannot select font 'C' troff::1259: warning: cannot select font 'C' troff::1275: warning: cannot select font 'C' troff::1293: warning: cannot select font 'C' troff::1354: warning: cannot select font 'C' ...snip... This seems new with Fedora 39. The root file system is newly installed not an upgrade, but the ~/ is positively ancient (possibly 5 years). Any ideas what's going on, how to get more information, and what component to file a bug against? -- Chris Murphy -- ___ 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
kdump enabled in F39
Hi folks, I'm having some difficulty tracking down why it's being enabled on Fedora 39 but not on Fedora 38. On both Fedora 38 and 39, /etc/kdump.conf contains auto_reset_crashkernel yes However, I've never seen the reported behavior until Fedora 39. While the crashkernel parameter is being set on the kernel command line, the kdump.service unit is disabled. I don't know how these things interact, so I don't know how big a deal the issue is. Maybe it's just wasted space on the kernel command line? In any case, eventually it will clutter up the command line for everyone once they update their kernel because this parameter will be added. And I don't know how we fix it with an update because it means stepping on everyone's /etc/kdump.conf - without a way of knowing if they want this or some other setting applied. https://bugzilla.redhat.com/show_bug.cgi?id=2243068 Thanks, -- Chris Murphy ___ 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: btrfs loses 32-bit application compatibility after a while
On Thu, Jul 20, 2023, at 11:55 AM, Florian Weimer wrote: > * Demi Marie Obenour: > >> From this thread, it appears that non-LFS 32-bit software is fundamentally >> unsupportable in the long run, just like software with 32-bit time_t is >> unsupportable. That leaves two options: >> >> 1. Break the ABI, preferably in such a way that causes non-LFS >>code to fail at load time rather than crashing. >> >> 2. Drop 32-bit support from the distribution altogether. >> >> It looks like trying to keep 32-bit non-LFS software working will be an >> endless time sink and is not sustainable in the long term. > > My impression is different. It's btrfs that is a poor choice for people > who want to run 32-bit software, have a lot of file creations/deletions, > and do not want to reformat and reinstall periodically. The situation > with XFS, for example, is different because you can supply the inode32 > mount option and get 32-bit applications going again, maybe after making > in-place copies of a few files. It should be straightforward to have mock create a subvolume for each chroot instead of a directory. Subvolumes have their own inode pool. Mock already knows how to delete btrfs subvolumes, which is quite a lot more efficient than calling unlinkat() per file and directory. For the many files created and deleted workflow, I think it's worth taking advantage of this. In the meantime, whatever parent directory is used for the chroots could be swapped out with a subvolume for a short term work around. It doesn't sound like the problem happens very quickly. -- Chris Murphy ___ 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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
On Thu, Jul 20, 2023, at 9:53 AM, Daniel P. Berrangé wrote: > What's the downside from full pre-empt that makes it inappropriate > as the defualt for Fedora server spins too ? Is it that it is > trading off overall peak performance in favour of reduced latency, > and we think servers would prefer the peak performance in general ? Maybe. But I'm not aware of any recent data one way or the other, certainly nothing Fedora specific. I don't expect full preemption will impact servers in any meaningful way. I just can't prove that. -- Chris Murphy ___ 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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
On Thu, Jul 20, 2023, at 9:51 AM, Michael Catanzaro wrote: > On Wed, Jul 19 2023 at 06:50:24 PM -0400, Chris Murphy > wrote: >> If restricted to desktops, then we can only do it with kernel >> parameters. That probably means doing it in Anaconda kickstart, with >> a per edition/spin option for doing so. > > I'm not fond of this solution. In practice, this would likely mean the > new preemption mode would apply only to new installs and not also to > upgraded systems, right? Probably. A grubby command could add the proper kernel parameter to the bootloader configuration, but grubby isn't being used anywhere in Fedora (not anaconda for initial installs, not when installing kernel upgrades) so it isn't being exercised. The more users customize, the less likely grubby is going to detect their use case and fail gracefully. grubby would need to have a strict "only add new parameter" option. Right now it also replaces the kernel command line with the contents of /etc/kernel/cmdline to all bootloader snippets in /boot/loader/entries - including snippets for other OS's, which would be bad. -- Chris Murphy ___ 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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
On Wed, May 24, 2023, at 2:12 PM, Chris Murphy wrote: > On Sat, May 20, 2023, at 4:43 PM, Demi Marie Obenour wrote: > Therefore, I am >> asking if Fedora should use full kernel preemption by default. > > https://pagure.io/fedora-workstation/issue/228 > > The outstanding questions: > > a. Do we need some tests that help decide this with metrics? If so what > should those be? > b. Should it be restricted to the desktop edition/spins? Or Fedora wide? > c. How do we make the change? > > I have no ideas for a.) and I don't know what would be a sufficient > sample of workloads across all of Fedora; or whether to separately test > the different editions. > > I think if the answer to b.) is it should be Fedora-wide, means there's > more pressure to answer yes to a.) > Whereas if it's focused on desktops, perhaps less testing is needed? I lost track of this so unfortunately there's no Fedora 39 proposal. If the only comparison is preempt full vs voluntary, that's a simple A vs B test to run a pile of benchmarks against. The question then is what set of benchmarks do we want to use for this? We could use the Phoronix test suite. At least we'd get an idea if the change would result in bad press (everyone laugh at the silly bad joke). https://github.com/phoronix-test-suite/phoronix-test-suite Otherwise I don't have any ideas what would be a suitable test suit. And also still unanswered is if the change should happen Fedora wide or restricted to desktops. If restricted to desktops, then we can only do it with kernel parameters. That probably means doing it in Anaconda kickstart, with a per edition/spin option for doing so. For this issue to progress, it needs one or more co-owners to help get it turned into a feature for Fedora 40. -- Chris Murphy ___ 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: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On Mon, Jun 26, 2023, at 7:09 PM, Jiri Konecny wrote: > Dne 26. 06. 23 v 20:39 Hans de Goede napsal(a): >> Says 2G is the supported minimum. It would be good to see if >> that can actually be made to / kept working. >> >> Has anyone already tested the new installer on a system with its >> RAM limited to 2G ? > If you need low memory footprint you probably don't want to use Live > image for installation. It's the biggest one because it needs to have > whole Gnome environment in memory. For that, I would suggest you to use > Fedora Server network installation ISO. I recommend Everything netinstaller for the desktop use case. It's also a netinstaller, but the partitioning defaults are the same as Workstation edition. It's not that easy to find with the new web site design. It's in alternative downloads. I had to web search to find it. But it is the first option on that page. https://alt.fedoraproject.org/ -- Chris Murphy ___ 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: SecureBoot certificates
On Wed, Jun 14, 2023, at 7:20 PM, Kevin Kofler via devel wrote: > Chris Murphy wrote: >> OK I tried this again and discover shim is signed twice. >> >> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, >> CN=Microsoft Corporation UEFI CA 2011 >> Not Before: Sep 9 19:40:20 2021 GMT >> Not After : Sep 1 19:40:20 2022 GMT >> >> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, >> CN=Microsoft Corporation Third Party Marketplace Root >> Not Before: Jun 27 21:22:45 2011 GMT >> Not After : Jun 27 21:32:45 2026 GMT > > Are you sure those are 2 independent signatures and not a signature chain? No idea. -- Chris Murphy ___ 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: SecureBoot certificates
On Wed, May 31, 2023, at 1:31 PM, przemek klosowski via devel wrote: > I also have a recently updated F38 with shim-x64-15.6-2.x86_64. The > BOOTX64.EFI file has two certificates Ha! Yeah so I'm just repeating what you said two weeks ago. I don't have an explanation for the dual signatures, whether or not it's a problem. -- Chris Murphy ___ 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: SecureBoot certificates
OK I tried this again and discover shim is signed twice. Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 Not Before: Sep 9 19:40:20 2021 GMT Not After : Sep 1 19:40:20 2022 GMT Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root Not Before: Jun 27 21:22:45 2011 GMT Not After : Jun 27 21:32:45 2026 GMT This is the same for EFI/fedora/shimx64.efi and EFI/BOOT/BOOTX64.EFI which also have the same sha256sum hashes. So maybe there isn't actually a problem other than it's confusing that there are two signatures that also have different validity periods? I'm not sure what it means. -- Chris Murphy ___ 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: SecureBoot certificates
On Fri, May 26, 2023, at 10:20 AM, Steve Grubb wrote: > sbattach --detach signature /boot/efi/EFI/BOOT/BOOTX64.EFI > openssl pkcs7 -inform DER -in signature -text -print_certs > shim-certs.txt > > Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, > CN=Microsoft Corporation UEFI CA 2011 > Validity > Not Before: Sep 9 19:40:20 2021 GMT > Not After : Sep 1 19:40:20 2022 GMT What version of shim do you have installed? What edition/spin are you using? I have shim-x64-15.6-2.x86_64 and it's reporting Not Before: Jun 27 21:22:45 2011 GMT Not After : Jun 27 21:32:45 2026 GMT A possible explanation is rpm-ostree derivatives may show a current version grub and shim, but those are not copied to the EFI System partition. That's the job of bootupd but I'm not sure if that's fully implemented yet in Fedora. -- Chris Murphy ___ 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: Election Status?
On Wed, May 24, 2023, at 2:55 PM, Peter Boy wrote: >> Am 24.05.2023 um 20:30 schrieb Chris Murphy : >> >> I'm pretty sure we no longer have a program manager? > > What’s that about? As I understand it, part of recent Red Hat layoffs. Red Hat and Fedora program/project managers were impacted. And also no emails or matrix messages from Ben Cotton in two weeks. He is the one who announces elections and sets up that whole system, reports the results, updates everything related to the subsequent changes, etc. That's all I know. -- Chris Murphy ___ 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: more distinct default bash prompt?
On Tue, May 23, 2023, at 1:08 AM, Jens-Ulrik Petersen wrote: > On Tue, May 23, 2023 at 12:47 PM Neal Gompa wrote: >> I actually would prefer that we color both, and make it obvious that >> "root" is special. We should account for common color-blindness >> issues, though. > > Sure, I think I agree: perhaps purple for root? I think if we avoid the need to distinguish between redish and greenish, it's OK. Redish includes red, pink, magenta. Greenish includes green, cyan, sky blue. Ergo, you can use green or red, you just don't want to make the A vs B red and green because they will look the same to anyone with a red/green color discrimination limitation. Much less common is blue/yellow. I don't have data handy but off the top of my head, tritonopia and tritonomaly cases will notice the difference between purple vs orange OK. We do have publicly available math to predict the discrimination of various nopias and nomalies; I'm not sure exactly how it's implemented in GIMP but there is a "color deficient vision" filter should give an adequate idea whether or not a design has expected/sufficient/desired differentiation of elements based on color. (We don't actually know what anyone's color experience is, as it turns out. That's what I mean by this.) https://docs.gimp.org/2.10/en/gimp-display-filter-dialog.html > > I am all for "color blind testing" (though I am not completely sure that > "color-blind" is the right term here > though I am not an a11y expert - I thought color blind is more about > differentiating different colors like green and red, > but if you mean visual impairment/contrast/readability then I completely > agree). It's common vernacular. But it's more interesting than this term because it suggests one variety or effect. There are more than several. If we consider "color blind" means total lack of color discrimination, or monochromat - they are rare. I don't even know the number. Dichromats are much more common, where these are broken down into whether it's the long, medium, or short wavelngth cone is missing (entirely). The world does have some color, we think, at least there's discrimination possible. But it's of course limited without a third color receptor. Quite a lot more common are tricromats with anomalous spectral sensitivity of one of the receptors, i.e. the long wavelength cone might be green shifted, so it's more sensitive to yellows than the "standard observer". This then questions the whole age old concept of the standard observer, and for a while now it's been suspected we need more than one standard observer - because, well, they did all these tests in the early 1900's with something like 50 people. Seriously. And that's the data still largely used today. Anyway... I tend to call it a color discrimination variance. Or limitation. Oh and there are such folks as quadchromats. They have four color receptors. And then still there's the entire non-human animal kingdom full of completely different receptor peak wavelenth sensitivities, including tetrachromats and pentachromats. > I think in the end it will come down also to wider user testing since there > are so many different terminals > and color palettes around. > > Anyway that's why I proposed green since it seems to have reasonable contrast > for both light and dark terminals (unlike blue/cyan/yellow often). > I assume that may also be why Ubuntu and Nixos went with green. Green is an efficient color choice. It tends to appear to the brightest. Part of this relates to the luminosity function of human vision which has a peak wavelength that happens to be the same as the medium wavelength photo receptor (i.e. green). So given the same amount of radiant energy emitted across the visible spectrum, green will appear to be the brightest. Light purple is OK, Blue, indigo, or yellow tends to be harder to to detect complex shapes (like letters and numbers) but I'm not sure of the reason(s). -- Chris Murphy ___ 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: Election Status?
On Wed, May 24, 2023, at 12:03 PM, Tom Stellard wrote: > Hi, > > According to the schedule[1], the voting period was supposed to begin > on Friday, but elections.fedoraproject.org does not list any open elections > yet. Does anyone have an ETA for when voting will start? I'm pretty sure we no longer have a program manager? So I'm kinda expecting a lot of things to just silently break. I don't know what the fallback plan is. -- Chris Murphy ___ 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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
On Sat, May 20, 2023, at 4:43 PM, Demi Marie Obenour wrote: Therefore, I am > asking if Fedora should use full kernel preemption by default. https://pagure.io/fedora-workstation/issue/228 The outstanding questions: a. Do we need some tests that help decide this with metrics? If so what should those be? b. Should it be restricted to the desktop edition/spins? Or Fedora wide? c. How do we make the change? I have no ideas for a.) and I don't know what would be a sufficient sample of workloads across all of Fedora; or whether to separately test the different editions. I think if the answer to b.) is it should be Fedora-wide, means there's more pressure to answer yes to a.) Whereas if it's focused on desktops, perhaps less testing is needed? Still another strategy might be to just make preempt full the default Fedora wide in Rawhide with enough advance notice (like, nowish or soon after Fedora 39 branches). And once it starts causing issues, revert. That's a bit spaghetti on the wall test strategy but it's also cheap. (I am aware this is not a good strategy for testing doneness of spaghetti.) Regarding c.) gets tricky if it's not Fedora wide. The simplest case is, the change applies only to desktops, everything else remains on voluntary. The only way I'm aware of we can change it on the desktops is to set a kernel parameter. This means we need to have Anaconda set it as a boot parameter, but only for desktops. There is a debugfs facility for changing it during runtime, but this is not reliable due to debugfs being disabled when kernel lockdown is in place, which is tied to Secure Boot being enabled. Hence, the lkml thread referenced in the issue. But the lkml thread went no where (no responses). Possibly it wasn't provocative enough. Or simply there are no plans to expose this switch anywhere else. https://lkml.org/lkml/2023/4/11/1291 Conversely if even two other Fedora editions/spins/variants want some kind of opt out or opt in, it quickly gets tricky to do all that unique work setting a boot parameter, rather than just flipping the default across the board and not having a boot parameter. Anyway, it seems like it would be semi-straightforward to do it in Anaconda just for desktops using kickstart `bootloader --append=` command. https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#bootloader -- Chris Murphy ___ 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)
On Wed, May 10, 2023, at 7:36 PM, Owen Taylor wrote: > > > On Wed, May 10, 2023 at 5:34 PM Chris Murphy wrote: >> __ >> >> >> On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote: >>> >>> >>> On Wed, May 10, 2023 at 12:02 PM Neal Gompa wrote: >>>> >>> Now, there's a second problem with reading everything from the ESP - it's >>> slow for two reasons. First, because read speeds when going through the >>> firmware are much slower than the Linux NVMe stack. And second, because we >>> have to read everything in order to checksum and verify it. >>> >>> For that reason, Demi's suggestion of moving things onto a dm-verity >>> protected partition is intriguing. Could that even be a loopback file on >>> the ESP? It would be like a lazy-read system extension. >>> >>> The performance geek in me thinks "we could see exciting speedups from >>> that!" - the practical side of me thinks "it might be a few second faster. >>> And much more complex! Let's just go with efifb, keep the initramfs small, >>> and accept any minor regressions". >> >> GRUB doesn't support dm-verity, but I don't know if it would make a >> difference if it did. Once the kernel has the ability to interact with >> physical storage, understand partitions, initialize dm-verity, and read a >> file systemt... it could just mount `/` . I think the only way the current >> initial root file system works with the kernel is for the bootloader to read >> an entire initrd file into RAM, and then the kernel can randomly access >> things in that RAM disk. > > In this idea, the dm-verity parition/file would only be accessed from the > initrd, once we have enough kernel to ability to interact with physical > storage, understand partitions, initialize dm-verity, and read *a* partition, > but potentially not enough to read from a bluetooth keyboard, show a > graphical prompt, mount / from the network, etc. > > What dm-verity provides here is a way to trust content without requiring it > to be read ahead of time, checksumed, signature checked and put into ram. > > To be clear, I don't think this is necessarily the right way to go - I think > using efifb, not prompting for a passphrase when possible, etc, are simpler > approaches. OK got it. So it would be some kind of intermediate /usr that bridges between initramfs and /sysroot mounting? I'm not sure the added complexity helps significantly with authenticity over either LUKS or fscrypt. > >> >> It's early still for UKI details but I assume we will need both a universal >> UKI (all use cases), and much smaller use case focused UKIs. I say that >> because the desktops in the default installation configuration are the >> largest single use case. With Btrfs built-into the kernel, we don't need >> that much in the initrd to setup block devices, discover their contents, and >> perform switch root. >> >> The next most common use case(s), device-mapper and md based, require a pile >> of user space programs running to do all the work setting things up. Maybe >> we can just get away with two images, a simple fast one and the universal. > > The elephant in the room is whether the "desktops in the default > installation" UKI requires piles of graphics firmware. It might not be at all > small in that case. True. I don't know what the limitations/reasons are for firmware blobs needing to be available so early during boot. But (a) we have chosen a file system by default that we can shrink online (b) have at least 128 partitions possible (c) we can extent Boot Loader Spec to permit multiple XBOOTLDR. So we can make room for these firmware blobs. It's just fricking ugly. And I'm not sure it'll be RPM's domain if these things really need to exist on /boot. Something will have to put them there, as needed. -- Chris Murphy ___ 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)
On Wed, May 10, 2023, at 7:11 PM, Chris Adams wrote: > Once upon a time, Chris Murphy said: >> Read-only drivers, which are the only drivers under discussion here, aren't >> a per se problem because they can't modify the file system. So they have no >> complaints about that. > > But those read-only drivers are incomplete and problematic, especially > as filesystems get more complex. I've been bitten before by an > ill-timed unclean shutdown, where an update was still in the /boot ext4 > journal but not comitted, so the system would not boot, because the > GRUB2 ext4 driver doesn't read the journal. Right. But is the program updating /boot doing it correctly? Given the decision to use a journaled file system but a bootloader that doesn't do journal replay, it means the program needs to use a write order and sync policy to ensure there's no expectation of journal replay. Otherwise inevitably it's going to break. So it's a series of mistakes. > There should be _less_ put into GRUB2 filesystem support IMHO, not more. > No more complex filesystems; keep /boot something simple like ext2 that > GRUB2 can reasonably be expected to handle basically 100%, possibly > mounted read-only during normal operation, mount with "sync", and with > all updates as atomic as practical. It still needs the program that modifies /boot to do the updates in the proper sequence. That's not happening right now so it's a risk no matter the file system. But if simpler is better, and ext2 is acceptable, then FAT should also be acceptable. It has the added benefit of all firmware supporting it. -- Chris Murphy ___ 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)
On Wed, May 10, 2023, at 5:21 PM, Lennart Poettering wrote: > So to add to this. I happen to be at LFSMMBPF at the moment, the Linux > File System summit (among other things) where all the Linux FS people > meet. I spoke to a couple of FS maintainers here, and well, let me > make this very clear: using any of the major Linux file systems with > drivers that are not the ones in the Linux kernel is a very bad idea, > and expressly not supported by them. [They actually used much harsher > words, that I'll not repeat here – this is the "friendly" version of > their take on your idea.] > > So, unless you want to go against what the people who actually > maintain the file systems expressly say please just get this idea out > of your head that porting Linux file systems into EFI fs drivers was a > good, supportable idea. > > And Neal, Chris, if you don't believe the above, then hey, I am happy > to open a thread with them in CC where they can tell you in person how > bad an idea that is. I don't know what question you asked them. Any modifications (writes) performed outside kernel code is not supported, since forever. Read-only drivers, which are the only drivers under discussion here, aren't a per se problem because they can't modify the file system. So they have no complaints about that. -- Chris Murphy ___ 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)
On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote: > > > On Wed, May 10, 2023 at 12:02 PM Neal Gompa wrote: >> > Now, there's a second problem with reading everything from the ESP - it's > slow for two reasons. First, because read speeds when going through the > firmware are much slower than the Linux NVMe stack. And second, because we > have to read everything in order to checksum and verify it. > > For that reason, Demi's suggestion of moving things onto a dm-verity > protected partition is intriguing. Could that even be a loopback file on the > ESP? It would be like a lazy-read system extension. > > The performance geek in me thinks "we could see exciting speedups from that!" > - the practical side of me thinks "it might be a few second faster. And much > more complex! Let's just go with efifb, keep the initramfs small, and accept > any minor regressions". GRUB doesn't support dm-verity, but I don't know if it would make a difference if it did. Once the kernel has the ability to interact with physical storage, understand partitions, initialize dm-verity, and read a file systemt... it could just mount `/` . I think the only way the current initial root file system works with the kernel is for the bootloader to read an entire initrd file into RAM, and then the kernel can randomly access things in that RAM disk. It's early still for UKI details but I assume we will need both a universal UKI (all use cases), and much smaller use case focused UKIs. I say that because the desktops in the default installation configuration are the largest single use case. With Btrfs built-into the kernel, we don't need that much in the initrd to setup block devices, discover their contents, and perform switch root. The next most common use case(s), device-mapper and md based, require a pile of user space programs running to do all the work setting things up. Maybe we can just get away with two images, a simple fast one and the universal. -- Chris Murphy ___ 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)
On Wed, May 10, 2023, at 9:42 AM, Lennart Poettering wrote: > You are arguing here into two opposing directions. One one hand you > want to chainload multiple kernels+initrd (claiming this was a good idea out > of the problem of sizing ESP/XBOOTLDR sufficientlly), and then on the > other hand you claim there's too much kernel+initrd in the boot > process? > > What is it now? Pick one: more initrd or less initrd? I've only ever said I want faster boot and smaller initrd. Everything else is pointing out the consequences of alternatives, not advocacy of them. -- Chris Murphy ___ 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)
On Mon, Apr 24, 2023, at 12:15 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/BiggerESP > This change will increase the minimum size of the ESP to be 500MB, > which is also the same value used by Microsoft for Windows 10 and > newer. Issue 1: Currently anaconda calls mkdosfs on the ESP without any options and historically are reluctant to add non-default mkfs options. By default, mkdosfs will create a FAT 16 file system on a 500M (either SI or IEC units). The UEFI spec clearly prefers FAT 32 for the ESP on built-in drives. To my knowledge there haven't been any FAT 16 related bugs reported during the many years Fedora created FAT 16 ESPs. But it's probably better to create it as FAT 32. I don't know where the cutoff is in the mkdosfs code, but a 512MiB (IEC units) does result in a FAT 32 file system. So you might make it 512MiB. Issue 2: Last I checked (about 12 months ago), Windows 10 and 11 images from microsoft.com were still creating ~99M (I forget which units, and it may have been 100). That's consistent with: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11 "The minimum size of this partition is 100 MB, and must be formatted using the FAT32 file format." So I'm not sure if Microsoft got the memo, and it's actually vendors' OEM images that are using large ESP size? -- Chris Murphy ___ 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: Fun with GRUB2, BLS and Multiboot USB
On Wed, Apr 26, 2023, at 12:26 AM, Philip Rhoades via devel wrote: > People, > > LILO and SysLinux were simple and GRUB1 was straightforward - but by the > time GRUB2 came around I was long past configuring my own kernels and > hacking around at a lower level . . now I think, finally, I need to know > more about how GRUB2 - works specifically with Fedoras 38+. > > This current interest was prompted when I upgraded my WS from F37 > KDE(->Sway) via a beta F38 LiveSway and found that /boot/grub2/grub.cfg > did not contain a menuentry for the latest F38!? - much hacking and > experimenting followed . . There are no GRUB native menu entries anymore since Fedora 30. There are Boot Loader Spec formatted "snippets" in /boot/loader/entries and Fedora's GRUB contains blscfg.mod which is a GRUB module that provides GRUB with the ability to read BLS snippets and create menu entries from them. https://fedoraproject.org/wiki/Releases/30/ChangeSet#Make_BootLoaderSpec-style_configuration_files_the_default > So, I have git cloned the grub2 stuff and had a look at it but I am too > old now to be digging around in that stuff just at the moment - so, has > any Fedora Guru produced a diagram or at least a point list, of what > Grub does from turning on the power to the display of the Grub menu on a > Fedora machine? - that would be nice as a more-detailed overview than I > have been able to find so far - but not so low-down I am amongst the > weeds . . that might come later . . It's one of those cases of "no not that specification the other specification". There's no way you'd know this is the case without some digging. Also since https://fedoraproject.org/wiki/Releases/34/ChangeSet#Unify_the_GRUB_configuration_files_location_across_all_supported_architectures there are two grub.cfg files. One is on the EFI System partition and merely points to (forwards) to the real one in /boot/grub2. This is consistent with BIOS and upstream GRUB's location for the grub.cfg. I guess hindsight being 20/20 we could have changed grubx64.efi to look for "grub.static" in the same directory as the EFI program instead of "grub.cfg" and then there'd only be one grub.cfg and it'd be the real one rather than the forwarding one. -- Chris Murphy ___ 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)
On Tue, May 9, 2023, at 2:47 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, May 09, 2023 at 01:31:01PM -0500, Chris Adams wrote: >> Once upon a time, Chris Murphy said: >> > What about the increasing growth in linux-firmware and in particular the >> > NVIDIA firmware requirements? My reading suggests it's significant and the >> > future growth also significant. >> >> Could we use a dumb framebuffer in initrd and get rid of all the GPU >> firmware from the image? > > Maybe, probably, who knows… But it's not just the video. The pressure > to add more stuff and more drivers will only grow: bluetooth for keyboards > and FIDO2, sound support for voice assistance, network for remote attestation > or clevis, etc. We can push this can down the road, but it seems we need > to be ready to add move stuff before root is available anyway. I still think we need less kernel and initramfs in order to get more by having `/` available faster. Fast enough that the user isn't looking for or expecting interactivity in the few seconds it should take to get to `/` being mounted. Otherwise, next up will be embeding GNOME Shell into the initramfs because we're tired of waiting for a real a11y and i18n environment to be available so we can prompt the user for an encryption passphrase with appropriate rules, fonts, locale support, etc. I can conjure up some use cases for stuffing Firefox in the initramfs. Maybe we should just put /usr into the initramfs. We'll just all accept 20+ second linux+initrd times to accommodate everyone getting through the elevator door simultaneously. No problem. -- Chris Murphy ___ 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)
On Tue, May 9, 2023, at 12:31 PM, Lennart Poettering wrote: > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote: > >> I've been asked to consider converting /boot to a Btrfs subvolume so >> that it no longer has a fixed space allocation to deal with the ever >> increasing amount of firmware required for NVIDIA GPUs[1]. This is >> currently incompatible with how systemd views the world, because the >> "discoverable partition spec" is wired to partitions, and there is no >> equivalent spec for subvolumes of a volume. And I imagine that >> XBOOTLDR (whatever that is) also would have a problem with this. > > This makese no sense. If you want /boot to just be a subvolume of the > rootfs btrfs, then this would imply it's also covered by the same > security choices, i.e. encryption. We want to bind that sooner or > later to things like TPM2, FIDO2, PKCS11. And that's simply not > feasible from a boot loader environment. Windows and macOS do this, so it is feasible, the question is what are the consequences of this and are we willing to live with them? One obvious consequence, it further creates dependency on a single bootloader, GRUB. Or we need an independent project that provides an EFI program for unlocking LUKS volumes within the pre-boot environment, thus making plaintext view available to any bootloader. > Hence, the place the kernel is loaded from (regardless if you call it > /efi or /boot or /boot/efi, and regardless what fs it is) must be > accessible from the boot loader easily, without requiring > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader. I understand that might be difficult and something we don't want to do for resource reasons, but there isn't a technical impediment for it. > > Hence: btrfs subvols won't work for this > > A simple vfat partition however will. FAT isn't resizable. The growth requirement for /boot is greater for some use cases more than others, so there is pressure building because it will create waste for some use cases and underprovisioning in other use cases. Those unverprovisioned being told they can't upgrade but need to reprovision to solve this is kindof annoying. > >> Also, as an aside, there is now a "from-scratch" Btrfs EFI driver in >> development[2] (and for your personal horror, an NTFS one too[3]). > > Not sufficient. You'd also have to implement a LUKS EFI driver, and a > TPM2 EFI driver, and a FIDO2 EFI driver, and so on and so > on. Basically, you have to reimplement a good chunk of the Linux > kernel, of Linux userspace, systemd and so on in EFI mode. > > Good luck with that. Right. Hence Linux Boot. Dump all the toy drivers in favor of real ones. And a real user space. -- Chris Murphy ___ 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)
On Tue, May 9, 2023, at 8:08 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, May 09, 2023 at 12:02:26PM +0200, Gerd Hoffmann wrote: >> 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? > > 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.) > > (*) 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. Related but slightly off topic... What about the increasing growth in linux-firmware and in particular the NVIDIA firmware requirements? My reading suggests it's significant and the future growth also significant. There's some preference to put /boot on Btrfs to take advantage of storage pooling so that we're neither over nor under provisioning the size of /boot. The problem I have with this is two fold: what about our non-btrfs use cases? Surely those use cases are equally concerned about this problem? And then what are the impediments to booting the kernel faster and more quickly getting `/` mounted? Why is there so much pressure to stuff the firmware blobs into the initramfs or onto /boot in general? Why does firmware availability need to happen so early during boot, and is it really not possible to somehow make mounting `/` a higher priority than it has been up until now? Huge universal initramfs will slow down boot. And it delays mounting `/`. So if there is some good reason why firmware blobs need to be available soon, it's in direct opposition to booting fast and that strikes me as a design flaw or need for a feature request. I just don't know what that could be. But to just keep stuffing more things into the initramfs doesn't scale either. Back to the original topic: ESP and XBOOTLDR are not user domain, should have no user facing configuration in a GUI at all. It's irrelevant esoteric knowledge that 99% of our users do not need to worry about. By extension, they don't belong in /etc/fstab nor should they be persistently mounted. Whether one or the other are temporarily mounted to /boot, /efi, /boot/efi, is up to the developers creating tools that modify these volumes. I prefer that they are mounted to a pseudo-random location in /run but I don't really care. NOTE: We can apply SELinux labels to FAT file systems by using 'mount -o context=' mount option. The limitation is the label applies to that entire mount point, you don't get per directory labels, it's a one size fits all. Recent Windows 10/11 images on microsoft.com within the last year produce a 100M EFI System partition per: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11 I have reinstalled Windows 10 and 11 using the microsoft.com procured installer as of a year ago and it likewise creates a 100M ESP. Maybe Microsoft didn't get the memo and the space requirement is really something the OEM's are concerned about? So I expect this problem is not only our problem to solve. -- Chris Murphy ___ 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: default bash history (non)preservation
On Tue, Apr 11, 2023, at 12:02 PM, stan via devel wrote: > On Tue, 11 Apr 2023 10:48:11 -0400 > "Chris Murphy" wrote: > >> Hi, >> >> For a long time I've noticed lost history from multiple Terminal >> tab/windows. It seems like the last tab or window to close is the >> history that gets written to .bash_history, and everything else is >> just lost. >> >> Somehow I found this: >> https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/11/update-bash-history-in-realtime.html >> >> I've implemented the suggested two line change to .bash_profile: >> >> # User specific environment and startup programs >> shopt -s histappend >> PROMPT_COMMAND="history -a;$PROMPT_COMMAND" >> >> The resulting behavior appears to be shells still have their own >> unique histories while active. But once closed, their histories >> become merged (interlaced based on the time they were issued?) and >> available when a new shell is created. >> >> I think this would be a pretty cool yet subtle Fedora 39 feature. >> However, >> >> a) I'm uncertain exactly where this belongs as a default, .bashrc or >> .bash_profile or some parent file that's copied to create these files >> (for new users); > > I like option 3 if it is going to be automatic. Right. Which raises the question whether existing user profiles should be modified. There's pros and cons either way. And whether that more strongly favors adding this to .bashrc or .bash_profile, and whether there are subtleties in the resulting behavior depending on which file is used; or if they're equivalent. Normally I'd said don't apply a change to existing users. But in this case, I think the risk of modifying existing user behavior is low, meanwhile the potential for even more confusion is high if we don't change it. -- Chris Murphy ___ 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: default bash history (non)preservation
On Tue, Apr 11, 2023, at 12:07 PM, Adam Williamson wrote: > I've been doing something like this for years, but I wouldn't > necessarily recommend it as an OOTB default. It has some interesting > subtleties, like the order of the command history you get when you hit > 'up' changes depending on when the history is updated by other > terminals and when the terminal you're in reloads it. I'm not seeing this effect. While active, the shells apparently have completely unique histories, and don't interact with each other (until they're closed). From time to time I see zero length files, e.g. .bash_history-04863.tmp appear but I don't know what they do, there's nothing in them. -- Chris Murphy ___ 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
default bash history (non)preservation
Hi, For a long time I've noticed lost history from multiple Terminal tab/windows. It seems like the last tab or window to close is the history that gets written to .bash_history, and everything else is just lost. Somehow I found this: https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/11/update-bash-history-in-realtime.html I've implemented the suggested two line change to .bash_profile: # User specific environment and startup programs shopt -s histappend PROMPT_COMMAND="history -a;$PROMPT_COMMAND" The resulting behavior appears to be shells still have their own unique histories while active. But once closed, their histories become merged (interlaced based on the time they were issued?) and available when a new shell is created. I think this would be a pretty cool yet subtle Fedora 39 feature. However, a) I'm uncertain exactly where this belongs as a default, .bashrc or .bash_profile or some parent file that's copied to create these files (for new users); b) if this is (still) an optimal way to go about it; c) what are the possible negative side effects? Any thoughts? -- Chris Murphy ___ 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: Shorter Shutdown Timer (System-Wide Change proposal)
On Tue, Jan 17, 2023, at 11:51 AM, Peter Boy wrote: >> Am 16.01.2023 um 13:23 schrieb Lennart Poettering : >> >> Just to say this cleary btw: when we introduced the time-out initially >> we were coming from sysvinit where no such time-out existed at >> all. Hence we picked a conservative (i.e. overly long) value to not >> upset things too badly. And yes, some people were very much upset we >> now defaulted to a time-out. >> >> If we'd start from scratch without sysvinit heritage, I think we >> would have started with something much much lower right-away. > > When introducing a timeout, you obviously had the grace to choose a > fairly conservative (i.e. cautious) default value that did not lead to > major problems. Would be interesting what would have been if you had > started with 15 sec. Why? it was 0 sec before systemd. If anything, the time out behavior is masking problems with services not shutting down in a timely manner. >> It >> appears to me fedora is considering switch to that now, and I >> certainly think that would make a lot of sense. > > The way it is proposed it doesn’t make a lot of sense. Desktops and > servers work very differently and have different requirements. For > servers, this proposal in its present form makes no sense at all, and > is on the contrary dangerous. Why? It's been said in this thread that servers come with a higher expectation of rebooting upon request rather than indefinitely hanging, in contrast to desktops where there can be some tolerance for delay in exchange for safety. Why should a server sysadmin's request for a reboot or shutdown be second guessed? What are the consequences of second guessing? What I've seen on Fedora Server when there are services that hold things up is invariably sshd does immediately quit so now I can't even log back in to find out what's holding up the reboot. It's quite substantially a worse Ux than on the desktop. I mean, ostensibly I know what I'm doing on my own server and don't need to be second guessed like a desktop user. At least postgresql and libvirtd are configured to inhibit reboot/shutdown indefinitely until they properly quit. Services can opt into this behavior, overriding the default. But indefinite delay would pose a bigger problem on server than on desktops, due to the loss of any feedback and control. > A strangely ignorant attitude to take a positive view of the change, > even if those affected, the customers, are upset and fear considerable > disadvantages. Only someone who is not responsible for TBs of data and > thousands of users can talk like this. The least you have to do is test > and check what effects it has and prove that the concern is unjustified. The proposal changes a default behavior. It's not itself an override. -- Chris Murphy ___ 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: Shorter Shutdown Timer (System-Wide Change proposal)
On Fri, Dec 23, 2022, at 12:56 AM, Demi Marie Obenour wrote: > Why cache mode unsafe? How big a performance win is it? Huge. In effect fsync is ignored. So if the host dies, write order is not guaranteed and can toast the guest file system. The guest dying shouldn't pose a problem because the write order is eventually honored by the host. There's a variety of complex journal replay behaviors of the various file systems that'll come into play (no pun intended). -- Chris Murphy ___ 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: Shorter Shutdown Timer (System-Wide Change proposal)
On Thu, Dec 22, 2022, at 5:22 PM, Steve Grubb wrote: > On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote: >> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: >> >> > On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: >> > >> > > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer >> > > >> > > This document represents a proposed Change. As part of the Changes >> > > process, proposals are publicly announced in order to receive >> > > community feedback. This proposal will only be implemented if approved >> > > by the Fedora Engineering Steering Committee. >> > > >> > > == Summary == >> > > A downstream configuration change to reduce the systemd unit timeout >> > > from 2 minutes to 15 seconds. >> > >> > Great change, please do it! >> > >> > Also, sometimes after reaching the timeout, systemd extends wait by >> > another 2 minutes (or 1m30). I wasn't able to find in the sources or >> > documentation why this happens, but this behaviour should be blocked. >> > Otherwise some services after 15s will get another 15, and then another… >> >> 15 seconds feels very aggressive to me. I can think of some cases, like >> libvirtd automatically suspending or cleanly shutting down running VMs, >> that might well take longer than that. Could we not go for 30 seconds? >> Going all the way from 90/120 down to 15 seems pretty radical. > > I run across this with some regularity. PackageKit is not installed on my > system. What I wished was that when there is a stall shutting down, a message > to the console or a dialog box explains who is holding up shutdown. If we > knew who was holding things up, bugs might get filed. I wonder if systemctl list-jobs would be too much? This information needs to be logged too because 15 seconds won't be enough to see much. And for it to be logged, sysroot needs to be rw. > > In some cases I know that the system is rebuilding the nvidia drivers so that > graphics work on boot up. I'd like to let that finish and it certainly takes > more than 15 seconds. But without a blame message, how do we know what needs > looking into? I expect there is (or will be) a way of tagging service units with indefinite wait. Reboot can't happen in the middle of kmod updates. -- Chris Murphy ___ 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:00 PM, Lennart Poettering wrote: > On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote: > >> 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 > > I am pretty strongly against the idea of ext4 for /boot/. > > First of all, the firmware can't read it natively, but what's worse, > uefi cannot even make sense of any of the features it provides above > vfat. i.e. file ownership, access modes, ACLs, selinux labels, xattrs, > symlinks, … are all complete nonsense to the UEFI fs layer (and to > boot loaders that natively implement the fs drivers, the same). The > UEFI fs API has no concepts for *any* of these features. Hence, if > this is supposed to carry data intended for consumption by the boot > loader, why the f**k would you use a file system it cannot even > remotely take benefit of? And for btrfs, the GRUB btrfs.mod doesn't do any checksum checking at all, so there's not even an incremental improvement to integrity, let alone any support for fs-verity. So while I like btrfs for /boot due to the space efficiency advantage (I don't have to ask how big boot should be, no space is wasted and I don't run out either), I'm willing to give it up for practical matters like simplicity and reduced attack and maintenance surface area. -- Chris Murphy ___ 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 6:53 AM, 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. What's the use case? Is it a nice to have or is it a hard requirement and why? The Linux FAT driver does support SELinux context with a mount option. We aren't using that right now but we can have a suitable SELinux label enforced file system wide on ESP and XBOOTLDR. > Everyone can do whatever they want with the files, and a trivial power > outage can easily wipe out all of its contents. This is a rare but real problem. I think we should be looking at ESP and XBOOTLDR updates doing A/B updates, i.e. write the updates to temporary files or directories and then use renameat(2) which is atomic at the VFS layer, and should get pretty close to atomic at the FAT layer to the degree that worse case scenario we have either the old *and* new files following a crash. Ideally we'd get old *or* new. But that's probably not possible with FAT. But we can still boot. >> Such drivers would need to be signed to be used >> under SecureBoot, thus expanding the set of components you >> need to audit & trust for security purposes. > > These drivers are backports from the grub2 code. If we trust GRUB, we > can trust them too. > > Fedora Infra can be configured to sign the contents of the efifs package > with a Fedora SB key. Yeah but then try getting all the distros to agree on signing efifs. How many distros are there? It's not unfair to say all distros should be able to put their signed efifs drivers on the ESP because that's the only way their bootloader can read loader/entries to properly draw a boot menu. -- Chris Murphy ___ 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 6:22 AM, Vitaly Zaitsev via devel wrote: > On 20/12/2022 19:56, Chris Murphy wrote: >> 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. > > Nobody should use FAT for /boot. efifs[1] should be used instead. > > systemd-boot can load these drivers from ESP out of the box[2]. The founding principle in Boot Loader Spec is that multiboot between Linux distros sucks. The cooperation between distros, is shit. And BLS strives to present an opportunity to compromise and fix that problem. It's harder to fix this problem if XBOOTLDR is not FAT. efifs drivers need to be Secure Boot signed just like the bootloader. The firmware already trusts its built-in FAT driver, for better or worse, so what is the exact problem with just using that so we don't have to deal with UEFI SB signing efifs drivers, and the much harder job of expecting every distro to include signed efifs drivers *on the ESP* for multiboot to work? If /boot is ext4, then every Linux distro must include a signed ext4 efifs driver in order to properly render the boot menu. But what if (open)SUSE doesn't want to use ext4, they want Btrfs? Compromise dictates that every distro now needs to provide a signed btrfs efifs driver too. OK Red Hat uses XFS for boot, so now every distro needs to include ext4, btrfs, and XFS signed efifs drivers with every installation. It's explosively more complicated to implement let alone to agree upon than just use the one driver we know everyone has and can use. XBOOTLDR in practice needs to be FAT. I don't like it. But I like it better than choosing batshit as the alternative, and having a bunch of signed efifs drivers on the ESP per distro sounds like batshit to me. And not in the good way. -- Chris Murphy ___ 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: Shorter Shutdown Timer (System-Wide Change proposal)
On Thu, Dec 22, 2022, at 1:29 PM, Adam Williamson wrote: > On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: >> On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: >> > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer >> > >> > This document represents a proposed Change. As part of the Changes >> > process, proposals are publicly announced in order to receive >> > community feedback. This proposal will only be implemented if approved >> > by the Fedora Engineering Steering Committee. >> > >> > == Summary == >> > A downstream configuration change to reduce the systemd unit timeout >> > from 2 minutes to 15 seconds. >> >> Great change, please do it! >> Also, sometimes after reaching the timeout, systemd extends wait by >> another 2 minutes (or 1m30). I wasn't able to find in the sources or >> documentation why this happens, but this behaviour should be blocked. >> Otherwise some services after 15s will get another 15, and then another… > > 15 seconds feels very aggressive to me. I can think of some cases, like > libvirtd automatically suspending or cleanly shutting down running VMs, > that might well take longer than that. Could we not go for 30 seconds? > Going all the way from 90/120 down to 15 seems pretty radical. Yeah. I'm not opposed to the change, and I understand the main impetus behind it (PackageKitd), but it's the consequences of unknowns that I'm still left scratching my head trying to imagine worse case before we actually subject users to it. There really isn't a good kernel facility for something in between SIGTERM which is ignorable, and SIGKILL which isn't. And I'm not familiar with systemd's facilities for tracking service shutdown progress. i.e. I'm OK with SIGKILL for a process that isn't responding. But I'm also not sure if there's a facility for a process indicating either "I'm working on it" or "don't force kill me or it'll be bad". I also don't know if privileged services doing writes to the file system can inhibit either remount read-only or umount? And if so, do we just wait for all of that to complete? I think we'd have to. I'm pretty leery of rebooting forcibly even if we can't remount ro because some process is holding things up, doing the best it can to flush. Databases and VM's do come to mind, in particular because I routinely run VMs on my laptop with cache mode unsafe. If the VM is forcibly quit, it's fine. But if the host is forcibly rebooted before the VM's pending writes are completed by the host, that'd be bad (regardless of the file system choice). Also I wonder if there's a way for desktops to opt into this behavior? Or a way for servers, iot, cloud, and rpm-ostree based systems to opt out? They very well might have legitimate reasons for very long service shutdowns: they're really super busy, and forward progress is being made but it'll take a *lot* longer than 15 minutes to get to a safe shutdown point. -- Chris Murphy ___ 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 2:22 PM, Daniel P. Berrangé wrote: > parted/libparted already have support for handling GUIDs since > their 3.5 release. > > I added pyparted support in > > https://github.com/dcantrell/pyparted/pull/95 > > and I've got work in progress for blivet support > > https://github.com/storaged-project/blivet/pull/1080 > > in theory that should merely then require anaconda to set a flag > in blivet to automagicaly enable setting well known GUIDs. > > I've also got some changes to pykickstart to let the GUID be > set in kickstart file part commands. Wow, great news! -- Chris Murphy ___ 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 1:56 PM, Chris Murphy wrote: > For example: > https://bugzilla.redhat.com/show_bug.cgi?id=2120845 > > For that matter, grubby likewise steps on *all* BLS snippets found in > /boot/loader/entries when using the --update=ALL flag, not just the BLS > snippets Incomplete thought: --update=ALL modifies all snippets in /boot/loader/entries, not just the BLS snippets the currently running root owns. This brings up the concept of each installed distro, whether literally a different distro or merely an additional instance of the same distro, having ownership of its BLS snippets and not owning other BLS snippets. Fedora A should not be modifying Fedora B's BLS snipets, but it does. And now breaks them since the change earlier this year mentioned in the bug. -- Chris Murphy ___ 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 1:56 PM, Chris Murphy wrote: > So I think the first big barrier to entry is answering the questions: > > * Enhance parted/libparted to support arbitrary GUIDs and enhance > blivet to understand the full listing of GUIDs? Or > > * Enhance parted/libparted to support full listing of GUIDs? Or > > * switch anaconda/blivet to using fdisk/libfdisk? It already supports > pretty much all GPT partition type GUIDs and receives regular updates > with additions; I'm not sure if it supports arbitrary GUIDs, the CLI > tool seems not to support it but maybe fdisk does. Typo: maybe libfdisk does (support arbitrary partition type GUIDs) -- Chris Murphy ___ 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)
expanding the discoverable partitions conceptually, a sort of "discoverable subvolumes spec" so that Btrfs and OSTree and LVM could benefit from discoverability via a naming convention that a new systemd generator could parse and take action on. LVM and OSTree don't have an approximate equivalent of btrfs default subvolumes, so they are in need of a solution to find the proper root without it being explicit. If we're going to accept that specifying root trees must be explicit for LVM and OSTree, then I think we might as well leave things be for Btrfs and explicitly list the root tree there too. > * 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. This is not a major consideration for this feature proposal, but the sooner some of these decisions are made the easier it's going to be by not having to unwind mistakes down the road: For the purposes of a VM, it's a single OS setup so it makes sense to go with the simplest option which is an ESP on /boot that serves the purposes of both ESP and "boot" (bootloader, bootloader configuration, and kernels all on one volume). However... There is the still common and supported baremetal dual-boot scenario were the ESP will be too small, so we'll need ESP on /efi, and XBOOTLDR on /boot. While we could support both EFI only and EFI+XTBOOTLDR layouts for the different use cases, I'd encourage just supporting one size fits all: EFI+XTBOOTLDR. It's more compatible (dual boot), and more like what we have today. > * 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. 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 problem with a large initrd anyway is that we have to load the whole thing in memory and unpack it. And this will increase boot times. For whatever reason, the bootloaders don't support particularly fast reading off modern storage. Maybe it's a pre-boot environment limitation, not a bootloader limitation, I'm not sure. -- Chris Murphy ___ 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 Fri, Dec 9, 2022, at 7:30 AM, Ray Strode wrote: > Hi, > > On Thu, Dec 8, 2022 at 2:55 PM Adam Williamson > wrote: >> 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". > Presumably we could package the firmware separately and just unpack it > into place from a udev rule when the hardware is detected? > > But first, do we actually know this is a problem? > I think you're saying squashfs loads the whole decompressed image into > memory, but my expectation prior to your mail was that it performs I/O > on the usb stick (with a cache in between). If my intuition was right > and files only hit ram when accessed, then it seems like this is > pretty much not an issue, right? From a certain point of view there's a potential inefficiency with squashfs reads in that there's a minimum block size that it needs to read in order decompress its 128 KiB block. It's possible quite a lot of what's decompressed isn't (immediately) needed. But it's still a random access file system. It's not necessary to read the whole image into RAM. Repo metadata is the big hit for netinstall because it's downloaded into /tmp which is tmpfs. And DVD already has repomd on it, and only downloads more if you enable some other repo. Live doesn't need repomd. So initially netinstaller uses less memory up until the the Anaconda language selection screen appears, at which point it starts background downloading repomd. It quickly catches up to, and surpasses, Live media memory consumption. Off hand, I'm not sure what's producing all the anonymous pages during Live installation but it's a fairly linear increase as the installation progresses. Since it's an rsync based installation, I'm currently frownie facing pondering the cause of the anon page explosion. -- Chris Murphy ___ 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 8, 2022, at 12:08 PM, Adam Williamson wrote: > I mean, the modern systems that *need* GPU firmware generally seem to > do pretty well with using native resolution and don't perform too > badly, especially in the simple installer UI. When I test the fallback > path on my bare metal test box on UEFI it uses the monitor's native > resolution and performs fine (even, honestly, in GNOME), and that > motherboard is nearly a decade old even. Don't know if this is the same > for everyone, of course. For what it's worth, this is back on the change list for Fedora 37. https://fedoraproject.org/wiki/Changes/Linux_Firmware_Minimization -- Chris Murphy ___ 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 8, 2022, at 10:28 AM, Adam Williamson wrote: > On Thu, 2022-12-08 at 17:10 +, Gary Buhrmaster wrote: >> On Thu, Dec 8, 2022 at 5:06 PM Adam Williamson >> wrote: >> >> > It already *is* compressed, which is why it doesn't get any smaller in >> > the compressed filesystem image, unlike the other things I mentioned. >> > Check for yourself - look under /lib/firmware and you'll see only >> > things ending in .xz. >> >> Right, but zstd *may* have a better compression >> ratio than .xz (that was at least one of the reasons >> given for the changes to support it). > > I actually spent half an hour looking into that yesterday as I got > diverted into the details of how the filesystem compression stuff > works, but all the references I found say xz consistently compresses > better than zstd. zstd's advantages over xz are in *performance* (time > taken to compress and decompress). So switching from xz to zstd seems > like it would make things bigger, not smaller. xz will use a larger computation cost upfront (compression) to achieve a higher compression ratio than zstd, i.e. you can always ask xz to spend more time to get a higher compression ratio and thus beat zstd on resulting file size. But zstd will always beat xz if you favor time to compress, and significantly beats xz on decompression time. Net costs: Fedora releng takes one compression hit per image created, but consumers of those images which also includes a ton of Fedora QA bot time as well as human users are in the dozens to thousands of hits per image created. The net energy cost is quite a lot higher using xz compared to zstd. Only focusing on image size is misleading. There's a very real energy hit of all this compression and decompression. I don't know how to weigh the costs and figure out a compromise, but totally ignoring one of the costs is probably incorrect. For all I know a balanced approach means using xz but at a lower compression ratio, but someone with round tuits and interest would need to look at it. -- Chris Murphy ___ 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 8, 2022, at 10:06 AM, Daniel P. Berrangé wrote: > Is there something that can be done to optimize the RAM usage, > in spite of the large installer env size ? What's wrong with the RAM usage now? We do semi-regularly run into issues with openQA VM's running out of memory. So far they're all been considered bugs when we hit them, and the change is reverted including a system change to bump tmpfs on /tmp quite a lot. But keeping the VMs at 2G has helped discover changes that in retrospect shouldn't have been changed. Ergo, even though it's a pain to regularly hit these bugs, I don't think there is a per se problem with the 2G RAM selection. When it's all working as expected, swap on zram is used rather significantly and works as expected. > If we're installing off DVD media, it shouldn't be required to > pull all of the content into RAM, since it can be fetched on > demand from the media. AFAIK this doesn't happen. Files are read in only on demand, not a monolithic read of everything and kept in cache somehow. > IOW, 99% of the firmware never need > leave the ISO, so shouldn't matter if firmware is GBs in size [1] > if we never load it off the media. Same for languages, only > the one we actually want to use should ever get into RAM. At first glance it might seem you can get memory savings by not having swap on zram enabled. But what happens is anonymous pages can't be compressed. And also they can't be dropped since they have no files backing them. The result is file pages get dropped in memory tight situations and we end up getting (file) page faults, and it's just super expensive. Yes you can read these pages back from files but it's extra costly because even if it's only a 4K read that's needed, it'll translate into potentially upwards of 1M reads: to find the 4K extent requires reading multiple 4K ext4 metadata blocks, which aren't necessarily colocated in a 128 KiB squashfs block, so we end up reading 1 to 10 of those, taking the ram and memory hit to decompress them to reveal their 4K content we need, dropping the rest. And then doing that every time there's a page fault. So I'd say it's probably asking for a performance hit that isn't really going to save much memory. On high latency devices like USB sticks, it's not a good UX. > If we're installing off a network source, we need to pull content > into RAM, but that doesn't mean we should pull everything in at > once upfront. Pretty sure netinstaller's big RAM hit is repo metadata. All of it is downloaded before we have partitioning done, thus the repo metadata isn't stored on disk, rather in memory and it's tmpfs so it may not be compressed either (at least it's not subject to swap on zram out of the gate). I'm pretty sure partitioning happens before the packages are downloaded though, which means they get stored on disk not in memory. But the repo metadata is pretty big now and that's a big memory hit for netinstallers. -- Chris Murphy ___ 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 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
On Thu, Nov 10, 2022, at 6:08 PM, Robbie Harwood wrote: > Ben Cotton writes: > >> By design, ostree does not manage bootloader updates as they can not >> (yet) happen in a transactional, atomic and safe fashion. > > As we've talked about before, it's not possible to make updates > transactional. It involves, per spec and depending on processor > architecture, updating multiple files in different directories, > potentially on different filesystems entirely, one of which is fat32. EFI/FedoraA EFI/FedoraB NVRAM bootorder uses A then B Update the bootloader in EFI/FedoraB At any point of failure, only the EFI/FedoraA bootloader path is used. Once everything in EFI/FedoraB is committed to stable media, set bootnext FedoraB. If the boot fails, automatic failback to FedoraA. If the boot succeeds, bootupd can change bootorder. B then A. ? -- Chris Murphy ___ 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
On Wed, Oct 5, 2022, at 3:01 PM, Vít Ondruch wrote: > > 3. "Boot menu" in GUI? Given that one can reach the GUI, why it should > not be possible to choose the boot entry for next boot? Or even choose > to open FW setup. This could solve this other problem too. https://bugzilla.redhat.com/show_bug.cgi?id=2049849 The GUI tool can use efibootmgr to set bootnext or even bootorder. -- Chris Murphy ___ 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
On Wed, Oct 5, 2022, at 11:43 AM, Geraldo Simião Kutz wrote: > On my acer Aspire laptop it's the "esc" key. Works everytime I want to see > the grub menu. The gotcha with ESC is that it brings up firmware settings on qemu-kvm when using UEFI (edk2-ovmf). -- Chris Murphy ___ 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
On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote: > However, on ask.fp, a user mentioned that the grub menu is no longer > enabled by default on single boot systems so that changing the kernel is > no longer easily possible, and put forward > https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for > this argument. Yet, the article indicates that the argument is not fully > correct and even with single boot installations, SHIFT can be used to > get into the grub menu. I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, because it's reserved by UEFI firmware for one of its menus. And SHIFT has never worked. Maybe Esc or TAB? Given this inconsistency, I have a mixed opinion of the hidden GRUB menu. -- Chris Murphy ___ 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: limiting the (systemd) journal size
On Tue, Sep 27, 2022, at 7:14 PM, Allan via devel wrote: > On Tue, 27 Sep 2022 12:31:11 -0600 > "Chris Murphy" wrote: > > The original PinePhone only comes with a 16GB eMMC. Using 4GB for > journal on that would for sure be insane. The root file system for this device might be around 15G, therefore max journal size is 1.5G. But also stops growing its usage once the journal uses more than 15% free space. The 4G cap is the high end cap which applies when the file system is > 40G. -- Chris Murphy ___ 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: limiting the (systemd) journal size
On Tue, Sep 27, 2022, at 12:13 PM, Daniel P. Berrangé wrote: > On Tue, Sep 27, 2022 at 10:12:57AM -0600, Chris Murphy wrote: >> Hi, >> >> Fedora uses systemd-journald for system logging. By default it is a >> persistent log kept on /var, and uses up to 4G disk space, although >> in certain circumstances it can go a bit higher. See 'man journald.conf' >> for details. > > snip > >> The obvious bike-shedding questions are: >> Is 4G is too much or too little? If so what amount it should be? >> Is size still the correct approach? Or should we consider a max >> retention time? And if so, what would it be and how granular >> should it be? > > In context of modern physical machines, 4G is probably barely > noticeable for most people, given common physical disks measure > 100's of GBs as a starting point. Dual-boot is pretty common, and so are 128G NVMe drives in new laptops. So it's "sufficiently not rare" that Fedora is being installed into less than 50G that it needs to be accounted for. > > Some people run Fedora on pretty old hardware where disk sizes > may be more limited. > > Virtual machines are probably the place with the biggest disk > usage constraints where, 4GB could be pretty impactful when > a VM may only have a few 10's of GB of storage purchased. Agree. It is possibly similar to the small storage cheap dual-boot baremetal case. > You mentioned '10%' earlier, is that is another existing > limit that's already applied, in addition to the 4GB absolute > size limit ? Yes. SystemMaxUse= defaults to 10% of the file system size, capped to 4G. I'm not certain this is a hard limit, i.e. I think if journals take up just under 4G and a new journal file can be created, it's allowed to grow to the max size which I think is 128M (I've only ever seen 128M sized journals, so it's anecdotal evidence not man page or code based). So it could plausibly grow to ~4.1GiB? > If so that'd obviously benefit the small disk > scenarios. A relative limit is going to be way oversized > for large disk scenarios though. > > Both absolute and relative size limits look complementary > and neccessary. Currently SystemKeepFree= is 15% of file system size. Once free space goes below that limit, systemd will stop growing its usage, but won't reduce its usage. > I wonder if max retention is actually useful at all though, > at least for generic out of the box usage > > For systems with low rate of logging, the size of the journal > will grow slowly enough that max retention won't have a notable > impact for along time. > > For systems with high rate of logging, a generic max retention > probably won't be aggressive enough to constrain the disk usage > quickly enough to stop problems arising. > > Max rentention time doesn't take into account available disk > storage in any way. Correct, it allows a significant float based on usage, consider space consumption relatively less important than the value reduction of the journal entries over time. This is what rsyslogd does, which I think its default retention is two weeks (?) and is configurable. If you think most users most of the time have no need or expectation of needing journal entries beyond X weeks, then you'd presumably be a proponent of a relatively more dominant retention time policy (while still allowing for the max use limit). > > While there might a sweet spot, its effectiveness looks to > be somewhat limited, narrow in scope & unlikely to please a > broad enough userbase. IOW, combination of abs+rel size limits > look a more generally effective OOTB setting to avoid storage > over use. > > Max retention time looks most relevant/useful as a mechanism for > implementing organizational policies on data record keeping times, > and quite site specific. True but also pretty common in the era before systemd-journald in which it really was predominately time based rentention. -- Chris Murphy ___ 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: limiting the (systemd) journal size
On Tue, Sep 27, 2022, at 10:59 AM, Gregory Bartholomew wrote: >> >> What about modifying /etc/systemd/journald.conf: >> >> MaxFileSec=1week >> MaxRetentionSec=5week >> >> This should result in at least 4 weeks of journal entries, i.e. it would >> delete a journal >> file once entries reach 5 weeks old, but since the journal files are rotated >> weekly, it >> should mean a given journal file won't have more than a week's worth of >> entries. >> So you'd have between 4-5 weeks worth of entries at any given time. > > Thanks for the tip. That does look like a better solution and I'll do > that for my containers. Although, since I don't want it to hinder > future updates of /etc/systemd/journald.conf, I'll put those lines in > /etc/systemd/journald.conf.d/override.conf. I hadn't considered the container case at all, that containers running systemd-journald would have their own journals and retention policy. I wonder if the container default should have volatile journals? Or forward the journals to the host by default? But yes I can see how many containers each thinking they have a 4G cap could quickly become a problem. -- Chris Murphy ___ 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: limiting the (systemd) journal size
On Tue, Sep 27, 2022, at 10:38 AM, Gregory Bartholomew wrote: > FWIW (probably not much), I have run into an issue with regard to the > default journal size being too large on Fedora Server when running a > bunch of systemd-nspawn containers each with sshd and fail2ban enabled. > When I reboot a bunch of the containers at once (or the whole > hypervisor), fail2ban really seemed to bog things down and use a lot of > CPU time (re)scanning the journals for failed ssh attempts to (re)ban > the IP addresses. In my case, I worked around the issue with the > following. The real problem might be with my fail2ban configuration or > something else. But it might be something to consider when thinking > about what would be a good size/time limit for the journal. > > # cat /etc/systemd/system/fail2ban.service.d/override.conf > [Service] > ExecStartPre=/usr/bin/journalctl --vacuum-time=1months What about modifying /etc/systemd/journald.conf: MaxFileSec=1week MaxRetentionSec=5week This should result in at least 4 weeks of journal entries, i.e. it would delete a journal file once entries reach 5 weeks old, but since the journal files are rotated weekly, it should mean a given journal file won't have more than a week's worth of entries. So you'd have between 4-5 weeks worth of entries at any given time. -- Chris Murphy ___ 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
limiting the (systemd) journal size
Hi, Fedora uses systemd-journald for system logging. By default it is a persistent log kept on /var, and uses up to 4G disk space, although in certain circumstances it can go a bit higher. See 'man journald.conf' for details. Example: >Sep 27 07:26:05 fovo.local systemd-journald[602]: System Journal >(/var/log/journal/$machine_id) is 385.9M, max 4.0G, 3.6G free. In this example Fedora 37 Workstation system, logging is happening since August 20, is about 10M/day of journal accumulation, or 1.12 years of journals before garbage collection begins. Exactly what will trigger garbage collection depends on the system. There are quite a few knobs for adjusting various aspects of retention and how granular the garbage collection will be. e.g. it's common to see 64M system journal files that contain weeks of entries. It's also possible to limit the journal file size, thus improving granularity whether to retain a bit more or less than the ideal amount. Some folks use services with verbose or debug logging. 4G might only be a few months of logs in such a case. Whereas other folks have a small root device in which even the smaller of 10% or 4G can be quite a lot and in certain cases is not a hard limit. Also note that on Btrfs with compression enabled, the stored amount is quite a bit less. Like all of user space, systemd-journald sees the uncompressed file sizes, so its retention behavior hasn't changed as a result of btrfs compression. What has changed is we're only (physically) storing about 1/3 of whatever the max retention is on a given system. The obvious bike-shedding questions are: Is 4G is too much or too little? If so what amount it should be? Is size still the correct approach? Or should we consider a max retention time? And if so, what would it be and how granular should it be? Also, what's the scope? Is a change needed Fedora-wide, in a manner that's upstreamable? That could prove difficult because any change will negatively impact other use cases, not least of which is what the upgrade behavior should be if it'll involve trimming journals. Are the current defaults optimal for most use cases most of the time? There will be a higher burden of persuasion to get a Fedora-wide change, rather than optimizing for just desktops. But that isn't intended to limit the discussion to just the desktop case. Just to be aware that the broader and grander the change, the more consideration of the consequences there needs to be, i.e. less bike shedding. More background and discussion upstream and Workstation working group issues. [1] [1] https://pagure.io/fedora-workstation/issue/213 https://github.com/systemd/systemd/issues/17382 -- Chris Murphy ___ 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: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On Tue, Sep 20, 2022, at 9:50 AM, Brian C. Lane wrote: > On Mon, Sep 19, 2022 at 12:16:33PM -0700, Adam Williamson wrote: >> "The installer must be able to install into free space alongside an >> existing clean Windows installation and install a bootloader which can >> boot into both Windows and Fedora." >> >> to say: >> >> "The installer must be able to install into free space alongside an >> existing clean Windows installation. As long as the Windows >> installation does not have BitLocker enabled, the installer must also >> install a bootloader which can boot into both Windows and Fedora." > > We have reached a point where boot security is important enough that > Windows is now only allowing their bootloader to be used. With bitlocker > enabled this is working exactly how it was designed so I'd change the > wording to require that grub2 doesn't prevent windows from continuing to > boot via their preferred method and leave it at that. > > And while there may be a possible solution using BootNext, until someone > does the work and tests it there is no point in requiring grub2 to do > something it cannot do. An additional topic is having boot entries for Windows (and macOS) that don't work in the meantime. While we could just remove the scripts that create these entries to chainload another bootloader, they're still needed for BIOS systems which don't support bootnext. -- Chris Murphy ___ 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: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On Mon, Sep 19, 2022, at 1:16 PM, Adam Williamson wrote: > > "The installer must be able to install into free space alongside an > existing clean Windows installation and install a bootloader which can > boot into both Windows and Fedora." > > to say: > > "The installer must be able to install into free space alongside an > existing clean Windows installation. As long as the Windows > installation does not have BitLocker enabled, the installer must also > install a bootloader which can boot into both Windows and Fedora." Workstation working group discussed it at today's meeting, and there were no objections to the language change proposal. -- Chris Murphy ___ 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: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On Mon, Sep 19, 2022, at 2:45 PM, Robbie Harwood wrote: > The only way to get the TPM state to match not using a particular loader > is to not use a loader - i.e., have grub2 (or efibootmgr in Fedora > userspace) set EFI BootNext and reboot the machine. I know systemd-boot does implement bootnext, can modify it in NVRAM. But last I checked GRUB can't. I've asked upstream GRUB about supporting bootnext and a reboot, but the discussion didn't go anywhere. Is there any interest or work happening to make this possible? Because if not, then it seems the only way forward is efibootmgr, and see if desktops want to add a GUI wrapper around it. -- Chris Murphy ___ 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: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement
On Mon, Sep 19, 2022, at 2:45 PM, Robbie Harwood wrote: > I'm fine with the proposed change. I'm also fine with the original > text. > > During boot, certain actions are taken that are recorded in the TPM. > These include, for instance, any loaders that are run - like grub2. The > result is that if you load Windows from grub2 rather than the EFI > firmware, the TPM state will be different. Bitlocker cares about this > TPM state. > > So: if you install Windows and set up Bitlocker booting through grub, it > will continue to work through grub. The Windows installer drops a payload on the drive, and sets a bootnext for an entry that points to the Windows bootloader, not via GRUB. And then, the instant we update either shim or grub, Windows boot will break. I think working around this is sufficiently tedious no users are likely to do it. -- Chris Murphy ___ 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: Heads-up / for discussion: dnf not working with 1G of RAM or less
On Tue, Aug 30, 2022, at 9:43 AM, Chris Murphy wrote: > On Tue, Aug 30, 2022, at 8:27 AM, Richard W.M. Jones wrote: >> Another is that LUKS filesystem decryption uses a deliberately >> "memory-hard" algorithm called Argon2 which requires loads of RAM and >> sometimes has problems running on a machine with 1GB and no swap. > > The built-in default for cryptsetup on Fedora is LUKS2 which uses > argon2id with parameters: > Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4 > > It is possible to specify a different memory requirement at luksFormat > time. But I'm not sure if there's any warning emitted by cryptsetup if > there's significant memory pressure, i.e. high potential that a future > Fedora might fail to open this volume. But yeah, if we have use cases where an encrypted image is created on a system or in a container with plenty of memory, thus the high memory requirement of the default applies, but then is later used with libguestfs in a container or VM with less memory available, it's a possible problem. I'm not really sure what the resolution for this is though. We'd either have to change the cryptsetup default to something like 512MB Fedora wide, or the burden is on the create time sysadmin to override the Fedora default. -- Chris Murphy ___ 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: Heads-up / for discussion: dnf not working with 1G of RAM or less
On Tue, Aug 30, 2022, at 8:27 AM, Richard W.M. Jones wrote: > Another is that LUKS filesystem decryption uses a deliberately > "memory-hard" algorithm called Argon2 which requires loads of RAM and > sometimes has problems running on a machine with 1GB and no swap. The built-in default for cryptsetup on Fedora is LUKS2 which uses argon2id with parameters: Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4 It is possible to specify a different memory requirement at luksFormat time. But I'm not sure if there's any warning emitted by cryptsetup if there's significant memory pressure, i.e. high potential that a future Fedora might fail to open this volume. -- Chris Murphy ___ 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: Heads-up / for discussion: dnf not working with 1G of RAM or less
On Mon, Aug 29, 2022, at 11:12 AM, Chris Murphy wrote: > On Mon, Aug 29, 2022, at 11:10 AM, Adam Williamson wrote: >> There *is* a workaround, BTW - I didn't mention this in my original >> mail, and probably should have. At least according to discussion in the >> bug, microdnf works OK. So you can use that instead. > > Yes, but will you be able to install it? Yes you could go to koji, > download the correct RPMs, and have rpm do it without dnf but... that'd > be a pretty saucy work around. Can microdnf and dnf co-exist? If so, maybe the non-desktops should just include microdnf along side dnf? Or is this potentially a trap where microdnf can also fail for the same reason (i.e. it's not dnf, it's the size of the repo metadata)? -- Chris Murphy ___ 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: Heads-up / for discussion: dnf not working with 1G of RAM or less
On Mon, Aug 29, 2022, at 11:10 AM, Adam Williamson wrote: > On Mon, 2022-08-29 at 10:53 +0200, Fabio Valentini wrote: >> On Mon, Aug 29, 2022 at 9:53 AM Brian (bex) Exelbierd >> wrote: >> > >> > I wonder if we should take another approach here. Assuming no serious bugs >> > in dnf, rather than tuning dnf for low memory environments could we >> > suggest those folks use Fedora Silverblue, CoreOS, or IoT? >> >> Just speaking for myself: I have Fedora installations on 1G RAM VM >> servers that I've been upgrading for many years now, and they just >> keep chugging along as of Fedora 35. If I would need to either 1) pay >> twice the money per month to keep this setup, or 2) spend a few days >> reprovisioning the servers with Fedora CoreOS 36 (assuming it doesn't >> suffer from the same problem), then I'd consider neither of these >> options a desirable outcome. > > There *is* a workaround, BTW - I didn't mention this in my original > mail, and probably should have. At least according to discussion in the > bug, microdnf works OK. So you can use that instead. Yes, but will you be able to install it? Yes you could go to koji, download the correct RPMs, and have rpm do it without dnf but... that'd be a pretty saucy work around. -- Chris Murphy ___ 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: [fedora-arm] Heads-up / for discussion: dnf not working with 1G of RAM or less
On Mon, Aug 29, 2022, at 4:49 AM, Hans de Goede wrote: > 1. ZRAM helps a lot here, but I guess with containers when limiting them > to 1G you really only get 1G since ZRAM works on the system level not > the container level. In the VM case though ZRAM should help, is ZRAM > enabled ? ZRAM is enabled by default for Workstation installs, but > maybe not in other installs ? swap on zram is used on all Fedora variants except CoreOS. > 2. Maybe there are some other processes also taking up more RAM > then expected causing extra memory pressure ? I've found 'below' (in Fedora repo) very useful in tracking down processes that are contributing to memory, cpu, or io pressure - using cgroups accounting. It's possible to zoom in on a cgroup, see individual processes, their memory, io, cpu and swap activity. Pressure (PSI) is useful because it results in latencies, potentially everywhere else. So when you suspect bad behavior in your app, it might be because something else is soaking resources. Your app might be legitimately putting memory or cpu or io pressure on the system, that's the primary purpose of the setup, to service that app. So it can sometimes be difficult to figure out whether your app's resource requirements are reasonable/normal or if it's run away. -- Chris Murphy ___ 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
F36->F37 dnf system upgrade errors
f-fonts" No match for group package "google-noto-sans-takri-vf-fonts" No match for group package "vdr-skinsoppalusikka" No match for group package "banshee" No match for group package "google-noto-sans-ugaritic-vf-fonts" No match for group package "polarsys-b612-sans-fonts" No match for group package "google-noto-sans-thai-looped-vf-fonts" No match for group package "xorg-x11-drv-armsoc" No match for group package "google-noto-sans-marchen-vf-fonts" No match for group package "google-noto-sans-anatolian-hieroglyphs-vf-fonts" No match for group package "google-noto-sans-hatran-vf-fonts" No match for group package "google-noto-sans-osmanya-vf-fonts" No match for group package "kanjistrokeorders-fonts" No match for group package "google-noto-serif-tangut-vf-fonts" No match for group package "bcm283x-firmware" No match for group package "google-noto-sans-vai-vf-fonts" No match for group package "ubuntu-title-fonts" Error: Problem: problem with installed package python3-cchardet-2.1.7-5.fc36.x86_64 - package python3-cchardet-2.1.7-5.fc36.x86_64 requires python(abi) = 3.10, but none of the providers can be installed - python3-3.10.6-1.fc36.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) # dnf group list hidden Last metadata expiration check: 2:17:32 ago on Tue 16 Aug 2022 02:21:40 PM EDT. Available Environment Groups: Fedora Custom Operating System Minimal Install Fedora Server Edition Fedora Cloud Server KDE Plasma Workspaces Xfce Desktop LXDE Desktop LXQt Desktop Cinnamon Desktop MATE Desktop Sugar Desktop Environment Deepin Desktop Development and Creative Workstation Web Server Infrastructure Server Basic Desktop i3 desktop Installed Environment Groups: Fedora Workstation Installed Groups: Anaconda tools base-x Container Management Core Firefox Web Browser Fonts GNOME Guest Desktop Agents Hardware Support LibreOffice Multimedia Common NetworkManager Submodules Printing Support Sound and Video Virtualization Fedora Workstation product core x86 Baremetal Tools Available Groups: [snip] -- Chris Murphy ___ 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
On Mon, Aug 1, 2022, at 6:51 AM, Kamil Paral wrote: > > I suppose Anaconda would have to be involved, detect encrypted partitions and > provide a hint when the bootloader is created. It would be a static solution, > far from ideal, but arguably better than the current state. I think a GRUB patch is needed in the mkconfig scripts, to check for Bitlocker and when present inhibit creation of the Windows boot entry. The problem with that is it's silent, looks like Windows is missing. So yeah, also needed is some kind of Anaconda informational message. -- Chris Murphy___ 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: future of dual booting Windows and Fedora, redux
On Fri, Jul 29, 2022, at 9:29 AM, Philipp Homann wrote: > Hi, > > haven't read all the posts, maybe this was mentioned in one of them. > > What about an EFI binary, which sets the next boot entry and initiates > a reboot? > This can be loaded by grub with the next boot device as parameter, > which can be dynamically set on grub config generation. > Or even as a BLS entry. I guess GRUB could chainload this EFI program. The EFI program looks for the "Windows" boot entry in NVRAM and sets it as bootnext, then reboots the system. Of course this EFI binary would need to be signed with an appropriate Fedora CA for UEFI Secure Boot. I don't know if making this a standlone EFI program really accelerates getting it ready to deploy, compared to just making it a GRUB module. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Fri, Jul 29, 2022, at 5:25 AM, Lennart Poettering wrote: > On Fr, 29.07.22 00:21, Peter Boy (p...@uni-bremen.de) wrote: > >> > One is not really supposed to have multiple ESPs >> >> I have another question regarding multiple ESPs, maybe a bit >> off-topic. For software raid we currently have a kind of „off-label >> use“. Anaconda puts the ESP on a raid partition (and the /boot >> partition as well) and so the partition is marked as RAID and not as >> ESP. I know, there are several alternatives in development to >> synchronise ESP partitions, but none is included in Anaconda. And >> maybe none of the alternatives is ready for production. How does >> this fit into the plans being discussed here? It is an important >> issue for Fedora Server. > > That's a terrible idea. UEFI file system drivers are > read/write. The built-in FAT driver is rw. The efifs drivers (via GRUB) are ro. Yes it's a terrible idea. I've mentioned this many times elsewhere it's come up. I'm not sure whether the loophole to use mdadm RAID1 for ESP is still in Anaconda. Originally it was added, as I understand it, because a RHEL customer requested it. > Given that firmware and uefi programs can and do write through the > official sanctioned UEFI APIs to the ESP using RAID on ESP is a really > bad idea — unless the firmware also implements your flavour of > RAID. But it would be news to me that firmwares exist that support > Linux software RAID natively. Intel IMSM format is supported by Linux software RAID. You can use Intel firmware RAID a.k.a. fake-RAID for this. Or any firmware RAID using a format supported by mdadm including DDF. Otherwise, right now, the sync use case is in bootupd's court. > I mean, my understanding is that you want to increase reliability by > having a working ESP around on multiple disks. But by doing such > off-label use stuff you just create problems for yourself that > decrease realiability. Yep. Software RAID to increase uptime following failure is OK. But degraded boot is fraught with problems and unreliability. I don't think it should be a requirement for any Fedora product. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Fri, Jul 29, 2022, at 4:38 AM, Kamil Paral wrote: >> - Documentation: GRUB's Windows boot option may not work, how to use >> efibootmgr --bootnext and --bootorder > > Currently there is this (insufficient, of course): > https://ask.fedoraproject.org/t/windows-with-encrypted-disks-bitlocker-cant-be-booted-from-the-grub-boot-menu/20612 Looks pretty good actually. What's missing or unclear? I think we should consider swapping the built-in bootmanager and efibootmgr sections. The efibootmgr section needs enhancement first: how to find the Windows boot entry number; use case 1: do a one time boot of windows with --bootnext; use case 2: persistently make Windows or Fedora the default boot OS with --bootorder; use case 3: boot Fedora from Windows when Windows is the default boot OS. Each with examples and screenshots. The efibootmgr CLI is a consistent interface for everyone. It's much easier to document concisely. The firmware method defies screenshots or examples. I'd either make it a secondary section or remove it, but have no strong feeling about it. > > I'd like to see some proper guide available in Fedora Docs/Quick Docs/wiki > that I could reference from that Common Issue entry. I'd like Ask and Quickdoc to be essentially identical. This no conflicting info between them. Each is a single authoritative source. And each should be updated in parity. >> In the near term, we're looking at an awareness and documentation effort, >> while seeing how the other options shake out. And it probably doesn't >> significantly matter whether we change the release criterion now or also >> wait a bit longer. > > We can change the criterion shortly before Final, if needed. Since we expect > the situation to improve in the future, we could just add a (temporary) > footnote to the existing criterion saying that the special case of Windows > partitions encrypted by Bitlocker are exempt from the requirement (of booting > Windows from GRUB). > One pretty big weakness I missed in the summary: the non-functional Windows menu item in GRUB. That's quite a trap. I'm not sure any documentation adequately addresses this. But I also don't know an easy way to detect this situation and either inhibit creation of or remove this item. -- Chris Murphy___ 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: future of dual booting Windows and Fedora, redux
On Thu, Jul 28, 2022, at 2:47 PM, Gregory Bartholomew wrote: > On Thu, Jul 28, 2022 at 1:34 PM Chris Murphy wrote: >> Seems to me the only valid type code for a merged ESP+XBOOTLDR is ESP. What >> am I missing? > > Right. I'd like to use the ESP type code for the merged ESP+XBOOTLDR so that > the firmware will pick it up properly. The only problem is when using the > bootctl command to initialize that partition (/boot), it requires that I set > the SYSTEMD_RELAX_XBOOTLDR_CHECKS variable. I don't think it should require > setting that environment variable in that case. But maybe I'm using the > command incorrectly? The command I'm running is: > > SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot > --esp-path=/boot omit --boot-path and have only an --esp-path > > I think you have to set both "--boot-path" and "--esp-path" to the same value > to get the merged partition. If I leave off "--boot-path", then I don't have > to set the variable. But I'm not sure that it will configure everything > correctly in that case. Will it? It should. BLS envisions two configurations: ESP only, contains all files; ESP contains bootloaders, XBOOTLDR contains /loader/entries and everything else. There isn't really a concept of one partition being both ESP and XBOOTLDR. An argument could be made in favor of two ESPs instead of an ESP and XBOOTLDR, but whatever. I'm not going to make it. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Thu, Jul 28, 2022, at 2:05 PM, Gregory Bartholomew wrote: > > Also, this might be a little off-topic, but I've recommend that people use > systemd-boot when trying to dual-boot Windows before: > https://ask.fedoraproject.org/t/dual-booting-windows-10-and-fedora-34/14158/2 > The user reported that they were happy with that solution later on in that > thread, but one annoyance I have is that it requires setting a > "SYSTEMD_RELAX_XBOOTLDR_CHECKS" variable before running "bootctl install". Is > that really necessary? The purpose of XBOOTLDR, "shared $boot" is sufficiently different purpose than "dedicated $boot" to warrant differentiation with unique partition type GUIDs. That's the purpose of partition type GUIDs. > I'd like to request that systemd-boot "automatically" accept/recognize a > merged ESP+XBOOTLDR partition without having to set that special variable. Seems to me the only valid type code for a merged ESP+XBOOTLDR is ESP. What am I missing? -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
OK. Happy day, we have maybe come full circle. Here's my attempt at a summary: * systemd-boot should be evaluated for Secure Boot signing, so that it can be a viable and testable alternative bootloader to GRUB. Maybe this opens the door to changing the default bootloader in Fedora down the road. It already supports modifying the UEFI bootnext variable, followed by a reboot, when choosing Windows from its menu. Thus it could help resolve the Bitlocker issue. * Unresolved is how to address the current blocker bug Long term approaches (not Fedora 37, maybe Fedora 38 or beyond): - fix/enhance GRUB (no interest so far upstream) - use systemd-boot in lieu of GRUB Short term approaches: - Documentation: GRUB's Windows boot option may not work, how to use efibootmgr --bootnext and --bootorder Unknown time frame approaches: - A GUI utility wrapper for efibootmgr. (The seemingly simple often isn't so simple, or maybe it is. I don't know.) In the near term, we're looking at an awareness and documentation effort, while seeing how the other options shake out. And it probably doesn't significantly matter whether we change the release criterion now or also wait a bit longer. ack/nack/patch? -- Chris Murphy ___ 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: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
On Thu, Jul 28, 2022, at 2:11 AM, Vojtech Trefny wrote: > On Wed, Jul 27, 2022 at 5:53 PM Chris Murphy wrote: >> >> >> >> On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote: >> > Once upon a time, Neal Gompa said: >> >> My understanding is that Windows preloads are now blank-encrypted. >> >> That is, there's a BitLocker volume wrapping the filesystem, even with >> >> encryption turned off. It makes encrypting the disk later >> >> significantly easier (it doesn't have to do filesystem resizing and >> >> reallocation games). >> > >> > Huh, okay. It seems cryptsetup can't open it, but dislocker can. >> >> You can do something like >> >> dd if=/dev/nvme0n1p5 skip=1024000 count=2048 2>/dev/null | hexdump -C >> >> And see if that 1MiB range looks like ciphertext (garbage) or plaintext. I >> wouldn't be surprised if it's encrypted, and the encryption key itself isn't >> wrapped, it's just exposed in the Bitlocker metadata in a way dislocker can >> discover and cryptsetup can't (yet) - but I'm speculating. > > This is also what happens if you choose to "decrypt" your BitLocker > volume in Windows so if it is this case, cryptsetup doesn't support > it. We intentionally ignored this case mostly because it looked like a > small corner case (if you choose do decrypt the volume, Windows will > in the end fully decrypt the data and get rid of the BitLocker > volume/container), but if it's going to be a widespread use, we might > need to start looking into that. As Milan said, a reproducer and an > upstream issue for cryptsetup would be nice. > >> >> >> > But this does mean that doing anything in anaconda based on detection of >> > BitLocker being present should consider that... >> >> Either libblkid or cryptsetup would need to learn how to differentiate >> between the two kinds of Bitlocker volumes, in order for anaconda to have a >> chance of treating them differently. I'm not sure what the consideration >> would be though. > > If it really is the case described above, from libblkid point of view, > this is still BitLocker and the data is still encrypted so no > difference in how it should be handled -- mount cannot mount it, > ntfsresize cannot resize it so for all intents and purposes it is a > BitLocker volume and we cannot treat it differently just because the > volume key itself is not protected. > I think one of the thread responders was thinking that it would be possible to still use a GRUB menu entry for the decrypted BitLocker case. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Wed, Jul 27, 2022, at 9:46 PM, Stephen Smoogen wrote: > > > On Wed, Jul 27, 2022 at 17:37 Chris Murphy wrote: >> >> >> On Wed, Jul 27, 2022, at 5:07 PM, Lennart Poettering wrote: >> > On Mi, 27.07.22 17:01, Chris Murphy (li...@colorremedies.com) wrote: >> > 65;6800;1c >> >> >> If the additional barrier to adoption that Fedora imposes is that >> >> every distro needs to also include signed efifs ext4 in order to >> >> read $BOOT, I think it's too much. >> > >> > I do not follow that logic. First of all, if they can sign grub or >> > sd-boot they should be able to sign efifs too. Secondly, they could >> > just embedd the relevant efifs driver in the sd-boot binary, and sign >> > the result (see other mail). Hence, you build two binaries. Make one >> > of them. Sign one binary. >> >> Sure. But all the distros need to support and build efifs drivers in order >> to support at least common $BOOT file systems across all of Linux, if >> they're really truly committed to BLS, if not arbitrary file systems. >> >> There's at least ext4, XFS, Btrfs widely used as $BOOT by default these >> days. But more when looking at what distro installers allow /boot to be: >> f2fs, ZFS, LUKS, LVM... >> >> Seems like a Pandora's box to me. > > But isn’t what you are outlining an existing Pandora’s box you are going to > have to deal with? All those systems are existing already and will be in > place. Telling all couple hundred thousand dual boosters you have to reformat > a partition to play with the new thing is also a high bar to deal with. I'm lost. I'm trying to figure out how Fedora users with Windows Bitlocker enabled, can still boot Windows in a sane way. None of the four ideas I put forward require reformatting anything. a. Fix/enhance GRUB so it uses "bootnext" and a reboot to directly use the Windows bootloader b. Create a user space utility that can use "bootnext" (optionally also "bootorder" for persistent change) to directly use the Windows bootloader c. Change the release criterion (I don't know that this really gets us off the hook, it's just a plain bad experience even without a criterion) d. Shout from a mountain for more help (punt) The systemd-boot idea is not one I oppose, but it's not going to happen until Fedora 38 at the soonest, even if someone proposed it, even if it got accepted. It looks to me like a moonshot, thus not that interesting when we have a problem to solve now. > There is also going to be issues where various windows software is going to > see this mountable partition and play with it. Going from past experience > every anti virus will freak out at least once a month over seeing Linux > executables on a fat partition and quarantine them. As far as I'm aware, Windows ignores GPT partition type GUIDs it doesn't recognize. You have actually experienced what you're describing? > Yes your system is easier to deal with but it is still not as simple as it > seems to be seen. It is going to be painful in new ways Still not sure what the context is. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Wed, Jul 27, 2022, at 5:07 PM, Lennart Poettering wrote: > On Mi, 27.07.22 17:01, Chris Murphy (li...@colorremedies.com) wrote: > 65;6800;1c >> If the additional barrier to adoption that Fedora imposes is that >> every distro needs to also include signed efifs ext4 in order to >> read $BOOT, I think it's too much. > > I do not follow that logic. First of all, if they can sign grub or > sd-boot they should be able to sign efifs too. Secondly, they could > just embedd the relevant efifs driver in the sd-boot binary, and sign > the result (see other mail). Hence, you build two binaries. Make one > of them. Sign one binary. Sure. But all the distros need to support and build efifs drivers in order to support at least common $BOOT file systems across all of Linux, if they're really truly committed to BLS, if not arbitrary file systems. There's at least ext4, XFS, Btrfs widely used as $BOOT by default these days. But more when looking at what distro installers allow /boot to be: f2fs, ZFS, LUKS, LVM... Seems like a Pandora's box to me. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Wed, Jul 27, 2022, at 4:47 PM, Lennart Poettering wrote: > On Mi, 27.07.22 16:19, Chris Murphy (li...@colorremedies.com) wrote: > >> >> Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or >> >> Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be >> >> FAT in order to fulfill the interoperability intent of the spec, because >> >> it is a shared $BOOT across all distros. >> > >> > You can use any FS you want with efifs[1]. >> >> Yeah, but it's impractical: >> >> * $BOOT is supposed to be readable by all distros that share $BOOT > > Hmm, afaik fedora installs /boot/ currently as ext4, no? *Every* Linux > OS should be able to mount that... I'm talking about distro bootloaders being able to read $BOOT in the pre-boot environment. If Fedora decides $BOOT Is ext4, that binds other distros looking to adopt BLS into shipping signed efifs ext4 too, in order to use the same $BOOT format we are. Or else, ignore our XBOOTLDR and create their own, in which case we're right back to square one, which is mutually exclusive /boot, no sharing or cooperation between distros. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Wed, Jul 27, 2022, at 4:30 PM, Lennart Poettering wrote: > So, let's say you want to make sd-boot be able to access a legacy ext4 > /boot/ fs. First, fix the GPT partition type of that /boot/ partition > to be the XBOOTLDR one (so that sd-boot can recognize it; currently > fedora for some reason marks it as "generic Linux partition"). Then > take the ext4 uefi driver from the project above, sign it as you sign > every EFI binary, and drop it into the /EFI/systemd/drivers/ directory > on the ESP. This is all you need to do, as sd-boot looks into that > dir, and automatically loads all drivers found there. Works for single distro installation, sure. But the intent and promise of BLS is distro interoperability with a shared $BOOT among multiple distros. If the additional barrier to adoption that Fedora imposes is that every distro needs to also include signed efifs ext4 in order to read $BOOT, I think it's too much. But also we need verification and clarification on this "GRUB only" proscription by Microsoft of any other bootloader, mentioned earlier in this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/W6BI4G7NST6WXIMF6GPAKC6R4EE6OS2D/ -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Wed, Jul 27, 2022, at 4:27 PM, Vitaly Zaitsev via devel wrote: > On 27/07/2022 22:19, Chris Murphy wrote: >> * $BOOT is supposed to be readable by all distros that share $BOOT > > It will. efifs will be installed to ESP partition. > >> * efifs drivers must be signed in order to be loaded on UEFI Secure Boot >> enabled systems > > True. But I think Fedora can sign drivers from the efifs package with > own keys. > >> * shim is distro specific, and is what provides the key for efifs as well as >> the 2nd stage bootloader > > I prefer no shim in my computers. I'm using systemd-boot signed by my > own CA. That is not a generic solution we can ship in Fedora. Since each distro ships their own shim, they'd each have to ship their own signed fsfs in order to read the shared a non-FAT $BOOT. It's too high a barrier to adoption. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Wed, Jul 27, 2022, at 2:36 PM, Vitaly Zaitsev via devel wrote: > On 27/07/2022 18:53, Chris Murphy wrote: >> Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or >> Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be FAT >> in order to fulfill the interoperability intent of the spec, because it is a >> shared $BOOT across all distros. > > You can use any FS you want with efifs[1]. Yeah, but it's impractical: * $BOOT is supposed to be readable by all distros that share $BOOT * efifs drivers must be signed in order to be loaded on UEFI Secure Boot enabled systems * shim is distro specific, and is what provides the key for efifs as well as the 2nd stage bootloader There are already enough barriers to Boot Loader Spec adoption. But this would be too big a barrier. Again though, I think the sd-boot discussions really need to go in a separate thread so they have the proper visibility rather than being hidden in an rather distinctly unrelated thread. In this thread we need to focus on solutions for the immediate problem of dual boot with Bitlocker enabled. -- Chris Murphy ___ 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: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
On Wed, Jul 27, 2022, at 1:17 PM, Milan Broz wrote: > On 27/07/2022 17:52, Chris Murphy wrote: >> On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote: >>> Once upon a time, Neal Gompa said: >>>> My understanding is that Windows preloads are now blank-encrypted. >>>> That is, there's a BitLocker volume wrapping the filesystem, even with >>>> encryption turned off. It makes encrypting the disk later >>>> significantly easier (it doesn't have to do filesystem resizing and >>>> reallocation games). >>> >>> Huh, okay. It seems cryptsetup can't open it, but dislocker can. >> >> You can do something like >> >> dd if=/dev/nvme0n1p5 skip=1024000 count=2048 2>/dev/null | hexdump -C >> >> And see if that 1MiB range looks like ciphertext (garbage) or plaintext. I >> wouldn't be surprised if it's encrypted, and the encryption key itself isn't >> wrapped, it's just exposed in the Bitlocker metadata in a way dislocker can >> discover and cryptsetup can't (yet) - but I'm speculating. >> >> >>> But this does mean that doing anything in anaconda based on detection of >>> BitLocker being present should consider that... >> >> Either libblkid or cryptsetup would need to learn how to differentiate >> between the two kinds of Bitlocker volumes, in order for anaconda to have a >> chance of treating them differently. I'm not sure what the consideration >> would be though. >> > > If you report this as a bug for cryptsetup (with description how to > create such Bitlocker volume), we can check how to fix it. > > Otherwise nothing happens :-) Yeah that's what I meant by "(yet)" :D -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Wed, Jul 27, 2022, at 12:11 PM, Daniel P. Berrangé wrote: > On Wed, Jul 27, 2022 at 10:13:57AM -0400, Chris Murphy wrote: >> >> >> On Wed, Jul 27, 2022, at 4:42 AM, Daniel P. Berrangé wrote: >> > >> > Since you say systemd-boot can already do what we want in this regard: >> > >> > e. Replace grub for EFI systems with systemd-boot ? >> >> I wish it were possible. I'm pretty sure the Red Hat bootloader team >> has no time or interest in it. And there's no upgrade path, because >> systemd-boot requires a FAT /boot volume. The lack of an upgrade path, >> I think, is a bigger issue than a system-wide change proposal to: >> switch to systemd-boot on UEFI, including FAT /boot partition, for >> new clean installs. > > AFAICT, use of /boot is entirely optional, and is ignored if it > can't be accessed (due to either not existing, or having an unsupported > filesystem type). I've got VMs booting with system-boot where /boot is > xfs and systemd-boot pulls the kernel found in /boot/efi. Boot Loader Spec defines $BOOT as either EFI System partition (ESP) or Extended Boot Loader Partition (XBOOTLDR), and in effect they need to be FAT in order to fulfill the interoperability intent of the spec, because it is a shared $BOOT across all distros. While some firmware also can read NTFS or HFS+, we're not likely to ever consider using them for $BOOT. I'm not sure what an XFS /boot would contain when using systemd-boot. > IIUC, the main reason for the loader to use /boot is if /boot/efi > is insufficiently large for storing the kernels, and /boot has > greater space. Admittedly this is probably still the key issue for > the upgrade scenario, since existing Fedora VMs seem to get a /boot/efi > partition that is even smaller than /boot. The main case for XBOOTLDR is dual boot, because we can't control the creation of the ESP. Microsoft and OEMs are still routinely creating 99 MiB ESPs. Otherwise we can have a large ESP, possibly scaled to the size of the drive or possibly extract intent from the user (in a custom partitioning path) about installing additional distros, etc. to reserve the proper amount of space for this shared $BOOT. >> There's quite a lot of GRUB upstream work related to TPM stuff, >> including measured boot. I have no idea if we're going to use any >> of that at some point, but it's not something in systemd-boot's >> realm. > > The Grub support for the RPM measurements is one of the big reasons > for wanting to replace Grub IMHO. Every single statement that is > executed from the grub.conf file gets individually measured into > the TPM[1]. Writing a policy to validate correctness of the measurement > taking into account grub.conf permuations is beyond the bounds of > reasonableness. This is a key problem the virt maintainers are facing > when trying to figure out how to support confidential virtualization, > where we need to measure the boot process. A vastly simplified boot > loader like sd-boot + unified kernels is quite appealing in this area. I don't disagree. But there are Secure Boot impediments that need to be figured out to switch to sd-boot. And I think they need to be explored with the other sd-boot issues in a dedicated thread, because moving to sd-boot is at best Fedora 38 time frame. And the Bitlocker issue needs improvement sooner than that. -- Chris Murphy ___ 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: BitLocker (was Re: future of dual booting Windows and Fedora, redux)
On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote: > Once upon a time, Neal Gompa said: >> My understanding is that Windows preloads are now blank-encrypted. >> That is, there's a BitLocker volume wrapping the filesystem, even with >> encryption turned off. It makes encrypting the disk later >> significantly easier (it doesn't have to do filesystem resizing and >> reallocation games). > > Huh, okay. It seems cryptsetup can't open it, but dislocker can. You can do something like dd if=/dev/nvme0n1p5 skip=1024000 count=2048 2>/dev/null | hexdump -C And see if that 1MiB range looks like ciphertext (garbage) or plaintext. I wouldn't be surprised if it's encrypted, and the encryption key itself isn't wrapped, it's just exposed in the Bitlocker metadata in a way dislocker can discover and cryptsetup can't (yet) - but I'm speculating. > But this does mean that doing anything in anaconda based on detection of > BitLocker being present should consider that... Either libblkid or cryptsetup would need to learn how to differentiate between the two kinds of Bitlocker volumes, in order for anaconda to have a chance of treating them differently. I'm not sure what the consideration would be though. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Wed, Jul 27, 2022, at 4:42 AM, Daniel P. Berrangé wrote: > > Since you say systemd-boot can already do what we want in this regard: > > e. Replace grub for EFI systems with systemd-boot ? I wish it were possible. I'm pretty sure the Red Hat bootloader team has no time or interest in it. And there's no upgrade path, because systemd-boot requires a FAT /boot volume. The lack of an upgrade path, I think, is a bigger issue than a system-wide change proposal to: switch to systemd-boot on UEFI, including FAT /boot partition, for new clean installs. There's quite a lot of GRUB upstream work related to TPM stuff, including measured boot. I have no idea if we're going to use any of that at some point, but it's not something in systemd-boot's realm. > Or at least make systemd-boot a supported option alongside > grub for those who need dual boot with Windows Given resources, I expect it would be more likely to replace GRUB with systemd-boot, on UEFI, than support both. And the likelihood of anything but GRUB I'd put at "very low". I'd like to be wrong but... -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Wed, Jul 27, 2022, at 5:55 AM, Kamil Paral wrote: > > I've been to numerous events where we helped students install Fedora into > dual boot. One of the top 5 questions afterwards (maybe even #1) is "how do I > make it boot Windows by default?". In the old days, that consisted of editing > the grub config file and changing the default selected value to match the > Windows boot item, or when "GRUB_DEFAULT=saved" actually worked, I just told > them "It will remember the last selected option". That was easy enough and > user friendly. > > From the proposed options, only a) satisfies that. It could be an option with b) as well. Just change bootorder so that Windows is first. Efibootmgr supports this too. > > While all of us here are happy to run Fedora by default, let's not forget > about newcomers and their needs, because our user base will die out otherwise. This is a good point to underscore. The user experience following a Fedora installation when Bitlocker is enabled, is the appearance of Windows being broken or inaccessible. We are probably better off asking Anaconda to refuse to install when Bitlocker is detected. Or at least a warning dialog. Or perhaps refuse to install just with Automatic partitioning, i.e. accept a somewhat weak argument that users of Custom/Advanced-Custom can deal with the ensuing confusion->a Windows boot option in the GRUB menu that doesn't boot Windows as expected. > If there's not enough will to implement option a) (or some workaround with > the same effect), we'll have to change our release criterion (option c) - I'd > probably propose some changes to the wording). I just made it match the OS X criterion (which should be renamed macOS, this section is dating itself :P) > I don't see any benefit in delaying the status quo (option d)). But we should > also clarify the situation to our users. On the Fedora download page, we > should make it clear that users with an encrypted drive will not be able to > boot Windows out of the box anymore, and they'll need to take additional > steps to get into Windows. Yeah, I agree that absent software solutions to the problem, we definitely need better documentation. Fedora download page, and Ask Fedora. If there's one thing I'd like to communicate, it's *your data is OK!* You've previous reported users became convinced installing Fedora broke Windows, and resulted in data loss. That's how bad the experience is. And it's sad that some folks just gave up and ended up toasting their own data due to this confusion. The thing I keep coming back to is this is not just bad for Fedora, it's bad for all the distros that support dual boot Windows. > That might include a tool in Fedora (option b)), or figuring out how to get > to a one-time boot menu. I'm not sure how much we can depend on the firmware's built-in boot manager for anything. I'm pretty sure we can depend on the firmware honoring bootnext and bootorder. Windows can show Fedora as a boot option. shift key+restart -> Use A Device -> Fedora. This sets a bootnext variable in NVRAM for the firmware to follow. > It should also contain instructions on how to switch back to the Windows > bootloader by default (after installation, and ideally also as an option > during installation), and how to boot Fedora then. > > A note: Option b) mentions the Windows boot menu would get removed on UEFI > systems - it would be good to do this only if anaconda detects a Bitlocker > partition. There's no need to make it harder for Windows users who do not > have their disks encrypted. GRUB isn't that smart. Bitlocker could be enabled by the user at any time, if it's not enabled by default. My inclination is *if* upstream GRUB Is going to abandon this use case, there might as well be a clean break. Keep it on BIOS, remove it entirely on UEFI. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Tue, Jul 26, 2022, at 7:18 PM, Chris Adams wrote: > Once upon a time, Chris Murphy said: >> a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, >> so that instead of chainloading the Windows bootloader from GRUB, GRUB will >> modify the system NVRAM such that the next boot (only) will directly boot >> the Windows bootloader. Thus far there's no interest by GRUB upstream. >> Whereas systemd-boot has implemented it. > > Is GRUB upstream any more active these days? It is but seems there's no interest in this particular issue. I started a couple threads on this topic previously, but there's not much traction: https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00072.html https://lists.gnu.org/archive/html/grub-devel/2022-03/msg00227.html > IIRC Fedora has a whole > pile of patches; I'm sure nobody wants the pile to grow, but it doesn't > look like that's changing. Could this be implemented in Fedora's GRUB? It's been cut down quit a bit actually. GRUB 2.06 cut the patchset around in half. And GRUB 2.12 release is imminent, which will cut things down farther. Since the Red Hat bootloader team is pretty swamped as it is, and has indicated it needs to drop BIOS support (in favor of the newly minted BIOS SIG) soon, I'm skeptical the bootloader team has at least the time to work on this, maintain it, and try to push it upstream. Thing is, it really needs upstream to agree to it, because if it's not upstreamed, what's the point? This is an issue that affects all distros and quite a lot of users eventually, as Bitlocker by default becomes more prevalent. Maybe this issue needs more visibility? Behind the handful of lists I've tried so far? -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Tue, Jul 26, 2022, at 9:15 PM, Kevin Kofler via devel wrote: > Chris Murphy wrote: >> Summary: Windows 10/11 increasingly enables Bitlocker (full disk >> encryption) out of the box with the encryption key sealed in the TPM. > […] >> The Bitlocker encryption key is unsealed only if the boot chain >> measurement by the TPM matches the expected values in a TPM PCR. > > So, basically, they set up things without the user's knowledge so that the > user's data can only be decrypted from Windows, only when booted directly, > and only with Restricted Boot enabled. Does that not fit the definition of > ransomware? Treacherous Computing at its finest… Does anyone still believe > that all this is about security? cryptsetup does have Bitlocker support, so long as you have the recovery key you can unlock and get access to your data, I've tested this. Bitlocker has nothing to do with Secure Boot. This is entirely beside the point though, which is to try and make dual boot as useful for users as possible. We want users to be confident about both OS's remain accessible in a discoverable way, without having to jump through hoops. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Tue, Jul 26, 2022, at 4:59 PM, Neal Gompa wrote: > On Tue, Jul 26, 2022 at 1:43 PM Kevin Kofler via devel > wrote: >> >> Chris Murphy wrote: >> > On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote: >> >> As I already mentioned the last time this has come up: Why can we not, >> >> instead of chainloading Windows directly, chainload a systemd-boot >> >> configured to always bootnext to Windows? >> > >> > Pretty sure shim still hard codes the name grub$arch.efi as the 2nd >> > bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find >> > and run it. They can't co-exist right now. Also, there's no current plan >> > by anyone to add systemd-boot for Secure Boot signing. >> >> That is not what I suggested. >> >> I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora, >> systemd-boot would be configured to always reboot to Windows, booting Fedora >> from GRUB would bypass it entirely), not shim → systemd-boot → Windows. >> > > That may work indeed, but we'd need to ensure it can't be used as a > stage-two bootloader somehow. Maybe systemd-boot signed with a Fedora key only GRUB provides, and shim does not? Either shim or GRUB must have this key so regardless we need help from folks who can sign Fedora's bootloaders. Seems more complicated compared to a user space program that merely does `efibootmgr --bootnext $windows` -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Tue, Jul 26, 2022, at 4:42 PM, Kevin Kofler via devel wrote: > Chris Murphy wrote: >> On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote: >>> As I already mentioned the last time this has come up: Why can we not, >>> instead of chainloading Windows directly, chainload a systemd-boot >>> configured to always bootnext to Windows? >> >> Pretty sure shim still hard codes the name grub$arch.efi as the 2nd >> bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find >> and run it. They can't co-exist right now. Also, there's no current plan >> by anyone to add systemd-boot for Secure Boot signing. > > That is not what I suggested. > > I suggested shim → GRUB → systemd-boot → Windows (and shim → GRUB → Fedora, > systemd-boot would be configured to always reboot to Windows, booting Fedora > from GRUB would bypass it entirely), not shim → systemd-boot → Windows. OK. But still systemd-boot would need to be signed by Fedora. And be capable of defaulting to Windows, and hidden menu, so it doesn't show bootloader snippets on the boot or EFI volumes. I don't know whether it can be configured this way. It's a Rube Goldberg machine way of doing this. In effect three bootloaders to support. I'm not convinced this is the path of least resistance. But it seems to be worth considering. -- Chris Murphy ___ 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: future of dual booting Windows and Fedora, redux
On Tue, Jul 26, 2022, at 4:06 PM, Kevin Kofler via devel wrote: > As I already mentioned the last time this has come up: Why can we not, > instead of chainloading Windows directly, chainload a systemd-boot > configured to always bootnext to Windows? Pretty sure shim still hard codes the name grub$arch.efi as the 2nd bootloader. Hence having to rename sd-boot as grubx64.efi for shim to find and run it. They can't co-exist right now. Also, there's no current plan by anyone to add systemd-boot for Secure Boot signing. >GRUB would still think it boots > Windows directly. (I do not see why it would notice any difference, all that > would change is the name of the image that gets chainloaded.) And systemd- > boot does not need to know that it is being chainloaded from GRUB. So I do > not see why that would not work, without any changes to the software. -- Chris Murphy ___ 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
future of dual booting Windows and Fedora, redux
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result: 1. Fedora's installer, Anaconda, can't resize Bitlocker volumes. We could use better documentation to help the user perform the volume resize in Windows, before proceeding to booting our installation media. The documentation probably should be explicitly referenced by the Windows version of Fedora Media Writer. 2. The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR. When shim+GRUB are in the boot chain, as is the case in our default dual boot installation, the measurements are wrong, and this means the GRUB menu entry to boot Windows won't work. The user is dropped to a Windows Bitlocker recovery page. If they have their backup encryption key handy, it will work but to say the least this condition is unexpected and not user friendly - not least of which is many users won't have this backup key handy since they didn't take the action to enable Bitlocker in the first place. The bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=2049849 It was a Fedora 36 final release blocking bug, but considered a "difficult to fix" exceptional case, moving it to Fedora 37 final. Some of the options for consideration: a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it. b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader. And also remove the Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.) c. Change the release criterion. https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual_boot Current: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora. Replacement: The installer must be able to install into free space alongside an existing clean Windows installation, install and configure a bootloader that will boot Fedora. d. Consider the problem sufficiently difficult to fix that we need an extension to the exceptional case allowance, and wave the bug for another release. Thoughts? -- Chris Murphy ___ 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 proposal: Make Fedora CoreOS a Fedora Edition (System-Wide change)
On Tue, Jul 5, 2022 at 9:43 PM Dusty Mabe wrote: > > > > On 7/5/22 17:03, Neal Gompa wrote: > > On Sat, Jun 25, 2022 at 2:17 PM Vipul Siddharth > > wrote: > >> > >> > >> == Feedback == > >> > >> This change was previously submitted for Fedora 34 and feedback were > >> collected in the following [https://pagure.io/fesco/issue/2516 FESCo > >> ticket]. > >> The 2 main feedback received are either addressed or in the process of > >> being addressed. > >> > >> * FCOS should not trail behind the latest Major Fedora version: see > >> [[https://fedoraproject.org/wiki/Changes/FedoraCoreOS#Major_Fedora_Version_release_Go/NoGo|Major > >> Fedora Version release Go/NoGo criteria]] > >> > > > > I don't feel this is sufficiently addressed. Why is it that the stable > > stream can't be switched when all the other artifacts are released? > > Why is it two weeks *after* GA? > > Fedora CoreOS is unique in that by default nodes are automatically updated. > We let the exact content > set that we are going to ship to our `stable` stream bake in our `testing` > stream for ~two weeks. This > allows people to find issues that we don't find in our CI and report them. We > find CI is good, but > there is no substitute for real workloads. > > The exact content set delivered as part of Fedora GA isn't available two > weeks before GA date so it's > hard for us to ship GA content in our `stable` stream on GA day and follow > our current update model. > > We do have the `next` stream which does get updated often in the weeks before > GA, but a significantly > smaller set of users are running `next`. Given the amount of testing happening to produce GA, is it possible to have an exception to the 2 week rule for GA? -- Chris Murphy ___ 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: Linux Firmware Minimization (late System-Wide Change proposal)
On Fri, Jul 1, 2022 at 9:47 PM Dusty Mabe wrote: > > > > On 7/1/22 18:14, Neal Gompa wrote: > > On Fri, Jul 1, 2022 at 2:10 PM Michael Catanzaro > > wrote: > >> > >> On Fri, Jul 1 2022 at 01:54:58 PM -0400, Ben Cotton > >> wrote: > >>> A DNF plugin will be written to make use of the `Supplements` metadata > >>> to automatically install the appropriate firmware packages based on > >>> the hardware present on the system (see openSUSE's `libzypp`: > >>> https://github.com/openSUSE/libzypp/blob/a34d857dbe3b16d4a7e0219cd213cc5a87966538/zypp/target/modalias/Modalias.cc > >>> and > >>> https://github.com/openSUSE/libzypp/blob/7f345ea4892fd02345e8de47c2a08ab5b174650b/doc/autoinclude/Modalias.doc) > >> > >> What about Fedora editions that don't have dnf (Silverblue, Kinoite, > >> CoreOS)? > > > > They load libdnf through rpm-ostree, so a libdnf plugin will still work. > > > > I'm not the most qualified to speak to this point, but I'm not sure that just > because rpm-ostree uses libdnf > under the hood this will automatically just work. I suspect that it won't > work. Probably for those variants > we'd just need to include the `linux-firmware-all` package (or whatever > equivalent to get what we currently have). Or could the plugin be used to create rpm-ostree layers with the necessary firmware packages? -- Chris Murphy ___ 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 proposal: Make Fedora CoreOS a Fedora Edition (System-Wide change)
On Sat, Jun 25, 2022 at 12:17 PM Vipul Siddharth wrote: > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > > == Summary == > > This change is to promote Fedora CoreOS to Edition status alongside > Workstation, Server and IoT. Consider updating the proposal to include Cloud since it now has Edition status once again. -- Chris Murphy ___ 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, Jun 27, 2022 at 1:56 AM Florian Weimer wrote: > > * Neal Gompa: > > > I treat Secure Boot purely as a compatibility interface. We need to do > > just enough to get through the secure boot environment. > > Right. It's not even clear to me why we enforce kernel module > signatures in Secure Boot mode, and disable a few other kernel features. If users can load arbitrary unsigned kernel modules or hibernation images, it silently circumvents UEFI Secure Boot. I agree this is a frustrating paradigm for users who want certain features like using 3rd party modules with a Fedora kernel, or using locked down kernel features, but I'm not sure what the alternative is. -- Chris Murphy ___ 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 Spins SIG Proposal: Fedora Mate SIG and Cinnamon SIG
Most things related to testing and prerelease happen in the Fedora QA team. We're just post-release for F36 so there's not a lot of visible activity, but things will be picking up again soon. https://fedoraproject.org/wiki/QA -- Chris Murphy On Sat, Jun 4, 2022, 12:04 PM Ahmed Almeleh < aalmeleh.whatever.0...@gmail.com> wrote: > I could do the testing for you. > > On Sat, 4 Jun 2022 at 17:01, Leigh Scott wrote: > >> The Cinnamon spin (kickstart and comps) are managed by Dan Book. >> >> https://fedoraproject.org/wiki/Changes/Cinnamon_Spin#Owner >> >> >> I'm the only fedora developer working on Cinnamon. >> I don't have any spare time to do more things including testing. >> ___ >> 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 >> > ___ > 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 > ___ 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)
On Thu, Jun 2, 2022 at 6:19 PM Peter Boy wrote: > > > > > Am 02.06.2022 um 22:42 schrieb Neal Gompa : > > > > > > It's not standard at all. We don't even test for this setup regularly. > > It's not a test case, and it's not even supposed to work right now. > > It’s standard as it is a typical use case in private or SME environments. If that's true there should be plenty of people willing to put in the work to make this work reliably. So far they haven't, in particular on UEFI. > And do you really think we distribute dmraid for years now "and it's not even > supposed to work right now.“? dmraid is deprecated in favor of either mdadm or LVM based RAID (both use the kernel's md driver as the backend), for a very long time. dmraid is even deprecate at least as far back as RHEL 7.6 > And don't hide behind formalistic arguments that just suit you by chance. > Your change proposal deliberately makes it impossible for existing server > users (or makes it unnecessarily overly difficult) who have relied (and could > rely) on us so far to continue using Fedora Server. I consider this > irresponsible. And I don't understand why you stubbornly insist on this > change proposal as is, instead of looking for solutions that keep mischief > away from our users and change to GPT as default (which is undoubtedly the > future standard). GPT is already the default when the drive size is > 2 TB, for about a decade. GPT is the default on UEFI since the start. So the problem you're talking about, while real, seems to be a low enough of a priority that no one really wants to fix the problem - so far. You continue to use emotionally charged language as both a distraction from the real issue as well as a motivator to stop a feature. The reality is MBR support is going away, because BIOS support is going away. This feature is part of moving forward with that reality. We cannot make people do work they don't want to do. The solution to the degraded raid problem is actually relatively well understood, it's just that insufficient resources have come forward to actually solve the issue. But that cannot be an impediment for making other necessary changes. > > Also, any system with drives >=2TB will get GPT automatically, you > > can't have MBR in those setups. All this does is remove the default > > special case for smaller disks. > > This is a completely different case. For disks > 2 TB simply nothing changes, > neither better nor worse. For disks < 2 TB your change proposal results in a > deterioration. Why do you want it so badly? It's not completely different, it results in the *exact* problem you're complaining about. You don't get to say the effect of GPT > 2T is OK, but it's a negative when applied to < 2T as if your entire strategy for working "standard" and "typical" use cases means < 2T drives are mandatory. If the use case is important, the issue needs to be fixed. -- Chris Murphy ___ 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)
On Thu, Jun 2, 2022 at 3:27 PM Peter Boy wrote: > > > > > Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek > > : > > > > On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote: > >> > >> ... > >> > >> And even those who can continue to use Fedora Server via update are under > >> the threat of having to switch distributions overnight in the event of a > >> technical error. Fedora will become unusable for them. A great "feature", > >> that you would like to introduce, obviously at all costs. > > > > Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to trigger > > the issue.) > > > According to the latest Anaconda documentation [1] there is no option > inst.mbr, there is just inst.gpt. Maybe, it is an undocumented feature. > > And do we really want our users to fiddle around with editing boot line > options as a standard procedure for using a standard use case? Define standard. I can't tell what you mean by it here. Bootable degraded raid is not a common use case. It's not a default and preset configuration in the installer. You really have to know what you're doing, and you have to know the installer's idiosyncrasies to make the installation work this way. This use case is not in the Server edition product requirements doc, or technical spec doc, or in Fedora release criterion It is true that the use case is reasonable and useful, but it is also unusual. If it's really important, then it at least needs a discussion on the test@ list, with QA folks about how to go about making it a release criterion, which minimally involves (a) writing up the criterion, using unambiguous language, narrowly defining the requirement (b) documentation changes (c) creating test cases (d) resources to actually run the test cases every release cycle (e) optionally+hopfully some portion of the testing can be automated but all the previous items are prerequisites to that. -- Chris Murphy ___ 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)
On Sun, May 29, 2022 at 6:56 AM Peter Boy wrote: > > > > > Am 14.05.2022 um 18:45 schrieb Ben Cotton : > > > > https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault > > > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > == Summary == > > This Change makes it so that Fedora Linux systems installed on legacy > > x86 BIOS systems will get GPT partitioning by default instead of > > legacy MBR partitioning. This makes x86 BIOS installs more similar to > > x86 UEFI installs. > > > > == Owner == > > * Name: [[User:Ngompa| Neal Gompa]], [[User:Dcavalca| Davide > > Cavalca]], [[User:Salimma| Michel Alexandre Salim]], > > [[User:Chrismurphy| Chris Murphy]] > > * Email: ngomp...@gmail.com, dcava...@fb.com, mic...@michel-slm.name, > > chrismur...@fedoraproject.org > > > > > > == Detailed Description == > > Once implemented, Anaconda will create a GPT disk table on > > non-partitioned disks or when the disk is being completely reset when > > Fedora x86 install/live media is booted in BIOS mode. > > Fedora Server WG discussed the proposal and insists that the proposal be > deferred until Anaconda can install software raid on biosboot systems with > GPT (see https://bugzilla.redhat.com/show_bug.cgi?id=2088113 and > https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) > - at least for Fedora Server where software raid is a common use. What's the basis for holding up this feature though? Yes it's a bug, but it wouldn't be a release blocking bug because there's no release criteria covering degraded boot. And on UEFI we already have this problem because multiple ESPs aren't created or populated (sync'd). I think it's a worthwhile use case to improve the current behavior so that it works, but I don't think it's OK to hold up a release indefinitely while insisting other people do the work required to bring such functionality to Fedora. -- Chris Murphy ___ 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