Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TKLDev sandbox mode does not work #616

Closed
vondrt4 opened this issue Apr 22, 2016 · 11 comments

Comments

Projects
None yet
5 participants
@vondrt4
Copy link

commented Apr 22, 2016

[update from Jeremy] - for now, we'll probably just leave the sandbox out, but we need to update the docs to reflect the fact that that's no longer a thing...


Reading the Hello World manual and trying it on the side, I have found that when the sandbox filesystem is changed and make called, it does not take 11 seconds, but begins from scratch, and fails with
error: root.sandbox is dirty with manual changes. To continue: deck -D build/root.sandbox
When I do that, the changes are thrown away. And the next make starts from scratch again.

And I'm afraid that the second part ending with make root-patched also does not take 12 s, but builds it from scratch.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@JedMeister

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

I'll have a quick look and see what I can see...

@JedMeister

This comment has been minimized.

Copy link
Member

commented Apr 25, 2016

I wonder if this behaviour is a regression introduced when fixing #530? Or whether it is another altogether separate bug?

@JedMeister JedMeister added this to the 14.2 milestone May 13, 2016

@qrntz

This comment has been minimized.

Copy link
Member

commented May 13, 2016

It is a regression indeed… the problem with reversing the change however is that the #530 file spillage returns. I'm trying to work around it.

@JedMeister

This comment has been minimized.

Copy link
Member

commented Aug 30, 2016

For now, it seems like the best path forward would be to scrap the root.sandbox altogether. This requires us to update the docs to no longer include reference to it in the docs.

@DocCyblade

This comment has been minimized.

Copy link
Member

commented Oct 8, 2016

So, when you say the sandbox is broke, does this mean you can not build to sandbox (skip the ISO part) and chroot into the sandbox and play around? It's been while since I was playing around with TKLDev (almost a year) and I remember doing that so I could quickly test a config change, then do a fuser command to kill all the processes in the sandbox, then remove the sandbox deck then build the ISO if everything worked in the chroot. Does that still work or do I need to build ISO every time?

@DocCyblade

This comment has been minimized.

Copy link
Member

commented Oct 9, 2016

This bug is really bugging me! It's put a wrench in my dev work. Where I used to be able to throw away the root.patch and start over, you have to rebuild it every time!

I have been pouring over the source for the make files, deck and other things. I think I may have found the issue, and I don't think it's related to #530. I'll post more when I think I have it narrowed down

@DocCyblade

This comment has been minimized.

Copy link
Member

commented Oct 9, 2016

Well, ok I can CONFIRM that #530 introduced this issue. Squash one bug, it polymorphs into another!

See my commands below, I basically reverted the deck.py back to the last commit, and it works like it should.

For clarification, does the old bug only show it's head when you make ISO?

root@tkldev products/core# ~/switch_deck_current.sh 

Switch deck.py to [master]
'/usr/lib/deck/pylib/deck.py.current' -> '/usr/lib/deck/pylib/deck.py'
-rw-r--r-- 1 root root 9936 Oct  9 07:50 /usr/lib/deck/pylib/deck.py
deck.py state is now that of [master]

root@tkldev products/core# make clean

root@tkldev products/core# make root.sandbox

... (builds) ...

touch build/stamps/root.patched
deck build/root.patched build/root.sandbox
touch build/stamps/root.sandbox

root@tkldev products/core# rm build/stamps/root.sandbox 
root@tkldev products/core# make root.sandbox
deck -D build/bootstrap
deck -D build/root.build
deck /turnkey/fab/bootstraps/jessie build/bootstrap
fab-apply-overlay /turnkey/fab/common/overlays/turnkey.d/apt build/bootstrap;

... (starts the whole build) ...

root@tkldev products/core# make clean
deck -D build/root.sandbox
deck -D build/root.patched
deck -D build/root.build
deck -D build/bootstrap
rm -rf build/root.spec build/cdroot build/product.iso build/log build/stamps

root@tkldev products/core# ~/switch_deck_prev.sh 

Switch deck.py to commit [53a3280]
'/usr/lib/deck/pylib/deck.py.prev' -> '/usr/lib/deck/pylib/deck.py'
-rw-r--r-- 1 root root 9942 Oct  9 08:05 /usr/lib/deck/pylib/deck.py
deck.py state is not that of commit [53a3280]

