Worktree fix luks soft reboot

[prestist]

Add x-initrd.attach option unconditionally to all LUKS crypttab entries.
This prevents systemd-cryptsetup-generator from adding
Conflicts=umount.target, which is necessary for soft-reboot to work
correctly with LUKS.

[gemini-code-assist]

Code Review

This pull request introduces logic to detect if the system is running on ostree and updates the crypttab generation to include the 'x-initrd.attach' option when necessary. I have identified an issue where the ostree marker file is incorrectly being checked within the target sysroot instead of the host's runtime directory. Additionally, I have suggested updating the detection logic to support an environment variable override for better testability and recommended updating the test case to verify the full crypttab output.

[travier]

This looks OK. But why is this CoreOS specific? Isn't Image Mode / bootc in the same boat here?

[prestist]

@travier ah im sorry, yeah my description was a little too specific sounding, I was just giving examples. The changes also would fix it for bootc / Image Mode. I will update the description.

Unless you were talking more about why I was conditionality pivoting for ostree systems only?

[travier]

I think my question is: What happens on Image Mode? If you take a bootc image and install it via Anaconda, does soft-reboot works? Is it anaconda that does the same workaround that we are adding here? Then adding it to Ignition makes sense as we use it instead of Anaconda. Otherwise if this does not work on Image Mode then we should probably figure out a fix that does not rely on Ignition.

[prestist]

I think my question is: What happens on Image Mode? If you take a bootc image and install it via Anaconda, does soft-reboot works? Is it anaconda that does the same workaround that we are adding here? Then adding it to Ignition makes sense as we use it instead of Anaconda. Otherwise if this does not work on Image Mode then we should probably figure out a fix that does not rely on Ignition.

oooh that is a very fair concern, to be honest I am not sure; I can do some research but it is out of my initial knowledge scope.

[prestist]

Alright so I did look into anaconda, its doing the same thing mostly. Its adding x-initrd.attach unconditionally for any LUKS device. @travier , In which case maybe we just drop our conditional. Makes it cleaner?

rhinstaller/anaconda#6785

[travier]

Thanks for finding rhinstaller/anaconda#6785, this helps with the context. Reading https://redhat.atlassian.net/browse/RHEL-112702 as well, this appear to be needed (wanted?) only for the root device?

[travier]

Are we writing a crypttab entry for the root device today?

[prestist]

Are we writing a crypttab entry for the root device today?

From my understanding there is no special case for root, so yes, if root is configured to be encrypted.

ignition/docs/operator-notes.md

Line 161 in 2446e1f

Ignition generates entries in `/etc/crypttab` for each device and expects that the operating system has hooks to be able to unlock the device (e.x.: `systemd-cryptsetup-generator`).

ignition/internal/exec/stages/files/filesystemEntries.go

Lines 38 to 98 in e3c445c

	func (s *stage) createCrypttabEntries(config types.Config) error {
	if len(config.Storage.Luks) == 0 {
	return nil
	}
	s.PushPrefix("createCrypttabEntries")
	defer s.PopPrefix()
	path, err := s.JoinPath("/etc/crypttab")
	if err != nil {
	return fmt.Errorf("building crypttab filepath: %v", err)
	}
	crypttab := fileEntry{
	types.Node{
	Path: path,
	},
	types.FileEmbedded1{
	Mode: cutil.IntToPtr(0600),
	},
	}
	extrafiles := []filesystemEntry{}
	for _, luks := range config.Storage.Luks {
	out, err := exec.Command(distro.CryptsetupCmd(), "luksUUID", util.DeviceAlias(*luks.Device)).CombinedOutput()
	if err != nil {
	return fmt.Errorf("gathering luks uuid: %s: %v", out, err)
	}
	uuid := strings.TrimSpace(string(out))
	netdev := ""
	if len(luks.Clevis.Tang) > 0 || cutil.NotEmpty(luks.Clevis.Custom.Pin) && cutil.IsTrue(luks.Clevis.Custom.NeedsNetwork) {
	netdev = ",_netdev"
	}
	keyfile := "none"
	if !luks.Clevis.IsPresent() {
	keyfile = filepath.Join(distro.LuksRealRootKeyFilePath(), luks.Name)
	// Write keyfile into sysroot
	contentsUri, ok := s.State.LuksPersistKeyFiles[luks.Name]
	if !ok {
	return fmt.Errorf("missing persisted keyfile for %s", luks.Name)
	}
	keyfilePath, err := s.JoinPath(keyfile)
	if err != nil {
	return fmt.Errorf("building keyfile path: %v", err)
	}
	extrafiles = append(extrafiles, fileEntry{
	types.Node{
	Path: keyfilePath,
	},
	types.FileEmbedded1{
	Contents: types.Resource{
	Source: &contentsUri,
	},
	Mode: cutil.IntToPtr(0600),
	},
	})
	}
	uri := dataurl.EncodeBytes([]byte(fmt.Sprintf("%s UUID=%s %s luks%s\n", luks.Name, uuid, keyfile, netdev)))
	crypttab.Append = append(crypttab.Append, types.Resource{
	Source: &uri,
	})
	}

[travier]

Thanks, code LGTM but if I understand correctlty, we should do that only for the root device and not for all mounts as those would be unmounted and re-mounted as needed on a soft reboot.

[travier]

Another interesting element is that this will not fix soft reboot for existing systems, only new ones as Ignition only runs once: rhinstaller/anaconda#6785 (comment). I'll file a tracking issue so that we remember that.

[prestist]

hmm looking at this more, I am questioning if this fix belongs in Ignition at all. The root LUKS device is set up by coreos-installer right?
If so and if the soft-reboot issue is specifically about the root LUKS device, this change in Ignition wouldn't fix it. I think that adding x-initrd.attach to non-root data volumes shouldn't hurt, but its starting to seem like its not enough?

wdyt? should this be a coreos-installer change instead?

[travier]

The root LUKS device is setup by ignition on first boot via the transpose-fs logic that copies the rootfs content into ram, then sets up the LUKS device and then copies the rootfs content back. So I think this is the right place. Can you make a kola test for soft-reboot on LUKS in fedora-coreos-config? That should let us validate that this is the right fix.