Le 09/10/2012 13:09, Marcus Schäfer a écrit :
Hi,
Could you please try a local build and check why? The script is called from this folder: /tmp/kiwiboot.8bPLPn And the script looks for MLO in boot/MLO and does not found it and ignore it.
MLO is here: /usr/src/packages/KIWIROOT-oem/boot/MLO
Is there a environment variable usable for "/usr/src/packages/KIWIROOT-oem/" or should we hardcode it? Adrian? Marcus? Is there anything we could use here for full path resolution? For now, please just hardcode it. Hmm, I did not get the full picture. I built locally for panda and don't see that problem. So the situation with MLO is as follows with the current kiwi code:
- MLO is installed by the package u-boot-omap4panda for panda it provides it in /boot when kiwi prepares the boot image.
For beagleboard, it is provided by x-loader-omap3beagle, not u-boot. Maybe the problem is here?
When kiwi creates the initrd cpio archive it moves among other things the MLO to image/loader/MLO because /boot is removed from the initrd after the kernel was extracted. Thus MLO is in the kiwi created initrd at:
gzip -cd /space/mytest/initrd-oemboot-suse-12.2.armv7l-2.7.1.gz |\ cpio -it | grep MLO
==> image/loader/MLO
you should first check if this is the case in your build as well
No. I only have this one: [ 814s] Oct-09 08:54:51 <1> : EXEC [gzip -9 -cd /usr/src/packages/KIWI-oem/oem/initrd-oemboot-suse-12.2.armv7l-2.7.1.gz 2>&1 | cpio -it 2>/dev/null | grep efi_gop.module 2>&1] You can double check in my full build log (with my patch), here: http://guillaume.gardet.free.fr/openSUSE/patched_JeOS-beagle.log
- now when kiwi creates the oem disk image it extracts all relevant data from the initrd into a tmpdir. In the log you should see something like this:
Importing uboot loaders EXEC [gzip -9 -cd /space/mytest/oem-pandaFlavour/initrd-oemboot-suse-12.2.armv7l-2.7.1.splash.gz 2>&1 | (cd /tmp/kiwiboot.w9zWIv && cpio -di 'image/loader/*' 2>&1)]
Yes: [ 829s] Oct-09 08:55:06 <1> : EXEC [gzip -9 -cd /usr/src/packages/KIWI-oem/oem/initrd-oemboot-suse-12.2.armv7l-2.7.1.splash.gz 2>&1 | (cd /tmp/kiwiboot.KsYkmB && cpio -di 'image/loader/*' 2>&1)]
- when creating the bootpartition filesystem the data from the tmpdir is copied to the boot partition. In the log this appears like this:
Copying boot image to disk ... EXEC [mount /dev/mapper/loop0p1 /tmp/kiwiloop.jBDV6Z 2>&1] EXEC [cp -dR /tmp/kiwiboot.w9zWIv/boot /tmp/kiwiloop.jBDV6Z 2>&1]
Yes: [ 853s] Oct-09 08:55:30 <1> : EXEC [mount /dev/mapper/loop0p1 /tmp/kiwiloop.J3pMYx 2>&1] [ 853s] Oct-09 08:55:30 <1> : EXEC [cp -dR /tmp/kiwiboot.KsYkmB/boot /tmp/kiwiloop.J3pMYx 2>&1]
...
- now kiwi calls the post bootloader install script within the context of the tmpdir. In this example: 'cd /tmp/kiwiboot.w9zWIv && bash --norc -c ...'
Not found.
within that tmpdir the relative path 'boot/MLO' always exists if MLO was provided by the initrd as the steps before should show. In the log/terminal you should see something like:
Calling post bootloader install script: ... '[' -f boot/MLO ']' + opt='count=1 seek=1 conv=notrunc' + dd if=boot/MLO of=/space/mytest/oem-pandaFlavour/LimeJeOS-12.2.armv7l-1.12.2.raw bs=128k count=1 seek=1 conv=notrunc 0+1 records in 0+1 records out 34312 bytes (34 kB) copied, 0.000427246 s, 80.3 MB/s
No, I need to provide the path to kiwiroot-oem folder because there is no MLO here.
All that worked in my test build. What's different when the buildservice does it ?
It must be the difference between beagle (MLO provided by x-loader-omap3beagle) and panda (MLO provided by u-boot)
hardcoding abs paths is not a solution not even a hacky one :) This will cause us more trouble than everything else
Ok. So it seems MLO for beagle is not correctly installed in initrd, so it is not available in tmp dir. Any idea how to solve it ? Guillaume
Thanks
Regards, Marcus
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org