Closed Dude4Linux closed 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...
@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.
@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.
@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.
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.
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?
@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
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