I'd like to try RasPiOS 64 bit on my 8 GB Pi4 as a preliminary
to migrating it from 32 bit to 64 bit. Does the new "first time
setup wizard" have the ability to manipulate partitions and
install from microSD onto a usb-connected hard drive?

I've kinda learned how to do that with FreeBSD and it's quite a
pain: Suppress growfs by renaming /firstboot, then get into single
user mode, muck around in gpart to add a swap partition, /usr partition
and finally copy contents of the old /usr directory to the new one.

This provides the traditional disk layout of boot, root, swap and /usr.
Having a separate /usr partition seems to be out of fashion theses days,
but keeping the root bits on a distinct part of the disk is harmless
at worst. Having swap I don't need is _much_ better than needing swap
I don't have 8-)


Looking at https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/
the setup wizard appears to be very little help to this end.

If there's a better guide, or maybe some CD-installer inherited
from Debian that can be used, please point it out. I plan on
doing an initial install on microSD to learn the lay of the
land but am not really familiar with RasPiOS admin tools. Once
I have a better idea what I'm doing I'll install the new OS
on a new 1 TB drive and migrate user files from the old disk.

Thanks for reading!

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 27/12/2022 18:13, bob prohaska wrote:

I'd like to try RasPiOS 64 bit on my 8 GB Pi4 as a preliminary
to migrating it from 32 bit to 64 bit. Does the new "first time
setup wizard" have the ability to manipulate partitions and
install from microSD onto a usb-connected hard drive?

It didn't last time I tried it.

The way I set up a dual bootable 32/64 bit Pi was to take an SD card
with an existing 32 bit installation, and used gparted to shrink the
existing root partition to less than half the card, double the size of
the boot FAT partition to 512MB and add a new root64 ext4 partition in
the rest of the space.

I moved the contents of the existing boot partition to a boot32 sub
directory, then took a 64 bit Raspbian ISO image and copied the boot
partition to boot partition of the SD card, and the root partition to
the root64 partition. You then need to edit two files; cmdline.txt on
boot to load the OS from /dev/mmcblk0p2 and /etc/fstab on root64 to
mount / from /dev/mmcblk0p2.

It should then boot to the 64 bit OS. To swap back to the 32 bit OS make
a script to move the boot partitions files in to a boot64 sub
directory, and restore the files from the boot32 subdirectory, then
reboot. And vice versa for a script to go from 32 bit to 64 bit.

If you want to do the same with a USB attachd drive, follow the
instructions for the boot partitions on the SD card, and make the root32
and root64 partitions on the USB drive. Use /dev/sda instead of
/dev/mmcblkp0 above until you get it going, but then I recommend you
replace references to /dev/sda in both sets of cmdline.txt and
/etc/fstab with PARTUUID=xxxxxx-yy where xxxxxx-yy is the the value corresponding to the partition from ls -l /dev/disk/by-partuuid This
stops the Pi booting from the wrong device should you insert a storage
device into another socket.

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

druck <news@druck.org.uk> wrote:

On 27/12/2022 18:13, bob prohaska wrote:

I'd like to try RasPiOS 64 bit on my 8 GB Pi4 as a preliminary
to migrating it from 32 bit to 64 bit. Does the new "first time
setup wizard" have the ability to manipulate partitions and
install from microSD onto a usb-connected hard drive?

It didn't last time I tried it.

Ok, then I didn't miss anything hugely important.

The way I set up a dual bootable 32/64 bit Pi was to take an SD card
with an existing 32 bit installation, and used gparted to shrink the
existing root partition to less than half the card, double the size of
the boot FAT partition to 512MB and add a new root64 ext4 partition in
the rest of the space.

In this case I don't need dual boot, so life is a bit simpler.

I made a microSD with 64 bit Bullseye and experimented a bit.
There's no way to interrupt the growfs on first boot so I just
let it run and then dd'd the entire microSD onto the hard disk.
That didn't fill the hard disk, unlike SD Card Copier. The resulting
hard disk booted and ran just fine, seemingly a bit faster than 32 bit.

I ended up using gnome-disk-utility (maybe that's just a GUI front
end for gparted?), adding a swap partition to the hard disk and
creating a /usr partition in the remaining space. Using cp -a appears
to have copied the old /usr to the new parition. That's where matters
rest at the moment. Next is to edit /etc/fstab to mount the new
usr partition over the old directory and clean out old files. I'll
have to review the syntax for fstab before doing much more.

