templates.d/99-generic/live: Enable automatic persistence for live media

[Conan-Kudo]

This change alters the live environment operating mode to default to operating with full root system persistence using the functionality recently added to Dracut.

It also adds menu entries so that it is possible to reset the persistence or start without persistence at all.

This re-applies the change after it was reverted in Fedora Linux 38.

Reference: https://fedoraproject.org/wiki/Changes/ModernizeLiveMedia

[coveralls]

Pull Request Test Coverage Report for Build 7316367067

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 43.472%

---

Totals
Change from base Build 7277687214:	0.0%
Covered Lines:	1616
Relevant Lines:	3504

---

💛 - Coveralls

[AdamWill]

So I tested this in openQA, and it seems there's a problem. It doesn't run the right mode of gnome-initial-setup on startup. Currently in Rawhide, when booting a Workstation live, it should run a specific mode of g-i-s which just shows the language and input method questions, then shows a "Try or Install?" screen which lets you continue to a live desktop or launch the installer. However, with this patch applied, a live image seems to run a different mode of g-i-s: after the input method question, it continues to the "create a user" part of the flow, which should not happen.

[AdamWill]

Hum, so now I had a bit more time to look at this, g-i-s may be doing the right thing after all. See the upstream MR for g-i-s. It's quite clever, because it folds in a similar feature that Endless has, and Endless already use persistence, so they already decided that in live+persistent mode, showing the "create a user" steps makes sense (which it does).

So I think I was wrong in diagnosing that g-i-s is in the wrong mode; it might be in exactly the right mode, running the live workflow but showing the user creation pages because persistence is enabled. It does look like this is what's intended to happen. This is the check to force live user mode:

if (gis_kernel_command_line_has_argument ((const char *[]) { "rd.live.image", "endless.live_boot", NULL }))
  force_live_user_mode = TRUE;

so we should still be hitting that, because with this patch, rd.live.image is still on the cmdline. But then later there's this:

  if (driver_mode == GIS_DRIVER_MODE_LIVE_USER && !gis_kernel_command_line_has_argument ((const char *[]) { "rd.live.overlay", NULL })) {
    ActUserManager *act_client = act_user_manager_get_default ();
    const char *username = "liveuser";
    g_autoptr(ActUser) user = NULL;
    g_autoptr(GError) error = NULL;

    user = act_user_manager_create_user (act_client, username, username, ACT_USER_ACCOUNT_TYPE_ADMINISTRATOR, &error);

    if (user != NULL) {
      act_user_set_password_mode (user, ACT_USER_PASSWORD_MODE_NONE);
      gis_driver_set_username (driver, username);
      gis_driver_set_account_mode (driver, UM_LOCAL);
      gis_driver_set_user_permissions (driver, user, NULL);
    }
    return NULL;
  }

That is, we automatically create a 'liveuser' account and skip the account page - but only if we're in live mode and rd.live.overlay is not on the cmdline. With this patch, rd.live.overlay is on the cmdline, so I think g-i-s is probably hitting exactly this path, and intentionally showing the account creation page.

I'll test the live image locally to see exactly how it works, and if it seems sane, I'll update the openQA tests to handle this new path and run them again.

[AdamWill]

Hum, okay, so I tested some more, and I think this has issues.

Booting with an actual USB stick on a bare metal host, I see these errors during boot:

May 09 10:56:39 fedora dracut-initqueue[877]: mount: /run/initramfs/overlayfs: can't find LABEL=fedorapersist.
May 09 10:56:39 fedora unknown: 
May 09 10:56:39 fedora unknown: 
May 09 10:56:39 fedora unknown: 
May 09 10:56:39 fedora unknown: 
May 09 10:56:39 fedora unknown:    Unable to find a persistent overlay; using a temporary one.
                              All root filesystem changes will be lost on shutdown.
