| systemdlete | just updated to new kernel and now my display wont go hi res. I think there is some package I need, but I don't recall now. | 00:58 |
|---|---|---|
| systemdlete | (be nice if there were a dependency so this would be performed automatically like other items...) | 00:59 |
| systemdlete | firmware-amd-graphics? But that should have already been installed. Display was working correctly before kernel upgrade. | 01:06 |
| rwp | Boot the previous kernel and verify that it works? Or doesn't. I have been burned by the kernel dropping support for hardware I am still using. | 01:09 |
| rwp | Check the boot log and dmesg output and see if there is a warning about missing firmware? | 01:12 |
| rwp | For a somewhat older AMD GPU I only have firmware-amd-graphics installed and it is okay for me. | 01:13 |
| rwp | Check /var/log/Xorg.0.log for errors and to verify which driver is being used. | 01:13 |
| rwp | Run "xrandr" and verify the resolutions it reports from the displays. | 01:14 |
| systemdlete | there were NUMEROUS warnings about missing firmware, but I don't remember for which hardware. | 01:18 |
| systemdlete | I will save your suggestions as steps for a checklist, thank you! | 01:18 |
| systemdlete | Anyway, installing the radeon firmware-amd-graphics package did the trick. | 01:22 |
| systemdlete | It's happy again. So am I. | 01:22 |
| systemdlete | I am now seeing a message upon boot saying "Waiting for /dev to be fully populated." It has been hanging there since forever. I DO NOT USE WIRELESS with the system I am booting. | 01:24 |
| systemdlete | (some say this message is associated with wireless, so just being complete about this) | 01:25 |
| systemdlete | and I never have used wireless with it. But it was working until now. | 01:25 |
| systemdlete | I've seen this before, and rebooting seems to make it go away, but I am wondering if I need to fix something. | 01:25 |
| rwp | Why was firmware-amd-graphics removed? Upgrading a kernel should not be removing that package. | 01:28 |
| systemdlete | I agree! | 01:28 |
| rwp | I often see that message "Waiting for /dev to be fully populated" too. It seems to be an asynchronous boot race condition. It's unrelated to wireless. | 01:29 |
| systemdlete | I do not know the answer to that question. However, I will add that I have been to this channel umpteen times with this same question. It seems like this happens fairly frequently, maybe when kernels are upgraded. | 01:29 |
| systemdlete | I LOVE race conditions. | 01:29 |
| systemdlete | They are so hard to detect and correct... :D | 01:29 |
| systemdlete | I GUARANTEE I did not intentionally remove the graphics package. I have no reason I would. | 01:30 |
| systemdlete | rwp, do you find that rebooting can make the hang go away? | 01:30 |
| rwp | There are two log files /var/log/apt/* and /var/log/dpkg.log which log activity. I would look there. | 01:30 |
| rwp | I never see a hang. It is just a message that will appear brief and then the boot will continue. Presumably /dev became populated. | 01:31 |
| systemdlete | It is hanging for me. | 01:31 |
| systemdlete | rwp: Looks like it got removed when I ran --fix-broken install (for some other problem iirc) | 01:34 |
| systemdlete | back in July | 01:35 |
| systemdlete | at https://unix.stackexchange.com/questions/698327/occasional-stuck-at-boot-up-line-waiting-for-dev-to-be-fully-populated, they suggest to add parameter to udevadm settle to limit the hang to a few seconds. | 01:37 |
| rwp | At least the removal is explained. Using --fix-broken is allowed to remove things. And just today we were talking about dist-upgrade and remove too. | 01:40 |
| systemdlete | On that hang, I tried disabling "quiet" from the boot line. Now, the same message appears, but there is a lot of stuff after that. The last lines are re: [drm] | 01:42 |
| rwp | JFTR and without trying to cast blame or anything but we know that it was removed only because it was told it was okay to remove it. | 01:42 |
| systemdlete | last of those drm messages was about "cursor bypass" | 01:42 |
| systemdlete | I DO read those messages from apt these days to check what it is about to do. But I must have overlooked this for some reason. | 01:43 |
| systemdlete | Maybe I thought, gee, if apt thinks it is OK to remove the package, then it is probably smarter than me when it comes to calculating the dependency chains. | 01:44 |
| rwp | I have no idea on the waiting for /dev population problem. | 01:44 |
| systemdlete | I accept "blame," but I also think that apt could be a bit more *apt* since it IS the package manager after all... :D | 01:44 |
| systemdlete | (see what I did there?) | 01:45 |
| systemdlete | So --fix-broken fixed one thing and broke another. And I didn't (for whatever reason) try to stop it. | 01:46 |
| rwp | Looking around I find that firmware-linux-nonfree has an "firmware-amd-graphics (= 20190114-2)" type dependency. That is rigid. Inflexible. And can cause things to be removed if only mixmatched versions are available. | 01:48 |
| rrq | systemdlete: that ".. fully populated." message appears to come from /etc/init.d/eudev and the waiting is for "udevadm settle" which has a default timeout of 120 seconds (= some 1-2 eternities) | 01:52 |
| systemdlete | longer than 2 eternities. At least 3. 120 seconds is 2 minutes, and I guarantee it hangs longer than that. | 01:53 |
| systemdlete | I checked to see if USB might be hanging it up. But I don't have any USB attached. | 01:57 |
| systemdlete | (USB came up in my searches also, so I thought I should double check that) | 01:57 |
| systemdlete | I'm going to try adding a 10 sec timeout and see if that helps any... | 01:58 |
| rrq | I don't know for sure, but maybe it's actually waiting for 120s of no udev events following "the last"... maybe a "-t 3" or such would be more fun? | 01:58 |
| rrq | or 10 | 01:58 |
| * systemdlete doh! | 02:06 | |
| systemdlete | Turns out it might be related to virtualbox 7.0, which I have rolled back to 6.1 and now all is working again. | 02:07 |
| * systemdlete braces for 3 rounds of "I hate Virtualbox" | 02:07 | |
| systemdlete | Sorry to bother you all with a problem not related to devuan at all... but the other issue with the graphics package stands, and I will be on the lookout for that in the future. | 02:08 |
| systemdlete | I probably should have checked that before I came here crying about that one. | 02:09 |
| systemdlete | vbox 7.0 just came out a few days ago and I decided to try it out on my test box. Glad I did before upgrading my main system. | 02:10 |
| systemdlete | I usually don't upgrade until about the 3rd or 4th maintenance release of a major bump. | 02:10 |
| systemdlete | In fact, I try to avoid such upgrades across the board, not just vbox. | 02:11 |
| systemdlete | Anyway, thank you all for the help. Always appreciated. | 02:12 |
| rwp | VirtualBox does seem to be at the center of a lot of problems! | 02:28 |
| rwp | More seriously I think after making major system changes a reboot to verify that things still boot the same is always good practice. | 02:29 |
| rwp | And then if it doesn't then for certain it was the change that just happened. | 02:29 |
| rwp | I once had a hang-fire from two months earlier affect me on a system! I rebooted it and was certain nothing had changed recently. Tracked it back to a by that time quite old change that hadn't had a reboot yet to verify it. | 02:30 |
| systemdlete | I did not reboot the host because, usually, that isn't necessary. But it sure is a good idea... | 02:31 |
| systemdlete | I'll retry that experiment again, and reboot after upgrading to the new version. See if that changes things. Good idea again, thanks. | 02:31 |
| systemdlete | And, just to confirm your own experience, I had not booted this host for months (sometime after that firmware booboo) | 02:32 |
| systemdlete | So, looks like I just had a taste of the same as you did. | 02:33 |
| systemdlete | So, I tried to boot a more recent kernel (5.10.0-18-amd64) but the graphics are messed up again. I tried to re-install firmware-amd-graphics again and rebooted, but it is still messed up. I don't get hi-res. | 03:49 |
| systemdlete | However | 03:49 |
| systemdlete | When I reboot with the bpo kernel, where the graphics were working, there is no problem. I get higher resolutions. | 03:50 |
| systemdlete | Do I need some specific version of the package? | 03:50 |
| * systemdlete 's head is spinning | 03:51 | |
| onefang | I use the bpo kernels for my AMD graphics card, but I think it's a later model than you use. | 04:13 |
| onefang | AMD Radeon RX 5600 XT (NAVI10, DRM 3.46.0, 5.18.0-0.deb11.4-amd64, LLVM 11.0.1) | 04:13 |
| onefang | This is under Chimaera. | 04:14 |
| onefang | And looks like there's a new kernel update coming soon. Some of the kernel support packages tend to come first, and there's updates waiting for them. | 04:16 |
| onefang | Plus a new vulkan library update. | 04:16 |
| onefang | So I was waiting for today to install that vulkan update, then the kernel half update popped up. I'm planning on pulling my computer apart today for it's annual cleaning, but now this means I get to reboot it again sometime next week when the new kernel arrives. | 04:19 |
| onefang | I HATE rebooting my computer, coz it takes half an hour to get logged back into everything. lol | 04:20 |
| onefang | Coz everyone wants a different chat system, I have one entire monitor dedicated to them, then gotta log onto the various servers I look after, and web sites, and and and... | 04:22 |
| onefang | Yet I still get things like - | 04:26 |
| onefang | amdgpu 0000:23:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000012 SMN_C2PMSG_82:0x00000006 | 04:26 |
| onefang | amdgpu 0000:23:00.0: amdgpu: Failed to export SMU metrics table! | 04:26 |
| onefang | Though no actual problems. | 04:26 |
| Xenguy | onefang, It's true, one has to build it all back up again (at least browsers can remember their state) | 04:39 |
| onefang | Simple tab groups extension is good for keeping my tabs herded. | 04:41 |
| FilipZ | I am using wpa_gui for the wireless connection, and it spawns 2 dhclient processes at once, while doing ifup wlan0. Is this something wrong? Can it cause problems with connecting to the Wi-Fi? If so, how can I fix this? | 04:57 |
| Xenguy | FilipZ, If anyone can help you, it would be rrq | 04:58 |
| Xenguy | He wrote the Networking text file that comes with Devuan | 04:59 |
| rrq | FilipZ: would you mind pastebin your interfaces file somewhere? | 05:00 |
| Xenguy | <3 | 05:00 |
| FilipZ | Yes. Here: https://paste.debian.net/1256971/ | 05:14 |
| rrq | that one looks fine; is /etc/network/interfaces.d/ empty ? | 05:15 |
| FilipZ | Yes. It's empty | 05:26 |
| rrq | i think I've have seen multiple dhclient when shifting access point but only transiently; do the process have the same arguments (check e.g with "pgrep -a dhclient") | 05:27 |
| rrq | only one of them whould be identified in /run/dhclient.wlan0.pid so it shuld be safe to terminate any other | 05:28 |
| FilipZ | The exact same, I believe | 05:45 |
| rrq | I suppose the short answer is that usually dhclient wouldn't cause any problem | 05:45 |
| rrq | it starts as a foreground process and then it spawns a background service after configuration | 05:46 |
| rrq | for dbugging, you could change the "iface default" stanza into a static IP assignment, and then you wouldn't have ane dhclient involved | 05:52 |
| rrq | it would read something like: (3 lines) | 05:52 |
| rrq | iface default inet static | 05:53 |
| FilipZ | Yes. I checked now, and I recorded it previously. It only have the exact same arguments. Specifically it was "dhclient -4 -v -i -pf /run/dhclient.wlan0.pid -If /var/lib/dhcp/dhclient.wlan0.leases -I -df /var/lib/dhcp/dhclient6.wlan0.leases wlan0". | 05:53 |
| rrq | address 192.168.0.24/24 | 05:53 |
| rrq | gateway 192.168.0.1 | 05:53 |
| rrq | ... of course the actual IP numbers would need to fit your setup | 05:53 |
| rrq | eg grab them from the last lease in /var/lib/dhcp/dhclient.wlan0.leases | 05:57 |
| FilipZ | Ok. Thank you. I will check if it changes anything. I also described more specifically yesterday what happens when my Wi-Fi connection buggs like this, but I didn't receive any answer, so maybe it wasn't of any help. | 05:57 |
| FilipZ | Alright, copied. | 05:58 |
| rrq | yes, as I remember you needed to use an older firmware version to have some luck (?) | 06:03 |
| rrq | that is at a s/w level that I don't have much experience with | 06:04 |
| FilipZ | Using older hardware didn't seem to visibly help | 06:11 |
| FilipZ | But I meant what I wrote yesterday, and that was a couple days earlier. | 06:23 |
| rrq | you may need to use "--force" for ifdown; I think that should make better sure that any started dhclient will be killed | 06:32 |
| rrq | (no "-force" for ifup) | 06:34 |
| FilipZ | I always did so previously. It didn't worked like this. It have only killed one. | 06:34 |
| rrq | could you check with "ls /etc/network/if-*/" that you don't have any editing backup files... | 06:39 |
| rrq | there are the 4 directories: if-down.d, if-post-down.d, if-pre-up.d and if-up.d | 06:40 |
| rrq | they typically hold links to scripts, which all handle the ifupdown actions | 06:42 |
| rrq | esp "wpasupplicant -> ../../wpa_supplicant/ifupdown.sh" ... which files/links do you have there? | 06:42 |
| FilipZ | I didn't use -force for ifup, the wpa_gui did this. | 06:48 |
| FilipZ | What would these backup files look like? | 06:50 |
| FilipZ | They all have a symbolic link to the wpa_supplicant and some own files. | 06:50 |
| FilipZ | Only interfaces.d is empty. | 06:51 |
| rrq | right. what do you have other than wpasupplicant? | 06:51 |
| FilipZ | Right. Those were all links to /etc/wpa_supplicant/ifupdown.sh, not just wpa_supplicant. I do not have any other symbolic links in if-* | 06:54 |
| rrq | ok. .. I was looking at your yesterday notes; you mention '3. "ifup -v --force wlanO=default";' ... where was that from? | 06:55 |
| HackphiL | Le Salut à toutes et tous \0/ | 06:57 |
| FilipZ | /if-down.d/ have openvpn, and resolvconf, /if-up.d/ have openvpn, mountnfs, 000resolvconf, and ethtool, /if-pre-up.d/ have wireless-tools and ethtool, /if-post-down.d/ have wireless-tools, and all of them share a link to the ifupdown.sh | 06:57 |
| FilipZ | rrq: that was a process I noticed in the task manager when it happened. | 06:58 |
| FilipZ | It looks like the wpa_gui did this | 06:58 |
| FilipZ | Or so I think | 06:58 |
| rrq | I can't find any "--force" in the wpa suite binaries/scripts except for an advice notice from wpa_supplicant | 06:59 |
| rrq | though the action looks right... would be from wpa_action I think | 07:00 |
| rrq | ok, line 946 in /etc/wpa_supplicant/functions.sh .. used by wpa_action | 07:05 |
| rrq | so, that one is fine, and its dhclient; the other ones were residue from failures | 07:06 |
| rrq | looks like dhclient locks up in some way due to some wlan0 interface failure.. maybe a transient failure of soeme sort | 07:08 |
| rrq | perhaps it could be "masked" by adding to the "default" stanza a line "pre-up pkill -9 dhclient" | 07:10 |
| FilipZ | What do you mean by the "default" stanza? | 07:14 |
| FilipZ | Where do I have to add that line? | 07:16 |
| rrq | after "iace default inet dhcp" | 07:18 |
| rrq | I need to rush... pehaps someone else has ideas of why the wlan adapter keeps falling out | 07:18 |
| dokma | How am I supposed to find the netinstall ISO from here: https://www.devuan.org/get-devuan | 15:38 |
| dokma | Emacs crashed... | 15:39 |
| dokma | So... how am I supposed to find the netinstall ISO from here: https://www.devuan.org/get-devuan ?? | 15:39 |
| fsmithred | dokma, try the Download link in the upper-right part of the page. | 15:42 |
| dokma | It leads to that same page... | 15:42 |
| fsmithred | never mind. It doesn't work. | 15:42 |
| fsmithred | WTF??? | 15:42 |
| dokma | That is the download page... | 15:42 |
| dokma | I'm supposed to go down to the mirrors and somehow figure out the path to the ISOs | 15:42 |
| dokma | But I do not know the structure so I'm trying to guess for the past 10 minutes. | 15:43 |
| fsmithred | go to files.devuan.org | 15:43 |
| fsmithred | that link is wrong. I will fix it. | 15:43 |
| fsmithred | on the files.devuan page, there is a link to iso mirrors, in case you want to pick one close to home | 15:43 |
| fsmithred | netinstall iso is in the directory named Installer Isos | 15:44 |
| dokma | found it | 15:44 |
| dokma | The fact that a programmer with 20 years of experience with internet cannot find installation ISOs from Devuan's own pages is rather problematic | 15:45 |
| hagbard | fsmithred: The link on devuan.org ist the right link, and works. | 15:45 |
| dokma | A normie has no chance. | 15:45 |
| dokma | Which link? | 15:45 |
| hagbard | The Download link that points to the mirror page. | 15:46 |
| hagbard | With the mirrors having the same files as files.devuan.org. | 15:46 |
| dokma | How am I supposed to download the netinstall iso from the mirrors? This is where I end up on one of the mirrors: http://devuan.bio.lmu.de | 15:47 |
| dokma | What from there? | 15:47 |
| dokma | I need to get to the ISOs | 15:47 |
| fsmithred | that's a package mirror | 15:47 |
| dokma | Oh.. so I was supposed to know that. | 15:48 |
| fsmithred | that one does not belong in that list | 15:48 |
| fsmithred | pick a different one | 15:48 |
| dokma | I get it now. | 15:48 |
| fsmithred | no, you absolutely were NOT supposed to know that | 15:48 |
| hagbard | That linkt to lmu is indeed wrong. should be http://devuan-cd.bio.lmu.de/ | 15:49 |
| fsmithred | hagbard, thanks. That's better than removing it. | 15:51 |
| fsmithred | all better | 16:00 |
| FilipZ | rrq: I pasted "pre-up pkill -9 dhclient" after "iace default inet dhcp", in mine interfaces file, like you wrote. After I turned my PC again, wpa_gui and wpa_cli turned on three times, and dhclient didn't turn at all. I had to comment out that line for it to start to work again. | 16:14 |
| fhffhqvb | https://www.devuan.org/os/releases says ASCII is "Maintained", but there hasn't been a update since july, apart from devuan-keyring...? | 17:08 |
| hagbard | I think that is just the status of the debian release, where packages from oldoldstable could still get security updates once in a blue moon. | 17:11 |
| fhffhqvb | i would at least expected tzdata to get an update, i saw an update in beowulf. and isc-dhcp-client. | 17:15 |
| hagbard | But practicality and pragmatism taken into account, the status might well be called 6-feet-under-and-grass-growing-on-top, yes. | 17:15 |
| gnarface | if you were going to archive a copy for posterity, now would be the time | 17:17 |
| hagbard | Oh, wait, it actually isn't maintained any more: Debian sais: "Debian LTS support for Debian 9 "Stretch" ended on June 30, 2022 " | 17:20 |
| hagbard | https://wiki.debian.org/LTS | 17:21 |
| fhffhqvb | so maybe change the status? | 17:21 |
| fsmithred | stretch has not been moved to archive.debian.org yet. | 17:33 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!