[opensuse-arm] Beagleboard xM boots with 12.2 image but not with factory image
Hi, With latest factory: openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot) With 12.2 image: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... It boots normaly. Any idea? Is there any change in MLO handling in factory? Regards, Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
Hi,
With latest factory: openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot)
With 12.2 image: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... It boots normaly.
Any idea? Is there any change in MLO handling in factory?
Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 05/10/2012 22:19, Alexander Graf a écrit :
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
Hi,
With latest factory: openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot)
With 12.2 image: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... It boots normaly.
Any idea? Is there any change in MLO handling in factory? Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there?
Hexdump shows there is no MLO installed in raw image at offset 128k for Factory (contrary to 12.2 images). So, the script used (or script call) for factory seems to be buggy. Note that dd command seems ok in the script but I think it is never executed. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 08.10.2012, at 15:19, Guillaume Gardet wrote:
Le 05/10/2012 22:19, Alexander Graf a écrit :
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
Hi,
With latest factory: openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot)
With 12.2 image: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... It boots normaly.
Any idea? Is there any change in MLO handling in factory? Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there?
Hexdump shows there is no MLO installed in raw image at offset 128k for Factory (contrary to 12.2 images). So, the script used (or script call) for factory seems to be buggy. Note that dd command seems ok in the script but I think it is never executed.
Could you please try a local build and check why? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 08/10/2012 15:22, Alexander Graf a écrit :
On 08.10.2012, at 15:19, Guillaume Gardet wrote:
Le 05/10/2012 22:19, Alexander Graf a écrit :
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
Hi,
With latest factory: openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot)
With 12.2 image: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... It boots normaly.
Any idea? Is there any change in MLO handling in factory? Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there? Hexdump shows there is no MLO installed in raw image at offset 128k for Factory (contrary to 12.2 images). So, the script used (or script call) for factory seems to be buggy. Note that dd command seems ok in the script but I think it is never executed. Could you please try a local build and check why?
I could but I do not how. I always use online OBS. Could you give me some hints/commands, please? Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 08.10.2012, at 15:34, Guillaume Gardet wrote:
Le 08/10/2012 15:22, Alexander Graf a écrit :
On 08.10.2012, at 15:19, Guillaume Gardet wrote:
Le 05/10/2012 22:19, Alexander Graf a écrit :
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
Hi,
With latest factory: openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot)
With 12.2 image: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... It boots normaly.
Any idea? Is there any change in MLO handling in factory? Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there? Hexdump shows there is no MLO installed in raw image at offset 128k for Factory (contrary to 12.2 images). So, the script used (or script call) for factory seems to be buggy. Note that dd command seems ok in the script but I think it is never executed. Could you please try a local build and check why?
I could but I do not how. I always use online OBS. Could you give me some hints/commands, please?
$ osc co openSUSE:Factory:ARM JeOS $ cd openSUSE:Factory:ARM JeOS $ osc build JeOS-beagle.kiwi images armv7l :) The MLO configuration is all in external scripts in that directory, so you can hopefully add debugging to them there. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 08/10/2012 15:41, Alexander Graf a écrit :
On 08.10.2012, at 15:34, Guillaume Gardet wrote:
Le 08/10/2012 15:22, Alexander Graf a écrit :
On 08.10.2012, at 15:19, Guillaume Gardet wrote:
Le 05/10/2012 22:19, Alexander Graf a écrit :
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
Hi,
With latest factory: openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot)
With 12.2 image: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... It boots normaly.
Any idea? Is there any change in MLO handling in factory? Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there? Hexdump shows there is no MLO installed in raw image at offset 128k for Factory (contrary to 12.2 images). So, the script used (or script call) for factory seems to be buggy. Note that dd command seems ok in the script but I think it is never executed. Could you please try a local build and check why? I could but I do not how. I always use online OBS. Could you give me some hints/commands, please? $ osc co openSUSE:Factory:ARM JeOS $ cd openSUSE:Factory:ARM JeOS $ osc build JeOS-beagle.kiwi images armv7l Thanks.
Note that the last command give me one error. If I use instead "osc build images armv7l JeOS-beagle.kiwi", it starts to build normally.
:)
The MLO configuration is all in external scripts in that directory, so you can hopefully add debugging to them there.
Ok. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 08.10.2012, at 15:47, Guillaume Gardet wrote:
Le 08/10/2012 15:41, Alexander Graf a écrit :
On 08.10.2012, at 15:34, Guillaume Gardet wrote:
Le 08/10/2012 15:22, Alexander Graf a écrit :
On 08.10.2012, at 15:19, Guillaume Gardet wrote:
Le 05/10/2012 22:19, Alexander Graf a écrit :
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
> Hi, > > With latest factory: > openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz > Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot) > > With 12.2 image: > http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... > It boots normaly. > > Any idea? Is there any change in MLO handling in factory? Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there? Hexdump shows there is no MLO installed in raw image at offset 128k for Factory (contrary to 12.2 images). So, the script used (or script call) for factory seems to be buggy. Note that dd command seems ok in the script but I think it is never executed. Could you please try a local build and check why? I could but I do not how. I always use online OBS. Could you give me some hints/commands, please? $ osc co openSUSE:Factory:ARM JeOS $ cd openSUSE:Factory:ARM JeOS $ osc build JeOS-beagle.kiwi images armv7l Thanks.
Note that the last command give me one error. If I use instead "osc build images armv7l JeOS-beagle.kiwi", it starts to build normally.
Oops, sorry :)
:)
The MLO configuration is all in external scripts in that directory, so you can hopefully add debugging to them there.
Ok.
Thanks a lot! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 08/10/2012 15:22, Alexander Graf a écrit :
On 08.10.2012, at 15:19, Guillaume Gardet wrote:
Le 05/10/2012 22:19, Alexander Graf a écrit :
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
Hi,
With latest factory: openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot)
With 12.2 image: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... It boots normaly.
Any idea? Is there any change in MLO handling in factory? Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there? Hexdump shows there is no MLO installed in raw image at offset 128k for Factory (contrary to 12.2 images). So, the script used (or script call) for factory seems to be buggy. Note that dd command seems ok in the script but I think it is never executed. 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? Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 08.10.2012, at 17:51, Guillaume Gardet wrote:
Le 08/10/2012 15:22, Alexander Graf a écrit :
On 08.10.2012, at 15:19, Guillaume Gardet wrote:
Le 05/10/2012 22:19, Alexander Graf a écrit :
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
Hi,
With latest factory: openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot)
With 12.2 image: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... It boots normaly.
Any idea? Is there any change in MLO handling in factory? Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there? Hexdump shows there is no MLO installed in raw image at offset 128k for Factory (contrary to 12.2 images). So, the script used (or script call) for factory seems to be buggy. Note that dd command seems ok in the script but I think it is never executed. 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. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 08/10/2012 21:06, Alexander Graf a écrit :
On 08.10.2012, at 17:51, Guillaume Gardet wrote:
Le 08/10/2012 15:22, Alexander Graf a écrit :
On 08.10.2012, at 15:19, Guillaume Gardet wrote:
Le 05/10/2012 22:19, Alexander Graf a écrit :
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
Hi,
With latest factory: openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot)
With 12.2 image: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... It boots normaly.
Any idea? Is there any change in MLO handling in factory? Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there? Hexdump shows there is no MLO installed in raw image at offset 128k for Factory (contrary to 12.2 images). So, the script used (or script call) for factory seems to be buggy. Note that dd command seems ok in the script but I think it is never executed. 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.
Ok, done. I submitted a merge request: https://build.opensuse.org/request/show/137561 Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 09.10.2012, at 11:11, Guillaume Gardet wrote:
Le 08/10/2012 21:06, Alexander Graf a écrit :
On 08.10.2012, at 17:51, Guillaume Gardet wrote:
Le 08/10/2012 15:22, Alexander Graf a écrit :
On 08.10.2012, at 15:19, Guillaume Gardet wrote:
Le 05/10/2012 22:19, Alexander Graf a écrit :
On 05.10.2012, at 18:11, Guillaume Gardet wrote:
> Hi, > > With latest factory: > openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build41.2.raw.xz > Beagleboard xM does not boot because no MLO is found. (60 is written on serial port which means no MLO on SD, trying UART boot) > > With 12.2 image: > http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/openSUS... > It boots normaly. > > Any idea? Is there any change in MLO handling in factory? Hrm. We switched from in-kiwi boot loader scripts to external ones provided in the image description, to enable us to support more boards in the future without modifying kiwi every time. Maybe something broke along there? Hexdump shows there is no MLO installed in raw image at offset 128k for Factory (contrary to 12.2 images). So, the script used (or script call) for factory seems to be buggy. Note that dd command seems ok in the script but I think it is never executed. 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.
Ok, done. I submitted a merge request: https://build.opensuse.org/request/show/137561
Perfect :). I accepted it, so we should have working images again soon. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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. 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 - 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)] - 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] ... - now kiwi calls the post bootloader install script within the context of the tmpdir. In this example: 'cd /tmp/kiwiboot.w9zWIv && bash --norc -c ...' 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 All that worked in my test build. What's different when the buildservice does it ? hardcoding abs paths is not a solution not even a hacky one :) This will cause us more trouble than everything else Thanks Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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
Hi,
- 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?
I just wanted to show an example, because I can easily test with panda I choosed this one. Of course you are right when building for a beagle board x-loader-omap3beagle would be used here. But the process is the same concerning the MLO install
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
This is nothing you can see in your build log. fetch the created initrd cpio and test if the MLO is inside: I'm pretty sure it's missing because I can't see any MLO reference in your log. Does x-loader-omap3beagle also provide /boot/MLO in the same way e.g u-boot-omap4panda does ? kiwi atm searches only for boot/MLO
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 ?
I'm building for beagle now and test if I can reproduce it Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 09/10/2012 14:59, Marcus Schäfer a écrit :
Hi,
- 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? I just wanted to show an example, because I can easily test with panda I choosed this one. Of course you are right when building for a beagle board x-loader-omap3beagle would be used here. But the process is the same concerning the MLO install
I do not know the kiwi magic, so I suppose it is the same process. ;)
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 This is nothing you can see in your build log. fetch the created initrd cpio and test if the MLO is inside: I'm pretty sure it's missing because I can't see any MLO reference in your log.
Yes, the command gzip -cd ./build-root/usr/src/packages/KIWI-oem/initrd-oemboot-suse-12.2.armv7l-2.7.1.gz | cpio -it | grep MLO returned only: 129939 blocs
Does x-loader-omap3beagle also provide /boot/MLO in the same way e.g u-boot-omap4panda does ? kiwi atm searches only for boot/MLO
It installs it in /boot/MLO. See: https://build.opensuse.org/package/view_file?file=x-loader-omap3beagle.spec&package=x-loader-omap3beagle&project=openSUSE%3AFactory%3AARM&rev=129826a296d2cbef30e4225a4e1525d9
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 ? I'm building for beagle now and test if I can reproduce it
Ok. Thanks. Guillaume
Regards, Marcus
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
For beagleboard, it is provided by x-loader-omap3beagle, not u-boot. Maybe the problem is here?
Hmm, also my beagle test build worked. When I compared your log with mine it's different here: Copying boot image to disk EXEC [blkid /dev/mapper/loop0p1 2>&1] EXEC [blkid -o value -s TYPE /dev/mapper/loop0p1] EXEC [mount /dev/mapper/loop0p1 /tmp/kiwiloop.GcVSTY 2>&1] EXEC [cp -dR /tmp/kiwiboot.IXTKqd/boot /tmp/kiwiloop.GcVSTY 2>&1] EXEC [mv /tmp/kiwiloop.GcVSTY/boot/boot.scr /tmp/kiwiloop.GcVSTY] EXEC [mv /tmp/kiwiloop.GcVSTY/boot/u-boot.bin /tmp/kiwiloop.GcVSTY] EXEC [mv /tmp/kiwiloop.GcVSTY/boot/MLO /tmp/kiwiloop.GcVSTY] In your log only the boot.scr is found but no u-boot.bin and no MLO which means they are not part of the generated initrd. To me it looks like you did not boot include those packages. The following is from the kiwi-templates arm JeOS example: <packages type="bootstrap" profiles="beagleFlavour"> <package name="kernel-omap2plus" bootinclude="true"/> <package name="u-boot-omap3beagle" bootinclude="true"/> <package name="x-loader-omap3beagle" bootinclude="true"/> </packages> The bootinclude make sure they are installed when kiwi builds the initrd too. In your log they are installed only into the system image Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 09/10/2012 15:15, Marcus Schäfer a écrit :
Hi,
For beagleboard, it is provided by x-loader-omap3beagle, not u-boot. Maybe the problem is here? Hmm, also my beagle test build worked. When I compared your log with mine it's different here:
Copying boot image to disk EXEC [blkid /dev/mapper/loop0p1 2>&1] EXEC [blkid -o value -s TYPE /dev/mapper/loop0p1] EXEC [mount /dev/mapper/loop0p1 /tmp/kiwiloop.GcVSTY 2>&1] EXEC [cp -dR /tmp/kiwiboot.IXTKqd/boot /tmp/kiwiloop.GcVSTY 2>&1] EXEC [mv /tmp/kiwiloop.GcVSTY/boot/boot.scr /tmp/kiwiloop.GcVSTY] EXEC [mv /tmp/kiwiloop.GcVSTY/boot/u-boot.bin /tmp/kiwiloop.GcVSTY] EXEC [mv /tmp/kiwiloop.GcVSTY/boot/MLO /tmp/kiwiloop.GcVSTY]
In your log only the boot.scr is found but no u-boot.bin and no MLO which means they are not part of the generated initrd. To me it looks like you did not boot include those packages. The following is from the kiwi-templates arm JeOS example:
<packages type="bootstrap" profiles="beagleFlavour"> <package name="kernel-omap2plus" bootinclude="true"/> <package name="u-boot-omap3beagle" bootinclude="true"/> <package name="x-loader-omap3beagle" bootinclude="true"/> </packages>
Well, you got it. bootinclude is missing. I will submit a new merge request reverting my previous patch and adding bootinclude for u-boot and x-loader.
The bootinclude make sure they are installed when kiwi builds the initrd too. In your log they are installed only into the system image
Thanks. Guillaume
Regards, Marcus
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
<packages type="bootstrap" profiles="beagleFlavour"> <package name="kernel-omap2plus" bootinclude="true"/> <package name="u-boot-omap3beagle" bootinclude="true"/> <package name="x-loader-omap3beagle" bootinclude="true"/> </packages>
Well, you got it. bootinclude is missing. I will submit a new merge request reverting my previous patch and adding bootinclude for u-boot and x-loader.
cool, thanks for your effort... I hope it will boot ;) Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 09/10/2012 15:26, Marcus Schäfer a écrit :
Hi,
<packages type="bootstrap" profiles="beagleFlavour"> <package name="kernel-omap2plus" bootinclude="true"/> <package name="u-boot-omap3beagle" bootinclude="true"/> <package name="x-loader-omap3beagle" bootinclude="true"/> </packages> Well, you got it. bootinclude is missing. I will submit a new merge request reverting my previous patch and adding bootinclude for u-boot and x-loader. cool, thanks for your effort... I hope it will boot ;)
Yes, It boots! Thanks. :) Merge request have been accepted: https://build.opensuse.org/request/show/137609 Now I am facing other problems but it will be another thread! ;) Guillaume
Regards, Marcus
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
cool, thanks for your effort... I hope it will boot ;)
Yes, It boots! Thanks. :)
nice :)
Now I am facing other problems but it will be another thread! ;)
yep as usual, hope we can sort them out too Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (3)
-
Alexander Graf -
Guillaume Gardet -
Marcus Schäfer