How does one put a Pi into single-user mode? The method seems to
be quite different from BSD, it appears to involve sulogin but doesn't
unmount the filesystems, which is usually the point of the exercise.
The man page is rather terse, seemingly.

I moved the contents of the existing boot partition to a boot32 sub directory, then took a 64 bit Raspbian ISO image and copied the boot partition to boot partition of the SD card, and the root partition to
the root64 partition. You then need to edit two files; cmdline.txt on
boot to load the OS from /dev/mmcblk0p2 and /etc/fstab on root64 to
mount / from /dev/mmcblk0p2.

It should then boot to the 64 bit OS. To swap back to the 32 bit OS make
a script to move the boot partitions files in to a boot64 sub
directory, and restore the files from the boot32 subdirectory, then
reboot. And vice versa for a script to go from 32 bit to 64 bit.

If you want to do the same with a USB attachd drive, follow the
instructions for the boot partitions on the SD card, and make the root32
and root64 partitions on the USB drive. Use /dev/sda instead of
/dev/mmcblkp0 above until you get it going, but then I recommend you
replace references to /dev/sda in both sets of cmdline.txt and
/etc/fstab with PARTUUID=xxxxxx-yy where xxxxxx-yy is the the value corresponding to the partition from ls -l /dev/disk/by-partuuid This
stops the Pi booting from the wrong device should you insert a storage
device into another socket.

The reference to partuuid is helpful, I've used /dev/sd* till now.
There have been persistent problems with the Pi crashing when a 2nd
disk is plugged in, now the the fix is apparent.

Thanks for writing!

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

druck <news@druck.org.uk> wrote:
...

replace references to /dev/sda in both sets of cmdline.txt and
/etc/fstab with PARTUUID=xxxxxx-yy where xxxxxx-yy is the the value corresponding to the partition from ls -l /dev/disk/by-partuuid This
stops the Pi booting from the wrong device should you insert a storage
device into another socket.

Something is still amiss. In /etc/fstab I have
bob@raspberrypi:~ $ more /etc/fstab
proc /proc proc defaults 0 0 PARTUUID=04071fa6-01 /boot vfat defaults 0 2 PARTUUID=04071fa6-02 / ext4 defaults,noatime 0 1 PARTUUID=04071fa6-03 none swap
PARTUUID=04071fa6-04 /usr ext4 defaults,noatime 0 2

The machine boots, starts swap and generally works fine. However,
if I plug in the old hard disk (to copy over user files) the machine immediately loses communications with the root drive. Both disks are
of the Sabrent model UASP persuasion and use JMicron usb-sata bridges
but the disk shown above uses a JMS577 bridge chip and the old disk
uses a JMS561, so they aren't identical..

Any idea what I'm doing wrong?

Thanks for reading,

bob prohaska

-- druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Wed, 28 Dec 2022 21:46:20 -0000 (UTC), bob prohaska wrote:

druck <news@druck.org.uk> wrote:
...

replace references to /dev/sda in both sets of cmdline.txt and
/etc/fstab with PARTUUID=xxxxxx-yy where xxxxxx-yy is the the value
corresponding to the partition from ls -l /dev/disk/by-partuuid This
stops the Pi booting from the wrong device should you insert a storage
device into another socket.

Something is still amiss. In /etc/fstab I have bob@raspberrypi:~ $ more /etc/fstab proc /proc proc defaults 0
0 PARTUUID=04071fa6-01 /boot vfat defaults 0
2 PARTUUID=04071fa6-02 / ext4 defaults,noatime 0
1 PARTUUID=04071fa6-03 none swap PARTUUID=04071fa6-04
/usr ext4 defaults,noatime 0 2

The machine boots, starts swap and generally works fine. However,
if I plug in the old hard disk (to copy over user files) the machine immediately loses communications with the root drive. Both disks are of
the Sabrent model UASP persuasion and use JMicron usb-sata bridges but
the disk shown above uses a JMS577 bridge chip and the old disk uses a JMS561, so they aren't identical..

Any idea what I'm doing wrong?

