Raspberry Pi Forums

It seems that there was a particular issue with my setup.
Forget what I wrote below.

Sorry

paulv wrote: ↑

Sun Jul 28, 2019 8:07 pm

The procedure to make the RPi boot from a USB SSD or flash disk/stick is pretty well documented.

However, when you're using a "real" hard disk, one of the spinning kind, there is a quirk lurking in the background. The standard procedure to expand the newly imaged drive to take the full size does notwork on "real" hard disks. "the procedure does not know how to do that"

That's odd - it definitely used to work. I imaged an old 160GB laptop hard disc for my Pi 3B+ a few months ago and it did the auto-resize just fine. I've not tried it with Raspbian Buster though - Kodi is currently broken on Raspbian Buster, and I need that before I upgrade.

Buster does report that error but the HDD I have is already resized by using Etcher to image first

I can then either boot from this or use a hybrid SD/HDD boot depending on machine and USB adapter.

Andyroo wrote: ↑

Mon Jul 29, 2019 11:02 pm

the HDD I have is already resized by using Etcher to image first

I wasn't aware etcher resized the root partition after writing it to the disc. Are you sure it does this?

Well the last 500Gb HD I did this was was resized so something must have

I even checked it with gparted and it was a new drive...

andrum99 wrote: ↑

Mon Jul 29, 2019 11:10 pm

Andyroo wrote: ↑

Mon Jul 29, 2019 11:02 pm

the HDD I have is already resized by using Etcher to image first

I wasn't aware etcher resized the root partition after writing it to the disc. Are you sure it does this?

No, it doesn't. The partition gets resized at first boot.

paulv wrote: ↑

Sun Jul 28, 2019 8:07 pm

The standard procedure to expand the newly imaged drive to take the full size does notwork on "real" hard disks.

What evidence do you have that this is any more widespread than a problem you've have had with a particular hard disk ?

I've used the automatic resize process many times without any problems.

PeterO

andrum99 wrote: ↑

Mon Jul 29, 2019 9:55 pm

paulv wrote: ↑

Sun Jul 28, 2019 8:07 pm

The procedure to make the RPi boot from a USB SSD or flash disk/stick is pretty well documented.

However, when you're using a "real" hard disk, one of the spinning kind, there is a quirk lurking in the background. The standard procedure to expand the newly imaged drive to take the full size does notwork on "real" hard disks. "the procedure does not know how to do that"

That's odd - it definitely used to work. I imaged an old 160GB laptop hard disc for my Pi 3B+ a few months ago and it did the auto-resize just fine. I've not tried it with Raspbian Buster though - Kodi is currently broken on Raspbian Buster, and I need that before I upgrade.

I just completed several hours of testing a usb-boot update and didn't find any instances of Raspbian Buster failing to auto-resize when direct booting on a 3B/3B+, regardless of whether a "real" hard disk, one of the spinning kind, or one of the solid state variety was being used.

PeterO wrote: ↑

Tue Jul 30, 2019 6:24 am

I've used the automatic resize process many times without any problems.

PeterO

Yup, that statement by the OP is nonsense. I've tested buster on my 3B+ with a 500GB WD Scorpio Blue HDD and an ELUTENG black adapter.

Wrote image to drive and booted Pi 3B+ with no SD card.
Automatic resize worked and rebooted system.
Ran through startup script and system updates and it rebooted again.
Tweaked some settings with the Raspbian configuration utility and rebooted again.
Everything worked fine (as expected).

I can understand wanting a custom partition configuration, but claiming that the default system doesn't work on "real" hard disks is wrong. If the OP did have problems it wasn't with Raspbian or the resize script. It was likely power, slow spin-up or an incompatible USB adapter (which are well known problems that have nothing to do with the resize script). It even works on other models with a bootcode.bin-only SD card.

The rest of the OP's procedure seems unnecessarily complicated with no good reasoning behind it. The whole post really makes no sense to me with statements such as,

With my applications, I don't like to have the whole disk automatically being resized anyway. This procedure is fine for normal size SD cards (say up to 64GB), but for larger sizes, no longer.

Really, why?

That may be applicable if you're running the RPi as a desktop, but even so, I don't think that's a good practice anymore.

Again, why? If you're going to ask others to perform a complex procedure, some good reasoning behind it is needed.

And then there's this little gem,

From the earlier days onward, I have segmented my application data files on another device, to reduce the wear and tear of the SD card. It makes sense to me to update the OS by re-flashing a card, but please leave my precious data alone. Remember a re-flash of the OS means a re-flash of the whole card/drive.

If you're booting from an SD card, then why make a bootable USB HDD?

Sorry, paulv, but I really don't understand why you think all this extra complexity is necessary, and your post is confusing. Are you booting from a card and putting your data on HDD, because it seems like you are booting from the HDD, in which case re-imaging is going to wipe everything anyway.

Andyroo wrote: ↑

Mon Jul 29, 2019 11:02 pm

Buster does report that error but the HDD I have is already resized by using Etcher to image first

I can then either boot from this or use a hybrid SD/HDD boot depending on machine and USB adapter.

It would seem that there is something specific to your setup that is causing the auto-resize on first boot to fail. This is not the same as auto-resize not working, rather that in some specific instances it can fail. If you want to get it fixed then please file a bug, but don't assume because it doesn't work for you that it is the same for everyone else.