[systemd-devel] sd-boot kickstart
Hello, I watched the video and presentation https://cfp.all-systems-go.io/media/sdboot-asg2019.pdf I could not agree more! Anaconda/Kickstart install grub as the bootloader. Is there some hidden option to use sd-boot instead or is it necessary to install sd-boot manually after the OS is deployed? Thanks in advance. Regards, Damian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user slice changes for uid ranges
hello mantas, jeremy, all, wrt the pam script magic, i'm not a big fan, esp because it is optional. i'd rather have those users not login than that they don't have the constraints. (but obvioulsy, i really don't want to lock myself out, so i totally see what you need the optional keyword) wrt the generators, i'll have a look how those really work and what i could do with them. i like the idea that the user slice settings are only generated when needed (and maybe even cleaned upwhen there are too many old ones to avoid performance issues) searching for info on generators and user slices, i stumbled on https://github.com/systemd/systemd/issues/2556 where this was also mentioned. unfortunaltey, no examples, so if someone can share some examples, that would be great ! anyway, thanks a lot, stijn On 9/29/19 4:07 PM, Jérémy ROSEN wrote: > I don't have a complete solutions, but here are a couple of tools that you > might be able to assemble into something that work > * dropins, you could do a dropin for every existing UID that sets the > Slice= field > * generators : could be used to generate those dropins > * also note that if a unit is named a-b-c.service, systemd will look for > dropins named a-b-.service and a-.service... there might be something to do > with that, but I havn't given it much thought > > Le ven. 27 sept. 2019 à 18:28, Mantas Mikulėnas a > écrit : > >> On Fri, Sep 27, 2019 at 5:03 PM Stijn De Weirdt >> wrote: >> >>> hi all, >>> >>> i'm looking for an "easy" way to set resource limits on a group of users. >>> >>> we are lucky enough that this group of users is within a (although >>> large) high enough range, so a range of uids is ok for us. >>> >>> generating a user-.slice file for every user (or symlink them or >>> whatever) looks a bit cumbersome, and probably not really performance >>> friendly if the range is in eg 100k (possible) uids. >>> >>> e.g. if this range was 100k-200k, i was more looking for a way to do >>> e.g. user-1X.slice or user-10:20.slice >>> >> >> As far as I know there isn't a good systemd-native method for this, but >> you can dynamically set slice parameters during PAM processing, as in this >> blog post: >> https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu1804SystemdUserLimits >> >> -- >> Mantas Mikulėnas >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user slice changes for uid ranges
On Tue, Oct 1, 2019 at 11:19 AM Stijn De Weirdt wrote: > hello mantas, jeremy, all, > > > wrt the pam script magic, i'm not a big fan, esp because it is optional. > i'd rather have those users not login than that they don't have the > constraints. (but obvioulsy, i really don't want to lock myself out, so > i totally see what you need the optional keyword) > It's as optional as you make it. If the script exits with non-0, pam_exec returns PAM_SYSTEM_ERR and you can treat this as a fatal error. To avoid locking yourself out, either always make it exit 0 for root, or "session [success=1 default=ignore] pam_succeed_if.so user ingroup wheel", etc. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Sun, Sep 29, 2019, at 6:08 AM, Lennart Poettering wrote: > i.e maybe write down a spec, that declares how to store settings > shared between host OS, boot loader and early-boot kernel environment > on systems that have no EFI NVRAM, and then we can make use of > that. i.e. come up with semantics inspired by the boot loader spec for > finding the boot partition to use, then define a couple of files in > there for these params. I like the idea in general but it would mean there's no mechanism to "roll back" to a previous configuration by default, which is a quite important part of OSTree (and other similar systems). (Relatedly this is also why ostree extends the BLS spec with an atomically-swappable /boot/loader symlink, though I want to get away from that eventually) That said, maybe one thing we want regardless is a "safe mode" boot that skips any OS customization and will get one booted enough to be able to fix/retry for configuration like this. BTW related to EFI - as you know AWS doesn't support it, and we're making a general purpose OS. Fedora isn't just about desktops, and we need to be careful about doing anything in the OS that diverges from the server side. (That said I only recently discovered that GCP supports it as well as vTPMs, working on "blessing" our Fedora CoreOS images to note they support it https://github.com/coreos/mantle/pull/1060 ) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-boot kickstart
On Tue, Oct 1, 2019 at 1:05 AM Damian Ivanov wrote: > > Hello, > > I watched the video and presentation > https://cfp.all-systems-go.io/media/sdboot-asg2019.pdf > I could not agree more! Anaconda/Kickstart install grub as the > bootloader. Is there some hidden option to use sd-boot instead or is > it necessary to install sd-boot manually after the OS is deployed? I only see extlinux as an alternative to grub: https://pykickstart.readthedocs.io/en/latest/ I think it's a question for Anaconda developers how to support sd-boot: https://www.redhat.com/mailman/listinfo/anaconda-devel-list -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-boot kickstart
Thanks, I'll check it out. On Wed, Oct 2, 2019 at 9:06 AM Chris Murphy wrote: > > On Tue, Oct 1, 2019 at 1:05 AM Damian Ivanov wrote: > > > > Hello, > > > > I watched the video and presentation > > https://cfp.all-systems-go.io/media/sdboot-asg2019.pdf > > I could not agree more! Anaconda/Kickstart install grub as the > > bootloader. Is there some hidden option to use sd-boot instead or is > > it necessary to install sd-boot manually after the OS is deployed? > > I only see extlinux as an alternative to grub: > https://pykickstart.readthedocs.io/en/latest/ > > I think it's a question for Anaconda developers how to support sd-boot: > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > > > > -- > Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-analyze shows long firmware time with sd-boot
Hi, systemd-243-2.gitfab6f01.fc31.x86_64 systemd-analyze reports very high firmware times, seemingly related to uptime since last cold boot. That is, if I poweroff then boot, the time for firmware seems reasonable; whereas reboots appear to show cumulative time for only the firmware value. This is in a qemu-kvm VM, using edk2-ovmf-20190501stable-4.fc31.noarch reboot (warm boot) $ systemd-analyze Startup finished in 8min 2.506s (firmware) + 12ms (loader) + 1.414s (kernel) + 1.383s (initrd) + 8.962s (userspace) = 8min 14.278s graphical.target reached after 8.946s in userspace [chris@localhost-live ~]$ # systemd-analyze Startup finished in 18min 13.786s (firmware) + 11ms (loader) + 1.420s (kernel) + 1.361s (initrd) + 8.855s (userspace) = 18min 25.434s graphical.target reached after 8.840s in userspace [root@localhost-live ~]# # systemd-analyze Startup finished in 20min 22.976s (firmware) + 11ms (loader) + 1.410s (kernel) + 1.360s (initrd) + 8.801s (userspace) = 20min 34.560s graphical.target reached after 8.790s in userspace [root@localhost-live ~]# # systemd-analyze Startup finished in 51min 8.018s (firmware) + 12ms (loader) + 1.415s (kernel) + 1.370s (initrd) + 8.836s (userspace) = 51min 19.653s graphical.target reached after 8.821s in userspace [root@localhost-live ~]# poweroff+boot (cold boot) # systemd-analyze Startup finished in 2.402s (firmware) + 15ms (loader) + 1.498s (kernel) + 1.358s (initrd) + 8.723s (userspace) = 13.998s graphical.target reached after 8.709s in userspace [root@localhost-live ~]# -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-analyze shows long firmware time with sd-boot
On Wed, Oct 2, 2019 at 9:26 AM Chris Murphy wrote: > Hi, > > systemd-243-2.gitfab6f01.fc31.x86_64 > > systemd-analyze reports very high firmware times, seemingly related to > uptime since last cold boot. That is, if I poweroff then boot, the > time for firmware seems reasonable; whereas reboots appear to show > cumulative time for only the firmware value. > > This is in a qemu-kvm VM, using edk2-ovmf-20190501stable-4.fc31.noarch > > systemd-analyze calculates the time delta based on the LoaderTimeInitUSec EFI variable, which is stored by systemd-boot during initialization. systemd-boot reads the time by calling 'rdtsc' and dividing it by estimated ticks/ms. It assumes that the TSC starts at 0, so "firmware time" is just (current_tsc - 0). (The code is at: https://github.com/systemd/systemd/blob/master/src/boot/efi/util.c#L15-L60) Based on this mailing list thread, it looks like qemu-kvm did not reset the TSC on soft reboot in the past, and I'm not sure if the patches to make it do so were actually applied or not: https://qemu-devel.nongnu.narkive.com/jbnsv2H8/patch-kvm-clear-guest-tsc-on-reset -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
