Today I upgraded my APU4D4 IPFire Firewall from core 178 to core 179. Everything is working well except the new Extra HD.
I have an EXT4 formatted USB-Stick inserted into the USB port of my APU4D4. Up to and including core 178 I could seamlessly use it with ExtraHD and create a shared Samba drive.
After upgrade to core 179 and reboot, this USB stick was not anymore mounted. ExtraHD was listing it, but flagged it as ‘Not mounted’.
Based on some post in this forum, I’ve then manually deleted the file ‘/var/ipfire/extrahd/devices’.
However, after a reboot this file is not recreated. ExtraHD is not recognizing any device anymore.
The USB stick is OK. I did a file system check at my Linux laptop
Can you help me to get the ExtraHD drive back again, please?
You deleted a file based on a forum post related to the previous version of Extra HD. The file might be doing quite different things now compared to previously.
I just tried plugging in a usb stick into my production IPFire and the stick was found.
I then specified a mount point and pressed the pencil icon and the mount point was created and the stick mounted.
I could then list the contents of the stick.
I then selected the green mounted icon and the drive was unmounted.
So I am not finding any issues.
When you plug in your usb stick and run lsblk from the command line do you see the usb stick listed?
What mount point did you use with the previous version of Extra HD?
For me it looks like as if ‘/var/ipfire/extrahd/bin/extrahd.pl’ is still the previous core 178 version:
There in no no string ‘udev’ in the file ‘var/ipfire/extrahd/bin/extrahd.pl’.
During the CU179 Testing the problem I found was related to LVM volumes. For those, as there is a workaround of adding the info into fstab, it was decided to leave fixing LVM on ExtraHD until after CU179 was released.
@jon then flagged up that some usb sticks were not showing up and it was identified that slow USB sticks were not getting correctly mounted at boot. A commit was done to fix that, at the start of last week, and there has been no feedback since then of further issues so the CU179 Testing has been released today.
As some of you are now flagging further issues found after release then I would suggest the best thing is to add them in as comments to the ExtraHD bug that is currently still open. https://bugzilla.ipfire.org/show_bug.cgi?id=12863
I would think you can also add a line for it into fstab. However, I would suggest not using sda nomenclature but the UUID in case adding or removing drives causes the drives to be renamed differently. The UUID is unique for each drive and I have been using those for all my fstab definitions for the last 4 years or so rather than /dev/sda1 etc
How would I have to store the entry in fstab if I want to mount the hard disk formatted with the UUID and EXT4 in the path /mnt/SSD-4TB?
Am a bit unpracticed in using fstab
Sorry
For example, if the UUID is 1234-ABCD and you want to mount it at /mnt/mydisk with ext4 filesystem:
UUID=1234-ABCD /mnt/mydisk ext4 defaults 0 0
Save the file and exit the text editor.
Create the mount point directory if it doesn’t exist:
mkdir -p /mnt/mydisk
Mount the filesystem to verify:
mount -a
The fstab entry ensures that the disk is mounted at boot or when you run mount -a. The defaults option refers to the default mount options, and 0 0 at the end are for dump and filesystem check options, which are generally safe to leave as zero.
The dump and pass (also called “check”) are the fifth and sixth fields in the /etc/fstab entry, respectively.
Dump: The dump field is used by the dump utility to decide if a filesystem should be backed up. If the value is 0, the dump utility will ignore the filesystem. If the value is set to 1, it will be included in the backup. dump is not commonly used these days, so this field is usually set to 0.
Pass (Check): The pass field specifies the order in which the fsck utility will check the filesystems at boot time. The root filesystem should have this set to 1, and other filesystems you want to be checked should be set to 2. If this is set to 0, fsck will not check the filesystem. It’s advisable to set the root filesystem to 1 and any additional filesystems to 2 to ensure they’re checked at boot, though not simultaneously, which could slow down the boot process.
In most cases, for additional disks and partitions, setting both dump and pass to 0 is acceptable, which means no backup and no check at boot.
A small note, usually noatime is interpreted as both “no last access time” for files and directories as nodiratime is supposed to be used only if noatime is missing, but I usually add both just in case, as I never found a problem with this redundancy.
The code scans for the UUID’s of all block devices and uses that data to mount all available drives on the previously defined mount points but if you want details you will need to go through the code.
I knew the old code pretty well but now its time to learn the new code!
rebooting does not re-mount the external drive. And the external drive cannot be re-mounted via extrahd.
I can get the extrahd to mount a external drive by removing the needed drive from /var/ipfire/extrahd/devices. And then all is well until the next reboot.
