Difference between revisions of "Talk:Persistent block device naming"

From ArchWiki
Jump to: navigation, search
(Link to Grub feature request pertaining to disk by-id)
(does not work)
 
(31 intermediate revisions by 7 users not shown)
Line 1: Line 1:
Enabling persistent naming in /etc/fstab is easy, just replace the device name in the first column by the new persistent name. In my example I would replace /dev/sda7 by one of the following:
+
== systemd-boot entry with label ==
  
/dev/disk/by-label/home or
+
Should we add a systemd-boot entry using LABEL to the bottom section? --[[User:Betseg|Betseg]] ([[User talk:Betseg|talk]]) 15:17, 29 July 2015 (UTC)
/dev/disk/by-uuid/31f8eb0d-612b-4805-835e-0e6d8b8c5591
 
Do so for all the partitions in your fstab file.
 
  
 +
:Could do, but it might also be worthwhile to consider slim down that section and crosslink more instead. Or, as a first step, you could convert the LABEL example at the end to a systemd-boot one and crosslink it to [[Systemd-boot#Standard root installations]] for the additional info there. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:35, 29 July 2015 (UTC)
  
... is this really truely ?
+
::Plus, there is already [[Kernel parameters#Configuration]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:20, 30 July 2015 (UTC)
  
I have to use :
+
== <s>Using persistent naming > Boot managers</s> ==
  
UUID=31f8eb0d-612b-4805-835e-0e6d8b8c5591 /home
+
This is suggested:
  
or I understood somewhat wrongly.
+
root=/dev/disk/by-label/''root_myhost''
  
piwi
+
Alongside with:
  
 +
root=LABEL=root_myhost
  
----
+
According to https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader, this "naming" is expected by the cryptdevice kernel parameter of the cryptsetup mkinitcpio's hook.
 +
So I used a small variation on my computer:
  
:It works, yes. But I prefer LABEL over UUID:
+
cryptdevice=/dev/disk/by-partlabel/''root_myhost''
:<tt>LABEL=HOME-jfs /home nodev,nosuid,noatime 0 2</tt>
 
  
: --[[User:Byte|byte]] 08:19, 19 December 2006 (EST)
+
And once in a few reboots, cryptsetup's hook can't find the disk!
 +
However, the following, supposed to be equivalent, works fine:
  
 +
cryptdevice=PARTLABEL=''root_myhost''
  
----
+
So I suggest replacing every {{ic|/dev/disk/}} by either {{ic|PARTLABEL}}, {{ic|PARTUUID}}, {{ic|LABEL}} or {{ic|UUID}}, either in those examples, or here https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader.
  
Found this howto easy & very usefull :)
+
As reference, the function used by cryptsetup's hook to parse the cryptdevice parameter: https://git.archlinux.org/mkinitcpio.git/tree/init_functions#n325.
Have got a few HDDs & USBKeys that love to be (disk-label) mounted so easy but still a sure way (by easy i mean, compared to udev rules ;).
 
:--[[User:Kozaki|kozaki]] 15:19, 7 January 2007 (PST)
 
  
----
+
{{unsigned|17:53, 21 October 2017‎|Arshlinux}}
but I havn't this /dev/disk/by-label directary,why?
 
mawchmail@gmail.com
 
  
----
+
:[https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader This section] suggests {{ic|1=cryptdevice=UUID=<device-UUID>:cryptroot}}, not {{ic|1=cryptdevice=/dev/disk/by-uuid/<device-UUID>:cryptroot}}, so I don't see the point of your proposal. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:12, 21 October 2017 (UTC)
  
That's because that directory is actually created (and destroyed) '''''dynamically''''' when you attach (or detach) some disk or partition that has a label! A bit scary for the uninitiated, but true....
+
::Oh you are right, and because {{ic|1=PARTLABEL=}} was missing I must have used {{ic|/dev/disk/by-partlabel}} instead of {{ic|PARTLABEL}}. In this case I suggest adding {{ic|PARTLABEL}}, {{ic|PARTUUID}} and {{ic|LABEL}} to {{ic|UUID}} in [https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader this section]. -- [[User:Arshlinux|Arshlinux]] ([[User talk:Arshlinux|talk]]) 21:40, 21 October 2017 (UTC)
:--[[User:jf|jf]] 15:32, 29 March 2007 '''("Why couldn't everybody JUST use easily-referenced 'GMT', or 'UTC'?!!!")'''
 
  
== by-path and by-id unsuitable? ==
+
:::That section has one simple example using UUID and links to [[Persistent block device naming]] for the other options, so it should be solved on this page. I see that you've [https://wiki.archlinux.org/index.php?title=Persistent_block_device_naming&diff=next&oldid=483210 added an example], so let's close this. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:01, 22 October 2017 (UTC)
  
the article says by-path is unsuitable because it "contain[s] strings to indicate which subsystem they belong to (i.e. "-ide-", for 'by-path', and "ata-" for 'by-id')"
+
::Let me reformulate, as always, I carefully visit the wiki and I first read: {{Quote|{{bc|1=cryptdevice=''device'':''dmname''}}
  
How does that make it unsuitable? For by-path, that string is the same each boot, because the bus doesn't move (even if the buses get initialized in a different order) -- e.g. suppose you've got two SATA disks, on SATA connector #1 and #2 on your motherboard. #1 may become /dev/sda on one boot, and /dev/sdb the next time. Its by-path name won't change, though -- /dev/disk/by-path/sata-1 will point to /dev/sda in the first case and /dev/sdb in the second case, so it's persistent.
+
* {{ic|''device''}} is the path to the device backing the encrypted device. Usage of [[Persistent block device naming]] is advisable.|https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#cryptdevice}}
  
Furthermore, by-path is actually safer than by-label and by-uuid, because those rely on the disk data to identify the disk. Suppose you and a friend both named your boot drive "root". Your friend's power supply blows, so you plug his drive into your eSATA port to retrieve some data for him -- but oops, your system found his "root" label before yours, and suddenly you're trying to boot to the wrong disk. (I've actually tested this, and it can/does happen. It's most likely to happen when something is wrong, e.g. one of your drives is dying -- which is also when you least *want* it to happen.)
+
::and then on the linked page the following example: {{Quote|{{bc|1=root=/dev/disk/by-label/''root_myhost''}}|https://wiki.archlinux.org/index.php/Persistent_block_device_naming#Boot_managers}}
  
[[User:Thetrivialstuff|Thetrivialstuff]] 01:04, 13 August 2011 (EDT)
+
::So I write {{bc|1=cryptdevice=/dev/disk/by-partlabel/''root_myhost''}} instead of the only thing that works every boot, which is: {{bc|1=cryptdevice=PARTLABEL=''root_myhost''}}
  
: I am also confused by that statement in the article with respect to "by-id". E.g. elsewhere I see:
+
::We should mention it somewhere. -- [[User:Arshlinux|Arshlinux]] ([[User talk:Arshlinux|talk]]) 14:15, 22 October 2017 (UTC)
: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html
 
:: The World Wide Identifier (WWID) can be used in reliably identifying devices. It is a persistent, system-independent ID that the SCSI Standard requires from all SCSI devices. '''The WWID identifier is guaranteed to be unique for every storage device, and independent of the path that is used to access the device.'''
 
:: This identifier can be obtained by issuing a SCSI Inquiry to retrieve the Device Identification Vital Product Data (page 0x83) or Unit Serial Number (page 0x80). The mappings from these WWIDs to the current /dev/sd names can be seen in the symlinks maintained in the /dev/disk/by-id/ directory.
 
:: For example, a device with a page 0x83 identifier would have:
 
  
:: scsi-3600508b400105e210000900000490000 -> ../../sda
+
:::Yes, you have mentioned it [https://wiki.archlinux.org/index.php?title=Persistent_block_device_naming&diff=next&oldid=483210 here]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:42, 22 October 2017 (UTC)
  
:: Or, a device with a page 0x80 identifier would have:
+
::::I did not mention that {{ic|1=cryptdevice=/dev/disk/by-partlabel/root_myhost}} does not work though :) -- [[User:Arshlinux|Arshlinux]] ([[User talk:Arshlinux|talk]]) 20:23, 22 October 2017 (UTC)
 
 
:: scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda
 
 
 
:: Red Hat Enterprise Linux 5 automatically maintains the proper mapping from the WWID-based device name to a current /dev/sd name on that system. '''Applications can use the /dev/disk/by-id/ name to reference the data on the disk, even if the path to the device changes, and even when accessing the device from different systems. '''
 
: Am I missing something?
 
: [[User:Goulo|Goulo]] 04:42, 11 January 2012 (EST)
 
:: I don't know if this could be relevant, at least in the context of using by-id with GRUB on BIOS computers: https://savannah.gnu.org/bugs/index.php?35354#comment3 --[[User:Kit|Kit]] ([[User talk:Kit|talk]]) 17:49, 25 October 2012 (UTC)
 

Latest revision as of 20:23, 22 October 2017

systemd-boot entry with label

Should we add a systemd-boot entry using LABEL to the bottom section? --Betseg (talk) 15:17, 29 July 2015 (UTC)

Could do, but it might also be worthwhile to consider slim down that section and crosslink more instead. Or, as a first step, you could convert the LABEL example at the end to a systemd-boot one and crosslink it to Systemd-boot#Standard root installations for the additional info there. --Indigo (talk) 20:35, 29 July 2015 (UTC)
Plus, there is already Kernel parameters#Configuration. -- Lahwaacz (talk) 06:20, 30 July 2015 (UTC)

Using persistent naming > Boot managers

This is suggested:

root=/dev/disk/by-label/root_myhost

Alongside with:

root=LABEL=root_myhost

According to https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader, this "naming" is expected by the cryptdevice kernel parameter of the cryptsetup mkinitcpio's hook. So I used a small variation on my computer:

cryptdevice=/dev/disk/by-partlabel/root_myhost

And once in a few reboots, cryptsetup's hook can't find the disk! However, the following, supposed to be equivalent, works fine:

cryptdevice=PARTLABEL=root_myhost

So I suggest replacing every /dev/disk/ by either PARTLABEL, PARTUUID, LABEL or UUID, either in those examples, or here https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader.

As reference, the function used by cryptsetup's hook to parse the cryptdevice parameter: https://git.archlinux.org/mkinitcpio.git/tree/init_functions#n325.

—This unsigned comment is by Arshlinux (talk) 17:53, 21 October 2017‎. Please sign your posts with ~~~~!

This section suggests cryptdevice=UUID=<device-UUID>:cryptroot, not cryptdevice=/dev/disk/by-uuid/<device-UUID>:cryptroot, so I don't see the point of your proposal. -- Lahwaacz (talk) 18:12, 21 October 2017 (UTC)
Oh you are right, and because PARTLABEL= was missing I must have used /dev/disk/by-partlabel instead of PARTLABEL. In this case I suggest adding PARTLABEL, PARTUUID and LABEL to UUID in this section. -- Arshlinux (talk) 21:40, 21 October 2017 (UTC)
That section has one simple example using UUID and links to Persistent block device naming for the other options, so it should be solved on this page. I see that you've added an example, so let's close this. -- Lahwaacz (talk) 14:01, 22 October 2017 (UTC)
Let me reformulate, as always, I carefully visit the wiki and I first read:
cryptdevice=device:dmname
https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#cryptdevice


and then on the linked page the following example:
root=/dev/disk/by-label/root_myhost
https://wiki.archlinux.org/index.php/Persistent_block_device_naming#Boot_managers


So I write
cryptdevice=/dev/disk/by-partlabel/root_myhost
instead of the only thing that works every boot, which is:
cryptdevice=PARTLABEL=root_myhost
We should mention it somewhere. -- Arshlinux (talk) 14:15, 22 October 2017 (UTC)
Yes, you have mentioned it here. -- Lahwaacz (talk) 17:42, 22 October 2017 (UTC)
I did not mention that cryptdevice=/dev/disk/by-partlabel/root_myhost does not work though :) -- Arshlinux (talk) 20:23, 22 October 2017 (UTC)