| critr | in response to the inquiry about kernel updates take excessive time, eralier today, i can report that todays' kernel update, which consisted of the the kernel and a couple of libraries, iirc, seemed to take the usual amount of time... a few minutes. | 02:30 |
|---|---|---|
| Guest28 | What Init system should I use? | 04:00 |
| Guest28 | SysVint? or OpenRC? | 04:00 |
| Guest28 | Is OpenRC runlevels on devuan the same as Gentoo ? | 04:00 |
| Xenguy | Which init system to you want to use? | 04:04 |
| gnarface | Guest28: if in doubt you should use sysvinit because there's more help available for it | 04:05 |
| Guest28 | I duuno im discovering linux | 04:05 |
| gnarface | i don't know about runlevels specifically, but the openrc install we inherit from debian has some notable significant differences from gentoo's deployment | 04:06 |
| Guest28 | anyone knows about the Element Bridge? | 04:06 |
| Xenguy | If you are new to linux, try to stick with sane defaults | 04:06 |
| Xenguy | e.g. sysvinit | 04:07 |
| gnarface | that said, changing it to be exactly like gentoo's version, or even installing gentoo's version is possible... but it's a question of whether you want to spend the effort on that or just stick with what's gonna work with the least effort | 04:07 |
| Guest28 | Thanks Xenguy | 04:07 |
| Xenguy | np | 04:07 |
| gnarface | no idea about element bridge, sorry | 04:07 |
| Guest28 | thanks gnarface | 04:07 |
| Xenguy | Never heard of it | 04:07 |
| Guest28 | https://github.com/Kicksecure/security-misc/blob/master/usr/libexec/security-misc/hide-hardware-info | 04:07 |
| Guest28 | im tring to apply that | 04:07 |
| Guest28 | leaving now thanks for help | 04:12 |
| Guest28 | :) | 04:12 |
| DRX | I experienced a bug on updating linux-image yesterday on Chimaera. Does Devuan have a bug reporting system, or would it be best to use Debian's? | 17:45 |
| mason | DRX: Both ideally, if it exists both places. | 17:48 |
| DRX | I haven't found one for Devuan. Where would that be? | 17:50 |
| buZz | DRX: are you looking for gttps://bugs.devuan.org/ ? | 17:52 |
| buZz | eh | 17:52 |
| buZz | https://bugs.devuan.org/ | 17:52 |
| Xenguy | DRX, See the last section of this document: https://files.devuan.org/devuan_chimaera/Release_notes.txt | 17:53 |
| DRX | I the urls for bugs as references 33 and 34. Thanks. | 17:55 |
| DRX | Correction: I *see* the URLs for ... | 17:59 |
| friedhelm | There is also a "reportbug" package in Devuan. | 18:01 |
| DRX | I'm not sure what package to report the bug for. I would think maybe linux-image-amd64, but Devuan's bug page for that (https://bugs.devuan.org/cgi/pkgreport.cgi?which=pkg&data=linux-image-amd64) says not to report new bugs against that package. | 18:14 |
| buZz | well, now you have instructions ;) | 18:14 |
| ted-ious | Maybe it makes sense to report the bug for apt or apt-get on devuan. | 18:17 |
| ted-ious | Since debian isn't going to care that you had a problem with their kernel unless it also affects debian users. | 18:17 |
| ted-ious | DRX: What was the bug? | 18:17 |
| DRX | The bug was with virtual machines I had running qemu-system-x86_64 and kvm using rtl8139 network interfaces. They worked fine for years (since the first Devaun release and before on Debian), but the network interfaces appeared unplugged as soon as I updated to linux-image-5.10.0.24-amd64 from linux-image-5.10.0.23. They worked fine again when I downgraded. | 18:21 |
| buZz | DRX: maybe default behaviour just changed and you need to configure it differently now? | 18:23 |
| DRX | I wouldn't expect that from just a kernel update with security patches. I'm pretty sure it is related to the patches applied. | 18:24 |
| buZz | you could check the diff? | 18:25 |
| DRX | I think this might affect Debian users as well. It doesn't look like linux-image-amd64 is forked in Devuan; I imaging the diff on Debian may work. | 18:25 |
| buZz | or you could figure out how to 'plug' the virtual network cards? :) | 18:30 |
| ted-ious | DRX: So the virtual interfaces were showing up as offline when you booted the vm's? | 18:33 |
| DRX | I tried issuing the QEMU monitor command set_link <netid> off and then on via virsh, which should similated unplugging and plugging something into the Ethernet jack, but the VM OSes didn't notice. | 18:33 |
| ted-ious | Is that the only problem? | 18:33 |
| DRX | Yes, they were showing as offline, and wouldn't come online. | 18:33 |
| ted-ious | Or did they refuse to come up with ifconfig or whatever. | 18:33 |
| ted-ious | Oh. | 18:33 |
| ted-ious | So they're actually broken. | 18:34 |
| ted-ious | That sounds like a driver regression. | 18:34 |
| ted-ious | Are you using libvirt or just qemu on its own? | 18:34 |
| ted-ious | virsh sounds like it has to be libvirt but I don't want to assume. | 18:35 |
| DRX | Yep, quite broken. I would think it is a driver regression, but I thought the only changes were security patches for GDS and Inception. | 18:35 |
| DRX | Virsh is a command line tool for communicating with libvirt, so yes, that is it. | 18:36 |
| ted-ious | Ok. | 18:36 |
| ted-ious | Personally I found libvirt to be a living nightmare because of how badly it handled networking so my goal was to use it to learn a bit about qemu and then abandon it asap. | 18:37 |
| ted-ious | Specifically if I made any changes to networking I had to reboot vm's and sometimes do other things to the host even. | 18:38 |
| ted-ious | That doesn't sound exactly like your situation but if I were you I'd see if rebooting the host fixed anything. | 18:38 |
| ted-ious | If that's possible. | 18:38 |
| DRX | Interesting. For what it is worth, I don't use any of the fancy network configuration in libvirt (i.e. net-list shows nothing); each VM just has it's own vnet interface that shows up with e.g. ifconfig. | 18:40 |
| DRX | Oh, I tried rebooting (as always). Rebooting into the older linux-image-5.10.0.23-amd64 worked fine, but into the newer one, it was broken. | 18:41 |
| DRX | I suspect this might be caused by the patch for Inception, since this was on an EPYC server. I had previously upgraded the firmware, so that wasn't the problem (at least by itself). Maybe the kernel patch and firmware patch don't get along? I dunno. | 18:42 |
| ted-ious | Is the new kernel causing the problem on the host or the vm? | 18:46 |
| ted-ious | I thought it was the vm but it sounds like you mean host. | 18:47 |
| DRX | The host seems to run fine and the vnet interfaces are there as before, but the VM OSes see the rtl8139 network interfaces as disconnected. | 18:48 |
| buZz | why rtl8139 btw, and not a faster ethernet device? | 18:49 |
| buZz | like e1000 ? | 18:50 |
| buZz | iirc that should be supported nowadays quite well? | 18:50 |
| buZz | faster/more modern | 18:50 |
| DRX | These were Windows 10 VMs (thus the need for the EPYC server!); it has been a while since I checked, but I didn't think could work with e1000. | 18:52 |
| buZz | intel network cards are -afaik- totally supported on that WINNT kernel | 18:52 |
| buZz | likely much better than that ancient rtl8139 :D | 18:52 |
| ted-ious | I was just going to say that! :) | 18:53 |
| buZz | <3 | 18:53 |
| buZz | GMTA ted-ious | 18:53 |
| buZz | i used to buy rtl8139 cards new in store around 20? 30? years ago? | 18:53 |
| ted-ious | I have heard some people say that the ancient drivers are better to rely on because they are simpler and easier to audit. | 18:53 |
| DRX | Some time ago (maybe under the old Windows 7?) those didn't work, at least not without all that fun "insert driver disk" to get the network interfaces to work stuff. | 18:53 |
| buZz | DRX: likely e100 would have a driver | 18:54 |
| buZz | win7 is what, 15 years old now? not many ppl with gbps back then | 18:54 |
| ted-ious | DRX: I will bet you an excellent bowl of chili that if you switch to the e1000 windows will barely notice and just continue working. | 18:54 |
| buZz | omg chili <3 | 18:54 |
| DRX | One of those VMs has been around for a while, since at least Windows 7 (someone else took care of it before that). | 18:55 |
| ted-ious | Even windows 7 got modern drivers in its updates before it went eol. | 18:55 |
| DRX | Yeah, I had no problem on another server (older Intel) that runs my Linux VMs; those used virtio network interfaces. | 18:56 |
| buZz | our (single) win10 machine at the hackerspace self-upgraded itself to win11 | 18:56 |
| buZz | so much shit broke :( now we gotta reinstall it from scratch | 18:56 |
| DRX | Oh, I LOVE chili! | 18:56 |
| buZz | (its a machine for SteamVR) | 18:56 |
| DRX | No, not for Steam. The Windows VM is just for boring business stuff that needs Windows. Meh. | 18:57 |
| buZz | yes, steamVR games mostly require windows | 18:57 |
| ted-ious | A vm is probably the best home for that. | 18:58 |
| buZz | nope | 18:58 |
| buZz | :D | 18:58 |
| buZz | steam VR inside a VM is utter hell, hahaha | 18:58 |
| ted-ious | I mean the boring business stuff not steam. | 18:58 |
| buZz | oh, yeah, totally | 18:58 |
| buZz | my place for 'boring windows business stuff' is 'out the window' | 18:59 |
| buZz | :D | 18:59 |
| ted-ious | DRX: If you do switch to e1000 I'd like to know if you have to reboot more than the vm to get it to work. | 18:59 |
| ted-ious | Libvirt being cranky and all that. | 19:00 |
| DRX | Regarding the upgrade to Windows 11, that VM simulates an older Intel processor that won't allow the upgrade to Windows 11. So, it stays Windows 10 for now. I suppose I will need to upgrade it eventually. | 19:00 |
| ted-ious | Ooh that's smart! | 19:00 |
| ted-ious | I don't use windows myself but everything I've read indicates that each new version is worse than the last. | 19:01 |
| DRX | ted-ious: If I still have the problems with the rtl8139 interface, I will try the e1000. | 19:01 |
| DRX | Yes. That is my opinion as well. I just had to add another 8 GiB RAM stick (up to 16 GiB total) to a laptop yesterday so it could handle running a few things at the same time on Windows 11. | 19:02 |
| DRX | Sometime in the past, they had the boring business stuff on CentOS (before I was taking care of it), but I think the vendor dropped support for that. | 19:05 |
| ted-ious | I guess it's desktopy not servery stuff? | 19:05 |
| DRX | The Windows is going these days (they want everyone using it in the "cloud" and paying a monthly subscription for that), I think other OSes will pick up more and more users. | 19:06 |
| DRX | The business stuff is really mostly a database server. Why they need Windows to do that ... ? | 19:07 |
| ted-ious | The answer used to be good developer tools. | 19:13 |
| DRX | ted-ious: Just to be clear, I did reboot the host (a few times even). I always reboot the host after linux-image updates or firmware updates. | 19:13 |
| ted-ious | That should take libvirt's problems out of the question. | 19:15 |
| DRX | Yeah. The more I think about it, the more it seems like the patches for Inception are the likely culprit (maybe it mistakenly also applied the patch for Gather even though it isn't an Intel?). | 19:16 |
| onefang | I think the best way to take libvirt's problems out of the question is to uninstall it and just write qemu scripts by hand. | 19:24 |
| ted-ious | I can't say no to that. | 19:39 |
| critr | speaking of inception, i updated my mobo firmware and the kernel, so i hope that takes care of it. | 19:41 |
| DRX | I submitted a bug report. | 19:49 |
| DRX | (to Debian). | 19:49 |
| DRX | Inception is bad, but Zenbleed was quite bad, and trivial to use. I would worry some on a regular PC, but on a server with VMs, those are particularly bad and should be patched ASAP. | 19:51 |
| DRX | I don't think the performance hit for the fixes was nearly as bad for the AMD vulnerabilities as it was for Gather Data Sampling aka Downfall. | 19:53 |
| EHeM | Using APT, I'm unable to find any versions of linux-source-6.1, aside from 6.1.27-1~bpo11+1 and 6.1.38-1; problem is both of these have *known* *vulnerabilities*. | 20:37 |
| EHeM | 6.1.38-4 should nominally have been available 2+ days ago. | 20:38 |
| buZz | sooo, did e1000 fix it? | 20:44 |
| buZz | i guess they didnt try | 20:44 |
| critr | latest kernel is 6.1.0-11 | 21:08 |
| critr | for daedalus | 21:09 |
| EHeM | critr: Unless Devuan kernel versions no longer correspond to Debian kernel versions, I would be thinking "oh ****" in that case. | 21:49 |
| EHeM | Oh, that is the precompiled package version, not the source package version. | 22:52 |
| EHeM | critr: Since I'm getting no where by other means, could you try `apt policy linux-source-6.1` on your daedalus machine and confirm the version and URL it gives you? | 22:57 |
| * EHeM . o O ( Precompiled 6.1.0-11 should equate to source 6.1.38-4; binary picked up, but source didn't? ) | 22:58 | |
| critr | Installed: (none) / Candidate: 6.1.38-4 / Version table: / 6.1.38-4 500 / 500 http://deb.devuan.org/merged daedalus-security/main amd64 Packages | 23:14 |
| critr | EHeM: ^ | 23:18 |
| EHeM | critr: Thanks! | 23:27 |
| EHeM | Though if my rereading is right this round isn't actually fixes /I/ worry about. :-( | 23:45 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!