Read-only OEM install

[Roger Oberholtzer]

I have an OEM image based on Leap 42.3 that builds/installs fine
(pertty much...). I want to make a variation on this where the
complete installed image is read-only. All writes are to RAM. I know
kiwi does this, and have previously made PXE images that are like
this. When reading the kiwi docs, I admit I have gotten confused about
how best to do this with an OEM image. My current definition is:

<type image="oem" filesystem="ext4" boot="oemboot/suse-leap42.3"
installiso="true" bootloader="grub2" kernelcmdline="splash"
firmware="efi" initrd_system="dracut">

I would like to keep ext4. I am totally confused about what to specify
so that the image is read-only.

After I (we?) solve that, would it be possible for me to do one
prepare for both versions, and then a create for the normal and a
create for the read-only version?

--
Roger Oberholtzer

[Roger Oberholtzer]

Part of my confusion is that the docs say one thing for image, while
kiwi-ng says something else:

The docs: https://doc.opensuse.org/projects/kiwi/doc section 4.1.4
describes image="split"

kiwi-ng:

error: value of attribute "image" is invalid; must be equal to
"btrfs", "clicfs", "cpio", "docker", "ext2", "ext3", "ext4", "iso",
"oci", "oem", "pxe", "squashfs", "tbz", "vmx" or "xfs"

I am guessing "split" is now something else.

--
Roger Oberholtzer

[David Cassany]

Hi Roger,

> I have an OEM image based on Leap 42.3 that builds/installs fine
> (pertty much...). I want to make a variation on this where the
> complete installed image is read-only. All writes are to RAM. I know
> kiwi does this, and have previously made PXE images that are like
> this. When reading the kiwi docs, I admit I have gotten confused about
> how best to do this with an OEM image.

I am not entirely sure I understand your request, but there are several
ways in which you manage to get your writes into RAM. The most obvious
would be to deploy the oem image directly to RAM, not sure this is
exactly what you want as this implies having everything in RAM.

Another option is to use the overlayroot attribute, which will force
root to be a read only squashfs that will be overlayed to an extra
read-write partition (at the moment I am having a look if I can see an
option to force this partition to happen in RAM).

> After I (we?) solve that, would it be possible for me to do one
> prepare for both versions, and then a create for the normal and a
> create for the read-only version?

Yes, this can be achieved by using profiles, you can have multiple
<type> definitions in a single config.xml file, if this is your concern.

Regards,
David

[Marcus Schäfer]

Hi,

> I have an OEM image based on Leap 42.3 that builds/installs fine
> (pertty much...). I want to make a variation on this where the
> complete installed image is read-only. All writes are to RAM.

I think you are talking about an overlay system. kiwi supports this
with a squashfs compressed read-only root system overlayed using
the overlayfs filesystem into an extra read-write partition.
All is read-only (except boot, grub2 can't read from squashfs)
and all writes go to an extra partition with a filesystem of your
choice

For oem images the type setup would look like this:

<type
image="oem"
filesystem="ext4"

initrd_system="dracut"
overlayroot="true"
installiso="true"
bootloader="grub2"
boot="oemboot/suse-leap42.3"
kernelcmdline="splash"
firmware="efi"
>

In your packages section you also need

<packages type="image">
...
<package name="dracut-kiwi-overlay"/>
</packages>


Notes:

- When using a root overlay all other fancy filesystem variations
like btrfs volumes/snapshots or lvm volumes will no longer work
because that is incompatible with the kernel overlayfs

- I'm not completely finished with porting oem repartition and other
code from the kiwi oemboot code into dracut modules. Thus if you
build the image as indicated above only the deployment code in
the generated .install.iso file will be able to repartition and
resize the target disk. If you just dump the .raw disk on the
target the code to resize and repartition is missing because
the boot in this image is a dracut initrd

- Overall the above type will fundamentally change your image.
It's still an oem image in kiwi speak but it's no longer the
same thing as you build before due to a completly different
technology to run the OS. Thus thinking it's the same but
just read-only writing somewhere else is not correct

- The documentation on http://doc.opensuse.org/ is for v7 the
next generation kiwi docs does not yet provide a section for
overlayed root images, because I'm not done with it and the
prio is low at the moment

- I would not try to keep two variants via profiles in one image
description. The reason is I consider the result as too different
and that should be worth two independent image descriptions

Regards,
Marcus
--
Public Key available via: https://keybase.io/marcus_schaefer/key.asc
keybase search marcus_schaefer
-------------------------------------------------------
Marcus Schäfer (Res. & Dev.) SUSE Linux GmbH
Tel: 0911-740 53 0 Maxfeldstrasse 5
FAX: 0911-740 53 479 D-90409 Nürnberg
HRB: 21284 (AG Nürnberg) Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
http://www.suse.de
-------------------------------------------------------

[Roger Oberholtzer]

On Tue, Oct 10, 2017 at 11:02 AM, Marcus Schäfer <m...@suse.de> wrote:
> Hi,
>
>> I have an OEM image based on Leap 42.3 that builds/installs fine
>> (pertty much...). I want to make a variation on this where the
>> complete installed image is read-only. All writes are to RAM.

The reason we want to have changes in RAM is that in this use case,
the power may go away without a proper shutdown. The OEM image will
run on an Intel NUC in a box hanging off the back of a vehicle-based
measurement system. We want to minimize the places where a power
outage could lead to a failure.

We have a similar system (but in a VME rack inside a vehicle
measurement system) based on a KIWI-built PXE image where the initrd
is in memory (via dhcp/tftp), and the rest of the OS is served via a
vblade server. We want to eliminate the need for the server. Also, the
new system can have a local hard disk, which the older PXE one could
not have.

The disadvantage of an in RAM changes solution are that we cannot
easily change the OS in a permanent fashion. Like changing services or
running the firstboot autoyast stuff.

So we are at a decision point:
- All changes in RAM: Pro: Power failures are not so much of a
concern. Con: The OEM image must be ready to go and allows no
modifications, like changing services or running the firstboot
autoyast stuff.
- All changes to dedicated partition: Pro: The installed OS can be
modified. Power failures are less of a concern in that the damage
would be limited to a smaller partition. But, at the end of the day,
would that be safer than simply writing to the OS partition? Con: If
this little partition gets messed up it could just as easily keep the
system from booting.

As to not supporting LVM in the overlayroot scenario, we don't really
want that. We just want a partition to be made that uses all the space
left on the disk. The LVM approach is the only way within kiwi to
accomplish this. But a different solution is also interesting. Our
earlier Python script that did this was difficult to keep working as
it looked at the messages from various programs. Kind of like what
kiwi loves doing.

--
Roger Oberholtzer