Hi guys, Great news! Kudos to Adrian for getting some of the OBS internals to work with new kiwi, we have our first ARM image built with kiwi: http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/Lime... It's even using the brand new "tbz" image type, which means that the tarball you see there actually contains another tarball which contains a rootfs to play around with. You can use that with your own kernels, with our kernels, as chroot on your android system. Anything you can imagine! :) There are still some things to straighten out. We have to inject qemu into the target system to be able to build, but we really don't want to keep it around after building is finished. So we have to figure something there :). Also, I'm currently trying to get efika and panda images rolling. So far the initrd creation is missing qemu again, but that should only be a matter of tweaking a few things. And by then we should have kiwi images available for the public! Just in time for FOSDEM! Yay! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 02.02.2012, at 01:33, Alexander Graf wrote:
Hi guys,
Great news! Kudos to Adrian for getting some of the OBS internals to work with new kiwi, we have our first ARM image built with kiwi:
http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/Lime...
It's even using the brand new "tbz" image type, which means that the tarball you see there actually contains another tarball which contains a rootfs to play around with. You can use that with your own kernels, with our kernels, as chroot on your android system. Anything you can imagine! :)
There are still some things to straighten out. We have to inject qemu into the target system to be able to build, but we really don't want to keep it around after building is finished. So we have to figure something there :).
Also, I'm currently trying to get efika and panda images rolling. So far the initrd creation is missing qemu again, but that should only be a matter of tweaking a few things. And by then we should have kiwi images available for the public! Just in time for FOSDEM! Yay!
Ok, so I got things fixed up far enough to have the initrd be built properly, fixed a few qemu bugs along the way that get lvm working and now I'm stuck here:
Feb-02 03:10:53 <1> : Set boot space to: 64M
Our /boot is 64MB (I think that was one of the odd constraints we had from omap)
Feb-02 03:10:53 <1> : EXEC [find /usr/src/packages/KIWIROOT-vmx | wc -l] Feb-02 03:10:54 <1> : EXEC [du -s --block-size=1 /usr/src/packages/KIWIROOT-vmx | cut -f1] Feb-02 03:10:55 <1> : Starting with disk size: 503M Feb-02 03:10:55 <1> : Using 32192 inodes for the root filesystem Feb-02 03:10:55 <1> : EXEC [uname -m] Feb-02 03:10:56 <1> : Creating initial boot structureFeb-02 03:10:56 <1> : EXEC [mkdir -p /tmp/kiwiboot.ohSml2/boot 2>&1] Feb-02 03:10:56 <1> : EXEC [cp /usr/src/packages/KIWI-vmx/initrd-vmxboot-suse-SLES12.armv7l-2.7.1.splash.gz /tmp/kiwiboot.ohSml2/boot/initrd.vmx 2>&1] Feb-02 03:10:56 <1> : EXEC [cp /usr/src/packages/KIWI-vmx/initrd-vmxboot-suse-SLES12.armv7l-2.7.1.kernel.no-version-found /tmp/kiwiboot.ohSml2/boot/linux.vmx 2>&1] done Feb-02 03:10:57 <1> : Increasing disk size by 64M to: 567M Feb-02 03:10:57 <1> : EXEC [mkdir -p /tmp/kiwiboot.ohSml2/boot 2>&1] Feb-02 03:10:57 <1> : Importing uboot loadersFeb-02 03:10:57 <1> : EXEC [gzip -9 -cd /usr/src/packages/KIWI-vmx/initrd-vmxboot-suse-SLES12.armv7l-2.7.1.splash.gz 2>&1 | (cd /tmp/kiwiboot.ohSml2 && cpio -di 'image/loader/*' 2>&1)] skipped Feb-02 03:11:04 <1> : EXEC [rm -rf /tmp/kiwiboot.ohSml2/image 2>&1] Feb-02 03:11:04 <1> : Additional commandline options: "console=ttymxc0"Feb-02 03:11:04 <1> : Saving disk label on disk: 0x54813fdb...Feb-02 03:11:04 <1> : EXEC [mkdir -p /tmp/kiwiboot.ohSml2/boot/grub] done Feb-02 03:11:04 <1> : Creating uBoot initrd image...Feb-02 03:11:04 <1> : EXEC [mkimage -A arm -O linux -T ramdisk -C none -a 0x0 -e 0x0 -n 'Initrd' -d /tmp/kiwiboot.ohSml2/boot/initrd.vmx /tmp/kiwiboot.ohSml2/boot/initrd.uboot]
So now we have the initrd twice in /boot, right? Once as initrd.gz and once as initrd.uboot.
done Feb-02 03:11:05 <1> : Creating boot.script uboot config file...Feb-02 03:11:05 <1> : EXEC [mkimage -A arm -O linux -a 0 -e 0 -T script -C none -n 'Boot-Script' -d /tmp/kiwiboot.ohSml2/boot/boot.script /tmp/kiwiboot.ohSml2/boot/boot.scr] done Feb-02 03:11:06 <1> : Creating virtual disk...Feb-02 03:11:06 <1> : EXEC [qemu-img create /usr/src/packages/KIWI-vmx/LimeJeOS-openSUSE-Factory-ARM.armv7l-1.12.1.raw 567M 2>&1] Feb-02 03:11:06 <1> : EXEC [/sbin/losetup -s -f /usr/src/packages/KIWI-vmx/LimeJeOS-openSUSE-Factory-ARM.armv7l-1.12.1.raw 2>&1] Feb-02 03:11:07 <1> : EXEC [which parted 2>&1] Feb-02 03:11:07 <1> : EXEC [which parted 2>&1] Feb-02 03:11:07 <1> : EXEC [dd if=/dev/zero of=/dev/loop2 bs=512 count=1 2>&1] Feb-02 03:11:08 <1> : EXEC [/usr/sbin/parted -s /dev/loop2 mklabel msdos 2>&1] Feb-02 03:11:08 <1> : EXEC [/usr/sbin/parted -m /dev/loop2 unit s print | head -n 3 | tail -n 1 | cut -f2 -d:] Unsupported ioctl: cmd=0x5331 (0) Unsupported ioctl: cmd=0x127a (0) Feb-02 03:11:09 <1> : Disk Sector count is: 1161215 Feb-02 03:11:09 <1> : Disk Cylinder size is: (1 * 1 * 512) 512 Bytes Feb-02 03:11:09 <1> : PARTED input: /dev/loop2 [mkpart primary 2048 133119] Feb-02 03:11:09 <1> : EXEC [/usr/sbin/parted -s /dev/loop2 unit s mkpart primary 2048 133119 2>&1] Feb-02 03:11:10 <1> : EXEC [which parted 2>&1] Feb-02 03:11:11 <1> : EXEC [/usr/sbin/parted -m /dev/loop2 unit s print | grep :2048 | cut -f3 -d:] Unsupported ioctl: cmd=0x5331 (0) Unsupported ioctl: cmd=0x127a (0) Feb-02 03:11:11 <1> : PARTED input: /dev/loop2 [mkpart primary 133120 1161215] Feb-02 03:11:11 <1> : EXEC [/usr/sbin/parted -s /dev/loop2 unit s mkpart primary 133120 1161215 2>&1] Feb-02 03:11:12 <1> : PARTED input: /dev/loop2 [set 1 type 0xc] Feb-02 03:11:12 <1> : EXEC [/usr/sbin/parted -s /dev/loop2 unit s set 1 type 0xc 2>&1] Feb-02 03:11:12 <1> : PARTED input: /dev/loop2 [set 2 type 0x8e] Feb-02 03:11:12 <1> : EXEC [/usr/sbin/parted -s /dev/loop2 unit s set 2 type 0x8e 2>&1] Feb-02 03:11:13 <1> : PARTED input: /dev/loop2 [set 1 boot on] Feb-02 03:11:13 <1> : EXEC [/usr/sbin/parted -s /dev/loop2 unit s set 1 boot on 2>&1] Feb-02 03:11:13 <1> : EXEC [/sbin/kpartx -a /dev/loop2 2>&1] Feb-02 03:11:13 <1> : EXEC [vgremove --force kiwiVG 2>&1] Feb-02 03:11:14 <1> : EXEC [test -d /dev/kiwiVG && rm -rf /dev/kiwiVG 2>&1] Feb-02 03:11:14 <1> : EXEC [pvcreate /dev/mapper/loop2p2 2>&1] Feb-02 03:11:15 <1> : EXEC [vgcreate kiwiVG /dev/mapper/loop2p2 2>&1] Feb-02 03:11:16 <1> : EXEC [lvcreate -l +100%FREE -n LVRoot kiwiVG 2>&1] done Feb-02 03:11:17 <1> : Creating ext3 root filesystemFeb-02 03:11:17 <1> : EXEC [mkfs.ext3 -i 16384 -F -O resize_inode -N 32192 /dev/kiwiVG/LVRoot 2>&1] done Feb-02 03:11:17 <1> : EXEC [dd if=/dev/kiwiVG/LVRoot bs=128k count=1 2>/dev/null | file -] Feb-02 03:11:18 <1> : EXEC [mount /dev/kiwiVG/LVRoot /tmp/kiwiloop.4KkehU 2>&1] Feb-02 03:11:18 <1> : Copying system image tree on diskFeb-02 03:11:18 <1> : EXEC [rsync -aHXA --one-file-system /usr/src/packages/KIWIROOT-vmx/ /tmp/kiwiloop.4KkehU 2>&1] done Feb-02 03:11:29 <1> : EXEC [sync] Feb-02 03:11:32 <1> : EXEC [umount /tmp/kiwiloop.4KkehU 2>&1] Feb-02 03:11:33 <1> : Creating DOS boot filesystemFeb-02 03:11:33 <1> : EXEC [/sbin/mkdosfs -F 32 -n 'boot' /dev/mapper/loop2p1 2>&1] done Feb-02 03:11:33 <1> : Copying boot image to diskFeb-02 03:11:33 <1> : EXEC [dd if=/dev/mapper/loop2p1 bs=128k count=1 2>/dev/null | file -] Feb-02 03:11:34 <1> : EXEC [dd if=/dev/mapper/loop2p1 bs=128k count=1 2>/dev/null | grep -q CLIC] Feb-02 03:11:34 <1> : EXEC [mount /dev/mapper/loop2p1 /tmp/kiwiloop.4KkehU 2>&1] Feb-02 03:11:35 <1> : EXEC [cp -dR /tmp/kiwiboot.ohSml2/boot /tmp/kiwiloop.4KkehU 2>&1] failed Feb-02 03:11:35 <3> : Couldn't copy boot data to system image: cp: writing `/tmp/kiwiloop.4KkehU/boot/initrd.vmx': No space left on device cp: failed to extend `/tmp/kiwiloop.4KkehU/boot/initrd.vmx': No space left on device cp: writing `/tmp/kiwiloop.4KkehU/boot/boot.scr': No space left on device cp: failed to extend `/tmp/kiwiloop.4KkehU/boot/boot.scr': No space left on device cp: writing `/tmp/kiwiloop.4KkehU/boot/linux.vmx': No space left on device cp: failed to extend `/tmp/kiwiloop.4KkehU/boot/linux.vmx': No space left on device failed Feb-02 03:11:35 <1> : EXEC [sync] Feb-02 03:11:37 <1> : EXEC [umount /tmp/kiwiloop.4KkehU 2>&1] Feb-02 03:11:37 <1> : EXEC [sync] Feb-02 03:11:38 <1> : EXEC [vgchange -an 2>&1] Feb-02 03:11:39 <1> : EXEC [dmsetup remove /dev/mapper/loop2p1 2>&1] Feb-02 03:11:39 <1> : EXEC [dmsetup remove /dev/mapper/loop2p2 2>&1] Feb-02 03:11:39 <1> : EXEC [/sbin/losetup -d /dev/loop2 2>&1] Feb-02 03:11:40 <1> : EXEC [rm -rf /tmp/kiwiboot.ohSml2 2>&1] Feb-02 03:11:40 <1> : EXEC [rm -rf /tmp/kiwiloop.4KkehU 2>&1] Feb-02 03:11:40 <3> : KIWI exited with error(s) done Feb-02 03:11:40 <1> : EXEC [umount /usr/src/packages/KIWI-vmx/mnt-19918 2>&1] Feb-02 03:11:41 <1> : EXEC [rm -rf /usr/src/packages/KIWI-vmx/boot-VMX.7Zxd39 2>&1] Feb-02 03:11:41 <1> : EXEC [umount /usr/src/packages/KIWI-vmx/mnt-19918 2>&1]
agraf@wichary:/abuild/agraf/openSUSE:Factory:ARM/JeOS-imx51> l -h /abuild/agraf/buildroot.JeOS-imx51//usr/src/packages/KIWI-vmx/ total 362M drwxr-xr-x 2 root root 456 Feb 2 04:11 ./ drwxr-xr-x 12 399 399 304 Feb 2 03:58 ../ -rw-r--r-- 1 root root 567M Feb 2 04:11 LimeJeOS-openSUSE-Factory-ARM.armv7l-1.12.1.raw -rw-r--r-- 1 root root 33M Feb 2 04:10 initrd-vmxboot-suse-SLES12.armv7l-2.7.1.gz
This beast is already 33MB. So by keeping it in /boot twice, we exceed the 64MB we have available. Any ideas? In the long run, we should definitely redesign the whole bootstrapping process. Having FAT partitions is just insane. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
Feb-02 03:10:53 <1> : Set boot space to: 64M
Our /boot is 64MB (I think that was one of the odd constraints we had from omap)
yes do you remember our session with Dirk :) 64M seems to be a must have. If you like to give it a test with another size check the code in /usr/share/kiwi/modules/KIWIBoot.pm:__getBootSize ... # on arm it's required to have a maximum of 64MB for the boot part if ($arch =~ /arm/) { $gotMB = 64; } I would love to get rid of this but so far it seems required
cp: writing `/tmp/kiwiloop.4KkehU/boot/boot.scr': No space left on device cp: failed to extend `/tmp/kiwiloop.4KkehU/boot/boot.scr': No space left on device cp: writing `/tmp/kiwiloop.4KkehU/boot/linux.vmx': No space left on device
*urks*
-rw-r--r-- 1 root root 33M Feb 2 04:10 initrd-vmxboot-suse-SLES12.armv7l-2.7.1.gz
This beast is already 33MB.
So by keeping it in /boot twice, we exceed the 64MB we have available. Any ideas? In the long run, we should definitely redesign the whole bootstrapping process. Having FAT partitions is just insane.
I added a patch to kiwi which only leaves the uboot variant on /boot commit: 0387c5660cf82d734d6650475bec19e681142e81 from master Hope this helps 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
On 02.02.2012, at 10:35, Marcus Schäfer <ms@suse.de> wrote:
Hi,
Feb-02 03:10:53 <1> : Set boot space to: 64M
Our /boot is 64MB (I think that was one of the odd constraints we had from omap)
yes do you remember our session with Dirk :) 64M seems to be a must have. If you like to give it a test with another size check the code in
/usr/share/kiwi/modules/KIWIBoot.pm:__getBootSize
... # on arm it's required to have a maximum of 64MB for the boot part if ($arch =~ /arm/) { $gotMB = 64; }
I would love to get rid of this but so far it seems required
cp: writing `/tmp/kiwiloop.4KkehU/boot/boot.scr': No space left on device cp: failed to extend `/tmp/kiwiloop.4KkehU/boot/boot.scr': No space left on device cp: writing `/tmp/kiwiloop.4KkehU/boot/linux.vmx': No space left on device
*urks*
-rw-r--r-- 1 root root 33M Feb 2 04:10 initrd-vmxboot-suse-SLES12.armv7l-2.7.1.gz
This beast is already 33MB.
So by keeping it in /boot twice, we exceed the 64MB we have available. Any ideas? In the long run, we should definitely redesign the whole bootstrapping process. Having FAT partitions is just insane.
I added a patch to kiwi which only leaves the uboot variant on /boot commit: 0387c5660cf82d734d6650475bec19e681142e81 from master
I bumped it to 128MB last night too see if it'd break somewhere else later and that gave me a successful build! Woot :) Adrian, in obs the build is failing due to: Feb-02 11:03:10 <3> : Failed to mount /dev/mapper/loop0p1 to: /tmp/kiwiloop.teKAej: Unsupported ioctl: cmd=0x5331 (0) mount: unknown filesystem type 'vfat' [80C[10D[1;31mfailed [mFeb-02 11:03:10 <1> : EXEC [sync] failed Feb-02 11:03:11 <3> : Couldn't mount image boot device: /dev/mapper/loop0p1 failed Any idea how to fix this? Apparently the kernel doesn't include vfat support without y module. But we can't use the arm modules here either. Marcus, could we have a flag that tells kiwi to create an ext3 partition for /boot instead of vfat? The efikas can already boot off that and I would like to get MLO to understand ext2 too, so we can just use that instead of vfat. We will have to create a different boot.scr depending on the choice though. Also, I just played a bit with efi on x86. There we create a mount point /boot/efi which contains elilo and the currently used kernels. Maybe that would be the way to go for arm too for now? Have a /boot/uboot directory that is our first partition and have perl-bootloader copy / mkuimage ther kernel / initrd over to that partition from /boot. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
Marcus, could we have a flag that tells kiwi to create an ext3 partition for /boot instead of vfat? The efikas can already boot off that and I would like to get MLO to understand ext2 too, so we can just use that instead of vfat. We will have to create a different boot.scr depending on the choice though.
Not at the moment. The code there looks like this: /usr/share/kiwi/modules/KIWIBoot.pm #========================================== # create bootloader filesystem if needed #------------------------------------------ ... if ($bootloader =~ /syslinux|uboot|yaboot/) { $kiwi -> info ("Creating DOS boot filesystem"); if ($bootloader eq "yaboot") { $status = qxx ("/sbin/mkdosfs -F 16 $boot 2>&1"); } else { $status = qxx ("/sbin/mkdosfs -F 32 -n 'boot' $boot 2>&1"); } so pretty much hardcoded. Feel free to change this for testing. If you just remove uboot from the if the default will be an ext3 boot partition
Also, I just played a bit with efi on x86. There we create a mount point /boot/efi which contains elilo and the currently used kernels. Maybe that would be the way to go for arm too for now? Have a /boot/uboot directory that is our first partition and have perl-bootloader copy / mkuimage ther kernel / initrd over to that partition from /boot.
I don't have support for efi in kiwi at the moment. I also would like to have this on x86 as most systems have a deactivated efi bios on board 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 (2)
-
Alexander Graf -
Marcus Schäfer