Disk model (identity change) is possible?

I would like to change the USB mediums disk model 'STORE N GO' identity if possible (shown below). # fdisk -l Disk /dev/sdb: 57.77 GiB, 62025367552 bytes, 121143296 sectors Disk model: STORE N GO Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes # dmsetup rename /dev/mapper/sdb_crypt Transit-Medium Was able to create a new mapper name: Disk /dev/mapper/Transit-Medium: 57.75 GiB, 62008590336 bytes, 121110528 sectors 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: dos Disk identifier: 0x00000000 Which steps are required to do this? Is it possible to change the "Disk Model" identity? -Thanks

On 2024-12-27 08:02, -pj via openSUSE Users wrote:
I would like to change the USB mediums disk model 'STORE N GO' identity if possible (shown below).
# fdisk -l
Disk /dev/sdb: 57.77 GiB, 62025367552 bytes, 121143296 sectors Disk model: STORE N GO Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
I don't think so. But I don't see what relationship has that with dmsetup below.
# dmsetup rename /dev/mapper/sdb_crypt Transit-Medium Was able to create a new mapper name:
Disk /dev/mapper/Transit-Medium: 57.75 GiB, 62008590336 bytes, 121110528 sectors 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: dos Disk identifier: 0x00000000
Which steps are required to do this? Is it possible to change the "Disk Model" identity? -Thanks
-- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

On 12-27-2024 06:27AM, Carlos E. R. wrote:
On 2024-12-27 08:02, -pj via openSUSE Users wrote:
I would like to change the USB mediums disk model 'STORE N GO' identity if possible (shown below).
# fdisk -l
Disk /dev/sdb: 57.77 GiB, 62025367552 bytes, 121143296 sectors Disk model: STORE N GO Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
I don't think so.
Ok thank you for that information.
But I don't see what relationship has that with dmsetup below.
I have changed this posts topic. Below is the /dev/mapper name that I would like to set persistently for the usb medium "Transit-Medium".
# dmsetup rename /dev/mapper/sdb_crypt Transit-Medium Was able to create a new mapper name:
Disk /dev/mapper/Transit-Medium: 57.75 GiB, 62008590336 bytes, 121110528 sectors 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: dos Disk identifier: 0x00000000
The /dev/mapper/Transit-Medium name I have now found to not be persistent, across powercycles. The mapper name has now reverted to /dev/mapper/luks-742dde43-08d7-4e4f-bce7-624c79bfb02b Which I believe to be a UUID? It's actually quite trivial most likely.
In order to have a persistent name of "Transit-Medium" set. Would editing fstab be in order? The usb medium will be used to transfer data from a few various machines so the best most uniform and functional way is to leave things how they currently are? Regards

On 2024-12-27 17:29, -pj via openSUSE Users wrote:
On 12-27-2024 06:27AM, Carlos E. R. wrote:
On 2024-12-27 08:02, -pj via openSUSE Users wrote:
I would like to change the USB mediums disk model 'STORE N GO' identity if possible (shown below).
# fdisk -l
Disk /dev/sdb: 57.77 GiB, 62025367552 bytes, 121143296 sectors Disk model: STORE N GO Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
I don't think so.
Ok thank you for that information.
Welcome :-)
But I don't see what relationship has that with dmsetup below.
I have changed this posts topic. Below is the /dev/mapper name that I would like to set persistently for the usb medium "Transit-Medium".
# dmsetup rename /dev/mapper/sdb_crypt Transit-Medium Was able to create a new mapper name:
Disk /dev/mapper/Transit-Medium: 57.75 GiB, 62008590336 bytes, 121110528 sectors 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: dos Disk identifier: 0x00000000
The /dev/mapper/Transit-Medium name I have now found to not be persistent, across powercycles. The mapper name has now reverted to /dev/mapper/luks-742dde43-08d7-4e4f-bce7-624c79bfb02b Which I believe to be a UUID? It's actually quite trivial most likely.
In order to have a persistent name of "Transit-Medium" set. Would editing fstab be in order?
No, /etc/crypttab. #/dev/mapper/name device or file none options Transit-Medium /dev/disk/by-uuid/742dde43 none auto Notice that there is sort of convention to use names such as "cr_...", but the name is actually arbitrary. Mind: I am unsure of the options, and whether also editing fstab is necessary, but I hope you can test this and find out ;-) 'device' can be of several forms: /dev/disk/by-id/ata-ST3500418... /dev/disk/by-uuid/4b87dd41... /dev/disk/by-partuuid/66a96652... /dev/disk/by-partlabel/Jz2-... UUID=f1f26736-... Not recognized when I tried. Might work now. [...] I have a note that YaST created such syntax once for me, so I guess it should work. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

