turnkeylinux / tracker

TurnKey Linux Tracker
https://www.turnkeylinux.org
71 stars 16 forks source link

[TKLDev] fab-chroot fails to mount build/root.patched #1267

Closed Dude4Linux closed 5 years ago

Dude4Linux commented 5 years ago

Steps to recreate: Download turnkey-tkldev-15.0-stretch-amd64.iso and install in Proxmox VM. Change to products/core and run make. Try to use fab-chroot on build/root.patched

root@tkldev .../products/core# fab-chroot build/root.patched/
mount: mount point /turnkey/fab/products/core/build/root.patched/proc does not exist
Traceback (most recent call last):
  File "/usr/lib/fab/wrapper.py", line 34, in <module>
    CliWrapper.main()
  File "/usr/lib/python2.7/dist-packages/pyproject.py", line 388, in main
    commands.run(name, args)
  File "/usr/lib/python2.7/dist-packages/pyproject.py", line 261, in run
    command.module.main()
  File "/usr/lib/fab/pylib/cmd_chroot.py", line 110, in main
    chroot = Chroot(newroot, environ=get_environ(env_conf))
  File "/usr/lib/python2.7/dist-packages/chroot.py", line 69, in __init__
    self.magicmounts = MagicMounts(self.path)
  File "/usr/lib/python2.7/dist-packages/chroot.py", line 28, in __init__
    self.mount()
  File "/usr/lib/python2.7/dist-packages/chroot.py", line 39, in mount
    executil.system("mount -t proc", "proc-chroot", self.paths.proc)
  File "/usr/lib/python2.7/dist-packages/executil.py", line 56, in system
    raise ExecError(command, exitcode)
executil.ExecError: non-zero exitcode (32) for command: mount -t proc 'proc-chroot'  '/turnkey/fab/products/core/build/root.patched/proc'
JedMeister commented 5 years ago

Unfortunately this is a known issue, although not one that is clearly spelt out anywhere, so thanks for opening this issue. It is directly related to #1157. Also possibly related to #1057 - although not directly.

The issue occurs because the new/updated deck in v15.x works a little differently than in did in previous versions (it's a rewrite in bash). And the underlaying reason for that is that we've switched to using overlayFS (from auFS) as the filesystem layering tool. auFS provides a bit more flexibility and is more featureful, but is no longer provided by Debian kernel by default. FWIW previously Debian were patching their kernel to provide auFS by default, now that overlayFS is in kernel mainline, they've dropped that patch in Stretch. It is still possible to use auFS but it adds a fair bit to the images, so we decided to press ahead with overlayFS.

The direct cause of this issue is that overlayFS only supports a single layer as read-write (the top layer in our usage). All layers underneath are read only, hence we hide them from access. auFS supports multiple rw layers, so we could leave all the previous layers available to users to edit.

As an added pain, this new functionality means that it is not possible to "back track" through the build. I.e. if you build all the way to ISO, and wish to "replay" or "back track" back to root.patched, you actually need to make clean and start again from scratch. :cry:

I haven't looked closely, but by my understanding it should at least theoretically be possible to re-implement the previous functionality. Essentially it would be a case of putting aside the higher layers and remounting the desired earlier layer as rw. The higher layers could then either be "replayed" (as ro) or rebuilt - depending on what seems the most logical and least error-prone.

Ideally we should aim to add back this missing functionality in some way, shape or form. In the meantime, we should at least update the docs so that they reflect what the user will experience.

So in the meantime, the workaround for fab-chrooting into root.patched, is to only build to root.patched. I.e. this will work:

make root.patched
fab-chroot build/root.patched

If you just want to make adjustments and bundle them into a new ISO, AFAIK that is still possible, although I haven't checked. It relies on making adjustments within root.sandbox and rebuilding the ISO (you would need to remove both product.iso and the relevant stamp). Although, I'm guessing that you're not building to ISO?! So that may not apply in your scenario!?

I know that is all very sub-optimal and I'd like to see it fixed, but unfortunately our resources are extremely limited ATM and I'm sad to say that this is not currently a high enough priority item to funnel resources into...

Dude4Linux commented 5 years ago

@JedMeister - Thanks for the clarification. I hadn't experienced this before I installed a new VM from the latest ISO. I suppose that was because I previously used a version 14.2 install that had been upgraded following your notes. It's not a big deal now that I know what's going on. I just wanted to check root-patched to make sure some changes had been installed without having to install the ISO in a VM.

JedMeister commented 5 years ago

@Dude4Linux - Ah ok. For your use case, you should find that root.sandbox should still be visible and should suffice to check what went into the ISO.

Additionally/alternatively, the previous directories (e.g. root.patched) still exist. However, as I mentioned, they are read-only and only exist as the layer (not the full OS of each layer on top of each other as was the case in build/ in v14.x) and as such are hidden by default. You can find them within the build/.deck directory. E.g. the root.patched layer can be found here: build/.deck/root.patched/upper/.

Hope that helps.

Dude4Linux commented 5 years ago

@JedMeister - I just used fab-chroot build/root.sandbox to test the latest changes to LXC appliance. It works as advertised. I think I should have been using root.sandbox instead of root.patched all along.

l-arnold commented 5 years ago

This needs to be documented here with clarifications between v14 (and older) and v15 https://github.com/turnkeylinux-apps/tkldev/blob/master/docs/setup.rst

I will try building in root.sandbox and root.patched. Just playing with a Core build right now.

l-arnold commented 5 years ago

So TKLDEV 15.0 from ISO on Promox did build Core.
Prior I had issues with TKLDEV 15 RC1 from ISO and TKLDEV 15.0 LCX on Promox building. I am not worried about the RC1 (deleted now). I have installed a Magento from LCX and likely working. I need to get a static address to really see, though I can get to it via shell and vpn.

I will do some TKLDEV tests. Curious whether we can build TKL 15 Apps from a TKLDEV 14 build?

JedMeister commented 5 years ago

@l-arnold - it should be possible to build v15.x apps on v14.2 TKLDev but it's been a long while since I've done it, so can't be 100% sure. OTTOMH the main thing is that you'll need the v15.x bootstrap downloaded, and you'll also need to set RELEASE as debian/stretch prior to building. E.g. to build LAMP (assuming you already have the v15.x bootstrap downloaded and unpacked):

cd lamp
export RELEASE=debian/stretch
make