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: reversible dual-boot test station, updated
I've refreshed this write-up based on a system with Windows 10 and Fedora 39 on LUKS on Btrfs, "installing" Fedora 40 along side via dnf system-upgrade. The two installations share /boot, /boot/efi, /home, with the two root file systems on Btrfs in their own subvolumes. https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation Features: * no re-partitioning; * no resizing; * no extra drive; * no installation or reinstallation, system upgrade is used instead; * reversibility, or undoability, i.e. you can delete the "test OS", or for that matter the older system root, with just a few steps. -- Chris Murphy -- ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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
Re: Partitioning in VirtualBox using FedoraCore 40
On Wed, Oct 11, 2023, at 2:21 AM, Adam Williamson wrote: > UEFI is not the default for VirtualBox, according to its documentation I haven't used VirtualBox in a long time, but my vague recollection is it has a wizard for creating VMs. And in the case you tell it the OS you're going to install is macOS, it will create a VM with UEFI firmware. If you repurpose such a VM, or clone it, it'll still have UEFI firmware. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Partitioning in VirtualBox using FedoraCore 40
On Tue, Oct 10, 2023, at 11:25 PM, George R Goffe wrote: > Chris, > > Thanks for responding. > > Here's the desired partition scheme: > > /boot > / > swap > /var > /opt > /usr > /export/home It's missing /boot/efi which is required on systems with UEFI firmware. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Partitioning in VirtualBox using FedoraCore 40
On Tue, Oct 10, 2023, at 9:04 PM, George R Goffe via test wrote: > Hi, > > I'm having trouble creating a partition scheme that I have been using > it seems like forever. Describe the scheme. > I keep getting this popup error message (enclosed). It looks like > anaconda is choosing to try partitions named by appending "/efi" to the > partition name. Looks to me like the same message multiple times, itself a bug (though cosmetic). I've only ever seen this message when the EFI system partition, which is defined as a partition assigned to /boot/efi as the mount point, is formatted ext4 (or anything other than EFI file system, which off hand I forget the term anaconda uses for this format). -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: why is my ESP filesystem getting mounted to /efi/???
On Wed, Oct 4, 2023, at 9:27 PM, Felix Miata wrote: > # inxi -S > System: > Host: ab560 Kernel: 6.4.16-200.fc38.x86_64 arch: x86_64 bits: 64 > Console: pty pts/1 Distro: Fedora release 39 (Thirty Nine) > # rpm -qa | grep grub > # grep -w /efi /proc/mounts > systemd-1 /efi autofs > rw,relatime,fd=52,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=24799 > > 0 0 > /dev/nvme0n1p1 /efi vfat If there isn't an /etc/fstab entry for the ESP, then systemd-auto-generator detects it's an ESP and will mount it on either /boot or /efi on demand (and unmount it after the timeout). If /boot is used in fstab, then /efi is used for the ESP. I'm pretty sure /efi doesn't exist unless you've (at one time or other) configured sd-boot instead of grub. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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: is cockpit able to handle btrfs mirror's ?
On Fri, Mar 10, 2023, at 1:57 PM, old sixpack13 wrote: > more to read: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/MNAGV2XFQOLXQAXGP2CBHOQRGVYDXD2O/ This is expected behavior right now (certainly not expected by a reasonable user) from a development perspective. There's a similar effect with multiple device Btrfs in KDE and GNOME, so it's not a Cockpit issue. https://github.com/storaged-project/udisks/issues/802 -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Boot issue, probably with grub and maybe mdraid
On Wed, Jan 18, 2023, at 1:18 PM, Bruno Wolff III wrote: > On Tue, Jan 17, 2023 at 18:37:20 -0600, > Bruno Wolff III wrote: >>Today one of three machines failed to boot 6.2.0-0.rc4. The machine >>that failed had not been rebooted in a week and now won't boot any >>kernel and it appears grub is aborting with a pointer out of range >>error. All three machines use ext4 and luks, but only the failing >>machine uses mdraid. I haven't recovered the failing machine yet, but >>plan to downgrade grub tomorrow and hope that confirms a grub bug by >>allowing it to boot. If so, I'll file a bug report. > > Running grub2-install in a live image fixed this. Is the system firmware BIOS or UEFI? Either way it's kinda confusing... BIOS GRUB does not update the embedded core.img (in the MBR gap or GPT BIOS BOOT partition), so when the RPM version changes, the embedded GRUB doesn't change, nor do any of the modules in /boot/grub2. So a grub bug trigging boot failure on BIOS is ... not expected. UEFI GRUB does update the grubx64.efi OSLoader found on the EFI System partition. So a grub bug could trigger boot failure here. But I'm surprised grub2-install even executes, due to well known issues making it not recommended as the resulting EFI file ends up having rather different behaviors than the EFI file produced in Fedora infra and included in the GRUB RPM. So either way it's kind of a weird result... I will speculate -> if UEFI, problem could be /boot/grub2 contained some older version of modules that your specific use case requires (the typical case in Fedora, modules aren't installed in either /usr or the EFI system partition on UEFI systems - everything needed is baked into the pre-built grubx64.efi OSLoader). Upon updating GRUB RPM, a new grubx64.efi was installed, but did not update the modules in /boot/grub2, this could cause a problem that would be resolved by grub2-install because if that command does execute, it results in version parity for grubx64.efi and the modules in /boot/grub2. But again, on UEFI grub2-install really should not be used. It's not a great situation but there is no agreement right now between distros using Secure Boot and upstream GRUB exactly how to handle grub-install any differently than it is right now. I pretty much see two options. If you want to use Fedora's grub package, you should "reset" it by following these instructions: https://fedoraproject.org/wiki/GRUB_2#Instructions_for_UEFI-based_systems If you have a special use case for GRUB that Fedora's doesn't meet: (a) I'd file a RFE bug in RHBZ and explain that use case, so the bootloader team is at least aware of it. And (b) I'd build GRUB from upstream source, and then you can use grub-install as expected. (It won't work out of the box with Secure Boot enabled and Fedora's shim, but I assume you're not using Secure Boot or else grub2-install wouldn't have fixed the problem.) But after writing all that, maybe UEFI doesn't apply to your use case :D >I'm not sure if this > is > a bug or if people are expected to do this themselves (before > rebooting) On BIOS, yes, it's expected to require manual user intervention to update the embedded GRUB binary and its modules found on the /boot volume. > because there are issues trying to automate this for legacy systems. It > might be that the scripts to do updates don't pull the correct devices > when /boot is on raid. It is very annoying though when this happens. I don't know if https://github.com/coreos/bootupd is doing this automatically on BIOS firmware systems now or is planning on doing it? At one time they were. I think the thought process from this point forward is focusing on UEFI Secure Boot workflows rather than inherently insecurable BIOS scenarios, and that the ship has just sailed. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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: Adding file swap on btrfs
FWIW there are some fixes and enhancements coming in btrfs-progs 6.1, now in koji for Rawhide, including making it easier to get info about hibernation file offset in a swapfile. I haven't messed with the new subcommand, but I personally prefer putting swapfiles in their own subvolume so that I can still snapshot the root subvolume. Snapshotting a subvolume containing a swapfile will render the swapfile invalid for use (or maybe the snapshot fails, not sure, haven't tried recently). The way I do this is mount the top-level of the file system (just do a normal mount without any options), and inside you'll see what appears to be two directories: root and home. Those are the subvolumes the installer creates by default. Create a new subvolume in here and add it to fstab such that: UUID=$fsuuid /var/swap btrfs noatime,subvol=swap 0 0 I use chattr +C on this swap subvolume, that way any new files created inside will inherit. This is something the new subcommand will do for you. An additional entry in fstab: /var/swap/swapfile1 none swap defaults 0 0 You can certainly make a nested /var/swap thereby avoiding the need to create the earlier fstab entry. But note that snapshots still don't have this nested subvolume in them, so if you do a rollback it also won't have the nested swap subvolume or file - thus you boot probably hangs because the fstab is looking for this swapfile to activate and never finds it. So I just do it the way I describe, that way I can more or less forget about it. But an alternative to that, if you really prefer nested, is s/defaults/nofail/ for the swapfile entry and now a missing swap won't cause boot to fail *but* you also may one day forget all this and come to realize that there's no swap activated because you once did a rollback way back when... :D -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@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: [systemd-devel] default journal retention policy
On Thu, Dec 22, 2022, at 11:00 AM, Lennart Poettering wrote: > On Do, 22.12.22 10:56, Chris Murphy (li...@colorremedies.com) wrote: >> Still another idea, we could add a new setting MinRetentionSec=90day >> which would translate into "not less than 90 days" and would only >> delete journal files once all the entries in a journal file are at >> least 90 days old. > > Well, that naming would suggest it would override the size > constraints, and it shouldn't. But yeah, ignoring the choice of name I > think it would make sense to add that. Add an RFE. Yeah I'm not sure what to call it. LessRetentionSec or PrefRetentionSec add jargon, but maybe that's adequately dealt with by updating the journald.conf man page? -- Chris Murphy
[systemd-devel] default journal retention policy
Hi, Fedora Workstation working group is considering reducing the journal retention policy from upstream default. This is the tracking issue https://pagure.io/fedora-workstation/issue/213 This is the Fedora development list discussion thread https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/NDO5S2KUUDO5G6JLKZGQNFBXOW5KHPR5/#XATT3XYFV2UALPTJTL5RSQD3D4IVNSVO As Lennart mentions in that devel thread, it's preferred that the change be upstreamable, and the Fedora Workstation working group agrees. https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/XATT3XYFV2UALPTJTL5RSQD3D4IVNSVO/ The consensus of the discussion is that there should be less retention. The range of retention varies quite a bit, but I think 3-6 months is OK. In practice, most configurations eventually up with 4G of journals, since that's the cap. This typically is over a year of journals, but of course it really depends on additional configuration, e.g. in my case I do a lot of debugging, so I'm often enabling debug logging, therefore 4G worth of journal files happens pretty quick, maybe 3 months. As I understand it, rsyslog has a two week retention policy by default. journald supports quite a lot of knobs related to journal total size, free space, file sizes, and rentention time. My favorite simple idea of the moment is to set a default MaxRetentionSec=100day which translates to "probably not less than 90 days, but not more than 100 days" of retention. The policy looks at entry age to determine if the retention threshold is met, but the garbage collection affects journal files. So if a single entry in a file reaches 100 days, the whole file is deleted, which could plausibly be a week or two of entries. Still another idea, we could add a new setting MinRetentionSec=90day which would translate into "not less than 90 days" and would only delete journal files once all the entries in a journal file are at least 90 days old. By leaving all the other settings alone, the 4G cap (or if less, the 10% of file system size rule) still applies. So in no case would any use case end up using more space for logs. Any thoughts? -- Chris Murphy
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: Unexpected system freeze
On Wed, Nov 23, 2022, at 12:00 AM, George R Goffe via test wrote: > Howdy, > > System is FC38: > > Current kernel is: kernel-6.1.0-0.rc5.20221118git84368d882b96.43.fc38.x86_64 > > I just experienced an unexpected system freeze about an hour or so ago. > /var/log/messages contains oom killer messages. Are "we" still having > oom problems? Is there a docs location that can provide oom killer > information? Is there a system or process dump hiding somewhere on this > system? journalctl is the best way to find out what's going on, we need to see the systemd-oomd messages to see if there's a problem in the logic. It could also be kernel related. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Can't create msdos partition table without advanced partitioning?
On Sat, Nov 19, 2022, at 9:18 PM, Tom Horsley wrote: > Installing fedora 37 from workstation live iso to a virtual machine. > > I couldn't find any way to partition a blank disk with a msdos > partition table without using the advanced manual partitioning. > Did I miss something, or is that the way it works now? Yeah it's in the change set but somehow is missing from the release notes. I've let docs folks know. https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault You can force MBR by using a boot parameter at boot time: inst.mbr I only advise doing this if there's a problem (firmware confusion) with GPT. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@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: How do I rebuild Grub/Boot/initramfs from a Live USB?
On Sat, Oct 29, 2022, at 1:18 AM, Tim via users wrote: > Here's some more advice you probably won't like: Multi-booting (any > computer, any OS) can be a pain, and it may be best to only attempt > that after you've learnt how a system works. Your safest approach to > learning a new system is to get a second hard drive, unplug your first > one, install onto a fresh drive in isolation, and learn how the system > works. Multiboot is probably fragile. Or at least it is inclined toward chaos, in that we cannot account for everything. Fedora only tests and blocks releases against Windows and macOS existing first, and Fedora second. As there's no manifestation of support beyond community support, is anything supported? We more or less say things that we are willing to block release on are supported, as in they have to work at the time a version is released. But there's lots of buts. And one of those buts is, if you're setting up a system in a way we aren't testing, we certainly aren't going to block release on such edge cases that affect few users. Triboot is definitely one of those. But case in point, lets say you have a completely clean system. Install Fedora copy A, and then you want to do a dual boot of two Fedoras. Say, Fedora Workstation and KDE. Or Fedora 35 and 36. Dual boot Fedoras. Supported? Nope. We have no release criterion for that. Only bugs that happen independent of that configuration would be blockers, not bugs that only manifest as part of a dual boot Fedora installation. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How do I rebuild Grub/Boot/initramfs from a Live USB?
On Sat, Oct 29, 2022, at 12:54 AM, Slade Watkins via users wrote: > On 10/28/22 4:27 PM, Jake D wrote: >> I really can't believe that these Linux systems are so fragile and the ONLY >> option is to start over > > Wanted to hop in here real fast and say: > Pop!_OS, which is my primary distro (with Fedora being my secondary), > has the option to go into recovery (has a small partition just for > up-to-date recovery media) and reinstall your OS without losing any > personal files. > > AFAIK, it's one of the only distributions that has something like it. Fedora doesn't have a recovery partition. But there is a (sort of hidden, or at least non-obvious) way of doing a custom installation while preserving home. There isn't detailed documentation for it. It's just a test case. https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home This is more official than the draft dual boot one I posted previously, in that I try to keep this one up to date. But it's just a test case, intended for a test setup to make sure installer functionality isn't lost. It's not really intended as installation advise. It could be adapted into a Quick Doc for that purpose though. But my understanding of the original poster's issue is that he now has a bunch of system level customizations. Not so much user level customizations. Therefore the reuse home directory method wouldn't help much. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How do I rebuild Grub/Boot/initramfs from a Live USB?
On Fri, Oct 28, 2022, at 7:09 PM, Jake D wrote: > No, it's not a troll. > > Thank-you for your otherwise completely irrelevant , unsolicited and > entirely unhelpful opinion piece. I'm sorry for not realising Windows > upsets you so much and is therefore inferior, and for daring to ask if > Linux has similar recovery functionality, after being told the only > answer is to completely start from scratch. Clearly, I should have > realised immediately that this means it's the more resilient system. > > I will immediately stop using my working windows partition and stare at > my non booting "grub> prompt instead. Also can you advise which bridge > you wish for me to jump off as punishment for my question? Multiboot systems are inherently complex. Like, you really have had a train derailment. And you're asking for help with that as if there's a button you can push to fix that. There's no button for train derailments. It's a customized recovery every time that requires esoteric knowledge. Everything about it is manual. Are trains fragile? I'm not sure that's the best description but yeah once they start going off the rails it's a catastrophic system. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How do I rebuild Grub/Boot/initramfs from a Live USB?
On Fri, Oct 28, 2022, at 5:53 PM, Jonathan Billings wrote: > It sounds like you only wiped the /boot partition, which should be > fairly easy to get back. But /boot/grub2 and /boot/loader/entries are on /boot so the real grub.cfg and BLS snippets are gone, which are trivial to create if you're an expert. If you're not, it might as well be ouji board antics. There's so many tiny things like this that the installer does, that it sorta makes it a grand experiment in "what the hell did we miss" doing the fix manually. We can just (a) reformat the boot partition, get its new fsUUID put into (b) /boot/efi/EFI/fedora/grub.cfg and (c) /etc/fstab on the existing root (d) mount everything in the proper order so we can do a chroot (e) run grub2.mkconfig (f) do a dnf reinstall kernel so that we for sure have a vmlinuz on /boot and modules of the same version in /usr and BLS snippet But uhh what am I missing? Like, I'd just reboot at this point and wait for the failure to give me a hint what I'm missing. But in this case, the user gets stuck in a way they maybe can't get out of or describe and then we're worse off having wasted the time. >Reinstalling the kernel and grub2 packages > will get you the packaged bits, and running dracut like you ran should > get you the initrd, although only after you’ve got the kernel. reinstalling the kernel will run dracut, we don't need to run it again > > After everything is reinstalled, then run the grub2-mkconfig command to > create the grub config file in your new /boot partition. > > Just make sure you do everything from the chroot in an EFI booted > rescue environment, either on a livecd or booting the NetBoot iso with > the rescue option. So unfortunately Live images don't have Anaconda rescue environments. And while the netinstaller does, it will fail to find /boot by UUID in the /etc/fstab because it doesn't exist anymore so the assembly and chroot will fail. The manual method means high likelihood of missing a step or getting it in the wrong order. Or asking someone to test all the steps in a VM. Hence why reinstallation is easier. If it's Btrfs, we can keep the old root and swap roots. We need to fix two things (a) change the rootflags=subvol argument in the BLS snippets, so they mount root subvolume instead of root00 subvolume (b) update the /boot fsUUID in /etc/fstab Right? Is that it? I think that's it. OH OK there is one more problem. Probably the kernel in the new /boot is old and that version's modules don't exist anymore in the (old) root subvolume's /usr and therefore we can't boot. So yeah that has to get fixed somehow... If the Btrfs volume is mounted normally (without any options) to /mnt we can copy the old kernel modules from the new root to the old root and now the old root will boot. cp -r /mnt/root00/usr/lib/modules/$theonlydirpresent /mnt/root/usr/lib/modules/ Right? That will return fairly instantly because it'll be a reflink copy, so it might lead some folks to think it didn't work because it was too fast :P What should be true is in the first path with root00, if you hit TAB after the last /, it should autocomplete the only directory present which is the shipping kernel for Fedora 36. Or hey I have that kernel in a btrfs snapshot I created after an F36 clean install. It should be 5.17.5-300.fc36.x86_64 so the actual command ought to be cp -r /mnt/root00/usr/lib/modules/5.17.5-300.fc36.x86_64 /mnt/root/usr/lib/modules/ OK I think that's everything? -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How do I rebuild Grub/Boot/initramfs from a Live USB?
On Fri, Oct 28, 2022, at 4:27 PM, Jake D wrote: >> My opinion: This is probably easier in a live discussion on IRC or Matrix. >> There's >> just too much back and forth required. > > Are these different forums? I just googled 'Fedora matrix 'and I'm > getting a lot of very varied hits https://chat.fedoraproject.org IRC and Matrix are chat protocols. There's a bridge in place so that, in effect, you're in the same channel whether you join #fedora on libera.chat (IRC) or #fedora on fedora.im (Matrix). You can get a native matrix account via element.io or you can get a Fedora account and use that to connect to Fedora's matrix home server. Why you pick one vs another depends on how big your matrix presence is, I guess. You're finding multiple options because of multiple eras: IRC then matrix.org then Fedora got its own matrix home servers. But you can access them all with any method due to the behind the scenes bridging. I personally use cmurf:fedora.im (matrix using the Fedora matrix home servers) >> But the absolute easiest thing to do is mount the encrypted btrfs, make a >> backup of the >> home directory, and then clean install followed by restoring the home >> directory files from >> the backup. > > I understand what you're saying but as I mentioned in a previous > comment, I have 4 weeks of setup already in place on this system. > Theres not really any files on there worth covering but more dayd and > days of fiddling to get things working, much of which im sturggling to > remember, > > Reinstall is essentially a complete writeoff. THeres no way I'll have > it setup up again by Monday, I'll have to withdraw from the class and > thats a large course fee forfeiture I'd rather avoid. OK, there is another option which is a clean install along side the existing installation, but following this clean install you'll abandon the new root and switch to the old root that has all your customizations. Basically you'll be doing a clean install just to get all the nuggets in /boot and /boot/efi in the proper shape. Some post install surgery will still necessary though... Is it more complicated to do a modified dual boot where we have two roots and then switch the roots and make the necessary changes to /etc/fstab and BLS snippets in /boot/loader/entries? Or just manually create every file we need? Uhhh I think it's probably easier to do the side by side installation, preserving the existing root. And then abandon the new root, while keeping the replacement /boot/efi/EFI/fedora and /boot But that's a guess. So this is a draft I helped write for having dual boot Fedoras, i.e. two roots. https://fedoraproject.org/wiki/User:Sumantrom/Draft/dualboot_f33_btrfs That needs a number of modifications for your situation though. So I think before going down that road we should discuss whether that's really the best option or not. > I really can't believe that these Linux systems are so fragile and the > ONLY option is to start over, is there nothing like Resotre Points in > windows? Not automatically and only for the root (/) and home (/home). You've toasted the /boot volume which is functionally like Windows' system volume that it boots from initially, if you wipe that, you'd be totally screwed on Windows too. And also these days on Windows you don't get automatic restore points either, you'd have to have done it before the mistake. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How do I rebuild Grub/Boot/initramfs from a Live USB?
On Fri, Oct 28, 2022, at 4:21 PM, Jake D wrote: >> HyperKitty is a web front-end for what is really a mailing list. Most >> people here access the list via a standard mailer rather than the web >> interface, which (IMHO) gives better results, including proper quoting. > > I 'm not really sure what a "standard mailer" is or what you mean by > 'mailing list', and honestly I'm a bit more focused on getting the > computer to boot at all by monday. This was one of the resources on > the course material and I'm asking everywhere I can, I'm a bit frantic > frankly. Panic is one of the best known paths to data loss. Before making any further changes, I advise a backup of important user data. Do not attempt repair or reinstallation until there's at least two independent copies of your important data. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How do I rebuild Grub/Boot/initramfs from a Live USB?
On Fri, Oct 28, 2022, at 2:31 PM, Jake D wrote: > Hello all. > > I need some help. My opinion: This is probably easier in a live discussion on IRC or Matrix. There's just too much back and forth required. But the absolute easiest thing to do is mount the encrypted btrfs, make a backup of the home directory, and then clean install followed by restoring the home directory files from the backup. Otherwise you and at just one other person have to have a fairly intense conversation about very low level esoterics. Boot is very distro specific. There's maybe two or three dozen steps to repair this setup. They all have to be exactly correct or it won't work. Much of this logic is in the installer. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@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: gnome-shell crash when resuming/waking up from idle
On Wed, Sep 21, 2022, at 12:08 AM, Kamil Paral wrote: > Hi folks, > I wonder if I'm the only one who sees an occasional gnome-shell crash on > Fedora 37 when the system is resumed from suspend, or possibly even woken up > from idle (screen turned off)? It happens to me a few times per week, > completely randomly, I can't reproduce it intentionally. I haven't seen any gnome-shell crashes since before branch. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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: Release criteria proposal: require GNOME Shell extension install/remove to work
On Mon, Sep 12, 2022, at 3:35 PM, Adam Williamson wrote: > Hey folks! > > So a bug came up at today's blocker review meeting: > https://bugzilla.redhat.com/show_bug.cgi?id=2106868 > > it takes a minute to parse, but the tl;dr is that right now in Fedora > 37, you can't go to https://extensions.gnome.org and install > extensions. > > We agreed that it doesn't violate any existing release criteria, but to > me, this is actually kind of a significant problem. Anecdotally, I get > the impression that a lot of our Workstation users do use extensions, > and not being able to easily install them on a fresh install would be a > big problem for them, and make us look pretty bad. > > We have a handful of extensions packaged, though I'm not sure how well > they're kept up to date. Aside from those, I don't know of any other > really practical way for regular users to install extensions besides > https://extensions.gnome.org . Is there one? > > Assuming for now that there isn't, I'm gonna propose this as a Final > release criterion to see how people feel about it, to come after > "Default panel functionality": > > # > > === GNOME extensions === > > On Fedora Workstation, it must be possible to install and remove > extensions by visiting https://extensions.gnome.org in the default web > browser, after installing the required browser extension. > > # > > Do folks think this is important enough to block Final release on? > Desktop folks, do you consider it "supportable"? Discussed at the meeting today, and we definitely want this to work, and appreciate the bug report. We expect we'll be able to get it fixed for release. However, there's reluctance to broaden the scope of the criteria because our influence has limits, including the infrastructure aspects of extensions that we can't control (such as the web site itself). So we'd like to see this covered under existing criterion. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Silverblue user mailing list??
On Fri, Sep 9, 2022, at 5:44 AM, Jack Craig wrote: > hi all, > > I've been subscribed to this list for a while and I have never seen any > traffic regarding Silverblue, is there a separate mailing list for > Silverblue?? Pretty sure most of it happens on Discourse. https://discussion.fedoraproject.org/tag/silverblue -- Chris Murphy___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@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: Request for testing: Fedora 37 pre-Beta validation tests
On Mon, Aug 29, 2022, at 8:36 PM, Josh Berkus wrote: > On 8/29/22 17:22, Adam Williamson wrote: >> It would be really great if we can get the validation tests run now so >> we can find any remaining blocker bugs in good time to get them fixed. >> Right now the blocker list looks short, but there are definitely some >> tests that have not been run. > > Last I checked, flatpak was still broken. Will retest this week. What's broken with flatpak? I've been using several flatpaks OK since 'dnf system-upgrade' a week ago. -- Chris Murphy ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-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/cloud@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: /etc/grub2.cfg Flagged a Potenially missing
On Sun, Aug 28, 2022, at 7:38 PM, Stephen Morris wrote: > Hi, > /etc/extlinux.conf is flagged as missing flagged as missing by what? This file is normally not created on any Fedora variant I'm aware of. It could be a legacy file. > /etc/grub2.cfg and /etc/grub2-efi.cfg both of which point to the > same file also display the same way as /etc/extlinux.conf, but in this > case the file pointed to actually does exist, and is linking to > /boot/grub2/grub.cfg, which I regularly write to with sudo and > grub2-mkconfig, There is no reason to regularly replace grub.cfg, it's a static file these days. The files that change are drop-in files found in /boot/loader/entries and can be modified with grubby per examples at: https://fedoraproject.org/wiki/GRUB_2#Changing_kernel_command-line_parameters_with_grubby -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: After latest updates to F37 from updates testing, tab completion goes missing, wallpapoz stops working
There isn't enough information available to understand the problem. Please provide the complete /etc/fstab, blkid, and journalctl -b for a failing boot while booting with parameters: systemd.log_level=debug rd.debug udev.log-priority=debug That will sufficiently slow down the boot that if the problem is related to a race condition, the problem may not happen. If that's the case you'll have to do separate boots with one of the above parameters at a time to see which debug method exposes the cause. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@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
Re: reversible dual-boot test station
I've added a section how to modify /etc/kernel/cmdline in the snapshot before rebooting. https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: reversible dual-boot test station
On Tue, Aug 23, 2022, at 10:54 AM, Steven A. Falco wrote: > Under "Setup" it says: > > rm /etc/kernel/cmdline /etc/kernel/cmdline > > Shouldn't it just be: > > rm /etc/kernel/cmdline Yep. Fixed. Thanks! However, due to recent changes in grub currently in updates-testing for both 36 and 37, I'm no longer confident in this write up and have to retest. That /etc/kernel/cmdline can contain stale information has broken this use case at the moment, so I need to see if there's a better work around than deleting this file. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: reversible dual-boot test station
On Sun, Aug 21, 2022, at 2:31 PM, Chris Murphy wrote: > > https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation I found a small problem, fixed in the latest version. Gory details: If you've ever used grubby, an /etc/kernel/cmdline file is created that contains the current subvolume name, e.g. rootflags=subvol=root36. But then when you snapshot it and boot e.g. root37, when performing the upgrade the existence of this file causes /etc/grub.d/10_linux to favor that old root. So the new BLS snippet for Fedora 37 contains rootflags=subvol=root36 instead of root37. The file can safely be removed or renamed so I added that to the setup section instructions. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: mount fails for btrfs filesystem, need help please.
On Mon, Aug 22, 2022, at 7:41 PM, George R Goffe via test wrote: > Howdy, > > Thanks to all who responded... > > Chris, > > I tried the superblock mount but that still fails. Then I tried the > rescue=all mount. That succeeded... I have copied all the files I need. > From what I read, corrupted files get copied too... and there were some > which I removed from the copies. It does disable data checksum verification, so it's possible. It's a valid option to use the individual option method, leaving data checksumming in place, e.g. mount -o ro,rescue=usebackuproot,nologreplay,ibadroots in this case it will complain about corrupt file blocks and won't let them be copied out. How this gets handled depends on the application - some applications stop at the first bad file. Others continue reading the rest of the same file, then stop. Still others continue reading all file blocks. > From > "https://lists.fedoraproject.org/archives/search?mlist=users%40lists.fedoraproject.org=parent+transid+verify+failed; > > I found some other commands that you wrote. I presume after unmounting > this problematic filesystem. Is it time to run them? Try "mount -o rescue=usebackuproot" this is also used by rescue=all, but permits rw mount. If it works, the current damaged root tree will be replaced by a good one. > btrfs rescue zero-log > btrfs check --repair --init-extent-tree > btrfs check --repair I don't think any of these are indicated for this problem. Zero log is harmless, but the messages don't indicate a problem related to the tree log. Init extent tree is taking a big chance It might work, it might make things worse. And it'll take a while. I'd just take advantage of the ro rescue mount to get your data out such as it is. And then mkfs time. Wipe it and clean install, restore from backups. It's the more reliable way of getting back to good. But it's useful to look at logs over the last couple days to see if there's prior evidence of problems and what they might be. Because it sounds to me like the hardware has become unreliable in some way. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: mount fails for btrfs filesystem, need help please.
On Mon, Aug 22, 2022, at 11:47 AM, Chris Murphy wrote: > On Mon, Aug 22, 2022, at 11:46 AM, Chris Murphy wrote: > >> After that, you can umount the file system. And mount again with '-o >> rescue=usebackuproot' and hopefully it finds a good backup root, and >> can fix itself. If it gets confused again, it'll go read only to avoid >> making things worse. > > This mount is just a one time thing, assuming it works. You can just > umount, and then reboot normally. Also, generally easier to ask for me (cmurf) on https://matrix.to/#/#fedora:fedoraproject.org to ask about Btrfs questions; or if I'm not around ask on #btrfs:libera.chat -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: mount fails for btrfs filesystem, need help please.
On Mon, Aug 22, 2022, at 11:46 AM, Chris Murphy wrote: > After that, you can umount the file system. And mount again with '-o > rescue=usebackuproot' and hopefully it finds a good backup root, and > can fix itself. If it gets confused again, it'll go read only to avoid > making things worse. This mount is just a one time thing, assuming it works. You can just umount, and then reboot normally. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
