FilipZ | Hi! I was there some time before, and asked about a help with the bugged wireless software. I use currently the wpa_gui to connect. I think I have 2 at least partially separate issues, where one kills the wireless software until the system is restarted, and the second causes my wireless software to repeatedly disconnect and connect with the Wi-Fi. I decided to leave fixing of the first, bigger issue, for later as it seemed to be to | 06:36 |
---|---|---|
FilipZ | to resolve, and I would like to at least fix the second issue for now. It looks to me like wpa_gui gets in conflict with itself, as every time when it happens, there appear 4 processes called: 1. "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"; 2. "sh -c CLIENT="-i"; /sbin/dhclient -4 -v $CLIENT -pf /run/dhclient.wlan0.pid -If /var/lib/dhcp/d | 06:36 |
FilipZ | t.wlan0.leases -I -df /var/lib/dhcp/dhclient6.wlan0.leases wlan0"; 3. "ifup -v --force wlanO=default"; 4. "wpa_action wlan0 CONNECTED"; and after this 4 another processes: 1. "dhclient -4 -v -i -r -pf /run/dhclient.wlan0.pid -If /var/lib/dhcp/dhclient.wlan0.leases -I -df /var/lib/dhcp/dhclient6.wlan0.leases wlan0"; 2. "sh -c CLIENT="-i"; /sbin/dhclient -4 -v $CLIENT -r -pf /run/dhclient.wian0.pid -If /var/lib/dhcp/dhclient.wlan0.le | 06:36 |
FilipZ | I -df /var/lib/dhcp/dhclient6.wlan0.leases wlan0"; 3. "ifdown -v wlan0"; 4. "wpa_action wlan0 DISCONNECTED". Those processes are created, and closed repeatedly as the Wi-Fi is connected, and disconnected, until I eventually do "ifdown --force wlan0", except that dhclient processes accumulate over time while it happens. After "ifdown --force wlan0", then closing the dhclient processes, and then using "ifup wlan0", the issue is tempo | 06:36 |
FilipZ | fixed. What could be causing this behavior, and how could I fix that? | 06:36 |
chomwitt | in daedalus trying a 'apt-get upgrade' i see hundred of packages kept back. why that is happening | 10:43 |
gnarface | chomwitt: expected behavior from time to time with testing and unstable | 11:46 |
gnarface | basically what's happening is a package is broken somewhere and you're being protected form it | 11:46 |
gnarface | *from it | 11:46 |
gnarface | usually it'll pass unless you've already installed something broken before this | 11:46 |
gnarface | well, "broken" may be an oversimplification, i think it can also happen if you still have something installed from a previous distro that has been obsoleted by something new | 11:47 |
gnarface | you can easily tell if it's this second case though by comparing the difference between "upgrade" and "dist-upgrade" | 11:48 |
gnarface | dist-upgrade will just uninstall the obsolete packages to make way for the new ones | 11:48 |
gnarface | if whatever they're migrating to is not done yet though this could leave your system in an even more broken state, so i'd recommend against actually doing it | 11:49 |
gnarface | or at least make a full backup first | 11:49 |
gnarface | i don't know anything specific about this particular issue, just reciting relevant experience from past incidents | 11:50 |
chomwitt | gnarface, thanks | 15:25 |
rwp | chomwitt, In addition to that... New packages will want new dependencies. When running Testing one must run "apt-get upgrade", followed by "apt-get upgrade --with-new-pkgs", those are both _safe_ in that they will not remove anything. | 17:19 |
rwp | chomwitt, And then after those have install new packages then *try carefully* "apt-get dist-upgrade" reviewing the solution and approving only if reasonable. | 17:19 |
rwp | In Testing and Unstable as gnarface noted there are often migrations and transitions where the repository is in a transition state and not yet ready. | 17:20 |
rwp | After "upgrade", "upgrade --with-new-pkgs", "dist-upgrade", then purge off old dependencies no longer needed with "autoremove --purge". | 17:21 |
rwp | Review older removals now forgotten but still clinging on with "dpkg -l | grep ^rc". And transitions "dpkg -l | grep -e transition -e dummy". | 17:22 |
chomwitt | rwp, why should i do the dist-upgrade step? | 17:31 |
chomwitt | i have devuan daedalus which is testing i think | 17:32 |
gnarface | yes, daedalus is testing, and you'd still have to dist-upgrade occasionally to stay with it. in the process of being testing, old packages from chimaera (current stable) are being replaced with new ones for daedalus | 17:37 |
gnarface | but the regular "upgrade" mode will try hard to preserve functionality by blocking removal of anything that would break abi compatibility with anything else | 17:38 |
chomwitt | gnarface, thanks! i wasnt aware of that | 17:38 |
rwp | Even in Stable some upgrades require dist-upgrade. Have had security upgrades get recompiled with newer shared libraries. | 17:39 |
gnarface | yea i think you usually need dist-upgrade to replace a kernel too don't you? | 17:41 |
rwp | Yes. Some kernel security upgrades replace the existing kernel rather than upgrade it. (I do not approve.) And that requires removing the previous pkg version. | 17:42 |
rwp | Some people always use dist-upgrade for everything. That is possible to work. But the tangle of packages can be HUGE. Too huge to review. | 17:44 |
gnarface | there's some rules i've observed, like if you manually request something to be installed explicitly in the previous release then any packages that would cause it to be removed in the next release need a dist-upgrade or they'll be held back too | 17:44 |
rwp | And if people blindly dist-upgrade with Testing and Unstable and then just say Yes do it, then often that will REMOVE half the system. Bad time! | 17:44 |
gnarface | yea sometimes they don't actually have a workable solution in the repo, you really gotta pay attention to the removals before you let them happen | 17:45 |
rwp | Therefore I always do the safe operations first (upgrade, upgrade --with-new-pkgs) to reduce the amount of review needed with dist-upgrade. | 17:45 |
rwp | Right! | 17:45 |
rwp | Regarding your comment about autoremove, there is a flag noting if the package was pulled in explicitly or as a dependency. | 17:46 |
rwp | Run: apt-mark showmanual | 17:47 |
rwp | Those are explicitly installed packages. Those will never be candidates for "autoremove". | 17:47 |
rwp | These flags can be changed using apt-mark such as "apt-mark auto foo" will mark foo as being automatically installed by dependency rather than by explicit manual action. Making it a candidate for autoremove again. | 17:48 |
rwp | Sometimes in Testing and Unstable when the repos is in an unsafe transition condition but I do want something anyway I will craft things by using "apt-mark hold foo" to prevent it from being a candidate for remove. Then repeat the dist-upgrade review. Then hold another. Review. And then eventually get a solution I want. | 17:49 |
rwp | Then after that remove the temporary holds that I just applied. Don't forget that step! | 17:50 |
rwp | Can unhold everything all at once: apt-mark unhold $(apt-mark showhold) | 17:50 |
rwp | I prefer doing this with apt-mark and apt-get but this "crafting" of hinted solutions is what people who like aptitude tell me they like about aptitude because aptitude has an interactive solver mode. But I could never get comfortable with aptitude. | 17:52 |
chomwitt | so if i understand correctly the hundred list packages as 'kept back' could be because apt-get upgrade is not allowed to remove some packages or install new ones thus not being able to upgrade some installed ones ? | 17:58 |
djph | yes | 17:58 |
djph | or they have conflicting dependencies now (so "don't touch") | 17:59 |
chomwitt | so should i try now the dist-upgrade ? | 17:59 |
gnarface | did you make a backup? | 17:59 |
gnarface | you should really make a backup | 18:00 |
chomwitt | i have 'back in time' taking care of the directories i want but not of my whole system | 18:01 |
gnarface | well there's a real risk of making a mess you can't clean up | 18:05 |
chomwitt | one parenthetical question : why lsb_release says i have Devuan GNU/Linux 5 (daedalus/ceres) and not Devuan GNU/Linux 5 (daedalus) ? | 18:06 |
chomwitt | gnarface, do you take backups of you whole system i mean like images ? | 18:06 |
gnarface | as i understand it, it's because testing is forked from unstable after the previous testing goes stable and the previous stable goes to oldstable | 18:07 |
gnarface | i do take full disk image backups of some systems, i try to at least save the package list with the others | 18:08 |
chomwitt | gnarface, what image backup utility do you use ? | 18:13 |
gnarface | tar or dd as appropriate | 18:14 |
gnarface | mysqldump for databases... | 18:14 |
chomwitt | gnarface, i see . you prefer to stay close to command line . thanks also for answering the parenthetical question | 18:15 |
gnarface | yea i don't like backups to be fancy, it's bad luck | 18:16 |
msiism | rsync also makes a pretty good tool for backups. | 18:18 |
msiism | At least for a certain kind of backup. | 18:18 |
APic | Yes. | 18:18 |
gnarface | you can save a lot of time with rsync in theory if you do it right | 18:20 |
gnarface | but it's not easy to learn | 18:20 |
msiism | I use rsync for my daily backup and then something else that does snapshots, from time to time. | 18:20 |
chomwitt | https://www.linuxquestions.org/questions/2021-linuxquestions-org-members-choice-awards-133/backup-application-of-the-year-4175705728/ | 18:21 |
msiism | The results are presented in kind of a weird order here. | 18:24 |
rwp | chomwitt, Re: "daedalus/ceres" instead of "daedalus". It's because Daedalus is Testing now. Testing is NOT RELEASED. Testing is a release candidate. | 18:58 |
rwp | Stable is like when the wait staff bring food to your table at a restaurant. | 19:01 |
rwp | Testing is like walking into the kitchen and sampling the food while it is being plated. | 19:01 |
rwp | Unstable is like following the chef around and sampling the food while it is being cooked. | 19:01 |
rwp | chomwitt, If you pastebin the upgrade and dist-upgrade output we could give a review opinion on it. | 19:03 |
chomwitt | rwp, i liked the cooking analogy | 19:35 |
plasma41 | Debian has announced the eventual name of Debian 14, due for release in ~2027: Forky | 20:26 |
plasma41 | The jokes write themselves :-P | 20:26 |
bb|hcb | The should have choosen spoony, so devuan could become forky ;) | 20:30 |
plasma41 | Devuan 7 "F____" will be the next release since Devuan 3 "Beowulf" to share the same first letter as the corresponding Debian release. | 20:36 |
fluffywolf | so how long do we have to get a minor planet renamed to forky so we can use it too? :P | 20:56 |
fsmithred | fluffywolf, maybe three years. | 22:13 |
fsmithred | zo | 22:15 |
fsmithred | I'm bad at math. More like five years. | 22:15 |
fsmithred | bad at typing, too. | 22:15 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!