Read only boot and file system

I just discovered I can make the boot and file system partitions read only with raspi-config. Never had a use for it before. This post is an addendum to my other post, which I guess no one has an answer for. So if the makers of Mycroft are reading this, can I make the boot and file system partitions read-only and Mycroft still functions as normal? I don’t perceive any permanent writes, which need to be stored across reboot, that Mycroft needs to do on a raspberry pi and SD card since pretty much everything is accessed through the cloud.

EDIT: Probably should have said ‘permanent writes, after setting it all up’.

Fun fact: I just had a btrfs server shutting down because of bad ctrees. (ie boot into readonly) That was fun. You don’t want to emulate that.

So, media that has to be protected on seperate partitions, yes. Other than that…
there are mountains of data written onto the fs. If you want to redirect that to some place :rw … good luck

Ok, so that’s a no-go then. I thought maybe getting any writes to ram, without worrying about them disappearing on a power cycle. As far as a I thought, Mycroft didn’t constantly store new data, past the setup and skills adding. Of course, it would have to be disabled on upgrades, so there’s that…

There are benefits to having certain filesystems read-only.

On devices such as the Raspi it’s common to never shut them down - so they typically only go off in powercuts or when someone accidentally turns them off.
Additionally SD cards don’t like being written to a lot - they can wear out so having a read-only system helps.

Of course there are issues; as SGee says, data is written to the disk all the time - but nowadays there’s a lot of effort to restrict that to /var, /run and /tmp. Of those /var is often the only one actually on disk. The others are often RAM filesystems.

The solution for that is to use what’s called an overlay filesystem - it basically fakes writes and every time you reboot it starts over.

So yes, you totally can have a RO mycroft and I’d actually almost expect a productised device to make use of that.

I’ve not got round to it because mine actually boots via NFS and has no SD card at all :wink:

So, you’re doing a pxe boot of Mycroft? If so, I have some questions. Is this running on a raspberry pi? Wired or wireless? How long does it take to boot? Can you provide some details of your pxe server setup?

I really would like to do a pxe boot for octoprint on a soon-to-install raspberry pi, and maybe a pi server in the same area. Mycroft is wireless so I don’t think that would work.

Yes.
This is a Pi 4
It can only boot wired - booting is comparable to SD boot - maybe a touch faster

I use a normal Debian 10 machine as the server and it runs isc-dhcp-server and tftpd-hpa

dhcpd.conf has:

host damson { hardware ethernet dc:a6:32:af:6f:c9 ; fixed-address 10.0.0.164; ddns-hostname "damson"; }
and:

shared-network home {
  subnet 10.0.0.0 netmask 255.255.255.0 {
        range 10.0.0.90 10.0.0.126;
        one-lease-per-client on;
        filename "pxelinux.0";
        next-server 10.0.0.7;
  }
}

The ‘next-server’ is your tftp server iirc (it’s been over 10 years since I set that up :wink: )

Each pi has its /boot bind-mounted to a dedicated dir inside the tftp area (tftp is chrooted)
bootconf.txt has this in it:

BOOT_ORDER=0xf412
TFTP_IP=10.0.0.7
TFTP_PREFIX=1
TFTP_PREFIX_STR=/damson/

/boot/cmdline.txt is

console=serial0,115200 console=tty root=/dev/nfs nfsroot=10.0.0.7:/srv/rpi/diskless/damson,vers=3 rw ip=dhcp rootwait elevator=deadline

My notes include :

  update-rc.d resize2fs_once remove
  apt-get purge dphys-swapfile dphys-config
  update-rc.d -f dphys-swapfile remove

HTH

Thank you for this info! I might try this in a hardwired Pi server I have.

Great - do ask if you have any specific issues.