[opensuse-arm] 13.1 ARM images still broken. kiwi problem?
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": ********************************************************************** [ 248s] Oct-29 08:35:07 <1> : EXEC [touch /usr/src/packages/KIWI-oem/oem/plymouth.splash.active 2>&1] [ 248s] Oct-29 08:35:07 <1> : EXEC [umount /usr/src/packages/KIWI-oem/oem/boot-VMX.sYwlXQ/kiwi-VMXboot-4825//proc/sys/fs/binfmt_misc 2>&1] [ 248s] Oct-29 08:35:07 <1> : EXEC [umount /usr/src/packages/KIWI-oem/oem/boot-VMX.sYwlXQ/kiwi-VMXboot-4825//proc 2>&1] [ 248s] Oct-29 08:35:07 <1> : EXEC [umount /usr/src/packages/KIWI-oem/oem/boot-VMX.sYwlXQ/kiwi-VMXboot-4825//dev/pts 2>&1] [ 248s] Oct-29 08:35:07 <1> : EXEC [umount /usr/src/packages/KIWI-oem/oem/boot-VMX.sYwlXQ/kiwi-VMXboot-4825//sys 2>&1] [ 248s] Oct-29 08:35:07 <1> : EXEC [find /usr/src/packages/KIWI-oem/oem/boot-VMX.sYwlXQ/kiwi-VMXboot-4825 | wc -l] [ 248s] Oct-29 08:35:07 <1> : EXEC [du -s --block-size=1 /usr/src/packages/KIWI-oem/oem/boot-VMX.sYwlXQ/kiwi-VMXboot-4825 | cut -f1] [ 248s] Oct-29 08:35:07 <1> : EXEC [du -s --apparent-size --block-size=1 /usr/src/packages/KIWI-oem/oem/boot-VMX.sYwlXQ/kiwi-VMXboot-4825 | cut -f1] [ 249s] Oct-29 08:35:07 <1> : getSize: files: 5155 [ 249s] Oct-29 08:35:07 <1> : getSize: usage: 150364160 Bytes [ 249s] Oct-29 08:35:07 <1> : getSize: inode: 256 Bytes [ 249s] Oct-29 08:35:07 <1> : getSize: minsz: 318006784 Bytes [ 249s] Oct-29 08:35:07 <1> : Creating cpio archive... [ 249s] Oct-29 08:35:07 <1> : EXEC [pwd] [ 249s] Oct-29 08:35:07 <1> : EXEC [cd /usr/src/packages/KIWI-oem/oem/boot-VMX.sYwlXQ/kiwi-VMXboot-4825 && find . | cpio --create --format=newc --quiet | gzip -9 -f > /usr/src/packages/KIWI-oem/oem/initrd-oemboot-suse-13.1.armv7l-2.7.1.gz] [ 308s] Oct-29 08:36:07 <1> : Creating image MD5 sum... [ 308s] Oct-29 08:36:07 <1> : EXEC [factor 55525686] [ 309s] Oct-29 08:36:07 <1> : EXEC [cat /usr/src/packages/KIWI-oem/oem/initrd-oemboot-suse-13.1.armv7l-2.7.1.gz | md5sum - | cut -f 1 -d-] [ 309s] Oct-29 08:36:08 <1> : EXEC [echo "18f6e13e65005b25e125d96872a15948 9254281 6" > /usr/src/packages/KIWI-oem/oem/initrd-oemboot-suse-13.1.armv7l-2.7.1.md5] [ 309s] Oct-29 08:36:08 <1> : EXEC [rm -rf /usr/src/packages/KIWI-oem/oem/boot-VMX.sYwlXQ] [ 309s] Oct-29 08:36:08 <1> : Release package manager lock [ 309s] Oct-29 08:36:08 <1> : EXEC [rm -f /var/lock/kiwi-init.lock] [ 309s] Oct-29 08:36:08 <1> : Release package manager lock [ 309s] Oct-29 08:36:08 <1> : EXEC [rm -f /var/lock/kiwi-init.lock] [ 309s] Oct-29 08:36:08 <1> : EXEC [rm -f /var/cache/kiwi/zypper/zypper.conf.4825 /var/cache/kiwi/zypper/zypp.conf.4825] [ 309s] Oct-29 08:36:08 <3> : Couldn't find kernel file: /usr/src/packages/KIWI-oem/oem/initrd-oemboot-suse-13.1.armv7l-2.7.1.kernel [ 309s] Oct-29 08:36:08 <3> : KIWI exited with error(s) [ 309s] Oct-29 08:36:08 <1> : EXEC [rm -rf /usr/src/packages/KIWI-oem/oem/boot-VMX.sYwlXQ 2>&1] [ 311s] /.build/build: line 371: 1066 Killed background_monitor_process [ 313s] SysRq : Power Off [ 313s] Power down. ********************************************************************** armv7 rootfs images are fine. armv6 images are also fine locally but our worker kernel is missing FAT support: "FAT-fs (dm-0): codepage cp437 not found". Regards, Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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 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 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
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' I guess this applies to some boards. So with 13.1 do we still have special kernel packages ? I still see kernel-raspberrypi kernel-chromebook kernel-efikamx kernel-exynos kernel-cubox more ? 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
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
Hi,
kernel-exynos This one is used for Arndaleboard. Not sure what is upstream support. Alex, any idea?
It is based on upstream sources (with some small additional patches). I think it will remain as an additional flavor for now. Greetings, Dirk -- 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 Oscar,
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.
Where do you build the kernel? I'd like to include it in the Contrib project for sunxi. I have built a 12.3 based image that seems to work, but it seriously needs some adjustment still. Thanks, Dirk -- 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 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,
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 17:12, 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 I submitted a patch to kiwi and tested a build hope we get back on track soon
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 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
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 puzzled 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 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,
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... 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 -- 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, 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
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.
******************************************************************************** [ 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 -- 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 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 Marcus, 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.
******************************************************************************** [ 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 :)
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!" file command returns "linux.vmx: gzip compressed data, from Unix, max compression" whereas on a standard zImage, I get: "zImage-3.11.6-3-default: Linux kernel ARM boot executable zImage (little-endian)". So it is not the same file type. If I replace linux.vmx file by zImage, the kernel does boot. It does not go until linux prompt because of kernel problems but it is another story. So, I think your kiwi patch is missing something for zImage. Guillaume
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
Le 31/10/2013 14:08, Marcus Schäfer a écrit :
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 ??
I do not know about mkinitrd but what I know is that u-boot needs uImage or zImage type to be able to boot. Guillaume
So what ?
Alex ?
Thanks
Regards, Marcus
-- 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
Le 31/10/2013 14:22, 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. Guillaume
Regards, Marcus
-- 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
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
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
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 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
On 04.11.2013, at 11:52, Marcus Schäfer <ms@suse.de> 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
Le 04/11/2013 12:22, Alexander Graf a écrit :
On 04.11.2013, at 11:52, Marcus Schäfer <ms@suse.de> 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. Guillaume
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 <guillaume.gardet@free.fr> wrote:
Le 04/11/2013 12:22, Alexander Graf a écrit :
On 04.11.2013, at 11:52, Marcus Schäfer <ms@suse.de> 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 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?
Dirk, kiwi from Factory:ARM is broken because of a conflict. Could you fix it, please?
Done. Greetings, Dirk -- 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
Am 31.10.2013 um 06:08 schrieb Marcus Schäfer <ms@suse.de>:
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 ?
To boot, we need the zImage. To resolve the kernel version number, mkinitrd tries to fetch it from the zImage and then if that fails, fetches it from vmlinux.gz. Alex -- 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
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)? Thanks, Dirk -- 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
participants (5)
-
Alexander Graf -
Dirk Müller -
Guillaume Gardet -
Marcus Schäfer -
Oscar C