Hi, Thanks for the thorough reply, Hans! One question inline On Tue, 2021-01-05 at 12:31 +0100, Hans de Goede wrote: > Hi, > > On 12/30/20 11:52 PM, Neal Gompa wrote: > > On Wed, Dec 30, 2020 at 5:48 PM Marius Schwarz < > > fedoradev@xxxxxxxxxxxx> wrote: > > > > > > Am 30.12.20 um 22:14 schrieb Michel Alexandre Salim: > > > > - a separate partition for storing GRUB config, no matter what > > > > architecture, is probably the ideal solution > > > Not always. In VMs you would reduce the amount of partitions to > > > ease up > > > things. The main problem with Vms is, that you have LTS based > > > linux > > > distros on the host systems which can't mount the vm guest, if > > > the guest > > > uses newer filesystems. If you then use BTRFS on the boot > > > partition or > > > store grub configs in partionheaders, you can't access those from > > > the > > > guest making it impossible to change the bootconfig, if it fails > > > for > > > some stupid reasons like older pygrub ( xen ) boot loaders, > > > which can't > > > handle the kernel images compression/format. Happend last with > > > Xenserver > > > and Kernel 5.9. > > > > > > For this, i.E. me, choose to store the boot config on / so we > > > have just > > > one partition with ext4, which can easily mounted on the host, as > > > ext4 > > > can be handled by the older LTS systems on the host. > > > > > > As Fedora is a good server os, if the ui parts have been removed > > > ;), it > > > should be taken into any consideration, that it may not be a bare > > > metal > > > installation you make plans for. It still needs to run in good > > > old > > > stable setups ;) > > > > > > > The issues Michel is referring to do not apply to Fedora Server > > using > > Btrfs, because outside of Workstation, currently no variant of > > Fedora > > has cross-layer integration with the bootloader. > > I do not think that that is entirely true, well it depends on if > anaconda > also sets the menu_auto_hide=1 variable for other variants. The grub > hidden > boot menu stuff: > https://fedoraproject.org/wiki/Changes/HiddenGrubMenu > https://hansdegoede.livejournal.com/19081.html > > Should mostly work, assuming they at least use a systemd user- > session. > > The boot menu being hidden or not depends on the boot_success grubenv > variable, which gets set by a systemd-timer in the systemd-user > session > of non-system (aka normal) users if the user-session has lasted at > least > 2 minutes. > `boot_success` needs to be cleared per boot though, right? So that if the user session timer doesn't set it back (so we assume the boot failed), the next boot shows the GRUB menu. Where does this happen? I'm under the impression this happened in the GRUB execution environment, which is problematic if that environment is on a filesystem GRUB can't write to. Apologies for seeing this late, it would be nice to get this information going into tomorrow's FESCo meeting since Javier's proposal has a -1 that is partly due to concern over breaking the hidden menu functionality -- https://pagure.io/fesco/issue/2543 > And since Fedora 33, the integration to force the boot-menu to be > shown > is using the standard systemd DBUS APIs for this, so that e.g. : > > systemctl reboot -boot-loader-menu=60 > > To cause the menu to show next boot with a timeout of 60 seconds > works now, > except for a selinux bug which will hopefully be resolved soon: > https://bugzilla.redhat.com/show_bug.cgi?id=1856399 > > So other desktop-environments / spins / variants could also integrate > more closely with the hidden-boot-menu stuff, which is a pre- > requisite > for getting a fully flicker free boot. > Flagging Neal here for KDE > I would be happy to answer any questions people may have about this, > but > I'm afraid I do not have the time to actively help with this (outside > of > answering questions). > No worries! > As for writing docs, the FAQ on my blog answers all end-user > questions > that I know about. But yes we could use some more docs to help other > variants integrate better with this. If someone wants to start a wiki > page based on the Change + FAQ pages and then extend that as closer > integration is added to other variants, go for it. Feel free to take > all the text I wrote on this and put it under any FOSS license of > your > choice. Yeah, I can start a wiki and copy over the content of the FAQ, it might make sense to have something we can refer to that can be easily updated. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@xxxxxxxxxxxxxxx chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
