Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Read-only root filesystem

User discussion about Debian Development, Debian Project News and Announcements. Not for support questions.
Post Reply
Message
Author
User avatar
kguciek
Posts: 2
Joined: 2010-04-01 21:29

Read-only root filesystem

#1 Post by kguciek »

Hi,

For a few years I've been hammering each new Debian release to match my view of how a distribution should work like regarding read-only and read-write partitions. Well I thought that if some Debian devs consider it worthy, they might make some changes in Debian itself to make it easier in the future...

I am describing my rationale and principles on this page: http://www.guciek.net/en/read_only_root_filesystem

I will be obliged if you reply and let me know what do you think of all this. As I am pointing out in the text linked above, unionfs does not meet the needs that are behind this effort.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

Re: Read-only root filesystem

#2 Post by julian67 »

Your proposals (taken as a whole) are fine for particular circumstances but not as defaults on a general purpose OS. Someone obtaining Debian may be doing so to create a home desktop, a cluster, a web server, almost anything. So in terms of file system hierarchy and user and root privileges they get a quite generic system by default. This is fine as it is for many purposes but serves as only the starting point for others. Your proposed configuration would suit only a few circumstances easily but in general it would be an unwelcome set of defaults. This is especially true for new or less experienced users/admins who would have acute difficulties in administering and using such a system. It would also be true for anyone running a testing or unstable release and for many doing development. It could turn simple tasks into a serious of tiny annoying obstacles. For people running a stable release, especially those administering it remotely, it could be quite annoying to not get automatic package management update of cache, downloading and installation of security updates and instead have to log in and remount / and do it all themselves. It would mean that before doing a simple apt-cache search one may need to remount filesystems to be sure one is seeing an up to date result.

One thing I noticed on your website was
A mistake made by many distributions is putting package manager's state files in /var. In fact, these state files only change when packages are installed or uninstalled, so they are not any more "variable data" than files contained in packages.
But this isn't exactly the case. The package manager needs to write to disk not only when installing/uninstalling but also when updating, so if package management can't write this does a nice job of disabling it in a fundamental way and completely precludes automation.

I don't mean to criticise because I like your ideas but I don't think they are right for a general purpose distribution.
Wisdom from my inbox: "do not mock at your pottenocy"

User avatar
kguciek
Posts: 2
Joined: 2010-04-01 21:29

Re: Read-only root filesystem

#3 Post by kguciek »

julian67 wrote:Your proposed configuration would suit only a few circumstances easily but in general it would be an unwelcome set of defaults.
I might need to clarify this, as in fact the changes in Debian that I meant would not be changing its default behavior. Notice that:

- in the example scenario, the root partition is mounted read-write after default system installation and first boot,

- I am using generic terms, is case of Debian "package manager state files" mean dpkg state files, and apt lists and caches should stay in /var, the only change is that apt should re-create its needed directories if they are not present.

Post Reply