| minnesotags1 | Hello, We have a 5 node Proxmox setup connecting to a 6 node Ceph of approximately 60T usable space (3x duplication). We have approximately 90 hosted VMs most of them Windows 2012 server. We are looking for a new virtualization platform. I've worked with OpenStack, but find it very tough to administer/maintain. We are mostly in house. Is Opennebula the thing for us? | 00:08 |
|---|---|---|
| minnesotags1 | Also, How is the support for Opennebula on Devuan? | 00:09 |
| golinux | minnesotags: Haven't see you in a while . . . | 00:09 |
| golinux | seen | 00:09 |
| minnesotags1 | Yup..... | 00:12 |
| minnesotags1 | I recently started a new job! ;-) | 00:13 |
| Weeazy | hello | 02:51 |
| golinux | Weeazy: Do you have a question? | 02:55 |
| golinux | Just ask | 02:55 |
| Weeazy | no no, no question. I installed devuan a while back. It's been running great. I was just looking in to see what might be happening, with new releases and such | 02:57 |
| golinux | You're running ascii? | 02:59 |
| Weeazy | I installed in 2016 I think. Never ascii. | 03:00 |
| Weeazy | maybe when it was in beta? | 03:00 |
| golinux | Well, ascii is the current stable release | 03:00 |
| Leander | minnesotags1: we played with open nebula almost two years ago, the main problem was the lack of packages so we made custom ones by patching the debian ones, to basically remove one systemd command in the post-inst script | 03:01 |
| Weeazy | I was chatting with a person here that was working trying to get cinnamon to work on devuan, I wonder if that ever came about? | 03:01 |
| gnarface | i think they succeeded at that but i forget who that was | 03:02 |
| gnarface | someone got mate working too | 03:02 |
| golinux | Weeazy: Yes. It is an option in ascii. | 03:02 |
| Weeazy | ok, that's great! I'll have to look and see when I can schedule the upgrade. That machine is in service full time atm | 03:03 |
| golinux | https://files.devuan.org/devuan_ascii/Release_notes.txt | 03:04 |
| golinux | Be sure to read to avoid gottchas | 03:04 |
| Weeazy | ok. sure will. | 03:04 |
| golinux | You too gnarface. ;) | 03:04 |
| Weeazy | you know, I was using a primary machine with windows on it. And they just keep upgrading and upgrading and I can't turn it off. What's more, I think they are just making a big spy machine | 03:05 |
| golinux | You are probably right | 03:06 |
| golinux | No spying here. | 03:06 |
| Weeazy | so now both of my machines are linux | 03:06 |
| golinux | Great! | 03:06 |
| Weeazy | I'm very happy with linux and especially devuan. I feel more secure with devuan | 03:06 |
| golinux | Devuan is pretty much by geeks for geeks | 03:07 |
| golinux | Definitely not for the clueless. | 03:07 |
| Weeazy | I see there is an upgrade option from debian Jessie. that's awesome. I have one installation of that. | 03:09 |
| golinux | Yes, there are instructions on the website. | 03:10 |
| salsbury | hey | 03:20 |
| salsbury | have you guys noticed a performance drop in kernel 4.19? | 03:21 |
| gnarface | i think one is expected, no? | 03:21 |
| salsbury | because of meltdown? | 03:22 |
| gnarface | yea, because of the spectre/meltdown patches | 03:22 |
| gnarface | i can't tell you if 4.20 is better or worse | 03:22 |
| salsbury | so... 4.9 isn't implementing them even on recent releases? | 03:22 |
| gnarface | hmmm. i don't actually know if they backported those patches to 4.9 or not | 03:23 |
| gnarface | it is the type of thing debian would do, and the kernel devuan is using is just the stock debian kernel | 03:23 |
| salsbury | me neither, I assumed they would...but never checked | 03:23 |
| salsbury | hmmm | 03:24 |
| salsbury | oh well, maybe I've done something wrong | 03:24 |
| gnarface | how much performance loss are you talking about here? | 03:24 |
| salsbury | I'm measuring it in degrees Cº, nothing serious. havend done any benchmarks other than just eye balling | 03:25 |
| debdog | mayhap there's a mouse stuck in the heatsink? | 03:26 |
| salsbury | heheh | 03:26 |
| salsbury | not likely | 03:26 |
| salsbury | I've noticed it gets slower in single thread tasks though | 03:27 |
| gnarface | there's all kinds of other things that might have changed like default cpu frequency governor or video card driver | 03:27 |
| debdog | what I was trying to says, it could be a coincidence | 03:27 |
| salsbury | and a pronounced delay at boot time, while setting up a ramdisk, right after grub | 03:27 |
| gnarface | hmmm | 03:27 |
| salsbury | gnarface, actually, the governor is the same | 03:27 |
| salsbury | I took care of that | 03:28 |
| targz | Hi all, any news about adding the site https://www.gnutransfer.com/en in https://devuan.org/os/install what ? | 03:29 |
| salsbury | but don't sweat it guys, other than the ramdisk thing, it's just a feel, nothing critical | 03:29 |
| targz | sorry: any news about adding the site https://www.gnutransfer.com/en in https://devuan.org/os/install? | 03:30 |
| salsbury | I just wanted to know if you knew about a common well known bug or something | 03:30 |
| gnarface | salsbury: looks like the patches have been mostly applied, depending on architecture: https://wiki.debian.org/DebianSecurity/SpectreMeltdown | 03:30 |
| salsbury | oh nice, thanks gnarface | 03:32 |
| salsbury | :) | 03:32 |
| gnarface | there's a mention that you might need vendor firmware in some cases to make it work | 03:32 |
| Weeazy | reminds me I'm due to change the kernel on this box. | 03:33 |
| gnarface | oh | 03:33 |
| gnarface | salsbury: and then as i read that, i remembered reading this: https://linux.slashdot.org/story/18/11/24/2320228/two-linux-kernels-revert-performance-killing-spectre-patches#comments | 03:33 |
| gnarface | er, this i mean: https://linux.slashdot.org/story/18/11/24/2320228/two-linux-kernels-revert-performance-killing-spectre-patches | 03:33 |
| salsbury | hmmm that's interesting | 03:34 |
| gnarface | so it might be patched but disabled by default in some places, specifically because the kernel devs are complaining about poor performance | 03:35 |
| salsbury | 4.9.139 onwards. ascii is using 4.9.130 I believe | 03:35 |
| salsbury | hmmm | 03:36 |
| salsbury | actually, you know what, I'm pretty sure the ascii kern is configured with that option ON | 03:36 |
| salsbury | unless I don't know what I'm looking at, and that happens ....often... | 03:37 |
| gnarface | you might be right | 03:38 |
| gnarface | it looks like 4.18 is in the backports repo | 03:38 |
| gnarface | if you're looking for something else to compare performance to that would be a good thing to try | 03:38 |
| gnarface | i'm not sure sure whether or not you might also need updated firmware from non-free and maybe even a bios flash too | 03:41 |
| salsbury | bios? oh dear | 03:42 |
| gnarface | i'm not sure about that. cpu microcode can be updated just by package install, so maybe that's all you'll need. | 03:42 |
| salsbury | mine's hast seen a new revision in ages | 03:42 |
| gnarface | do you have the non-free microcode package for your cpu? | 03:43 |
| salsbury | on devuan, don't think so... | 03:43 |
| gnarface | the other thing is that i don't really know enough about how this works to know if the patches might be worse without hypothetically expected corresponding microcode updates | 03:43 |
| gnarface | i know a lot of people fly without them, but amd and intel both have been releasing microcode update packages even before all this spectre/meltdown vulnerability stuff, just to address other performance and stability problems | 03:45 |
| salsbury | oh actually yes, intel-microcode is present | 03:45 |
| salsbury | hmmm | 03:45 |
| Weeazy | hmm. yes. bios upgrade was available for my box too. | 03:45 |
| Weeazy | loathe to do it tho | 03:45 |
| gnarface | i don't know if all vendors are providing that part | 03:45 |
| gnarface | salsbury: just make sure that package is up-to-date | 03:46 |
| salsbury | straight from ascii repo so...yes? | 03:46 |
| gnarface | that should be right, yes | 03:47 |
| gnarface | you have security and updates/volatile added to your sources.list right? | 03:47 |
| salsbury | nah, I don't think it's the meltdown thing | 03:47 |
| salsbury | security, yes | 03:48 |
| salsbury | I probably did something wrong | 03:48 |
| gnarface | got nvidia hardware? | 03:48 |
| salsbury | yep, why? | 03:49 |
| gnarface | you might have accidentally switched to nouveau drivers during the upgrade, and that would noticeably hurt performance in a lot of cases | 03:49 |
| salsbury | 840m with nouveau and bumblebeed (it's a laptop) | 03:49 |
| salsbury | nah, had nouveau before as well | 03:50 |
| gnarface | ok, if you're sure it's not that | 03:50 |
| salsbury | it's not graphics related | 03:50 |
| salsbury | hmm this looks promising http://lkml.iu.edu/hypermail/linux/kernel/1809.2/00897.html | 04:00 |
| salsbury | talking about NUMA... | 04:02 |
| salsbury | i did disable all iommu stuff | 04:03 |
| salsbury | since my cpu doesn't support it | 04:03 |
| salsbury | but maybe there's more to it like general memory management stuff | 04:04 |
| gnarface | what is the ramdisk being created at boot for? | 04:04 |
| gnarface | i've been told that most times it is better to use tmpfs | 04:04 |
| salsbury | oh it's right after grub | 04:05 |
| salsbury | it has always done that, even in 4.9, out of the box | 04:06 |
| gnarface | really? | 04:06 |
| salsbury | "Loading ramdisk..." or something | 04:06 |
| gnarface | you aren't talking about the initrd.img are you? | 04:06 |
| salsbury | eh... | 04:06 |
| gnarface | hmm, maybe you are though | 04:06 |
| salsbury | hmmm | 04:07 |
| gnarface | i had a problem with that being too slow when booting from USB or SD card | 04:07 |
| gnarface | not so you should notice on faster media | 04:07 |
| salsbury | but if I boot with 4.9 I can notice it's way faster | 04:07 |
| salsbury | maybe the kernel is bigger | 04:08 |
| gnarface | but if you were booting from slow flash, a change to the setting of "include all drivers" or just "targeted drivers for this system" would noticeably increase boot times | 04:08 |
| salsbury | that might actually be it | 04:08 |
| gnarface | the difference in that setting can mean like a 500% increase in the size of the initrd.img | 04:08 |
| salsbury | wait a sec | 04:08 |
| salsbury | LOL | 04:09 |
| gnarface | it's still only a dozen or so megabytes but at PIO speeds, that can be add up easily to a 2 minute boot delay | 04:09 |
| salsbury | you're so right | 04:09 |
| salsbury | nah, I done f***** up | 04:09 |
| salsbury | lkololol | 04:10 |
| gnarface | something else entirely, like accidentally adding the wrong path to something? | 04:10 |
| salsbury | initrd.img size ---> 390MB | 04:10 |
| salsbury | previous initrd.img size ---> 34MB | 04:11 |
| gnarface | oh boy | 04:12 |
| salsbury | yeah... | 04:12 |
| gnarface | well that looks... wrong | 04:12 |
| salsbury | awfully so | 04:12 |
| gnarface | the biggest one i have here is 23M | 04:13 |
| gnarface | the smallest is 16M | 04:13 |
| gnarface | on this machine, anyway | 04:13 |
| salsbury | I did enable a bunch of stuff... but as modules, it shouldn't be in initrd.img right? | 04:14 |
| gnarface | actually that's where the modules go. they all go into initrd.img | 04:14 |
| salsbury | ah crap | 04:14 |
| salsbury | I did not know that | 04:14 |
| salsbury | :D | 04:15 |
| gnarface | strictly speaking, you don't even need one. but the default debian setup uses them so that it can preload drivers before the hardware that needs them | 04:15 |
| salsbury | I see | 04:15 |
| gnarface | (otherwise, stuff like your hdd controller driver and your network drivers would have to be statically built into the kernel to be accessible early enough in boot time) | 04:15 |
| salsbury | well, time to reconfigure it all again | 04:17 |
| gnarface | hmmm | 04:17 |
| salsbury | how did you get initrd.img so lean though? | 04:17 |
| salsbury | 16M is pretty neat | 04:17 |
| gnarface | that's just the ones that came with the kernel | 04:17 |
| salsbury | my 4.9 is at 34M | 04:18 |
| gnarface | oh, no i guess the 16M one is a custom build | 04:18 |
| gnarface | you're right | 04:18 |
| gnarface | i must have shaved out some stuff i didn't need | 04:18 |
| gnarface | i was using the debian kernel source packages | 04:18 |
| salsbury | hmmm | 04:18 |
| gnarface | so i just started with their config and then unchecked stuff i knew i didn't have | 04:18 |
| gnarface | i think i was disabling debugging stuff, looking for more wine performance (didn't find any) | 04:19 |
| salsbury | that's interesting | 04:19 |
| salsbury | I used linus's source files... and I did check some kvm debug stuff as well | 04:20 |
| gnarface | i seem to remember there was a command you could call to just trigger rebuilding the initrd.img with either the "all drivers" setting or just "targeted drivers for this system" setting, without actually rebuilding the entire kernel again. i could be wrong.... | 04:21 |
| gnarface | ... also, i don't know how safe it would be to use on your custom build | 04:21 |
| gnarface | i remember the setting was in a file in /etc/initramfs-tools/ though | 04:22 |
| salsbury | hmmm | 04:22 |
| gnarface | ah yes, top of the /etc/initramfs-tools/initramfs.conf file | 04:23 |
| gnarface | MODULES: [ most | netboot | dep | list ] | 04:23 |
| salsbury | yep | 04:24 |
| salsbury | that's it | 04:24 |
| salsbury | mine's on "most" | 04:24 |
| gnarface | this one is too | 04:24 |
| gnarface | hmmm | 04:25 |
| salsbury | I'm curious about the dep option | 04:25 |
| salsbury | though | 04:25 |
| gnarface | yea, they're all set to "most" here | 04:28 |
| gnarface | that's the default | 04:28 |
| gnarface | i feel like i had to set it to "all" once, a long time ago due to a unrelated bug, but i guess i don't remember for sure | 04:28 |
| gnarface | anyway, i suspect this is something that's still dependent on your kernel build options | 04:29 |
| golinux | targz: I vaguely remember that site. Sorry the ball got dropped. I'll put it on the Wed. agenda | 04:29 |
| salsbury | gnarface, I don't think I'll mess with that | 04:30 |
| salsbury | I done goofed up for sure, I'll compile it again | 04:30 |
| gnarface | salsbury: yea, don't change it yet, because that still wouldn't explain it being +350MB | 04:30 |
| salsbury | exactly | 04:30 |
| targz | golinux: Don't worry | 04:30 |
| salsbury | oh well *shrugs* | 04:30 |
| gnarface | salsbury: lemme know if you figure out what did it. i'm curious | 04:31 |
| salsbury | sure ;) | 04:31 |
| salsbury | brb | 04:42 |
| salsbury | gnarface: clue number 1: .config-4.9.0-8-amd64 only has one kerne hacking option. but doing menuconfig based on that enables a bunch more supported by 4.19.8 | 05:36 |
| salsbury | but this may be because I'm using linus src, not debian | 05:42 |
| gnarface | oh | 05:55 |
| gnarface | weird. is it possible you have an initrd.img with multiple kernel versions' modules in it? | 05:55 |
| gnarface | i didn't know that was a thing | 05:55 |
| gnarface | hmmm | 05:56 |
| gnarface | or, wait, maybe i misunderstood that | 05:56 |
| gnarface | maybe it would be better to grab a debian config for 4.19 from ceres | 05:57 |
| gnarface | or well, from sid, either would do | 05:57 |
| golinux | ceres and sid are identical but best to access via devuan mirror | 06:11 |
| golinux | gnarface: ^^^ | 06:11 |
| gnarface | that's a good point | 06:12 |
| _abc_ | fsmithred ? | 09:07 |
| _abc_ | !seen fsmithred | 09:07 |
| infobot | fsmithred <~user@devuan/developer/fsmithred> was last seen on IRC in channel #devuan, 10h 33m 21s ago, saying: 'the new artists didn't learn about borders'. | 09:07 |
| _abc_ | We/I need to make a statement of policy wrt firefox 60 and similar non-free things which run on devuan (default upgrade path) and cause security and usability problems to users. Also we/I need to establish some form of patch path to undo the damage soon. Perhaps using a user.js created and maintained under the devuan "umbrella", to be applied by users to forced-upgraded firefox. The patch should cover | 09:10 |
| _abc_ | especially "default on"-can't turn off updates of all aspects of the browser, including search engines, and default push for "web based authentication" as well as "deprecation" of local file stored password saving and retrieval, in favor of "online (free)? service" data snooping service storage thereof. | 09:10 |
| _abc_ | I feel this is important. There is no point in having a system which contains a trojan zero day horse, snitching everything one tries to do locally and all data to remote "benevolent" locations which just so happen to be in jurisdictions where this data can and is being copied and analyzed by third parties "legally", and without the knowledge or approval of the users. This even breaks EU gdpr. I am in EU. | 09:12 |
| _abc_ | Will be back about this. If anyone has a way to store "patches" against current devuan/debian ff 60.3 ESR in a user.js, they, and discussion thereof is welcome. | 09:13 |
| KatolaZ | _abc_: please put together these patches and submit them for review | 09:29 |
| _abc_ | I don't know how to extract what I changed in the prefs.js via about:config yet. I need to work on that later maybe tomorrow morning. If anyone has experience doing this somehow (sed, grep etc) please say so, a hint or two will save me a lot of time. | 09:31 |
| amesser | _abc_: Try looking at ~/.mozilla/firefox/<profile dir>/prefs.js. This file should contain all user changed settings | 09:38 |
| amesser | (and some timestamp/runtime stuff, but this should be extractable) | 09:40 |
| KatolaZ | _abc_: no idea, I don't use firefox | 09:49 |
| KatolaZ | (and the rare times I need it, are not enough to justify any tweaking for me) | 09:50 |
| _abc_ | amesser: it contains all my changes and a lot more things. Separating my changes is hard. I need to install a fresh copy and then run some diff | 10:06 |
| amesser | diff wont help for timestamps :-) | 10:06 |
| amesser | My prefs.js is only about 130 lines. could be done manually but when its large | 10:09 |
| amesser | it might be an problem | 10:09 |
| amesser | what you could try is the following use awk to reform the file in a format like "<pref-name><space><value>" | 10:10 |
| amesser | then use "cat my_prefs.txt initial_prefs.txt | sort | uniq -u" | 10:13 |
| amesser | i think the format should be "<pref-name>" (without the value) | 10:14 |
| amesser | then u should see only the values which are in one of those files, not in bith | 10:14 |
| amesser | s/bith/both | 10:14 |
| _abc_ | amesser: yes, that will be done eventually, perhaps with a CSV or .cpp in-between step so things can ge selected by users. After all I do not want a new system which shoehorns people into new settings they do not understand, replacing the old settings which they do not understand. | 10:17 |
| _abc_ | To be continued. | 10:17 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!