Cyril Brulebois <kibi@debian.org> (2016-05-06): > Strange, vagrant said partitioning from jessie worked fine? > > Anyway, we could try passing the mentioned option to mkfs.ext* to make > sure it doesn't get in the way, and see how it goes? > > I suppose we're interested in patching commit.d/format_ext3 from > src:partman-ext3 (yes, this could be considered confusing). If such a > package is uploaded to unstable, the next d-i daily build should > contain the said change. Of course this is largely suboptimal, as this would disable the flex_bg option (which is probably the default for good reasons) everywhere. I'm not at all familiar with u-boot integration. Am I correct in assuming this only happens after partitions are created? In which case it doesn't seem possible to: - keep on creating the partitions as currently done - alter them afterwards when u-boot integration happens since a quick test with a loopback-mounted image file led to: | kibi@wodi:/scratch$ sudo mkfs.ext4 /dev/mapper/loop0p1 | […] | kibi@wodi:/scratch$ sudo tune2fs -l /dev/mapper/loop0p1 | grep flex_bg | Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize | kibi@wodi:/scratch$ sudo tune2fs -O ^flex_bg /dev/mapper/loop0p1 | tune2fs 1.42.12 (29-Aug-2014) | Clearing the flex_bg flag would cause the the filesystem to be inconsistent. (BTW this is with a jessie userspace, so flex_bg was the default there already?) Anyway, we could probably implement the change globally regardless, just to make it possible to check the hypothesis on a wide range of devices, and only figure out later how to fix this in a better way? Vagrant, what do you think? KiBi.
Attachment:
signature.asc
Description: Digital signature