Installing RasPiOS on a mechanical hard disk

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

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

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.

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

druck snipped-for-privacy@druck.org.uk> wrote: ...

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

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'.

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

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).....

;-)

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

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

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."

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.

HTH

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

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

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

e.g.

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.

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

Who pi$$ed in your cornflakes this morning?

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

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.

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.

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

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