search

shermand100 / PiNodeXMR

Monero Node for Single Board Computers with Web Interface and additional tools pre-configured. Self Installing.
GNU General Public License v3.0
213 stars 41 forks source link

PiNode not keeping USB storage persistent #15

Closed ChiefGyk3D closed 2 years ago

ChiefGyk3D commented 3 years ago

upon reboot it looks like the hard drive I attach is not added upon boot and has to be readded in menu. Possibly want to pipe the label and such created to fstab to keep persistence. Furthermore free disk space is not shown in status

shermand100 commented 3 years ago

This one is actually one of the better scripts as it's one of more recent ones, the script is reasonably well labeled too so you should be able to make sense of it. What you've described above should happen via /home/pinodexmr/setup-usb.sh where a drive is selected by the user, it is prepared and mounted, then added to fstab identified by UUID so should be static.

Is there a duff entry in your fstab?

ChiefGyk3D commented 3 years ago

Yeah it's not writing anything to fstab at all it seems

ChiefGyk3D commented 3 years ago

I had to add a line manually to fstab. I'm going to spin up my second HC2 and do a fresh build to start testing and tinkering with your script. I may also incorporate a change for ext4 as it actually has some better performance, especially for my Odroid HC2 that is using SATA to connect directly to the hard drive than USB

shermand100 commented 3 years ago

Sure. UDF is a strange format choice on my part, but I think justified. The biggest complaint generally with this project is the initial sync time. UDF was chosen as a cross-platform format allowing for "registering" the drive with the PiNodeXMR setup menu -> shutdown -> take that UDF drive to any Mac or PC for a fast sync -> plug into PiNodeXMR and power on.

How many people take advantage of that option I don't know. Perhaps giving people a drive format choice?

ChiefGyk3D commented 3 years ago

Fair enough. So I narrowed the issue down to the fact your script is looking to erase the fourth line. Armbian only has two lines it seems in fstab. I manually added in the appropriate lines for fstab and stat resolved that issue. I am doing a fresh build on a spare Odroid HC2 then going to image the completed version to my laptop so I can stop completely trashing it and wasting hours compiling monero

ChiefGyk3D commented 3 years ago

Looking like a permissions error possibly and a slight tweak for my Odroid HC2 running armbian to work sudo sed "3 a UUID=$UUID /home/pinodexmr/.bitmonero $FILESYSTEM noexec,defaults 0 2" -i /etc/fstab added it to fstab but when trying from the script it didn't seem to create it at all. Any ideas?

shermand100 commented 3 years ago

So I've put a plaster on it for now and in cases where users have their OS on an SDcard, external USB drive being configured this *should work

https://github.com/monero-ecosystem/PiNode-XMR/commit/340575c8d1d854c2e3180b83a7965c42a40ddd7a

However it would only work on the above assumptions of hardware.

If an Armbian user were using an emmc module with an SD card also inserted I couldn't guarantee the external drive would be the third line.

Perhaps it should just be appended each time the USB setup script is run? Without deleting the old. It would mean that if someone persistantly changed their external storage they'd have a bunch of dead mounts and UUID links, but with the script reading top to bottom I'm not sure of the worst consequence of that?

ChiefGyk3D commented 3 years ago

Here's another issue. I was trying to download the raw blockchain using axel (might be another enhancement worth looking at) and apparently the disk dropped off for some reason but .bitmonero because of how it's setup merely just started using the SD card and filled up overnight so I had to kill that copy this morning and redo the hdd mount. May want to look at the USB script to make a symlink to a path that only works when the drive is attached. I.e. move from /home/pinodexmr/.bitmonero to /media/xmrblockchain/.bitmonero point /dev/sda1 to /media/xmrblockchain then symlink /home/pinodexmr/.bitmonero to /media/xmrblockchain/.monero So if the path doesn't exist at least you have it fail that way and know there is an issue.

ChiefGyk3D commented 3 years ago

I am using these exact paths ATM on my node in production on the HC2 after making the folder and chown to pinodexmr, then making a new .bitmonero folder in /media/xmrblockchain/.bitmonero and symlinking it. This should be mirrored for Pi possibly, no issues with performance or anything just adds a failsafe

ChiefGyk3D commented 3 years ago

I tested a HDD drop and it worked a bit better to prevent the issue. Modified the format UDF commands. I may eventually add an Ext4 format option later on

shermand100 commented 3 years ago

I'm going through all the issues here for the project and think this either needs taking further or closing. My thoughts:

My experience with fstab recently has been as expected and mounting on boot has succeeded with 2 different both SSDs and HDDs. However your point is still valid, but I think this is mostly down to a user error (perhaps a incorrectly powered or failing drive/device causing the mount to drop). Where possible and simple it'd be great to protect a user from these errors.

Once again it's a trade off. This project must be aimed at beginners and ease people into a crypto node with not too many options. We're currently streamlining things at the user level and if these symbolic mount points happen without the user knowing then that's all good. I mention simplicity because the simplest/cheapest way of running this project is (but not the best performance) is with microsd card. 128GB cards can be sought very cheaply and 64GB on a pruned node even cheaper, so at it's core, for now this must remain the default.

So implementing the symbolic link would need to be triggered by the USB storage setup? And if so this non-default location would also need to be annotated in each start script for Monerod to find the chain. Am I overlooking a simpler way to signify external storage device un-mounting.

This instead could be better attacked in the next Web-UI improvement and have a status box red/green with the text "USB storage enabled" colour triggered by the presence of /home/pinodexmr/.bitmonero mount point to the device path permanantly stored in /home/pinodexmr/setup-usb-path.sh

Have you had issues of this nature since this way raised in October. Does this need work. What are your thoughts now?

nkinnan commented 2 years ago

I can verify this issue still exists. I'm installed to a SD card with a USB SSD connected and fstab is not updated. I have two lines in fstab. Not being a linux person I won't attempt a pull request. Please let me know if you need additional info.

nkinnan commented 2 years ago

Was just about to manually add the line to my fstab when I realized it had finally populated. I believe what happened is that I started/stopped the server, creating the .bitmonero folder, then deleted everything in it, then used the attach usb storage option again. The only difference this time was that the .bitmonero folder was already present when I used the configure usb storage option.

shermand100 commented 2 years ago

Was just about to manually add the line to my fstab when I realized it had finally populated. I believe what happened is that I started/stopped the server, creating the .bitmonero folder, then deleted everything in it, then used the attach usb storage option again. The only difference this time was that the .bitmonero folder was already present when I used the configure usb storage option.

A good spot. Thanks. Yes this would have been the case when we started using those pre-build binaries. The mkdir for .bitmonero was in the commented out block in the build instructions.

So re-added back in for...

Raspberry Pi OS: 06a236ca4dfb97f41ed309bc586bb64989365973 Armbian: f2f3aff

This should solve the problem you had today.

shermand100 commented 2 years ago

So this is now a much rarer issue encountered by users. For the reasons I'll list below I'll close this issue but think this thread serves as good examples and mitigations for other users:

Closing this until we see a marked increase in USB storage related issues (no issues in last ~5 months)