On 12-27-2024 03:47PM, Carlos E. R. wrote:
On 2024-12-27 17:29, -pj via openSUSE Users wrote:
On 12-27-2024 06:27AM, Carlos E. R. wrote:
On 2024-12-27 08:02, -pj via openSUSE Users wrote:
I would like to change the USB mediums disk model 'STORE N GO' identity if possible (shown below).
# fdisk -l
Disk /dev/sdb: 57.77 GiB, 62025367552 bytes, 121143296 sectors Disk model: STORE N GO Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
I don't think so.
Ok thank you for that information.
Welcome :-)
But I don't see what relationship has that with dmsetup below.
I have changed this posts topic. Below is the /dev/mapper name that I would like to set persistently for the usb medium "Transit-Medium".
# dmsetup rename /dev/mapper/sdb_crypt Transit-Medium Was able to create a new mapper name:
Disk /dev/mapper/Transit-Medium: 57.75 GiB, 62008590336 bytes, 121110528 sectors 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: dos Disk identifier: 0x00000000
The /dev/mapper/Transit-Medium name I have now found to not be persistent, across powercycles. The mapper name has now reverted to /dev/mapper/luks-742dde43-08d7-4e4f-bce7-624c79bfb02b Which I believe to be a UUID? It's actually quite trivial most likely.
In order to have a persistent name of "Transit-Medium" set. Would editing fstab be in order?
No, /etc/crypttab.
#/dev/mapper/name device or file none options
Transit-Medium /dev/disk/by-uuid/742dde43 none auto
Notice that there is sort of convention to use names such as "cr_...", but the name is actually arbitrary.
I noticed.
Mind: I am unsure of the options, and whether also editing fstab is necessary, but I hope you can test this and find out ;-)
Thank you, I am testing.🥶
'device' can be of several forms:
/dev/disk/by-id/ata-ST3500418... /dev/disk/by-uuid/4b87dd41... /dev/disk/by-partuuid/66a96652... /dev/disk/by-partlabel/Jz2-...
Ok, I am unsure of the example forms mentioned above except for some of item two currently.
UUID=f1f26736-... Not recognized when I tried. Might work now. [...] I have a note that YaST created such syntax once for me, so I guess it should work.
Can you elaborate on how to use YaST to achieve this? So far, I have added to /etc/crypttab the following entry after backing up /etc/crypttab to /etc/crypttab.bak . Transit-Medium /dev/disk/by-uuid/742dde43-08d7-4e4f-bce7-624c79bfb02b none auto Updated dracut with < dracut --regenerate-all --force 1. After powercycling (with usb medium unplugged)...Message of < A start job is running for 1 minute 30 seconds.... is displayed. . ..after that boot continues rapidly. 2. After powercycling (with usb medium plugged)... boot messsege output is halted and a Message is displayed < Enter Transit-Medium passphrase > Once Transit-Medium passphrase is entered boot continues rapidly. Either of the two scenerios above result in a KDE console box asking for the LUKS passphrase yet again (when gui mount is attempted via systray). Regardless of if the usb medium is attached prior to boot or after boot has completed without usb medium attached. 1. lsblk -fs displays the following (after being mounted): Transit-Medium exfat 1.0 Explorer 6FFE-D844 53.1G 8% /run/media/paul/Explorer └─sdb crypto_LUKS 2 742dde43-08d7-4e4f-bce7-624c79bfb02b 2. lsblk -fs displays the following (after being unmounted): └─sda2 crypto_LUKS 1 d095bece-13e0-47ca-b2a9-f6119d3989fc └─sda Which UUID should I be attempting to use in (/etc/crypttab)? From experience now the first (1, see below). Do you know what 6FFE-D844 to the right of the label Explorer is (it must be one of the three remaining examples from your notes above)? So this *halting* behavior during boot is maybe similar to if < dmsetup rename old_name arbitrary_name > is used without updating dracut afterwards in a way, (because a LUKS passphrase is then asked twice) through boot process. Once before boot menu (after post) and once in the middle of boot messages (traces?) displayed. Could a possible issue be in the crypttab entry that has been appended? Transit-Medium /dev/disk/by-uuid/742dde43 none auto "none" or "auto" could be incorrect? I have attempted the following entry in /etc/crypttab and regenerated initrd with *worse* results. Transit-Medium /dev/disk/by-uuid/d095bece-13e0-47ca-b2a9-f6119d3989fc none auto As per second example 2. above. Result: The passphrase for the Main SSD is also then asked as well as passphrase for usb medium is asked. I do hope this is not to lengthy and ill written, I may just go back to default. I believe it was worth an attempted to provide this information for review. -Thanks

