Open eatradish opened 8 months ago
This doesn't look right. 16MiB is just the copy block size.
The rootfs has to be a multiple of the physical sector size which is 4KiB. If your image creation is producing FS images that are not a multiple of the sector size, then yeah, you have a problem ;)
This doesn't look right. 16MiB is just the copy block size.
The rootfs has to be a multiple of the physical sector size which is 4KiB. If your image creation is producing FS images that are not a multiple of the sector size, then yeah, you have a problem ;)
Thanks for the answer! do you think I should go ahead and change my PR to 4KiB or is there no need to go ahead and do anything?
The rootfs has to be a multiple of the physical sector size which is 4KiB. If your image creation is producing FS images that are not a multiple of the sector size, then yeah, you have a problem ;)
Thanks for pointing that out! Yes, due to the flaw in the calculation algorithm, our image creation process just always creates images which are not a multiple of 16MiB, 4KiB or 512B. I thought that each write in the dd
process should always equal to bs
.
See: https://github.com/AOSC-Dev/aosc-asahi-installer/commit/c5c8633865c4369b14cade8bc2c1e43026d1207a, if rootfs image size can not multipie of 16MiB, asahi-installer will raise
EINVAL
, users don't know whats happen ...The point of this commit is to look for illegitimate rootfs image sizes in advance, so that the raise error becomes clear.