Le 29/10/2013 10:59, Marcus Schäfer a écrit :

Hi,

...

As you can see here: https://build.opensuse.org/project/monitor/openSUSE:13.1:Ports

armv7 images are still broken with the same error message as in Factory some time ago (which should have been fixed): "Couldn't find kernel file": Because SUSE has so many different kernel layouts, kernel image types and names over all the supported architectures kiwi tries to map them and create a .kernel link. This works in the following way:

in /usr/share/kiwi/modules/KIWIConfig.sh::suseStripKernel() there is among other parts the code which moves the kernel file to a uniq name (vmlinuz)

#========================================== # create common kernel files, last wins ! #------------------------------------------ ...for arm we added some time ago:

if [ -f uImage-$VERSION ];then mv uImage-$VERSION vmlinuz elif [[ $arch =~ ^arm ]] && [ -f zImage-$VERSION ];then mv zImage-$VERSION vmlinuz elif [[ $arch =~ ^arm ]] && [ -f Image-$VERSION ];then mv Image-$VERSION vmlinuz ...

whenever the layout or the name of the kernel changes I need to adapt this. My first guess is, this is what happened

if the mapping failed the function:

/usr/share/kiwi/modules/KIWIImage.pm::extractLinux()

will not be able to extract the maped kernel file and thus the link will not exist which in the end leads to the error you are facing

if you can tell me which kernels we support for 13.1 on arm and what names and image types we will use I can fix this

Now, most images are zImage. We may still have also uImage for some boards. Guillaume

Regards, Marcus

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 29/10/2013 11:50, Marcus Schäfer a écrit :

Hi,

...

...

if you can tell me which kernels we support for 13.1 on arm and what names and image types we will use I can fix this Now, most images are zImage. We may still have also uImage for some boards. ok, I will run a test build. I saw for e.g the panda board we use the unified 'kernel-default' and no longer 'kernel-omap2plus'

Yes, the aim is to have all (or at least most) boards using kernel-default.

I guess this applies to some boards. So with 13.1 do we still have special kernel packages ? I still see

kernel-raspberrypi

Yes, raspberrypi is not yet fully upstream.

kernel-chromebook

I think Chromebook upstream support is still in an early stage. So, yes, we are using a custom kernel.

kernel-efikamx

efikamx needs a patch on top of kernel-default since it have been dropped from upstream kernel.

kernel-exynos

This one is used for Arndaleboard. Not sure what is upstream support. Alex, any idea?

kernel-cubox

I think upstream kernel has no video output support for Cubox. (A little bit annoying for a board designed to be a media center. ;) )

more ?

I would say sunxi kernel for cubieboards and maybe also ArmstoneA8 and Tegra. (In devel:ARM:*:Contrib:* repos). Guillaume

Thanks

Regards, Marcus

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

El 2013-10-29 12:03, Guillaume Gardet escribió:

Le 29/10/2013 11:50, Marcus Schäfer a écrit :

...

more ?

I would say sunxi kernel for cubieboards and maybe also ArmstoneA8 and Tegra. (In devel:ARM:*:Contrib:* repos).

Guillaume

Please, add kernel-sun7i to the list. I'm building kernel-sun7i from the linux-sunxi project since the code for the A20 SoC is not fully upstream. Oscar -- Cheers -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi Marcus, Le 29/10/2013 10:59, Marcus Schäfer a écrit :

Hi,

...

As you can see here: https://build.opensuse.org/project/monitor/openSUSE:13.1:Ports

armv7 images are still broken with the same error message as in Factory some time ago (which should have been fixed): "Couldn't find kernel file": Because SUSE has so many different kernel layouts, kernel image types and names over all the supported architectures kiwi tries to map them and create a .kernel link. This works in the following way:

in /usr/share/kiwi/modules/KIWIConfig.sh::suseStripKernel() there is among other parts the code which moves the kernel file to a uniq name (vmlinuz)

#========================================== # create common kernel files, last wins ! #------------------------------------------ ...for arm we added some time ago:

if [ -f uImage-$VERSION ];then mv uImage-$VERSION vmlinuz elif [[ $arch =~ ^arm ]] && [ -f zImage-$VERSION ];then mv zImage-$VERSION vmlinuz elif [[ $arch =~ ^arm ]] && [ -f Image-$VERSION ];then mv Image-$VERSION vmlinuz ...

whenever the layout or the name of the kernel changes I need to adapt this. My first guess is, this is what happened

if the mapping failed the function:

