Skip to content
This repository has been archived by the owner on Nov 7, 2022. It is now read-only.

How to correctly fix init.resizefs when booting rpi from ssd #27

Closed
Ognian opened this issue Sep 23, 2020 · 6 comments
Closed

How to correctly fix init.resizefs when booting rpi from ssd #27

Ognian opened this issue Sep 23, 2020 · 6 comments

Comments

@Ognian
Copy link
Contributor

Ognian commented Sep 23, 2020

When generating the image for raspberry pi and burning it to a ssd, so that the rpi boots from the usb disk instead of the sd card
everything it needs to be changed is this line ('p1' to '1') to make the install successful.
I'm not sure how we shall fix this. One possibility is to add a third '$IMAGE_TYPE' -> raspberrypiusb but this would lead to many changes in the if's which would make the code less readable. Another would be to add a '$IMAGE_SUBTYPE'...
The most elegant way would be to somehow programmatically find out the name of the first partition of the '$ROOTDISK'...
Any ideas ?

@Ognian
Copy link
Contributor Author

Ognian commented Oct 9, 2020

Added Ognian@e562ca5 but it is not tested yet... (don't have empty sd and/or usb ssd's now)

@Ognian Ognian changed the title How to correctly fix init.resizefs when booting rpi form ssd How to correctly fix init.resizefs when booting rpi from ssd Oct 9, 2020
@sgielen
Copy link
Owner

sgielen commented Oct 10, 2020

I think programmatically finding out the name of the first partition should be feasible. I guess the name of the disk is quite unpredictable and can also change in the future, so I would prefer not to hardcode any expectations of it. In that sense, I'd also like to get rid of this hardcoding of the expected name of the first partition that we have now.

Tools like lsblk are able to find out a partition tree from a block device, perhaps using /sys or /proc, I think it would be a good idea to find out how they do it, and use similar behaviour here.

@Ognian
Copy link
Contributor Author

Ognian commented Oct 13, 2020

Changed to Ognian@23ede0c should work but is still not tested...

@cwoolum
Copy link

cwoolum commented Mar 3, 2021

I was able to test this. The first commit does work. The second one has the following error:

lsblk: error while loading shared libraries: libmount.so.1: cannot open shared object file: No such file or directory
mount: can't read '/etc/fstab': No such file or directory

@cwoolum
Copy link

cwoolum commented Mar 3, 2021

I tried flashing a regular SD Card again afterward and failed due to the regex not matching. Since we're using sh instead of bash, the syntax needs to be a bit different.

if echo "$ROOTDISK" | grep -Eq $MMCROOT_REGEX; then

@sgielen
Copy link
Owner

sgielen commented Sep 14, 2022

Just pushed as b3ed5f1, thank you @Ognian and @cwoolum :-)

@sgielen sgielen closed this as completed Sep 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants