Hello I am installing clearlinux from live USB. My requirements:
ClearLinux will share one drive with Windows10 and Fedora32.
I would like to use hibernate and suspend.
There are several issues that are not clear.
Will I be able to adjust the choices in “Safe Installation” before it takes effect?
It is not clear whether I should reuse the existing 220MB /efi partition used by Windows and Fedora. Will the CLR_BOOT partition be only used as an /efi partition? Or will it accumulate kernels as in fedora /boot partition does? More generally will it require more space over time, or is sharing 100-150MB free space enough?
The installer gives me an error: CLR_SWAP must be <= 8GiB. Is this a fundamental restriction of ClearLinux? How do you support hibernation / suspend-to-disk with larger RAM systems?
After resizing the swap partition, and closing the partition manager, the installer returns without the CLR_SWAP error, but it now says:
Warning: No Media Selected. I reselect “Advanced Installation” and click “Partition Media” and the three CLR_??? partitions are still labelled. How do I proceed?
I would definitely advise against trying to multi-boot 3 OS from the same drive. This scenario is not tested, and the desktop version of Clear Linux is not in active development. Also, as discussed elsewhere on the forum, hibernation is disabled in Clear Linux, so you won’t be able to hibernate even if you do succeed in getting the OS installed.
Thank you for your answer to my question 3b, and for letting me know the untestedness of 3 OSes. Apparently I have been confusing by bringing up too many issues at one time. Here is the first question.
Will I be able to adjust the choices in “Safe Installation” before it takes effect? Or does it proceed automatically once you start that option?
Only Advanced Installation allows for the modification of partition sizes.
Safe Installation will use all of the free space on the selected media; creating a small boot and the remaining space for the OS (and a swapfile).
The modification of the disk does not start until the final “Confirmation” of the installation start is selected. All options about the installation are selected first, then the installation proceeds without user interactions.
The 8GiB limit was put in place intentionally. Mainly to prevent users from wasting space as the primary reason for such a large swap would be hibernation which is not supported.
You can override this limitation by adding the command line argument --skip-validation-size, no need to rebuild the application. You could also change this in the system configuration file for the installer by adding skipValidationSize: true to /usr/share/defaults/clr-installer/clr-installer.yaml.
@SimpleOne, thank you for your suggestions of fstab generator and zram and zswap. These options had not appeared in our searches.
Your answer makes me wonder whether the systemd solution has really any advantage over /etc/fstab: They both would need to be reconfigured after any install; it is not clear that either is “less stateless” than the other. /etc/fstab is familiar and well documented, so I’ll probably go with that.
No worries, hope it helps. The stuff below is probably not news to you @philip1, it’s just some background for anyone reading this in the future.
There’s really no great reason to bypass the use of /etc/fstab for most user modifications to mounts (unless you particularly enjoy playing with systemd unit files…)
Whilst that isn’t all that there is to the whole ‘stateless’ thing, it’s an example of where user config is isolated from core OS config. The result of that separation is that it’s our problem to maintain, backup (and restore as needed) our own user modifications/overrides. That’s pretty simple, just backup (and version, if you are keen) your /etc directory, and any other user content (typically /home, but perhaps /opt and so forth).
In your case, you are correct, it’s basically the same amount of work to perform a restoration. You have to restore files into /etc, it’s just a question of what files. You either restore /etc/fstab and let the OS dynamically recreate the systemd unit files, or you would restore the relevant unit files directly (which you could have written yourself in the first place if you were keen enough).
In essence, unless you don’t trust fs-tab-generator to do the job, or you have something too complex for it to handle, then you may as well stick with that which is well documented as you say, the path of least resistance