| systemdlete | lsusb -v says "can't get debug descriptor: Resource temporarily unavailable" and "can't get device qualifier: Resource temporarily unavailable" on stderr many times. I am seeing this on beowulf and chimaera on HARDWARE, not just VMs. | 03:03 |
|---|---|---|
| systemdlete | I detached every USB device and still getting those messages, but only with the -v option to lsusb. Plain lsusb does not generate those messages. | 03:04 |
| systemdlete | I've web searched for this, but most of the posts are from years ago, or they are specific to like Ubuntu, etc. | 03:04 |
| systemdlete | At any rate, none of them seem to provide a solution. | 03:05 |
| systemdlete | These errors don't indicate which device(s) are the culprits. (The hubs maybe? idk) | 03:06 |
| systemdlete | Must be the hubs. I just ran a test on a chimaera box, using a PS2 keyboard. lsusb (no -v) shows only hubs. But lsusb -v shows the errors. | 03:16 |
| rwp | I have no idea. Sounds like a bizarre problem. Did you disconnect something that was mounted without unmounting it? Was there data unflushed? | 03:16 |
| rwp | I might be inclined to reboot and see if that fixes things. | 03:17 |
| systemdlete | I've rebooted many times, with no change. | 03:17 |
| systemdlete | Are you asking about usb drives? | 03:17 |
| systemdlete | I haven't had any connected to either of my PCs since they have been rebooted. | 03:18 |
| rwp | Only asking about usb drives because they have state and you have a problem with usb state. | 03:18 |
| systemdlete | how do you know? Those messages don't seem to say much | 03:18 |
| systemdlete | It just says some resource is unavailable. It doesn't say which device. | 03:19 |
| rwp | It doesn't say which device but it is lsusb so it must be listing out the usb bus. Probably not a keyboard. Probably not a mouse. So what other usb things do people typically plug in? | 03:19 |
| systemdlete | I could try a cold reboot with a PS2 keyboard and do an lsusb -v. But that might be overkill. | 03:20 |
| systemdlete | I mean, with no usb devices plugged in at all. | 03:20 |
| systemdlete | but like you say, I doubt it is a kb or mouse also. | 03:20 |
| gnarface | tried a cold boot? | 03:20 |
| systemdlete | just about to do that, gnarface. | 03:20 |
| systemdlete | bbs... | 03:21 |
| systemdlete | sorry charlie, no difference. | 03:26 |
| systemdlete | I just cold-booted my test box with no USB attachments, period. Keyboard is PS2. And of course the HDMI for video. That's it. Still, when I log in as root, I get those same messages. So this could not have to do with previously plugged-in usb devices. | 03:27 |
| systemdlete | Most interestingly, the two boxes have different mainboards too. | 03:28 |
| systemdlete | and they are running different versions of the kernel. | 03:29 |
| systemdlete | so I opened two windows on the testbox and logged both into root. In one of those root windows, I tail -f /var/log/kern.log. In the other, I run "lsusb -v" | 03:33 |
| systemdlete | I can see the errors from lsusb -v, but not a peep from the kern.log. | 03:33 |
| systemdlete | also tried the messages and syslog logfiles, but same thing: no messages | 03:34 |
| systemdlete | I suppose there is strace | 03:35 |
| gnarface | very strange | 03:37 |
| gnarface | says temporarily unavailable though... like it plans on getting it eventually... | 03:37 |
| gnarface | i wonder what's doing that | 03:37 |
| rwp | I can reproduce the problem here too. It seems to be Linux kernel version related. | 03:37 |
| rwp | lsusb -v >/dev/null and the error messages are to stderr. | 03:38 |
| rwp | Both Beowulf and Chimaera kernels. But for example older Stretch is clean. | 03:38 |
| gnarface | oh, i'm seeing it on ceres too but it says "Couldn't open device, some information will be missing" instead | 03:39 |
| gnarface | i wouldn't worry about it, it's probably snafu | 03:39 |
| gnarface | maybe if you run it as root it won't do that | 03:39 |
| rwp | Hmm... My Ceres VM system is clean. But a chimaera VM emits the message. So it isn't clean because it is a VM. | 03:41 |
| rwp | systemdlete, What kernel version? uname -r | 03:42 |
| systemdlete | This happens with either the beowulf or chimaera kernels (standard issue ones) | 03:43 |
| systemdlete | so pastebinit does not work anymore? | 03:43 |
| systemdlete | I've been getting errors lately. Used to work fine. | 03:43 |
| systemdlete | Is there a better tool (should I use tpaste?) | 03:43 |
| systemdlete | I wanted to share my strace output | 03:44 |
| gnarface | you can't make pastebinit point to paste.debian.org anymore? | 03:45 |
| systemdlete | https://pastebin.com/JCkYazB2 | 03:47 |
| systemdlete | (uploaded it to pastebin manually) | 03:47 |
| systemdlete | I don't know; havn't looked into it really | 03:47 |
| systemdlete | I installed pastebinit. Do I need to make mods for it to work? | 03:47 |
| systemdlete | try logging in as root; you get different messages | 03:48 |
| gnarface | well you gotta change something to make it point to paste.debian.net (.net not .org my bad) but i'm not sure exactly what | 03:48 |
| systemdlete | oh | 03:48 |
| systemdlete | ok, not pastebin.com, gotcha | 03:49 |
| rwp | I tried lsusb -v as root across several different kernels. https://paste.debian.net/plain/1238007 | 03:49 |
| * systemdlete is so happy that others are able to reproduce the same silly problem | 03:49 | |
| systemdlete | (for once) | 03:49 |
| gnarface | debug descriptor, interesting | 03:49 |
| systemdlete | [somewhere in open source devland, some programmer is thinking OH S***T] | 03:50 |
| rwp | There were several errors. I just trimmed to either 1) clean or 2) emitted an error. There is also "device qualifier" mentioned too. | 03:50 |
| systemdlete | Sometimes error messages, while they themselves might be innocuous, are indicative of possibly deeper problems | 03:51 |
| rwp | JFTR but there is no guarantee this is kernel version related. Not yet. It could be lsusb version related. Or something else. | 03:51 |
| systemdlete | Seems more like the maintainer left debugging on when they checked in their code. | 03:52 |
| systemdlete | Because, honestly, for the most part, usb works. | 03:52 |
| systemdlete | [I DID say "for the most part"] | 03:53 |
| systemdlete | gnarface: I created a .pastebinit.xml file in my home directory, and it works, except it doesn't give me the page it pasted to, just the url and domainname | 03:59 |
| systemdlete | It works, rc = 0 | 03:59 |
| systemdlete | (I mean echo $? gives 0) | 03:59 |
| systemdlete | OK, pastebinit -l shows supported pastebins. debian is not one of them. | 04:02 |
| systemdlete | Trying dpaste, which is supported, it works correcctly again. | 04:03 |
| * systemdlete is once again reminded how useful the man pages can sometimes be | 04:04 | |
| systemdlete | hey, rwp and gnarface, thanks for looking at this | 04:05 |
| gnarface | ok, here's something a little weird though, rwp, systemdlete ... on my 4.19.0-20-amd64 kernel here there's no errors | 05:05 |
| gnarface | though in the actual device listings there's some "Capabilities: <access denied>" fields if you don't run it as root | 05:06 |
| gnarface | (when running as root the capabilities are populated) | 05:06 |
| gnarface | that diverges from rwp's report for 4.19.0-20-amd64, so there's some variable here besides the kernel version | 05:07 |
| gnarface | now this is starting to ring a bell, like it's been brought up before, but i can't remember what the diagnosis turned out to be | 05:07 |
| gnarface | that's a different machine, so the motherboards may be a factor still | 05:16 |
| systemdlete | Interesting because I am also running that on my beowulf box. | 05:22 |
| systemdlete | And getting the errors, as root. | 05:22 |
| systemdlete | You will get different errors running lsusb as root vs a regular user | 05:22 |
| systemdlete | (I've seen that on numerous posts about this issue) | 05:22 |
| systemdlete | gnarface: Mine is a Gigabyte board (beowulf box) | 05:23 |
| systemdlete | GA-970A-DS3P | 05:23 |
| rwp | gnarface, All of my runs were as root. Some were VMs and some were bare metal. | 05:55 |
| rwp | But two bare metal machines are clean. One is Beowulf and one is Ceres. | 05:56 |
| rwp | Sorry, strike that, I meant to say my bare metal Beowulf system reports the error but the bare metal Ceres machine is clean. | 05:56 |
| rwp | But as you say they are different motherboards in my case too. | 05:56 |
| gnarface | the more i think about it the more i think maybe it is a problem with lspci | 08:11 |
| gnarface | maybe sometimes mismatching kernel api features or something | 08:11 |
| systemdlete | If I install daedelus, I could see if the same problem occurs (kind of like ceres, I'd think) | 08:33 |
| systemdlete | (unless ceres has even more advanced kernels than daedelus) | 08:33 |
| brocashelm | ceres and daedalus are still pretty close | 08:45 |
| systemdlete | what do I need to install ceres? | 08:45 |
| systemdlete | (IN case I decide to do that) | 08:45 |
| brocashelm | to install ceres entirely or just certain packages? | 08:46 |
| systemdlete | Well, enough to make it run anyway | 08:46 |
| brocashelm | for the former, it's as easy as changing codenames on your sources.list and running apt update, apt dist-upgrade, and apt upgrade in that order | 08:47 |
| systemdlete | This would only be for some light testing. Here, I am interested in the usb subsystem | 08:47 |
| systemdlete | former=ceres? | 08:47 |
| brocashelm | for a full ceres install, yes | 08:47 |
| brocashelm | for the latter (certain packages from ceres), it can be done through some apt pinning stuff, but it's riskier and you might create a frankendevuan | 08:48 |
| systemdlete | so, I could essentially copy my chimaera install and distupgrade it? | 08:48 |
| brocashelm | so if you get anything from daedalus or ceres, you're better off just upgrading to those if the backports aren't doing it for you | 08:48 |
| systemdlete | "frankendevuan" -- I find that is hard to say out loud | 08:48 |
| brocashelm | yeah, as long as you change your codename from chimaera to ceres (only one line needed, so comment out the other repos like security, updates, etc.) | 08:49 |
| systemdlete | Well, I think I'll do a fresh install of daedalus from the ISO of apr 11 | 08:49 |
| systemdlete | or | 08:50 |
| brocashelm | you could do that | 08:50 |
| systemdlete | maybe I'll copy chimaera and upgrade it, idk. | 08:50 |
| brocashelm | better to upgrade | 08:50 |
| systemdlete | Why is it better? | 08:50 |
| brocashelm | as long as you have your backups, you can just reverse it if it doesn't work out | 08:50 |
| brocashelm | saves time with configs and other things | 08:51 |
| u-amarsh04 | As far as flexibility trying out different versions, I've used aptitude with preference for unstable, but testing, stable and experimental available | 08:51 |
| systemdlete | Or, I can just create a partition and copy it and then if I don't like it I can just blow it away. | 08:51 |
| brocashelm | sure | 08:51 |
| brocashelm | you could do that. copy your chimaera and upgrade that one | 08:51 |
| systemdlete | I mean, a full install only requires about 20g at most | 08:51 |
| systemdlete | I usually move my /home and /var to separate partitions anyway sometime after the install | 08:52 |
| systemdlete | that is, if I think I'll need the space. I prefer using lvm for all that. | 08:52 |
| systemdlete | So now we have established many paths. Thank you for these suggestions. | 08:52 |
| brocashelm | np | 08:53 |
| systemdlete | frankendevuan. | 08:53 |
| brocashelm | running ceres since june 2020 and never had any problems. just know what you're getting yourself into and you'll be fine. apt-listbugs is a useful package for this branch | 08:53 |
| systemdlete | FRANK-n-DEV-wun | 08:53 |
| systemdlete | I guess | 08:53 |
| brocashelm | current kernel for ceres/daedalus is 5.16.18-1 | 08:54 |
| systemdlete | For experimental stuff that is probably fine, yes. But for my personal stuff (banking, etc) I am kind of old and stuffy. I like the stable releases. | 08:54 |
| systemdlete | that is not too far off from current kernel on chimaera. | 08:55 |
| brocashelm | all down to personal use cases. all my devuans are ceres and that's ok with me ;) | 08:55 |
| brocashelm | but try it on a separate partition and see if you like it | 08:55 |
| systemdlete | It's really not a matter of "liking it" per se, for me. It's more a matter of seeing what it can and can't do, and how it may address some of the issues I have with current releases. | 08:56 |
| systemdlete | I mean, I like devuan, the only distro I really like at this point. | 08:56 |
| systemdlete | There is adelie, but that seems to be years away from finished product. But this is getting OT... | 08:57 |
| systemdlete | I don't want to get beaten with a stick here... | 08:57 |
| brocashelm | depending on what you need it for, i find gaming a lot snappier with ceres | 08:57 |
| brocashelm | but that could be due to newer video drivers | 08:57 |
| systemdlete | Any word on when debian is releasing next? I mean, for our daedalus | 08:58 |
| systemdlete | Last I heard was this summer | 08:58 |
| systemdlete | (Iirc) | 08:58 |
| brocashelm | whatever debian says. this page will tell you when to expect a freeze for testing (hence daedalus): https://release.debian.org/bookworm/freeze_policy.html | 08:59 |
| brocashelm | lts releases are every two years usually and bullseye only came out in august 2021 | 09:00 |
| systemdlete | now it's jan 23 | 09:00 |
| systemdlete | jan '23 | 09:00 |
| systemdlete | sometime after march '23 | 09:01 |
| systemdlete | so I have some time yet... | 09:01 |
| systemdlete | I still have some VMs to upgrade | 09:02 |
| systemdlete | ok, so I have installed a basic daedalus system on my testbox and I'm adding some packages. lsusb does not issue errors as regular user or root. But lsusb -v DOES issue errors for regular user, but not for root. | 12:10 |
| systemdlete | for the regular user, it just bitches that some info may be missing. Other than that, it looks "clean" | 12:11 |
| systemdlete | the stock kernel for daedalus seems to be 5.16.0-6 | 12:12 |
| systemdlete | I would up installing daedalus from a thumbdrive. | 12:14 |
| systemdlete | for daedalus, I had to make a change to the sources.list file. I changed the daedalus-security to just daedalus. It would not allow me to run apt update otherwise. | 19:08 |
| golinux | systemdlete: security and backports repos do not exist for the testing branch currently daedalus | 20:26 |
| xrogaan | That's intended. Debian's backport and security channels are special, in that they allow in changes to an otherwise frozen system. Testing is constantly changing, so no need for special channels. | 23:08 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!