Stop hard-coding sector size to 512

[Łukasz Zemczak]

Currently in one place still there's a hard-coded 512 byte sector size - this is no longer necessary as we have get_default_sector_size().

[Łukasz Zemczak (sil2100)]

This also makes me wonder if maybe sector size should be configurable through the gadget.yaml, since in theory the builder machine can be different than the machine we want to target in the end. But that would be super low priority I guess.

[Barry Warsaw (barry)]

There are a couple of places (not including the tests) where 512 is hard coded:

1) In the mkfs.vfat call in builder.py, we hard code `-S 512`

2) Just after that we allocate 34 512-byte sectors for the GPT backup.

3) As a fallback sector size if one cannot be determined

#1 could be replaced by a call to get_default_sector_size(), and maybe #2 could be too. #3 is fine.

I think it could be a gadget specified value if there's some way to influence the behavior when the images are built. mkfs.vfat has the -S option (which we already use, as hard coded in #1 above). mkfs.ext4 has $MKE2FS_DEVICE_SECTSIZE but from the documentation I can't tell if that actually changes the sector size of the underlying disk image. A little experiment would be necessary.

If you can't influence the disk image sector sizes in all cases, then probably the best we could do is warn/error on a mismatch.

[Łukasz Zemczak (sil2100)]

Originally I wanted to switch all the places where we hard-code the 512 bytes sector to using the values we get from pyparted (the .sectorSize() bit), but looking at the code now I guess it wouldn't make much sense. From what I see it's just doing an ioctl BLKSSZGET for the given block-device handle - and since we're calling it for an image file, it's not really that useful.

Working on this will only make sense if we somehow allow for altering the sector size from the gadget spec or the ubuntu-image arguments. In that case I still need to check if there's some way we can override the sector_size for a given device from inside pyparted, since otherwise we'll have to do size conversions manually (i.e. fetch the sector size and try to use multiples of it to accommodate) - which is terrible and non-scalable.

[Łukasz Zemczak (sil2100)]

This is basically supported via the --sector-size argument.