Hi Guillaume, That sounds all too familiar to me...
>> when I build locally JeOS-raspberrypi image, I get a *.raw image but it >> seems that partitioning is a bit strange. >> We have the 2 partitions: >> * 1st: FAT32 for Pi bootloader (mandatory unfortunately) with bootflag >> enabled >> * 2nd: EXT4 for rootfs can you paste output of fdisk partition listing "l" in expert mode ? >> >> But when I want to boot on it, it just does not boot at all, whereas it is >> readable from my desktop openSUSE. >> >> The thing is fdisk reports some problems with "v" command to verify >> partitions: >> Partition 1: head 160 greater than maximum 124 Ok, so the C/H/S geometry is wrong. One neat detail that we learned the hard way is that the C/H/S geometry really does matter for the actual device. kiwi is more optimized for the x86 world where almost everything uses plain LBA for accessing the devices and proper C/H/S mapping is not relevant anymore. its usage of gparted is a great part of that problem, as gparted is notoriously bad at keeping C/H/S mapping intact. The way most devices determine the correct H/S layout is by looking at the partition end of the 1st partition. The values in there are taken as number of Heads and Cyclinders, and that layout is then used later for determining where partitions are bound to start (the rule is that they have to start on a cylinder/head boundary if I remember correctly). We had this problem already several times before, and I thought we catched all wrong calculations in kiwi already (kiwi for some reason does those calculations manually), but it seems we missed the case for FAT32. The strategic "remove one sector from the partition length" is the fix we did also for all the other code paths, so the remaining work is to find where the duplicated code for creating the FAT32 partition lives in kiwi and patch that one as well. Greetings, Dirk -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
