sagari has been pulled out of rotation, and will hopefully stay that way except in cases of dire need. Closing this out.
2016-08-16 10:03:43 Odd_Bloke infinity: We're seeing yakkety build failures because of sagari's old kernel. Do I need to re-upload our hack-around for that to our build PPA, or might you be able to upgrade that kernel soonish? 2016-08-16 10:04:15 infinity Odd_Bloke: Is trusty's new enough? 2016-08-16 10:04:38 Odd_Bloke infinity: I _think_ so. 2016-08-16 10:04:50 infinity Odd_Bloke: I'll file a ticket. 2016-08-16 10:05:31 Odd_Bloke Yeah, https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums suggests it landed in 3.6. 2016-08-16 10:07:14 infinity Oh, but we didn't do LTS backports on all arches in precise. That started in trusty. Grr. 2016-08-16 10:08:53 infinity Odd_Bloke: Unfortunately, the solution is going to be to either upgrade sagari entirely or pull it out of rotation. Less fun. 2016-08-16 10:09:16 Odd_Bloke Oh, that sucks. :( 2016-08-16 10:12:36 infinity Odd_Bloke: I'll pull it out of rotation for now, but no guarantees it'll stay that way if the queues get deep. 2016-08-16 10:14:34 Odd_Bloke infinity: OK, thanks. We can cope with it being in rotation if there's a queue, because we're less likely to get scheduled on it. :p 2016-08-16 10:16:10 infinity Odd_Bloke: Heh. I'll throw some hours later at parallelising my current builders a bit more to make it a non-issue. 2016-08-16 10:16:40 Odd_Bloke infinity: Thanks. <3 ** Changed in: cloud-images Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1598136 Title: Fails to produce a loop-mountable FS on powerpc/armhf Status in cloud-images: Fix Released Status in e2fsprogs package in Ubuntu: Invalid Bug description: In yakkety cloud image builds for each of powerpc and armhf (but not amd64, i386, ppc64el, arm64 or s390x) we see the following failure: [2016-07-01 09:51:08] lb_binary_chroot P: Begin copying chroot... [2016-07-01 09:51:08] lb_binary_rootfs P: Begin building root filesystem image... 0+0 records in 0+0 records out 0 bytes copied, 3.7116e-05 s, 0.0 kB/s mke2fs 1.43.1 (08-Jun-2016) ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether binary/boot/filesystem.ext4 is mounted. Suggestion: Use Linux kernel >= 3.18 for improved stability of the metadata and journal checksum features. Discarding device blocks: 4096/343040 done Creating filesystem with 343040 4k blocks and 171600 inodes Filesystem UUID: 43ff7fc9-12bb-4151-8549-77c8e1e35e2c Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Allocating group tables: 0/11 done Writing inode tables: 0/11 done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: 0/11 done mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. This is caused by this code in live-build's lb_binary_rootfs script: dd if=/dev/zero of=binary/${INITFS}/filesystem.${LB_CHROOT_FILESYSTEM} bs=1024k count=0 seek=${REAL_DIM} mkfs.${LB_CHROOT_FILESYSTEM} -F -b ${LB_EXT_BLOCKSIZE:-1024} -i 8192 -m 0 -L ${LB_HDD_LABEL} ${LB_EXT_RESIZEBLOCKS:+-E resize=${LB_EXT_RESIZEBLOCKS}} binary/${INITFS}/filesystem.${LB_CHROOT_FILESYSTEM} mkdir -p filesystem.tmp ${LB_ROOT_COMMAND} mount -o loop binary/${INITFS}/filesystem.${LB_CHROOT_FILESYSTEM} filesystem.tmp To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1598136/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
