Re: Re: I cannot shutdown/poweroff after a HW upgrade - kernel gets stuck.
On Sun, Mar 26, 2023 at 11:33 PM Ram Ramesh wrote: > Hi Ramesh, > > this might help. The bug is fixed with kernel 6.0.2-1 > > https://groups.google.com/g/linux.debian.bugs.dist/c/p-sgJiTR00A?pli=1 > > All the best to you > Eike > > Elke, > > Thanks. v6.1 is available on bullseye-backports. I installed it and the > trouble is gone now. > > BTW, does non-free firmware tied to kernel version? > > I use firmware-realtek to deal with my dragon 2.5G NIC that seems to be > unstable without realtek-firmware. I want to make sure I use the correct > version (for linux v6.1), if there is such a requirement. > You will have to add and enable the non-free-firmware repo. deb http://deb.debian.org/debian/ bookworm main non-free contrib non-free-firmware Binary Blobs are not directly tied to a kernel version. Since the kernel became modular drivers and firmware are able to be developed and released on their own schedule. > Regards > Ramesh > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: Re: I cannot shutdown/poweroff after a HW upgrade - kernel gets stuck.
Hi Ramesh, this might help. The bug is fixed with kernel 6.0.2-1 https://groups.google.com/g/linux.debian.bugs.dist/c/p-sgJiTR00A?pli=1 All the best to you Eike Elke, Thanks. v6.1 is available on bullseye-backports. I installed it and the trouble is gone now. BTW, does non-free firmware tied to kernel version? I use firmware-realtek to deal with my dragon 2.5G NIC that seems to be unstable without realtek-firmware. I want to make sure I use the correct version (for linux v6.1), if there is such a requirement. Regards Ramesh
Re: exim failure
On Sun 26 Mar 2023 at 12:47:45 (-0700), pe...@easthope.ca wrote: > > (4) "TLS on connect is not natively supported." OK but the test > confirmed that it can work. Documentation could tell how to > configure. Otherwise link to instructions at least. > > (5) > https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html > states "There is also a -tls-on-connect command line option. This > overrides tls_on_connect_ports; it forces the TLS-only behaviour for > all ports." Connection from the local MUA to exim isn't encrypted. > The command line option will block that? > > What ideas are there to configure TLS-on-connect for localhost to > smarthost and leave MUA to localhost unencrypted on port 25? Just above that paragraph is the example for tls_on_connect_ports, ie tls_on_connect_ports = 465 I assume this goes into the configuration rather than the command line. I've never had to configure at this level without the benefit of a MACRO_PARAMETER to set. For example, I turn off certificate stuff on my LAN with: $ cat /etc/exim4/exim4.conf.localmacros # /etc/exim4/exim4.conf.localmacros MAIN_TLS_ADVERTISE_HOSTS = # $ Lacking a macro, you could try editing either /var/lib/exim4/config.autogenerated (rather like editing grub.cfg, in that reconfiguring Grub will overwrite it), or /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost which is more permanent (keep a backup of original). You might try adding the setting after the first active line in 30_exim4-config_remote_smtp_smarthost, or test it by adding it after line 857 in config.autogenerated (the same text). That assumes that the exim in bullseye supports what's documented for the latest version. Cheers, David.
Re: What's the correct procedure for replacing a DKMS module when it's upstreamed?
On Sun, Mar 26 2023 at 05:07:29 PM, Andy Smith wrote: > On Sun, Mar 26, 2023 at 04:51:25AM +, Andy Smith wrote: >> I have to build the kernel driver as an external DKMS >> module from: >> >> https://github.com/lwfinger/rtw89 >> >> Specifically that is the rtw_8852be module. >> >> That works fine, but it seems that this driver actually is present >> in upstream kernel versions somewhere in v6.1.x. > > After asking about this on debian-kernel it was pointed out that the > driver is not actually functional until somewhere in the 6.2 > upstream kernel, so is unlikely to be making it to a 6.1 LTS kernel > that will be found in bookworm. > > It may be in the trixie kernel package and/or I may end up getting > it from some future bookworm-backports kernel package, so the > question still remains about the proper way to transition from a > DKMS to an included module. > If you used dkms add to install the driver in the first place, dkms remove will remove it. See the manpage for the dkms command for details. If you installed a -dkms package to get the kernel module (there are several such packages in the debian repositories), uninstalling it will remove it. -- regards, kushal
Re: cpan oddity
On 2023-03-27 08:21, Jude DaShiell wrote: I ran cpan and did quick configuration and chose sudo to elevate privileges when necessary. Unfortunately I don't have write access on /usr/local/bin so cpan is crippled. -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and amo. Please use in that order." Ed Howdershelt 1940. try cpanminus? $ sudo apt install cpanminus
Re: cpan oddity
Jude DaShiell wrote: > I ran cpan and did quick configuration and chose sudo to elevate > privileges when necessary. Unfortunately I don't have write access on > /usr/local/bin so cpan is crippled. You can re-answer all the cpan questions by typing: cpan o conf init -dsr-
cpan oddity
I ran cpan and did quick configuration and chose sudo to elevate privileges when necessary. Unfortunately I don't have write access on /usr/local/bin so cpan is crippled. -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and amo. Please use in that order." Ed Howdershelt 1940.
Re: I cannot shutdown/poweroff after a HW upgrade - kernel gets stuck.
On Sonntag, 26. März 2023 18:08:15 -04 Ram Ramesh wrote: > I wanted to upgrade my server from 10 year old HW to something newer. > THis server runs debian bullseye with v5.19 kernel from backports. [snip] > > The only trouble I have is that it refuses to > reboot/shutdown/poweroff. It seem to go through all steps and reach > the end but seem to get stuck in this endless cycle complaining about > some blkdev issue. Here are the last lines printed on the console > that shows the cycle > > [OK] Reached target Power-off > [67652.NN] block device autoloading is deprecated and will be > removed > > [67667.NN] blkdev_get_no_open: 119 callbacks suppressed > different and number of callbacks being slightly different> > > I assume by "[OK]..." line that we are really at the end of shut down > process. When I turn off physically using power switch and reboot, I > do not get any fsck error messages. So, I assume that filesystems are > safe and kernel is somehow lost in some thread and cannot end the > reboot process. > > Any ideas what I can do? > > Regards > Ramesh Hi Ramesh, this might help. The bug is fixed with kernel 6.0.2-1 https://groups.google.com/g/linux.debian.bugs.dist/c/p-sgJiTR00A?pli=1[1] All the best to you Eike -- Eike Lantzsch KY4PZ / ZP5CGE [1] https://groups.google.com/g/linux.debian.bugs.dist/c/p-sgJiTR00A?pli=1
Re: Buster => Bullseye: packages kept back
On 2023-03-26 20:15, David Wright wrote:
On Sun 26 Mar 2023 at 11:16:21 (+0200), Jesper Dybdal wrote:
Yesterday, I upgraded Buster => Bullseye.
This morning, I got a mail from unattended-upgrades, which said:
Packages with upgradable origin but kept back:
Debian stable:
guile-2.2-libs w3m
and
Package guile-2.2-libs is kept back because a related package is kept back or
due to local apt_preferences(5).
Package w3m is kept back because a related package is kept back or due to local
apt_preferences(5).
What does this mean? I have what I believe to be a clean install, I
have never used apt_preferences, and until now, I had never heard of
guile or w3m. And I don't quite understand why I have them installed
at all. My sources.list contains only bullseye and
bullseye-backports.
It's a little odd that, the day after upgrading releases, you
already have backports in your sources list. Is there a specific
reason for that?
No. The reason is only that experience shows that during the lifetime
of a stable release, I will install a few backports. So the list might
just as well be ready from start. And currently, there is no backported
packages installed.
Your system seems to have some old packages on it; for example,
heirloom-mailx and ripole are both from stretch. If you need them,
check trhat you still have access to local copies of those packages
and then try removing them to see whether they're causing a logjam.
apt list says:
guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable
to: 2.2.7+1-6]
w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
If you read the Release Notes that come with each release, you'll
find instructions on "cleaning" a system before upgrading. A useful
tool to help with that is, for example:
$ aptitude why w3m
i imagemagick-6-doc Recommends www-browser
i w3m Provides www-browser
$
Thanks. The release notes do not mention aptitude why, which seems a
good tool.
which would mean, on my system in similar circumstances, that I could
remove w3m without ill effects, and then reinstall it later, after
things have unjammed. Similarly:
$ aptitude why guile-2.2-libs
i emacs-gtkDependsemacs-bin-common (= 1:27.1+1-3.1+deb11u2)
i A emacs-bin-common Recommends mailutils
i A mailutilsDependslibmailutils7
i A libmailutils7Dependsguile-2.2-libs
$
Here I could remove mailutils, though in this case certain commands
could temporarily fail, eg a cron job that sends an email.
$ apt-get -s purge mailutils
[ … ]
The following packages were automatically installed and are no longer required:
gsasl-common guile-2.2-libs libgsasl7 libmailutils7 libntlm0 mailutils-common
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
mailutils*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Purg mailutils [1:3.10-3+b1]
$
One of those no longer required packages may be what's causing the
problem. They can be reinstalled after you get a clean upgrade.
If things don't turn out as simple as that, then I would have an
in-depth read of man aptitude which can test (aptitude -s)
various paths for fixing the problem. It has the patience to
figure out all the dependency/recommendation chains for any
package on the system. (My system has 56 reasons to install
guile-2.2-libs though, as we know, none is entirely based on
dependencies.)
$ aptitude -v --show-summary=all-packages why guile-2.2-libs | less
Not /every/ package on a system has to come from the same release
version, but you should know which are the exceptions, why they're
installed, and what their dependencies are. So, for example, I have
squeeze's xtoolwait, whose dependencies, libc6 (>= 2.2.5), libx11-6,
and libxext6, are straightforward to satisfy.
One configuration change I always make is:
$ cat /etc/logrotate.d/apt
/var/log/apt/term.log {
rotate -1
monthly
compress
missingok
notifempty
}
/var/log/apt/history.log {
rotate -1
monthly
compress
missingok
notifempty
}
$
which keeps a perpetual log of what gets installed on a system, when,
and hints as to why. This helps to answer the questions implied in
your opening paragraphs. (I don't install with aptitude, but that
has a similar configuration parameter.)
Cheers,
David.
I have not yet decided exactly what I'll do, but each answer to my
original post has significantly improved my understanding of the install
system.
Many thanks to everybody who answered!
--
Jesper Dybdal
https://www.dybdal.dk
I cannot shutdown/poweroff after a HW upgrade - kernel gets stuck.
I wanted to upgrade my server from 10 year old HW to something newer. THis server runs debian bullseye with v5.19 kernel from backports. Here is the list of items I got in the upgraded system 1. Intel z690 mother board (asrock steel legend) 2. Core i3-13100 cpu 3. Super Flower 650W PSU, 4. G.SKILL DDR4 RAM 5. 2x SK hynix P31 nvme SSD 1TB each. I reused these from old build 1. Geforce GT 630 video card 2. SAS9211i HBA card for extra SATA ports 3. All my large spinning drives that contained data in RAID6 and RAID1 I made a raid1 on mvme ssd and created 3 partitions. In one I installed debian testing (bookworm with v6.1 kernel) and in another, I image copied the old installation I had before the HW upgrade. Debian bookworm runs fine and reboots/shutsdown as expected. My old system copied over also works fine for most part. It boots and runs everything that I care about. All my RAID disks are working. No issue as long as it runs. The only trouble I have is that it refuses to reboot/shutdown/poweroff. It seem to go through all steps and reach the end but seem to get stuck in this endless cycle complaining about some blkdev issue. Here are the last lines printed on the console that shows the cycle [OK] Reached target Power-off [67652.NN] block device autoloading is deprecated and will be removed [67667.NN] blkdev_get_no_open: 119 callbacks suppressed I assume by "[OK]..." line that we are really at the end of shut down process. When I turn off physically using power switch and reboot, I do not get any fsck error messages. So, I assume that filesystems are safe and kernel is somehow lost in some thread and cannot end the reboot process. Any ideas what I can do? Regards Ramesh
Re: Buster => Bullseye: packages kept back
On 2023-03-26 23:12, Jeffrey Walton wrote: On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal wrote: Yesterday, I upgraded Buster => Bullseye. For completeness, here is the Debian procedure for a release upgrade: https://wiki.debian.org/DebianUpgrade . Thanks. Interesting that the Wiki recommends using apt-get, while the Bullseye release notes recommend apt. -- Jesper Dybdal https://www.dybdal.dk
Re: ssh -N en alleen maar ssh -N toestaan
Op 26-03-2023 om 23:51 schreef Paul van der Vlis: Hoi Geert en anderen, Op 26-03-2023 om 12:50 schreef Geert Stappers: Hoi, Uit `man 1 ssh` -N Do not execute a remote command. This is useful for just forward ports. Nu is `ssh -N` een client kant ding. Hoe aan server kant borgen dat alleen maar port forwarding gebeurd? Ik had gedacht om het dicht te timmeren door aan authorized_keys op de server wat toe te voegen aan de regel met de pubkey voor het account dat de `ssh -N` moet gaan doen. Er is "no-port-forwarding" https://www.ssh.com/academy/ssh/authorized-keys-openssh#no-port-forwarding maar niet iets als "only-port-forwarding" https://www.ssh.com/academy/ssh/authorized-keys-openssh Wat zien jullie zoal aan mogelijkheden om aan server kant er voor te zorgen dat SSH client alleen maar een verbinding voor de portforward maakt, dat shell access niet kan? Wat ik doe aan de server-kant is /usr/sbin/nologin als shell gebruiken. Oh, en ik zie dat ik ook dit nog doe in sshd_config: - UsePAM no Match User een,twee AllowTcpForwarding remote AllowStreamLocalForwarding no X11Forwarding no PermitTTY no PermitEmptyPasswords yes PasswordAuthentication yes - Kritiek is welkom ;-) Ik heb trouwens nog een kleine extra beveiliging in de firewall, mensen moeten zich eerst ergens aanmelden, dan pas krijgt hun IP toegang. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Distro tries to set up own partition
On Sun Mar 26 14:37:35 2023 Rich wrote: > The OP very much reminds me of a poster who goes by a different handle > who posts in a different group where each post begins with a vague > statement of a chosen solution for a "problem" and asking for help > with transitioning their chosen solution to completion. > > Of course, omitted is any detail of the initial problem that is trying > to be solved, as well is omitted any and all useful factual details of > system, setup, or environment. > > Then, much like here, after 85+ posts, diverging in multiple different > directions, that other poster will finally be cajoled into revealing > a critical bit of the actual problem and/or a critical fact re. their > system, setup, or environment which shows that all 85+ posts, in seven > different directions, were all just wasted time, and had that poster > just mentioned the real problem they were trying to solve, the > solution could have been offered quickly, and on point. https://en.wikipedia.org/wiki/XY_problem -- /~\ Charlie Gibbs | You can't save the earth \ /| unless you're willing to X I'm really at ac.dekanfrus | make other people sacrifice. / \ if you read it the right way. |-- Dogbert the green consultant
Re: ssh -N en alleen maar ssh -N toestaan
Hoi Geert en anderen, Op 26-03-2023 om 12:50 schreef Geert Stappers: Hoi, Uit `man 1 ssh` -N Do not execute a remote command. This is useful for just forward ports. Nu is `ssh -N` een client kant ding. Hoe aan server kant borgen dat alleen maar port forwarding gebeurd? Ik had gedacht om het dicht te timmeren door aan authorized_keys op de server wat toe te voegen aan de regel met de pubkey voor het account dat de `ssh -N` moet gaan doen. Er is "no-port-forwarding" https://www.ssh.com/academy/ssh/authorized-keys-openssh#no-port-forwarding maar niet iets als "only-port-forwarding" https://www.ssh.com/academy/ssh/authorized-keys-openssh Wat zien jullie zoal aan mogelijkheden om aan server kant er voor te zorgen dat SSH client alleen maar een verbinding voor de portforward maakt, dat shell access niet kan? Wat ik doe aan de server-kant is /usr/sbin/nologin als shell gebruiken. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Buster => Bullseye: packages kept back
On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal wrote: > > Yesterday, I upgraded Buster => Bullseye. For completeness, here is the Debian procedure for a release upgrade: https://wiki.debian.org/DebianUpgrade . Jeff
Re: Potentially OT. Videos lagging & buffering in any browser but Google Chrome.
On 3/26/23, Juan R.D. Silva wrote: > Hi folks, > > Debian Bullseye here up to date. Browsers installed: Firefox, Opera, > Vivaldi, and Google Chrome. > > I'm having a weird problem streaming movies from archive.org. The movies > are lagging & keep buffering in all browsers but Google Chrome. Google > Chrome streams same movies at the same time without any stuttering. > > So far I've notices it using on archive.org only, so I'm not sure if the > problem is on my side or on archive.org. The problem is rather recent > but persistent and in last days get really bad. At first, I just came in to say, "Yeah, me, too." It's with CSI (Las Vegas style) on pluto(dot)tv. Since I background that as a mood enhancer, I pretty much don't notice. When viewed, it seems to somehow aesthetically fit that series. Pinterest website has been doing weird things, too. Last few days I'm lucky if a fifth of each of their webpages loads. If I want to view the videos they're pushing, I have to copy and paste over to Google Chrome. Pinterest then pretty much runs seamlessly on that, too. Since you've tested several other web browsers, I wonder if they're all using something similar, thus similarly buggy, as a building block in their projects. Important to note is mine is straight from Mozilla's website. I can't remember what was buggy, but that's always the reason I go straight to them out of exasperation. Next it came to mind to think maybe there's a setting buried within each browser's preferences. And so I checked Firefox. There's a picture-in-picture option that I just toggled OFF. Just rebooted because something was odd with RAM (2.5GB still in use) after all program were closed. That step-by-step download buffering effect isn't showing on Firefox now, at least in my case, I suppose it could be about multiple copies somehow conflicting.. or something along those lines, anyway. Time will tell if it's about something else should the buffering effect start up again. Instead of wading through installing Opera and Vivaldi, I hit up a search engine. Both browsers can be found offering tips on how to set their own picture-in-picture offerings. Google Chrome has it, too, but it was hard to find. Mine's under chrome://flags (per the Internet) then search for picture-in-picture. It's set at default then also offers enabled and disabled. I can't tell which mine is set at, and I'm not up for experimenting. Experiments is coincidentally a word you'll see if you visit that address. One last thought is I read somewhere that ISPs, especially smaller ones, have been caught throttling users based on type of usage even though the same ISPs label their services as unlimited. Conspiracy theories tossed aside, that's still a rational possibility that needs pursued on my end here. BUT THEN... Google Chrome does work properly. That's why I haven't wasted any time nor brain storage on actively investigating local ISP throttling as a most likely answer. :) For whatever it's worth in their parts as players, I'm using: * Sid identifying itself to hardinfo as Debian 12 Bookworm * Kernel 6.1.20-1 (2023-03-19) x86_64 * AMD A10-5750M APU with Radeon(tm) HD Graphics * pavucontrol to toggle sounds on LXQt desktop * 16GB RAM that Firefox REGULARLY eats alive thus triggering ongoing restarts * Zero SWAP in use with 8GB unmounted on standby if needed * 2.56 GHz quad core that seems to never change from 2500 according to hardinfo. In the past, other laptops have fluctuated all over their respective ranges. Probably overkill in sharing, but you never know what ultimately might be a causative. Cindy :) Update: Pinterest is still not working. PlutoTV's CSI is still running much more smoothly a couple of hours after toggling picture-in-picture off, BUT I think I'm starting to see a small hint of buffering coming back. "free -m" shows RAM at 7.4GB available. It will be a couple hours before that gets eaten up. When it does, that will help show how much of an effect memory has in my instance of this. Notable: Back over at Firefox again: Under its Settings > Privacy & Security, I accidentally found the following likewise toggled ON: Firefox Data Collection and Use * Allow Firefox to send technical and interaction data to Mozilla * Allow Firefox to make personalized extension recommendations * Allow Firefox to install and run studies * Allow Firefox to send backlogged crash reports on your behalf Included for whatever it's worth since the topic of browsers' negative effect on computer memory seems to come up enough to be considered a thing... that would help make it a suspect in this buffering question. -- Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: exim failure
In-reply-to: References: <5319ac62b1294b2290d3d14a6cd8b...@easthope.ca> From: David Wright Date: Sat, 25 Mar 2023 23:34:54 -0500 In the first instance, just try sending a test message using the commands I gave, except starting off with: $ openssl s_client -crlf -connect mail.easthope.ca:465 After the certificate stuff, you should then see lines like: ... And you carry on from there with: AUTH PLAIN encodedstring The test message was transmitted. Good! (1) Section 1. in https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html has "email submission but with TLS immediately upon connect instead of using STARTTLS" is officially blessed by the IETF, and recommended by them in preference to STARTTLS. From the tests, my conclusion is that Island Hosting requires TLS-on-connect & STARTTLS won't work. Consistent with the IETF recommendation. Now all that's needed is to configure exim properly. /usr/share/doc/exim4-base/README.Debian.gz should be a good starting point for documentation but leaves several questions. (2) 2.1.1. The Debconf questions "Since you can usually read this file only after having answered the questions ..." What file? I infer as central concept of the paragraph, "Command 'dpkg-reconfigure exim4-config' takes as input /usr/share/doc/exim4-base/exim4.conf.template and responses from the user and produces as output /usr/share/doc/exim4-base/update-exim4.conf.conf." (3) "Both exim4-daemon-heavy and exim4-daemon-light support TLS/SSL using the GnuTLS library." Isn't openssl the default in Debian? What is the purpose of this sentence about GnuTLS? (4) "TLS on connect is not natively supported." OK but the test confirmed that it can work. Documentation could tell how to configure. Otherwise link to instructions at least. (5) https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html states "There is also a -tls-on-connect command line option. This overrides tls_on_connect_ports; it forces the TLS-only behaviour for all ports." Connection from the local MUA to exim isn't encrypted. The command line option will block that? What ideas are there to configure TLS-on-connect for localhost to smarthost and leave MUA to localhost unencrypted on port 25? Thanks,... P.
Re: Buster => Bullseye: packages kept back
On Sun 26 Mar 2023 at 11:16:21 (+0200), Jesper Dybdal wrote:
> Yesterday, I upgraded Buster => Bullseye.
>
> This morning, I got a mail from unattended-upgrades, which said:
>
> > Packages with upgradable origin but kept back:
> > Debian stable:
> >guile-2.2-libs w3m
>
> and
> > Package guile-2.2-libs is kept back because a related package is kept back
> > or due to local apt_preferences(5).
> > Package w3m is kept back because a related package is kept back or due to
> > local apt_preferences(5).
> What does this mean? I have what I believe to be a clean install, I
> have never used apt_preferences, and until now, I had never heard of
> guile or w3m. And I don't quite understand why I have them installed
> at all. My sources.list contains only bullseye and
> bullseye-backports.
It's a little odd that, the day after upgrading releases, you
already have backports in your sources list. Is there a specific
reason for that?
Your system seems to have some old packages on it; for example,
heirloom-mailx and ripole are both from stretch. If you need them,
check trhat you still have access to local copies of those packages
and then try removing them to see whether they're causing a logjam.
> apt list says:
> > guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
> > guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable
> > to: 2.2.7+1-6]
> >
> > w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
> > w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
If you read the Release Notes that come with each release, you'll
find instructions on "cleaning" a system before upgrading. A useful
tool to help with that is, for example:
$ aptitude why w3m
i imagemagick-6-doc Recommends www-browser
i w3m Provides www-browser
$
which would mean, on my system in similar circumstances, that I could
remove w3m without ill effects, and then reinstall it later, after
things have unjammed. Similarly:
$ aptitude why guile-2.2-libs
i emacs-gtkDependsemacs-bin-common (= 1:27.1+1-3.1+deb11u2)
i A emacs-bin-common Recommends mailutils
i A mailutilsDependslibmailutils7
i A libmailutils7Dependsguile-2.2-libs
$
Here I could remove mailutils, though in this case certain commands
could temporarily fail, eg a cron job that sends an email.
$ apt-get -s purge mailutils
[ … ]
The following packages were automatically installed and are no longer required:
gsasl-common guile-2.2-libs libgsasl7 libmailutils7 libntlm0 mailutils-common
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
mailutils*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Purg mailutils [1:3.10-3+b1]
$
One of those no longer required packages may be what's causing the
problem. They can be reinstalled after you get a clean upgrade.
If things don't turn out as simple as that, then I would have an
in-depth read of man aptitude which can test (aptitude -s)
various paths for fixing the problem. It has the patience to
figure out all the dependency/recommendation chains for any
package on the system. (My system has 56 reasons to install
guile-2.2-libs though, as we know, none is entirely based on
dependencies.)
$ aptitude -v --show-summary=all-packages why guile-2.2-libs | less
Not /every/ package on a system has to come from the same release
version, but you should know which are the exceptions, why they're
installed, and what their dependencies are. So, for example, I have
squeeze's xtoolwait, whose dependencies, libc6 (>= 2.2.5), libx11-6,
and libxext6, are straightforward to satisfy.
One configuration change I always make is:
$ cat /etc/logrotate.d/apt
/var/log/apt/term.log {
rotate -1
monthly
compress
missingok
notifempty
}
/var/log/apt/history.log {
rotate -1
monthly
compress
missingok
notifempty
}
$
which keeps a perpetual log of what gets installed on a system, when,
and hints as to why. This helps to answer the questions implied in
your opening paragraphs. (I don't install with aptitude, but that
has a similar configuration parameter.)
Cheers,
David.
Re: Buster => Bullseye: packages kept back
On 2023-03-26 17:37, Cindy Sue Causey wrote:
On 3/26/23, Jesper Dybdal wrote:
Packages with upgradable origin but kept back:
Debian stable:
guile-2.2-libs w3m
DISCLAIMER: The subject line indicates a distribution upgrade, but it
looks like your sources.list is only Bullseye. My response is based on
a stabilized single
It was a clean Buster with a few backports, and I upgraded it following
the instructions in the Bullseye release notes. Basically:
* apt update
* apt upgrade --without-new-pkgs
* apt full-upgrade
Hi.. There's a long response attached below, but first I'm wondering
if this is an appropriate instance for using:
apt-get dist-upgrade
I just searched the standing emails and didn't see it mentioned yet.
It comes to mind to ask because of the subject line here.
The rest of what I wrote.
If this had been my upgrade, my now several years long method of
attack is to try:
apt-get upgrade guile-2.2-libs
I changed to that method after seeing it mentioned on Debian-User.
Prior to that, I *used to* do "apt-get install ".
Don't do that. That messes with how apt labels packages as "manual"
and "auto" with respect to how they came to be installed.
The following might work if one is nervous about the outcome, but I
don't have a way to test it to prove as fact right now:
apt-get upgrade -s guile-2.2-libs
Doing that gives:
The following packages will be REMOVED:
libgc1c2
The following NEW packages will be installed:
libgc1
The following packages will be upgraded:
guile-2.2-libs libdatetime-timezone-perl tzdata w3m
I think I will either do that or try to remove them
If I try "apt-get -s upgrade" (i.e., without the package name) it says:
The following packages have been kept back:
guile-2.2-libs w3m
The following packages will be upgraded:
libdatetime-timezone-perl tzdata
So I'm beginning to suspect that the libgc1/libgc1gc2 packages have
something to do with it.
Thanks a lot! - also for the more general information quoted below.
Jesper
That's a simulated upgrade that theoretically shows most of what will
occur if the user decides to follow through.
Every time I've ever chosen to upgrade a package that's been held, the
situation has been one or more of the following:
1) A package's numbering sequence has been raised a significant step
2) One or more new packages will be installed as part of the newest upgrade
3) One or more old packages will be removed as part of the newest upgrade.
Step 1 usually runs in tandem with Step 3. Not always, though. Python2
and Python3 come to mind as an exception. They can both be installed
together in cases of dire necessity. I'm not totally comfortable
highlighting Python as an example, but I am seeing them called
"different versions of" instead of "different programs based on"
Python out on the Net.
The kernel is an example of where holds occur on regular occasion. The
kernel affects almost everything else. Developers keeping it on hold
helps system administrators manually address its upgrade. That gives
sysadmins the opportunity to review the kernel's changelog and verify
that their production machines will continue to work as flawlessly as
possible after each upgrade.
For my usage of Sid, I would look at:
https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.20+1_changelog
That was found by following a path starting at:
https://packages.debian.org/search?keywords=linux-image-amd64
Cindy :)
Side Note: I say "kernel affects _almost_ everything else" because
installation of the kernel is not the first step in the debootstrap
process. The kernel's installation occurs a few steps in after e.g.
the time settings, HOSTNAME, keyboard configuration, apt's
personalized repositories, limited sysadmin type package
installations, and /dev's base ("generic") devices have been
established. The steps to perform those actions operate successfully
with no kernel on board yet.
--
Jesper Dybdal
https://www.dybdal.dk
Re: What's the correct procedure for replacing a DKMS module when it's upstreamed?
On Sun, Mar 26, 2023 at 04:51:25AM +, Andy Smith wrote: > I have to build the kernel driver as an external DKMS > module from: > > https://github.com/lwfinger/rtw89 > > Specifically that is the rtw_8852be module. > > That works fine, but it seems that this driver actually is present > in upstream kernel versions somewhere in v6.1.x. After asking about this on debian-kernel it was pointed out that the driver is not actually functional until somewhere in the 6.2 upstream kernel, so is unlikely to be making it to a 6.1 LTS kernel that will be found in bookworm. It may be in the trixie kernel package and/or I may end up getting it from some future bookworm-backports kernel package, so the question still remains about the proper way to transition from a DKMS to an included module. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Buster => Bullseye: packages kept back
On 3/26/23, Jesper Dybdal wrote:
> Yesterday, I upgraded Buster => Bullseye.
>
> This morning, I got a mail from unattended-upgrades, which said:
>
>> Packages with upgradable origin but kept back:
>> Debian stable:
>>guile-2.2-libs w3m
>
> and
>> Package guile-2.2-libs is kept back because a related package is kept back
>> or due to local apt_preferences(5).
>> Package w3m is kept back because a related package is kept back or due to
>> local apt_preferences(5).
> What does this mean? I have what I believe to be a clean install, I
> have never used apt_preferences, and until now, I had never heard of
> guile or w3m. And I don't quite understand why I have them installed at
> all. My sources.list contains only bullseye and bullseye-backports.
>
> What do I do?
>
> apt list says:
>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from:
>> 2.2.4+1-2+deb10u1]
>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to:
>> 2.2.7+1-6]
>>
>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
DISCLAIMER: The subject line indicates a distribution upgrade, but it
looks like your sources.list is only Bullseye. My response is based on
a stabilized single
Hi.. There's a long response attached below, but first I'm wondering
if this is an appropriate instance for using:
apt-get dist-upgrade
I just searched the standing emails and didn't see it mentioned yet.
It comes to mind to ask because of the subject line here.
The rest of what I wrote.
If this had been my upgrade, my now several years long method of
attack is to try:
apt-get upgrade guile-2.2-libs
I changed to that method after seeing it mentioned on Debian-User.
Prior to that, I *used to* do "apt-get install ".
Don't do that. That messes with how apt labels packages as "manual"
and "auto" with respect to how they came to be installed.
The following might work if one is nervous about the outcome, but I
don't have a way to test it to prove as fact right now:
apt-get upgrade -s guile-2.2-libs
That's a simulated upgrade that theoretically shows most of what will
occur if the user decides to follow through.
Every time I've ever chosen to upgrade a package that's been held, the
situation has been one or more of the following:
1) A package's numbering sequence has been raised a significant step
2) One or more new packages will be installed as part of the newest upgrade
3) One or more old packages will be removed as part of the newest upgrade.
Step 1 usually runs in tandem with Step 3. Not always, though. Python2
and Python3 come to mind as an exception. They can both be installed
together in cases of dire necessity. I'm not totally comfortable
highlighting Python as an example, but I am seeing them called
"different versions of" instead of "different programs based on"
Python out on the Net.
The kernel is an example of where holds occur on regular occasion. The
kernel affects almost everything else. Developers keeping it on hold
helps system administrators manually address its upgrade. That gives
sysadmins the opportunity to review the kernel's changelog and verify
that their production machines will continue to work as flawlessly as
possible after each upgrade.
For my usage of Sid, I would look at:
https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.20+1_changelog
That was found by following a path starting at:
https://packages.debian.org/search?keywords=linux-image-amd64
Cindy :)
Side Note: I say "kernel affects _almost_ everything else" because
installation of the kernel is not the first step in the debootstrap
process. The kernel's installation occurs a few steps in after e.g.
the time settings, HOSTNAME, keyboard configuration, apt's
personalized repositories, limited sysadmin type package
installations, and /dev's base ("generic") devices have been
established. The steps to perform those actions operate successfully
with no kernel on board yet.
--
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *
Re: Buster => Bullseye: packages kept back
Thanks a lot for the responses. I'm still in doubt as to what to do. One thing I forgot to mention yesterday, but which I now think may be correlated with this problem, is that yesterday's upgrade mysteriously removed roundcube. I have no idea why, and I want it back, but that is not particularly urgent. I wonder if roundcube could have some dependencies that influence the other problem. I have saved the responses to some of your suggested commands; they may not be interesting, but just in case, they are available at https://www.dybdal.dk/bullseye with links in the text below. On 2023-03-26 13:17, davidson wrote: On Sun, 26 Mar 2023 Jesper Dybdal wrote: Yesterday, I upgraded Buster => Bullseye. Release notes for Debian 11 (bullseye) Upgrades from Debian 10 (buster) :: section 4.8 Obsolete Packages https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#obsolete This morning, I got a mail from unattended-upgrades, which said: Packages with upgradable origin but kept back: Debian stable: guile-2.2-libs w3m and Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5). Package w3m is kept back because a related package is kept back or due to local apt_preferences(5). What does this mean? My guess is that you have packages from Buster still installed, which are now obsolete (ie, not packaged for Bullseye). I speculate that these obsolete packages depend on guile-2.2-libs and w3m, and that this somehow (*waves hands around vaguely*) causes guile-2.2-libs and w3m to be held back. I "guess" and "speculate", and I confess I don't really know. (But in the remainder of my reply, I foolishly pretend that I do.) I have what I believe to be a clean install, I have never used apt_preferences, The message says ...because a related package is kept back OR due to local apt_preferences(5). That is, kept back (for whatever reason), OR because of apt_preferences. It need not have anything to do with apt_preferences. and until now, I had never heard of guile or w3m. $ apt-cache show guile-2.2-libs w3m And I don't quite understand why I have them installed at all. $ apt-mark showauto | grep -xE 'guile-2.2-libs|w3m' If they show up in the output of "apt-mark showauto", they were automatically installed (I'd guess in order to satisfy dependencies, recommends, etc) guile-2.2-libs do show up, w3m does not. Response in https://www.dybdal.dk/bullseye/apt-mark-show-auto.txt My sources.list contains only bullseye and bullseye-backports. Today it does. But the day before yesterday, I gather it was Buster's Last Stand. Indeed. And at that time, sources.list contained just buster and buster-backports. What do I do? Two options come to mind. FIRST OPTION: From the section of the Bullseye release notes I linked above... Some package management front-ends provide easy ways of finding installed packages that are no longer available from any known repository. The aptitude textual user interface lists them in the category “Obsolete and Locally Created Packages”, and they can be listed and purged from the commandline with: # aptitude search '~o' # aptitude purge '~o' I guess you could try that search command above, first. And then if you don't care about purging the obsolete packages it lists, then I guess you could purge them, to see if that permits you to upgrade these two packages that you never knew you had installed, and never explicitly asked for. The search command gives a list of 108 packages, which I'm somewhat reluctant to purge. Output in https://www.dybdal.dk/bullseye/aptitude-search-obsolete.txt SECOND OPTION: Since you have no explicit desire for either w3m or guile-2.2-libs, you could pretend to remove them, and see what your package manager thinks that entails. With apt-get, I would do $ apt-get -Vs remove w3m That gives a list of 129 packages that "were automatically installed and are no longer required" but as I understand it, it will remove only w3m, not those 129 packages. Output in https://www.dybdal.dk/bullseye/apt-get-Vs-remove-w3m.txt and $ apt-get -Vs guile-2.2-libs That gives first a list of 134 packages, and then: The following packages will be REMOVED: guile-2.2-libs (2.2.7+1-6) libmailutils7 (1:3.10-3+b1) mailutils (1:3.10-3+b1) I am not quite certain that I do not use or will use mailutils. Output in https://www.dybdal.dk/bullseye/apt-get-Vs-remove-guile.txt The -s makes it just for pretend, and the -V makes the packages apt threatens to remove show up in a nice column, instead jammed into one long hard-to-read row. If the removals don't look threatening to you, you know what to do. And if they do look threatening to you, then don't do it for real! apt list says: guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1] guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64
Re: Buster => Bullseye: packages kept back
On Sun, 26 Mar 2023 Jesper Dybdal wrote: Yesterday, I upgraded Buster => Bullseye. Release notes for Debian 11 (bullseye) Upgrades from Debian 10 (buster) :: section 4.8 Obsolete Packages https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#obsolete This morning, I got a mail from unattended-upgrades, which said: Packages with upgradable origin but kept back: Debian stable: guile-2.2-libs w3m and Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5). Package w3m is kept back because a related package is kept back or due to local apt_preferences(5). What does this mean? My guess is that you have packages from Buster still installed, which are now obsolete (ie, not packaged for Bullseye). I speculate that these obsolete packages depend on guile-2.2-libs and w3m, and that this somehow (*waves hands around vaguely*) causes guile-2.2-libs and w3m to be held back. I "guess" and "speculate", and I confess I don't really know. (But in the remainder of my reply, I foolishly pretend that I do.) I have what I believe to be a clean install, I have never used apt_preferences, The message says ...because a related package is kept back OR due to local apt_preferences(5). That is, kept back (for whatever reason), OR because of apt_preferences. It need not have anything to do with apt_preferences. and until now, I had never heard of guile or w3m. $ apt-cache show guile-2.2-libs w3m And I don't quite understand why I have them installed at all. $ apt-mark showauto | grep -xE 'guile-2.2-libs|w3m' If they show up in the output of "apt-mark showauto", they were automatically installed (I'd guess in order to satisfy dependencies, recommends, etc) My sources.list contains only bullseye and bullseye-backports. Today it does. But the day before yesterday, I gather it was Buster's Last Stand. What do I do? Two options come to mind. FIRST OPTION: From the section of the Bullseye release notes I linked above... Some package management front-ends provide easy ways of finding installed packages that are no longer available from any known repository. The aptitude textual user interface lists them in the category “Obsolete and Locally Created Packages”, and they can be listed and purged from the commandline with: # aptitude search '~o' # aptitude purge '~o' I guess you could try that search command above, first. And then if you don't care about purging the obsolete packages it lists, then I guess you could purge them, to see if that permits you to upgrade these two packages that you never knew you had installed, and never explicitly asked for. SECOND OPTION: Since you have no explicit desire for either w3m or guile-2.2-libs, you could pretend to remove them, and see what your package manager thinks that entails. With apt-get, I would do $ apt-get -Vs remove w3m and $ apt-get -Vs guile-2.2-libs The -s makes it just for pretend, and the -V makes the packages apt threatens to remove show up in a nice column, instead jammed into one long hard-to-read row. If the removals don't look threatening to you, you know what to do. And if they do look threatening to you, then don't do it for real! apt list says: guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1] guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to: 2.2.7+1-6] w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37] w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6] I notice that the installed versions listed above are in buster. This seems consistent with them being dependencies of buster packages that are now obsolete in bullseye. -- It is wisdom to recognize necessity, when all other courses have been weighed, though as folly it may appear to those who cling to false hope. -- Gandalf
ssh -N en alleen maar ssh -N toestaan
Hoi, Uit `man 1 ssh` -N Do not execute a remote command. This is useful for just forward ports. Nu is `ssh -N` een client kant ding. Hoe aan server kant borgen dat alleen maar port forwarding gebeurd? Ik had gedacht om het dicht te timmeren door aan authorized_keys op de server wat toe te voegen aan de regel met de pubkey voor het account dat de `ssh -N` moet gaan doen. Er is "no-port-forwarding" https://www.ssh.com/academy/ssh/authorized-keys-openssh#no-port-forwarding maar niet iets als "only-port-forwarding" https://www.ssh.com/academy/ssh/authorized-keys-openssh Wat zien jullie zoal aan mogelijkheden om aan server kant er voor te zorgen dat SSH client alleen maar een verbinding voor de portforward maakt, dat shell access niet kan? Groeten Geert Stappers -- Silence is hard to parse
Re: heu provat programari de conversió d'àudio a text?
Una nova web de transcripció que he descobert avui: https://www.microsiervos.com/archivo/ia/ai-transcriptions-voz-a-texto-gratis-castellano-catalan-gallego.html
Buster => Bullseye: doveadm now requires root privileges
Yesterday, I upgraded Buster => Bullseye. I have a cron job that cleans up all old mail from the mailbox that I use for my mobile phone by running "doveadm expunge" every night. That worked fine in Buster, but now it fails: jdmobile@nuser:~$ doveadm expunge mailbox '*' before 25d doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 23: ssl_cert: Can't open file /etc/letsencrypt/live/nuser.dybdal.dk/fullchain.pem: Permission denied Of course, doveadm cannot access the TLS key when running as a normal user. But why should it try to access that key at all when I have just asked it to clean up my own files in my own Maildir? Is there a way to make it not try to access that key and do its job anyway? Or another way to delete old mail? Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: Buster => Bullseye: packages kept back
On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal wrote: > > Yesterday, I upgraded Buster => Bullseye. > > This morning, I got a mail from unattended-upgrades, which said: > > > Packages with upgradable origin but kept back: > > Debian stable: > >guile-2.2-libs w3m > > and > > Package guile-2.2-libs is kept back because a related package is kept back > > or due to local apt_preferences(5). > > Package w3m is kept back because a related package is kept back or due to > > local apt_preferences(5). > What does this mean? I have what I believe to be a clean install, I > have never used apt_preferences, and until now, I had never heard of > guile or w3m. And I don't quite understand why I have them installed at > all. My sources.list contains only bullseye and bullseye-backports. > > What do I do? > > apt list says: > > guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1] > > guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to: > > 2.2.7+1-6] > > > > w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37] > > w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6] I would install aptitude, and then run `aptitude safe-upgrade`. Aptitude's solver can usually determine the upgrade path that avoids breaking the machine. Jeff
Buster => Bullseye: packages kept back
Yesterday, I upgraded Buster => Bullseye. This morning, I got a mail from unattended-upgrades, which said: Packages with upgradable origin but kept back: Debian stable: guile-2.2-libs w3m and Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5). Package w3m is kept back because a related package is kept back or due to local apt_preferences(5). What does this mean? I have what I believe to be a clean install, I have never used apt_preferences, and until now, I had never heard of guile or w3m. And I don't quite understand why I have them installed at all. My sources.list contains only bullseye and bullseye-backports. What do I do? apt list says: guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1] guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to: 2.2.7+1-6] w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37] w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6] Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: ssh-add after graphical login
Le 3/23/23 à 17:53, Erwan David a écrit : I create a shell script ~/bin/start-session.sh in this script I have the command ssh-add < - in System Settings > Startup and Shutdown > autostart I add this script as a login script Thanks Erwan, that's what I ended up doing. the ssh-add < - line looks dubious to me. It seems like you're redirecting standard input to standard input, that is to say it doesn't do much. Best, -- yassine -- sysadm +213-779 06 06 23 http://about.me/ychaouche Looking for side gigs.