Wild guess, but... have you checked whether any of the PARTUUID ids are
the same on both hard disks? If they are, I can well imagine that could
confuse the kernel. From your description it sounds as if that could be
the case, and 'UUID' is, after all, shorthand for 'Universally Unique Identifier'.


--

Martin | martin at
Gregorie | gregorie dot org

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Tue, 27 Dec 2022 18:13:44 -0000 (UTC), bob prohaska <bp@www.zefox.net> wrote:

I'd like to try RasPiOS 64 bit on my 8 GB Pi4 as a preliminary
to migrating it from 32 bit to 64 bit. Does the new "first time
setup wizard" have the ability to manipulate partitions and
install from microSD onto a usb-connected hard drive?

I've kinda learned how to do that with FreeBSD and it's quite a
pain: Suppress growfs by renaming /firstboot, then get into single
user mode, muck around in gpart to add a swap partition, /usr partition
and finally copy contents of the old /usr directory to the new one.

This provides the traditional disk layout of boot, root, swap and /usr. >Having a separate /usr partition seems to be out of fashion theses days,
but keeping the root bits on a distinct part of the disk is harmless
at worst. Having swap I don't need is _much_ better than needing swap
I don't have 8-)

Looking at >https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/
the setup wizard appears to be very little help to this end.

If there's a better guide, or maybe some CD-installer inherited
from Debian that can be used, please point it out. I plan on
doing an initial install on microSD to learn the lay of the
land but am not really familiar with RasPiOS admin tools. Once
I have a better idea what I'm doing I'll install the new OS
on a new 1 TB drive and migrate user files from the old disk.

Thanks for reading!

bob prohaska

I install all my vanilla Raspberry OS'ses on SSD on HD with the Raspberry installer (or other imager). Never had a problem yet.
This is the result on a 2TB SSD:
NAME FSTYPE SIZE MOUNTPOINT
sda 1.8T
+-sda1 vfat 256M /boot
+-sda2 ext4 1.8T /

When using on a HDD a filesize sresize script will immediately start to expand the partition to the max size. Wait until that
script finishes before rebooting - may take a while (2TB external 2.5" took ~20 minutes in my case).....

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Martin Gregorie <martin@mydomain.invalid> wrote:

On Wed, 28 Dec 2022 21:46:20 -0000 (UTC), bob prohaska wrote:

druck <news@druck.org.uk> wrote:
...

replace references to /dev/sda in both sets of cmdline.txt and
/etc/fstab with PARTUUID=xxxxxx-yy where xxxxxx-yy is the the value
corresponding to the partition from ls -l /dev/disk/by-partuuid This
stops the Pi booting from the wrong device should you insert a storage
device into another socket.

Something is still amiss. In /etc/fstab I have bob@raspberrypi:~ $ more
/etc/fstab proc /proc proc defaults 0
0 PARTUUID=04071fa6-01 /boot vfat defaults 0
2 PARTUUID=04071fa6-02 / ext4 defaults,noatime 0
1 PARTUUID=04071fa6-03 none swap PARTUUID=04071fa6-04
/usr ext4 defaults,noatime 0 2

The machine boots, starts swap and generally works fine. However,
if I plug in the old hard disk (to copy over user files) the machine
immediately loses communications with the root drive. Both disks are of
the Sabrent model UASP persuasion and use JMicron usb-sata bridges but
the disk shown above uses a JMS577 bridge chip and the old disk uses a
JMS561, so they aren't identical..

Any idea what I'm doing wrong?

Wild guess, but... have you checked whether any of the PARTUUID ids are
the same on both hard disks? If they are, I can well imagine that could confuse the kernel. From your description it sounds as if that could be
the case, and 'UUID' is, after all, shorthand for 'Universally Unique Identifier'.

;-)

Does the UUID come from the drive itself, or the usb bridge?
Drives are the same model but I'd think Seagate would at least
assign different serial numbers.

Eventually I'll try to check, the machine is in use now. I'll wait
a bit before experimenting since it's likely to force a reboot. Might
using a powered hub on one of the disks avoid conflict?

