Hi Simon,
On 6/27/23 11:00, Simon de Vlieger wrote:
On 6/27/23 10:40, Hans de Goede wrote:
> Ok, so can you provide some instructions for how to make this work ? I guess it would
be something like add the cmdline option + then start some systemd unit ? Can you please
put some instructions for this in the testing section of:
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation (with a note
that this is currently not supported / recommended).
>
>> About the improvements on the Live ISO, that should be a question on Fedora
Workstation SIG. Anaconda team is not in charge of the environment on the Live ISO.
>
> Well you are suggesting a change that is likely going to significantly increase the
amount of memory needed to do a livecd workstation install and as mentioned above pushing
the requirements above 2G would basically block this change since 2G RAM is currently the
advertised minimum RAM requirement for Fedora workstation installs.
>
> So although I realize this is not entirely fair IMHO if you want to push forward with
this feature then you may also be on the hook to look into reducing the memory footprint
elsewhere so that the end result still fits in 2G RAM. I have some experience with
tweaking the livecd to work with less RAM and I'm happy to share my experience in
this, but I do not have time to actually implement needed changes for this.
Hi Hans,
it would indeed involve adding the `inst.webui` and `inst.webui.remote` kernel command
line options and a systemd unit to start the relevant services (I *think* that'd only
be `cockpit.service`).
You likely also want to truncate the `/etc/cockpit/allowed-users` file so you can use
your empty password root login during installation.
This is normally taken care of when anaconda starts the webservice [1].
I've been working on landing live-installer generation in the image builder projects
(there's a separate change request for this). You can follow progress on that here
[2].
When the image builder PR lands the first follow ups will involve customization of the
live-installer. Including kernel options, packages, and systemd service files. This would
allow you to build a lighter version of the live-installer locally to use on the devices
you work with.
I am interested to know which tweaks you perform to have the livecd use less RAM to see
if I can codify those. Could you share your experience?
At the end of this email is a copy & paste of my own notes
of the set of hacks which I use to do a livecd install on
1G RAM x86 tablets.
Low hanging fruit would be evolution and gnome-software + packagekit.
There are 3 ways (IIRC) how the whole set of evolution-daya-server
processes gets started on a GNOME session:
1. Through /etc/xdg/autostart/org.gnome.Evolution-alarm-notify.desktop
for this we would need some way to annotate .desktop files to not
start on a livecd. This could be e.g. a X-GNOME-no-livecd-autostart=yes
on the .desktop + code in GNOME's code to generate systemd user
unit files to honor this.
2. Through a calendar search provider. This can easily be disabled in
the livecd sessions with a drop-in gconf settings file disabling the
search provider. In general many of the gnome-shell search providers
can be quite heavy for low spec machines. I think there might even
already be some code to disable some of them.
3. Stop gnome-shell starting /usr/libexec/gnome-shell-calendar-server,
which does the calendar integration in the clock widget in the top bar.
The main gnome-shell talks to this over a dbus proxy and if it cannot
be started it logs one warning and everything is fine.
Making it possible to run gnome-shell with calendar integration
disabled has been on my wishlist for quite a while now. This may also
be useful for the efforts to make gnome-shell work better on mobile
devices. Since the evolution data server processes might be a bit
too heavy for some mobile platforms too.
As for gnome-software + packagekit getting started (and taking
up quite a lot of RAM). I think these might already be disabled
on the livecd case, since auto downloading updates to have them
ready for installation on shutdown / reboot makes little sense
there. So the first thing to do there would be to check if
these are running at all.
If they are running there are 2 places where gnome-software
gets started:
1. /etc/xdg/autostart/org.gnome.Software.desktop
2. From a gnome-shell search provider
As for packagekit (will that still be there in F39?) this
gets triggered by both gnome-software as well as by some
code in gnome-shell talking to it to see if offline-updates
should be offered on shutdown/reboot.
One last thing to consider is to slightly increase the zram
factor on low RAM systems. Currently the zram real ram
relation is 1:1 which assuming a worst case compression
of 1:2 means that at full zram we end up with 1/2 real
RAM left, 1/2 RAM used for compressed swap through zram.
But typically RAM contents compresses pretty well, at least
achieving 1:3 compression. So if we are willing to reserve
half of the total RAM for compressed swap through zram then
we could make the zram size 1.5 times real RAM.
Regards,
Hans
p.s. here is the promised 1:1 copy of my notes on doing 1G RAM installs:
Fedora workstation Live install on 1G machine:
- At boot edit cmdline, add "3"
- vi /lib/systemd/zram-generator.conf
change zram-size to 2048
- systemctl stop systemd-zram-setup@.service
- systemctl start systemd-zram-setup@.service
- rm /usr/libexec/gnome-shell-calendar-server
- rm /etc/xdg/autostart/org.gnome.Evolution-alarm-notify.desktop
- rm /usr/bin/ibus-daemon
- systemctl disable --now sssd-kcm.socket
- backup existing efi\boot\bootx64.efi ?
- blkdiscard to fully-wipe ?
- resize partitions to make space ?
- systemctl start gdm
- settings -> search -> disable
- start a terminal with top, press shift+M kill unnecessary processes
like sssd_kcm, gnome-calendar, evolution*, tracker, ...
- start install to disk, cross fingers