Disable customizations?

[e-minguez]

I'm trying to boot SLE Micro using Lima (#1456) but it will require a rework of the scripts (for example this one https://github.com/lima-vm/lima/blob/master/pkg/cidata/cidata.TEMPLATE.d/boot/30-install-packages.sh).

On the other hand, I'm wondering if it would be a way to just disable the customizations and just boot the raw image, so you can create an ignition/combustion file with the required tweaks and then map it as a fw_cfg or an ISO file.

[afbjorklund]

Seems to be slightly out-of-scope, most of these "customizations" are actually required (like iptables or sshfs)

Couldn't you do some detection of MicroOS, and do whatever snapshot and reboot is require to install them ?

EDIT: I guess that something similar would also be needed, for the "nerdctl-full" installation from the tarball:

https://github.com/lima-vm/lima/blob/master/pkg/cidata/cidata.TEMPLATE.d/boot/40-install-containerd.sh

[afbjorklund]

And a password (or credentials) ?

[AkihiroSuda]

And a password (or credentials) ?

Via a custom CD-ROM, fw_cfg, etc.

[afbjorklund]

So some kind of half-raw mode, I guess that could work

Better than having default passwords (like legacy), I suppose

[e-minguez]

Seems to be slightly out-of-scope, most of these "customizations" are actually required (like iptables or sshfs)

Yes, but I think we are ok to extend the scope to support raw mode. Needs video mode (or serial), though, typically.

That would be awesome.

And a password (or credentials) ?

Via a custom CD-ROM, fw_cfg, etc.

Exactly. Ignition/Combustion can be used via a CD-ROM device (with a proper label such as "ignition") or via the -fw_cfg QEMU flag (https://documentation.suse.com/sle-micro/5.3/single-html/SLE-Micro-deployment/#sec-ignition-configuration for example)

[afbjorklund]

For my "TinyCore" use case, I left the default password on the console and disabled password login over ssh instead.

[afbjorklund]

I was able to get Tiny Core running, but the default kernel won't support guestagent (audit) or containers (cgroups).

FATA[0000] audit not supported by kernel: protocol not supported

But at least it still quite tiny (with GUI about twice), when adding some packages: bash coreutils openssh sshfs.

18M	CorePure64-13.1.iso
27M	TC-remastered.iso
30M	TinyCorePure64-13.1.iso
37M	TC-graphical.iso

---

It too had some issues, with the non-openstack location of user-data and the requirement on using /mnt/lima-cidata.

But other than those quirks, I think the basics should work with any system supporting a minimum of cloud-init (users).

$ limactl shell core
anders@lima-core:~$ more /etc/os-release 
NAME=TinyCore
VERSION="13.1"
ID=tinycore
VERSION_ID=13.1
PRETTY_NAME="TinyCoreLinux 13.1"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:tinycore:tinycore_linux:13.1"
HOME_URL="http://tinycorelinux.net/"
SUPPORT_URL="http://forum.tinycorelinux.net/"
BUG_REPORT_URL="http://forum.tinycorelinux.net/"
anders@lima-core:~$ uname -r
5.15.10-tinycore64
anders@lima-core:~$ nproc
4
anders@lima-core:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           3.9G       86.5M        3.7G       56.2M       77.6M        3.6G
Swap:        959.1M           0      959.1M

https://github.com/afbjorklund/tinycloudinit (cloud-init implemented in awk)

For it to be useful though, it would need an extensive adaption similar to boot2docker or boot2podman... Easier with alpine ?

The GUI option could be interesting, it does boot the desktop OK - but for some reason it won't start apps, not even Terminal

[afbjorklund]

I remastered a version of the kernel, which enables the guestagent to start. It doesn't run containers though.

The TC experiments, including downloads, are available from here: https://github.com/afbjorklund/tinycloud