Le 30/10/2013 08:54, Dirk Müller a écrit : > 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 ?
It is 'p', not 'l', but here it is: ******************************************************************************** Expert command (m for help): p Disk /dev/sdb: 122 heads, 62 sectors, 1020 cylinders Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID 1 80 32 33 0 159 14 25 2048 409608 0c 2 00 159 15 25 34 46 116 411656 1454072 83 3 00 0 0 0 0 0 0 0 0 00 4 00 0 0 0 0 0 0 0 0 00 ******************************************************************************** > > >>> 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. Thanks for information. Guillaume > > > Greetings, > Dirk > -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