On 2024-12-28 03:09, -pj via openSUSE Users wrote:
On 12-27-2024 03:47PM, Carlos E. R. wrote:
On 2024-12-27 17:29, -pj via openSUSE Users wrote:
...
Mind: I am unsure of the options, and whether also editing fstab is necessary, but I hope you can test this and find out ;-)
Thank you, I am testing.🥶
'device' can be of several forms:
/dev/disk/by-id/ata-ST3500418... /dev/disk/by-uuid/4b87dd41... /dev/disk/by-partuuid/66a96652... /dev/disk/by-partlabel/Jz2-...
Ok, I am unsure of the example forms mentioned above except for some of item two currently.
UUID=f1f26736-... Not recognized when I tried. Might work now. [...] I have a note that YaST created such syntax once for me, so I guess it should work.
Can you elaborate on how to use YaST to achieve this?
The YaST partitioner can create encrypted partitions or disks. When doing so, it writes entries to /etc/crypttab and fstab.
So far, I have added to /etc/crypttab the following entry after backing up /etc/crypttab to /etc/crypttab.bak .
You don't need a backup copy of the file, you are just writing a line. To restore the status, just comment oout or delete the new line :-)
Transit-Medium /dev/disk/by-uuid/742dde43-08d7-4e4f-bce7-624c79bfb02b none auto
Updated dracut with < dracut --regenerate-all --force
Does nothing for this case.
1. After powercycling (with usb medium unplugged)...Message of < A start job is running for 1 minute 30 seconds.... is displayed. . ..after that boot continues rapidly.
2. After powercycling (with usb medium plugged)... boot messsege output is halted and a Message is displayed < Enter Transit-Medium passphrase > Once Transit-Medium passphrase is entered boot continues rapidly.
Right. This is expected, now that I think. In the first case, the system waits for the appearance of /dev/disk/by-uuid/742dde43-08d7-4e4f-bce7-624c79bfb02b that you declared. In the second case, it sees it and asks for the password. Option "noauto" might correct this.
Either of the two scenerios above result in a KDE console box asking for the LUKS passphrase yet again (when gui mount is attempted via systray). Regardless of if the usb medium is attached prior to boot or after boot has completed without usb medium attached.
This is unfortunate. Seems that KDE ignores the crypttab file.
1. lsblk -fs displays the following (after being mounted): Transit-Medium exfat 1.0 Explorer 6FFE-D844 53.1G 8% /run/media/paul/Explorer └─sdb crypto_LUKS 2 742dde43-08d7-4e4f-bce7-624c79bfb02b
2. lsblk -fs displays the following (after being unmounted): └─sda2 crypto_LUKS 1 d095bece-13e0-47ca-b2a9-f6119d3989fc └─sda
Which UUID should I be attempting to use in (/etc/crypttab)? From experience now the first (1, see below).
None, the uuid is correct as you wrote it above (742dde43-08d7-...). lsblk sees the device as sdb, not as uuid. After the crypto is decrypted it also sees the uuid of the device inside the crypto.
Do you know what 6FFE-D844 to the right of the label Explorer is (it must be one of the three remaining examples from your notes above)?
I might if you manage to impede the line wrap and I could see the label headers in the first line of lsblk output ;-) But it seems a Windows created identification. Explorer could be the label.
So this *halting* behavior during boot is maybe similar to if < dmsetup rename old_name arbitrary_name > is used without updating dracut afterwards in a way, (because a LUKS passphrase is then asked twice) through boot process. Once before boot menu (after post) and once in the middle of boot messages (traces?) displayed.
Could a possible issue be in the crypttab entry that has been appended? Transit-Medium /dev/disk/by-uuid/742dde43 none auto "none" or "auto" could be incorrect?
noauto should tell it not to try. But then you have to mount it manually when you wish to.
I have attempted the following entry in /etc/crypttab and regenerated initrd with *worse* results.
Transit-Medium /dev/disk/by-uuid/d095bece-13e0-47ca-b2a9-f6119d3989fc none auto
The uuid is wrong. Well, rather I don't know where it comes from. The UUID in crypttab has to be that of the raw device before being mounted.
As per second example 2. above.
Result: The passphrase for the Main SSD is also then asked as well as passphrase for usb medium is asked.
I do hope this is not to lengthy and ill written, I may just go back to default. I believe it was worth an attempted to provide this information for review.
You could ignore KDE and mount the device manually, with correct entries both in crypttab and fstab. You have to learn the commands for manual mount, or I can pass you the scripts that I use. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

