Actually I did read somewhere that it is possible.
Actually I'm somewhere using this with.
Actually I did read somewhere that it is possible.
Actually I'm somewhere using this with.
My CH controller never reboots either. And only writes to its SD card when the configuration changes.
It comes up perfectly after a power cut...
I am not even interested in keeping it up to date. It does 1 job supremely well as it is
I ended up inadvertently doing this when my Pi wouldn't boot from SSD. It works, but it's awfully messy.
The SSD had a perfectly fine root partition, but the vfat one was borked somehow. Cant remember how I deborked it, but it runs fine now...
The root filing system is determined by what is in cmdline.txt of the sdcard (or the FAT like filing system on the first device it finds). What is in /etc/fstab wont change the root filing system in use.
---druck
With my first Pi (3b), I was paranoid about wearing out the MicroSD card.
I created an NFS share on a NAS server, and mapped most of the Pi's /var partition out to it via fstab. I did other weird stuff moving other writeable partitions over to the NAS, thus I had a pretty busy network.
Worked well for years, however when I desired to update the OS, decided life was too short to go though all that again, and instead focused on an improved backup ritual for the card.
I am not so sure about that At some stage during boot, fstab is used to (re) mount all partitions
I *think* that what happened in my case was that the root system was on SSD., but the linux image itself was from the SD card
The root volume (mounted on “/”) is the one volume that cannot be mounted/dismounted directly in the normal way on a Linux system. Instead, the kernel offers a special system call, pivot_root(2)
At boot time, the initial root volume is the contents of the initrd (“initial RAM disk”) image loaded by the bootloader along with the kernel. This contains, among other things, some minimal startup script that interprets the “root=” option that was passed to the kernel as its command line from the bootloader. At the end of initrd processing, it finds this volume, mounts it on a temporary directory somewhere, and uses pivot_root to swap that with the initrd root. The initrd filesystem (which is not root any more) is now mounted on that temporary directory and can be dismounted from it in the normal way, and all further processing can continue with the new root filesystem as “/”.
In a sense, the entry in /etc/fstab for the filesystem to mount on “/” is redundant in that it can never be used: accessing it means being able to open /etc/fstab in the first place, and you can only do that if the proper “/” is already mounted.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required