/usr/share/kiwi/modules/KIWIImage.pm::extractLinux()

will not be able to extract the maped kernel file and thus the link will not exist which in the end leads to the error you are facing

if you can tell me which kernels we support for 13.1 on arm and what names and image types we will use I can fix this

Your kiwi patch in 13.1:Ports did not fix it (see [0]) and now armv6 also fails on kernel extraction, see [1]. [0]: https://build.opensuse.org/package/live_build_log/openSUSE:13.1:Ports/JeOS-p... [1]: https://build.opensuse.org/package/live_build_log/devel:ARM:13.1:Contrib:Ras... Guillaume

Regards, Marcus

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi,

...

Your kiwi patch in 13.1:Ports did not fix it (see [0]) and now armv6 also fails on kernel extraction, see [1].

I'm working on this one and will come up with a patch today

I submitted a patch to kiwi and tested a build hope we get back on track soon Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --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 30/10/2013 10:54, Marcus Schäfer a écrit :

Hi,

...

Your kiwi patch in 13.1:Ports did not fix it (see [0]) and now armv6 also fails on kernel extraction, see [1]. I'm working on this one and will come up with a patch today

Seems your new patch does not help armv7 images. :( Guillaume

Regards, Marcus

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 30/10/2013 17:23, Marcus Schäfer a écrit :

Hi,

...

Seems your new patch does not help armv7 images. :( I did not get any feedback from Dirk that the patch is really active. Are you sure the change was applied somewhere in the buildservice space ?

I have it all up and running building armv7l images on my panda board, tested kernels: kernel-default and kernel-exynos

Kiwi seems to have been updated by Dirk: https://build.opensuse.org/package/rdiff/openSUSE:13.1:Ports/kiwi?linkrev=base&rev=2 But still fails: https://build.opensuse.org/package/live_build_log/openSUSE:13.1:Ports/JeOS-p... Maybe Dirk missed some patches? Guillaume

puzzled Marcus

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi, Le 30/10/2013 17:43, Marcus Schäfer a écrit :

Hi,

...

Kiwi seems to have been updated by Dirk: https://build.opensuse.org/package/rdiff/openSUSE:13.1:Ports/kiwi?linkrev=base&rev=2 yes I just checked out the project and saw this too, that looks good to me

...

But still fails: https://build.opensuse.org/package/live_build_log/openSUSE:13.1:Ports/JeOS-p... I also see other logs which fails for another reason, VM killed while calling a 'cat' command...

Checked just now and it seems that kernel problem is fixed but our workers are missing a kernel module: ******************************************************************************** [ 1032s] Oct-30 21:46:43 <1> : Creating ext4 root filesystem [ 1032s] Oct-30 21:46:43 <1> : EXEC [mkfs.ext4 -F -O resize_inode -N 49024 /dev/mapper/loop0p2 2>&1] [ 1033s] Oct-30 21:46:43 <1> : EXEC [/sbin/tune2fs -c 0 -i 0 /dev/mapper/loop0p2 2>&1] [ 1033s] Oct-30 21:46:43 <1> : EXEC [blkid /dev/mapper/loop0p2 2>&1] [ 1033s] Oct-30 21:46:43 <1> : EXEC [pvs --noheadings -o vg_name /dev/mapper/loop0p2 2>/dev/null] [ 1033s] Oct-30 21:46:43 <1> : EXEC [blkid -o value -s TYPE /dev/mapper/loop0p2] [ 1033s] Oct-30 21:46:44 <1> : EXEC [mount -o noatime,nobarrier /dev/mapper/loop0p2 /tmp/kiwiloop.aTi1gb 2>&1] [ 1033s] EXT4-fs (dm-1): Filesystem with huge files cannot be mounted RDWR without CONFIG_LBDAF [ 1033s] Oct-30 21:46:44 <3> : Failed to mount /dev/mapper/loop0p2 to: /tmp/kiwiloop.aTi1gb: mount: wrong fs type, bad option, bad superblock on /dev/mapper/loop0p2, [ 1033s] missing codepage or helper program, or other error [ 1033s] [ 1033s] In some cases useful info is found in syslog - try [ 1033s] dmesg | tail or so. ******************************************************************************** I am trying a local build to see if I can build the image. If so, we should ask Adrian to add: * codepage cp437 : for FAT32 support for ARMv6 images * CONFIG_LBDAF : for armv7 images But before, let see if I can build it locally. Guillaume

I searched the entire log from the above build for the newly added error message if the kernel was not found. This message is not part of the log but it has to be there if the mapping has failed. Thus I still think this build did not use the kiwi with the patch

...

Maybe Dirk missed some patches? don't think so

Regards, Marcus

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 31/10/2013 10:06, Marcus Schäfer a écrit :

Hi,

...

Checked just now and it seems that kernel problem is fixed but our workers are missing a kernel module: yep these part is fixed and I also was able to build with osc on a host machine. But the worker seems to be different.

Yes, JeOS-highbank is built. Panda is currently building and beagle need to be rebuilt. But it seems to be good! :) Now, we maybe could enable XFCE and E17 images? Dirk? Guillaume

...

******************************************************************************** [ 1032s] Oct-30 21:46:43 <1> : Creating ext4 root filesystem [ 1032s] Oct-30 21:46:43 <1> : EXEC [mkfs.ext4 -F -O resize_inode -N 49024 /dev/mapper/loop0p2 2>&1] [ 1033s] Oct-30 21:46:43 <1> : EXEC [/sbin/tune2fs -c 0 -i 0 /dev/mapper/loop0p2 2>&1] [ 1033s] Oct-30 21:46:43 <1> : EXEC [blkid /dev/mapper/loop0p2 2>&1] [ 1033s] Oct-30 21:46:43 <1> : EXEC [pvs --noheadings -o vg_name /dev/mapper/loop0p2 2>/dev/null] [ 1033s] Oct-30 21:46:43 <1> : EXEC [blkid -o value -s TYPE /dev/mapper/loop0p2] [ 1033s] Oct-30 21:46:44 <1> : EXEC [mount -o noatime,nobarrier /dev/mapper/loop0p2 /tmp/kiwiloop.aTi1gb 2>&1] [ 1033s] EXT4-fs (dm-1): Filesystem with huge files cannot be mounted RDWR without CONFIG_LBDAF [ 1033s] Oct-30 21:46:44 <3> : Failed to mount /dev/mapper/loop0p2 to: /tmp/kiwiloop.aTi1gb: mount: wrong fs type, bad option, bad superblock on /dev/mapper/loop0p2, [ 1033s] missing codepage or helper program, or other error [ 1033s] [ 1033s] In some cases useful info is found in syslog - try [ 1033s] dmesg | tail or so. ********************************************************************************

I am trying a local build to see if I can build the image. If so, we should ask Adrian to add: * codepage cp437 : for FAT32 support for ARMv6 images * CONFIG_LBDAF : for armv7 images yes I'm in contact with Dirk to find a solution for this one.

...

But before, let see if I can build it locally. as I said that worked fine for me, hope for you too :)

