[10:03] enyc, which "hardware virtualization" you mean? vtx? [10:47] LocutusOfBorg: i wonder, https://www.virtualbox.org/wiki/Changelog-6.1#v0 says "Virtualization core: Drop recompiler, i.e. running VMs now needs a CPU supporting hardware virtualization" [10:48] enyc: And you use a CPU from 15+ years ago that makes this a cause for concern? [10:49] enyc: Also, the argument that you'd like a stable release with lots of updates, "like 5.2" is a non-starter. 5.2 is special and got extended support because it was the last release with 32-bit host support. It's not the norm. [10:50] infinity: i uspsect, a common problem is virtualization disabled! ive seen it often , may well be the case that its' largerly a non-issue now but i don't have enough sample to be sure [10:50] nonetheless is reasonable ponit of note/discussion [10:51] I know LocutusOfBorg dealt with virtualbox package backport, and so-on! [10:51] enyc: Indeed, some people disable virt in their BIOS. I think those people get to keep both pieces (but also, most virt manager UIs, including vbox, will hint a that solution, I believe) [10:51] infinity: hrrm, or -.- is it ofetn "not enabled by default" in first-place? i've always wondered why it was an "option" at all!! [10:51] If you really need non-virt virt, qemu exists. [10:52] enyc: There's no standard that mandates it be on or off, so it seems to be at the manufacturer's discretion, and I've seen it ship both ways. [10:52] enyc: Sadly, if you want it always on, the best bet would be to ask Microsoft to mandate it for Win10 cert. :P [10:53] That was the only way we got BIOSes to uniformly ship in non-Legacy EFI mode by default after years of not. [10:54] Anyhow, the solution to "the BIOS setting is wrong" isn't "set your CPU on fire doing x86 emulation instead of passthrough", it's "tell the user to change the BIOS setting". [10:55] infinity: hrrm, i didn't ever find virtualbox was doing full emulation, ... just not the nested paging and other accelerated processes.... i though it always tries to set up all the equivalent pagetables to run ring3 code natively. [10:55] anyhow, no matter! [10:56] I might not grok what level of "hardware support" it's decided it now needs. [10:56] I try to avoid vbox except when asked to debug something that fails exclusively in vbox. :P [10:56] infinity: Xen has always been ablet o run userspace code natively, even in 386 on 386! [10:57] doko: so rebuild of gcc from proposed in release builds. so gcc&binutils in focal release must be ok. [10:57] infinity: using 80386/486 features only! [10:57] on arm64 [10:58] infinity: come to think of it, i *think* virtualbox has never supported 64bit-guests with without hardware-virt-support, so you have 64bit systems where yo ucan only run 32bit vms!! [10:58] enyc: True, but Xen's also a pretty special snowflake in the Linux hyp world in that it's the only "real" thin hypervisor, rather than a kernel bodge with userspace VMs on top. [10:59] LocutusOfBorg, infinity : nonetheless, 2 points remain, (a) does virtualbox 6.1 now include sufficient help for "your virtualization support is not turned on, see for help,examples on fixing this" [11:00] LocutusOfBorg, infinity : secondly, remains to be seen how stable vbox 6.1 becomes by the time 20.04.1 ish comes out! we will see. [11:00] thankyou [11:00] * enyc -> out for bit [11:01] enyc, 6.1 will gain minor releases even after 20.04 is out :) [11:01] and 5.2 is a real no-go [11:01] xnox, can you please add verbosity to the arm64 issues you mention above? [11:01] 5.2 dies upstream in July anyway. [11:02] I'm struggling with llvm-* build failures in proposed pocket [11:03] LocutusOfBorg: everything is in this chat yesterday as well. [11:03] mmm thanks, I'll grab logs, my BNC died [11:03] LocutusOfBorg: i'll start a rebuild in bileto ppa, and retest that gnutls28 builds. [11:04] enyc, btw finding a cpu that has no vt-x is mostly impossible today [11:04] I remember back 10 years ago, I had a non vtx cpu and could only virtualize 32bits [11:04] but meh, its 2020 now [11:05] xnox: Oh, is this the SIGILL thing you asked me about and didn't respond to my response? :) [11:05] xnox: If in doubt, blame the new binutils snapshot. [11:06] xnox: For bonus points, if the new binutils *is* generating bad code, we might need to scrape all arm64 builds since that binutils landed and queue them up for no-change rebuilds after it's fixed. :/ [11:06] infinity: yeap, that [11:07] xnox: It could be that someone OOPSed upstream and decided all armv8 is now armv8.1 or 8.2 or something. [11:07] infinity, so the llvm-* sadness is probably due to it [11:07] xnox: And luckily (?) for us, our arm64 buildds are literally the very first generation of armv8.0 that existed, so they'd catch that nicely. :P [11:07] but why debian unstable is not experiencing the same on arm64? [11:07] DAMN, that... [11:08] so Debian has "better" arm64 cpus? [11:08] (newer, whatever) [11:08] LocutusOfBorg: According to xnox, sid's busted too. [11:09] infinity: so, i am re-uploading gcc-9 into bileto ppa which is set to release pocket only. That should give me latest gcc build without new binutils. Will retry that, just upgrade binutils, to see if that's the one. [11:09] At least, gcc-9 fails to bootstrap in sid. [11:09] infinity: i kind of want to block-proposed-focal binutils and gcc-9 for now. [11:09] well gcc-9 ftbfs so won't migrate [11:09] but llvm-toolchain-9 rebuilds on arm64 didn't fail because the "SIGILL" are not experienced on the machine that built it? [11:10] xnox: I mean, it *could* be gcc (and that would be preferable, as the gcc delta is small and readable), but it's almost certainly the jump from binutils 2.33.1 to 2.33.50 (ie: 2.34-pre) [11:10] LocutusOfBorg: i see that on arm64 gcc ftbfs; and gnutls28 ftbfs when built by old gcc from focal-proposed. [11:10] infinity: we didn't chnage to 64k pages did we? [11:10] LocutusOfBorg: You're the one who decided the llvm thing is the same bug, not us. :) [11:10] LocutusOfBorg: It might not be. [11:10] [11:10] #1520162 compiled binaries don't work on arm64 64k pages kernel due to alignment [11:10] Fix Released (11 comments) last updated 2017-08-21 view this bug [11:11] Some binaries in 15.10 for aarch64 seem to be compiled with maxpagesize=4K which triggers issues when run on 64K pages [11:11] xnox: We friggin' better not have. [11:11] arm64 kernels (tested on all kernels back to 4.0). I spotted this while trying to boot an arm64 kernel with 64K pages enabled on 15.10 Ubuntu filesystem. [11:11] launchpad suggested this as a bug report [11:11] [11:11] #1520162 compiled binaries don't work on arm64 64k pages kernel due to alignment [11:11] Fix Released (11 comments) last updated 2017-08-21 view this bug [11:11] bah bad paste [11:12] infinity: doko: rebuilding gcc-9 alone in release pocket at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3891/+packages [11:12] infinity, since both Debian and Ubuntu had the same binutils snapshot, and debian was ok, and gcc didn't change in the meanwhile ( xnox ) because with llvm we still use gcc-8, I assumed it wasn't binutils fault [11:12] xnox: You can block-proposed binutils and gcc-9 if you like, but it won't really change anything, since everything in the archive is biult against proposed ANYWAY. [11:13] now, if new binutils generates wrong code, and arm-conova-02 can understand it, that would explain why we hit the bug in ubuntu [11:13] xnox: Regardless of where binutils and gcc live, we'll need to audit all the binaries that were build by the bad version(s) once we've determined the issue. [11:13] infinity: true [11:14] btw blaming my python3 clang move was also a possible thing [11:14] LocutusOfBorg: Anyhow, to answer your question (sort of), I don't know what hardware Debian is using for arm64, but if it's anything other than APM X-Gene, it's newer and "better" than ours. [11:15] The only other arm64 core as old as X-Gene is the first 64-bit iPhone core, whose name escapes me at the moment. [11:16] time to ask santa to send us new arm64 cores? [11:16] :) [11:16] Both are equally pure 8.0, both are about the same (lack of) speed, both look suspiciously similar under a microscope, but Apple swears up and down they did their all by themselves, honest. [11:16] :) [11:17] LocutusOfBorg: New cores isn't the problem, it's new servers around them that are. We're long past the point where we're cool with just stacking weird whitebox stuff on shelves and rigging up dev board with zip ties, so we've been shopping for Real Servers for a while. I believe we found some, but lead time and all that. [11:20] xnox: when did that start? because new binutils was only added on Thu [11:23] doko: i'm trying to establish what it is that is bad. My first observation is Friday 10th Jan 4:27am gnutls28 ftbfs. [11:23] doko: new binutils published on 8th of January on arm64 no? [11:23] https://launchpad.net/ubuntu/+source/binutils/2.33.50.20200107-1ubuntu1/+build/18529927 [11:24] btw doko your binutils probably dropped stuff from Steve, - * Fix autopkgtest failure when not cross. and Make autopkgtests cross-test-friendly. [11:30] I'll have a look. not forwarded to Debian ;p [11:50] so, if the current llvm-toolchain-7 and llvm-toolchain-9 build on focal-proposed, it means that llvm broke itself and it is now fixed [11:50] otherwise, blaming binutils [11:56] (since I use gcc-8) [12:13] jamespage: OVS is good in excuses, collectd already migrated (not version dependent) [12:13] dpdk itself seems blocked on some lib depends - the binaries that depend on them are not in main, so there should be no component mismatch - and the libs itself are in focal as new enough versions [12:14] I'll have to look more in detail about why it complains about unsatisfiable Depends: libipsec-mb0 and unsatisfiable Depends: libisal2 [12:14] maybe the enw queue handling for these binaries moved them to main [12:15] anyway ... on monday ... [12:33] infinity: focal-release + binutils from focal-proposed = sigill during gnutls28 builds [12:33] doko: ^ [12:33] infinity: can we purge binutils from focal-proposed (or like move it to a ppa?!) and what should I / we do next? [12:33] infinity: git bisect of binutils? [12:35] infinity: i see weird aarch64 reverts in binutils 23h ago. I'll play volleyball, and then will try a new binutils snapshot to see if it is unbroken. [12:36] doko: ^ [13:09] xnox: I'll look at removing it. Need to remove gcc-9 as well for that [13:49] * enyc meows and reads scrollback [13:50] LocutusOfBorg: fwiw my bugbear is that virtualbox discard/nonrotational is buggy/locks-up-VMs ! you have to manually zerofill and manually vboxmanage modifyhd --compact etc etc ;-( anyhow thats more avbox than ubuntu discussion! [14:23] enyc, there is the vbox-dev channel here :) [17:43] doko: new binutils snapshot seems good. gnutls28 built =) [17:43] doko: thank you [20:26] /usr/bin/deb-systemd-helper: error: systemctl preset failed on samba-ad-dc.service: No such file or directory [20:26] who broke samba? [20:27] and why is it configured now, hmm [20:28] hmm no must be something else, something was broken [20:28] The following packages have unmet dependencies: [20:28] libltdl-dev : Depends: automake-1.16 [20:29] I can't figure out what went wrong, the logs all seem fine [20:30] There's nothing in the log installing that -dev, or removing automake [20:30] or any dep error [20:31] so the samba error message was misleading :D === mnepton is now known as mneptok