May 09 10:56:39 fedora unknown:          Press [Enter] to continue.
May 09 10:56:39 fedora unknown: 
May 09 10:56:39 fedora unknown: 
May 09 10:56:40 fedora kernel: EXT4-fs (loop1): write access unavailable, skipping orphan cleanup
May 09 10:56:40 fedora kernel: EXT4-fs (loop1): mounted filesystem 422ac118-d307-4588-9b7c-39a11b575d29 ro with ordered data mode. Quota mode: none.
May 09 10:56:40 fedora systemd[1]: run-initramfs-squashfs.mount: Deactivated successfully.
May 09 10:56:40 fedora systemd[1]: Finished dracut-initqueue.service - dracut initqueue hook.
May 09 10:56:40 fedora systemd[1]: Reached target remote-fs-pre.target - Preparation for Remote File Systems.
May 09 10:56:40 fedora systemd[1]: Reached target remote-cryptsetup.target - Remote Encrypted Volumes.
May 09 10:56:40 fedora systemd[1]: Reached target remote-fs.target - Remote File Systems.
May 09 10:56:40 fedora systemd[1]: Starting dracut-pre-mount.service - dracut pre-mount hook...
May 09 10:56:40 fedora systemd[1]: Finished dracut-pre-mount.service - dracut pre-mount hook.
May 09 10:56:40 fedora systemd[1]: Mounting sysroot.mount - /sysroot...
May 09 10:56:40 fedora mount[910]: mount: /sysroot: special device LiveOS_rootfs does not exist.
May 09 10:56:40 fedora mount[910]:        dmesg(1) may have more information after failed mount system call.
May 09 10:56:40 fedora systemd[1]: sysroot.mount: Mount process exited, code=exited, status=32/n/a
May 09 10:56:40 fedora systemd[1]: sysroot.mount: Failed with result 'exit-code'.
May 09 10:56:40 fedora systemd[1]: Failed to mount sysroot.mount - /sysroot.
May 09 10:56:40 fedora kernel: overlayfs: failed to resolve '/run/overlayfs': -2

g-i-s shows the 'enter a username' screen, but once I enter a username, it does not prompt me to enter a password. In the logs, I see this:

May 09 18:03:13 localhost-live accounts-daemon[1304]: request by system-bus-name::1.67 [/usr/libexec/gnome-initial-setup pid:2254 uid:980]: create user 'test'
May 09 18:03:13 localhost-live useradd[2490]: new group: name=test, GID=1000
May 09 18:03:13 localhost-live useradd[2490]: new user: name=test, UID=1000, GID=1000, home=/home/test, shell=/bin/bash, from=none
May 09 18:03:13 localhost-live useradd[2490]: add 'test' to group 'wheel'
May 09 18:03:13 localhost-live useradd[2490]: add 'test' to shadow group 'wheel'
May 09 18:03:13 localhost-live audit[2497]: AVC avc:  denied  { open } for  pid=2497 comm="cat" path="/tmp/usericonKF4CN2" dev="tmpfs" ino=51 scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file permissive=0
May 09 18:03:13 localhost-live accounts-daemon[2497]: /bin/cat: /tmp/usericonKF4CN2: Permission denied
May 09 18:03:13 localhost-live gnome-initial-s[2254]: SetIconFile call failed: GDBus.Error:org.freedesktop.Accounts.Error.Failed: copying file '/tmp/usericonKF4CN2' to '/var/lib/AccountsService/icons/test' failed: unknown reason

When I reach the end of g-i-s, if I choose to go to a live desktop, it never successfully reaches one. If I choose to run the installer, that does work OK.

If I reboot and boot again 'with persistence enabled', there's no trace of anything I did on the previous boot - the home directory of the user I tried to create is not there, and journalctl -b-1 does not work.

If you want to try this out for yourself, the image is available at https://adamwill.fedorapeople.org/03861950-Fedora-Workstation-Live-x86_64-117403736.iso .

[AdamWill]

I also think there's a case here we might not have considered: what about booting from an optical disc? Yes, you can still write the ISO to a shiny coaster and boot it, it (probably) works. More realistically, you can boot a virtual machine with the ISO attached as a virtual optical medium.

In this case we still show all the "boot with persistence" options, but obviously persistence will not work. (But g-i-s will probably still try to create a user account). I'm not sure what we can do to make this path better, but it seems like an issue.