Regards, Marcus

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi,

I am testing images built by OBS.

On the beagleboard xM, I cannot boot using the linux.vmx file because it is not recognized as a zImage file. I get this error in u-boot: "Bad Linux ARM zImage magic!"

wait I was told by Alex that mkinitrd uses the vmlinux-*.gz variant of the kernel and not the zImage. Because of that information I intentionally changed the behavior ?? So what ? Alex ? Thanks Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --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

Hi,

I do not know about mkinitrd but what I know is that u-boot needs uImage or zImage type to be able to boot.

ok that's a clear statement, I will change it in kiwi now despite the information with regards to mkinitrd... maybe that part needs to be fixed too Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --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

Hi,

...

...

I do not know about mkinitrd but what I know is that u-boot needs uImage or zImage type to be able to boot. ok that's a clear statement, I will change it in kiwi now despite the information with regards to mkinitrd... maybe that part needs to be fixed too

Ok. Change it and let's see what happens with mkinitrd.

yep, done I will submit a new kiwi today, after my last test with the origen board. Dirk will pick up the new version and submit it to 13.1/Ports afterwards Regards, Marcus -- Public Key available gpg --keyserver pgp.mit.edu --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 31/10/2013 14:41, Marcus Schäfer a écrit :

Hi,

...

...

...

I do not know about mkinitrd but what I know is that u-boot needs uImage or zImage type to be able to boot. ok that's a clear statement, I will change it in kiwi now despite the information with regards to mkinitrd... maybe that part needs to be fixed too Ok. Change it and let's see what happens with mkinitrd. yep, done

I will submit a new kiwi today, after my last test with the origen board. Dirk will pick up the new version and submit it to 13.1/Ports afterwards

There is no new kiwi in 13.1:Ports but only in Virtualization:Appliances. Could you submit it to 13.1:Ports, please? Dirk, kiwi from Factory:ARM is broken because of a conflict. Could you fix it, please? Guillaume

