[lfs-support] Creating initial partition when disk names not persistent

[Theodore Driscoll]

--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

[Ken Moffat]

Hi
my daily-use machine runs openSuse. To experiment with LFS I added a
second SATA HDD.
Initially the Suse drive was /dev/sda, the new, unpartitioned, drive
/dev/sdb.
But I rebooted once more. Now Suse has swapped the names, so what used to
be /dev/sda is now /dev/sdb and vice-versa. If I reboot again, the names
sometimes swap back, sometimes do not.
Section 2.4, Creating a New Partition, doesn't allow for this situation -
it assumes the drive names are persistent.
Has anyone else encountered this situation, and found a way around it?
Cheers
Ted

I've never seen an _internal_ drive change its device across reboots
on the same kernel, except when other internal drives were added or
removed. And in that situation the device names persist for as long
as "this drive is plugged in here, that drive is plugged in there".

Hmm, I suppose it is possible if all the drivers are on an initrd
(most distros, including Suse) and there is some variability in
timings - but it seems unlikely.

So I guess that this is an external drive ? If so, expect pain when
you complete LFS and try to boot an external drive from grub.

With Suse, I assume it mounts by UUID - but I've been able to avoid
that approach on my own systems (I think there are two variants of
UUID-style, only one of which is supported without an initrd - and
LFS doesn't use initrds.)

For ext4, you might be able to use e2label to label the LFS
filesystem, and then mount with label= instead of /dev/sdXN. But
I'm not sure about how well that would work when you finish LFS and
try to boot it, if you have other partitions which you wish to mount
on the Suse drive (e.g. /boot, /home) and it won't work for swap.

But I'm sure somebody will be able to offer details on the variants
of UUID mounting and how to fix your problem. In the meantime,
"patience, and good luck!".

ĸen
--
Is it about a bicycle ?
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wiki

[Bruce Dubbs]

Post by Ken Moffat

Hi
my daily-use machine runs openSuse. To experiment with LFS I added a
second SATA HDD.
Initially the Suse drive was /dev/sda, the new, unpartitioned, drive
/dev/sdb.
But I rebooted once more. Now Suse has swapped the names, so what used to
be /dev/sda is now /dev/sdb and vice-versa. If I reboot again, the names
sometimes swap back, sometimes do not.
Section 2.4, Creating a New Partition, doesn't allow for this situation -
it assumes the drive names are persistent.
Has anyone else encountered this situation, and found a way around it?
Cheers
Ted

I've never seen an _internal_ drive change its device across reboots
on the same kernel, except when other internal drives were added or
removed. And in that situation the device names persist for as long
as "this drive is plugged in here, that drive is plugged in there".
Hmm, I suppose it is possible if all the drivers are on an initrd
(most distros, including Suse) and there is some variability in
timings - but it seems unlikely.
So I guess that this is an external drive ? If so, expect pain when
you complete LFS and try to boot an external drive from grub.
With Suse, I assume it mounts by UUID - but I've been able to avoid
that approach on my own systems (I think there are two variants of
UUID-style, only one of which is supported without an initrd - and
LFS doesn't use initrds.)
For ext4, you might be able to use e2label to label the LFS
filesystem, and then mount with label= instead of /dev/sdXN. But
I'm not sure about how well that would work when you finish LFS and
try to boot it, if you have other partitions which you wish to mount
on the Suse drive (e.g. /boot, /home) and it won't work for swap.
But I'm sure somebody will be able to offer details on the variants
of UUID mounting and how to fix your problem. In the meantime,
"patience, and good luck!".

I agree with Ken. I've never had the drive order change for internal
SATA (or older SCSI or IDE) drives. USB drives, yes. I'm not sure
about SATA, but for the older SCSI drive the order was determined by HW.
I suspect the same for SATA.

It is usually possible to change the boot drive in most system firmware.

The way to ensure that GRUB loads the correct root file system is to use
PARTUUID=<uuid> on the kernel command line. No initrd is required but a
GUID Partition Table (GPT) is required. Most distros use filesystem
UUIDs, but that requires an initrd.

Booting to a USB drive may require rootdelay=10 on the kernel command line.

-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wi

[Richard Melville]

Post by Ken Moffat

Hi
my daily-use machine runs openSuse. To experiment with LFS I added a
second SATA HDD.
Initially the Suse drive was /dev/sda, the new, unpartitioned,

drive

Post by Ken Moffat

/dev/sdb.
But I rebooted once more. Now Suse has swapped the names, so what

used to

Post by Ken Moffat

be /dev/sda is now /dev/sdb and vice-versa. If I reboot again, the

names

Post by Ken Moffat

sometimes swap back, sometimes do not.
Section 2.4, Creating a New Partition, doesn't allow for this

situation -

Post by Ken Moffat

it assumes the drive names are persistent.
Has anyone else encountered this situation, and found a way around

it?

Post by Ken Moffat

Cheers
Ted

I've never seen an _internal_ drive change its device across reboots
on the same kernel, except when other internal drives were added or
removed. And in that situation the device names persist for as long
as "this drive is plugged in here, that drive is plugged in there".
Hmm, I suppose it is possible if all the drivers are on an initrd
(most distros, including Suse) and there is some variability in
timings - but it seems unlikely.
So I guess that this is an external drive ? If so, expect pain when
you complete LFS and try to boot an external drive from grub.
With Suse, I assume it mounts by UUID - but I've been able to avoid
that approach on my own systems (I think there are two variants of
UUID-style, only one of which is supported without an initrd - and
LFS doesn't use initrds.)
For ext4, you might be able to use e2label to label the LFS
filesystem, and then mount with label= instead of /dev/sdXN. But
I'm not sure about how well that would work when you finish LFS and
try to boot it, if you have other partitions which you wish to mount
on the Suse drive (e.g. /boot, /home) and it won't work for swap.
But I'm sure somebody will be able to offer details on the variants
of UUID mounting and how to fix your problem. In the meantime,
"patience, and good luck!".

I agree with Ken. I've never had the drive order change for internal
SATA (or older SCSI or IDE) drives. USB drives, yes. I'm not sure
about SATA, but for the older SCSI drive the order was determined by HW.
I suspect the same for SATA.
It is usually possible to change the boot drive in most system firmware.
The way to ensure that GRUB loads the correct root file system is to use
PARTUUID=<uuid> on the kernel command line. No initrd is required but a
GUID Partition Table (GPT) is required. Most distros use filesystem
UUIDs, but that requires an initrd.
Booting to a USB drive may require rootdelay=10 on the kernel command line.

If using gdisk a label can also be applied at the same time as partitioning.

Richard

[Bruce Dubbs]

Post by Ken Moffat

     Hi
     my daily-use machine runs openSuse. To experiment with LFS I

added a

Post by Ken Moffat

     second SATA HDD.
     Initially the Suse  drive was /dev/sda, the new,

unpartitioned, drive

Post by Ken Moffat

     /dev/sdb.
     But I rebooted once more. Now Suse has swapped the names, so

what used to

Post by Ken Moffat

     be /dev/sda is now /dev/sdb and vice-versa. If I reboot

again, the names

Post by Ken Moffat

     sometimes swap back, sometimes do not.
     Section 2.4, Creating a New Partition, doesn't allow for

this situation -

Post by Ken Moffat

     it assumes the drive names are persistent.
     Has anyone else encountered this situation, and found a way

around it?

Post by Ken Moffat

     Cheers
     Ted

I've never seen an _internal_ drive change its device across reboots
on the same kernel, except when other internal  drives were added or
removed.  And in that situation the device names persist for as long
as "this drive is plugged in here, that drive is plugged in there".
Hmm, I suppose it is possible if all the drivers are on an initrd
(most distros, including Suse) and there is some variability in
timings - but it seems unlikely.
So I guess that this is an external drive ?  If so, expect pain when
you complete LFS and try to boot an external drive from grub.
With Suse, I assume it mounts by UUID - but I've been able to avoid
that approach on my own systems (I think there are two variants of
UUID-style, only one of which is supported without an initrd - and
LFS doesn't use initrds.)
For ext4, you might be able to use e2label to label the LFS
filesystem, and then mount with label= instead of /dev/sdXN.  But
I'm not sure about how well that would work when you finish LFS and
try to boot it, if you have other partitions which you wish to mount
on the Suse drive (e.g. /boot, /home) and it won't work for swap.
But I'm sure somebody will be able to offer details on the variants
of UUID mounting and how to fix your problem.  In the meantime,
"patience, and good luck!".

I agree with Ken.  I've never had the drive order change for internal
SATA (or older SCSI or IDE) drives.  USB drives, yes.  I'm not sure
about SATA, but for the older SCSI drive the order was determined by HW.
  I suspect the same for SATA.
It is usually possible to change the boot drive in most system firmware.
The way to ensure that GRUB loads the correct root file system is to use
PARTUUID=<uuid> on the kernel command line.  No initrd is required
but a
GUID Partition Table (GPT) is required.  Most distros use filesystem
UUIDs, but that requires an initrd.
Booting to a USB drive may require rootdelay=10 on the kernel command line.
If using gdisk a label can also be applied at the same time as partitioning.

I'm pretty sure that using the partition table for the root filesystem
also requires and initrd. There is no problem using it in the fstab though.

-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http:

[William Harrington]

Hi
my daily-use machine runs openSuse. To experiment with LFS I added a
second SATA HDD.
Initially the Suse drive was /dev/sda, the new, unpartitioned, drive
/dev/sdb.
But I rebooted once more. Now Suse has swapped the names, so what used
to be /dev/sda is now /dev/sdb and vice-versa. If I reboot again, the
names sometimes swap back, sometimes do not.
Section 2.4, Creating a New Partition, doesn't allow for this
situation - it assumes the drive names are persistent.
Has anyone else encountered this situation, and found a way around it?
Cheers
Ted

Hello Ted,

Is it possible that the first hard drive was in SATA port1 (or however
your motherboard labels them) rather than port0, and when you added the
second drive it was in port0, so when the drives are enumerated by the
system that the port0 drive is now sda, and the port1 drive which you
used all this time is now sdb?

What happens if you swap the SATA cables between the two drives or the
two motherboard SATA ports?

Sincerely,

William Harrington
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.w

[Michael Shell]

On Sun, 7 Oct 2018 07:25:55 +0200

But I rebooted once more. Now Suse has swapped the names, so what used
to be /dev/sda is now /dev/sdb and vice-versa. If I reboot again, the
names sometimes swap back, sometimes do not.

The kernel developers insist that the kernal assigned /dev/sdx names are
not to be considered persistent even for a constant hardware configuration.
Although it certainly is unusual for internal SATA drives to change between
boots (BIOS behavior?) it is not guaranteed that such names won't ever change
between boots.

So, reference the drives using their PARTUUID. The kernel understands this
referencing method natively and will not require any initramfs.

You can see the PARTUUID of all the drives via:

lsblk -o NAME,FSTYPE,PARTUUID

e.g., 7b01c1ac-a7b2-4841-a36d-3a7eb46ed741

For the kernel command line and grub, the format to reference by PARTUUID
is:

root=PARTUUID=7b01c1ac-a7b2-4841-a36d-3a7eb46ed741

https://wiki.gentoo.org/wiki/GRUB

For fstab it is formatted like:

PARTUUID=7b01c1ac-a7b2-4841-a36d-3a7eb46ed741 / ext2 defaults 1 1

You will have to have a gdisk-created partition table for each partition
to be assigned a PARTUUID.

Note that you cannot use UUID at boot without an initramfs - as UUID's are
post-udev assigned things and will not be available to the kernel during
the initial boot process.


Cheers,

Mike Shell
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wi

[Bruce Dubbs]

Post by Michael Shell
You will have to have a gdisk-created partition table for each partition
to be assigned a PARTUUID.

Newer version of fdisk can create/mange GUID Partition Tables (GPTs),
but you have to go into expert mode to display the partition UUIDs.

-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.o