root@tkldev products/core# make clean
deck -D build/root.sandbox
deck -D build/root.patched
deck -D build/root.build
deck -D build/bootstrap
rm -rf build/root.spec build/cdroot build/product.iso build/log build/stamps
root@tkldev products/core# 
root@tkldev products/core# make root.sandbox

... (builds) ...

touch build/stamps/root.patched
deck build/root.patched build/root.sandbox
touch build/stamps/root.sandbox
root@tkldev products/core# 

root@tkldev products/core# rm build/stamps/root.sandbox 
root@tkldev products/core# make root.sandbox 
deck -D build/root.sandbox
deck build/root.patched build/root.sandbox
touch build/stamps/root.sandbox
root@tkldev products/core# 
@JedMeister

This comment has been minimized.

Copy link
Member

commented Oct 9, 2016

Sorry I haven't got to you sooner Ken... From memory, yes, the old bug only becomes noticeable after you have built to ISO.

FWIW I never used the root.sandbox anyway (I like the idea but you can use root.patched itself to achieve a similar ends).

Personally the way I usually do it is to force the build to fail by adding exit 1 to the conf script. Then build to root.patched:

make root.patched

You can then play around in there (just like it was the sandbox):

fab-chroot build/root.patched

When you are done playing and want to retest building your code you just rebuild to root.patched: make root.patched. Because the last build failed it will rerun cleanly. Make sure you copy out your work (i.e. copy commands to your conf script(s) and copy out files you plan to overlay) before you rebuild as it will be destroyed.

When you are ready to build the ISO just remove the exit 1 from the conf script.

If at some point you build to root.patched cleanly but you want to rebuild root.patched again (without rebuilding from scratch) you just need to manually undeck root.patched and remove the stamp. You may need to use fuser to stop processes which are running in the chroot. From memory it goes something like this:

fuser -k build/root.patched
deck -D build/root.patched
rm stamps/root.patched
make root.patched

I may have got some of those commands wrong as it's been a while for me too, but that should get you going in the right direction...

@lirazsiri

This comment has been minimized.

Copy link
Member

commented Jan 6, 2017

For reference here's the Deck commit that fixed the spillage issue while introducing this regression:

turnkeylinux/deck@4aeb3aa

I'm looking into fixes as this vastly increases the length of the development cycle, which is not a good thing. Starting from scratch each time is a major drag. There's an easy workaround that doesn't involve reverting the Anton's file spillage fix to deck. If I can't fix deck directly I'll commit a fix to that.

In retrospect I think we should have given this higher priority. Anything that lengthens the development cycle discourage community contributions and can have a large negative impact.

@lirazsiri

This comment has been minimized.

Copy link
Member

commented Jan 6, 2017

I haven't found an easy fix yet for the deck regression. In the meantime, I'll document the test case for reproducing this in a way that also tests whether the file spillage issue is resolved.

Test setup:

mkdir -p orig/
touch orig/deletethis
touch orig/file
deck orig/ 0/

Reproduce bug:

If orig/ is newer than orig.timestamp and we have a build process that assumes the orig/ timestamp is fixed that is going to trigger a target rebuild.

touch orig.stamp; deck -D 2 || true && deck -D 1 || true && \
 deck 0/ 1 && rm 1/deletethis && deck 1/ 2/ && \
 [ -f  2/deletethis ] && echo "BUG: 2/deletethis exists" || echo "OK: ! 2/deletethis " && \
 ls -la --full-time |grep orig

OK: ! 2/deletethis 
drwxr-xr-x 3 root  root  4096 2017-01-06 15:50:22.069703752 +0200 orig
-rw-r--r-- 1 root  root     0 2017-01-06 15:50:21.397710827 +0200 orig.stamp

Underneath deck the thing that is updating orig is the aufs mount.:

# setup
mkdir -p old new

# this will update the timestamp for old
ls -la old
mount -t aufs -o dirs=/tmp/old,udba=reval none new
umount new
ls -la old

Bottom line: until this is fixed, we can no longer rely on timestamps of decked directories to indicate whether they have changed or not in the build process. The workaround is to use explicit timestamp files for the bootstrap build step like we have for the others, or just remove BOOTSTRAP as a dependency in product.mk

lirazsiri added a commit to turnkeylinux/fab that referenced this issue Jan 6, 2017

@lirazsiri

This comment has been minimized.

Copy link
Member

commented Jan 6, 2017

I committed a simple workaround which can easily be applied by hand to existing versions of TKLDev:

turnkeylinux/fab@8522380

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.