It turned out my desire to split root and /usr failed when it developed
that startup programs are located in /usr. /sbin is only a link to
/usr/sbin, for example, and there are a few others. Never noticed,
and obviously never checked 8-(

The machine is running 11 now, 64 bit. Seems quite nice and chromium
works a great deal better.

Thanks for reading,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska wrote:

Does the UUID come from the drive itself, or the usb bridge?

I presume they're just stored with sectors of the partition (or partition table)?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Thu, 29 Dec 2022 17:46:37 -0000 (UTC), bob prohaska wrote:

Does the UUID come from the drive itself, or the usb bridge?
Drives are the same model but I'd think Seagate would at least assign different serial numbers.

The output from "man 5 fstab" should be definitive. Here's the first
paragraph from the version on my laptop, which is running Fedora 36.
That's Linux version 6.0.15-200.fc36.x86_64 to be precise:

"The file fstab contains descriptive information about the filesystems
the system can mount. fstab is only read by programs, and not written;
it is the duty of the system administrator to properly create and
maintain this file. The order of records in fstab is important because
fsck(8), mount(8), and umount(8) sequentially iterate through fstab
doing their thing."


--

Martin | martin at
Gregorie | gregorie dot org

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Wed, 28 Dec 2022 17:31:28 +0000, bob prohaska wrote:

druck <news@druck.org.uk> wrote:

On 27/12/2022 18:13, bob prohaska wrote:

I'd like to try RasPiOS 64 bit on my 8 GB Pi4 as a preliminary
to migrating it from 32 bit to 64 bit. Does the new "first time
setup wizard" have the ability to manipulate partitions and
install from microSD onto a usb-connected hard drive?

It didn't last time I tried it.

Ok, then I didn't miss anything hugely important.

The way I set up a dual bootable 32/64 bit Pi was to take an SD card
with an existing 32 bit installation, and used gparted to shrink the
existing root partition to less than half the card, double the size of
the boot FAT partition to 512MB and add a new root64 ext4 partition in
the rest of the space.

In this case I don't need dual boot, so life is a bit simpler.

I made a microSD with 64 bit Bullseye and experimented a bit.
There's no way to interrupt the growfs on first boot so I just
let it run and then dd'd the entire microSD onto the hard disk.

And, that explains your UUID problem.

The device and partition UUIDs are generated and written to the
disk when you partition it. If you clone a partition using dd,
you clone the partition UUID as well, and the clone will have
the same partition UUID as the original filesystem.

Depending on the filesystem, you can use filesystem tools (eg.
tune2fs for ext2 filesystems) to alter the UUID in one of your
conflicting partitions.

[snip]

HTH
--
Lew Pitcher
"In Skills, We Trust"

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 29/12/2022 17:46, bob prohaska wrote:

Martin Gregorie <martin@mydomain.invalid> wrote:

On Wed, 28 Dec 2022 21:46:20 -0000 (UTC), bob prohaska wrote:

druck <news@druck.org.uk> wrote:
[Replacing /dev/sdX with PARTUUID]

The machine boots, starts swap and generally works fine. However,
if I plug in the old hard disk (to copy over user files) the machine
immediately loses communications with the root drive. Both disks are of
the Sabrent model UASP persuasion and use JMicron usb-sata bridges but
the disk shown above uses a JMS577 bridge chip and the old disk uses a
JMS561, so they aren't identical..

Any idea what I'm doing wrong?

Wild guess, but... have you checked whether any of the PARTUUID ids are

Does the UUID come from the drive itself, or the usb bridge?
Drives are the same model but I'd think Seagate would at least
assign different serial numbers.

The UUIDs are created when the drive is partitioned, and will be unique
unless you have low level copied the entire drive, e.g. with dd

It's possible that you can't use the two usb-sata bridges at the same
time, but it should work I've done it on laptops with no problems.
However, if he Pi is powering both devices directly you will run in to
USB power limits, and need to run one or both drives from a powered hub.

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 30/12/2022 12:24, druck wrote:

The UUIDs are created when the drive is partitioned, and will be unique unless you have low level copied the entire drive, e.g. with dd

No, its possible to change the UUID of a partition to match a previous disk

e.g.
https://www.simplified.guide/linux/disk-uuid-set

--
"What do you think about Gay Marriage?"
"I don't."
"Don't what?"
"Think about Gay Marriage."

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 29/12/2022 18:07, Andy Burns wrote:

bob prohaska wrote:

Does the UUID come from the drive itself, or the usb bridge?

I presume they're just stored with sectors of the partition (or
partition table)?

