Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

distri package management and a readonly rootfs #86

Open
Fuseteam opened this issue Jan 8, 2021 · 7 comments
Open

distri package management and a readonly rootfs #86

Fuseteam opened this issue Jan 8, 2021 · 7 comments
Labels
question Further information is requested

Comments

@Fuseteam
Copy link

Fuseteam commented Jan 8, 2021

I've been a user of ubuntu for over 2 years. one interesting aspect of it is the read-only rootfs. the distro makes use of image-based updates. one question that I've seen pop up a lot of times is: "why doesn't support apt?" the answer is of course because we use a read-only rootfs for image updates and as such cannot support apt. this leads to many users being unsatisfied because they can't install their favorite tools and package.

with that as a preface, here's my question since Distri uses images for updates could it work with read-only rootfs?

@stapelberg
Copy link
Member

I've been a user of ubuntu for over 2 years. one interesting aspect of it is the read-only rootfs

Did you forget a word in this sentence? Does Ubuntu really have a read-only rootfs by default? That’s news to me. Are you talking about a variant of Ubuntu maybe?

with that as a preface, here's my question since Distri uses images for updates could it work with read-only rootfs?

I haven’t tested this much, but here’s what I think: making most parts of the system read-only should work fine.

distri uses systemd, which does not need a read-writable root file system, see this Pid Eins systemd blog post about stateless systems for details and a lot more nuance.

As long as distri’s image store is writable (so that you can add a new image to the system), distri can mount the images and make the software available.

Now, does making the image store writable really still qualify as “read-only rootfs”? What’s left that’s read-only? /etc? Depending on the software, users might need to modify /etc, and then everything I can think of is writable after all :)

Typically, making a system read-only is done to prevent it from accidental modification. It sounds like you want to allow intentional modification (users installing tools/packages), so what do you want to achieve with a read-only rootfs in this case? If package installation works, doesn’t that go counter to the purpose of making anything read-only to begin with?

I hope that gives some perspective, but I’d really need more details to give better guidance here.

@stapelberg stapelberg added the question Further information is requested label Jan 10, 2021
@Fuseteam
Copy link
Author

I've been a user of ubuntu for over 2 years. one interesting aspect of it is the read-only rootfs

Did you forget a word in this sentence? Does Ubuntu really have a read-only rootfs by default? That’s news to me. Are you talking about a variant of Ubuntu maybe?

ah right i forgot the word "touch" ubuntu touch has a readonly rootfs by default not ubuntu

with that as a preface, here's my question since Distri uses images for updates could it work with read-only rootfs?

I haven’t tested this much, but here’s what I think: making most parts of the system read-only should work fine.

distri uses systemd, which does not need a read-writable root file system, see this Pid Eins systemd blog post about stateless systems for details and a lot more nuance.

As long as distri’s image store is writable (so that you can add a new image to the system), distri can mount the images and make the software available.

Now, does making the image store writable really still qualify as “read-only rootfs”? What’s left that’s read-only? /etc? Depending on the software, users might need to modify /etc, and then everything I can think of is writable after all :)

Typically, making a system read-only is done to prevent it from accidental modification. It sounds like you want to allow intentional modification (users installing tools/packages), so what do you want to achieve with a read-only rootfs in this case? If package installation works, doesn’t that go counter to the purpose of making anything read-only to begin with?

I hope that gives some perspective, but I’d really need more details to give better guidance here.

so the system has a readonly rootfs to allow for image based updates but it also allow for some paths to be writable. some some folders in /etc are indeed writable for example.
Typically the system is updated by replacing the rootfs image sans some writable paths. my goal is to allow installations of packages to work with this ota system.

i assume the image store is a single folder? where does distri mount the images to make it available?

@stapelberg
Copy link
Member

i assume the image store is a single folder?

Yes, the /roimg directory contains the images.

where does distri mount the images to make it available?

In the /ro mount point, using a FUSE daemon.

See https://distr1.org/things-to-try/ and https://distr1.org/getting-started/ to see the system in action

@Fuseteam
Copy link
Author

are /roimg and /ro the only writable paths we need? that actually seems to be compatible with ubuntu touch's readonly rootfs afaict. are there potential problems you can foresee? do you need to some more info about the set up?

@stapelberg
Copy link
Member

are /roimg and /ro the only writable paths we need?

(nit: /roimg can be writable, /ro is a virtual file system that is always read-only and allows access to the image contents)

Depends on the software. Some programs (e.g. Google Chrome) are portable and can run from /ro just fine. Other programs (e.g. the postfix mail server) require writing to /var.

distri does nothing to address this (a read-only root file system is not one of the project’s goals).

In distri, we compile programs with --prefix=/ro so that they can find their files when mounted under /ro.

Conceptually, this is pretty similar to homebrew installing everything under /usr/local, or Nix installing to /nix-store.

Perhaps this is all you need to do? Arrange for a single, writable path and install software in there?

@Fuseteam
Copy link
Author

Fuseteam commented Jan 12, 2021

hmmm that sounds promising to me yes, I will likely experiment with this once I get a chance, as for programs requiring write access to other paths, I suppose that's out of scope but an important note for me to keep in mind, thanks for the insight. For now I would be happy if I can make a distri work as is on ubuntu touch, I feel like I can get a better understanding of it all. i am definitely willing try and arrange for a single writable path to install software and see how distri behaves, I'll assume that will have to be /roimage in (for research purposes ofcourse). what about size, how large can these images get?

@stapelberg
Copy link
Member

For now I would be happy if I can make a distri work as is on ubuntu touch

Definitely try distri as-is before trying to make anything more involved work. See https://distr1.org/getting-started/

i am definitely willing try and arrange for a single writable path to install software and see how distri behaves

Note that you don’t need distri to play around with installing software to a single writable path. You can just build your software with --prefix= set accordingly and see how it behaves.

what about size, how large can these images get?

See https://repo.distr1.org/distri/jackherer/pkg/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants