You are here
Neontribe - Thu, 2013/04/18 - 13:35
My company have been building a turnkey appliance for the last few weeks. I have a vm setup with a turnkey-core install on it with tklpatch that I use to build the iso images as we iterate through out initial build.
I can happily do the following on this system:
working
root@core ~# ls
iso linked-data
root@core ~# tklpatch iso/turnkey-core-12.0-squeeze-x86.iso linked-data/
# extracting root filesystem and isolinux from ISO
Parallel unsquashfs: Using 1 processor
25597 inodes (25986 blocks) to write
[========================================================================================================================================================================================================================/] 25986/25986 100%
</snip>
95.41% done, estimate finish Thu Apr 18 10:16:31 2013
Total translation table size: 2048
Total rockridge attributes bytes: 1816
Total directory bytes: 4096
Path table size(bytes): 40
Max brk space used 0
104817 extents written (204 MB)
root@core ~# ls
iso linked-data turnkey-core-12.0-squeeze-x86-patched.iso
and it correctly builds our iso image. Recently I tried to replicate this at home and build another vm (just a fresh install of turnkey-core with tklpatch installed). However when I went to "apt-get install tklpatch" it says no installation candidate is available, once I have done an "apt-get update;apt-get install tklpatch" it installs however I'm now unable to build iso images:
broken
root@core ~# ls
linked-data turnkey-core-12.0-squeeze-x86.iso
root@core ~# tklpatch turnkey-core-12.0-squeeze-x86.iso linked-data/
# extracting root filesystem and isolinux from ISO
Parallel unsquashfs: Using 1 processor
25597 inodes (25986 blocks) to write
[===========================================================\] 25986/25986 100%
created 23964 files
created 2837 directories
created 1074 symlinks
created 38 devices
created 1 fifos
TKLPATCH_ISOLABEL: linked-data
# applying patch linked-data
# executing config script linked-data/conf/pre-debs
Adding 'local diversion of /sbin/initctl to /sbin/initctl.distrib'
# chroot execute: /tmp/tklpatch/pre-debs
Removing 'local diversion of /sbin/initctl to /sbin/initctl.distrib'
root@core ~# ls
linked-data turnkey-core-12.0-squeeze-x86.iso
turnkey-core-12.0-squeeze-x86.cdroot turnkey-core-12.0-squeeze-x86.rootfs
For comparison (working then broken package versions):
working:
root@core ~# apt-cache show tklpatch
Package: tklpatch
Priority: optional
Section: misc
Installed-Size: 85
Maintainer: Alon Swartz <alon@turnkeylinux.org>
Architecture: i386
Version: 0.93+12+gf0f0943
Depends: squashfs-tools, genisoimage, tar, gzip
Filename: pool/squeeze/main/t/tklpatch/tklpatch_0.93+12+gf0f0943_i386.deb
Size: 10126
MD5sum: 76db6fb4ab0b4a57c29b5ae2844e3d8e
SHA1: 8cce782dd731d8aaf8e37fae539b261cad6aca87
SHA256: 4ec355e531ef5d76068b58945bfa4d8a38ce50ef3037262607105acc2daa0f2b
Description: TurnKey Linux Customization Mechanism
Package: tklpatch
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 85
Maintainer: Alon Swartz <alon@turnkeylinux.org>
Architecture: all
Version: 0.93+10+g4c48672
Depends: squashfs-tools, genisoimage, tar, gzip
Description: TurnKey Linux Customization Mechanism
broken:
root@core ~# apt-cache show tklpatch
Package: tklpatch
Priority: optional
Section: misc
Installed-Size: 85
Maintainer: Alon Swartz <alon@turnkeylinux.org>
Architecture: i386
Version: 0.93+12+gf0f0943
Depends: squashfs-tools, genisoimage, tar, gzip
Filename: pool/squeeze/main/t/tklpatch/tklpatch_0.93+12+gf0f0943_i386.deb
Size: 10126
MD5sum: 76db6fb4ab0b4a57c29b5ae2844e3d8e
SHA1: 8cce782dd731d8aaf8e37fae539b261cad6aca87
SHA256: 4ec355e531ef5d76068b58945bfa4d8a38ce50ef3037262607105acc2daa0f2b
Description: TurnKey Linux Customization Mechanism
Is this intentional - has the usage of tklpatch changed, or is this a bug in the packaged version of tklpatch? I have disabled automatic updates on my office build machine as I'm worried that the latest version in the repository is broken.
The full working and broken tklpatch output are attached.
Regards
Andy
Forum:
I haven't used it lately...
But I don't think it's broken. Looking at your post it seems that it's the same TKLPatch deb (same file name, same size and same hashes...!)
A quick glance at you console output makes me think that your conf is probably not executable, but I'm only guessing...
That's strange...
I don't think the latest changes should have broken anything, especially not like this...
What do you have in linked-data/conf/pre-debs ? Thats where it seems to be failing, and no error message is really strange. Could you add -x to pre-debs so it outputs what its doing?
tree and ls -lash outputs
patch location
you can get our patch here if it's helpful btw
https://github.com/neontribe/Linked-Data.git
further testing
our pre-debs is empty:
#!/bin/bash -ex
# executed before apply-debs
apt-cache show is not identical between hosts
deffinately something odd, this is the full apt-cache show output from both systems, why do they look different???
working:
Are they the same version of TKL?
I just installed TKLPatch on TKL v12.0 core and my apt-cache output looks the same as you second one. I also tried installing your patch but I got a different output (although obviously I'm using v13.0RC Core ISO so perhaps that's the problem...)
annoying
It's annoying, because my 2 week old build machine that hasn't had any updates works fine, but every new install I do (or whenever our customer tries to generate an iso off the patch) the build breaks.
even though I'm doing a fresh git clone of the same repo before building :-/
I also did an apt-cache show apt to see if the debian apt tool chain has changed and it's the same version on both.
:(
for hijinks (test 13rc - it didn't break the build)
first thing first, rm -r linked-data and started over on both hosts. then did a git clone to rebuild both the patch directories (because of how we set our git repo up then did a mv Linked-Data/linked-data ../, rm -r Linked-Data.
so old working machine, this time with 13rc:
</snip - output so long it went out of my console history>
and new not-working machine, this time with 13rc:
32bit vs 64bit explains Jeremy's build problem
chroot: failed to run command `dpkg-divert': Exec format error
Jeremy did you try and build this patch with an amd64 iso on a 32bit system - I only get this error when I try and build against 64bit ISO on our 32bit build machine, if I use the i386 iso then it gets much further <see post above>
Andy
okay that was a crock of rubbish
okay im talking guff now, both fail in the same way, 32bit or 64bit on the "non working" build machine:
brand new vm same problem.
if someone could check my workflow am I missing a step
You are right, 64 bit the issue...
I have just applied this to a 32 bit v12 ISO (inside 32 bit TKL v12 Core) and it seems to work.
At least initially...
Obviously inserted page breaks for readability... And FYI it was using a v12 Core ISO I had already on my server (a known good one) and the clone of your git repo that I did last night.
Although my base install (what I installed TKLPatch into) has been installed for some time, but theoretically it should be at least similar to yours (as you haven't run apt-get upgrade...)
When I run
And then try to run your patch again (I removed the previously patched ISO) I get this:
Some strange stuff going on there!
seems the same
that's pretty much exactly what I get!
the reason it looks like i havn't done an apt-get upgrade is because during the install i told it to install security updates (which requires and apt-get update) so by the time i install tklpatch i get the current repo version.
if i don't do this, or don't manuallly apt-get update, i get a "no installation candidate available" message when trying to apt-get install it.
what version of tklpatch
Which version of tklpatch do you have now? I notice it WAS upgraded by apt. You should be able to do an apt-cache show tklpatch to get the version info.
because mine shows the same version but chops the bottom half of the package details of the apt-cache show output but otherwise looks the same, it's deff changing something though!
There was a regression, deployed a fix.
I found the issue, and you are correct - there was a regression (sorry about that!). The part that was failing was during enumeration of debs overlay - if debs/ existed but didn't contain any *all.deb or *$arch.deb, it would return a non-zero exit code which would traverse back up to the main tklpatch script, and abort.
I fixed the code, and verified it now works with all the use cases i could think of. I also updated the package archive with the new version:
Again, sorry about that.
Nice work Alon
Glad it's all good now! :)
cheers
THANK YOU!
Add new comment