UUID is something stored in the partition
e.g. this desktop :-

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda5 during installation UUID=3e48d310-2e08-44f8-8505-c38844132ab8 / ext4
errors=remount
-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=3B2E-0C1C /boot/efi vfat umask=0077 0 1
/swapfile none swap sw

0 0

--
Religion is regarded by the common people as true, by the wise as
foolish, and by the rulers as useful.

(Seneca the Younger, 65 AD)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Fri, 30 Dec 2022 14:13:23 +0000, The Natural Philosopher wrote:

On 29/12/2022 18:07, Andy Burns wrote:

bob prohaska wrote:

Does the UUID come from the drive itself, or the usb bridge?

I presume they're just stored with sectors of the partition (or
partition table)?

UUID is something stored in the partition
e.g. this desktop :-

# /etc/fstab: static file system information.

More to the point (as /etc/fstab is /not/ the origin of the UUIDs)
you can query the UUIDs using the lsblk(8) command. On /this/ desktop:

09:50 $ lsblk -o NAME,UUID
NAME UUID
sda
|-sda1 BB74-9357
|-sda2 d938cb66-4740-49ac-a848-e8f58efd745a
|-sda3 e91e7749-61cf-468a-8416-1e77ed707930
|-sda4 c1116b0d-ccef-4eac-a57b-fa7273c4c864
|-sda5 2ce04acb-8830-47bc-9a2e-4458fdcfbec3
|-sda6 b0de444a-fa2e-4028-b3e0-7eeff739e8ec
|-sda7 627c68a3-6bdd-47bc-8f89-4ba6b663fbb5
`-sda8 ad20aefc-8c71-44e6-8c37-2321805e2da8
sdb
|-sdb1 eda68709-1ec9-48fa-b50b-1ec3376c7dda
|-sdb2
|-sdb3 8ac5c015-c47f-46a3-9213-e58337805940
|-sdb4 abaa7f61-823f-497a-bc21-07a1fd46de20
|-sdb5 bb11bff0-2822-45a6-b773-df27201c4192
`-sdb6 741b91c4-7def-4ad8-b06d-8e39302db483

--
Lew Pitcher
"In Skills, We Trust"

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 30/12/2022 14:54, Lew Pitcher wrote:

On Fri, 30 Dec 2022 14:13:23 +0000, The Natural Philosopher wrote:

On 29/12/2022 18:07, Andy Burns wrote:

bob prohaska wrote:

Does the UUID come from the drive itself, or the usb bridge?

I presume they're just stored with sectors of the partition (or
partition table)?

UUID is something stored in the partition
e.g. this desktop :-

# /etc/fstab: static file system information.

More to the point (as /etc/fstab is /not/ the origin of the UUIDs)
you can query the UUIDs using the lsblk(8) command. On /this/ desktop:

Are you drunk already?

What about "UUID is something stored in the partition" did you not
understand?

I merely used the fstab example to show that indeed the UUID was not
DISK related, but was PARTITION related.

Why introduce a straw man claiming I said fstab DEFINES it.

Especially when I referenced a linux tool to alter it, on the disk
partition.

--
“There are two ways to be fooled. One is to believe what isn’t true; the other is to refuse to believe what is true.”

—Soren Kierkegaard

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Martin Gregorie <martin@mydomain.invalid> wrote:

Wild guess, but... have you checked whether any of the PARTUUID ids are
the same on both hard disks? If they are, I can well imagine that could confuse the kernel. From your description it sounds as if that could be
the case, and 'UUID' is, after all, shorthand for 'Universally Unique Identifier'.

It turns out that interposing a powered hub between the added disk
and the running system solves part of the problem; the kernel sees
the disk and does not lose communication with the device it booted
from. This works in both GUI and CLI modes.

ls -l reports
bob@raspberrypi:~ $ ls -l /dev/disk/by-partuuid
total 0
lrwxrwxrwx 1 root root 10 Dec 30 16:22 201f23f0-01 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Dec 30 16:22 201f23f0-02 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Dec 30 16:22 201f23f0-03 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Dec 30 15:17 c7f31cc0-01 -> ../../sda1
lrwxrwxrwx 1 root root 10 Dec 30 15:17 c7f31cc0-02 -> ../../sda2 bob@raspberrypi:~
so the problem isn't duplicate UUIDs.

