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: [email protected] To contact the owner, e-mail: [email protected]
