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 _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
