How do I make use of hard disk which has been installed but not yet used to date

My HP Z640 machine was upgraded a while ago to include an nvme drive and a “spare” 1TB hard drive in addition to the original and still existing SSD. I have set it up with a dual boot configuration with the original windows 10 system remaining on the SSD with it’s own EFI Sytem and the Leap 15.4 system on the nvme.
The entire Linux system including its own BIOS Boot and EFI System is on the nvme drive and it boots to grub with an option to select the Windows system.

When I use the Yast Partitioner to examine my Linux system I can see that I have the 1 TB HDD at /dev/sda with one xfs partition on /dev/sda1 mounted at /run/media/alastair/4db57f2b-bce3-40ce-af34-1d8a7b1cc9b1/ The last part is presently shown as the mount point.

I honestly do not recall what was in my mind when I set this up but I believe it was so that it could hold multimedia data. This seems reasonable since the drive is empty and I now wish to use it to hold some multimedia files. Why is the mount point presently shown as what looks like a UUID and is how do I add a directory to the disk which is included in my home tree to hold my data. Using Yast can I edit the partition to have it mounted on /home/alastair/working_media as an encrypted partition and how do I set this up??

Your Desktop Environment has auto-mounted that drive’s partition.

You can use the YaST Partitioner to assign a new system-wide mount point for that partition in ‘/etc/fstab’.
Use –

> lsblk --fs

to examine the current disk partitions and to determine each partition’s UUID value.

  • For the terabyte XFS partition, the UUID is possibly “4db57f2b-bce3-40ce-af34-1d8a7b1cc9b1”.

Once the partition at ‘/dev/sda1’ has been mounted – for example at ‘/home_new’ – you can use the user “root” to create new user directories and, change those new user directories to be owned by the specific users.

  • The users can then access those directories via ‘/home_new/«User Directory Name»/’ .

What do you mean “as an encrypted partition”? Either the content of this partition is encrypted, or it is not encrypted. There is no “as” here.

The partition mounted at ‘/home’ is definitely mounted via ‘/etc/fstab’ when the system boots.

In general, it may well be better to mount the terabyte XFS partition as I described and then –

  • Create a symbolic link from the “working_media” place in your user’s directory tree to your user’s directory tree on the new terabyte XFS partition.
    The user will never notice the difference …

The YaST Partitioner offers an option to encrypt new partitions.
<https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-security-cryptofs.html>

Many thanks for your help. I am taking one step at a time following your advice. Using Yast I edited the auto-mounted drive as you suggested and now have:-

alastair@HP-Z640-1:~> lsblk --fs
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                
└─sda1      xfs                4db57f2b-bce3-40ce-af34-1d8a7b1cc9b1  930.1G     0% /new_home
sdb                                                                                
├─sdb1      vfat   FAT32       226A-AA59                                           
├─sdb2                                                                             
├─sdb3      ntfs               08686B55686B4094                                    
└─sdb4      ntfs               761CEE841CEE3EAD                                    
sdc                                                                                
sdd                                                                                
sde                                                                                
sr0                                                                                
nvme0n1                                                                            
├─nvme0n1p1                                                                        
├─nvme0n1p2 vfat   FAT32       1CE1-6E9C                             432.5M    15% /boot/efi
├─nvme0n1p3 swap   1           b1696969-7ce5-4ed5-b762-fc5df3e35373                [SWAP]
└─nvme0n1p4 btrfs              6426a5c3-e7d1-4c54-9c71-45055b9b672d    1.7T     7% /usr/local
                                                                                   /var
                                                                                   /tmp
                                                                                   /root
                                                                                   /srv
                                                                                   /opt
                                                                                   /home
                                                                                   /boot/grub2/x86_64-efi
                                                                                   /boot/grub2/i386-pc
                                                                                   /
alastair@HP-Z640-1:~> 

You then point out to advise that it is not a good idea to mount another partition below that mount point.
What I have now in fstab is:-

alastair@HP-Z640-1:/etc> cat fstab
UUID=6426a5c3-e7d1-4c54-9c71-45055b9b672d / btrfs defaults 0 0
UUID=6426a5c3-e7d1-4c54-9c71-45055b9b672d /var btrfs subvol=/@/var 0 0
UUID=6426a5c3-e7d1-4c54-9c71-45055b9b672d /usr/local btrfs subvol=/@/usr/local 0 0
UUID=6426a5c3-e7d1-4c54-9c71-45055b9b672d /tmp btrfs subvol=/@/tmp 0 0
UUID=6426a5c3-e7d1-4c54-9c71-45055b9b672d /srv btrfs subvol=/@/srv 0 0
UUID=6426a5c3-e7d1-4c54-9c71-45055b9b672d /root btrfs subvol=/@/root 0 0
UUID=6426a5c3-e7d1-4c54-9c71-45055b9b672d /opt btrfs subvol=/@/opt 0 0
UUID=6426a5c3-e7d1-4c54-9c71-45055b9b672d /home btrfs subvol=/@/home 0 0
UUID=6426a5c3-e7d1-4c54-9c71-45055b9b672d /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=6426a5c3-e7d1-4c54-9c71-45055b9b672d /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
UUID=1CE1-6E9C /boot/efi vfat utf8 0 2
UUID=b1696969-7ce5-4ed5-b762-fc5df3e35373 swap swap defaults 0 0
alastair@HP-Z640-1:/etc>