Regards, Marcus

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 04.11.2013, at 11:52, Marcus Schäfer wrote:

Hi,

...

There is no new kiwi in 13.1:Ports but only in Virtualization:Appliances. Could you submit it to 13.1:Ports, please?

I have no permissions to do this, Dirk normally fetches from Virt:App

Does it include all patches from https://build.opensuse.org/package/show/openSUSE:13.1:Ports/kiwi ? If so, I can copypac the Virtualization:Appliances kiwi into 13.1:Ports. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 04.11.2013, at 12:39, Guillaume Gardet wrote:

Le 04/11/2013 12:22, Alexander Graf a écrit :

...

On 04.11.2013, at 11:52, Marcus Schäfer wrote:

...

Hi,

...

There is no new kiwi in 13.1:Ports but only in Virtualization:Appliances. Could you submit it to 13.1:Ports, please? I have no permissions to do this, Dirk normally fetches from Virt:App Does it include all patches from

https://build.opensuse.org/package/show/openSUSE:13.1:Ports/kiwi

? If so, I can copypac the Virtualization:Appliances kiwi into 13.1:Ports.

I think so.

Ok, I copied it over. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi Dirk, Le 07/11/2013 02:46, Dirk Müller a écrit :

Hi Guillaume,

...

There is no new kiwi in 13.1:Ports but only in Virtualization:Appliances. I did backport Marcus fixes to the 13.1 kiwi version. was there a problem with that one?

Yes, Marcus made other patches after your backports, but it is fixed now.

...

Dirk, kiwi from Factory:ARM is broken because of a conflict. Could you fix it, please? Done.

Thanks. Guillaume

Greetings, Dirk

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 31/10/2013 10:06, Marcus Schäfer a écrit :

Hi,

...

Checked just now and it seems that kernel problem is fixed but our workers are missing a kernel module: yep these part is fixed and I also was able to build with osc on a host machine. But the worker seems to be different.

It is fixed for officials repos workers but workers used for home repos are still broken. Dirk, could you have a look at it, please? Guillaume

...

******************************************************************************** [ 1032s] Oct-30 21:46:43 <1> : Creating ext4 root filesystem [ 1032s] Oct-30 21:46:43 <1> : EXEC [mkfs.ext4 -F -O resize_inode -N 49024 /dev/mapper/loop0p2 2>&1] [ 1033s] Oct-30 21:46:43 <1> : EXEC [/sbin/tune2fs -c 0 -i 0 /dev/mapper/loop0p2 2>&1] [ 1033s] Oct-30 21:46:43 <1> : EXEC [blkid /dev/mapper/loop0p2 2>&1] [ 1033s] Oct-30 21:46:43 <1> : EXEC [pvs --noheadings -o vg_name /dev/mapper/loop0p2 2>/dev/null] [ 1033s] Oct-30 21:46:43 <1> : EXEC [blkid -o value -s TYPE /dev/mapper/loop0p2] [ 1033s] Oct-30 21:46:44 <1> : EXEC [mount -o noatime,nobarrier /dev/mapper/loop0p2 /tmp/kiwiloop.aTi1gb 2>&1] [ 1033s] EXT4-fs (dm-1): Filesystem with huge files cannot be mounted RDWR without CONFIG_LBDAF [ 1033s] Oct-30 21:46:44 <3> : Failed to mount /dev/mapper/loop0p2 to: /tmp/kiwiloop.aTi1gb: mount: wrong fs type, bad option, bad superblock on /dev/mapper/loop0p2, [ 1033s] missing codepage or helper program, or other error [ 1033s] [ 1033s] In some cases useful info is found in syslog - try [ 1033s] dmesg | tail or so. ********************************************************************************

I am trying a local build to see if I can build the image. If so, we should ask Adrian to add: * codepage cp437 : for FAT32 support for ARMv6 images * CONFIG_LBDAF : for armv7 images yes I'm in contact with Dirk to find a solution for this one.

...

But before, let see if I can build it locally. as I said that worked fine for me, hope for you too :)

Regards, Marcus

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 01/11/2013 13:05, Dirk Müller a écrit :

Hi Guillaume,

...

It is fixed for officials repos workers but workers used for home repos are still broken. Dirk, could you have a look at it, please? There is no differentiation between official and non-official workers. where did you see it failing (project/package)?

It was on a branched project, but it succeeds now, so that is fine. Guillaume

Thanks, Dirk

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org