Re: Readonly RootFS support in Emdebian
Am 03.02.2011 09:36, schrieb Neil Williams:
On Wed, 02 Feb 2011 23:02:23 +0100
Marcus Osdoba<marcus.osdoba@googlemail.com> wrote:
I successfully followed the steps given in the Debian wiki [1] to come
over some restrictions to make debian work on a read only rootfs.
[ ] RO support is not compliant with Debian architecture.
The way you've defined it, no. Debian follows the FHS and only
having /var/ readwrite is itself not compliant with FHS.
I agree to have these writable: /home /srv /tmp and /var.
In my mini-example project, /tmp is served via tmpfs. To be compliant
with FHS /home and /srv might be bind mounted to /var/local* like
proposed in the wiki.
But (don't bite me), I ran through the FHS several times now in
different languages and interpretations. The FHS says nothing about READ
ONLY parts. It talks about "static" and "variable". Static data is data
which does not change without admin intervention. I think, booting the
system is not an intervention of the system administrator.
The /etc branch is classified as static data in FHS. Interpreting
"static" as data which might be read only (since the admin does not
change it) leads to /etc might be read only. So the constraint to have
/etc writable just for booting seems to break FHS.
[<- assumption 1 ; thesis 2 ->]
Following the FHS and removing the need to have /etc writable makes read
only rootfs easier to create and support.
It also clearly documents the packages which require a writable /etc/
and has a few workarounds.
"Hacks" like creating symlinks from /etc/mustbewritable to
/var/writableconfigfile and changing the skripts to follow links could
be done in the packages already. If you know the files in /etc which
must be writable, the Emdebian package could include the "hack" already.
Smbpasswd must be writable on samba start up, so I put it in
/var/lib/samba - the pkg-default is /etc/samba/smbpasswd.
I'm not sure what you're expecting Emdebian to do. Using bind mounts to
allow writes into /srv and /home is not something that happens in the
packages, you need to sort that out in /etc/fstab. multistrap can put
that file in place using the setupscript option but as to what actually
goes into that file and how it works with other packages, that's not
down to the packages themselves.
Agreed! (but look above for what can be done within the packages).
Emdebian Grip has the same support for this as Debian - it requires
custom setups. i.e. hacks.
Small tweaks like the mentioned symlinks could be done in Emdebian?
I know, that ro-rootfs is not a written goal of Emdebian, but as
mentioned in a former mail: rootfs is quite common in embedded usage.
Most systems which would need a read-only fs would probably be better
with a smaller distribution. That's the question around Baked - it's so
far from what Debian can normally do that it's questionable whether it
actually is Debian anymore. A read only fs is a step beyond Baked.
Ok.
I hoped, that RO is a possible option for Grip and worth to implement
beyond Grip in any case (e.g. Baked).
I understood, that "be 100% compatible with Debian" and "have small
sized rootfs and RO" compete with each other.
There's no point using Grip for a read only fs because Grip implicitly
requires a writable fs, as does Debian. You're just wasting space if
you use Grip rather than Baked - all that code meant to allow smooth
upgrades and post-installation configuration (all the code that makes
Debian Debian) is just useless. Don't install it in the first place -
use Baked and create the entire configuration exactly as you want.
Emdebian can help with the tools but the actual content of any Baked
system - or read-only fs - is down to whoever wants that particular
solution.
Thanks for clarifying that. Anyway, I like to have something in between.
My device has 256MiB so I dont't really need a 32MiB shrinked down
system. I like the comfort of Debian to apt-get install a new package
and update the system with upgrade. The system should provide any
possibility while staying "small" sized. Furthermore, it should be
stable and well tested.
With Grip I could achieve this!
I remounted my rootfs rw, did an apt-get install followed by remount ro
-> excellent! All with 100MiB. Now I miss the "prepare for RO"
configuration option (robust against power loss etc.).
An (online)update of Baked is not possible by definition. I have to
re-create an updated rootfs and reflash -> so I decided to use Grip
instead of Baked after studying the Emdebian web site.
(I experimented around with buildroot before and thought about Crush as
alternative, too - but after reading "Development stalled"...)
Thanks for the awesome work on multistrap and Emdebian in general!
Regards,
Marcus
Reply to: