You are not logged in.

#1 2021-10-17 17:09:02

Terence64w
Member
Registered: 2020-12-17
Posts: 29

Most reliable Disk-Identifier and Boot-Process

Hi,

I'm looking for the most reliable 'Disk-Identifier' to use in all new installations.

Apparently (see here) `/dev/disk/bu-id/` is assigned by kernel, hence not reliable.
The answer Nr. 27 propose to use `PARTUUID`.

I read also about using Serial-Number as disk-id (this used in FreeBSD).

Finally, as much I read as more I'm confused.

Can someone explain me which disk-identifier is the best and in case when will/can change?

GRUB don't recognize any other disk-identifier as his own (e.g. `hda0`), "rEFInd" have no (non GRUB) zfs-driver.

Which is the best bootloader also usable in systems without `systemd`?

Looking for simple qualified answer, thanks in advance.

Offline

#2 2021-10-17 20:50:27

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,650

Re: Most reliable Disk-Identifier and Boot-Process

All of the ones mentioned in that stack overflow are stable unless your partition layout changes significantly. See https://wiki.archlinux.org/title/Persis … ice_naming as well.

There's no bootloader that explicitly requires systemd, not even systemd-boot afaik. GRUB can and does use uuids by default which are stable as well.

This reads like an XY question why are you asking these questions in that way, what's your actual end goal?

Offline

#3 2021-10-18 17:42:40

Terence64w
Member
Registered: 2020-12-17
Posts: 29

Re: Most reliable Disk-Identifier and Boot-Process

V1del wrote:

All of the ones mentioned in that stack overflow are stable unless your partition layout changes significantly. See https://wiki.archlinux.org/title/Persis … ice_naming as well.

1. The link I posted prove the contrary, you can answer me that this "error/bug" is repaired or not happen in Arch but, you cannot say I'm laying. Besides, using *ubuntu and arch (not simultaneously/no dual-boot) on the same 'nvme' I got different '/dev/disk/by-id/' and I was wrong in my other thread.
2. Reading your linked article, the second link in the page leading me here. This advice me only that further "problems" can happen, for which an expert is needed to solve them. This don't really help to answer any question at all but tell me: "No btrfs and no zfs otherwise you get problems, most probably, you cannot solve by yourself and you need a second machine to investigate on the internet."
On one side is good to know the problem are documented and advised to the users (that reason why use Arch-Wiki), on the other side... no clear response on questions, no easy to find if the user don't open all links in the wiki and read these all.
3. Contrary answers, wikipedia and Arch-Wiki say `wwn` is unique, the link I posted and former thread of mine say no.
4. This regarding the industry but for user also interesting question: "Why nvme have no more `wwn`? HDD's have it, SATA-SSD have it, NVMe haven't. Maybe cause of lack of reliability, hence useless?|

V1del wrote:

There's no bootloader that explicitly requires systemd, not even systemd-boot afaik. GRUB can and does use uuids by default which are stable as well.

1. Yes, GRUB can and use root=UUID=0a3407de-014b-458b-b5c1-848e92a327a3 but not all OS's using GRUB do the same, a first search (grub supported disk-identifier) give me this. What does it mean? GRUB can dual-boot with Windows but badly with some other linuxes?
2. I don't ask explicitly for (30 years old) GRUB and not for SystemD-Boot because: GRUB apparently like a 'boot-partition' in ext2 (e.g. extra boot-partition by zfs-root) and don't support ZFS well, SystemD is not in all Linux-Distro (e.g. Artix, Devuan, Gento, etc.).
3. Do GRUB support "root=/dev/disk/by-id/wwn-0x60015ee0000b237f-part2" or still read only through`lsblk` which not contain `wwn`?

V1del wrote:

This reads like an XY question why are you asking these questions in that way, what's your actual end goal?

Well, if I ask a complicated question get answer like: "Post each question in one single thread, it is difficult to answer to complicated questions in one thread."
If I ask a simple question, see your quote.

I don't want to make this too complicated as it already is, hence here is my clear question:

Which disk-identifier will never change and which bootloader support such identifier and can boot every system, even with ZFS on it?

My goal is a system-wide id based on the disk and not on the partition type or kernel or kernel-module or lsblk, if I change something e.g. shrink a partition, replace it, install additional OS (multiboot), etc. all what I need to do is to change ID=0...F-part2 with part3, or add -part5 as additional entry, that's all. If I install an additional OS using the same EFI, /boot and swap.. no matter if "os-prober" on the first OS is installed or not, the second OS will delete everything else, hence the first os is no more bootlable. Example with no more bootable OS are in your same links. 

E.g. "FreeBSD" (can) use (also) serial number to make "Vdev" or "Zpool" but "TureNAS" next (actual Beta) "FreeNAS Scale" is"Debian"-based. Standard Debian have GRUB OS-Loader and SystemD Init, no RC (init), ZFS (file system in the kernel), ZBM (ZFS boot menu to start snapshots or other OS).

Please don't misunderstand me, my intention is not to criticize you personally or Arch or his wiki or the forum but, just would like to get one answer from expert-s:
YES: This ID is set by Disk-manufacturer, is on the disk no matter if encrypted or not and not depend on from file-system or kernel. Use this identifier and this loader, sample scripts here and here
NO: Is not yet a solution for this/that.

Why not yet done or who is responsible, or how should be implemented... that are all questions (or additional question) I don't care because:
1. Don't solve my problem.
2. Not motivating people working on it.
3. Even if I can help in solving the situation, nobody would listen to me.

Please don't take it personally but, giving me a couple of links I already read that state contradictory sentences that I already linked... don't help me at all, for not saying: It's not polite after I ask for qualified answer.
If you don't know the answer, is for me OK, I also don't know many things but, if you don't read my links (I post explicitly) or questions, and complain about my questions only and sending me back just links... than is "not polite" a mild expression. You just send the ball back to me, the user (me) put the wrong question, to simply question, to complicated question, cannot set a question, don't read the wiki, don't inform himself on other forums, what want to accomplish, with linux can you do what you want and if it's functioning make it, and so on and so fort.

My problem is: If I install and boot an Arch and/or an *ubuntu on my nvme I get different "/dev/disk/by-id/nvme-eui." if "/dev/disk/by-id/wwn-0x" is consistent, this not confirmed and nvme have no wwn. Grub (as you can see in my link) in some OS use UUID, where PARTUUID is recommended for encrypted disks, hence not for ZFS, and sometime use (30 years old) "hd0,1" plus UUID.

We still not know the truth about 'wwn', we still not know if grub or other loader can read 'wwn', we just have links (also yours) telling what sometimes don't work.
A sure solution is not indicated, nowhere.

I made neither a to complicated question nor a to simply one or the scope/target of achievement are not clear, the people having the same "problems" know the issues I expose with my links.

Offline

#4 2021-10-20 18:20:22

alysher
Member
Registered: 2017-07-31
Posts: 56

Re: Most reliable Disk-Identifier and Boot-Process

For all intents and purposes the only times you would likely see an ID change for a disk under UUID is if you repartition it, or purposely change the identifier. shrinking/expanding normally doesn't change the UUID.

Basically you have complete control of when and what the ID is, within some limitations.

if you are going for maximum compatibility between machines, I would use a GPT scheme with uuid. my two cents, but the entire choice will be up to you.


I started learning linux under Debian, and this is what I hope for every time I interact with the awesome Arch community.

Offline

Board footer

Powered by FluxBB