• Installing RasPiOS on a mechanical hard disk

    From bob prohaska@3:770/3 to All on Tuesday, December 27, 2022 18:13:44
    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)
  • From druck@3:770/3 to bob prohaska on Wednesday, December 28, 2022 12:21:44
    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)
  • From bob prohaska@3:770/3 to druck on Wednesday, December 28, 2022 17:31:28
    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)
  • From bob prohaska@3:770/3 to druck on Wednesday, December 28, 2022 21:46:20
    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)
  • From Martin Gregorie@3:770/3 to bob prohaska on Wednesday, December 28, 2022 22:04:58
    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)
  • From Joe@3:770/3 to bob prohaska on Thursday, December 29, 2022 14:31:05
    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)
  • From bob prohaska@3:770/3 to Martin Gregorie on Thursday, December 29, 2022 17:46:37
    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)
  • From Andy Burns@3:770/3 to bob prohaska on Thursday, December 29, 2022 18:07:26
    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)
  • From Martin Gregorie@3:770/3 to bob prohaska on Thursday, December 29, 2022 18:30:18
    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)
  • From Lew Pitcher@3:770/3 to bob prohaska on Thursday, December 29, 2022 19:50:27
    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)
  • From druck@3:770/3 to bob prohaska on Friday, December 30, 2022 12:24:06
    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)
  • From The Natural Philosopher@3:770/3 to druck on Friday, December 30, 2022 14:15:22
    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)
  • From The Natural Philosopher@3:770/3 to Andy Burns on Friday, December 30, 2022 14:13:23
    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)
  • From Lew Pitcher@3:770/3 to The Natural Philosopher on Friday, December 30, 2022 14:54:06
    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)
  • From The Natural Philosopher@3:770/3 to Lew Pitcher on Friday, December 30, 2022 18:38:51
    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)
  • From bob prohaska@3:770/3 to Martin Gregorie on Saturday, December 31, 2022 00:35:28
    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)
  • From Lew Pitcher@3:770/3 to The Natural Philosopher on Saturday, December 31, 2022 15:14:55
    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)
  • From The Natural Philosopher@3:770/3 to Lew Pitcher on Saturday, December 31, 2022 15:23:58
    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)
  • From bob prohaska@3:770/3 to bob prohaska on Saturday, December 31, 2022 17:14:51
    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)