Is there a similar tool like OpenVZ's pvebash for LXC to enter non booting containers?
- Thread starter apmuthu
- Start date
Just use
https://pve.proxmox.com/pve-docs/pct.1.html
What would be an example of a situation where a CT doesn't boot but needs internal fixing, as normally that means
FWIW, we'd also appreciate some coordination on creating new wiki articles, and ones for long time EOL versions like Proxmox VE 3.x make seldom sense to create, and referring to some arbitrary, potentially dangerous 3rd party script from an official Proxmox wiki makes it seem like some Proxmox staff vetted it, which did not happen.
pct? It got exec, enter and mount commands.https://pve.proxmox.com/pve-docs/pct.1.html
What would be an example of a situation where a CT doesn't boot but needs internal fixing, as normally that means
/sbin/init is broken. Please note also that doctoring on CTs with a simple chroot can be dangerous (not much protection there) and also break stuff (like user/group ID ranges for unprivileged CTs not matching anymore).FWIW, we'd also appreciate some coordination on creating new wiki articles, and ones for long time EOL versions like Proxmox VE 3.x make seldom sense to create, and referring to some arbitrary, potentially dangerous 3rd party script from an official Proxmox wiki makes it seem like some Proxmox staff vetted it, which did not happen.
There are many Proxmox users who still use v3.4. Many valid articles for such versions categorised as such have now been removed presumably to avoid confusion. This article is to help with non booting containers especially ones that have been migrated from OpenVZ to LXC. Inadvertant updation of an OpenVZ old container can cause such a situation to prevent it from re-booting.
When pvebash was resurrected in it's heyday, there were many kudos for it in the forum too. This will help self-service by those in the know. Caveats are welcome. Scares and Sermonising - No.
LXC currently does not have such a feature and with block devices for the raw images, no way to tinker with the innards to get them up and working when they cannot be booted.
Anyone in production use of the PVE in a dated version will have no incentive to change at all like the systemd that led to Devuan that was looked down in the forum initially to now embracing it fully.
No one wants to keep fiddling with host/guest environments regularly and they do not want surprises when upgrading without keeping an eagle's eye for changes in the codebase and forums regularly.
I checked out the new installs of PVE 6.4 and 7.2 and needed to use them on newer hardware as the old PVE 3.4 kernel did not support it. Furthermore, the hassles of migrating from highly customised OpenVZ is a nightmare no one wants to waste their lifetime on. Documenting it in the wiki / forum goes a long way indeed. Quite a few experienced PVE users have their own blogs / wikis documenting the nuances that will benefit from mutual crosslinks.
Those who are still on PVE 3.4 and like pvebash and build their own complex templates are welcome to contact me. The ebook of the old wiki for them is somewhere here in the forum to partake of as meticulous efforts have been taken to take them down from the Internet Archive and Google searches.
Recent versions of /usr/bin/dab and /usr/share/perl5/PVE/DAB.pm simply use dab task php which does not address the absence of the package php in certain old distributions (EOL) like squeeze, wheezy and jessie and use php5 instead. Also the supercession of the /etc/default/grub by the debian repo without a resurrection by the pve repo(s) resulting in the OS PROBER being re-enabled can cause headaches for some if not all besides losing the Proxmox branding as well in the boot menu.
In my customised DAB for both PVE 6 and 7, I have introduced dab task php5 (temporary workaround) for those who need it and php as per official DAB source seems to still use the php5 location for php.ini. There seems to be no .xz compression code in the dab abd DAB.pm now. Wonder where it is used. Useful feature will be get direct chroot into rootfs for each container from the GUI.
When pvebash was resurrected in it's heyday, there were many kudos for it in the forum too. This will help self-service by those in the know. Caveats are welcome. Scares and Sermonising - No.
LXC currently does not have such a feature and with block devices for the raw images, no way to tinker with the innards to get them up and working when they cannot be booted.
Anyone in production use of the PVE in a dated version will have no incentive to change at all like the systemd that led to Devuan that was looked down in the forum initially to now embracing it fully.
No one wants to keep fiddling with host/guest environments regularly and they do not want surprises when upgrading without keeping an eagle's eye for changes in the codebase and forums regularly.
I checked out the new installs of PVE 6.4 and 7.2 and needed to use them on newer hardware as the old PVE 3.4 kernel did not support it. Furthermore, the hassles of migrating from highly customised OpenVZ is a nightmare no one wants to waste their lifetime on. Documenting it in the wiki / forum goes a long way indeed. Quite a few experienced PVE users have their own blogs / wikis documenting the nuances that will benefit from mutual crosslinks.
Those who are still on PVE 3.4 and like pvebash and build their own complex templates are welcome to contact me. The ebook of the old wiki for them is somewhere here in the forum to partake of as meticulous efforts have been taken to take them down from the Internet Archive and Google searches.
Recent versions of /usr/bin/dab and /usr/share/perl5/PVE/DAB.pm simply use dab task php which does not address the absence of the package php in certain old distributions (EOL) like squeeze, wheezy and jessie and use php5 instead. Also the supercession of the /etc/default/grub by the debian repo without a resurrection by the pve repo(s) resulting in the OS PROBER being re-enabled can cause headaches for some if not all besides losing the Proxmox branding as well in the boot menu.
In my customised DAB for both PVE 6 and 7, I have introduced dab task php5 (temporary workaround) for those who need it and php as per official DAB source seems to still use the php5 location for php.ini. There seems to be no .xz compression code in the dab abd DAB.pm now. Wonder where it is used. Useful feature will be get direct chroot into rootfs for each container from the GUI.
FYI: Our repos only get around 1 percentage of traffic from 3.x and older hosts combined, trying to poll for updates, which are non-existent since well over five years.
I posted a fair warning and explanation, in addition to helpers that allow most relevant operations for modern containers. OpenVZ is EOL and LXC isn't working 1:1 like it, those are just facts. OpenVZ isn't coming back either, LXC, with its fully up streamed technology, is here to stay OTOH. So, embracing that sooner than later, and 7 years after initial support in PVE isn't really that early, will avoid future headaches and possible liability issues if you provide services for others.
That is IMO not exactly correct. I am the one that added Devuan support to DAB and also provided the templates in our CT template infrastructure; neither was it looked down nor do we embrace it fully (it's just available there alongside many other distros, as I find a wide variety of basic distros good to have). And personally I'd not dare using 3.4 nowadays in production, sorry but that's just negligent - at least if it's not fully air gapped and if a single third party, or otherwise not 100% trusted CT/process runs on it, as then it's just too easy to break out/attack.
Sure that, IME what helps is to keep it basic and avoid messing with CT internals from the outside. Higher level automation like ansible or similar can also help to avoid tight coupling with the underlying base system, making it easier to process some changes there.
Note that all tree mentioned distros are EOL even by the Debian LTS project (Jessie since June 2020, the others way before that).
As you mention php I'd guess those are actual network facing setups, possibly even internet; I'd heavily recommend not to use such very outdated LAMP like stacks anymore, they got tons of unfixed security advisories!
Anyway, you got a point there with the broken task, as either we drop support completely for very old releases (e.g. anything older than the old-old-stable suite), or it should work. For now, I tried to restore that task for old releases while keeping new ones supported: https://git.proxmox.com/?p=dab.git;a=commitdiff;h=cd85c459f76ea708aef48182c898da24b2de3320
Already available by starting the CT and opening a shell, both dooable from the web interface. As said, a
chroot alone is neither secure nor really functional (in most CTs anyway) and won't be added.Dropping to a shell can be done only if the LXC is running. No way to enter a stopped / non bootable LXC container unlike in an OpenVZ container using pvebash (uid and gid are preserved).
Thanks for the prompt change in DAB.pm and hopefully the said commit does not need any change in /usr/bin/dab though the archive repos are not implemented in it yet. Hope a DAB v3.4.2 deb file is released too and another for PVE 6.x too.
DAB for OpenVZ could use constructs having wildcards (*) in statements like:
whereas we can no longer do this in DAB for LXC as wildcards are used literally as part of file/folder names. Tried various constructs of escaping and in ${BASEDIR} type direct constructs as well. tar and untar seem to be the current alternatives.
Due to the need to accommodate newer hardware (DDR4, USB3, M2 SSD, performance and efficiency cores, etc) using later 5.x kernels and the need to exist with LXC containers realising that OpenVZ is not coming back, I am looking to support various scenarios for container recovery before putting both feet in.
Resurrecting PVE 3.4 machines is trivial when no more updates are envisaged, The /var/log/cache saves the day along with static apl-info/* files on pveam update and few will appear to have accessed the pve repo for it and hence the low 1% traffic info.
A lot of use cases exist for highly customised LXC too - SMEServer, BlueOnyx, SAIL Asterisk, etc.
chroot can be an option for special circumstances which can be removed after the work is done.
Anyone likes an optionnally usable chroot like pvebash in OpenVZ? A poll would be nice.
The GUI can have a form to enter LXC template URLs list for third-party ones.
Thanks for the prompt change in DAB.pm and hopefully the said commit does not need any change in /usr/bin/dab though the archive repos are not implemented in it yet. Hope a DAB v3.4.2 deb file is released too and another for PVE 6.x too.
DAB for OpenVZ could use constructs having wildcards (*) in statements like:
Code:
dab exec ln -s ....,
dab exec mv -r...
dab exec cp -r ...Due to the need to accommodate newer hardware (DDR4, USB3, M2 SSD, performance and efficiency cores, etc) using later 5.x kernels and the need to exist with LXC containers realising that OpenVZ is not coming back, I am looking to support various scenarios for container recovery before putting both feet in.
Resurrecting PVE 3.4 machines is trivial when no more updates are envisaged, The /var/log/cache saves the day along with static apl-info/* files on pveam update and few will appear to have accessed the pve repo for it and hence the low 1% traffic info.
A lot of use cases exist for highly customised LXC too - SMEServer, BlueOnyx, SAIL Asterisk, etc.
chroot can be an option for special circumstances which can be removed after the work is done.
Anyone likes an optionnally usable chroot like pvebash in OpenVZ? A poll would be nice.
The GUI can have a form to enter LXC template URLs list for third-party ones.
Last edited:
One will be released for Proxmox VE 7.x over the next weeks, Proxmox VE 6.x is EOL since a bit over a month a will not get any such updates anymore: https://pve.proxmox.com/pve-docs/chapter-pve-faq.html#faq-support-table
Wildcards are interpreted by the shell itself, so you need to execute the command in a shell if you want to use them, for example:
dab exec sh -c 'ls -l /var/l*'Thanks for the shell solution. Those worked well in PVE 3.4 - what else has changed?
The workaround in the DAB Makefile I had used was:
and has been replaced by the equivalent from OpenVZ now in LXC as:
The workaround in the DAB Makefile I had used was:
Bash:
cp -r ${BASEDIR}/usr/share/fonts/truetype/freefont/ ${BASEDIR}/var/www/frontac/reporting/fonts/
cp -r ${BASEDIR}/usr/share/fonts/truetype/ttf-bitstream-vera/ ${BASEDIR}/var/www/frontac/reporting/fonts/
cp -r ${BASEDIR}/usr/share/fonts/truetype/ttf-dejavu/ ${BASEDIR}/var/www/frontac/reporting/fonts/
cp -r ${BASEDIR}/usr/share/fonts/truetype/ttf-liberation/ ${BASEDIR}/var/www/frontac/reporting/fonts/
tar -czpf ${BASEDIR}/var/www/frontac/reporting/fonts/fonts.tar.gz ${BASEDIR}/usr/share/fonts/truetype/*/*.ttf
tar -xzpf ${BASEDIR}/var/www/frontac/reporting/fonts/fonts.tar.gz -C ${BASEDIR}/var/www/frontac/reporting/fonts/
rm -rf ${BASEDIR}/var/www/frontac/reporting/fonts/fonts.tar.gz
Bash:
dab exec sh -c 'ln -s /usr/share/fonts/truetype/ttf-dejavu/*.ttf /var/www/frontac/reporting/fonts/.'
dab exec sh -c 'ln -s /usr/share/fonts/truetype/freefont/*.ttf /var/www/frontac/reporting/fonts/.'
dab exec sh -c 'ln -s /usr/share/fonts/truetype/ttf-bitstream-vera/*.ttf /var/www/frontac/reporting/fonts/.'
dab exec sh -c 'ln -s /usr/share/fonts/truetype/ttf-liberation/*.ttf /var/www/frontac/reporting/fonts/.'
Last edited:
I can confirm that these latest constructs do not work in PVE 3.4 DAB and ends in the following error:
The said offending construct works in the old dispensation as:
Bash:
dab exec sh -c 'ln -s /usr/share/fonts/truetype/ttf-dejavu/*.ttf /var/www/frontac/reporting/fonts/.'
ln: missing file operand
Try `ln --help' for more information.
ve_exec failed - status 1
ve_exec failed - status 1
make: *** [all] Error 1The said offending construct works in the old dispensation as:
Bash:
dab exec ln -s /usr/share/fonts/truetype/ttf-dejavu/*.ttf /var/www/frontac/reporting/fonts/.