Closed ChiefGyk3D closed 2 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?
Yeah it's not writing anything to fstab at all it seems
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
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?
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
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?
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?
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.
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
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
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?
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.
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.
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.
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:
Most issues are not PiNodeXMR related and no issues reported since /etc/fstab auto-boot entry improved to look for previous entry to overwrite in commit https://github.com/monero-ecosystem/PiNode-XMR/commit/1a239379604c06744cb5efadb0908dfed6d7fd00
The above auto-mount from reboot seems to benefit anyone with intermittent power issues/underpowered supplies/over demanding drives.
Good education on suitable USB adaptors and less people using Raspberry Pi (which was particularly fickle to cheap adaptor).
UDF format dropped as an option to format new drives. Still backwards compatibility option for v4 to v5 migrating users
Closing this until we see a marked increase in USB storage related issues (no issues in last ~5 months)
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