[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: "enabling zram.service on LiveOS boots"



On Wed, 2019-06-19 at 13:21 -0600, Chris Murphy wrote:
> On Wed, Jun 19, 2019 at 10:33 AM Brian C. Lane <bcl redhat com> wrote:
> > On Wed, Jun 19, 2019 at 01:24:27PM +0200, jkonecny redhat com wrote:
> > > Hi Chris,
> > > 
> > > There has to be change in the live media creation. Anaconda don't have
> > > power on what is booted on Live DVD.
> > > 
> > > I think the Fedora kickstart used to create the DVD Live image is the
> > > change target here. That kickstart should enable the service so it will
> > > be auto-started during the Live DVD boot. However, if we do that then
> > > the service will be also enabled on the installed system which is
> > > probably not what we wanted to do...
> > 
> > Correct. The place to enable it would be in the livesys script that the
> > %post section writes. But I'm not sure if that's too late in the boot
> > process for it to be useful. As long as it is just started, not enabled,
> > from the script it should only run when booting the live iso and not the
> > installed system.
> 
> Or can Anaconda just 'systemctl start zram.service' when it's
> launched, whether on Live or netinstall?
> 
> The problems I'm seeing only in low memory situations, doesn't arise
> until Anaconda launches. So it's fine if 'systemctl start
> zram.service' happens late.
That's actually a good point & certainly the easiest thing to do. 

Because if we start zram really early at boot time, before the desktop environment starts
and then make sure to disable it on the installed system, I can imagine the installed
system failing to boot if it needed zram to even survive the DE launching.

On the other hand if the DE managed to start without zram, it should be able to start 
without it even after installation.

> 
> Looks like the change would go in
> https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-base.ks
> 
> It contains this section:
>    110    # enable swaps unless requested otherwise
>    111    swaps=\`blkid -t TYPE=swap -o device\`
>    112    if ! strstr "\`cat /proc/cmdline\`" noswap && [ -n "\$swaps" ] ; then
>    113      for s in \$swaps ; do
>    114        action "Enabling swap partition \$s" swapon \$s
>    115      done
>    116    fi
>    117    if ! strstr "\`cat /proc/cmdline\`" noswap && [ -f
> /run/initramfs/live/\${livedir}/swap.img ] ; then
>    118      action "Enabling swap file" swapon
> /run/initramfs/live/\${livedir}/swap.img
>    119    fi
> 
> Umm, anyone got any opinions on removing that whole thing?
> 
> a) I don't really see the point of using some legacy swap partition
> that the installer has some chance of needing to turn off in order to
> modify partitioning or what have you?
> 
> b) Silently activating a persistent swap is a security leak for LiveOS
> users, unless testing for encryption or setting up /dev/urandom key
> based encryption for it.
Sounds like sound arguments to me & details can be worked out once a PR is opened
for fedora-kickstarts.

> 
> Also, there is a package, zram-0.3-1.fc30.noarch, which is more
> recently developed and intended to be generic use. Any chance of
> deprecating the anaconda zram stuff and depending on this zram package
> instead?
> https://src.fedoraproject.org/rpms/zram/tree/master
I recommend opening a RFE bug in bugzilla so we can track this. When we added zram support
to Anaconda, non of this extra tooling existed yet and it could well be that what we are using
has a modern well maintained generic alternative.

> 
> Last, it looks like the systemd folks want to turn all of this into
> native systemd units, and get rid of the livesys script entirely.
> 
Anything that reduces the insanity of the live image creation kickstarts is a good thing. :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]