There's no disruption to the display if the extra disk is connected
directly to the second USB3 port, so if it's a power problem it's
not prolonged. All windows stay up, didn't see any lightning bolt
icon, but all commands report "no such filename" or words to that
effect. Power cycle is the only way out.

I expected that with both disks connected (one directly, the other
through the powered hub) the machine would reboot from whichever
disk was discovered first. In the one attempt so far it looks
like neither disk is discovered. No acivity visible at all. That's
a bit surprising. After sending this I'll experiment further.

Thanks for reading,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Fri, 30 Dec 2022 18:38:51 +0000, The Natural Philosopher wrote:

On 30/12/2022 14:54, Lew Pitcher wrote:

On Fri, 30 Dec 2022 14:13:23 +0000, The Natural Philosopher wrote:

On 29/12/2022 18:07, Andy Burns wrote:

bob prohaska wrote:

Does the UUID come from the drive itself, or the usb bridge?

I presume they're just stored with sectors of the partition (or
partition table)?

UUID is something stored in the partition
e.g. this desktop :-

# /etc/fstab: static file system information.

More to the point (as /etc/fstab is /not/ the origin of the UUIDs)
you can query the UUIDs using the lsblk(8) command. On /this/ desktop:

Are you drunk already?

Who pi$$ed in your cornflakes this morning?

What about "UUID is something stored in the partition" did you not understand?

I understand it as well as you do. I've said it before, in this thread.

I merely used the fstab example to show that indeed the UUID was not
DISK related, but was PARTITION related.

No, you made a statement that UUIDs were stored in the partition, then illustrated your statement with the contents of a configuration file
that (without further explanation) /could/ illustrate that UUIDs were
/not/ stored in the partition, but were metadata supplied to mount by
a static initialization file.

Note the *without futher explanation* part.

Why introduce a straw man claiming I said fstab DEFINES it.

You are introducing that strawman here and now. I said nothing of the
sort.

I did, however, mention a tool that /does/ extract UUIDs from the
physical device.

Especially when I referenced a linux tool to alter it, on the disk
partition.

--
Lew Pitcher
"In Skills, We Trust"

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 31/12/2022 15:14, Lew Pitcher wrote:

On Fri, 30 Dec 2022 18:38:51 +0000, The Natural Philosopher wrote:

On 30/12/2022 14:54, Lew Pitcher wrote:

On Fri, 30 Dec 2022 14:13:23 +0000, The Natural Philosopher wrote:

On 29/12/2022 18:07, Andy Burns wrote:

bob prohaska wrote:

Does the UUID come from the drive itself, or the usb bridge?

I presume they're just stored with sectors of the partition (or
partition table)?

UUID is something stored in the partition
e.g. this desktop :-

# /etc/fstab: static file system information.

More to the point (as /etc/fstab is /not/ the origin of the UUIDs)
you can query the UUIDs using the lsblk(8) command. On /this/ desktop:

Are you drunk already?

Who pi$$ed in your cornflakes this morning?

What about "UUID is something stored in the partition" did you not
understand?

I understand it as well as you do. I've said it before, in this thread.

I merely used the fstab example to show that indeed the UUID was not
DISK related, but was PARTITION related.

No, you made a statement that UUIDs were stored in the partition, then illustrated your statement with the contents of a configuration file
that (without further explanation) /could/ illustrate that UUIDs were
/not/ stored in the partition, but were metadata supplied to mount by
a static initialization file.

I am simply not used to dealing with people whose egos exceed their IQs.
Have a happy court-holding new year





--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska <bp@www.zefox.net> wrote:

I expected that with both disks connected (one directly, the other
through the powered hub) the machine would reboot from whichever
disk was discovered first. In the one attempt so far it looks
like neither disk is discovered. No acivity visible at all. That's
a bit surprising. After sending this I'll experiment further.

Running reboots behave as expected; the directly-connected disk is
discovered and boots, the disk connected via powered up is found
(and mounted) later. The failure was during a shutdown -h followed
by power-cycling the Pi while the hub-connected disk remained powered
by the hub. Disconnecting the disk from the hub doesn't help, so it
looks like having the hub powered up when the Pi is power-cycled
somehow inhibits the Pi starting up. Have to rearrange my power
cords to experiment further.

Thanks for reading,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)