Trouble with Extra HD @ core 179

I just spent few hours this week end doing this in a Debian machine. Here my notes on how to do this. In case it is useful.

To create an entry in /etc/fstab using the UUID, follow these steps:

  1. Access the machine via SSH as root.

  2. Run the blkid command to get the UUID:

    blkid
    

    Note the UUID for the hard disk you’re interested in.

  3. Open /etc/fstab:

    nano /etc/fstab
    
  4. Add a new line in /etc/fstab for the hard disk using the UUID. The general format is:

    UUID=your-uuid-goes-here  /mount/point  filetype  options  dump  pass
    

    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
    
  5. Save the file and exit the text editor.

  6. Create the mount point directory if it doesn’t exist:

    mkdir -p /mnt/mydisk
    
  7. 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.

1 Like

Thank you that has helped me for now and maybe there is still a solution to be able to manage this later again via ExtraHD.

You might want to add noatime and nodiratime to the defaults options in fstab. This should help saving writing cycles in your ssd.

UUID=your-uuid-goes-here  /mount/point  filetype  defaults,noatime,nodiratime  dump  pass

Thanks, I have added the two values and there is also a VEEAM backup running on the SSD which causes enough write cycles.

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.

@ewald - I have the same issue with CU 179

for me - External SSD connected via USB, EXT4 format, does not mount after reboot, cannot mount via EXTRAHD.

The only indicator of “odd” was the red circle on the right:

For me I deleted the devices in the /var/ipfire/extrahd/devices and then I was able to add a drive.

Still testing.

FYI - From what I can tell, the EXTRAHD does not populate /etc/fstab so I am not sure what happens on a reboot.

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! :exploding_head:


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.

I’ll add to bugzilla

this! very nice find!!

@ewald - please add this to bugzilla.
https://bugzilla.ipfire.org/show_bug.cgi?id=12863

it is udev-event that is missing

A bug report has been issued:

https://bugzilla.ipfire.org/show_bug.cgi?id=13354

2 Likes

atm it’s working again with build 180 testing.

1 Like

Cant mount ntfs formted hdd. Ext4 is working.

Can you confirm which Core Update you are finding this on.

What happens if you try and manually mount the ntfs hard disk. Does that work or not and if not what is the error message.

To mount ntfs volumes you need an extra parameter (-t ntfs3) because the kernel doesn’t detect this.
This is not supported by extrahd.

You have to mount this manually in /etc/fstab

4 Likes

Core 180.
Strange, ipfire can mount ntfs usb hdd, which was mounted before update. It is mounted under fuseblk file system.

Like we figured out, new one with ntfs is not recognized.
I dont know how to manually mount and is also unpractical.

thx

It is not really impractical. You need to do this fstab modification only once. Here’s a tutorial.

First you need to find the device name of your NTFS volume. You can use the lsblk command, which lists all block devices attached to your system. Here’s how to do it:

  1. Open a terminal.

  2. Enter the following command:

    lsblk -f
    
  3. Look for the device with an ntfs or ntfs3 file system type in the output. It will also show you the mount points if they are already mounted.

The output will look something like this:

NAME   FSTYPE LABEL       UUID                                 MOUNTPOINT
sda
├─sda1 ntfs   VolumeLabel XXXX-XXXX                            
├─sda2
...

In this example, sda1 is the partition with an NTFS file system. The device name would be /dev/sda1 if you want to mount this partition.

Remember that you should mount the specific partition (like sda1, sda2, etc.), not the entire disk (sda).

