On Friday, 23 December 2016 10:50:04 PM AEDT Craig Sanders via luv-main wrote: > On Fri, Dec 23, 2016 at 09:41:30PM +1100, [email protected] wrote: > > Debian/Unstable has a new version of GCC that has deprecated a lot of the > > older STL interfaces. It also has a kernel that won't work with the amd64 > > libc from Wheezy. > > yeah, i know. i had to build frankenwheezy (mwahahahah! gasp in horror > at wheezy with libc6 from jessie grafted on) for some docker images a > while back: > > > http://blog.taz.net.au/2016/09/16/frankenwheezy-keeping-wheezy-alive-on-a-c > ontainer-host-running-libc6-2-24/ > > AFAICT at the time, the incompatibility was with the later libc6 on > my sid docker host, not necessarily with the kernel...IIRC it started > failing after I upgraded libc6 on the host, without upgrading the kernel > or rebooting.
https://github.com/docker/docker/issues/28705 Above is a Docker issue about this. It's the vsyscall interface. Apparently you can use a kernel command-line option to enable the compatability (while weakening security). I never even tested that kernel option, I prefer to avoid things that reduce security and a franken-wheezy setup isn't difficult to arrange. Even extracting the glibc Debian package with ar and tar (because I couldn't run dpkg in the chroot) wasn't that difficult. https://lwn.net/Articles/446528/ Above is the explanation for the security issue. Note that it's from 2011. We have had a lot of time to deal with this. It seems that having libc in Wheezy depend on vsyscall was a mistake. > > It should be possible to change the Wheezy libc to the newer amd64 > > system call interface without changing much and using kvm or Xen is a > > possibility too. > > yep, wheezy still runs in a VM. as does etch (i also tried the same kind > of libc6 etc upgrades on etch to get it working in docker on sid but > couldn't get it working. gave up on that and created a VM instead. so > etch-based images will stop working in docker when stretch is released) Debian is designed to have everything run with the libc from the next release, there's no other way upgrades can work. It isn't designed to have a libc from 2 releases above. So the kernel command-line option might be the best option for etch. Also the Jessie kernel will have security support for another couple of years. There's no reason why you couldn't run a Stretch host with a Jessie kernel to support Etch docker images if that was necessary. Of course that would make ZFS kernel module support even more exciting than it already is... > > But I can imagine a situation where part of the tool-chain for > > scientific computing had a bug that was only fixed in a new upstream > > release that required a new compiler. > > that's one of the advantageѕ of VMs, you can keep old software alive > indefinitely....and that works very nicely with the kind of stuff I was > doing at Nectar with openstack - basic idea was to let researchers start > up VMs or even entire HPC clusters of VMs (e.g a controller-node VM > and a bunch of compute-node VMs, plus the required private networking, > scripting, configuration, etc) as needed for their computational tasks. That doesn't even solve the problem. Wheezy lost support for Chromium due to compiler issues. Kmail in Jessie never worked correctly for large mailboxes. So for me a basic workstation (lots of mail and web browsing) wasn't functional on either of those releases. I ended up running Jessie and then Unstable with a Wheezy image under systemd- nspawn for email which meant that I couldn't click on a link to launch a browser (not without more hackery than I had time for). It's easy to imagine a similar chain of events breaking a scientific workflow. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
