[SOLVED] Deb.7 Container wont run his init.d

[mannebk]

Hi Folks,

I got myself a new (power safing) node to replace my very hungry ProLiant-DL380 Gen5, so I thought this would be the perfect situation to go from PVE3.4 to current, as the DL380 still is working, I could play with the new HP-Gen8 as long as it would take to make it nice and tidy.

Install went fine.

I exchanged the enterpreice repository with the free one and did a full dist-upgrade to the following version:

root@ProLiant-Gen8-pve:~# pveversion -v
proxmox-ve: 4.2-51 (running kernel: 4.4.8-1-pve)
pve-manager: 4.2-5 (running version: 4.2-5/7cf09667)
pve-kernel-4.4.6-1-pve: 4.4.6-48
pve-kernel-4.4.8-1-pve: 4.4.8-51
lvm2: 2.02.116-pve2
corosync-pve: 2.3.5-2
libqb0: 1.0-1
pve-cluster: 4.0-39
qemu-server: 4.0-75
pve-firmware: 1.1-8
libpve-common-perl: 4.0-62
libpve-access-control: 4.0-16
libpve-storage-perl: 4.0-50
pve-libspice-server1: 0.12.5-2
vncterm: 1.2-1
pve-qemu-kvm: 2.5-17
pve-container: 1.0-64
pve-firewall: 2.0-27
pve-ha-manager: 1.0-31
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u1
lxc-pve: 1.1.5-7
lxcfs: 2.0.0-pve2
cgmanager: 0.39-pve1
criu: 1.6.0-1
zfsutils: 0.6.5-pve9~jessie
root@ProLiant-Gen8-pve:~#

I did backup from DL380 PVE 3.4 all my VMs and CTs to an external NFS share.

Then restored them to the Gen8 node (PVE 4.2-51).

My AsteriskNow that runs in a VM is fine. Everthing works.
I havent tried a Windows VM jet, as I am still not fully equiped with the hardware I wanted the gen8 to have.

But I got some problems with the CT, and I have no clue as to where to start.

This is a Deb.7 with the only job of providing a MySQL 4 DB

root@CT-Deb7-MySQL4:/etc/init.d# cat /etc/issue
Debian GNU/Linux 7 \n \l
root@CT-Deb7-MySQL4:/etc/init.d#

root@CT-Deb7-MySQL4:/etc/init.d# cat /proc/version
Linux version 4.4.8-1-pve (root@elsa) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Tue May 17 16:14:08 CEST 2016
root@CT-Deb7-MySQL4:/etc/init.d#

root@CT-Deb7-MySQL4:/etc/init.d# uname -a
Linux CT-Deb7-MySQL4 4.4.8-1-pve #1 SMP Tue May 17 16:14:08 CEST 2016 x86_64 GNU/Linux
root@CT-Deb7-MySQL4:/etc/init.d#

I got it an ethernet Interface per proxmox upgrade Wiki, with the same adjustments as the old machine had.

CT starts up fine.

But all the init.d scipts are not beeing run.

So no service is beeing run at all. They do actually start fine (the one I tested: MySQL4 and SSH) if I do start them manualy from CLI.

and then the service works as expected.

Any suggestions as to where to start? Google dindt tournd up anything usable to the problem of ignored init.d scripts in a CT with Wheezy on a host with PVE-Jessie.

Thanks

Cheers
Manne

 

[mannebk]

175 views an nobody got a hot brianchild?

I didnt expect to be so special... ;-)

 

[CBdVSdFSMB]

I had a similar behaviour but on the host system, when I used some closed source Infiniband drivers from Mellanox. This killed my networking scripts and after a reboot I only had the loopback device left ;-) It was the same as you describe - a manual "/etc/init.d/SERVICE restart" brought up all interfaces as configured.
After a long search I found the reason together with my colleague: It was the sysv-init-system.d-generator script (I don't know the exact name anymore). Debian is using a two-track-policy with the startup-scripts, why the old init.d-scripts still work as well as the new systemd-scripts. They do this with a funny converter script and I had a circular dependency which the generator script broke automatically (as planned by the script) but at the same time prevented the nework config from being applied. Maybe this is your problem too.

Cheers,
Johannes

EDIT: Forget about it - i mixed up the version numbers of Debian again (Jessie is 8, not 7) - so no systemd in your system... But maybe somebody stumbles upon this problem in the future ;-)

 

[mannebk]

well, thanks for your input, but indeed i do have systemd as the kernel used in pve4 is jessie (8) and the CT is running on this kernel too.

so i will ceck this out and report back, but it will take a while as im a bit loaded with work right now.

 

[fabian]

systemd is not in your kernel (it uses some kernel features, but that's about it). you won't magically use systemd in a container just because of the 4.4 kernel or just because you use systemd on the host. check the run levels and logs inside the container to figure out why the services are not started (correctly).

 

[mannebk]

Well it seems, i just wasn't patient enought.

This is the output of dmesg, and I didnt try right away with SSH, but made me a coffe. Then all was well. But it seems the system takes a long time to start up.

dmesg: see file

 

[fabian]

you need to look at the containers logs specifically (i.e., in the container's /var/log). dmesg is shared between host and containers because of the shared kernel.

 

[mannebk]

i see, thanks for the hint.

will do asap after i got my problem with PCIe passthrough solfed

https://forum.proxmox.com/threads/pcie-passthrough-on-4-4-acces-denied.27608/

as right now no container is availabe on the host.

Cheers
Manne

 

[Patrick Zippenfenig]

Reminds me of an openvz upstart udev problem. Some migrated containers took 5 minutes to start. inittab was blocked by udev. Unfortunately openvz enforces upstart instead of sysvinit in newer debian 7 templates.
There should be a file "/etc/apt/preferences.d/parallels" that prevents sysvinit from being installed.

back up !
$ rm /etc/apt/preferences.d/parallels
$ apt-get install sysvinit
$ cp /usr/share/sysvinit/inittab /etc/inittab
force restart (stop and start)
$ apt-get remove udev
$ reboot

 

[mannebk]

Thanks Patrick,

im off PVE now, as I could not make PCIe passtrhough work, due to some things HP did to their hardware unsing parts of the PCIe addresses for other things like health reporting.

So I cant further report on this issue anyhow, as Im moved away form Proxmox to Deb7 with OpenMediaVault and VirtualBox extension.

I actually do miss some of the PVE funktions, but thats no help if it does not work properly.

So this is not realy solved, but for me its solved, so I mark it as "solved", as it did work after I did reboot the CT a fiew times and waited long enough for it to realy start up, like 10-15 mins.

Thank you all for your support.