To mount an NTFS volume using the ntfs3 driver in /etc/fstab, you will need to add a new entry to the file that specifies the driver. Here’s how you can do it:

  1. Open the /etc/fstab file with a text editor. You will need root permissions to edit this file. For example, you can use nano:

    nano /etc/fstab
    
  2. Add a new line at the end of the file for your NTFS volume. The entry should look something like this:

    /dev/sdXn /mnt/your_mount_point ntfs3 defaults 0 0
    

    Replace /dev/sdXn with the actual device name of your NTFS volume, and /mnt/your_mount_point with the directory where you want to mount the volume.

    Here’s what each field means:

    • /dev/sdXn: The device name.
    • /mnt/your_mount_point: The mount point (folder) where the volume will be accessible.
    • ntfs3: The filesystem type.
    • defaults: Mount options. You can specify defaults or other options like rw for read-write access, uid=, gid=, etc., if needed.
    • 0: Dump (backup) option. 0 means don’t dump.
    • 0: Filesystem check order. 0 means don’t check at boot.
  3. Save the file and exit the text editor. For nano, you can press CTRL + X, then Y to confirm, and Enter to save.

  4. Now, you can either reboot your system or manually mount all filesystems mentioned in fstab with:

    mount -a
    

    This command will mount all filesystems specified in /etc/fstab.

  5. Verify that the volume is mounted correctly with:

    mount | grep your_mount_point
    

    or

    df -h
    

Make sure that the mount point directory (/mnt/your_mount_point) exists before you attempt to mount the volume. If it doesn’t, you can create it with:

mkdir /mnt/your_mount_point

Replace /mnt/your_mount_point with the actual path where you want to mount your NTFS volume.

2 Likes

Thx. This belongs to the wiki.

Just a few minutes ago I’ve updated successfully to IPFire core 181. Thanks for this new release.

My hope was that my ExtraHD issue reported for core 179 would be fixed. Unfortunately, ExtraHD does still not work for me.

Both for core 180 and now core 181, my USB stick is not detected as a drive.

/var/ipfire/extrahd/devices does not exist since I deleted it when having trouble with core 179.

Can you help me please to get ExtraHD working again?

By your post we cannot figure out the issue you see.

Please post a screenshot of the ExtraHD WebGUI before and after you add the USB drive.

And any relate log messages in the message log

Here we go:

/var/log/messages is including the following messages after inserting the USB stick:

Nov 23 17:00:18 IPFIREFW kernel: usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd
Nov 23 17:00:18 IPFIREFW kernel: usb 4-2: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
Nov 23 17:00:18 IPFIREFW kernel: usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 23 17:00:18 IPFIREFW kernel: usb 4-2: Product: Ultra
Nov 23 17:00:18 IPFIREFW kernel: usb 4-2: Manufacturer: SanDisk
Nov 23 17:00:18 IPFIREFW kernel: usb 4-2: SerialNumber: 4C530001220702112061
Nov 23 17:00:18 IPFIREFW kernel: usb-storage 4-2:1.0: USB Mass Storage device detected
Nov 23 17:00:18 IPFIREFW kernel: scsi host2: usb-storage 4-2:1.0
Nov 23 17:00:19 IPFIREFW kernel: scsi 2:0:0:0: Direct-Access SanDisk Ultra 1.00 PQ: 0 ANSI: 6
Nov 23 17:00:19 IPFIREFW kernel: sd 2:0:0:0: Attached scsi generic sg1 type 0
Nov 23 17:00:19 IPFIREFW kernel: sd 2:0:0:0: [sdb] 485228544 512-byte logical blocks: (248 GB/231 GiB)
Nov 23 17:00:19 IPFIREFW kernel: sd 2:0:0:0: [sdb] Write Protect is off
Nov 23 17:00:19 IPFIREFW kernel: sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
Nov 23 17:00:19 IPFIREFW kernel: sdb: sdb1 sdb2
Nov 23 17:00:19 IPFIREFW kernel: sd 2:0:0:0: [sdb] Attached SCSI removable disk

/etc/fstab does not list the newly inserted usb stick partitions.

blkid is showing the two partitions of the USB stick:

/dev/sdb2: UUID=“d2b4d010-b44f-4965-ad11-f06440f85265” BLOCK_SIZE=“1024” TYPE=“ext4” PARTUUID=“e11e9922-02”
/dev/sdb1: UUID=“db0ec710-b77f-4d11-94b3-33b18438348b” BLOCK_SIZE=“4096” TYPE=“ext4” PARTUUID=“e11e9922-01”

1 Like