Hey Fellows,
I think I've found the cause of this issue.
And some sort of Work Around.
When running the Libertine thing via terminal, you can cancel the process once you hit
the extracting coreutils stage. This will keep all the container files incl. the debootstrap.log file.
In there it says:
Preparing to unpack .../libc6_2.23-0ubuntu11.3_arm64.deb ...
ERROR: Your kernel version indicates a revision number
of 255 or greater. Glibc has a number of built in
assumptions that this revision number is less than 255.
If you\'ve built your own kernel, please make sure that any
custom version numbers are appended to the upstream
kernel number with a dash or some other delimiter.
uname -a shows:
Linux ubuntu-phablet 4.14.288-halium+ #1 SMP PREEMPT Sat Aug 27 21:08:42
That means, the 288 causes the error. Which is related to this bug.
I am using a Terminal SSH connection. And I can reproduce the issue with:
sudo apt-get update && sudo apt-get install --reinstall libc6
Reading package lists... Done
W: No sandbox user '_apt' on the system, can not drop privileges
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/2,198 kB of archives.
After this operation, 0 B of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 54291 files and directories currently installed.)
Preparing to unpack .../libc6_2.23-0ubuntu11.3_arm64.deb ...
ERROR: Your kernel version indicates a revision number
of 255 or greater. Glibc has a number of built in
assumptions that this revision number is less than 255.
If you\'ve built your own kernel, please make sure that any
custom version numbers are appended to the upstream
kernel number with a dash or some other delimiter.
I've adapted the common used work around for this, to replace the kernel revision number by
replacing the /bin/uname with an executable script placed in ~/Downloads/uname.
#!/bin/bash
unameparams="$(uname.orig "$@")"
revision_number=$(echo $unameparams | grep -oE '[0-9]{1}\.[0-9]{1,2}\.[0-9]{1,3}' | grep -oE '[0-9]{3}')
if [[ "$revision_number" > "254" ]] ;then
echo $unameparams | sed -E 's/[0-9]{1}\.[0-9]{1,2}\.[0-9]{1,3}/4.14.250/'
exit
else
uname.orig "$@"
fi
sudo mv /bin/uname /bin/uname.orig
sudo chmod 755 ~/Downloads/uname
sudo cp ~/Downloads/uname /bin/uname
This fixed the issue with the static call
sudo apt-get update && sudo apt-get install --reinstall libc6
But this doesn't worked for the libertine container, because it installs its own coreutils within chroot.
I am using this command to create the container.
libertine-container-manager create -i linuxapps -n linuxapps
To fix it for the creating process as well, I had to hit the target right after the Extracting Coreutils stage during
the process. Which was impossible to do manually, so I used a in second SSH Terminal session a while loop
to wait for uname to exist within the chroot and then replace it.
while ! test -f "/home/phablet/.cache/libertine-container/linuxapps/rootfs/bin/uname"; do
sleep 0.1
echo "Still waiting"
done
mv ~/.cache/libertine-container/linuxapps/rootfs/bin/uname ~/.cache/libertine-container/linuxapps/rootfs/bin/uname.orig
cp ~/Downloads/uname ~/.cache/libertine-container/linuxapps/rootfs/bin/uname
I've executed the while loop once the process reached the Extraction State, yes a lot of echo "Still waiting" were shown,
but it hit the target perfectly and the process continued.
Unfortunately, during the whole process, the ~/.cache/libertine-container/linuxapps/rootfs/bin/uname gets replaced with the real uname file quite often, but with much less time sensitivity. So I had plenty of time, each time, to check with:
ls -l ~/.cache/libertine-container/linuxapps/rootfs/bin/uname*
the size of it, and then manually cp the script with
cp ~/Downloads/uname ~/.cache/libertine-container/linuxapps/rootfs/bin/uname`
The whole process finshed after a while, with another warning, but the container was created.
I guess, to fix this thing in general, UBPorts needs to switch to
a libc6 version, that has abandoned this revision number check. i.e. glibc - 2.27-3ubuntu1.6 as stated in the last post of the above named bug.