Raspiblitz: [Research] Boot option from SSD

[openoms]

All applications with their own users could be built on the disk to spare SDcard write cycles.
In case of USB3 connection and SSD there is a significant gain on the speed as well.

For example with ThunderHub I've tested:

# create thunderhub user
sudo adduser --disabled-password --gecos "" thunderhub
# move the home directory to the disk
sudo usermod -m -d /mnt/hdd/app-storage/thunderhub thunderhub
# symlink to default folder
sudo ln -s /mnt/hdd/app-storage/thunderhub /home/thunderhub

but resulted in npm permission errors on installation.

Same when instead of the symlink I have swapped all /home/thunderhub paths to /mnt/hdd/app-storage/thunderhub

Will try with other services.

The ones with long build times like ElectRS and RTL would benefit greatly being built on the disk.

[openoms]

Running completely off the SSD is now possible as @hermanlim described in https://github.com/rootzoll/raspiblitz/issues/1205#issuecomment-635095566
Link to how to: https://www.tomshardware.com/how-to/boot-raspberry-pi-4-usb

Seems that it would need a dedicated (first) partition on the SSD so would only be realistic for new setups.

In that case the SDcard could be kept solely for firmware+OS updates and maybe for infrequent security backups for the SCB and other valuable data.
The SDcard contents could be cloned to the boot partition of the SSD during a first boot, update or recovery -> more work on the blitz.datadrive.sh

@rootzoll what do you think?

[rootzoll]

@openoms yes had the same realization. So the sd card will become as a way to insert new updates, but the OS is running from the SSD. This way we can even use cheaper sd card again, which would also lower the price :)

We can do this together with introducting a new default SSD partition layout similar as we do for experimental BTRFS ... so we would have:

• a os-partition (around 32GBs)
• a data-data partition
• a data-storage partition
• a temp-partition

[hermanlim]

USB thumb drive which is being used for the experimental BTRFS setup could also be partitioned to allow it to serve as an update vector. This would remove completely the need for the SD card once boot from USB is enabled by default on RPi4...

Even if not using BTRFS, I believe more people find it easier to access something that can write onto USB thumbdrive media as opposed to SD card since pretty much all computers come with USB drives but not all computers come with SD slot.

[rootzoll]

Running an additional thumb drive (for example as raid) should still be optional because of the extra power that is needed on the USB ... in the past power drop outs were one of the biggest troubles we had people getting corrupted databases. Even if the sd card reader of the Pi is in the end drawing on the same power its always the same standard component ... if we make an extra usb thumb drive part of our standard setup, people will connect all kind od USB storages as that drive and we risk lots of support requests. So I am just carefull here.

Also people know how to copy files over to a usb drive - but not how to write images to a usb drive. So an extra USB drive would just be dumb data drive with an image file on it ... not a bootable device and even if the USB thum drive would be bootable - so how would be get started with the RaspiBlitz on a fresh setup?

Running a RaspberryPi one basic skill is to learn how to write sd cards with images ... for all kind of projects. So I think even if this is an extra step to learn for people - its an empowering one and we should keep to that basic technique for default.

For the future for people that get delivered a pre-build node and want more convenience on update I could image a update process ... like the OS running on SSD, if an new image is available it will be downloaded thru TOR, then the new image gets written to the sd card and then the system reboots itself, starting that sd card running the update.

The update should not be automatic (user action still being required) and there should be no central person/server making delivery of the update (could be a changeable subscription with the shop/personoftrust delivering the prebuild node or something like that) ... but I think having the sd card still as the default/fallback boot medium of the RaspberryPi in the mix makes sense.

[geco91]

How can we create that one bootable partition on the SSD? To recap, we wanted to target for a future SSD layout:

• a os-partition (around 32GBs)
• a data-data partition
• a data-storage partition
• a temp-partition

All guides to make a RaspberryPi booting from SSD say that you should "clone" the sd card to your SSD or write the raspberryPi OS image to the SSD - which triggers the following question:

The sd card contains multiple partitions already - see:

So do we need to target for a layout like this?

• a boot partition (small)
• a os-partition (around 32GBs)
• a data-data partition
• a data-storage partition
• a temp-partition

That maybe possible on setup up fresh - first clone and then extend partitions. But how will we do updates? Can we clone/copy/replace single partitions? Any input here is welcome.

[openoms]

I think realisticly it would be the same as when switching to a BTRFS filesystem: https://github.com/rootzoll/raspiblitz/blob/v1.6/FAQ.md#how-to-use-btrfs-on-raspiblitz using the MIGRATION method.
Cannot guarantee the integrity of the data when moving partitions and it would also take a long time. The best is to repartition the disk and copy the verified blockchain back over from an external source (over the network as that is the most desktop-OS-independent way).

For testing and advanced users it would be nice to be able to prepare the disk with the new partition layout preloaded with the blockchain data (app-storage partition) and even maybe the app-data to simulate a recovery scenario.