need to incorporate losetup --sector-size 4096(maybe others?) possibly with an invocation parameter

[anon99]

It appears hardcoded to build 512 sector images. "failsafe losetup" needs some tweaking along with using kpartx to set/find partitions on 4096 sector loops for at least the final phase.

[eduble]

Hello, Can you elaborate and describe the problem you faced with the debootstick run and/or with the generated image? Thanks Etienne

[anon99]

I want to build an installation disk for an Ubuntu system using debootstrap. The system in question only has 4K drives [logical_blocksize and physical_blocksize = 4096]. I initially used debootstick and found it generated an image with 512sector characteristics. [blockdev --getbsz and --getss]. I looked over the code and found it used losetup with no --sector-size argument which would build a 512sector loop device. I made changes to failsafe losetup to add "--sector-size 4096" which broke failsafe() so I fixed undo_losetup to tolerate 1 or 3 arguments. [I believe the single argument losetup comes from the chrooted environment]. Much progress was made untill grub-install found the disksize in bytes (or kb) was not a round multiple of 4096, so I fixed estimate_minimal_rootpart_size_kb() to round up by 4k. The resulting image now appears to be 4096sector and boots but encounters an error attempting to resize the volume (which corrupts the underlying file). There is obviously something amiss as the 512sector image finds the size of the volume has not changed and avoids the resize. Any help much appreciated... Thanks for the reply!.

[eduble]

Thanks for the details. Are you sure that your drives are 4k only and do not support 512 emulation (512e)? I mean, the 512-fomatted image did not boot, or this is just a matter of performance? Note: I have also read that some USB external enclosures wrongly report 4k (https://knowledgebase.macrium.com/display/KNOW/Incompatible+Disk+Selected#IncompatibleDiskSelected-USB).

So the final goal would be to make debootstick able to generate both image formats (by adding a --sector-size option to debootstick itself, and updating the code to make it work...), right?

The changes you described seem correct to me. Unfortunately I have no native-4k disk myself, so I cannot help you much on this side.

The resulting image now appears to be 4096sector and boots but encounters an error attempting to resize the volume (which corrupts the underlying file).

Did you get an error message? debootstick just calls pvresize, lvresize and resize2fs, so if the file is corrupted, then there is probably an issue with 4k-sector management in one of these tools, or in the hardware / firmware of the disks you use.

There is obviously something amiss as the 512sector image finds the size of the volume has not changed and avoids the resize.

Usually we get this message (size has not changed) when we try to boot the generated image directly, on a virtual machine. To simulate a copy on a larger disk, one should run e.g. truncate -s 250G <image-file> before. If you really flashed the image on the disk, I have no other idea.

[anon99]

I'm not an expert on the quirks of 4K drives but do know a few things for sure. Some SAS drives can be formatted 512 or 4K.. sata drives report "enhanced format" or similar but they tend to be 4k physical 512 logical. Ordinary BIOS/MBR setups can boot 512 logical drives [the 4096 physical may cause a performance issue but is essentially hidden]. To boot a 4Klogical+physical drive you need UEFI/OVMF and a gpt partition table. A --sector-size option to debootstick would be ideal. There are all sorts of quirks lurking around in the 4ksector area, however I have some experience building Linux on real 4k(logical and physical) drives and the LVM tools seem happy enough, as do most things as long as the drive reports 4096 to --getbsz and --getss. As far as I can tell a loop-device behaves similarly to real hardware here. I have built images using real hardware and made loop-devices from their images and things seem to work correctly. I can send my patches (scattered with some debug stuff) if you want to look them over and either make suggestions or make a new "tree". I'd be more than happy to test/debug/whatever.

[eduble]

OK, you can clone the repository and push your changes there. I should have time to look at it next week.