pyavitz / debian-image-builder

Debian image builder for single board computers
Other
139 stars 33 forks source link

Add USB Devices #64

Closed ShorTie8 closed 1 year ago

ShorTie8 commented 1 year ago

Adds the ability to use a USB device instead of a image file

pyavitz commented 1 year ago

As it currently looks, it is pretty intrusive.

Makefile: Why do all these bits need to be inside the Makefile? If the idea as I understand it is to not use /dev/loop but instead use /dev/sdX, 90% of what was added there can just be removed.

lib/function/staging: Instead of stepping all over the single and dual partition functions, why not create two specific for the USB bit? https://github.com/pyavitz/debian-image-builder/blob/feature/lib/function/staging#L148 https://github.com/pyavitz/debian-image-builder/blob/feature/lib/function/staging#L153

if [[ $USB == "true" ]]; then
    ShorTie8_stuff_happens
else
    single_partition
fi

Maybe go even further and use usb_single_partition to call on the function? https://github.com/pyavitz/debian-image-builder/blob/feature/lib/function/staging#L205

If the naming conventions are kept the same in theory the builder would only need to know this is where the whiskey is being made.

Notes: Very few boards off the top of my head can do USB boot out of the bag. Shouldn't this also be SoC specific?

ShorTie8 commented 1 year ago

Thought I had made it the lease intrusive as I could. Sure I can do it all kinds of ways, writing all kind of code. Like my p3 adaptation @ a 144K patch.

Yup, actually do not need any Makefile mods. Just run scripts/Find_USB to make the USB_Drive.txt file.

As far as lib/function/staging goes is I moved the loseup to before fdisk, instead of after. That way I could pass the /dev/sdX to fdisk. And it does not matter for a image, before or after. The rest is the same order and stuff.

The USB device can be any thing. A sdcard in a usb adapter or emmc in it's adapter. They all boot sdcard's correct ??

pyavitz commented 1 year ago

My thought is the partitioning setup could be stand alone, but share as much of the same variables as the losetup or current variables as possible. I just did something similar to this with the write2mmc script which is now a write2anything script really.

https://github.com/pyavitz/debian-image-builder/blob/feature/files/scripts/write2mmc#L303

With that script, I have the user pre-define "it is interactive" the location used /dev/XXX. Something like this could be added to the custom.txt file, as to avoid interaction. That way the most important variables are always there and it doesn't have to look for any extra files. Plus the file is already sourced during staging.

One thing I could see being a issue is media speeds.

ShorTie8 commented 1 year ago

Personally I would never hard code a /dev/sdX. Your assumption of what it is may not always be correct. Let inotify-wait find it so it is always correct. But that tis me .. :/~

The "partitioning setup" ($Size) could be set back. I twas just trying to not do a resize on 1st boot is all. Guess I could just reset IMAGE_FOLDER to /dev & IMAGE_FILE_NAME to sdX. Maybe.

You already do a, rm -f {part-uuid.txt,board.txt,kernel.txt}; What is the big deal of a USB_Drive.txt file ??

media speeds ?? Ya, it might take a little longer, but I don't see any other possible issues.

pyavitz commented 1 year ago

You don't need to take my advice and I understand what the use of inotify-wait is for, but personally I'm not gonna just willy-nilly trust it.

Bugs
There are race conditions in the recursive directory watching code which can cause events to be missed if they occur in a directory immediately after that directory is created. This is probably not fixable.

Its not the file, its the point: USB_Drive.txt <-- Does this need to be here? Did stepping on the loop partition functions need to happen? Why not create USB partition functions?

Out of these 3 files part-uuid.txt,board.txt,kernel.txt part-uuid.txt could actually be removed. I keep it just in case I need to work some magic later in stage2. Beyond that its pretty pointless.

You know this is Github and open, if you don't wanna work with me in making the code cleaner cleaner in my opinion and more isolated so I don't need to fix or account for it later than you are more than welcome to fork the project and do whatever you want.

ShorTie8 commented 1 year ago

I'm working on making it cleaner. Actually just adjusting IMAGE_FOLDER to /dev & IMAGE_FILE_NAME to sdX kight do the trick. /dev/sda1 /root/debian-image-builder/p1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=936,iocharset=utf8,shortname=mixed,errors=remount-ro 0 0 /dev/sda2 /root/debian-image-builder/p2 ext4 rw,noatime 0 0 /dev/sda1 /root/debian-image-builder/p2/boot/broadcom vfat rw,relatime,fmask=0022,dmask=0022,codepage=936,iocharset=utf8,shortname=mixed,errors=remount-ro 0 0