Anyone else interested in running some of their ARM devices with root mounted read only ?
Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Anyone else interested in running some of their ARM devices with root mounted read only ?
I like to run devices that are left on 24x7 from read only root.
Recently I had-to revisit the way I do it, but this time I took better notes of what I did, in the hope to make it a less time consuming thing for the future.
I've addressed things like:
enabling it when "sysro" is passed to kernel via append
have an automated means of setting up /var related stuff to write to tmpfs
have an automated means of rolling back to standard /var
If there is any interest in this I'll make an article on docs.slackware
I suppose it has some security implications too (as you can't write until you escalate root privileges to do the remount) ... but my primary objective in running the system RO is making the system 100% power failure proof. Sometimes a power failure may request interactive fsck when the system comes back up again ... that won't happen on a RO system.
Even a RW mode NAS would benefit from a ro root IMO?
IMO: Although having the OS running the NAS in good health at all times is a good thing there are other important aspects to consider too.
On your NAS chances are that at least the volumes that you export will need to be in RW mode hence the NAS might still hang while booting asking for iterative fsck on the exported volumes. You could mark the exported volumes not to get fsck at boot time (in fstab) but then repeated power failures could gradually introduce crap in your inode and block lists to the point where you really start to get bad effects.
On a NAS where the exported data is mostly static it's unlikely that you run into inconsistencies in block and inode lists.
If your NAS's OS runs off rotating mass storage who cares how mane times blocks get re-writtren you're not going to have the blocks ware out like on flash devices. The most important factor that drove me to running some of my systems with root RO was indeed the flash storage ware. (*)
I think the best thing would be to have the NAS (or any other thing that needs to have permanent data saved to RW volumes) under UPS.
I see the RO root thing as most useful for things that have basically static data (except for rare occasions where you might briefly remount root RW mode) on flash storage ... thins like access points, routers, firewalls, dhcp servers, print servers and other similar stuff ... or at least that's my opinion.
The base system could be run RO, while the PAYLOAD could be non-OS managed:
After the OS has booted, the rc.local gives control to an dedicated app:
1. sophisticated fsck
2. maybe even basic crc check of data
3. connectivity check and assurance (WiFi, LAN, BT, tty-s etc)
4. data mounted locally and
5. data exported for sharing (nfs,smb/cifs,ftp,tftp,ssh etc)
And the rw critical stuff can always be linked to a dedicated var partition on the mass storage (spun or solid) which would be on overlay over an fail-var partition on the OS carrier media (MMC or USB eprom storage)
Not to mention fs overlays now that we have live OS "in house" whit Alien BOB's live Slackware?
Sorry I should not have digressed ... after all this thread is for finding how many are interested on running their Slackware systems root mounted RO.
Two is not that many
I might end up just sharing some scripts instead of writing an article about it.
I've attached the patch. I forgot to remove an old copy of rc.local from the original rc scripts ... please ignore the rc.local part in the patch.
I use my DDI thing to do network initialization so you might want to also ignore the changes regarding rc.inet*
In the past I've created industrial systems where I've taken steps to minimize writing to the storage device because of the power failure issue and storage wear. So that makes one more interested in your patch.
Two is a small number ... but we're a small community so it's a number anyway but probably still to small to get Stuart to look into this thingy.
If anyone is going to use the patches I posted above pleas take care that the random seed carried across reboots does not get written do some location on the SD that would make a mess of your file-system in the case your first partition starts before sector 2048 (some of the older fdisk did that).
And if you often reboot you might want to deal with id differently as I'm targeting always the same sector .... this is fine for a system that should be running 24x7 but is less then optimal for a system that often reboots.
I've not been active in a while on the forum as I've been silently working on a thing I like to call "Geek Watch": an Arduino Nano based watch that can display time in Decimal (for the ungeek), Octal (for the UNIX nerds) and Hexadecimal (for the geek) with a micro cron like alarm system. Definitely off topic but I'm thinking about writing a series of small articles about it starting with how to keep reasonably accurate time without writing crazy compensation functions ... then moving on to a real world button debounceing (where you're not allowed to stop doing everything else while waiting for the button to be released) ... and so on up to intermittent buzzing without writing extra code to toggle buzzer status.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.