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