On 12-28-2024 07:47AM, Carlos E. R. wrote:
On 2024-12-28 03:09, -pj via openSUSE Users wrote:
On 12-27-2024 03:47PM, Carlos E. R. wrote:
On 2024-12-27 17:29, -pj via openSUSE Users wrote:
...
Mind: I am unsure of the options, and whether also editing fstab is necessary, but I hope you can test this and find out ;-)
Thank you, I am testing.🥶
'device' can be of several forms:
/dev/disk/by-id/ata-ST3500418... /dev/disk/by-uuid/4b87dd41... /dev/disk/by-partuuid/66a96652... /dev/disk/by-partlabel/Jz2-...
Ok, I am unsure of the example forms mentioned above except for some of item two currently.
UUID=f1f26736-... Not recognized when I tried. Might work now. [...] I have a note that YaST created such syntax once for me, so I guess it should work.
Can you elaborate on how to use YaST to achieve this?
The YaST partitioner can create encrypted partitions or disks. When doing so, it writes entries to /etc/crypttab and fstab.
I have/had overlooked the possibility of using the "YaST partitioner" completely (:[). After using the YaST partition manager tool on, yet another usb medium, unmounted. Here is lsblk -fs output below (greyed out): NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdc1 crypto_LUKS 2 Transit-Medium 1ce85558-c759-4331-b8fc-00b2ec651cf3 └─sdc The following is now displayed by lsblk -fs after Transit-Medium (created by YaST partition manager) is mounted: cr_usb-Verbatim_STORE_N_GO_072136DA8095B519-0:0-part1 vfat FAT32 A8BC-9ED5 luks-1ce85558-c759-4331-b8fc-00b2ec651cf3 vfat FAT32 A8BC-9ED5 57.7G 0% /run/media/paul/A8BC-9ED5 └─sdc1 crypto_LUKS 2 Transit-Medium 1ce85558-c759-4331-b8fc-00b2ec651cf3 └─sdc ----------------- I do not believe any additional entries have been created in /etc/fstab when YaST partitioner performed the procedure on the usb medium displayed above: # cat /etc/fstab /dev/system/root / btrfs defaults 0 0 /dev/system/root /var btrfs subvol=/@/var 0 0 /dev/system/root /usr/local btrfs subvol=/@/usr/local 0 0 /dev/system/root /srv btrfs subvol=/@/srv 0 0 /dev/system/root /root btrfs subvol=/@/root 0 0 /dev/system/root /opt btrfs subvol=/@/opt 0 0 /dev/system/root /home btrfs subvol=/@/home 0 0 /dev/system/root /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0 /dev/system/root /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0 /dev/system/swap swap swap defaults 0 0 /dev/system/root /.snapshots btrfs subvol=/@/.snapshots 0 0 ----------------------- I do *not* believe any additional entries have been created in /etc/crypttab by use of YaST partition manager here either. # cat /etc/crypttab ... . output below is greyed out (attempted to 'paste as quote'). hightower-i5-6600k UUID=d095bece-13e0-47ca-b2a9-f6119d3989fc none x-initrd.attach # Transit-Medium /dev/disk/by-uuid/742dde43-08d7-4e4f-bce7-624c79bfb02b none auto ------------------
So far, I have added to /etc/crypttab the following entry after backing up /etc/crypttab to /etc/crypttab.bak .
You don't need a backup copy of the file, you are just writing a line. To restore the status, just comment oout or delete the new line :-)
Noted, thanks.🫥
Transit-Medium /dev/disk/by-uuid/742dde43-08d7-4e4f- bce7-624c79bfb02b none auto
Updated dracut with < dracut --regenerate-all --force
Does nothing for this case.
Ok, please see below for more thoughts on dracut regeneration.
1. After powercycling (with usb medium unplugged)...Message of < A start job is running for 1 minute 30 seconds.... is displayed. . ..after that boot continues rapidly.
2. After powercycling (with usb medium plugged)... boot messsege output is halted and a Message is displayed < Enter Transit-Medium passphrase > Once Transit-Medium passphrase is entered boot continues rapidly.
Right. This is expected, now that I think.
In the first case, the system waits for the appearance of /dev/disk/by- uuid/742dde43-08d7-4e4f-bce7-624c79bfb02b that you declared. In the second case, it sees it and asks for the password.
Option "noauto" might correct this.
Ok, I have not tried this.
Either of the two scenerios above result in a KDE console box asking for the LUKS passphrase yet again (when gui mount is attempted via systray). Regardless of if the usb medium is attached prior to boot or after boot has completed without usb medium attached.
This is unfortunate.
Yes it is.
Seems that KDE ignores the crypttab file.
Yes, and as you have said already a dracut regeneration is not necessary when modifying /etc/crypttab or /etc/fstab? I somewhat beg to differ because when using # dmsetup rename old_name new_name especially on a system bootable medium, dracut regeneration is necessary otherwise the LUKS passphrase will be asked twice and new dmsetup name will not *persist*.
1. lsblk -fs displays the following (after being mounted): Transit-Medium exfat 1.0 Explorer 6FFE-D844 53.1G 8% /run/media/paul/Explorer └─sdb crypto_LUKS 2 742dde43-08d7-4e4f-bce7-624c79bfb02b
2. lsblk -fs displays the following (after being unmounted): └─sda2 crypto_LUKS 1 d095bece-13e0-47ca-b2a9-f6119d3989fc └─sda
Which UUID should I be attempting to use in (/etc/crypttab)? From experience now the first (1, see below).
None, the uuid is correct as you wrote it above (742dde43-08d7-...). lsblk sees the device as sdb, not as uuid. After the crypto is decrypted it also sees the uuid of the device inside the crypto.
Do you know what 6FFE-D844 to the right of the label Explorer is (it must be one of the three remaining examples from your notes above)?
I might if you manage to impede the line wrap and I could see the label headers in the first line of lsblk output ;-)
Ok,🥶 I have attempted to "impede line wrap" by selecting Thunderbird > Edit > Settings > Composition > HTML Style > Then *Unticked* Use paragraph format instead of Body Text by default. Then I > Settings > Composition > Sending Format > *ticked* Only Plain Text. If this is incorrect, then how best to provide 'non-impeded line wrap'? while taking output from Konsole? An option I know of is to paste Konsole output as quote, but it's all greyed out then.?), I have been attempting to paste the output here (not as quote at first) and *now* as quote. The line wraps much to soon in the message which I intend to send. Using Thunderbird email client here. I'm going to create and attach a suse paste image to show this. Please see here: https://paste.opensuse.org/pastes/debd0562b1b1
------- Ok, so moving on, the label "Explorer" was a somewhat nonintuitive label which I designated while using Gparted to create and then label the filesystem inside the LUKS container (before my knowledge of YaST partition manager). This is lsblk -fs output with the "Explorer" medium unmounted (notice how the output below is dulled out, (pasted as quote): NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda1 └─sda sdc crypto_LUKS 2 742dde43-08d7-4e4f-bce7-624c79bfb02b - This is output of lsblk -fs when "Explorer" medium is mounted (trying to paste as quote the (output is dulled out as above). NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS cr_usb-Verbatim_STORE_N_GO_072136DA8095B519-0:0-part1 vfat FAT32 A8BC-9ED5 luks-742dde43-08d7-4e4f-bce7-624c79bfb02b exfat 1.0 Explorer 6FFE-D844 └─sdc crypto_LUKS 2 742dde43-08d7-4e4f-bce7-624c79bfb02b
But it seems a Windows created identification. Explorer could be the label.
I know but it is not, see above for explanation of Explorer label used here.
So this *halting* behavior during boot is maybe similar to if < dmsetup rename old_name arbitrary_name > is used without updating dracut afterwards in a way, (because a LUKS passphrase is then asked twice) through boot process. Once before boot menu (after post) and once in the middle of boot messages (traces?) displayed.
Could a possible issue be in the crypttab entry that has been appended? Transit-Medium /dev/disk/by-uuid/742dde43 none auto "none" or "auto" could be incorrect?
noauto should tell it not to try. But then you have to mount it manually when you wish to.
I have attempted the following entry in /etc/crypttab and regenerated initrd with *worse* results.
Transit-Medium /dev/disk/by-uuid/d095bece-13e0-47ca-b2a9-f6119d3989fc none auto
The uuid is wrong. Well, rather I don't know where it comes from.
The UUID in crypttab has to be that of the raw device before being mounted.
As per second example 2. above.
Result: The passphrase for the Main SSD is also then asked as well as passphrase for usb medium is asked.
I do hope this is not to lengthy and ill written, I may just go back to default. I believe it was worth an attempted to provide this information for review.
You could ignore KDE and mount the device manually, with correct entries both in crypttab and fstab. You have to learn the commands for manual mount, or I can pass you the scripts that I use.
You are correct in your assumption of my inability to issue the correct commands for "manual mount". I may be interested in utilizing the scripts which you have. I am not familiar with them in any means. Thank you kindly for your help with this also. -Best Regards

On 2024-12-28 21:40, -pj via openSUSE Users wrote:
On 12-28-2024 07:47AM, Carlos E. R. wrote:
On 2024-12-28 03:09, -pj via openSUSE Users wrote:
On 12-27-2024 03:47PM, Carlos E. R. wrote:
On 2024-12-27 17:29, -pj via openSUSE Users wrote:
...
UUID=f1f26736-... Not recognized when I tried. Might work now. [...] I have a note that YaST created such syntax once for me, so I guess it should work.
Can you elaborate on how to use YaST to achieve this?
The YaST partitioner can create encrypted partitions or disks. When doing so, it writes entries to /etc/crypttab and fstab.
I have/had overlooked the possibility of using the "YaST partitioner" completely (:[). After using the YaST partition manager tool on, yet another usb medium, unmounted. Here is lsblk -fs output below (greyed out):
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdc1 crypto_LUKS 2 Transit-Medium 1ce85558-c759-4331-b8fc-00b2ec651cf3 └─sdc
Please add this addon to your Thunderbird: Toggle Line Wrap Author Jan Kiszka Use the button to impede line wrap when posting such content with long lines so that we can read them correctly. Caveat: It wants a delicate permission to give. Too powerful. Alternatively, as you mentioned, use html and preformat.
The following is now displayed by lsblk -fs after Transit-Medium (created by YaST partition manager) is mounted:
cr_usb-Verbatim_STORE_N_GO_072136DA8095B519-0:0-part1 vfat FAT32 A8BC-9ED5 luks-1ce85558-c759-4331-b8fc-00b2ec651cf3 vfat FAT32 A8BC-9ED5 57.7G 0% /run/media/paul/A8BC-9ED5 └─sdc1 crypto_LUKS 2 Transit-Medium 1ce85558-c759-4331-b8fc-00b2ec651cf3 └─sdc
----------------- I do not believe any additional entries have been created in /etc/fstab when YaST partitioner performed the procedure on the usb medium displayed above:
# cat /etc/fstab
/dev/system/root / btrfs defaults 0 0 /dev/system/root /var btrfs subvol=/@/var 0 0 /dev/system/root /usr/local btrfs subvol=/@/usr/local 0 0 /dev/system/root /srv btrfs subvol=/@/srv 0 0 /dev/system/root /root btrfs subvol=/@/root 0 0 /dev/system/root /opt btrfs subvol=/@/opt 0 0 /dev/system/root /home btrfs subvol=/@/home 0 0 /dev/system/root /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0 /dev/system/root /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0 /dev/system/swap swap swap defaults 0 0 /dev/system/root /.snapshots btrfs subvol=/@/.snapshots 0 0 ----------------------- I do *not* believe any additional entries have been created in /etc/crypttab by use of YaST partition manager here either.
# cat /etc/crypttab ... . output below is greyed out (attempted to 'paste as quote').
hightower-i5-6600k UUID=d095bece-13e0-47ca-b2a9-f6119d3989fc none x-initrd.attach # Transit-Medium /dev/disk/by-uuid/742dde43-08d7-4e4f-bce7-624c79bfb02b none auto ------------------
Interesting.
So far, I have added to /etc/crypttab the following entry after backing up /etc/crypttab to /etc/crypttab.bak .
You don't need a backup copy of the file, you are just writing a line. To restore the status, just comment oout or delete the new line :-)
Noted, thanks.🫥
Transit-Medium /dev/disk/by-uuid/742dde43-08d7-4e4f- bce7-624c79bfb02b none auto
Updated dracut with < dracut --regenerate-all --force
Does nothing for this case.
Ok, please see below for more thoughts on dracut regeneration.
Dracut is necessary when the filesystem you created is needed to mount very early on boot. This is not the case, it is an external disk on usb, I understand. It is fine if mounted later by systemd.
1. After powercycling (with usb medium unplugged)...Message of < A start job is running for 1 minute 30 seconds.... is displayed. . ..after that boot continues rapidly.
2. After powercycling (with usb medium plugged)... boot messsege output is halted and a Message is displayed < Enter Transit-Medium passphrase > Once Transit-Medium passphrase is entered boot continues rapidly.
Right. This is expected, now that I think.
In the first case, the system waits for the appearance of /dev/disk/by- uuid/742dde43-08d7-4e4f-bce7-624c79bfb02b that you declared. In the second case, it sees it and asks for the password.
Option "noauto" might correct this.
Ok, I have not tried this.
Either of the two scenerios above result in a KDE console box asking for the LUKS passphrase yet again (when gui mount is attempted via systray). Regardless of if the usb medium is attached prior to boot or after boot has completed without usb medium attached.
This is unfortunate.
Yes it is.
Seems that KDE ignores the crypttab file.
Yes, and as you have said already a dracut regeneration is not necessary when modifying /etc/crypttab or /etc/fstab? I somewhat beg to differ because when using # dmsetup rename old_name new_name especially on a system bootable medium, dracut regeneration is necessary otherwise the LUKS passphrase will be asked twice and new dmsetup name will not *persist*.
Eventually, dracut will be run. You do not even need to reboot to mount external media, but you are testing what happens at boot time.
>> 1.
lsblk -fs displays the following (after being mounted): Transit-Medium exfat 1.0 Explorer 6FFE-D844 53.1G 8% /run/media/paul/Explorer └─sdb crypto_LUKS 2 742dde43-08d7-4e4f-bce7-624c79bfb02b
2. lsblk -fs displays the following (after being unmounted): └─sda2 crypto_LUKS 1 d095bece-13e0-47ca-b2a9-f6119d3989fc └─sda
Which UUID should I be attempting to use in (/etc/crypttab)? From experience now the first (1, see below).
None, the uuid is correct as you wrote it above (742dde43-08d7-...). lsblk sees the device as sdb, not as uuid. After the crypto is decrypted it also sees the uuid of the device inside the crypto.
Do you know what 6FFE-D844 to the right of the label Explorer is (it must be one of the three remaining examples from your notes above)?
I might if you manage to impede the line wrap and I could see the label headers in the first line of lsblk output ;-)
Ok,🥶 I have attempted to "impede line wrap" by selecting Thunderbird > Edit > Settings > Composition > HTML Style > Then *Unticked* Use paragraph format instead of Body Text by default.
Did not work because the posting was sent as plain text when sending. This is controlled in Options/Sending format. Trick: press shift key, then click on "reply to list". The composer will start in the "other" mode. If normal is plain text, this time it will start in html mode. Trick 2: When posting in html, the correct format to use to send computer output is "preformat", which is equivalent to "code". It uses a fixed width font and no wrap. Or, you can use the line wrap on/off button I mentioned above.
Then I > Settings > Composition > Sending Format > *ticked* Only Plain Text.
Ah. Yeah, it converts to plain text and destroys the paragraph formatting. Unfortunate.
If this is incorrect, then how best to provide 'non-impeded line wrap'? while taking output from Konsole? An option I know of is to paste Konsole output as quote, but it's all greyed out then.?), I have been attempting to paste the output here (not as quote at first) and *now* as quote. The line wraps much to soon in the message which I intend to send. Using Thunderbird email client here. I'm going to create and attach a suse paste image to show this.
Yeah. Or, attach to the email as text, is another possibility.
Please see here: https://paste.opensuse.org/pastes/debd0562b1b1
------- Ok, so moving on, the label "Explorer" was a somewhat nonintuitive label which I designated while using Gparted to create and then label the filesystem inside the LUKS container (before my knowledge of YaST partition manager).
This is lsblk -fs output with the "Explorer" medium unmounted (notice how the output below is dulled out, (pasted as quote):
Did not work, I'm editing it.
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda1 └─sda sdc crypto_LUKS 2 742dde43-08d7-4e4f-bce7-624c79bfb02b
- This is output of lsblk -fs when "Explorer" medium is mounted (trying to paste as quote the (output is dulled out as above). NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS cr_usb-Verbatim_STORE_N_GO_072136DA8095B519-0:0-part1 vfat FAT32 A8BC-9ED5 luks-742dde43-08d7-4e4f-bce7-624c79bfb02b exfat 1.0 Explorer 6FFE-D844 └─sdc crypto_LUKS 2 742dde43-08d7-4e4f-bce7-624c79bfb02b
But it seems a Windows created identification. Explorer could be the label.
I know but it is not, see above for explanation of Explorer label used here.
Right.
So this *halting* behavior during boot is maybe similar to if < dmsetup rename old_name arbitrary_name > is used without updating dracut afterwards in a way, (because a LUKS passphrase is then asked twice) through boot process. Once before boot menu (after post) and once in the middle of boot messages (traces?) displayed.
Could a possible issue be in the crypttab entry that has been appended? Transit-Medium /dev/disk/by-uuid/742dde43 none auto "none" or "auto" could be incorrect?
noauto should tell it not to try. But then you have to mount it manually when you wish to.
I have attempted the following entry in /etc/crypttab and regenerated initrd with *worse* results.
Transit-Medium /dev/disk/by-uuid/d095bece-13e0-47ca-b2a9-f6119d3989fc none auto
The uuid is wrong. Well, rather I don't know where it comes from.
The UUID in crypttab has to be that of the raw device before being mounted.
As per second example 2. above.
Result: The passphrase for the Main SSD is also then asked as well as passphrase for usb medium is asked.
I do hope this is not to lengthy and ill written, I may just go back to default. I believe it was worth an attempted to provide this information for review.
You could ignore KDE and mount the device manually, with correct entries both in crypttab and fstab. You have to learn the commands for manual mount, or I can pass you the scripts that I use.
You are correct in your assumption of my inability to issue the correct commands for "manual mount". I may be interested in utilizing the scripts which you have. I am not familiar with them in any means. Thank you kindly for your help with this also.
https://paste.opensuse.org/pastes/d4235ce348f0 Expand in /usr/local/bin using "tar -xvzf crypto.tgz". It is just a script and links to it: lrwxrwxrwx 1 root root 12 Jul 3 2013 crypto_ -> crypto_mount* lrwxrwxrwx 1 root root 12 Jul 3 2013 crypto_fsck -> crypto_mount* lrwxrwxrwx 1 root root 12 Jul 3 2013 crypto_info -> crypto_mount* lrwxrwxrwx 1 root root 12 Jul 3 2013 crypto_lst -> crypto_mount* lrwxrwxrwx 1 root root 12 Jul 3 2013 crypto_map -> crypto_mount* -rwxr-xr-- 1 root medios 8123 Jul 19 2016 crypto_mount* lrwxrwxrwx 1 root root 12 Jul 3 2013 crypto_sinfo -> crypto_mount* lrwxrwxrwx 1 root root 12 Jul 3 2013 crypto_umount -> crypto_mount* lrwxrwxrwx 1 root root 12 Jul 3 2013 crypto_unmap -> crypto_mount* I hope the names are self explanatory. As I wrote it for myself, some of the comments inside are in Spanish. If you need to read them, I'll rewrite in English. I don't remember if the script works only as root, or maybe as user. I use it as root. You need to create entries in crypttab like this: cr_Aux_01 /dev/disk/by-uuid/..... none noauto ^ arbitrary In /etc/fstab: /dev/mapper/cr_Aux_01 /data/aux_01 xfs noauto,nofail,lazytime 1 6 You can change the names and options, but they have to match across the two files. The above is a combination I use on external disks. My script doesn't cover all cases; for instance: ##cr_RescueLegolas UUID=3804e2da-f4a4-4c26-9121-d763dd8f736e none timeout=300,discard doesn't work. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
participants (2)
-
-pj
-
Carlos E. R.