The terabyte partition which is not now shown here in fstab above,  but the "new_home" is showing in the root directory.  Not sure why the terebyte disk is not showing?

If this is OK and the device is correctly mounted I understand if I now create a symbolic link from /new_home to a working_media directory in /home/alastair/ and that would all be correct and the best way to achieve my objective.

If this is correct so far, can I go back to use Yast to format the partition as encrypted and then proceed as above with the symbolic link and use the new directory in my home directory.

Being slow and careful this morning as I had a minor op yesterday and am still enjoying hangover from the anaesthetic!!!

Another question: My xfs terabyte hard drive has been “demoted” from sda1 to sdb1 as in:-

alastair@HP-Z640-1:~> lsblk --fs
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                
├─sda1      vfat   FAT32       226A-AA59                                           
├─sda2                                                                             
├─sda3      ntfs               08686B55686B4094                                    
└─sda4      ntfs               761CEE841CEE3EAD                                    
sdb                                                                                
└─sdb1      xfs                4db57f2b-bce3-40ce-af34-1d8a7b1cc9b1                
sdc                                                                                
sdd                                                                                
sde                                                                                
sr0                                                                                
nvme0n1                                                                            
├─nvme0n1p1                                                                        
├─nvme0n1p2 vfat   FAT32       1CE1-6E9C                             432.5M    15% /boot/efi
├─nvme0n1p3 swap   1           b1696969-7ce5-4ed5-b762-fc5df3e35373                [SWAP]
└─nvme0n1p4 btrfs              6426a5c3-e7d1-4c54-9c71-45055b9b672d    1.7T     7% /usr/local
                                                                                   /srv
                                                                                   /var
                                                                                   /tmp
                                                                                   /root
                                                                                   /opt
                                                                                   /home
                                                                                   /boot/grub2/x86_64-efi
                                                                                   /boot/grub2/i386-pc
                                                                                   /
alastair@HP-Z640-1:~>

Why?

BIOS assigns those positions and usually is in order that it discovers them.

Yes, the order in which the Linux Kernel assigns the /dev/sd? devices is sometimes somewhat surprising –

Greg KH advocates not relying on this order. He likes give an example of a (real!) hideously designed motherboard, which re-arranges the PCI order between subsequent boots. It sounds like the above question is about one such example.


Bottom line:

To get persistent device naming with block devices, use the block devices below /dev/disk/by-id or /dev/disk/by-uuid.

1 Like

Hi and thanks. I learn something new every day. I would be happy to use UUIDs. Pity they are not more memorable!

Also thanks to your link I now understand more about encryption options and how they work. Will come back to this when I have some time as need is not urgent.

There is no need for that.
Normal users are not interested. And as system manager months can go before one needs one. And then they can be found in the /dev/disk/by-* directories and can e.g. be listed with (as root)

lsblk -f

lsblk normally reads udev database and so does not need root access (which is different from blkid which reads directly from block devices). Once upon a time SUSE built util-linux without udev support but that was fixed a couple of years ago.

I indeed see no difference anymore between this done as root or other user.

I stopped memorizing. fdisk and lsblk got nice output options. Tailoring the output to the columns needed helps a lot:

3400G:~ # fdisk -o Device,Size,Type -l /dev/nvme0n1
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Samsung SSD 950 PRO 512GB               
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A84F222E-0177-499B-A7EA-BDA6F31E2196

Device           Size Type
/dev/nvme0n1p1   100M EFI System
/dev/nvme0n1p2 476.8G Linux filesystem
3400G:~ # 
3400G:~ # lsblk -o path,fstype,uuid /dev/nvme0n1 
PATH           FSTYPE UUID
/dev/nvme0n1          
/dev/nvme0n1p1 vfat   6DEC-64F9
/dev/nvme0n1p2 btrfs  e7ad401f-4f60-42ff-a07e-f54372bc1dbc
3400G:~ # 
3400G:~ # cat /etc/fstab 
UUID=6DEC-64F9                             /boot/efi               vfat   defaults                      0  0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc  /                       btrfs  defaults                      0  0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc  /var                    btrfs  subvol=/@/var                 0  0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc  /root                   btrfs  subvol=/@/root                0  0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc  /home                   btrfs  subvol=/@/home                0  0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
3400G:~ # 

Hi dcurtisfra,
Having fun with this and encryption options the encrypted partition not mounted at boot time. This works as described but I have a question.

If I open the encrypted partition some time later I get a second instance of pCloud starting and appearing in my Tasks. My pCloud is started from an AppImage on booting. Is it possible to suppress this second pCloud start?

Sorry, I can’t help you here – I don’t use encrypted partitions – none of the user files I have on my Laptop disks contain information which should not be published.

Hi and thanks for this.
I have persevered with the main business of encryption and the problem artefact of a second pCloud icon has not been repeated.
I do have some issues however and and some details have not been explained. I have had some problems possibly due to some mapping going on behind the scenes. If however I adhere to the directions for creating the encrypted partition and have it “not start at boot” all is OK.

If I then wish to access the encrypted drive I use Dolphin to open the encrypted partition. I get the pw entry prompt OK but I then get two more prompt requirements for root entry. The first of these is for Authentication to unlock the encrypted device which comes from polkit.subject-pid and polkit.caller-pid. The second is for authentication to mount /dev/mapper/cr_test.

If I enter my root pw promptly I get an red error warning banner that the partition is already mounted.
Other than the initial scare factor I can then access the drive OK.

Thanks again for the guidance and the link.
Alastair.