Buster to Bullseye upgrade problem

[Gareth Evans]

Hello,

I upgraded from Buster stable to Bullseye stable last night, with apparent 
success eventually, but it went less than smoothly and I would be grateful for 
any advice as to why that may have been.

I followed the preparation advice at

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html

and it seemed to me that there were no non-Debian packages in apt-forktracer 
output, although I'm afraid I didn't save the list.

The upgrade process stopped abruptly a couple of times, once without any 
indication as to why.

$ cat /etc/apt/sources.list
deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
#deb http://deb.debian.org/debian bullseye-proposed-updates main contrib 
non-free
deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
non-free
deb http://deb.debian.org/debian/ bullseye-backports main contrib non-free


>From script output:

# apt full-upgrade
[...]
Errors were encountered while processing:
 /tmp/apt-dpkg-install-2vllSE/09-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb

E: Sub-process /usr/bin/dpkg returned an error code (1)

# apt install --fix-broken
[...]
Setting up zfs-initramfs (2.0.3-9) ...
Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64

# apt full-upgrade
[...]
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...

W: APT had planned for dpkg to do more than it reported back (8974 vs 9007).
   Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 
texlive-latex-base:amd64 texlive-latex-extra:amd64 
texlive-latex-recommended:amd64 texlive-pictures:amd64 
texlive-plain-generic:amd64 texlive-science:amd64

# apt full-upgrade
[...]

Apparent success...

$ apt policy *gir*bad*
gir1.2-gst-plugins-bad-1.0:
  Installed: 1.18.4-3
  Candidate: 1.18.4-3
  Version table:
 *** 1.18.4-3 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status

$ cat /etc/debian_version
11.0

$ uname -a
Linux  5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 
GNU/Linux

Reboots without issue. 

Is there any way to verify an upgrade completed properly?  Would there be 
obvious errors on exit if it didn't?

Thanks,
Gareth

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Wed 18 Aug 2021, at 00:44, Gareth Evans  wrote:
> Hello,
> 
> I upgraded from Buster stable to Bullseye stable last night, with 
> apparent success eventually, but it went less than smoothly and I would 
> be grateful for any advice as to why that may have been.
> 
> I followed the preparation advice at
> 
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html
> 
> and it seemed to me that there were no non-Debian packages in 
> apt-forktracer output, although I'm afraid I didn't save the list.
> 
> The upgrade process stopped abruptly a couple of times, once without 
> any indication as to why.
> 
> $ cat /etc/apt/sources.list
> deb http://deb.debian.org/debian/ bullseye main contrib non-free
> deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
> #deb http://deb.debian.org/debian bullseye-proposed-updates main 
> contrib non-free
> deb http://deb.debian.org/debian-security/ bullseye-security main 
> contrib non-free
> deb http://deb.debian.org/debian/ bullseye-backports main contrib 
> non-free
> 
> 
> >From script output:
> 
> # apt full-upgrade
> [...]
> Errors were encountered while processing:
>  /tmp/apt-dpkg-install-2vllSE/09-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> 
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> # apt install --fix-broken
> [...]
> Setting up zfs-initramfs (2.0.3-9) ...
> Processing triggers for initramfs-tools (0.133+deb10u1) ...
> update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64
> 
> # apt full-upgrade
> [...]
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> 
> W: APT had planned for dpkg to do more than it reported back (8974 vs 
> 9007).
>Affected packages: texlive-fonts-recommended:amd64 
> texlive-lang-greek:amd64 texlive-latex-base:amd64 
> texlive-latex-extra:amd64 texlive-latex-recommended:amd64 
> texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> 
> # apt full-upgrade
> [...]
> 
> Apparent success...
> 
> $ apt policy *gir*bad*
> gir1.2-gst-plugins-bad-1.0:
>   Installed: 1.18.4-3
>   Candidate: 1.18.4-3
>   Version table:
>  *** 1.18.4-3 500
> 500 http://deb.debian.org/debian bullseye/main amd64 Packages
> 100 /var/lib/dpkg/status
> 
> $ cat /etc/debian_version
> 11.0
> 
> $ uname -a
> Linux  5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) 
> x86_64 GNU/Linux
> 
> Reboots without issue. 
> 
> Is there any way to verify an upgrade completed properly?  Would there 
> be obvious errors on exit if it didn't?
> 
> Thanks,
> Gareth
> 
> 

I have been digging/experimenting a bit more and have reverted to Buster 
several times by rolling back zfs snapshots to retry upgrading with different 
approaches:


(1) Minimal system upgrade, then full-upgrade, per

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade

Minimal upgrade completed without issue, but the same problems with the same 
solutions as in my first email appeared in the full-upgrade part of the process.


(2) Single-line sources.list:

deb http://deb.debian.org/debian/ bullseye main contrib non-free

Same approach as in (1), same problems and solutions.


(3) Minimal upgrade followed by "apt upgrade" (not full-upgrade) - this is 
apparently not to be recommended! (I know this is what full/dist-upgrade is 
for, but I thought I'd see what happened.)  Fwiw...

There were no breakages in the upgrade process in this approach, but then the 
system dropped to initramfs on reboot due to lack of zfs modules (much building 
having been conspicuous by its absence).  Booting into a previous kernel at 
this stage got to graphical login, all Bullseye themed so far, but no desktop 
appeared after successful login, and *Buster* shutdown screen appeared after 
holding power off.  


So whatever way I approach it, the upgrade doesn't run smoothly at all, though 
it seems to succeed eventually using a combination of 

[optionally...] apt upgrade --without-new-pkgs
apt full-upgrade
apt install --fix-broken
apt full-upgrade x2


As for causes...

syslog is silent on the issues

/var/log/apt/term.log shows:

--
Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
[1mdpkg:[0m error processing archive 
/tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which 
is also in package pitivi 0.999-1+b1
[1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal (Broken 
pipe)
--

However it gives no clue as to why the upgrade stops again later, with things 
for apt still to do, after the second (of three) 

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Wed 18 Aug 2021, at 23:33, piorunz  wrote:
> On 18/08/2021 16:14, Gareth Evans wrote:
> > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > [1mdpkg:[0m error processing archive 
> > /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> >  (--unpack):
> >   trying to overwrite 
> > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > which is also in package pitivi 0.999-1+b1
> > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal 
> > (Broken pipe)
>
 
> IMO that's the source of your problem.
> You have two packages fighting to overwrite the same file. You should
> inspect them.
> Are you sure they come from buster, not from foreign repository?

Apparently they are both from Buster.  Removing pitivi before upgrading 
improves things, but not completely plain sailing.

On Buster:

# aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
#

# apt-forktracer | sort 
libck0 (0.6.0-1.2~bpo10+1) [Debian Backports: 0.6.0-1.2~bpo10+1]
libnvpair3linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
libuutil3linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
libzfs4linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
libzpool4linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
sane-airscan (0.99.19-1~bpo10+1) [Debian Backports: 0.99.19-1~bpo10+1]
sysbench (1.0.18+ds-1~bpo10+1) [Debian Backports: 1.0.18+ds-1~bpo10+1]
zfs-dkms (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1 2.0.3-9~bpo10+1] 
[Debian: 0.7.12-2+deb10u2 0.7.12-2+deb10u2]
zfs-initramfs (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1 
2.0.3-9~bpo10+1] [Debian: 0.7.12-2+deb10u2 0.7.12-2+deb10u2]
zfsutils-linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1] [Debian: 
0.7.12-2+deb10u2]
zfs-zed (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1] [Debian: 
0.7.12-2+deb10u2]

# aptitude search '~o'
#

# apt policy pitivi
pitivi:
  Installed: 0.999-1+b1
  Candidate: 0.999-1+b1
  Version table:
 *** 0.999-1+b1 500
500 http://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status

# apt-show-versions | grep newer
#

# aptitude search '~i(!~ODebian)'
#

# apt remove --purge pitivi

# apt upgrade --without-new-pkgs
(completes)

# apt full-upgrade
[...]
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...

W: APT had planned for dpkg to do more than it reported back (7510 vs 7543).
   Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 
texlive-latex-base:amd64 texlive-latex-extra:amd64 
texlive-latex-recommended:amd64 texlive-pictures:amd64 
texlive-plain-generic:amd64 texlive-science:amd64

# apt full-upgrade
(completes)

Oh well.  Thanks.
G


> 
> You have commands to check for this:
> 
> check if any packages are newer than repository (possibly foreign)
> apt-show-versions | grep newer
> 
> check if any packages are foreign (not from Debian)
> aptitude search '~i(!~ODebian)'
> 
> 
> --
> 
> With kindest regards, piorunz.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄
> 
> 

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Thu 19 Aug 2021, at 05:50, David Wright  wrote:
> On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > On Wed 18 Aug 2021, at 23:33, piorunz  wrote:
> > > On 18/08/2021 16:14, Gareth Evans wrote:
> > > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > > [1mdpkg:[0m error processing archive 
> > > > /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> > > >  (--unpack):
> > > >   trying to overwrite 
> > > > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > > > which is also in package pitivi 0.999-1+b1
> > > > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal 
> > > > (Broken pipe)
> > >
> >  
> > > IMO that's the source of your problem.
> > > You have two packages fighting to overwrite the same file. You should
> > > inspect them.
> > > Are you sure they come from buster, not from foreign repository?
> > 

Hi David,

> > Apparently they are both from Buster.
> 
> I'm afraid not. You need to check the version numbers more carefully.

I meant the packages (gir1.2-gst-plugins-bad-1.0, pitivi) being upgraded, 
rather than the versions replacing them, were both from Buster at the point of 
the upgrade (weren't they?)

On Bullseye now:

$ apt policy *gir*bad*
gir1.2-gst-plugins-bad-1.0:
  Installed: 1.18.4-3
  Candidate: 1.18.4-3
  Version table:
 *** 1.18.4-3 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status

$ aptitude why gir1.2-gst-plugins-bad-1.0
i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)

(having installed pitivi again after removing it before upgrading to see what 
difference it made)

I don't understand what the problem is/was - shouldn't apt just have handled 
this?

Have I misunderstood what you have shown/what you are saying?

Thanks,
Gareth

> 
> $ apt policy gir1.2-gst-plugins-bad-1.0
> gir1.2-gst-plugins-bad-1.0:
>   Installed: (none)
>   Candidate: 1.14.4-1+deb10u2
>   Version table:
>  1.14.4-1+deb10u2 990
> 990 http://deb.debian.org/debian buster/main amd64 Packages
> 990 http://security.debian.org/debian-security 
> buster/updates/main amd64 Packages
> $ apt-file list gir1.2-gst-plugins-bad-1.0 
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstInsertBin-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstMpegts-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstPlayer-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstWebRTC-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/AUTHORS
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/NEWS.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/README.Debian
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/README.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.Debian.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/copyright
> $ 
> 
> File list of package gir1.2-gst-plugins-bad-1.0 in bullseye of 
> architecture amd64
> 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstBadAudio-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstCodecs-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstInsertBin-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstMpegts-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstPlayer-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib ← 
> new in bullseye
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstWebRTC-1.0.typelib
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.Debian.gz
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.gz
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/copyright
> 
> Cheers,
> David.
> 
> 

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Fri 20 Aug 2021, at 12:32, Greg Wooledge  wrote:
> On Thu, Aug 19, 2021 at 10:45:57PM -0500, David Wright wrote:
> > One might assume so, but only you can check that. There are two logs
> > of the upgrade. /var/log/apt/history.log (and its predecessors) shows
> > the command issued, followed by the packages affected, with the old
> > and new version numbers in parentheses. /var/log/apt/term.log (and its
> > predecessors) shows the various packages being unpacked and then set
> > up.
> 
> Huh.  I didn't know about the terminal session logs.  Nifty.
> 

> 'Twould be nice if it showed the command which was typed before each
> logged session, but still... nifty.

You may be aware of "script" which I have found useful for that. You have to 
overlook gibberishy characters though, as backspace and other special chars are 
included in the output file.

https://linux.die.net/man/1/script

You can set it up to run with new terminals, but I can't find the instructions 
to do so.

Kind regards
Gareth

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Fri 20 Aug 2021, at 04:45, David Wright  wrote:
> On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> > On Thu 19 Aug 2021, at 05:50, David Wright  wrote:
> > > On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > > > On Wed 18 Aug 2021, at 23:33, piorunz  wrote:
> > > > > On 18/08/2021 16:14, Gareth Evans wrote:
> > > > > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > > > > [1mdpkg:[0m error processing archive 
> > > > > > /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> > > > > >  (--unpack):
> > > > > >   trying to overwrite 
> > > > > > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib',
> > > > > >  which is also in package pitivi 0.999-1+b1
> > > > > > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by 
> > > > > > signal (Broken pipe)
> > > > >
> > > > > IMO that's the source of your problem.
> > > > > You have two packages fighting to overwrite the same file. You should
> > > > > inspect them.
> > > > > Are you sure they come from buster, not from foreign repository?
> > > > 
> > > > Apparently they are both from Buster.
> > > 
> > > I'm afraid not. You need to check the version numbers more carefully.
> > 

Hello again,

Thanks David, for your clear explanation of the problem.

> > I meant the packages (gir1.2-gst-plugins-bad-1.0, pitivi) being upgraded, 
> > rather than the versions replacing them, were both from Buster at the point 
> > of the upgrade (weren't they?)
> 
> One might assume so, but only you can check that ...

I was mistaken in thinking that gir1.2-gst-plugins-bad-1.0 was installed in 
Buster in the first place.

[Buster]
$ apt policy gir*bad*
gir1.2-gst-plugins-bad-1.0:
  Installed: (none)
  Candidate: 1.14.4-1+deb10u2
  Version table:
 1.14.4-1+deb10u2 500
500 http://deb.debian.org/debian buster/main amd64 Packages
500 http://security.debian.org/debian-security buster/updates/main 
amd64 Packages

$ aptitude why gir1.2-gst-plugins-bad-1.0
Not currently installed
The candidate version 1.14.4-1+deb10u2 has priority optional
No dependencies require to install gir1.2-gst-plugins-bad-1.0

$ apt policy pitivi
pitivi:
  Installed: 0.999-1+b1
  Candidate: 0.999-1+b1
  Version table:
 *** 0.999-1+b1 500
500 http://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status

So pitivi 0.999 as installed is a Buster package, and gir* is installed during 
the upgrade as a dependency of Bullseye's newer pitivi version.

[Bullseye] 
$ aptitude why gir1.2-gst-plugins-bad-1.0
i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)


The first upgrade interruption issue (repeated here for clarity):

--
Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb 
(--unpack):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which 
is also in package pitivi 0.999-1+b1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
--

appears to be a file conflict, per 

https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts

which includes that "File conflicts should not occur if you upgrade from a 
“pure” buster system..."

So I would like to know if apt is not handling this properly, or if the 
scenario of a file changing packages (see David's previous email) is an 
expected exception to the (sort of) rule.

Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?  It's not 
a conflict involving two Bullseye packages, nor with one from Bullseye and one 
held/pinned etc, so I don't see why it should happen.

FWIW I followed s4.2 of the release notes ("start from pure Debian") 
meticulously
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#system-status

as well as running the commands kindly suggested by piorunz:

> On Wed 18 Aug 2021, at 23:33, piorunz  wrote:
> [...]
> check if any packages are newer than repository (possibly foreign)
> apt-show-versions | grep newer
> 
> check if any packages are foreign (not from Debian)
> aptitude search '~i(!~ODebian)'

There is also no explanation in term.log, syslog or dpkg.log for the second 
interruption:

--
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
[upgrade interrupted...]
W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
   Affected packa

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Sat 21 Aug 2021, at 13:42, Sven Hartge  wrote:
> Gareth Evans  wrote:
> 
> > So I would like to know if apt is not handling this properly, or if
> > the scenario of a file changing packages (see David's previous email)
> > is an expected exception to the (sort of) rule.
> 

Hi Sven,

> > Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?
> 
> No, because Debian Policy says that partial upgrades are supported and
> must work.

Interesting, thanks.  I will have a look at [1,2,3] which seem relevant - any 
good refs would be appreciated, even for other distros if the 
concepts/techniques are similar.

Many thanks,
Gareth

[1] https://www.debian.org/doc/debian-policy/policy.pdf

[2] https://wiki.debian.org/Packaging/Intro

[3] https://www.debian.org/doc/manuals/developers-reference/index.en.html

> 
> > It's not a conflict involving two Bullseye packages, nor with one from
> > Bullseye and one held/pinned etc, so I don't see why it should happen.
> 
> This might be a genuine bug in one of the two packages here, where a
> Conflict/Breaks/Replaces dependendy was needed to move a file from one
> package to another.
> 
> I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007 is part
> of that problem.
> 
> Grüße,
> S°
> 
> -- 
> Sigmentation fault. Core dumped.
> 
> 

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Sun 22 Aug 2021, at 05:36, David Wright  wrote:
> On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > On Fri 20 Aug 2021, at 04:45, David Wright  wrote:
> > > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> 
> > $ apt policy pitivi
> > pitivi:
> >   Installed: 0.999-1+b1
> >   Candidate: 0.999-1+b1
> >   Version table:
> >  *** 0.999-1+b1 500
> > 500 http://deb.debian.org/debian buster/main amd64 Packages
> > 100 /var/lib/dpkg/status
> > 
> > So pitivi 0.999 as installed is a Buster package, and gir* is installed 
> > during the upgrade as a dependency of Bullseye's newer pitivi version.
> > 
> > [Bullseye] 
> > $ aptitude why gir1.2-gst-plugins-bad-1.0
> > i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> > 
> > 
> > The first upgrade interruption issue (repeated here for clarity):
> > 
> > --
> > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > dpkg: error processing archive 
> > /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> >  (--unpack):
> >  trying to overwrite 
> > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > which is also in package pitivi 0.999-1+b1
> > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > --
> > 
> > appears to be a file conflict, per 
> > 
> > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts
> > 
> > which includes that "File conflicts should not occur if you upgrade from a 
> > “pure” buster system..."
> > 
> > So I would like to know if apt is not handling this properly, or if the 
> > scenario of a file changing packages (see David's previous email) is an 
> > expected exception to the (sort of) rule.
> 

Hi David,

> As Sven posted, it looks as if #965007 is the cause. A snag is
> that, because the bug has been closed, it no longer shows up on
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007
> Moral: for major upgrades, always set "Archived and Unarchived"
> on https://www.debian.org/Bugs/ because these sorts of bug are
> likely to have been fixed by the time unstable→stable arrives.
> 
> But the workaround is to recall reading (!) § 4.5.4 in the Release
> Notes, and force things as shown there.

I did see that but had already managed to make progress with apt install 
--fix-broken before twigging a file conflict (which is obvious once realised!)

> 
> > There is also no explanation in term.log, syslog or dpkg.log for the second 
> > interruption:
> > 
> > --
> > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > [upgrade interrupted...]
> > W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
> >Affected packages: texlive-fonts-recommended:amd64 
> > texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 
> > texlive-latex-recommended:amd64 texlive-pictures:amd64 
> > texlive-plain-generic:amd64 texlive-science:amd64
> > ---
> > 
> > which occurs even if pitivi is removed before upgrading, and the warning 
> > doesn't appear in term.log either.
> > 
> > If anyone can shed further light, I would be interested, but it's not 
> > ultimately a roadblock to upgrading so possibly not worth worrying about.
> 
> I'm no help here, as I've never seen output like that,
> neither the "[ … ]", nor the "W: APT had planned …".
> Is that output, with [upgrade interrupted...], a verbatim
> copy/paste? Did this message appear spontaneously, or
> because you yourself interrupted the process?

"[...]" was just my way of showing output until this point has not been 
included in the paste, or that the paste includes gaps in output.  I use this 
by habit from academic writing but perhaps  might be better for this 
purpose?  

The interrupt and following "W: APT had planned..." appeared spontaneously.  
The upgrade stops, and [...] here stands in for etckeeper output, which I 
removed as noisy.

> 
> ISTR that history.log records intent, not achievement, whereas
> term.log can obviously /only/ log achievement, so a comparison
> of their two lists of packages for the interrupted step might give
> a clue, perhaps a more fruitful one than just the list of Affected
> packages quoted above.

I have just noticed that the logged action after which it trips up:

Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...

is related to what may be another problem of sorts.  php7.3 packag

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Sun 22 Aug 2021, at 13:18, Gareth Evans  wrote:
> On Sun 22 Aug 2021, at 05:36, David Wright  wrote:
> > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > > On Fri 20 Aug 2021, at 04:45, David Wright  
> > > wrote:
> > > > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> > 
> > > $ apt policy pitivi
> > > pitivi:
> > >   Installed: 0.999-1+b1
> > >   Candidate: 0.999-1+b1
> > >   Version table:
> > >  *** 0.999-1+b1 500
> > > 500 http://deb.debian.org/debian buster/main amd64 Packages
> > > 100 /var/lib/dpkg/status
> > > 
> > > So pitivi 0.999 as installed is a Buster package, and gir* is installed 
> > > during the upgrade as a dependency of Bullseye's newer pitivi version.
> > > 
> > > [Bullseye] 
> > > $ aptitude why gir1.2-gst-plugins-bad-1.0
> > > i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> > > 
> > > 
> > > The first upgrade interruption issue (repeated here for clarity):
> > > 
> > > --
> > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > dpkg: error processing archive 
> > > /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> > >  (--unpack):
> > >  trying to overwrite 
> > > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > > which is also in package pitivi 0.999-1+b1
> > > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > > --
> > > 
> > > appears to be a file conflict, per 
> > > 
> > > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts
> > > 
> > > which includes that "File conflicts should not occur if you upgrade from 
> > > a “pure” buster system..."
> > > 
> > > So I would like to know if apt is not handling this properly, or if the 
> > > scenario of a file changing packages (see David's previous email) is an 
> > > expected exception to the (sort of) rule.
> > 
> 
> Hi David,
> 
> > As Sven posted, it looks as if #965007 is the cause. A snag is
> > that, because the bug has been closed, it no longer shows up on
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007
> > Moral: for major upgrades, always set "Archived and Unarchived"
> > on https://www.debian.org/Bugs/ because these sorts of bug are
> > likely to have been fixed by the time unstable→stable arrives.
> > 
> > But the workaround is to recall reading (!) § 4.5.4 in the Release
> > Notes, and force things as shown there.
> 
> I did see that but had already managed to make progress with apt 
> install --fix-broken before twigging a file conflict (which is obvious 
> once realised!)
> 
> > 
> > > There is also no explanation in term.log, syslog or dpkg.log for the 
> > > second interruption:
> > > 
> > > --
> > > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > > [upgrade interrupted...]
> > > W: APT had planned for dpkg to do more than it reported back (5014 vs 
> > > 5047).
> > >Affected packages: texlive-fonts-recommended:amd64 
> > > texlive-lang-greek:amd64 texlive-latex-base:amd64 
> > > texlive-latex-extra:amd64 texlive-latex-recommended:amd64 
> > > texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > > ---
> > > 
> > > which occurs even if pitivi is removed before upgrading, and the warning 
> > > doesn't appear in term.log either.
> > > 
> > > If anyone can shed further light, I would be interested, but it's not 
> > > ultimately a roadblock to upgrading so possibly not worth worrying about.
> > 
> > I'm no help here, as I've never seen output like that,
> > neither the "[ … ]", nor the "W: APT had planned …".
> > Is that output, with [upgrade interrupted...], a verbatim
> > copy/paste? Did this message appear spontaneously, or
> > because you yourself interrupted the process?
> 
> "[...]" was just my way of showing output until this point has not been 
> included in the paste, or that the paste includes gaps in output.  I 
> use this by habit from academic writing but perhaps  might be 
> better for this purpose?  
> 
> The interrupt and following "W: APT had planned..." appeared 
> spontaneously.  The upgrade stops, and [...] here stands in for 
>

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Sun 22 Aug 2021, at 15:37, David Wright  wrote:
> On Sun 22 Aug 2021 at 13:18:38 (+0100), Gareth Evans wrote:
> > On Sun 22 Aug 2021, at 05:36, David Wright  wrote:
> > > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> 
> > > > There is also no explanation in term.log, syslog or dpkg.log for the 
> > > > second interruption:
> > > > 
> > > > --
> > > > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > > > [upgrade interrupted...]
> > > > W: APT had planned for dpkg to do more than it reported back (5014 vs 
> > > > 5047).
> > > >Affected packages: texlive-fonts-recommended:amd64 
> > > > texlive-lang-greek:amd64 texlive-latex-base:amd64 
> > > > texlive-latex-extra:amd64 texlive-latex-recommended:amd64 
> > > > texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > > > ---
> 
> [ … ]
> 
> > > I'm no help here, as I've never seen output like that,
> > > neither the "[ … ]", nor the "W: APT had planned …".
> > > Is that output, with [upgrade interrupted...], a verbatim
> > > copy/paste? Did this message appear spontaneously, or
> > > because you yourself interrupted the process?
> > 
> > "[...]" was just my way of showing output until this point has not been 
> > included in the paste, or that the paste includes gaps in output.  I use 
> > this by habit from academic writing but perhaps  might be better for 
> > this purpose?  
> > 
> > The interrupt and following "W: APT had planned..." appeared spontaneously. 
> >  The upgrade stops, and [...] here stands in for etckeeper output, which I 
> > removed as noisy.
> 
> Both the < … > and [ … ] are fine; it's just that 

> [...] "upgrade
> interrupted", in a passive construction, avoids specifying the agent,
> which is what we need to know: was it you or APT whodunit.

It wasn't me, but an apparent breakage.

> 
> [ … ]
> 
> > I have just noticed that the logged action after which it trips up:
> > 
> > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > 
> > is related to what may be another problem of sorts.  php7.3 packages are 
> > removed as part of the upgrade but the config (mods-[enabled]) isn't 
> > changed.  Apache2 won't start after upgrading until I
> > 
> > a2dismod *php*7.3*
> > 
> > >From /var/log/syslog: 
> > Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP Server...
> > Aug 22 00:29:58 qwerty apachectl[59333]: apache2: Syntax error on line 146 
> > of /etc/apache2/apache2.conf: Syntax error on line 3 of 
> > /etc/apache2/mods-enabled/php7.3.load: Cannot load 
> > /usr/lib/apache2/modules/libphp7.3.so into server: 
> > /usr/lib/apache2/modules/libphp7.3.so: cannot open shared object file: No 
> > such file or directory
> > Aug 22 00:29:58 qwerty apachectl[59330]: Action 'start' failed.
> > 
> > Is it normal to have to do this sort of thing after a major upgrade?  If 
> > not, could a hiccup here be related to the upgrade breaking?
> 
> Well, the apache version is upgraded from 2.4.38 to 2.4.46 during the
> transition from buster to bullseye, and although APT will look after
> upgrading its conffiles, "conffiles" are those configuring the apache
> software, not the mods-available/enabled that configure the service.
> 
> People who run apache servers may have their own opinions on the
> correct procedure. My own would be that you should be sure a
> configuration is correct before you run that service, and testing
> it is not best done during a major upgrade, but when the dust has
> settled.

What do you mean by "when the dust has settled" in this context?  

Thanks,
Gareth

> 
> Cheers,
> David.
> 
> 

Re: Colemak layout at boot time

[Gareth Evans]

On Sun 19 Sep 2021, at 05:49, David Wright  wrote:
> On Sat 18 Sep 2021 at 21:56:34 (+0100), piorunz wrote:
> > On 18/09/2021 20:00, David Wright wrote:
> > 
> > > A lot of hits from googling   grub colemak   including
> > > https://forums.debian.net//viewtopic.php?f=16&t=76833
> > > which uses dvorak as an example.
> > 
> > Thanks for your reply.
> > Yes I seen this page.
> > 
> > ckbcomp dvorak command outputs the layout details and everything.
> > 
> > However:
> > $ ckbcomp colemak
> > /usr/bin/ckbcomp: Can not find file "symbols/colemak" in any known directory
> > 
> > > 
> > > I don't recall the definition of "boot time password". Does this
> > > denote something that Grub asks, or is it when dmcrypt is running
> > > from the initrd?
> > 
> > By that I meant GRUB editor and Debian's standard whole disk encryption
> > in Debian. I don't have Colemak there. I need to enter password in
> > Colemak. Yes, I think that's called dmcrypt.
> > 
> > > Which is a reminder: is your keyboard definition
> > > in /etc/default/keyboard getting incorporated into the initrd or not?
> > 
> > I don't know that. I only have Colemak in KDE. Everything else,
> > including virtual terminals (Ctrl+Alt+F keys) are Qwerty.
> 
> How do you normally login, at a VC or in a Display Manager?
> 
> Where did you run "sudo dpkg-reconfigure keyboard-configuration" from?
> 

> Have you seen this line:
>   update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64
> since you changed /etc/default/keyboard and ran
>   sudo dpkg-reconfigure keyboard-configuration?

I replied just now before seeing this.  I think I may have taken the "GRUB uses 
the US keyboard layout by default" in my link a bit too far!  

> 
> Checking your current initrd is a little tedious: you run
> unmkinitramfs to unpack the initrd, and you zcat your
> /etc/console-setup/cached_UTF-8_del.kmap.gz to, say, /tmp.
> Then run, eg:
> 
> $ diff -u …/main/etc/console-setup/cached_UTF-8_del.kmap 
> /tmp/cached_UTF-8_del.kmap
> $ 
> 
> where they are the unpacked and decompressed files respectively.
> 
> Cheers,
> David.
> 
> 

Re: Colemak layout at boot time

[Gareth Evans]

On Sun 19 Sep 2021, at 06:14, Gareth Evans  wrote:
> On Sun 19 Sep 2021, at 05:49, David Wright  wrote:
> > On Sat 18 Sep 2021 at 21:56:34 (+0100), piorunz wrote:
> > > On 18/09/2021 20:00, David Wright wrote:
> > > 
> > > > A lot of hits from googling   grub colemak   including
> > > > https://forums.debian.net//viewtopic.php?f=16&t=76833
> > > > which uses dvorak as an example.
> > > 
> > > Thanks for your reply.
> > > Yes I seen this page.
> > > 
> > > ckbcomp dvorak command outputs the layout details and everything.
> > > 
> > > However:
> > > $ ckbcomp colemak
> > > /usr/bin/ckbcomp: Can not find file "symbols/colemak" in any known 
> > > directory
> > > 
> > > > 
> > > > I don't recall the definition of "boot time password". Does this
> > > > denote something that Grub asks, or is it when dmcrypt is running
> > > > from the initrd?
> > > 
> > > By that I meant GRUB editor and Debian's standard whole disk encryption
> > > in Debian. I don't have Colemak there. I need to enter password in
> > > Colemak. Yes, I think that's called dmcrypt.
> > > 
> > > > Which is a reminder: is your keyboard definition
> > > > in /etc/default/keyboard getting incorporated into the initrd or not?
> > > 
> > > I don't know that. I only have Colemak in KDE. Everything else,
> > > including virtual terminals (Ctrl+Alt+F keys) are Qwerty.
> > 
> > How do you normally login, at a VC or in a Display Manager?
> > 
> > Where did you run "sudo dpkg-reconfigure keyboard-configuration" from?
> > 
> 
> > Have you seen this line:
> >   update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64
> > since you changed /etc/default/keyboard and ran
> >   sudo dpkg-reconfigure keyboard-configuration?
> 
> I replied just now before seeing this.  I think I may have taken the 
> "GRUB uses the US keyboard layout by default" in my link a bit too far! 
>  
> 
> > 
> > Checking your current initrd is a little tedious: you run
> > unmkinitramfs to unpack the initrd, and you zcat your
> > /etc/console-setup/cached_UTF-8_del.kmap.gz to, say, /tmp.
> > Then run, eg:
> > 
> > $ diff -u …/main/etc/console-setup/cached_UTF-8_del.kmap 
> > /tmp/cached_UTF-8_del.kmap
> > $ 
> > 
> > where they are the unpacked and decompressed files respectively.
> > 
> > Cheers,
> > David.
> > 
> > 
> 
> 

I have set up a VM with up-to-date Bullseye KDE (LUKS/LVM guided partitioning) 
to try to replicate this problem.

Adding the UK Colemak keyboard layout and promoting it to the top of the list 
in system settings > keyboard does not make it take effect in either the LUKS 
boot-time password or the graphical login - only after login to KDE.

Switching to UK layout for usage and then running in konsole

# dpkg-reconfigure keyboard-configuration

[choosing UK then Colemak then default for AltGr/special keys etc]

does not change the active keyboard layout, nor for the LUKS boot password or 
graphical login.

Out of interest, I thought I would try the  instructions (section 5):

https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

- but they fail at the third command:

# tar -C "$memdisk" -cf /boot/grub/memdisk.tar
tar: Cowardly refusing to create an empty archive
Try 'tar --help' or 'tar --usage' for more information

I lack much experience with ramdisks and all but the simplest of grub 
configuration, but I can't see either an obvious problem with the syntax 
suggested, or anything in 'tar --help' that helps.

Any suggestions?

Thanks
Gareth

Re: Colemak layout at boot time

[Gareth Evans]

On Sun 19 Sep 2021, at 11:48, Gareth Evans  wrote:
> On Sun 19 Sep 2021, at 06:14, Gareth Evans  wrote:
> > On Sun 19 Sep 2021, at 05:49, David Wright  wrote:
> > > On Sat 18 Sep 2021 at 21:56:34 (+0100), piorunz wrote:
> > > > On 18/09/2021 20:00, David Wright wrote:
> > > > 
> > > > > A lot of hits from googling   grub colemak   including
> > > > > https://forums.debian.net//viewtopic.php?f=16&t=76833
> > > > > which uses dvorak as an example.
> > > > 
> > > > Thanks for your reply.
> > > > Yes I seen this page.
> > > > 
> > > > ckbcomp dvorak command outputs the layout details and everything.
> > > > 
> > > > However:
> > > > $ ckbcomp colemak
> > > > /usr/bin/ckbcomp: Can not find file "symbols/colemak" in any known 
> > > > directory
> > > > 
> > > > > 
> > > > > I don't recall the definition of "boot time password". Does this
> > > > > denote something that Grub asks, or is it when dmcrypt is running
> > > > > from the initrd?
> > > > 
> > > > By that I meant GRUB editor and Debian's standard whole disk encryption
> > > > in Debian. I don't have Colemak there. I need to enter password in
> > > > Colemak. Yes, I think that's called dmcrypt.
> > > > 
> > > > > Which is a reminder: is your keyboard definition
> > > > > in /etc/default/keyboard getting incorporated into the initrd or not?
> > > > 
> > > > I don't know that. I only have Colemak in KDE. Everything else,
> > > > including virtual terminals (Ctrl+Alt+F keys) are Qwerty.
> > > 
> > > How do you normally login, at a VC or in a Display Manager?
> > > 
> > > Where did you run "sudo dpkg-reconfigure keyboard-configuration" from?
> > > 
> > 
> > > Have you seen this line:
> > >   update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64
> > > since you changed /etc/default/keyboard and ran
> > >   sudo dpkg-reconfigure keyboard-configuration?
> > 
> > I replied just now before seeing this.  I think I may have taken the 
> > "GRUB uses the US keyboard layout by default" in my link a bit too far! 
> >  
> > 
> > > 
> > > Checking your current initrd is a little tedious: you run
> > > unmkinitramfs to unpack the initrd, and you zcat your
> > > /etc/console-setup/cached_UTF-8_del.kmap.gz to, say, /tmp.
> > > Then run, eg:
> > > 
> > > $ diff -u …/main/etc/console-setup/cached_UTF-8_del.kmap 
> > > /tmp/cached_UTF-8_del.kmap
> > > $ 
> > > 
> > > where they are the unpacked and decompressed files respectively.
> > > 
> > > Cheers,
> > > David.
> > > 
> > > 
> > 
> > 
> 
> I have set up a VM with up-to-date Bullseye KDE (LUKS/LVM guided 
> partitioning) to try to replicate this problem.
> 
> Adding the UK Colemak keyboard layout and promoting it to the top of 
> the list in system settings > keyboard does not make it take effect in 
> either the LUKS boot-time password or the graphical login - only after 
> login to KDE.
> 
> Switching to UK layout for usage and then running in konsole
> 
> # dpkg-reconfigure keyboard-configuration
> 
> [choosing UK then Colemak then default for AltGr/special keys etc]
> 
> does not change the active keyboard layout, nor for the LUKS boot 
> password or graphical login.
> 
> Out of interest, I thought I would try the  instructions (section 5):
> 
> https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html
> 
> - but they fail at the third command:
> 
> # tar -C "$memdisk" -cf /boot/grub/memdisk.tar
> tar: Cowardly refusing to create an empty archive
> Try 'tar --help' or 'tar --usage' for more information
> 
> I lack much experience with ramdisks and all but the simplest of grub 
> configuration, but I can't see either an obvious problem with the 
> syntax suggested, or anything in 'tar --help' that helps.
> 
> Any suggestions?
> 
> Thanks
> Gareth
> 
> 

Scrap that, I missed the . at the end of the command

Re: Colemak layout at boot time

[Gareth Evans]

On Sun 19 Sep 2021, at 13:00, Gareth Evans  wrote:
> On Sun 19 Sep 2021, at 11:48, Gareth Evans  wrote:
> > On Sun 19 Sep 2021, at 06:14, Gareth Evans  wrote:
> > > On Sun 19 Sep 2021, at 05:49, David Wright  
> > > wrote:
> > > > On Sat 18 Sep 2021 at 21:56:34 (+0100), piorunz wrote:
> > > > > On 18/09/2021 20:00, David Wright wrote:
> > > > > 
> > > > > > A lot of hits from googling   grub colemak   including
> > > > > > https://forums.debian.net//viewtopic.php?f=16&t=76833
> > > > > > which uses dvorak as an example.
> > > > > 
> > > > > Thanks for your reply.
> > > > > Yes I seen this page.
> > > > > 
> > > > > ckbcomp dvorak command outputs the layout details and everything.
> > > > > 
> > > > > However:
> > > > > $ ckbcomp colemak
> > > > > /usr/bin/ckbcomp: Can not find file "symbols/colemak" in any known 
> > > > > directory
> > > > > 
> > > > > > 
> > > > > > I don't recall the definition of "boot time password". Does this
> > > > > > denote something that Grub asks, or is it when dmcrypt is running
> > > > > > from the initrd?
> > > > > 
> > > > > By that I meant GRUB editor and Debian's standard whole disk 
> > > > > encryption
> > > > > in Debian. I don't have Colemak there. I need to enter password in
> > > > > Colemak. Yes, I think that's called dmcrypt.
> > > > > 
> > > > > > Which is a reminder: is your keyboard definition
> > > > > > in /etc/default/keyboard getting incorporated into the initrd or 
> > > > > > not?
> > > > > 
> > > > > I don't know that. I only have Colemak in KDE. Everything else,
> > > > > including virtual terminals (Ctrl+Alt+F keys) are Qwerty.
> > > > 
> > > > How do you normally login, at a VC or in a Display Manager?
> > > > 
> > > > Where did you run "sudo dpkg-reconfigure keyboard-configuration" from?
> > > > 
> > > 
> > > > Have you seen this line:
> > > >   update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64
> > > > since you changed /etc/default/keyboard and ran
> > > >   sudo dpkg-reconfigure keyboard-configuration?
> > > 
> > > I replied just now before seeing this.  I think I may have taken the 
> > > "GRUB uses the US keyboard layout by default" in my link a bit too far! 
> > >  
> > > 
> > > > 
> > > > Checking your current initrd is a little tedious: you run
> > > > unmkinitramfs to unpack the initrd, and you zcat your
> > > > /etc/console-setup/cached_UTF-8_del.kmap.gz to, say, /tmp.
> > > > Then run, eg:
> > > > 
> > > > $ diff -u …/main/etc/console-setup/cached_UTF-8_del.kmap 
> > > > /tmp/cached_UTF-8_del.kmap
> > > > $ 
> > > > 
> > > > where they are the unpacked and decompressed files respectively.
> > > > 
> > > > Cheers,
> > > > David.
> > > > 
> > > > 
> > > 
> > > 
> > 
> > I have set up a VM with up-to-date Bullseye KDE (LUKS/LVM guided 
> > partitioning) to try to replicate this problem.
> > 
> > Adding the UK Colemak keyboard layout and promoting it to the top of 
> > the list in system settings > keyboard does not make it take effect in 
> > either the LUKS boot-time password or the graphical login - only after 
> > login to KDE.
> > 
> > Switching to UK layout for usage and then running in konsole
> > 
> > # dpkg-reconfigure keyboard-configuration
> > 
> > [choosing UK then Colemak then default for AltGr/special keys etc]
> > 
> > does not change the active keyboard layout, nor for the LUKS boot 
> > password or graphical login.
> > 
> > Out of interest, I thought I would try the  instructions (section 5):
> > 
> > https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html
> > 
> > - but they fail at the third command:
> > 
> > # tar -C "$memdisk" -cf /boot/grub/memdisk.tar
> > tar: Cowardly refusing to create an empty archive
> > Try 'tar --help' or 'tar --usage' for more information
> > 
> > I lack much experience with ramdisks and all but the simplest of grub 
> > configuration, but I can't see either an obvious problem with the 
> > syntax suggested, or anything in 'tar --help' that helps.
> > 
> > Any suggestions?
> > 
> > Thanks
> > Gareth
> > 
> > 
> 
> Scrap that, I missed the . at the end of the command
> 
> 

The commands appeared to succeed (with suitable alteration of variables) but my 
VM now boots into a grub prompt immediately - doesn't ask for LUKS password.  I 
think this may be because I didn't change the "ahci" module to something else 
in step 3.  

man grub-mkimage doesn't list possibilities.  Can anyone suggest a suitable 
alternative for a VM created with virt-manager/qemu-kvm?  

Many thanks
Gareth

Re: Colemak layout at boot time

[Gareth Evans]

On Sun 19 Sep 2021, at 13:43, piorunz  wrote:
> On 19/09/2021 13:26, Gareth Evans wrote:
> 
> > The commands appeared to succeed (with suitable alteration of variables) 
> > but my VM now boots into a grub prompt immediately - doesn't ask for LUKS 
> > password.  I think this may be because I didn't change the "ahci" module to 
> > something else in step 3.
> >
> > man grub-mkimage doesn't list possibilities.  Can anyone suggest a suitable 
> > alternative for a VM created with virt-manager/qemu-kvm?
> 

> Are you saying I could try this Section 5 method to have Colemak at GRUB
> and LUKS password prompt? Not VM, but my laptop, real HW.

Not yet.  As things stand, those commands have only succeeded in breaking the 
VM I set up for the purpose, but I'm hoping someone can suggest the appropriate 
tweak, if the reason is what I think it is.

G

> 
> 
> --
> With kindest regards, Piotr.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄
> 
> 

Bullseye - who and users return nothing

[Gareth Evans]

Hello,

I've just noticed that: 

$ who

and

$ users

both return nothing, with or without sudo.

$ sudo strace who

access("/var/run/utmpx", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
or directory)
access("/var/run/utmpx", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
or directory)
close(1)= 0
close(2)= 0
exit_group(0)   = ?
+++ exited with 0 +++

I found these which look at least semi-relevant for other distros;  the redhat 
link seems to suggest a failure at or before login.

https://www.suse.com/support/kb/doc/?id=17277
https://bugzilla.redhat.com/show_bug.cgi?id=1396065

- but nothing for Debian - so any advice on how to proceed would be appreciated.

Can anyone replicate this or suggest what may have happened?  I'm fairly sure 
I've used who since upgrading from Buster.

Would try creating the files but I'm not sure of Debian's ownership/permissions 
requirements.

$ cat /etc/debian_version
11.2

Thanks,
Gareth

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Mon 24 Jan 2022, at 12:45, Greg Wooledge  wrote:
> On Mon, Jan 24, 2022 at 09:51:05AM +0000, Gareth Evans wrote:
>> I've just noticed that: 
>> 
>> $ who
>> 
>> and
>> 
>> $ users
>> 
>> both return nothing, with or without sudo.
>
>> Can anyone replicate this or suggest what may have happened?  I'm fairly 
>> sure I've used who since upgrading from Buster.
>
> Definitely can't replicate.  "who" gives me 28 lines of output for all
> of my terminals.
>
> As far as suggesting a cause -- we'd need more info.  

> Which init system
> are you using?  

systemd.  But for root on ZFS per 

https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html
 (adjusted for Bullseye) 

it's standard Debian-mate amd64

> How are you logging in?  

Logging into Mate with lightdm

> Are you using any terminal
> emulators, and if so, which one(s)?

mate-terminal

>
> Is the /var file system full?  (Or any mount underneath /var if you have
> such.)

$ sudo zfs list
NAMEUSED  AVAIL REFER  MOUNTPOINT
bpool   172M   660M   96K  /boot
bpool/BOOT  170M   660M   96K  none
bpool/BOOT/debian   170M   660M  170M  /boot
rpool  67.6G  45.7G  192K  /
rpool/ROOT 11.2G  45.7G  192K  none
rpool/ROOT/debian  11.2G  45.7G 11.2G  /
rpool/data  200K  45.7G  200K  /data
rpool/home 15.0G  45.7G 9.27G  /home
rpool/large3.06G  45.7G 3.06G  /large
rpool/backup1  4.94G  45.7G 1.03G  /backup1
rpool/backup2  15.7G  45.7G 3.94G  /backup2
rpool/swap 8.50G  54.2G  108K  -
rpool/var  9.06G  45.7G  412K  /var
rpool/var/cache 192M  45.7G  192M  /var/cache
rpool/var/lib  6.29G  45.7G  720K  /var/lib
rpool/var/lib/docker   19.0M  45.7G 19.0M  /var/lib/docker
rpool/var/lib/libvirt  5.94G  45.7G 5.94G  /var/lib/libvirt
rpool/var/lib/mysql 335M  45.7G  246M  /var/lib/mysql
rpool/var/log   363M  45.7G  363M  /var/log
rpool/var/spool 103M  45.7G  103M  /var/spool
rpool/var/tmp   250M  45.7G  250M  /var/tmp
rpool/var/www  1.89G  45.7G 1.40G  /var/www


> Have you done anything unique or unusual to your system that would cause
> it not to log sessions in /var/run/utmp?

Not afaik

>
>> $ sudo strace who
>> 
>> access("/var/run/utmpx", F_OK)  = -1 ENOENT (No such file or 
>> directory)
>> openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
>> file or directory)
>> access("/var/run/utmpx", F_OK)  = -1 ENOENT (No such file or 
>> directory)
>> openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
>> file or directory)
>> close(1)= 0
>> close(2)= 0
>> exit_group(0)   = ?
>> +++ exited with 0 +++
>
> Your /var/run/utmp file is missing.  That's definitely going to cause
> a problem here.
>
> Here's what mine looks like:
>
> unicorn:~$ df /var/run
> Filesystem 1K-blocks  Used Available Use% Mounted on
> tmpfs1215580  1456   1214124   1% /run
> unicorn:~$ ls -ld /var/run
> lrwxrwxrwx 1 root root 4 Jan 11  2018 /var/run -> /run/
> unicorn:~$ ls -l /var/run/utmp
> -rw-rw-r-- 1 root utmp 12288 Jan 20 15:08 /var/run/utmp
>
> I don't know what happened to yours, but since /run is an in-memory
> file system, all of the stuff inside it (including the utmp file) has
> to be created at boot time, or at login time at the very latest.
>

> You could try creating the file with the correct user/group/perms and
> see if that helps, but that probably won't survive the next reboot.

/var/run$ sudo touch utmp
/var/run$ sudo chown root:utmp utmp
/var/run$ sudo chmod 664 utmp
/var/run$ ls -l utmp
-rw-rw-r-- 1 root utmp 0 Jan 25 00:08 utmp
/var/run$ who
/var/run$
[logout, login]
/var/run$ ls -l /var/run/utmp
-rw-rw-r-- 1 root utmp 384 Jan 25 00:17 /var/run/utmp
$ who
user tty7 2022-01-25 00:17 (:0)
$ sudo reboot
...
$ ls -l /var/run/utmp
ls: cannot access '/var/run/utmp': No such file or directory

>
> You could also try rebooting and see if it gets created correctly.  If
> it doesn't, then I guess you get to dive into the internals of your
> init system to discover what's going wrong.
>

user@qwerty:~$ sudo service  systemd-update-utmp status
● systemd-update-utmp.service - Update UTMP about System Boot/Shutdown
 Loaded: loaded (/lib/systemd/system/systemd-update-utmp.service;

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 01:31, Gareth Evans  wrote:
> On Mon 24 Jan 2022, at 12:45, Greg Wooledge  wrote:
>> On Mon, Jan 24, 2022 at 09:51:05AM +0000, Gareth Evans wrote:
>>> I've just noticed that: 
>>> 
>>> $ who
>>> 
>>> and
>>> 
>>> $ users
>>> 
>>> both return nothing, with or without sudo.
>>
>>> Can anyone replicate this or suggest what may have happened?  I'm fairly 
>>> sure I've used who since upgrading from Buster.
>>
>> Definitely can't replicate.  "who" gives me 28 lines of output for all
>> of my terminals.
>>
>> As far as suggesting a cause -- we'd need more info.  
>
>> Which init system
>> are you using?  
>
> systemd.  But for root on ZFS per 
>
> https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html
>  
> (adjusted for Bullseye) 
>
> it's standard Debian-mate amd64
>
>> How are you logging in?  
>
> Logging into Mate with lightdm
>
>> Are you using any terminal
>> emulators, and if so, which one(s)?
>
> mate-terminal
>
>>
>> Is the /var file system full?  (Or any mount underneath /var if you have
>> such.)
>
> $ sudo zfs list
> NAMEUSED  AVAIL REFER  MOUNTPOINT
> bpool   172M   660M   96K  /boot
> bpool/BOOT  170M   660M   96K  none
> bpool/BOOT/debian   170M   660M  170M  /boot
> rpool  67.6G  45.7G  192K  /
> rpool/ROOT 11.2G  45.7G  192K  none
> rpool/ROOT/debian  11.2G  45.7G 11.2G  /
> rpool/data  200K  45.7G  200K  /data
> rpool/home 15.0G  45.7G 9.27G  /home
> rpool/large3.06G  45.7G 3.06G  /large
> rpool/backup1  4.94G  45.7G 1.03G  /backup1
> rpool/backup2  15.7G  45.7G 3.94G  /backup2
> rpool/swap 8.50G  54.2G  108K  -
> rpool/var  9.06G  45.7G  412K  /var
> rpool/var/cache 192M  45.7G  192M  /var/cache
> rpool/var/lib  6.29G  45.7G  720K  /var/lib
> rpool/var/lib/docker   19.0M  45.7G 19.0M  /var/lib/docker
> rpool/var/lib/libvirt  5.94G  45.7G 5.94G  /var/lib/libvirt
> rpool/var/lib/mysql 335M  45.7G  246M  /var/lib/mysql
> rpool/var/log   363M  45.7G  363M  /var/log
> rpool/var/spool 103M  45.7G  103M  /var/spool
> rpool/var/tmp   250M  45.7G  250M  /var/tmp
> rpool/var/www  1.89G  45.7G 1.40G  /var/www
>
>
>> Have you done anything unique or unusual to your system that would cause
>> it not to log sessions in /var/run/utmp?
>
> Not afaik
>
>>
>>> $ sudo strace who
>>> 
>>> access("/var/run/utmpx", F_OK)  = -1 ENOENT (No such file or 
>>> directory)
>>> openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
>>> file or directory)
>>> access("/var/run/utmpx", F_OK)  = -1 ENOENT (No such file or 
>>> directory)
>>> openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
>>> file or directory)
>>> close(1)= 0
>>> close(2)= 0
>>> exit_group(0)   = ?
>>> +++ exited with 0 +++
>>
>> Your /var/run/utmp file is missing.  That's definitely going to cause
>> a problem here.
>>
>> Here's what mine looks like:
>>
>> unicorn:~$ df /var/run
>> Filesystem 1K-blocks  Used Available Use% Mounted on
>> tmpfs1215580  1456   1214124   1% /run
>> unicorn:~$ ls -ld /var/run
>> lrwxrwxrwx 1 root root 4 Jan 11  2018 /var/run -> /run/
>> unicorn:~$ ls -l /var/run/utmp
>> -rw-rw-r-- 1 root utmp 12288 Jan 20 15:08 /var/run/utmp
>>
>> I don't know what happened to yours, but since /run is an in-memory
>> file system, all of the stuff inside it (including the utmp file) has
>> to be created at boot time, or at login time at the very latest.
>>
>
>> You could try creating the file with the correct user/group/perms and
>> see if that helps, but that probably won't survive the next reboot.
>
> /var/run$ sudo touch utmp
> /var/run$ sudo chown root:utmp utmp
> /var/run$ sudo chmod 664 utmp
> /var/run$ ls -l utmp
> -rw-rw-r-- 1 root utmp 0 Jan 25 00:08 utmp
> /var/run$ who
> /var/run$
> [logout, login]
> /var/run$ ls -l /var/run/utmp
> -rw-rw-r-- 1 root utmp 384 Jan

modprobe tun required after reboot for virt-manager

[Gareth Evans]

Further to my disappearing /var/run/utmp query, I also newly can't start VMs 
with virt-manager without first doing

$ sudo modprobe tun

This has also changed recently, apparently without intervention on my part.

Presumably it has stopped being autoloaded somewhere.

Should tun be in 

/etc/modules-load.d/modules.conf

or is there an on-demand approach which seems to have been corrupted?

Thanks,
Gareth

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 02:54, Greg Wooledge  wrote:
> On Tue, Jan 25, 2022 at 01:31:35AM +0000, Gareth Evans wrote:
>> /var/run$ sudo touch utmp
>> /var/run$ sudo chown root:utmp utmp
>> /var/run$ sudo chmod 664 utmp
>> /var/run$ ls -l utmp
>> -rw-rw-r-- 1 root utmp 0 Jan 25 00:08 utmp
>> /var/run$ who
>> /var/run$
>> [logout, login]
>> /var/run$ ls -l /var/run/utmp
>> -rw-rw-r-- 1 root utmp 384 Jan 25 00:17 /var/run/utmp
>> $ who
>> user tty7 2022-01-25 00:17 (:0)
>> $ sudo reboot
>> ...
>> $ ls -l /var/run/utmp
>> ls: cannot access '/var/run/utmp': No such file or directory
>
> A google search led me to <https://bugs.archlinux.org/task/47749>
> which says that the /run/utmp file is supposed to be created by
> "tmpfiles", specifically by the instructions in the configuration
> file /usr/lib/tmpfiles.d/systemd.conf .
>

> On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:
>
> F! /run/utmp 0664 root utmp -
>
> Does your system have this file, and if so, does it contain that line?

Thanks, yes:

$ sudo cat /usr/lib/tmpfiles.d/systemd.conf | grep utmp
F! /run/utmp 0664 root utmp -

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 03:02, Gareth Evans  wrote:
> On Tue 25 Jan 2022, at 02:54, Greg Wooledge  wrote:
>> On Tue, Jan 25, 2022 at 01:31:35AM +0000, Gareth Evans wrote:
>>> /var/run$ sudo touch utmp
>>> /var/run$ sudo chown root:utmp utmp
>>> /var/run$ sudo chmod 664 utmp
>>> /var/run$ ls -l utmp
>>> -rw-rw-r-- 1 root utmp 0 Jan 25 00:08 utmp
>>> /var/run$ who
>>> /var/run$
>>> [logout, login]
>>> /var/run$ ls -l /var/run/utmp
>>> -rw-rw-r-- 1 root utmp 384 Jan 25 00:17 /var/run/utmp
>>> $ who
>>> user tty7 2022-01-25 00:17 (:0)
>>> $ sudo reboot
>>> ...
>>> $ ls -l /var/run/utmp
>>> ls: cannot access '/var/run/utmp': No such file or directory
>>
>> A google search led me to <https://bugs.archlinux.org/task/47749>
>> which says that the /run/utmp file is supposed to be created by
>> "tmpfiles", specifically by the instructions in the configuration
>> file /usr/lib/tmpfiles.d/systemd.conf .
>>
>
>> On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:
>>
>> F! /run/utmp 0664 root utmp -
>>

>> Does your system have this file, and if so, does it contain that line?
>
> Thanks, yes:
>
> $ sudo cat /usr/lib/tmpfiles.d/systemd.conf | grep utmp
> F! /run/utmp 0664 root utmp -

And fwiw (from a comment in the link you provided)

$ sudo journalctl -b _COMM=systemd-tmpfiles
-- Journal begins at Sat 2021-08-21 14:27:06 BST, ends at Tue 2022-01-25 03:04:>
-- No entries --

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 03:28, Greg Wooledge  wrote:
> On Tue, Jan 25, 2022 at 03:06:00AM +0000, Gareth Evans wrote:
>> On Tue 25 Jan 2022, at 03:02, Gareth Evans  wrote:
>> > On Tue 25 Jan 2022, at 02:54, Greg Wooledge  wrote:
>> >> A google search led me to <https://bugs.archlinux.org/task/47749>
>> >> which says that the /run/utmp file is supposed to be created by
>> >> "tmpfiles", specifically by the instructions in the configuration
>> >> file /usr/lib/tmpfiles.d/systemd.conf .
>> >>
>> >
>> >> On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:
>> >>
>> >> F! /run/utmp 0664 root utmp -
>> >>
>> 
>> >> Does your system have this file, and if so, does it contain that line?
>> >
>> > Thanks, yes:
>> >
>> > $ sudo cat /usr/lib/tmpfiles.d/systemd.conf | grep utmp
>> > F! /run/utmp 0664 root utmp -
>> 
>> And fwiw (from a comment in the link you provided)
>> 
>> $ sudo journalctl -b _COMM=systemd-tmpfiles
>> -- Journal begins at Sat 2021-08-21 14:27:06 BST, ends at Tue 2022-01-25 
>> 03:04:>
>> -- No entries --
>
> Next thing to check seems to be:
>
> systemctl status systemd-tmpfiles-setup.service

Aha...

systemd-tmpfiles-setup.service - Create Volatile Files and Directories
 Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static)
 Active: active (exited) since Tue 2022-01-25 01:46:52 GMT; 1h 53min ago
   Docs: man:tmpfiles.d(5)
 man:systemd-tmpfiles(8)
Process: 1340 ExecStart=systemd-tmpfiles --create --remove --boot 
--exclude-prefix=/dev (code=exited, status=73)
   Main PID: 1340 (code=exited, status=73)
CPU: 20ms

Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of /var/log/journal.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of /var/log/journal.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of 
/var/log/journal/7f684579096949909ba2bfac31e8423e.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of 
/var/log/journal/7f684579096949909ba2bfac31e8423e.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of 
/var/log/journal/7f684579096949909ba2bfac31e8423e.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /run during canonicalization of /run/log/journal.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /run during canonicalization of /run/log/journal.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of 
/var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of 
/var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
Jan 25 01:46:52 qwerty systemd[1]: Finished Create Volatile Files and 
Directories.

Googling "Detected unsafe path transition during canonicalization" led me to 

https://bbs.archlinux.org/viewtopic.php?id=260924

where a user sees this error because / is owned by the user rather than root.

Lo and behold

$ stat /

shows this is what has somehow happened.

$ sudo chown root:root /

solves the disappearing /var/run/utmp problem (and fixes who/users) 

There is nothing in bash history to suggest I did this - can/should it happen 
any other way?

Thanks very much for your help Greg.

Gareth


>
> Make sure it hasn't been disabled or masked, I suppose.  The unit file
> contains this command:
>
> ExecStart=systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
>
> So, I guess make sure yours has that too.  But hopefully you'll discover
> that it's been disabled or something silly like that, and then you can
> just enable it.

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 04:10, Polyna-Maude Racicot-Summerside 
 wrote:
> On 2022-01-24 23:03, Gareth Evans wrote:
>> On Tue 25 Jan 2022, at 03:28, Greg Wooledge  wrote:
>>> On Tue, Jan 25, 2022 at 03:06:00AM +, Gareth Evans wrote:
>>>> On Tue 25 Jan 2022, at 03:02, Gareth Evans  wrote:
>>>>> On Tue 25 Jan 2022, at 02:54, Greg Wooledge  wrote:
>>>>>> A google search led me to <https://bugs.archlinux.org/task/47749>
>>>>>> which says that the /run/utmp file is supposed to be created by
>>>>>> "tmpfiles", specifically by the instructions in the configuration
>>>>>> file /usr/lib/tmpfiles.d/systemd.conf .
>>>>>>
>>>>>
>>>>>> On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:
>>>>>>
>>>>>> F! /run/utmp 0664 root utmp -
>>>>>>
>>>>
>>>>>> Does your system have this file, and if so, does it contain that line?
>>>>>
>>>>> Thanks, yes:
>>>>>
>>>>> $ sudo cat /usr/lib/tmpfiles.d/systemd.conf | grep utmp
>>>>> F! /run/utmp 0664 root utmp -
>>>>
>>>> And fwiw (from a comment in the link you provided)
>>>>
>>>> $ sudo journalctl -b _COMM=systemd-tmpfiles
>>>> -- Journal begins at Sat 2021-08-21 14:27:06 BST, ends at Tue 2022-01-25 
>>>> 03:04:>
>>>> -- No entries --
>>>
>>> Next thing to check seems to be:
>>>
>>> systemctl status systemd-tmpfiles-setup.service
>> 
>> Aha...
>> 
>> systemd-tmpfiles-setup.service - Create Volatile Files and Directories
>>  Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; 
>> static)
>>  Active: active (exited) since Tue 2022-01-25 01:46:52 GMT; 1h 53min ago
>>Docs: man:tmpfiles.d(5)
>>  man:systemd-tmpfiles(8)
>> Process: 1340 ExecStart=systemd-tmpfiles --create --remove --boot 
>> --exclude-prefix=/dev (code=exited, status=73)
>>Main PID: 1340 (code=exited, status=73)
>> CPU: 20ms
>> 
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of /var/log/journal.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of /var/log/journal.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of 
>> /var/log/journal/7f684579096949909ba2bfac31e8423e.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of 
>> /var/log/journal/7f684579096949909ba2bfac31e8423e.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of 
>> /var/log/journal/7f684579096949909ba2bfac31e8423e.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /run during canonicalization of /run/log/journal.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /run during canonicalization of /run/log/journal.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of 
>> /var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of 
>> /var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
>> Jan 25 01:46:52 qwerty systemd[1]: Finished Create Volatile Files and 
>> Directories.
>> 
>> Googling "Detected unsafe path transition during canonicalization" led me to 
>> 
>> https://bbs.archlinux.org/viewtopic.php?id=260924
>> 
>> where a user sees this error because / is owned by the user rather than root.
>> 
>> Lo and behold
>> 
>> $ stat /
>> 
>> shows this is what has somehow happened.
>> 
>> $ sudo chown root:root /
>> 
>> solves the disappearing /var/run/utmp problem (and fixes who/users) 
>> 
>> There is nothing in bash history to suggest I did this - can/should it 
>> happen any other way?

> No one other than you know the whole story behind what happened with
> your computer.
>
> Is it a new clean install
> How did you partition the hard drive
> etc..

Hi,

The last clean installation was of Buster and it's since been upgraded to 
Bulls

Re: modprobe tun required after reboot for virt-manager

[Gareth Evans]

On Tue 25 Jan 2022, at 02:11, Gareth Evans  wrote:
> Further to my disappearing /var/run/utmp query, I also newly can't 
> start VMs with virt-manager without first doing
>
> $ sudo modprobe tun
>
> This has also changed recently, apparently without intervention on my part.
>
> Presumably it has stopped being autoloaded somewhere.
>
> Should tun be in 
>
> /etc/modules-load.d/modules.conf
>
> or is there an on-demand approach which seems to have been corrupted?
>
> Thanks,
> Gareth

Fixed.

https://lists.debian.org/debian-user/2022/01/msg01003.html

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 04:50, David Wright  wrote:
> On Tue 25 Jan 2022 at 04:22:39 (+), Gareth Evans wrote:
>> On Tue 25 Jan 2022, at 04:10, Polyna-Maude Racicot-Summerside 
>>  wrote:
>> > On 2022-01-24 23:03, Gareth Evans wrote:
>> >> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> >> transition / → /var during canonicalization of 
>> >> /var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
>> >> Jan 25 01:46:52 qwerty systemd[1]: Finished Create Volatile Files and 
>> >> Directories.
>> >> 
>> >> Googling "Detected unsafe path transition during canonicalization" led me 
>> >> to 
>> >> 
>> >> https://bbs.archlinux.org/viewtopic.php?id=260924
>> >> 
>> >> where a user sees this error because / is owned by the user rather than 
>> >> root.
>> >> 
>> >> Lo and behold
>> >> 
>> >> $ stat /
>> >> 
>> >> shows this is what has somehow happened.
>> >> 
>> >> $ sudo chown root:root /
>> >> 
>> >> solves the disappearing /var/run/utmp problem (and fixes who/users) 
>> >> 
>> >> There is nothing in bash history to suggest I did this - can/should it 
>> >> happen any other way?
>> 
>> > No one other than you know the whole story behind what happened with
>> > your computer.
>> >
>> > Is it a new clean install
>> > How did you partition the hard drive
>> > etc..
>> 
>> The last clean installation was of Buster and it's since been upgraded to 
>> Bullseye.
>> 
>> An unfinished and accidentally-executed 
>> 
>> sudo chown /[some/file] 
>> 
>> doesn't seem impossible, but the lack of any such thing in bash history 
>> seems curious.  Perhaps a leading space crept in too, which would exclude 
>> the command from the history.
>> 
>> I was just wondering about other ways that could happen, if any.
>
> A frequent way, sometimes narrated in Operator Horror Stories from
> years ago, was untarring an archive. Gnu tar does its best to protect
> you, but can be overridden.
>

> But my Q1 is always "What were the ownerships and permissions before
> you reverted them?" That's often the best clue. 

As of now:

$ ls -ld /
drwxr-xr-x 23 root root 33 Jan 21 14:48 /

The only difference was my username in the owner position.

There is nothing in my [timestamped] bash history at 14:48 on 21 Jan.  Just 
before that time I had used engrampa from the command line. Use of other 
scripts around the time suggests the archive concerned may have been a file in 
/var/www/html - I do sometimes have to change permissions and ownership there, 
so perhaps (cough mumble mumble).

Thanks all.
G






> Eg, from just yesterday:
> https://lists.debian.org/debian-user/2022/01/msg00874.html
> caused by restoring backups from amanda.
>
> Cheers,
> David.

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 10:47, Andrei POPESCU  wrote:
> On Ma, 25 ian 22, 04:03:17, Gareth Evans wrote:
>> 
>> Googling "Detected unsafe path transition during canonicalization" led me to 
>> 
>> https://bbs.archlinux.org/viewtopic.php?id=260924
>> 
>> where a user sees this error because / is owned by the user rather than root.
>> 
>> Lo and behold
>> 
>> $ stat /
>> 
>> shows this is what has somehow happened.
>> 
>> $ sudo chown root:root /
>> 
>> solves the disappearing /var/run/utmp problem (and fixes who/users) 
>> 
>> There is nothing in bash history to suggest I did this - can/should it 
>> happen any other way?
>

> Occam's Razor would suggest this was done when setting up your / on ZFS.

Hi Andrei,

chown root:root / 

fixed both this issue and my need (today, as discussed in my other email) to 

modprobe tun

to be able to run VMs with virt-manager.

That was a new problem I only noticed today when setting up a VM to find/grep 
relevant strings/filenames that would exist in a new installation.  I use VMs 
more often than who/users but have certainly done both without issue since 
setting up / on ZFS.

But worth bearing in mind :)

Thanks
Gareth


>
>
> Kind regards,
> Andrei
> -- 
> http://wiki.debian.org/FAQsFromDebianUser
>
> Attachments:
> * signature.asc

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 01:31, Gareth Evans  wrote:
> On Mon 24 Jan 2022, at 12:45, Greg Wooledge  wrote:
>> On Mon, Jan 24, 2022 at 09:51:05AM +0000, Gareth Evans wrote:
>>> I've just noticed that: 
>>> 
>>> $ who
>>> 
>>> and
>>> 
>>> $ users
>>> 
>>> both return nothing, with or without sudo.
>>
>>> Can anyone replicate this or suggest what may have happened?  I'm fairly 
>>> sure I've used who since upgrading from Buster.
>>
>> Definitely can't replicate.  "who" gives me 28 lines of output for all
>> of my terminals.
>>
>> As far as suggesting a cause -- we'd need more info.  
>
>> Which init system
>> are you using?  
>
> systemd.  But for root on ZFS per 
>
> https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html
>  
> (adjusted for Bullseye) 
>
> it's standard Debian-mate amd64
>
>> How are you logging in?  
>
> Logging into Mate with lightdm
>
>> Are you using any terminal
>> emulators, and if so, which one(s)?
>
> mate-terminal
>
>>
>> Is the /var file system full?  (Or any mount underneath /var if you have
>> such.)
>
> $ sudo zfs list
> NAMEUSED  AVAIL REFER  MOUNTPOINT
> bpool   172M   660M   96K  /boot
> bpool/BOOT  170M   660M   96K  none
> bpool/BOOT/debian   170M   660M  170M  /boot
> rpool  67.6G  45.7G  192K  /
> rpool/ROOT 11.2G  45.7G  192K  none
> rpool/ROOT/debian  11.2G  45.7G 11.2G  /
> rpool/data  200K  45.7G  200K  /data
> rpool/home 15.0G  45.7G 9.27G  /home
> rpool/large3.06G  45.7G 3.06G  /large
> rpool/backup1  4.94G  45.7G 1.03G  /backup1
> rpool/backup2  15.7G  45.7G 3.94G  /backup2
> rpool/swap 8.50G  54.2G  108K  -
> rpool/var  9.06G  45.7G  412K  /var
> rpool/var/cache 192M  45.7G  192M  /var/cache
> rpool/var/lib  6.29G  45.7G  720K  /var/lib
> rpool/var/lib/docker   19.0M  45.7G 19.0M  /var/lib/docker
> rpool/var/lib/libvirt  5.94G  45.7G 5.94G  /var/lib/libvirt
> rpool/var/lib/mysql 335M  45.7G  246M  /var/lib/mysql
> rpool/var/log   363M  45.7G  363M  /var/log
> rpool/var/spool 103M  45.7G  103M  /var/spool
> rpool/var/tmp   250M  45.7G  250M  /var/tmp
> rpool/var/www  1.89G  45.7G 1.40G  /var/www
>
>
>> Have you done anything unique or unusual to your system that would cause
>> it not to log sessions in /var/run/utmp?
>
> Not afaik
>
>>
>>> $ sudo strace who
>>> 
>>> access("/var/run/utmpx", F_OK)  = -1 ENOENT (No such file or 
>>> directory)
>>> openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
>>> file or directory)
>>> access("/var/run/utmpx", F_OK)  = -1 ENOENT (No such file or 
>>> directory)
>>> openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
>>> file or directory)
>>> close(1)= 0
>>> close(2)= 0
>>> exit_group(0)   = ?
>>> +++ exited with 0 +++
>>
>> Your /var/run/utmp file is missing.  That's definitely going to cause
>> a problem here.
>>
>> Here's what mine looks like:
>>
>> unicorn:~$ df /var/run
>> Filesystem 1K-blocks  Used Available Use% Mounted on
>> tmpfs1215580  1456   1214124   1% /run
>> unicorn:~$ ls -ld /var/run
>> lrwxrwxrwx 1 root root 4 Jan 11  2018 /var/run -> /run/
>> unicorn:~$ ls -l /var/run/utmp
>> -rw-rw-r-- 1 root utmp 12288 Jan 20 15:08 /var/run/utmp
>>
>> I don't know what happened to yours, but since /run is an in-memory
>> file system, all of the stuff inside it (including the utmp file) has
>> to be created at boot time, or at login time at the very latest.
>>
>
>> You could try creating the file with the correct user/group/perms and
>> see if that helps, but that probably won't survive the next reboot.
>
> /var/run$ sudo touch utmp
> /var/run$ sudo chown root:utmp utmp
> /var/run$ sudo chmod 664 utmp
> /var/run$ ls -l utmp
> -rw-rw-r-- 1 root utmp 0 Jan 25 00:08 utmp
> /var/run$ who
> /var/run$
> [logout, login]
> /var/run$ ls -l /var/run/utmp
> -rw-rw-r-- 1 root utmp 384 Jan

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 13:11, Greg Wooledge  wrote:
> On Tue, Jan 25, 2022 at 01:06:42PM +0000, Gareth Evans wrote:
>> Just realised I gave contradicting info earlier - I said both that I 
>> upgraded from Buster (which is literally true) and that
>> 
>> "But for root on ZFS per 
>> 
>> https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html
>>  (adjusted for Bullseye)  <<<<<<
>> 
>> ..."
>> 
>> which isn't, because Bullseye arrived via dist-upgrade, rather than a fresh 
>> installation.
>> 
>> My mistake may have prompted Andrei's suggestion which I then explained away 
>> partly in relation to having upgraded - sorry.
>
> I don't know anything about ZFS.  That said, it's *conceivable* that
> your / ownership has been broken this entire time, and you never noticed
> until now.  Either because you never ran "who", or because 

> systemd in
> buster didn't check the parent directory ownerships, but the one in
> bullseye does.

That's interesting.

FWIW, trying to get a timeframe...

My email re bullseye upgrade hiccups back in August

https://lists.debian.org/debian-user/2021/08/msg00979.html

indicates that I upgraded to Bullseye on 17th Aug 2021.  There were at most a 
few days of experimenting with restoring Buster snapshots and re-upgrading, but 
that was certainly done with by October, when QEMU logs show VM usage.   

I've never had to 

modprobe tun 

to start a VM before today, and Bash history shows who usage on 22/12/21.  
Given this info and that the / ownership fix fixed both problems, I think that 
suggests a recent(ish) event as the cause.

>
> Food for thought.
>
> (It's not clear to me how setting up ZFS on / would involve your
> unprivileged username, though.  Sounds more like a "boot from rescue
> media and do everything in a root shell" sort of job.  

It is, but...

"5. Create a user account:

username=YOUR_USERNAME
zfs create rpool/home/$username
adduser $username
cp -a /etc/skel/. /home/$username
chown -R $username:$username /home/$username
..."

https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html

:)


> So I'm more
> inclined to think the damage was done by some sort of backup/recovery
> gone wrong, as previously speculated.)

Re: The Raspberry Pi that Took a Day Off.

[Gareth Evans]

> On 25 Jan 2022, at 14:17, Martin McCormick  wrote:
> 
> This Pi is running Debian Stretch.  I believe that's what version
> 9 is called.  I have it capturing audio from a radio receiver and
> it's been doing that for several years now and it was doing that
> yesterday morning.  Later in the day, I downloaded more audio
> and, after a long pause, I got the message from ssh that the
> Raspberry Pi wasn't there any longer so I retrieved the Pi from
> the room where it was and brought it to my Debian desktop system
> to work on it.
> 
>I could login to the Pi which seemed to be up and running
> but the short story is that it couldn't talk to any address but
> our router.I couldn't even ping it's interface from the Pi,
> itself.
> 
>If I was on the Raspberry Pi's console, everything looked
> normal as long as one wasn't using the TCP/IP interface.  You
> could even do a ip addr or an ipconfig -a command and it would
> show that it had gotten the correct address from our dhcp server
> which is in the router.  It would successfully ping the router
> but no other addresses, not even the address it uses on our
> network.
> 
>I finally quit messing with it and went to bed but fired
> it up again today, January 25 and low and behold, it just came
> right up and is now back doing what it has been doing.
> 
>Is it possible that it got a corrupted lease for dhcp
> from the router?  Dhcp leases on our Netgear router are issued
> for not quite 24 hours so it may have gotten a bad lease, kept
> renewing it for the time it was powered up and then it got a new
> version of that lease today and all is well.
> 
>It's the same IP address because I have put it in the
> router as a static IP address.
> 
>The other thing that is weird is that the Raspberry Pi in
> question has both a wired Ethernet and a WiFi interface and both
> were misbehaving identically.
> 
>Normally, the wired port is not used and the dhcp lease
> renewal process happens over WiFi.
> 
>The results of ip addr always showed a correct subnet
> mask and the only rules in iptables are the 2 default rules.  In
> other words, all looked normal except that it didn't work.
> 
>While I had it on the work bench, so to speak, I ran fsck
> -fy on the SSD card since it has been a couple of years since I
> last did that and there was not a single squawk about anything.
> 
>Thanks for any ideas about how things got wrong and then
> magically fixed themselves.
> 
>When I turned it off last night, I gave it the halt -p
> command.  The power supply has no switch so I unplugged it from
> power so it started fresh about 8 hours later.
> 
> Martin WB5AGZ
> 

Hi Martin,

Are your router logs accessible?

Is there anything of potential relevance in those or the pi logs around the 
time it stopped/restarted 'connecting' (or even in the interim)?

Perhaps

cat /var/log/syslog{.n} | grep -i dhcp

might be a start, where {.n} indicates an optional eg. .1, .2 etc if syslog 
itself no longer contains logs from the relevant time.

The router may have a web interface that includes a section for errors if you 
can't get into it with ssh.  Not sure how helpful that might be even if one 
exists, but  maybe worth a look.

Gareth

Disappearning shim-signed after failed dist-upgrade

[Gareth Evans]

A recent dist-upgrade on Buster (in a scripted cron job run at 01:00 daily) 
failed due to apt-listbugs complaining about the boot-breaking bug in 
shim-signed, and pinning v1.33 in the process.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990082

The next (manual) dist-upgrade removed shim-signed v1.33

$ cat /var/log/apt/history.log
Start-Date: 2021-06-20  18:33:29
Commandline: apt-get -y dist-upgrade
Requested-By: x (1000)
Upgrade: shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7, 
1.36~1+deb10u1+15.4-5~deb10u1)
Remove: shim-signed:amd64 (1.33+15+1533136590.3beb971-7)
End-Date: 2021-06-20  18:33:30

unattended-upgrades (which I had forgotten was installed) upgraded some related 
packages earlier the same day, but not shim-signed itself:

$ cat /var/log/apt/history.log
Start-Date: 2021-06-20  06:26:31
Commandline: /usr/bin/unattended-upgrade
Upgrade: shim-helpers-amd64-signed:amd64 (1+15+1533136590.3beb971+7+deb10u1, 
1+15.4+5~deb10u1), shim-unsigned:amd64 (15+1533136590.3beb971-7+deb10u1, 
15.4-5~deb10u1)
End-Date: 2021-06-20  06:26:34

The only references to shim-signed in apt history logs were the initial Buster 
installation, and the recent removal:

/var/log/apt$ grep -n "shim-signed:" history.log*
history.log:209:Remove: shim-signed:amd64 (1.33+15+1533136590.3beb971-7)
history.log.6:33:Install: [...] shim-signed:amd64 
(1.33+15+1533136590.3beb971-7) [...]


As I don't currently use secure boot, I ignored the bug warnings when I 
reinstalled it and dependencies (the buster-updates version per the email from 
debian-stable-announce yesterday
https://lists.debian.org/debian-stable-announce/2021/06/msg1.html

...but still:

$ apt policy shim-signed
shim-signed:
  Installed: 1.36~1+deb10u2+15.4-5~deb10u1
  Candidate: 1.36~1+deb10u2+15.4-5~deb10u1

$ apt-listbugs list shim-signed
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of shim-signed (→ ) 
 b1 - #990082 - High chance of boot problems with buster's version of arm64 shim
grave bugs of shim-signed (→ ) 
 b2 - #987991 - shim-signed: Recent dbx update blacklists shimx64.efi 
(1.33+15+1533136590.3beb971-7) (Fixed: shim-signed/1.34)
Summary:
 shim-signed(2 bugs)

$ apt-listbugs list shim-signed-common
critical bugs of shim-signed-common (→ ) 
 b1 - #990158 - shim-signed-common: No UEFI boot with error "Could not create 
MokListXRT"
Summary:
 shim-signed-common(1 bug)

Is this referring to the non buster-updates package?

Can anyone enlighten me as to:

Why might shim-signed v1.33 have been removed by dist-upgrade despite the 
previous upgrade attempt having been aborted by apt-listbugs?

What's the best way to reinstall an older package version and its old 
dependencies if affected by something like this, and it isn't to be found in 
/var/cache/apt/archives?

Thanks,
Gareth

Re: Disappearing shim-signed after failed dist-upgrade

[Gareth Evans]

On Tue 22 Jun 2021, at 19:13, David Wright  wrote:
> On Tue 22 Jun 2021 at 08:59:13 (+0100), Gareth Evans wrote:
> > A recent dist-upgrade on Buster (in a scripted cron job run at 01:00 daily) 
> > failed due to apt-listbugs complaining about the boot-breaking bug in 
> > shim-signed, and pinning v1.33 in the process.
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990082
> 
> AFAICT it looks as though you were just a victim of bad timing.
> I happened to upgrade the point release at Start-Date:
> 2021-06-19  17:27:11, and my term.log shows:
> 
>   Setting up fluidsynth (1.1.11-1+deb10u1) ...
>   Setting up shim-helpers-amd64-signed (1+15.4+5~deb10u1) ...
>   Installing for x86_64-efi platform.
>   Installation finished. No error reported.
>   Setting up python-libxml2 (2.9.4+dfsg1-7+deb10u2) ...
>   Setting up shim-signed:amd64 (1.36~1+deb10u1+15.4-5~deb10u1) ...
>   Installing for x86_64-efi platform.
>   Installation finished. No error reported.
>   Secure Boot not enabled on this system.
>   Processing triggers for mime-support (3.62) ...
> 
> By 01:00 next morning, the grave bug stopped your upgrade from
> finishing. I guess that's a disadvantage of unattended upgrades:
> you don't see the bug reports as they occur. (I download any
> updates automatically, which serves as an announcement, but
> always upgrade manually.)
> 
> > The next (manual) dist-upgrade removed shim-signed v1.33
> > 
> > $ cat /var/log/apt/history.log
> > Start-Date: 2021-06-20  18:33:29
> > Commandline: apt-get -y dist-upgrade
> > Requested-By: x (1000)
> > Upgrade: shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7, 
> > 1.36~1+deb10u1+15.4-5~deb10u1)
> > Remove: shim-signed:amd64 (1.33+15+1533136590.3beb971-7)
> > End-Date: 2021-06-20  18:33:30
> > 
> > unattended-upgrades (which I had forgotten was installed) upgraded some 
> > related packages earlier the same day, but not shim-signed itself:
> > 
> > $ cat /var/log/apt/history.log
> > Start-Date: 2021-06-20  06:26:31
> > Commandline: /usr/bin/unattended-upgrade
> > Upgrade: shim-helpers-amd64-signed:amd64 
> > (1+15+1533136590.3beb971+7+deb10u1, 1+15.4+5~deb10u1), shim-unsigned:amd64 
> > (15+1533136590.3beb971-7+deb10u1, 15.4-5~deb10u1)
> > End-Date: 2021-06-20  06:26:34
> > 
> > The only references to shim-signed in apt history logs were the initial 
> > Buster installation, and the recent removal:
> > 
> > /var/log/apt$ grep -n "shim-signed:" history.log*
> > history.log:209:Remove: shim-signed:amd64 (1.33+15+1533136590.3beb971-7)
> > history.log.6:33:Install: [...] shim-signed:amd64 
> > (1.33+15+1533136590.3beb971-7) [...]
> > 
> > 
> > As I don't currently use secure boot, I ignored the bug warnings when I 
> > reinstalled it and dependencies (the buster-updates version per the email 
> > from debian-stable-announce yesterday
> > https://lists.debian.org/debian-stable-announce/2021/06/msg1.html
> 
> AIUI that's the correct thing to do in our situation. (It's an upgrade
> rather than a reinstall: my new shim-signed{,-common} debs arrived at
> noon yesterday.)
> 
> > ...but still:
> > 
> > $ apt policy shim-signed
> > shim-signed:
> >   Installed: 1.36~1+deb10u2+15.4-5~deb10u1
> >   Candidate: 1.36~1+deb10u2+15.4-5~deb10u1
> > 
> > $ apt-listbugs list shim-signed
> > Retrieving bug reports... Done
> > Parsing Found/Fixed information... Done
> > grave bugs of shim-signed (→ ) 
> >  b1 - #990082 - High chance of boot problems with buster's version of arm64 
> > shim
> > grave bugs of shim-signed (→ ) 
> >  b2 - #987991 - shim-signed: Recent dbx update blacklists shimx64.efi 
> > (1.33+15+1533136590.3beb971-7) (Fixed: shim-signed/1.34)
> > Summary:
> >  shim-signed(2 bugs)
> > 
> > $ apt-listbugs list shim-signed-common
> > critical bugs of shim-signed-common (→ ) 
> >  b1 - #990158 - shim-signed-common: No UEFI boot with error "Could not 
> > create MokListXRT"
> > Summary:
> >  shim-signed-common(1 bug)
> > 
> > Is this referring to the non buster-updates package?
> 
> No. But I don't use secure boot, so I haven't been following along
> with the shim's problem. (That is the same state of play shown by my system.)
> 
> > Can anyone enlighten me as to:
> > 
> > Why might shim-signed v1.33 have been removed by dist-upgrade despite the 
> > previous upgrade attempt having been aborted by apt-listbugs?
> 
> $ aptitude why shim-signed
> i   grub-efi-amd64   

Re: Disappearing shim-signed after failed dist-upgrade

[Gareth Evans]

On Tue 29 Jun 2021, at 17:11, David Wright  wrote:
> On Tue 29 Jun 2021 at 08:29:22 (+0300), Andrei POPESCU wrote:
> > On Lu, 28 iun 21, 09:46:17, David Wright wrote:
> > > 
> > > But your evening run of   apt-get -y dist-upgrade   was unconstrained,
> > > and so shim-signed could be removed because it was no longer being
> > > held onto as a Depends or Recommends.
> > 
> > Except that `apt-get dist-upgrade` doesn't do that (`autoremove` does), 
> > it only removes packages when it determines that it's needed to complete 
> > the dist-upgrade, so a Conflicts or Breaks with an upgraded package.
> 
> So we can presume, perhaps, that it's a case of ranking:
> shim-signed being installed as a Recommends is ranked lower
> than upgrading shim-signed-common, and so it gets removed.
> 
> All my systems were upgraded successfully because I ignored
> any arm64 bug reports, so all my lists and caches have been
> refreshed since, and I don't have access to the control data
> for shim-signed/1.33+15+1533136590.3beb971-7.
> 
> Perhaps others can make better informed guesses.
> 
> Cheers,
> David.
> 
> 

I suspect "aptitude why shim-signed" may not remain relevant, but if so:

$ aptitude why shim-signed
i   grub-efi-amd64-signed Recommends shim-signed

apt history shows grub-efi-amd64-signed was last upgraded along with other 
grub* packages, apparently without issue, on 2021-03-03.

Even if I had made use of upgrade rather than dist-upgrade, presumably a 
dist-upgrade would have been indicated here (by the existence of packages kept 
back) and the same position would have resulted - ie. having to wait for a 
potentially essential package to be made available in upgraded form so it could 
be reinstalled so that it could be further upgraded in future... no?

$ aptitude why shim-signed-common
i   shim-signed Depends shim-signed-common (>= 1.36~1+deb10u2+15.4-5~deb10u1)

It seems the upgrade of shim-signed-common may have removed shim-signed.

Shouldn't essential packages involved in dependencies only ever be available 
for upgrade together, unless perhaps the dependency >=version remains satisfied?

Before succeeding in installing the newer version of shim-signed, I did try 
installing the version originally installed with Buster, but apt said it wasn't 
available.  In the end I didn't need to attempt installing from eg. DVD, but 
couldn't this be impossible too due to other conflicts?

In short, should a boot-related package ever be removed and not replaced in the 
same upgrade operation?

Is it to be expected to have to keep an eye on this sort of thing?

Thanks all.
Gareth

Re: Disappearing shim-signed after failed dist-upgrade

[Gareth Evans]

On Tue 29 Jun 2021, at 22:41, Gareth Evans  wrote:
> On Tue 29 Jun 2021, at 17:11, David Wright  wrote:
> > On Tue 29 Jun 2021 at 08:29:22 (+0300), Andrei POPESCU wrote:
> > > On Lu, 28 iun 21, 09:46:17, David Wright wrote:
> > > > 
> > > > But your evening run of   apt-get -y dist-upgrade   was unconstrained,
> > > > and so shim-signed could be removed because it was no longer being
> > > > held onto as a Depends or Recommends.
> > > 
> > > Except that `apt-get dist-upgrade` doesn't do that (`autoremove` does), 
> > > it only removes packages when it determines that it's needed to complete 
> > > the dist-upgrade, so a Conflicts or Breaks with an upgraded package.
> > 
> > So we can presume, perhaps, that it's a case of ranking:
> > shim-signed being installed as a Recommends is ranked lower
> > than upgrading shim-signed-common, and so it gets removed.
> > 
> > All my systems were upgraded successfully because I ignored
> > any arm64 bug reports, so all my lists and caches have been
> > refreshed since, and I don't have access to the control data
> > for shim-signed/1.33+15+1533136590.3beb971-7.
> > 
> > Perhaps others can make better informed guesses.
> > 
> > Cheers,
> > David.
> > 
> > 
> 
> I suspect "aptitude why shim-signed" may not remain relevant, but if so:
> 
> $ aptitude why shim-signed
> i   grub-efi-amd64-signed Recommends shim-signed
> 
> apt history shows grub-efi-amd64-signed was last upgraded along with 
> other grub* packages, apparently without issue, on 2021-03-03.
> 
> Even if I had made use of upgrade rather than dist-upgrade, presumably 
> a dist-upgrade would have been indicated here (by the existence of 
> packages kept back) and the same position would have resulted - ie. 
> having to wait for a potentially essential package to be made available 
> in upgraded form so it could be reinstalled so that it could be further 
> upgraded in future... no?
> 
> $ aptitude why shim-signed-common
> i   shim-signed Depends shim-signed-common (>= 1.36~1+deb10u2+15.4-5~deb10u1)
> 
> It seems the upgrade of shim-signed-common may have removed shim-signed.
> 
> Shouldn't essential packages involved in dependencies only ever be 
> available for upgrade together, unless perhaps the dependency >=version 
> remains satisfied?
> 
> Before succeeding in installing the newer version of shim-signed, I did 
> try installing the version originally installed with Buster, but apt 
> said it wasn't available.  In the end I didn't need to attempt 
> installing from eg. DVD, but couldn't this be impossible too due to 
> other conflicts?
> 
> In short, should a boot-related package ever be removed and not 
> replaced in the same upgrade operation?
> 
> Is it to be expected to have to keep an eye on this sort of thing?
> 
> Thanks all.
> Gareth
> 
> 

> having to wait for a potentially essential package to be made available 
> in upgraded form

That and related comments might not make sense.

I didn't explain there was a period when I couldn't (re)install shim-signed as 
apt install reported not found or something like that.  Thinking about it 
further after sending the above, I'm not entirely sure at what point I unpinned 
shim-signed, so will check logs and snapshots and rack brains and get back to 
you.

Thanks,
Gareth

runc CVEs in docker.io

[Gareth Evans]

Hello,

I was just trying to install docker.io on Buster stable when apt-listbugs 
complained about one of the open CVEs listed here:

https://security-tracker.debian.org/tracker/source-package/runc

Given that these are all fixed in Bullseye (and at least the grave apt-listbugs 
issue has been fixed in eg Ubuntu since March 2020 [1]) why not also Buster?

apt-listbugs said:

... CVE-2019-16884 (Fixed: runc/1.0.0~rc9+dfsg1-1) ...

According to 

https://tracker.debian.org/pkg/runc

there are 3 open security issues in (Stretch and) Buster (though I imagine 
Debian's support for Stretch has ended with EOL in 2020?) - do fixes like this 
come in batches?  

Thanks,
Gareth

[1] https://ubuntu.com/security/notices/USN-4297-1

Re: runc CVEs in docker.io

[Gareth Evans]

On Mon  2 Aug 2021, at 11:48, Dominique Dumont  wrote:
> On Tuesday, 27 July 2021 18:07:53 CEST Gareth Evans wrote:
> > Given that these are all fixed in Bullseye (and at least the grave
> > apt-listbugs issue has been fixed in eg Ubuntu since March 2020 [1]) why
> > not also Buster?
> 

> According to runc security tracker, a fixed runc is available for buster, 
> albeit in buster's security repository.

Thanks Dominique, do you have a link for this please?  All I can find is

https://security-tracker.debian.org/tracker/source-package/runc

which includes 

"available versions
...
buster  1.0.0~rc6+dfsg1-3"

and in the section following that, the ~rc6 version is apparently vulnerable on 
Buster to all open issues listed (at the time of writing), including 
CVE-2019-16884 complained of by apt-listbugs.  I can't see any reference there 
to a security repo version, and my system doesn't find it, even after adding 
the line suggested in "keeping secure" [link below] to sources.list

> I guess that security repo is missing from your /etc/apt/sources.list
> 
> See https://www.debian.org/security/#keeping-secure for instructions.

I already had a couple of references to security repos (do they all point to 
the same thing?) but added the line suggested anyway - but no change even after 
reboot and a second update.


$ sudo cat /etc/apt/sources.list
deb https://deb.debian.org/debian buster contrib main non-free
deb https://deb.debian.org/debian buster-updates contrib main non-free
deb https://deb.debian.org/debian-security/ buster/updates contrib main non-free
deb https://deb.debian.org/debian buster-backports contrib main non-free
deb https://security.debian.org/ buster/updates contrib main non-free
deb https://security.debian.org/debian-security buster/updates contrib main 
non-free


$ sudo apt update
Hit:1 https://security.debian.org buster/updates InRelease
Hit:2 https://deb.debian.org/debian buster InRelease
Hit:3 https://linux.teamviewer.com/deb stable InRelease
Hit:4 https://security.debian.org/debian-security buster/updates InRelease
Hit:5 https://deb.debian.org/debian buster-updates InRelease
Hit:6 https://deb.debian.org/debian-security buster/updates InRelease
Hit:7 https://deb.debian.org/debian buster-backports InRelease
...
All packages are up to date.


$ sudo apt install docker.io
...
grave bugs of runc (→ 1.0.0~rc6+dfsg1-3) 
 b1 - #942026 - runc: CVE-2019-16884 (Fixed: runc/1.0.0~rc9+dfsg1-1)
Summary:
 runc(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] 


Tracker still shows that CVE and two others as open security issues in Buster.  

https://tracker.debian.org/pkg/runc

and

$ apt policy runc
runc:
  Installed: (none)
  Candidate: 1.0.0~rc6+dfsg1-3
  Version table:
 1.0.0~rc6+dfsg1-3 500
500 https://deb.debian.org/debian buster/main amd64 Packages


Grateful for any further advice.

Thanks,
Gareth

> 
> HTH
> 
> Dod
> 
> 
> 
> 

Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

[Gareth Evans]

> On 28 Jan 2022, at 16:52, David Wright  wrote:
> 
> On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote:
>> David Wright  writes:
>>> I've not heard of that problem. You were prevented from zeroing the
>>> entire device, which would have wiped the partition table anyway.
>>> 
>>> What I would want to check is that the OS isn't doing something
>>> stupid, like trying to automount it, failing, and consequently
>>> setting the device readonly. By OS, I really mean DEs, or
>>> automounters in general.
>>> 
>>> You could also try zeroing it in another machine, ± any adapters
>>> required. (Bear in mind that adapters do have readonly sliders.)
>> 
>>I suspect this is the crux of the problem.  the adapter I
>> connected is a card reader.  You put the SSD in a little plastic
>> jacket that holds the SSD in such a way that the card reader can
>> access the edge connector but the holder jacket has no electronics.
>> There is a small notch in the plastic of the jacket on the left
>> edge and the right front corner of the plastic carrier has a
>> diagonal cut to prevent someone from putting it in upsidedown.
> 
> Yes, most connectors are keyed in some way, though some are quite
> fragile, like the plastic post in PS/2 keyboards and mice.
> 
>>Since I posted, there is good news but I still wonder if
>> I am not going bonkers because after unplugging the Sony card reader
>> and plugging it back in, I now am getting device /dev/sdg instead
>> of /dev/sdh.  I was also able to do the following:
>> 
>>#sudo fdisk /dev/sdg
>> 
>> which gave me the fdisk utility as before so I did what crazy
>> people do which is to do the same thing as before, hoping for
>> different results.
> 
> That's why people are encourages to use [PART]UUIDs and [PART]LABELs
> instead of dynamically chosen kernel names.
> 
> Pulling the card could reset a gate, or it could clean the contacts.
> Who knows. I would tend to mark down the card as suspect, and not
> use it in mission-critical ways.
> 
>>By Joe, I got them.
>> 
>> I typed d to delete a partition and it put partition 2 up as the
>> default candidate as before so I selected it and then typed d
>> again which told me that only partition 1 was left so it was
>> deleted.
>> 
>>I had gotten this far before so wasn't too excited but type
>> w and this time got the message stating that the partition table
>> had been rewritten and fdisk then exited.
>> 
>>Now, doing sudo fdisk -l /dev/sdg yields
>> 
>> 1wb5agz martin tmp $ sudo fdisk -l /dev/sdg
>> Disk /dev/sdg: 28.8 GiB, 30908350464 bytes, 60367872 sectors
>> Disk model: USB   HS-SD Card
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disklabel type: dos
>> Disk identifier: 0x680226ff
>> 
>>The partitions are gone.  My latest screwball theory is
>> that the Sony card reader went in to some sort of protective mode
>> after the dd operation overwrote the device.  My unplugging the
>> reader and plugging it back in reran the driver which reset the
>> protective mode back to normal which may be why it all worked
>> right this time.
> 
> Who knows.
> 
>>One last question:  Since the image will still be too
>> large as it is, can tunefs be run on it or a copy of it to shrink
>> about 4 gb of user space?  The good system I copied the image
>> from only had about 12%  of the partition used so I should be
>> able to transplant it to the smaller disk if tunefs can do that
>> and still leave a bootable device.
> 
> I don't know what this image contains, but I'm guessing it's the
> rootfs for the Pi. My question then is how full was it. I assume
> that you don't run it to 100% usage, and even then, there are
> files you can do without, like rotated logfiles, caches etc.
> 
> Two different methods:
> 
> One course of action would be to copy the old to the new card, just
> as you have done, with dd running out of space. That deals with
> three things: the MBR, the partition table, and the first partition
> (whatever that it).
> 
> Next, I would fdisk it, delete partition 2 and recreate it so that
> its size matches the partition table entry. Recreate a filesystem
> with mkfs.
> 
> Next, I copy the entire contents of the second partition from the
> old card to the new, using   copy -a   or   rsync …   or whatever
> you're comfortable with. This assumes, I think, that you don't
> have weird things like sparse files and so on.
> 
> If you run out of space, then you may need to prune your target
> to make sure the essential files (like /etc, /usr) are copied,
> and be more selective with other trees, like parts of /var, /home.
> 

> A second course of action would be to copy the entire card to
> file on a disk, loop mount it, and reduce the contents of the
> second partition so that you know there'll be room for it on the
> new card. Then dd from the image ...

I've been anticipating this stage and looking for s

Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

[Gareth Evans]

> On 28 Jan 2022, at 18:16, Gareth Evans  wrote:
> 
> 
> 
>>> On 28 Jan 2022, at 16:52, David Wright  wrote:
>>> 
>>> On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote:
>>> David Wright  writes:
>>>> I've not heard of that problem. You were prevented from zeroing the
>>>> entire device, which would have wiped the partition table anyway.
>>>> 
>>>> What I would want to check is that the OS isn't doing something
>>>> stupid, like trying to automount it, failing, and consequently
>>>> setting the device readonly. By OS, I really mean DEs, or
>>>> automounters in general.
>>>> 
>>>> You could also try zeroing it in another machine, ± any adapters
>>>> required. (Bear in mind that adapters do have readonly sliders.)
>>> 
>>>   I suspect this is the crux of the problem.  the adapter I
>>> connected is a card reader.  You put the SSD in a little plastic
>>> jacket that holds the SSD in such a way that the card reader can
>>> access the edge connector but the holder jacket has no electronics.
>>> There is a small notch in the plastic of the jacket on the left
>>> edge and the right front corner of the plastic carrier has a
>>> diagonal cut to prevent someone from putting it in upsidedown.
>> 
>> Yes, most connectors are keyed in some way, though some are quite
>> fragile, like the plastic post in PS/2 keyboards and mice.
>> 
>>>   Since I posted, there is good news but I still wonder if
>>> I am not going bonkers because after unplugging the Sony card reader
>>> and plugging it back in, I now am getting device /dev/sdg instead
>>> of /dev/sdh.  I was also able to do the following:
>>> 
>>>   #sudo fdisk /dev/sdg
>>> 
>>> which gave me the fdisk utility as before so I did what crazy
>>> people do which is to do the same thing as before, hoping for
>>> different results.
>> 
>> That's why people are encourages to use [PART]UUIDs and [PART]LABELs
>> instead of dynamically chosen kernel names.
>> 
>> Pulling the card could reset a gate, or it could clean the contacts.
>> Who knows. I would tend to mark down the card as suspect, and not
>> use it in mission-critical ways.
>> 
>>>   By Joe, I got them.
>>> 
>>> I typed d to delete a partition and it put partition 2 up as the
>>> default candidate as before so I selected it and then typed d
>>> again which told me that only partition 1 was left so it was
>>> deleted.
>>> 
>>>   I had gotten this far before so wasn't too excited but type
>>> w and this time got the message stating that the partition table
>>> had been rewritten and fdisk then exited.
>>> 
>>>   Now, doing sudo fdisk -l /dev/sdg yields
>>> 
>>> 1wb5agz martin tmp $ sudo fdisk -l /dev/sdg
>>> Disk /dev/sdg: 28.8 GiB, 30908350464 bytes, 60367872 sectors
>>> Disk model: USB   HS-SD Card
>>> Units: sectors of 1 * 512 = 512 bytes
>>> Sector size (logical/physical): 512 bytes / 512 bytes
>>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>> Disklabel type: dos
>>> Disk identifier: 0x680226ff
>>> 
>>>   The partitions are gone.  My latest screwball theory is
>>> that the Sony card reader went in to some sort of protective mode
>>> after the dd operation overwrote the device.  My unplugging the
>>> reader and plugging it back in reran the driver which reset the
>>> protective mode back to normal which may be why it all worked
>>> right this time.
>> 
>> Who knows.
>> 
>>>   One last question:  Since the image will still be too
>>> large as it is, can tunefs be run on it or a copy of it to shrink
>>> about 4 gb of user space?  The good system I copied the image
>>> from only had about 12%  of the partition used so I should be
>>> able to transplant it to the smaller disk if tunefs can do that
>>> and still leave a bootable device.
>> 
>> I don't know what this image contains, but I'm guessing it's the
>> rootfs for the Pi. My question then is how full was it. I assume
>> that you don't run it to 100% usage, and even then, there are
>> files you can do without, like rotated logfiles, caches etc.
>> 
>> Two different methods:
>> 
>> One course of action would be to copy the old to the new card, just
>> as you have done, with dd running out of space. That deals with
>> th

Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

[Gareth Evans]

> On 28 Jan 2022, at 20:40, David Wright  wrote:
> 
> On Fri 28 Jan 2022 at 18:22:37 (+), Gareth Evans wrote:
>>> On 28 Jan 2022, at 18:16, Gareth Evans  wrote:
>>>>> On 28 Jan 2022, at 16:52, David Wright  wrote:
>>>>> On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote:
>>>>> David Wright  writes:
>>>>>> I've not heard of that problem. You were prevented from zeroing the
>>>>>> entire device, which would have wiped the partition table anyway.
>>>>>> 
>>>>>> What I would want to check is that the OS isn't doing something
>>>>>> stupid, like trying to automount it, failing, and consequently
>>>>>> setting the device readonly. By OS, I really mean DEs, or
>>>>>> automounters in general.
>>>>>> 
>>>>>> You could also try zeroing it in another machine, ± any adapters
>>>>>> required. (Bear in mind that adapters do have readonly sliders.)
>>>>> 
>>>>>  I suspect this is the crux of the problem.  the adapter I
>>>>> connected is a card reader.  You put the SSD in a little plastic
>>>>> jacket that holds the SSD in such a way that the card reader can
>>>>> access the edge connector but the holder jacket has no electronics.
>>>>> There is a small notch in the plastic of the jacket on the left
>>>>> edge and the right front corner of the plastic carrier has a
>>>>> diagonal cut to prevent someone from putting it in upsidedown.
>>>> 
>>>> Yes, most connectors are keyed in some way, though some are quite
>>>> fragile, like the plastic post in PS/2 keyboards and mice.
>>>> 
>>>>>  Since I posted, there is good news but I still wonder if
>>>>> I am not going bonkers because after unplugging the Sony card reader
>>>>> and plugging it back in, I now am getting device /dev/sdg instead
>>>>> of /dev/sdh.  I was also able to do the following:
>>>>> 
>>>>>  #sudo fdisk /dev/sdg
>>>>> 
>>>>> which gave me the fdisk utility as before so I did what crazy
>>>>> people do which is to do the same thing as before, hoping for
>>>>> different results.
>>>> 
>>>> That's why people are encourages to use [PART]UUIDs and [PART]LABELs
>>>> instead of dynamically chosen kernel names.
>>>> 
>>>> Pulling the card could reset a gate, or it could clean the contacts.
>>>> Who knows. I would tend to mark down the card as suspect, and not
>>>> use it in mission-critical ways.
>>>> 
>>>>>  By Joe, I got them.
>>>>> 
>>>>> I typed d to delete a partition and it put partition 2 up as the
>>>>> default candidate as before so I selected it and then typed d
>>>>> again which told me that only partition 1 was left so it was
>>>>> deleted.
>>>>> 
>>>>>  I had gotten this far before so wasn't too excited but type
>>>>> w and this time got the message stating that the partition table
>>>>> had been rewritten and fdisk then exited.
>>>>> 
>>>>>  Now, doing sudo fdisk -l /dev/sdg yields
>>>>> 
>>>>> 1wb5agz martin tmp $ sudo fdisk -l /dev/sdg
>>>>> Disk /dev/sdg: 28.8 GiB, 30908350464 bytes, 60367872 sectors
>>>>> Disk model: USB   HS-SD Card
>>>>> Units: sectors of 1 * 512 = 512 bytes
>>>>> Sector size (logical/physical): 512 bytes / 512 bytes
>>>>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>>>> Disklabel type: dos
>>>>> Disk identifier: 0x680226ff
>>>>> 
>>>>>  The partitions are gone.  My latest screwball theory is
>>>>> that the Sony card reader went in to some sort of protective mode
>>>>> after the dd operation overwrote the device.  My unplugging the
>>>>> reader and plugging it back in reran the driver which reset the
>>>>> protective mode back to normal which may be why it all worked
>>>>> right this time.
>>>> 
>>>> Who knows.
>>>> 
>>>>>  One last question:  Since the image will still be too
>>>>> large as it is, can tunefs be run on it or a copy of it to shrink
>>>>> about 4 gb of user space?  The good system I copied the image
>>>>> from only ha

Re: Resize2fs Questions

[Gareth Evans]

> On 31 Jan 2022, at 14:41, Martin McCormick  wrote:
> 
> #I should be telling resize2fs to squeeze everything in to a 7GB
> #partition.
>   sudo resize2fs /dev/loop0p2 +7G
> [...]
> then I delete P2 and then add a
> new partition which defaults to 2.

This seems to replace the partition containing the filesystem you've just 
resized with an empty one - doesn't it?

Re: Resize2fs Questions

[Gareth Evans]

> On 31 Jan 2022, at 17:37, Andy Smith  wrote:
> 
> Hello,
> 
> On Mon, Jan 31, 2022 at 05:27:56PM +0000, Gareth Evans wrote:
>>>> On 31 Jan 2022, at 14:41, Martin McCormick  wrote:
>>> 
>>> #I should be telling resize2fs to squeeze everything in to a 7GB
>>> #partition.
>>>  sudo resize2fs /dev/loop0p2 +7G
>>> [...]
>>> then I delete P2 and then add a
>>> new partition which defaults to 2.
>> 
>> This seems to replace the partition containing the filesystem you've just 
>> resized with an empty one - doesn't it?
> 
> When you change a partition table it doesn't do anything to the
> data on the disk, only the partition table. Every partition resizing
> operation that only has to move the end position essentially does it
> this way.
> 
> (If you have to move the start then the data has to be moved first)
> 
> If you were using parted then you might type:
> 
> resizepart 2 7g
> 
> which looks less scary, but does exactly the same thing.
> 
> Cheers,
> Andy
> 
> -- 
> https://bitfolk.com/ -- No-nonsense VPS hosting
> 

Hi Andy, I appreciate the data doesn't go anywhere, but...

>> then I delete P2 and then add a
>> new partition which defaults to 2.

doesn't that at least result in the appearance of deletion (an empty partition) 
if done after the resizing?

Re: Resize2fs Questions

[Gareth Evans]

> On 31 Jan 2022, at 17:58, Gareth Evans  wrote:
> 
> 
> 
>> On 31 Jan 2022, at 17:37, Andy Smith  wrote:
>> 
>> Hello,
>> 
>> On Mon, Jan 31, 2022 at 05:27:56PM +, Gareth Evans wrote:
>>>>>> On 31 Jan 2022, at 14:41, Martin McCormick  
>>>>>> wrote:
>>>>> 
>>>>> #I should be telling resize2fs to squeeze everything in to a 7GB
>>>>> #partition.
>>>>> sudo resize2fs /dev/loop0p2 +7G
>>>>> [...]
>>>>> then I delete P2 and then add a
>>>>> new partition which defaults to 2.
>>> 
>>> This seems to replace the partition containing the filesystem you've just 
>>> resized with an empty one - doesn't it?
>> 
>> When you change a partition table it doesn't do anything to the
>> data on the disk, only the partition table. Every partition resizing
>> operation that only has to move the end position essentially does it
>> this way.
>> 
>> (If you have to move the start then the data has to be moved first)
>> 
>> If you were using parted then you might type:
>> 
>> resizepart 2 7g
>> 
>> which looks less scary, but does exactly the same thing.
>> 
>> Cheers,
>> Andy
>> 
>> -- 
>> https://bitfolk.com/ -- No-nonsense VPS hosting
>> 
> 
> Hi Andy, I appreciate the data doesn't go anywhere, but...
> 
>>> then I delete P2 and then add a
>>> new partition which defaults to 2.
> 
> doesn't that at least result in the appearance of deletion (an empty 
> partition) if done after the resizing?

Do you mean creating a new partition 'around' the data makes it accessible 
again?  That would make sense re eg what testdisk seems to do...

Re: Resize2fs Questions

[Gareth Evans]

> On 31 Jan 2022, at 18:03, Gareth Evans  wrote:
> 
> 
> 
>> On 31 Jan 2022, at 17:58, Gareth Evans  wrote:
>> 
>> 
>> 
>>>> On 31 Jan 2022, at 17:37, Andy Smith  wrote:
>>> 
>>> Hello,
>>> 
>>> On Mon, Jan 31, 2022 at 05:27:56PM +, Gareth Evans wrote:
>>>>>>> On 31 Jan 2022, at 14:41, Martin McCormick  
>>>>>>> wrote:
>>>>>> 
>>>>>> #I should be telling resize2fs to squeeze everything in to a 7GB
>>>>>> #partition.
>>>>>> sudo resize2fs /dev/loop0p2 +7G
>>>>>> [...]
>>>>>> then I delete P2 and then add a
>>>>>> new partition which defaults to 2.
>>>> 
>>>> This seems to replace the partition containing the filesystem you've just 
>>>> resized with an empty one - doesn't it?
>>> 
>>> When you change a partition table it doesn't do anything to the
>>> data on the disk, only the partition table. Every partition resizing
>>> operation that only has to move the end position essentially does it
>>> this way.
>>> 
>>> (If you have to move the start then the data has to be moved first)
>>> 
>>> If you were using parted then you might type:
>>> 
>>> resizepart 2 7g
>>> 
>>> which looks less scary, but does exactly the same thing.
>>> 
>>> Cheers,
>>> Andy
>>> 
>>> -- 
>>> https://bitfolk.com/ -- No-nonsense VPS hosting
>>> 
>> 
>> Hi Andy, I appreciate the data doesn't go anywhere, but...
>> 
>>>> then I delete P2 and then add a
>>>> new partition which defaults to 2.
>> 
>> doesn't that at least result in the appearance of deletion (an empty 
>> partition) if done after the resizing?
> 
> Do you mean creating a new partition 'around' the data makes it accessible 
> again?  That would make sense re eg what testdisk seems to do...

Sorry - wasn't thinking!

Re: Resize2fs Questions

[Gareth Evans]


> On 31 Jan 2022, at 23:36, Andy Smith  wrote:
> Hello,
> 
> On Mon, Jan 31, 2022 at 05:57:45PM +0000, Gareth Evans wrote:
>>> On 31 Jan 2022, at 17:37, Andy Smith  wrote:
>> Hi Andy, I appreciate the data doesn't go anywhere, but...
>> 
>>>> then I delete P2 and then add a
>>>> new partition which defaults to 2.
>> 
>> doesn't that at least result in the appearance of deletion (an empty 
>> partition) if done after the resizing?
> 
> A partition table is just basically a list of start and end
> positions of partitions.
> 
> When you "delete a partition" all you've done is removed the entry
> in the table, but the data that belongs to the partition you just
> deleted is still on the disk in the place where it always was.
> 
> If you then put back a partition the same as it was before (or
> bigger), it will then show up as a valid partition again.
> 
> In the case of a grow, you then tell your FS or whatever to use the
> empty space that's now at the end.
> 
> In the case of a shrink, you already told your FS (or whatever) to
> create a gap between the end of the FS and the end of the partition,
> so after deleting that partition you can add a "new" partition that
> has an end position that matches the end of the shrunken FS.
> 
> If this does not make it clear that "deleting a partition" in fdisk
> or parted or whatever is a perfectly normal thing to do that doesn't
> in itself trash your data, I don't know how better to explain it and
> you will have to elaborate as to where the confusion lies. I don't
> know what "the appearance of deletion" means to you in this context
> or why you think it harms any data that is on a disk.

Hi Andy,

I'm afraid I replied before I'd thought through what I had in mind, which was, 
wrongly, that deleting a partition unlinks the files it contains.

"Appearance of deletion" was a poor choice of words.  I meant that unlinked 
files could be recovered (if not first overwritten), although deletion is 
indeed the appropriate term.

Thinking of testdisk/photorec reminded me that I was thinking (and writing) 
wrongly in the first place.

Thanks anyway for your explanation.

Gareth
 
> 
> Cheers,
> Andy
> 
> -- 
> https://bitfolk.com/ -- No-nonsense VPS hosting
> 

Re: QEMU/KVM doesn't open new window - Access only via vnc viewer

[Gareth Evans]

> On 31 Mar 2022, at 09:44, Dieter Rohlfing  wrote:
> 
> Hi,
> 
> I'm just about to install Debian11/Bullseye on a host. There are several
> VMs running under QEMU/KVM to set up.
> 
> With Debian9/Stretch I created a new VM via command line:
> 
> /usr/bin/kvm -drive
> file=/qemu/win-70/win-70.jessie.raw,if=virtio,media=disk,cache=none,format=raw
> -name Win-70 -vga std -m 3072 -enable-kvm -rtc base=localtime -boot order=c
> 
> As a result QEMU/KVM opened a new window with the output of the VM.
> 
> With Debian11/Bullseye QEMU/KVM doesn't open a new window, but a message
> appears, telling me to access the output via a vnc viewer. With the vnc
> viewer I can see this output: the VM started correctly.
> 
> How can I get back the output of the VM in a window (like in Debian9)?
> 
> My researches in the internet delivered no results. I always found
> statements like "open a window with the option '-vga std'". Is this no
> more valid for Debian11?
> 
> Dieter
> 

A different invocation method, but does this help, or give a clue to something 
equivalent?

https://lists.debian.org/debian-user/2021/09/msg00691.html

Re: Libreoffice: printing "dirties" the file being printed

[Gareth Evans]

On Thu  7 Apr 2022, at 09:58, Jonathan Dowland  wrote:
> On Sat, Apr 02, 2022 at 07:08:11PM +0100, Brad Rogers wrote:
>>Tools menu/Options - General; 'Printing sets "document modified" status'
>

> Does anyone have any insight into why this is an option? More
> specifically, what reason would anyone want to have their document
> marked as modified because they printed it?

I wondered about that too and looked into it.  I now can't find the references 
I found, either in my browser history or by re-searching, but iirc, 
Apple[-related] and LibreOffice forum posts suggested it's to do with:

LO:  MS Word does it, so LO does it / because fields in the document may be 
automatically updated prior to printing

Apple: Pages documents include a "last printed" property which gets updated 
when the doc is printed - which suggests there's no option in that case.

Not sure of the accuracy of either report...

Best wishes,
Gareth

>
> -- 
> Please do not CC me for listmail.
>
> 👱🏻Jonathan Dowland
> ✎  j...@debian.org
> 🔗 https://jmtd.net

Re: CUPS - how to match autodetected printers to physical ones

[Gareth Evans]

On Mon 11 Apr 2022, at 19:23, Brian  wrote:
> On Mon 11 Apr 2022 at 13:55:03 -0400, Greg Wooledge wrote:
>
>> On Mon, Apr 11, 2022 at 06:47:59PM +0100, Brian wrote:
>> > BTW. I am interested in how using /usr/lib/cups/backend/snmp went.
>> > Its drawback is that not all printers provide an snmp service.
>> 
>> wooledg:~$ /usr/lib/cups/backend/snmp
>> network socket://10.76.172.120 "HP LaserJet 4250" "hp LaserJet 4250" 
>> "MFG:Hewlett-Packard;CMD:PJL,MLC,PCLXL,PCL,PJL,POSTSCRIPT;1284.4DL:4d,4e,1;MDL:hp
>>  LaserJet 4250;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4250;" "W01-0224"
>> network socket://10.76.172.88 "HP LaserJet 4100 Series" "HP LaserJet 4100 
>> Series" "MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,POSTSCRIPT,PCLXL,PJL;MDL:HP 
>> LaserJet 4100 Series ;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4100 Series;" 
>> ""
>> network socket://10.76.173.60:9100 "HP LaserJet P3010 Series" "HP LaserJet 
>> P3010 Series" 
>> "MFG:Hewlett-Packard;CMD:PJL,BIDI-ECP,PJL,POSTSCRIPT,PDF,PCLXL,PCL;MDL:HP 
>> LaserJet P3010 Series;CLS:PRINTER;DES:Hewlett-Packard LaserJet P3010 
>> Series;" ""
>> 
>> Looks like that doesn't contain anything for the Canon printers.
>
> Although used by other vendors, a socket://... URI is really an HP
> thing, used by JetDirect appliances, so not surprising. Anyway, this
> very useful info of yours would prompt me to discard advising the use
> of snmp to match IP address with printer model. We are back to
> avahi-browse.
>
> I appreciate you print to that printer infrequently but would suggest a
> manually set up queue may suit you.
>
> Execute
>
>   driverless
>
> to get its URI. (I am sure you can sort out which one it is).
>
> Then
>
>   lpadmin -p SENSIBLE_PRINTER_NAME -L MYOFFICE -v URI -E -m everywhere
>
> -- 
> Brian.


I've been searching for documentation on CUPS "implicitclass" but can't find 
much.

I did find this:

'CUPS can automatically merge multiple identical network printers into 
"implicit classes". This allows clients to send jobs to the implicit class and 
have them print on the first available printer or server.' [though the doc 
predates CUPS driverless printing by some margin]
https://www.cups.org/test/testfile.pdf (p4)

The above is similar (though possibly quite different) to
https://opensource.apple.com/source/cups/cups-87/doc/sam.shtml#PRINTER_CLASSES
(2nd para under 'The Basics')

Assuming implicitclass is the mechanism of first resort in auto-detection (my 
own setup suggests so), does anyone know if this means that, with multiple 
devices of the same type, there's no guarantee from which device printing from 
the same queue will emerge, or are implicit classes resulting from 
auto-detection implemented as implicit classes of one?

Thanks,
Gareth

snapshot.debian.org

[Gareth Evans]

Hello,

I have a strange printing problem which can be replicated on two identical 
printers on two different networks, when printing to wireless driverless IPP 
with Brother MFC-L2740DW printers from Bullseye, whether the printer is 
auto-detected or manually added via ocalhost:631 or system-config-printer.  

The printers light up and look like business, print queue monitors report jobs 
completed, but nothing actually prints.

There are some errors in /var/log/cups/error_log but I won't go into that at 
the moment because I'm trying to downgrade cups and this is another problem.

I think this problem has occurred since a cups update on 2022-05-27, so having 
purged it completely and removed /etc/cups and reinstalled it (along with much 
else due to dependency issues of libcups2) I am now trying to downgrade cups to 
see if that makes a difference.

I have followed the instructions at:

https://vincent.bernat.ch/en/blog/2020-downgrade-debian

$ sudo cat /etc/apt/sources*d/snapshot.list
deb [check-valid-until=no] 
https://snapshot.debian.org/archive/debian/202220526T155509Z/ bullseye main 
contrib non-free
$

$  sudo cat /etc/apt/pref*d/snapshot.pref
Package: *cups*
Pin: origin snapshot.debian.org
Pin-Priority: 1001
$

but...

$ sudo apt update

Err:7 https://snapshot.debian.org/archive/debian/202220526T155509Z bullseye 
Release
  404  Not Found [IP: 185.17.185.185 443]


AFAICS from examples/instructions at snapshot.debian.org my snapshot.list file 
is correct - it looks to me like something has moved/is offline at the server 
end.  Pinging snapshot.debian.org doesn't seem to be helpful as the IP which is 
not found changes depending on the archive requested - but snapshot.debian.org 
itself replies to pings.

Is anyone involved with snapshot.debian.org?  ...or aware of issues at the 
moment?

Thanks,
Gareth

Re: snapshot.debian.org

[Gareth Evans]

On Mon  6 Jun 2022, at 12:19, Gareth Evans  wrote:
> Hello,
>
> I have a strange printing problem which can be replicated on two 
> identical printers on two different networks, when printing to wireless 
> driverless IPP with Brother MFC-L2740DW printers from Bullseye, whether 
> the printer is auto-detected or manually added via ocalhost:631 or 
> system-config-printer.  
>
> The printers light up and look like business, print queue monitors 
> report jobs completed, but nothing actually prints.
>
> There are some errors in /var/log/cups/error_log but I won't go into 
> that at the moment because I'm trying to downgrade cups and this is 
> another problem.
>
> I think this problem has occurred since a cups update on 2022-05-27, so 
> having purged it completely and removed /etc/cups and reinstalled it 
> (along with much else due to dependency issues of libcups2) I am now 
> trying to downgrade cups to see if that makes a difference.
>
> I have followed the instructions at:
>
> https://vincent.bernat.ch/en/blog/2020-downgrade-debian
>
> $ sudo cat /etc/apt/sources*d/snapshot.list
> deb [check-valid-until=no] 
> https://snapshot.debian.org/archive/debian/202220526T155509Z/ bullseye 
> main contrib non-free
> $
>
> $  sudo cat /etc/apt/pref*d/snapshot.pref
> Package: *cups*
> Pin: origin snapshot.debian.org
> Pin-Priority: 1001
> $
>
> but...
>
> $ sudo apt update
> 
> Err:7 https://snapshot.debian.org/archive/debian/202220526T155509Z 
> bullseye Release
>   404  Not Found [IP: 185.17.185.185 443]
> 

Sorry, please ignore - 404 because too many 2s in 20222.
Working now.
G

>
> AFAICS from examples/instructions at snapshot.debian.org my 
> snapshot.list file is correct - it looks to me like something has 
> moved/is offline at the server end.  Pinging snapshot.debian.org 
> doesn't seem to be helpful as the IP which is not found changes 
> depending on the archive requested - but snapshot.debian.org itself 
> replies to pings.
>
> Is anyone involved with snapshot.debian.org?  ...or aware of issues at 
> the moment?
>
> Thanks,
> Gareth

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

On Mon  6 Jun 2022, at 13:05, rhkra...@gmail.com wrote:
> On Monday, June 06, 2022 07:34:07 AM Gareth Evans wrote:
>> On Mon  6 Jun 2022, at 12:19, Gareth Evans  wrote:
>> > I have a strange printing problem which can be replicated on two
>> > identical printers on two different networks, when printing to wireless
>> > driverless IPP with Brother MFC-L2740DW printers from Bullseye, whether
>> > the printer is auto-detected or manually added via ocalhost:631 or
>> > system-config-printer.
>
> Is there a facility to run a test print directly from the printer?  If so, 
> does that work?

Hello,

Yes, the printer prints test pages and reports from its own console, and 
documents via wifi from my iphone, but not from Debian.  Even 11.0 with 
non-updated cups.  Same issue with an identical printer on another network - 
that does print from Buster.  I half suspected a router problem, but same 
issues when Bullseye laptop and my printer are linked via iphone wifi hotspot.  
Same issue when my Bullseye laptop is linked via EE mobile broadband router 
(locally) to an identical printer (in another place, 10 miles away, so can't 
check for differences regularly).

After using system-config-printer to print a test page on an auto-detected 
driverless IPP profile, connected via 2.5GHz wifi to a router, to which the 
Bullseye laptop is connected via 5GHz wifi, I get no output, and:

$ lpstat -t
scheduler is running
no system default destination
device for Brother_MFC_L2740DW_series: 
implicitclass://Brother_MFC_L2740DW_series/
Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 13:12:54 BST
printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 2022 
13:12:54 BST
No suitable destination host found by cups-browsed.
Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 13:12:48 
BST

After changing laptop to 2.5GHz wifi...

$ lpstat -t
scheduler is running
no system default destination
device for Brother_MFC_L2740DW_series: 
implicitclass://Brother_MFC_L2740DW_series/
Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 13:14:40 BST
printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 2022 
13:14:40 BST
Printer disappeared or cups-browsed shutdown
Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 13:12:48 
BST

$ sudo systemctl status cups-browsed
[sudo] password for user: 
● cups-browsed.service - Make remote CUPS printers available locally
 Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor >
 Active: active (running) since Mon 2022-06-06 13:04:25 BST; 11min ago
   Main PID: 1666 (cups-browsed)
  Tasks: 3 (limit: 14146)
 Memory: 3.8M
CPU: 209ms
 CGroup: /system.slice/cups-browsed.service
 └─1666 /usr/sbin/cups-browsed

Jun 06 13:04:25 qwerty systemd[1]: Started Make remote CUPS printers available >

*I deleted 5GHz wifi profile from Network Manager Edit Connections*
$ sudo reboot

$ sudo systemctl status cups-browsed
[sudo] password for user: 
● cups-browsed.service - Make remote CUPS printers available locally
 Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor >
 Active: active (running) since Mon 2022-06-06 13:27:27 BST; 3min 13s ago
   Main PID: 2059 (cups-browsed)
  Tasks: 3 (limit: 14146)
 Memory: 2.9M
CPU: 100ms
 CGroup: /system.slice/cups-browsed.service
 └─2059 /usr/sbin/cups-browsed

Jun 06 13:27:27 qwerty systemd[1]: Started Make remote CUPS printers available >
lines 1-11/11 (END)


$ lpstat -t
scheduler is running
no system default destination
device for Brother_MFC_L2740DW_series: 
implicitclass://Brother_MFC_L2740DW_series/
Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 13:27:46 BST
printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 2022 
13:27:46 BST
Printer disappeared or cups-browsed shutdown
Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 13:12:48 
BST

*Turned printer off and on again*

$ lpstat -t
scheduler is running
no system default destination
device for Brother_MFC_L2740DW_series: 
implicitclass://Brother_MFC_L2740DW_series/
Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 13:31:39 BST
printer Brother_MFC_L2740DW_series now printing Brother_MFC_L2740DW_series-6.  
enabled since Mon 06 Jun 2022 13:31:39 BST
Waiting for job to complete.
Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 13:12:48 
BST


$ lpstat -t
scheduler is running
no system default destination
device for Brother_MFC_L2740DW_series: 
implicitclass://Brother_MFC_L2740DW_series/
Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 13:32:06 BST
printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 2022 
13:32:06 BST

But nothing printed.

/var/log/cups/erro

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

CUPS error log excerpt attached.
G


On Mon  6 Jun 2022, at 14:02, Gareth Evans  wrote:
> On Mon  6 Jun 2022, at 13:05, rhkra...@gmail.com wrote:
>> On Monday, June 06, 2022 07:34:07 AM Gareth Evans wrote:
>>> On Mon  6 Jun 2022, at 12:19, Gareth Evans  wrote:
>>> > I have a strange printing problem which can be replicated on two
>>> > identical printers on two different networks, when printing to wireless
>>> > driverless IPP with Brother MFC-L2740DW printers from Bullseye, whether
>>> > the printer is auto-detected or manually added via ocalhost:631 or
>>> > system-config-printer.
>>
>> Is there a facility to run a test print directly from the printer?  If so, 
>> does that work?
>
> Hello,
>
> Yes, the printer prints test pages and reports from its own console, 
> and documents via wifi from my iphone, but not from Debian.  Even 11.0 
> with non-updated cups.  Same issue with an identical printer on another 
> network - that does print from Buster.  I half suspected a router 
> problem, but same issues when Bullseye laptop and my printer are linked 
> via iphone wifi hotspot.  Same issue when my Bullseye laptop is linked 
> via EE mobile broadband router (locally) to an identical printer (in 
> another place, 10 miles away, so can't check for differences regularly).
>
> After using system-config-printer to print a test page on an 
> auto-detected driverless IPP profile, connected via 2.5GHz wifi to a 
> router, to which the Bullseye laptop is connected via 5GHz wifi, I get 
> no output, and:
>
> $ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_MFC_L2740DW_series: 
> implicitclass://Brother_MFC_L2740DW_series/
> Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 
> 13:12:54 BST
> printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 
> 2022 13:12:54 BST
>   No suitable destination host found by cups-browsed.
> Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 
> 13:12:48 BST
>
> After changing laptop to 2.5GHz wifi...
>
> $ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_MFC_L2740DW_series: 
> implicitclass://Brother_MFC_L2740DW_series/
> Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 
> 13:14:40 BST
> printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 
> 2022 13:14:40 BST
>   Printer disappeared or cups-browsed shutdown
> Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 
> 13:12:48 BST
>
> $ sudo systemctl status cups-browsed
> [sudo] password for user: 
> ● cups-browsed.service - Make remote CUPS printers available locally
>  Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; 
> vendor >
>  Active: active (running) since Mon 2022-06-06 13:04:25 BST; 11min ago
>Main PID: 1666 (cups-browsed)
>   Tasks: 3 (limit: 14146)
>  Memory: 3.8M
> CPU: 209ms
>  CGroup: /system.slice/cups-browsed.service
>  └─1666 /usr/sbin/cups-browsed
>
> Jun 06 13:04:25 qwerty systemd[1]: Started Make remote CUPS printers 
> available >
>
> *I deleted 5GHz wifi profile from Network Manager Edit Connections*
> $ sudo reboot
>
> $ sudo systemctl status cups-browsed
> [sudo] password for user: 
> ● cups-browsed.service - Make remote CUPS printers available locally
>  Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; 
> vendor >
>  Active: active (running) since Mon 2022-06-06 13:27:27 BST; 3min 13s ago
>Main PID: 2059 (cups-browsed)
>   Tasks: 3 (limit: 14146)
>  Memory: 2.9M
> CPU: 100ms
>  CGroup: /system.slice/cups-browsed.service
>  └─2059 /usr/sbin/cups-browsed
>
> Jun 06 13:27:27 qwerty systemd[1]: Started Make remote CUPS printers 
> available >
> lines 1-11/11 (END)
>
>
> $ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_MFC_L2740DW_series: 
> implicitclass://Brother_MFC_L2740DW_series/
> Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 
> 13:27:46 BST
> printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 
> 2022 13:27:46 BST
>   Printer disappeared or cups-browsed shutdown
> Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 
> 13:12:48 BST
>
> *Turned printer off and on again*
>
> $ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_MFC_L2740DW_series: 
> implicitclass://Brother_MFC_L2740DW_series/
> Brother_MFC_L2740DW_series accepting requests s

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

On Mon  6 Jun 2022, at 14:14, Eduardo M KALINOWSKI  
wrote:
> On 06/06/2022 08:19, Gareth Evans wrote:
>> Hello,
>> 
>> I have a strange printing problem which can be replicated on two identical 
>> printers on two different networks, when printing to wireless driverless IPP 
>> with Brother MFC-L2740DW printers from Bullseye, whether the printer is 
>> auto-detected or manually added via ocalhost:631 or system-config-printer.
>
> I have this exact printer. Driverless printing works, but not with the 
> automatically generated entry included by cups-browsed (or some other 
> package), i have to manually add a printer queue using
>
> # lpinfo -v
>
> to get a list of URLs (the one starting with ipp:// is the one 
> necessary), and then something like
>
> # lpadmin -p Brother2740 -v IPP_URL_FROM_ABOVE -E -m everywhere
>
>

That worked, and it's now printing normally after reboot via the added profile, 
thank you Eduardo.  

Not sure what's happened though as it worked perfectly with both auto-detected 
and manually-added printer profiles from Bullseye until a week or two ago.  My 
logs suggest no update to system-config-printer.  I did change the printer's 
hostname (on printer console) but both the printer and laptop have been 
restarted several times since then, printers re-added and re-auto-detected etc.

HTTP_STATE_WAITING Closing for error 32 (Broken pipe)

- appears in the error log for jobs it is now actually printing, so that seems 
to be unrelated.

I don't like it when things stop working without explanation.  

Why should adding via the command line work, but not via system-config-printer 
or localhost:631?

Any further debugging tips would be appreciated.

Thanks,
Gareth



> -- 
> BOFH excuse #201:
>
> RPC_PMAP_FAILURE
>
> Eduardo M KALINOWSKI
> edua...@kalinowski.com.br

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

Recent message with screenshots didn't get through (at least yet) - text below, 
plus another observation.

On Mon  6 Jun 2022, at 16:53, Gareth Evans  wrote:
> On Mon  6 Jun 2022, at 16:23, Eduardo M KALINOWSKI 
>  wrote:
>> On 06/06/2022 10:48, Gareth Evans wrote:
>>> Not sure what's happened though as it worked perfectly with both 
>>> auto-detected and manually-added printer profiles from Bullseye until a 
>>> week or two ago.  My logs suggest no update to system-config-printer.  I 
>>> did change the printer's hostname (on printer console) but both the printer 
>>> and laptop have been restarted several times since then, printers re-added 
>>> and re-auto-detected etc.
>>
>> In my case it never worked any other way. But I never dug very deep to 
>> try to find out why.
>>
>>> Why should adding via the command line work, but not via 
>>> system-config-printer or localhost:631?
>>
>> I guess adding it in CUPS web interface (localhost:631) should work, if 
>> the exact same parameters are selected: the ipp:// url and the "CUPS PPD 
>> generator" (selected by "-m everywhere" option) as opposed to 
>> "cups-filters PPD generator".
>>
>> That might be the explanation (at least for my case). From what I 
>> understand from https://wiki.debian.org/CUPSDriverlessPrinting , there 
>> are those two options, and "The cups-filters PPD generator is used by 
>> default with cups-browsed". In theory either should work, but there's 
>> probably some quirk in the printer and some small difference between the 
>> two methods.
>>
>> -- 
>> Tchurin-tchurin-tchun-clain!
>>
>> -- Chapolim
>>
>> Eduardo M KALINOWSKI
>> edua...@kalinowski.com.br
>
> When adding a printer with system-config-printer, it is detected and 
> listed under "Network Printer" in the list (when expanded) (twice).  I 
> currently see what's in the screenshots attached, but sometimes the 
> "IPP network printer via DNS-SD" connection option changes to something 
> involving AppSocket/... at the beginning.  
>
> There seem to be different connections available at different times.
>
> Any ideas why that should be?
>
> It seems to me that something has changed.  Given the problem was the 
> same with an identical printer on a different network, I guess it's 
> something to do with CUPS (or its config) rather than the printer 
> itself misbehaving.  I had factory-reset it a couple of days ago.
>
> Thanks,
> Gareth
>
>
> Attachments:
> * Screenshot at 2022-06-06 16-39-52.png
> * Screenshot at 2022-06-06 16-40-03.png

$ driverless list
DEBUG: Started ippfind (PID 95003)
"driverless:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" en "Brother" 
"Brother MFC-L2740DW series, driverless, cups-filters 1.28.7" 
"MFG:Brother;MDL:MFC-L2740DW series;CMD:PWGRaster,AppleRaster,URF,PWG;"
"driverless-fax:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" en 
"Brother" "Brother MFC-L2740DW series, Fax, driverless, cups-filters 1.28.7" 
"MFG:Brother;MDL:MFC-L2740DW series;CMD:PWGRaster,AppleRaster,URF,PWG;"
DEBUG: ippfind (PID 95003) exited with no errors.

The error log except attached earlier includes:

[line no] log text
[30] D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-is-accepting-jobs boolean 
true
D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state enum idle
D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state-reasons keyword none
D [06/Jun/2022:13:32:04 +0100] [Job 6]  end-of-attributes-tag 
D [06/Jun/2022:13:32:04 +0100] [Job 6] IPP/2.0 Get-Job-Attributes #22
D [06/Jun/2022:13:32:04 +0100] [Job 6]  operation-attributes-tag 
D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-charset charset utf-8
D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-natural-language 
naturalLanguage en-gb
D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-uri uri 
ipp://mfcl2740dw.local:631/ipp/faxout

  ^^

   Fax

D [06/Jun/2022:13:32:04 +0100] [Job 6] job-id integer 82

D [06/Jun/2022:13:32:04 +0100] [Job 6]  unsupported-attributes-tag 
D [06/Jun/2022:13:32:04 +0100] [Job 6] requested-attributes keyword 
job-media-sheets-completed
D [06/Jun/2022:13:32:04 +0100] [Job 6]  job-attributes-tag 
D [06/Jun/2022:13:32:04 +0100] [Job 6] job-id integer 82
D [06/Jun/2022:13:32:04 +0100] [Job 6] job-impressions-completed integer 0
D [06/Jun/2022:13:32:04 +0100] [Job 6] job-name nameWithoutLanguage Test Page
D [06/Jun/2022:13:3

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

On Mon  6 Jun 2022, at 17:45, Gareth Evans  wrote:
> Recent message with screenshots didn't get through (at least yet) - 
> text below, plus another observation.
>
> On Mon  6 Jun 2022, at 16:53, Gareth Evans  wrote:
>> On Mon  6 Jun 2022, at 16:23, Eduardo M KALINOWSKI 
>>  wrote:
>>> On 06/06/2022 10:48, Gareth Evans wrote:
>>>> Not sure what's happened though as it worked perfectly with both 
>>>> auto-detected and manually-added printer profiles from Bullseye until a 
>>>> week or two ago.  My logs suggest no update to system-config-printer.  I 
>>>> did change the printer's hostname (on printer console) but both the 
>>>> printer and laptop have been restarted several times since then, printers 
>>>> re-added and re-auto-detected etc.
>>>
>>> In my case it never worked any other way. But I never dug very deep to 
>>> try to find out why.
>>>
>>>> Why should adding via the command line work, but not via 
>>>> system-config-printer or localhost:631?
>>>
>>> I guess adding it in CUPS web interface (localhost:631) should work, if 
>>> the exact same parameters are selected: the ipp:// url and the "CUPS PPD 
>>> generator" (selected by "-m everywhere" option) as opposed to 
>>> "cups-filters PPD generator".
>>>
>>> That might be the explanation (at least for my case). From what I 
>>> understand from https://wiki.debian.org/CUPSDriverlessPrinting , there 
>>> are those two options, and "The cups-filters PPD generator is used by 
>>> default with cups-browsed". In theory either should work, but there's 
>>> probably some quirk in the printer and some small difference between the 
>>> two methods.
>>>
>>> -- 
>>> Tchurin-tchurin-tchun-clain!
>>>
>>> -- Chapolim
>>>
>>> Eduardo M KALINOWSKI
>>> edua...@kalinowski.com.br
>>
>> When adding a printer with system-config-printer, it is detected and 
>> listed under "Network Printer" in the list (when expanded) (twice).  I 
>> currently see what's in the screenshots attached, but sometimes the 
>> "IPP network printer via DNS-SD" connection option changes to something 
>> involving AppSocket/... at the beginning.  
>>
>> There seem to be different connections available at different times.
>>
>> Any ideas why that should be?
>>
>> It seems to me that something has changed.  Given the problem was the 
>> same with an identical printer on a different network, I guess it's 
>> something to do with CUPS (or its config) rather than the printer 
>> itself misbehaving.  I had factory-reset it a couple of days ago.
>>
>> Thanks,
>> Gareth
>>
>>
>> Attachments:
>> * Screenshot at 2022-06-06 16-39-52.png
>> * Screenshot at 2022-06-06 16-40-03.png
>
> $ driverless list
> DEBUG: Started ippfind (PID 95003)
> "driverless:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" en 
> "Brother" "Brother MFC-L2740DW series, driverless, cups-filters 1.28.7" 
> "MFG:Brother;MDL:MFC-L2740DW series;CMD:PWGRaster,AppleRaster,URF,PWG;"
> "driverless-fax:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" 
> en "Brother" "Brother MFC-L2740DW series, Fax, driverless, cups-filters 
> 1.28.7" "MFG:Brother;MDL:MFC-L2740DW 
> series;CMD:PWGRaster,AppleRaster,URF,PWG;"
> DEBUG: ippfind (PID 95003) exited with no errors.
>
> The error log except attached earlier includes:
>
> [line no] log text
> [30] D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-is-accepting-jobs 
> boolean true
> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state enum idle
> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state-reasons keyword 
> none
> D [06/Jun/2022:13:32:04 +0100] [Job 6]  end-of-attributes-tag 
> D [06/Jun/2022:13:32:04 +0100] [Job 6] IPP/2.0 Get-Job-Attributes #22
> D [06/Jun/2022:13:32:04 +0100] [Job 6]  operation-attributes-tag 
> 
> D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-charset charset utf-8
> D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-natural-language 
> naturalLanguage en-gb
> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-uri uri 
> ipp://mfcl2740dw.local:631/ipp/faxout
> 
>   ^^
> 
>Fax
>
> D [06/Jun/2022:13:32:04 +01

Re: non installed printer can not be removed

[Gareth Evans]

On Thu 16 Jun 2022, at 22:13, Hans  wrote:
> Hi folks,
>
> I am struggeling with a little problem, I can not explain. 
>
> A friend of mine uses a printer (Samsung SL-C480FW), which is connected to 
> the 
> router with wireless. However, although there are no drivers and no ppd-files 
> installed, the printer is seen by cups (and also by system-printer-config) 
> but 
> can not be used (think, because the missing ppd-file).
>
> When this is installed, udev-entries and so on are set, then the printer is 
> seen for example with ipp://192.168.*.*. 
>
> However, printing does not work, although the printer gets data, but then 
> hangs. I believe, this is a driver problem (because this appeared, since my 
> friend got a new router (FritzBox).
>
> I hope, for this I will find a solution, so hints are welcome, buut not the 
> reason for this thread.
>
> Much more I am interested, to know, why I can not delete the printer in CUPS 
> or system-config-printer? Any printer I add, can be deleted, but the last 
> entry can not be deleted. 
>
> What is wrong? Why does the kernel see the correct printer, and where does it 
> get its information? It is not connected at the USB-port, so no information 
> could be taken from this.
>
> Any ideas?
>
> Thanks for any help!
>
> Best regards
>
> Hans

Various sources (but not HP documentation afaics) suggest this printer is 
airprint-compatible.

https://www.amazon.co.uk/Samsung-C480FW-Colour-Multifunction-Printer/dp/B010NE2HKI

https://productz.com/en/samsung-xpress-sl-c480fw/p/wxnG7

If so, I would suggest "cannot delete" = continuous autodetection.

What is the output of

$ driverless

As for not actually being able to print, I have a problem like that too which 
has only recently emerged with an airprint printer which worked until recently.

You might find you can print (as I do) if you add a queue via lpadmin.  

As helped me recently:

"# lpinfo -v

to get a list of URLs (the one starting with ipp:// is the one 
necessary), and then something like

# lpadmin -p Brother2740 -v IPP_URL_FROM_ABOVE -E -m everywhere"

https://lists.debian.org/debian-user/2022/06/msg00212.html

Re: non installed printer can not be removed

[Gareth Evans]




> On 17 Jun 2022, at 01:56, Gareth Evans  wrote:
> On Thu 16 Jun 2022, at 22:13, Hans  wrote:
>> Hi folks,
>> 
>> I am struggeling with a little problem, I can not explain. 
>> 
>> A friend of mine uses a printer (Samsung SL-C480FW), which is connected to 
>> the 
>> router with wireless. However, although there are no drivers and no 
>> ppd-files 
>> installed, the printer is seen by cups (and also by system-printer-config) 
>> but 
>> can not be used (think, because the missing ppd-file).
>> 
>> When this is installed, udev-entries and so on are set, then the printer is 
>> seen for example with ipp://192.168.*.*. 
>> 
>> However, printing does not work, although the printer gets data, but then 
>> hangs. I believe, this is a driver problem (because this appeared, since my 
>> friend got a new router (FritzBox).
>> 
>> I hope, for this I will find a solution, so hints are welcome, buut not the 
>> reason for this thread.
>> 
>> Much more I am interested, to know, why I can not delete the printer in CUPS 
>> or system-config-printer? Any printer I add, can be deleted, but the last 
>> entry can not be deleted. 
>> 
>> What is wrong? Why does the kernel see the correct printer, and where does 
>> it 
>> get its information? It is not connected at the USB-port, so no information 
>> could be taken from this.
>> 
>> Any ideas?
>> 
>> Thanks for any help!
>> 
>> Best regards
>> 
>> Hans
> 
> Various sources (but not HP documentation afaics) suggest this printer is 
> airprint-compatible.
> 
> https://www.amazon.co.uk/Samsung-C480FW-Colour-Multifunction-Printer/dp/B010NE2HKI
> 
> https://productz.com/en/samsung-xpress-sl-c480fw/p/wxnG7
> 
> If so, I would suggest "cannot delete" = continuous autodetection.
> 
> What is the output of
> 
> $ driverless
> 
> As for not actually being able to print, I have a problem like that too which 
> has only recently emerged with an airprint printer which worked until 
> recently.
> 
> You might find you can print (as I do) if you add a queue via lpadmin.  
> 
> As helped me recently:
> 
> "# lpinfo -v
> 
> to get a list of URLs (the one starting with ipp:// is the one 
> necessary), and then something like
> 
> # lpadmin -p Brother2740 -v IPP_URL_FROM_ABOVE -E -m everywhere"
> 
> https://lists.debian.org/debian-user/2022/06/msg00212.html
> 

Can anyone with a fax-capable MFP confirm that driverless autodetected printing 
works with CUPS on Debian 11 with the latest stable CUPS version?

My debug-enabled cups error log includes the following, which makes me wonder 
if it's being identified correctly:

Does this suggest it's being detected as (only) a fax?  (Though this relates to 
a queue manually added with system-config-printer as nothing is autodetected)

D [17/Jun/2022:00:47:45 +0100] [Job 36] Resolving \"Brother MFC-L2740DW 
series\", regtype=\"_ipp._tcp\", domain=\"local.\"...
D [17/Jun/2022:00:47:45 +0100] [Notifier] state=3
D [17/Jun/2022:00:47:45 +0100] [Notifier] PrinterStateChanged
D [17/Jun/2022:00:47:45 +0100] [Job 36] Color Manager: Calibration Mode/Off
D [17/Jun/2022:00:47:45 +0100] [Job 36] PID 2953512 
(/usr/lib/cups/filter/bannertopdf) exited with no errors.
D [17/Jun/2022:00:47:45 +0100] [Job 36] Calling 
FindDeviceById(cups-MFC-L2740DW_DLIPP)
D [17/Jun/2022:00:47:45 +0100] [Job 36] Found device 
/org/freedesktop/ColorManager/devices/cups_MFC_L2740DW_DLIPP
D [17/Jun/2022:00:47:45 +0100] [Job 36] Calling 
org.freedesktop.ColorManager.Device.Get(ProfilingInhibitors)
D [17/Jun/2022:00:47:45 +0100] [Job 36] Calling 
FindDeviceById(cups-MFC-L2740DW_DLIPP)
D [17/Jun/2022:00:47:45 +0100] [Job 36] Found device 
/org/freedesktop/ColorManager/devices/cups_MFC_L2740DW_DLIPP
D [17/Jun/2022:00:47:45 +0100] [Job 36] Calling 
GetProfileForQualifiers(Gray.Stationery.600dpi...)
D [17/Jun/2022:00:47:45 +0100] [Job 36] Found profile 
/org/freedesktop/ColorManager/profiles/MFC_L2740DW_DLIPP_Gray__
D [17/Jun/2022:00:47:45 +0100] [Job 36] Calling 
org.freedesktop.ColorManager.Profile.Get(Filename)
D [17/Jun/2022:00:47:45 +0100] [Job 36] Resolved as 
\"ipp://mfcl2740dw.local:631/ipp/faxout\"...

system-config-printer refuses to persist changes to the driver for autodetected 
queues with previous cups versions which do autodetect it, hanging on to the 
version including "...fax, driverless...".

Thanks,
Gareth

Re: non installed printer can not be removed

[Gareth Evans]

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

On Mon  6 Jun 2022, at 20:03, Gareth Evans  wrote:
> On Mon  6 Jun 2022, at 17:45, Gareth Evans  wrote:
>> Recent message with screenshots didn't get through (at least yet) - 
>> text below, plus another observation.
>>
>> On Mon  6 Jun 2022, at 16:53, Gareth Evans  wrote:
>>> On Mon  6 Jun 2022, at 16:23, Eduardo M KALINOWSKI 
>>>  wrote:
>>>> On 06/06/2022 10:48, Gareth Evans wrote:
>>>>> Not sure what's happened though as it worked perfectly with both 
>>>>> auto-detected and manually-added printer profiles from Bullseye until a 
>>>>> week or two ago.  My logs suggest no update to system-config-printer.  I 
>>>>> did change the printer's hostname (on printer console) but both the 
>>>>> printer and laptop have been restarted several times since then, printers 
>>>>> re-added and re-auto-detected etc.
>>>>
>>>> In my case it never worked any other way. But I never dug very deep to 
>>>> try to find out why.
>>>>
>>>>> Why should adding via the command line work, but not via 
>>>>> system-config-printer or localhost:631?
>>>>
>>>> I guess adding it in CUPS web interface (localhost:631) should work, if 
>>>> the exact same parameters are selected: the ipp:// url and the "CUPS PPD 
>>>> generator" (selected by "-m everywhere" option) as opposed to 
>>>> "cups-filters PPD generator".
>>>>
>>>> That might be the explanation (at least for my case). From what I 
>>>> understand from https://wiki.debian.org/CUPSDriverlessPrinting , there 
>>>> are those two options, and "The cups-filters PPD generator is used by 
>>>> default with cups-browsed". In theory either should work, but there's 
>>>> probably some quirk in the printer and some small difference between the 
>>>> two methods.
>>>>
>>>> -- 
>>>> Tchurin-tchurin-tchun-clain!
>>>>
>>>> -- Chapolim
>>>>
>>>> Eduardo M KALINOWSKI
>>>> edua...@kalinowski.com.br
>>>
>>> When adding a printer with system-config-printer, it is detected and 
>>> listed under "Network Printer" in the list (when expanded) (twice).  I 
>>> currently see what's in the screenshots attached, but sometimes the 
>>> "IPP network printer via DNS-SD" connection option changes to something 
>>> involving AppSocket/... at the beginning.  
>>>
>>> There seem to be different connections available at different times.
>>>
>>> Any ideas why that should be?
>>>
>>> It seems to me that something has changed.  Given the problem was the 
>>> same with an identical printer on a different network, I guess it's 
>>> something to do with CUPS (or its config) rather than the printer 
>>> itself misbehaving.  I had factory-reset it a couple of days ago.
>>>
>>> Thanks,
>>> Gareth
>>>
>>>
>>> Attachments:
>>> * Screenshot at 2022-06-06 16-39-52.png
>>> * Screenshot at 2022-06-06 16-40-03.png
>>
>> $ driverless list
>> DEBUG: Started ippfind (PID 95003)
>> "driverless:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" en 
>> "Brother" "Brother MFC-L2740DW series, driverless, cups-filters 1.28.7" 
>> "MFG:Brother;MDL:MFC-L2740DW series;CMD:PWGRaster,AppleRaster,URF,PWG;"
>> "driverless-fax:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" 
>> en "Brother" "Brother MFC-L2740DW series, Fax, driverless, cups-filters 
>> 1.28.7" "MFG:Brother;MDL:MFC-L2740DW 
>> series;CMD:PWGRaster,AppleRaster,URF,PWG;"
>> DEBUG: ippfind (PID 95003) exited with no errors.
>>
>> The error log except attached earlier includes:
>>
>> [line no] log text
>> [30] D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-is-accepting-jobs 
>> boolean true
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state enum idle
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state-reasons keyword 
>> none
>> D [06/Jun/2022:13:32:04 +0100] [Job 6]  end-of-attributes-tag 
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] IPP/2.0 Get-Job-Attributes #22
>> D [06/Jun/2022:13:32:04 +0100] [Job 6]  operation-attributes-tag 
>> 
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-charset charset utf-8
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-natural-la

debian-user message size limit

[Gareth Evans]

Is there a limit for message size on debian-user?

I can't find any such info on

https://lists.debian.org/

https://www.debian.org/MailingLists/

https://lists.debian.org/debian-user/

but a couple of recent large-ish messages (one ~270K with two screenshots, one 
70K with log output) have neither got through nor bounced back.

It would be helpful to know what it is if there is one.

Thanks,
Gareth

Re: debian-user message size limit

[Gareth Evans]

> On 17 Jun 2022, at 17:51, Nicolas George  wrote:
> 
> Gareth Evans (12022-06-17):
>> but a couple of recent large-ish messages (one ~270K with two
>> screenshots, one 70K with log output) have neither got through nor
>> bounced back.
> 
> “Avoid sending large attachments.”
> 
> https://www.debian.org/MailingLists/
> 
> This is not specific to Debian, most Libre Software mailing-list I know
> have a similar policy. It is inefficient and annoying for recipients.
> Put your screenshots on some transient hosting site.
> 
> Regards,
> 
> -- 
>  Nicolas George
> 

Thank you both - I'll try that next time.
Gareth

Re: debian-user message size limit

[Gareth Evans]

On Fri 17 Jun 2022, at 20:00, Brian  wrote:
> On Fri 17 Jun 2022 at 16:24:54 +0100, Gareth Evans wrote:
>
>> Is there a limit for message size on debian-user?
>> 
>> I can't find any such info on
>> 
>> https://lists.debian.org/
>> 
>> https://www.debian.org/MailingLists/
>> 
>> https://lists.debian.org/debian-user/
>> 
>> but a couple of recent large-ish messages (one ~270K with two
>> screenshots, one 70K with log output) have neither got through nor
>> bounced back.
>> 
>> It would be helpful to know what it is if there is one.
>
> Don't expect Listmaster to rush here and tell us :),
>
> According to mutt, one of the mails you sent earlier today is 70K
> in size:
>
>   https://lists.debian.org/debian-user/2022/06/msg00586.html
>
> Do you hear anyone complaining? You did not. The bandwidth usage is
> low and time to download it is minuscule. The wheels are greased in
> -user.
>
> However, you cheated and put a log file inline. Naughty :). Good
> sense reigns in -user, however, so no one begrudges it.
>

> You know that attachments of ~270K and 70K do not get through. 

For the record, I had thought the log excerpts in the 70K email were likely to 
be just about acceptable inline - there was no attempt to send a ~70K 
attachment.  Perhaps there should (or shouldn't) have been.  I would find it 
difficult to consider 70K "large".  With no guidance on the issues in eg 
monthly FAQ, this creates ambiguity and uncertainty.

There was quite a delay in both the 70K email and the message size limit 
question getting back to me, such that I thought both may have been dropped or 
held - first the former, hence the latter, and then still an unusually long 
wait.  But such is email sometimes.

The lack of dropped/held feedback [1] (if messages even are held) along with 
ambiguity around message/attachment sizes, makes it difficult to judge what to 
do and when, if anything.

Best wishes,
Gareth

[1] "Another known limitation in our mailing list software is that most 
rejected e-mails get silently dropped, so the user has no real indication on 
what went wrong."
https://www.debian.org/MailingLists/


> Try
> ~50K next time and be aware that compression with gzip or xz is a
> option. Text files compress well.
>
> If 50K is rejected, no harm is done. Try again to find the upper
> limit.
>
> Attacments to a mailing list like -user are an efficient us of its
> services. Ephemeral info on other sites isn't of any value to users
> in the future.
>
> -- 
> Brian.

Re: debian-user message size limit

[Gareth Evans]

> On 17 Jun 2022, at 23:25, Bijan Soleymani  wrote:
> 
> On 2022-06-17 18:20, Bijan Soleymani wrote:
>>> On 2022-06-17 11:24, Gareth Evans wrote:
>>> Is there a limit for message size on debian-user?
>> I checked the data. I have been subscribed since 2003, though I
>> haven't been active for a lot of that period.
> 
> Actually I didn't store the emails from some point in 2004 through part of 
> 2008.
> 
> So I can't say when the limit was lowered but at least from 2009 until now 
> there hasn't been anything over 101KB (103,424 bytes).
> 
> Bijan
> 

Thanks for taking the time and effort to do that and letting us know.
G

Re: non installed printer can not be removed

[Gareth Evans]

> On 19 Jun 2022, at 13:56, gene heskett  wrote:
> 
> On 6/18/22 05:54, Hans wrote:
>> Hi Brian,
>> 
>>> You were expected to execute 'lpinfo -v' and give us the output. We
>>> also expect the result of 'driverless'.
>> this is difficult, as the computer is 600km away from me and I have no access
>> to it at the moment.>
>> 
>>> Put the URI in double quotes.
>> I will try it, next time, I get access to the computer.
>> 
>>> It is not a rights problem. No user needs to be in group lp. It is a
>>> security risk. Take them out of it.
>> Ok, I will do it.
>> 
 Any other ideas?
>>> The present ideas are good enough :).
>> Yeah, thanks a lot, and I will try it again. Meanwhile I sent another mail,
>> but I suppose, it does also not much help.
>> 
>> Anyway, I will do as you advised next time I get access to the computer.
>> 
>> Best regards and a happy weekend!
>> 
>> Hans
> Looks like I should have replied to you Hans, see my reply to Gareth..
> 
> Cheers, Gene Heskett.
> -- 
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> 

Hi Gene,

I had (and still have) a feeling that Hans and I might have at least partly the 
same CUPS-related (or possibly router-related) problem with our printers, both 
of which are fax- and scan-capable MFDs, though his is a Samsung.

I used the Brother drivers with occasional hiccups on Ubuntu until 2019.  I 
then switched to Buster and (having been oblivious to it on Ubuntu, if it 
existed there then) found driverless printing suited my needs, though the 
Brother drivers do offer more options.

I can print to driverless queues created with lpadmin, though why not to 
driverless queues created by other means or autodetected is mystifying.

Many thanks anyway for your suggestion.

Best wishes,
Gareth

Re: non installed printer can not be removed

[Gareth Evans]

On Sun 19 Jun 2022, at 23:01, The Wanderer  wrote:
> On 2022-06-19 at 15:47, Brian wrote:
>
>> On Sun 19 Jun 2022 at 14:54:58 -0400, The Wanderer wrote:
>> 
>>> On 2022-06-19 at 14:50, Brian wrote:
>
 What does being "precious" involve?
>>> 
>>> I'm less certain about this, but my guess is that it means that
>>> CUPS insists on having these detected printers listed as available,
>>> rather than permitting them to be deleted from the list of
>>> available printers and having them remain that way.
>> 
>> You (or the OP) would have to say what is meant by "delete". CUPS
>> essentially *discover* printers. It is why it exists. Is that not
>> wanted?
>
> I understand the reason for CUPS' existence to be, not *discovering
> printers*, but *facilitating the ability to print*. That could involve
> discovering printers and presenting them as available, or it could
> involve only presenting as available a list of printers that have been
> entered into CUPS or otherwise set up in CUPS by some more manual means.
> (Among perhaps other possibilities.)
>
> Certainly at my workplace I understand that our Macs use CUPS for
> (network) printing, but at least at one point in our history (within the
> past decade), we had to go in and define each printer by IP address in
> CUPS on each Mac (or on the central machine which would be replicated to
> the others).
>

> I can certainly see it as being reasonable to want to be able to have
> CUPS perform printer discovery *on request*, and manually choose which
> of the discovered printers to add to the list of ones that will be
> remembered and shown as available when printing, but not have CUPS run
> discovery *automatically* and *automatically* add every discovered
> printer to that list. (I don't know with any confidence whether CUPS
> does the latter; I don't run it in enough environments with enough
> different available printers to have been able to make an assessment.
> However, I do have the impression that it may.)

I think /etc/apt/cups-browsed.conf provides flexibility here - notes explain 
the options but not what the defaults are. Having purged and reinstalled in my 
case, all lines in this file are comments.

man cups-browsed isn't helpful in that respect either.

Gareth

>
> -- 
>The Wanderer
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard Shaw
>
>
> Attachments:
> * signature.asc

Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[Gareth Evans]

On Mon 20 Jun 2022, at 17:34, The Wanderer  wrote:
> On 2022-06-20 at 12:01, Brian wrote:
>
>> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote:
>> 
>>> On 2022-06-20 at 08:59, Brian wrote:
>
 The ability to print to an IPP printer involves discovering its
 URI. CUPS gets the URI via avahi-daemon whether it is an
 on-demand or manual queue.
>>> 
>>> But that discovery doesn't have to be done by CUPS; once the URI is
>>> known, it should be possible for CUPS to simply accept the URI and
>>> work with it from then on, without discovery entering into the
>>> picture.
>> 
>> "...once the URIis known"? What mechaism does that? Incidentally, a
>> URI is required to query a printer for its attributes.
>
> Any of a number of mechanisms.
>
> CUPS could run discovery once, then either A: present the discovered URI
> with a prompt for whether to add it to its local list of known printers
> or B: add it to that list automatically, and then in either case not run
> discovery again until something asks it to.
>
> The user could run discovery manually (e.g. from the command line), then
> enter the discovered URI into CUPS.
>
> The user could look at another computer where the URI is already present
> in CUPS, and copy that across to the computer at hand.
>
> I could probably come up with more options if I thought about it for
> long enough.
>
 Setting up a  manual queue for a moden printer is still available
 but is unnecessary. 'lpstat -e' showves every printer on a subnet
 and they should (barring bugs) appear in an application's print
 dialog without any intervention.
>>> 
>>> The thing is, though, sometimes this is *undesirable*.
>> 
>> It is possible that upstream CUPS would agree. The intention is to
>> do something about it eventually.
>
> Depending on what the "something" is, that could be a very positive
> development!
>
>>> Going back to my workplace as an example, we have one subnet per
>>> building per floor, and one printer per classroom; we want the
>>> computers in each room to be able to see and print to the printer
>>> from that classroom, *only*. Having the ones from the other
>>> classrooms show up in the applications' print dialog would be a
>>> problem.
>> 
>> DNS-SD doesn't traverse subnets.
>
> Yes, but we don't have one subnet per classroom, we have one subnet per
> floor, with multiple classrooms per floor.
>
 You can control whether Avahi browses for printers or not but
 cannt make it selective in its browsing. DNS-SD is an
 all-or-nothing public service discovery protocol. Perhaps think
 of the display screens at airports.
>>> 
>>> That's just about discovery, though. I'm talking about what's done
>>> with the discovered information.
>>> 
>>> It sounds to me as if it's being said that CUPS takes the
>>> discovered information and automatically puts every discovered
>>> printer into the list of printers that will be made available in
>>> the print dialog (or equivalent).
>>> 
>>> That should not be the only option. It should also be possible to
>>> run discovery, manually select zero or more printers from the set
>>> discovered, and add *just those printers* to the list of those
>>> that will be shown in the print dialog
>>> 
>>> (It should also be possible to add printers to that list manually,
>>> without running discovery, if you know the necessary information.)
>> 
>> That's certainly possible at present.
>
> I figured, and seemed to recall, but did not want to assume.
>
>>> The result would be being able to be sure that the list of printers
>>> available in the print dialog will only change if someone manually
>>> modifies it, rather than changing automatically if the set of
>>> printers discoverable on the network changes.
>> 
>> Other would see the automatic change as a definite plus.
>
> And in some cases so would I! But not in others. And my interpretation
> of Gene's original complaint, as you quoted it, would suggest that he is
> in a case where he also would not.
>
> That's why whether or not this discovery-and-updating process is
> performed automatically should be *configurable*.
>
 I beleive filtering of a printer list using LDAP is something
 being considered for inclusion in a future CUPS.
>>> 
>>> Why should LDAP need to be involved? Unless you're using an
>>> external print server to get the printer list from (in which case
>>> things become in some ways simpler and in other ways considerably
>>> more complicated), the list of printers that applications should
>>> see is local, and should be able to be maintained locally without
>>> bringing external things such as LDAP into the picture.
>> 
>> My understanding of LDAP is very limited. All I know is that CUPS
>> will eshew simple filtering. It has been tried, and didn't work.
>
> I don't even know why filtering would be involved. You're not starting
> with a longer list and filtering it to show only a subset; you're
> starting with an empty list, populating it (either

Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[Gareth Evans]

On Mon 20 Jun 2022, at 23:31, Gareth Evans  wrote:
> On Mon 20 Jun 2022, at 17:34, The Wanderer  wrote:
>> On 2022-06-20 at 12:01, Brian wrote:
>>
>>> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote:
>>> 
>>>> On 2022-06-20 at 08:59, Brian wrote:
>>
>>>>> The ability to print to an IPP printer involves discovering its
>>>>> URI. CUPS gets the URI via avahi-daemon whether it is an
>>>>> on-demand or manual queue.
>>>> 
>>>> But that discovery doesn't have to be done by CUPS; once the URI is
>>>> known, it should be possible for CUPS to simply accept the URI and
>>>> work with it from then on, without discovery entering into the
>>>> picture.
>>> 
>>> "...once the URIis known"? What mechaism does that? Incidentally, a
>>> URI is required to query a printer for its attributes.
>>
>> Any of a number of mechanisms.
>>
>> CUPS could run discovery once, then either A: present the discovered URI
>> with a prompt for whether to add it to its local list of known printers
>> or B: add it to that list automatically, and then in either case not run
>> discovery again until something asks it to.
>>
>> The user could run discovery manually (e.g. from the command line), then
>> enter the discovered URI into CUPS.
>>
>> The user could look at another computer where the URI is already present
>> in CUPS, and copy that across to the computer at hand.
>>
>> I could probably come up with more options if I thought about it for
>> long enough.
>>
>>>>> Setting up a  manual queue for a moden printer is still available
>>>>> but is unnecessary. 'lpstat -e' showves every printer on a subnet
>>>>> and they should (barring bugs) appear in an application's print
>>>>> dialog without any intervention.
>>>> 
>>>> The thing is, though, sometimes this is *undesirable*.
>>> 
>>> It is possible that upstream CUPS would agree. The intention is to
>>> do something about it eventually.
>>
>> Depending on what the "something" is, that could be a very positive
>> development!
>>
>>>> Going back to my workplace as an example, we have one subnet per
>>>> building per floor, and one printer per classroom; we want the
>>>> computers in each room to be able to see and print to the printer
>>>> from that classroom, *only*. Having the ones from the other
>>>> classrooms show up in the applications' print dialog would be a
>>>> problem.
>>> 
>>> DNS-SD doesn't traverse subnets.
>>
>> Yes, but we don't have one subnet per classroom, we have one subnet per
>> floor, with multiple classrooms per floor.
>>
>>>>> You can control whether Avahi browses for printers or not but
>>>>> cannt make it selective in its browsing. DNS-SD is an
>>>>> all-or-nothing public service discovery protocol. Perhaps think
>>>>> of the display screens at airports.
>>>> 
>>>> That's just about discovery, though. I'm talking about what's done
>>>> with the discovered information.
>>>> 
>>>> It sounds to me as if it's being said that CUPS takes the
>>>> discovered information and automatically puts every discovered
>>>> printer into the list of printers that will be made available in
>>>> the print dialog (or equivalent).
>>>> 
>>>> That should not be the only option. It should also be possible to
>>>> run discovery, manually select zero or more printers from the set
>>>> discovered, and add *just those printers* to the list of those
>>>> that will be shown in the print dialog
>>>> 
>>>> (It should also be possible to add printers to that list manually,
>>>> without running discovery, if you know the necessary information.)
>>> 
>>> That's certainly possible at present.
>>
>> I figured, and seemed to recall, but did not want to assume.
>>
>>>> The result would be being able to be sure that the list of printers
>>>> available in the print dialog will only change if someone manually
>>>> modifies it, rather than changing automatically if the set of
>>>> printers discoverable on the network changes.
>>> 
>>> Other would see the automatic change as a definite plus.
>>
>> And in some cases so would I! But not in 

Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[Gareth Evans]

On Mon 20 Jun 2022, at 23:50, Gareth Evans  wrote:
> On Mon 20 Jun 2022, at 23:31, Gareth Evans  wrote:
>> On Mon 20 Jun 2022, at 17:34, The Wanderer  wrote:
>>> On 2022-06-20 at 12:01, Brian wrote:
>>>
>>>> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote:
>>>> 
>>>>> On 2022-06-20 at 08:59, Brian wrote:
>>>
>>>>>> The ability to print to an IPP printer involves discovering its
>>>>>> URI. CUPS gets the URI via avahi-daemon whether it is an
>>>>>> on-demand or manual queue.
>>>>> 
>>>>> But that discovery doesn't have to be done by CUPS; once the URI is
>>>>> known, it should be possible for CUPS to simply accept the URI and
>>>>> work with it from then on, without discovery entering into the
>>>>> picture.
>>>> 
>>>> "...once the URIis known"? What mechaism does that? Incidentally, a
>>>> URI is required to query a printer for its attributes.
>>>
>>> Any of a number of mechanisms.
>>>
>>> CUPS could run discovery once, then either A: present the discovered URI
>>> with a prompt for whether to add it to its local list of known printers
>>> or B: add it to that list automatically, and then in either case not run
>>> discovery again until something asks it to.
>>>
>>> The user could run discovery manually (e.g. from the command line), then
>>> enter the discovered URI into CUPS.
>>>
>>> The user could look at another computer where the URI is already present
>>> in CUPS, and copy that across to the computer at hand.
>>>
>>> I could probably come up with more options if I thought about it for
>>> long enough.
>>>
>>>>>> Setting up a  manual queue for a moden printer is still available
>>>>>> but is unnecessary. 'lpstat -e' showves every printer on a subnet
>>>>>> and they should (barring bugs) appear in an application's print
>>>>>> dialog without any intervention.
>>>>> 
>>>>> The thing is, though, sometimes this is *undesirable*.
>>>> 
>>>> It is possible that upstream CUPS would agree. The intention is to
>>>> do something about it eventually.
>>>
>>> Depending on what the "something" is, that could be a very positive
>>> development!
>>>
>>>>> Going back to my workplace as an example, we have one subnet per
>>>>> building per floor, and one printer per classroom; we want the
>>>>> computers in each room to be able to see and print to the printer
>>>>> from that classroom, *only*. Having the ones from the other
>>>>> classrooms show up in the applications' print dialog would be a
>>>>> problem.
>>>> 
>>>> DNS-SD doesn't traverse subnets.
>>>
>>> Yes, but we don't have one subnet per classroom, we have one subnet per
>>> floor, with multiple classrooms per floor.
>>>
>>>>>> You can control whether Avahi browses for printers or not but
>>>>>> cannt make it selective in its browsing. DNS-SD is an
>>>>>> all-or-nothing public service discovery protocol. Perhaps think
>>>>>> of the display screens at airports.
>>>>> 
>>>>> That's just about discovery, though. I'm talking about what's done
>>>>> with the discovered information.
>>>>> 
>>>>> It sounds to me as if it's being said that CUPS takes the
>>>>> discovered information and automatically puts every discovered
>>>>> printer into the list of printers that will be made available in
>>>>> the print dialog (or equivalent).
>>>>> 
>>>>> That should not be the only option. It should also be possible to
>>>>> run discovery, manually select zero or more printers from the set
>>>>> discovered, and add *just those printers* to the list of those
>>>>> that will be shown in the print dialog
>>>>> 
>>>>> (It should also be possible to add printers to that list manually,
>>>>> without running discovery, if you know the necessary information.)
>>>> 
>>>> That's certainly possible at present.
>>>
>>> I figured, and seemed to recall, but did not want to assume.
>>>
>>>>> The result would be being able to be sur

Re: I *think* I found the apache2 docs, but it's in .html and Icannot get firefox to access it using "file:"+ /path/to/filedir

[Gareth Evans]

On Tue 21 Jun 2022, at 18:06, gene heskett  wrote:
> On 6/21/22 12:11, Andrew M.A. Cater wrote:
>> On Tue, Jun 21, 2022 at 11:55:56AM -0400, gene heskett wrote:
>>> Greetings all;
>>>
>>> So how am I supposed to read these installed docs?
>>>
>>> Thanks all.
>>>
>>> Cheers, Gene Heskett.
>>> -- 
>>> "There are four boxes to be used in defense of liberty:
>>>   soap, ballot, jury, and ammo. Please use in that order."
>>> -Ed Howdershelt (Author, 1940)
>>> If we desire respect for the law, we must first make the law respectable.
>>>   - Louis D. Brandeis
>>>
>> >From a web browser?
>>
>> file:///usr/share/doc/apache2-doc
>>
>> That's three slashes - file:// - two slashes - and then the filesystem path.
>>
>> Hope this helps, with every good wish, as ever,
>>
>> Andy Cater
> And that works, the third slash is new to me.
>

> So now the only thing I've changed from the default install is in 
> /etc/apache2/envvars
> for usr and grp to be www-data. But now it won't restart.
> journalctl -xe reports:
> Jun 21 12:46:16 coyote apachectl[286443]: AH00526: Syntax error on line 
> 63 of /etc/apache2/conf-enabled/security.conf:
> Jun 21 12:46:16 coyote apachectl[286443]: Invalid command 'Header', [...]

In my (unedited) version of that file:

[...]
61 # Requires mod_headers to be enabled.
62 #
63 #Header set X-Content-Type-Options: "nosniff"

If line 63 is required un-commented, then

$ sudo a2enmod headers
$ sudo systemctl restart apache2

should do the trick.

$ sudo apache2ctl -M

should then inlclude

"headers_module (shared)" 

which

https://httpd.apache.org/docs/current/mod/mod_headers.html

confirms is the identifier for mod_headers.

$ sudo a2dismod headers
$ sudo systemctl restart apache2
to disable, should that be desired.

Hope that helps.
Gareth



> perhaps misspelled or defined by a module not included in the server 
> configuration
> Jun 21 12:46:16 coyote apachectl[286440]: Action 'start' failed.
>
> It appears apache2 probably has it own mechanism for moving/linking stuff
> from mods-available to mods-enabled but makes no reference to the name 
> of that
> utility that I have found. Does it have a name? Or do I cobble up a 
> symlink in mc?
>
> Thanks Andy.
>> .
>
>
> Cheers, Gene Heskett.
> -- 
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis

Re: I *think* I found the apache2 docs, but it's in .html and Icannot getfirefox to access it using "file:"+ /path/to/filedir

[Gareth Evans]

On Tue 21 Jun 2022, at 20:16, gene heskett  wrote:
> On 6/21/22 14:09, Gareth Evans wrote:
>> On Tue 21 Jun 2022, at 18:06, gene heskett  wrote:
>>> On 6/21/22 12:11, Andrew M.A. Cater wrote:
>>>> On Tue, Jun 21, 2022 at 11:55:56AM -0400, gene heskett wrote:
>>>>> Greetings all;
>>>>>
>>>>> So how am I supposed to read these installed docs?
>>>>>
>>>>> Thanks all.
>>>>>
>>>>> Cheers, Gene Heskett.
>>>>> -- 
>>>>> "There are four boxes to be used in defense of liberty:
>>>>>soap, ballot, jury, and ammo. Please use in that order."
>>>>> -Ed Howdershelt (Author, 1940)
>>>>> If we desire respect for the law, we must first make the law respectable.
>>>>>- Louis D. Brandeis
>>>>>
>>>> >From a web browser?
>>>>
>>>> file:///usr/share/doc/apache2-doc
>>>>
>>>> That's three slashes - file:// - two slashes - and then the filesystem 
>>>> path.
>>>>
>>>> Hope this helps, with every good wish, as ever,
>>>>
>>>> Andy Cater
>>> And that works, the third slash is new to me.
>>>
>>> So now the only thing I've changed from the default install is in
>>> /etc/apache2/envvars
>>> for usr and grp to be www-data. But now it won't restart.
>>> journalctl -xe reports:
>>> Jun 21 12:46:16 coyote apachectl[286443]: AH00526: Syntax error on line
>>> 63 of /etc/apache2/conf-enabled/security.conf:
>>> Jun 21 12:46:16 coyote apachectl[286443]: Invalid command 'Header', [...]
>> In my (unedited) version of that file:
>>
>> [...]
>> 61 # Requires mod_headers to be enabled.
>> 62 #
>> 63 #Header set X-Content-Type-Options: "nosniff"
>>
>> If line 63 is required un-commented, then
>>
>> $ sudo a2enmod headers
>> $ sudo systemctl restart apache2
>>
>> should do the trick.
> After I found it with locate/ /usr/sbin is not in su's $PATH
> That fixed the error, and I uncommented the stanza in apache2.conf
> that points to the directory I want the server to access, and
> localhost:port# displays the default startup page ok.
>
> dig "my-site-name" returns the proper ipv4 address.

>   I just used the address:6309 and it worked. So I edited the
> address bar to use the registered name:6309 and hit F5,
> a couple times, and that works.

Do you see a page titled "Apache2 Debian Default Page" with the Debian logo?

If so it's probably configured in

/etc/apache2/sites-available/000-default.conf

or 

/etc/apache2/sites-available/default-ssl.conf for https version

as Debian uses name-based virtual hosts with a config file structure which does 
not correspond to the Apache docs afaics, and I can't find any Debian docs on 
the subject.

https://httpd.apache.org/docs/2.4/configuring.html
https://httpd.apache.org/docs/2.4/vhosts/

000-default is already enabled (though the other for https may not be) if 
you're seeing the page I referred to above.

$ sudo a2ensite filename (without .conf)

is the command you would use to enable an "available" configuration (which 
creates a symlink in ../sites-enabled), but you may find it easier just to edit 
the existing 000-default.conf file.  You can create another (or iirc just 
extend it) if you want to add other (domain-)name-based sites in future.

* in the virtualhost tag as in "*:portNo" means "all domains", so these would 
need to be specified if >1.

This tutorial (amongst others I'm sure) explains the Debian approach:

https://vitux.com/debian-apache/

You may find that putting a suitable  stanza around your directory 
stanza in apache2.conf works (eg. copy the relevant parts from 000-default), 
though I think you would at least need to disable 000-default if you do. For 
that:

$ sudo a2dissite 000-default

I think the most pain-free method is likely to be to edit or add to the files 
in 
/etc/apache2/sites-available/

Hope that helps.
Gareth


>
> So now I need a  stanza in apache2.conf that works.
> This one doesn't:
> 
>      Options Indexes FollowSymLinks
>      AllowOverride None
>      Require all granted
> 
>
> Do I need to comment out the default page to expose mine?
> I have constructed that path, made a subdir for buster armhf
> stuff in it and placed an preempt-rt kernel file in it. 
> The intent
> is to let anybody download it. If the bots insist on wasting my
> upload bw, I may OTP passwd protect the subdirs, but that's a
> future option & howto question.
>
> Making progress, I think, Thanks Gareth.
>
> Take care & stay well.
>
> Cheers, Gene Heskett.
> -- 
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis

Re: I *think* I found the apache2 docs, but it's in .html and Icannot getfirefox to access it using "file:"+ /path/to/filedir

[Gareth Evans]

> On 21 Jun 2022, at 22:12, Gareth Evans  wrote:
> 
> On Tue 21 Jun 2022, at 20:16, gene heskett  wrote:
>>> On 6/21/22 14:09, Gareth Evans wrote:
>>> On Tue 21 Jun 2022, at 18:06, gene heskett  wrote:
>>>> On 6/21/22 12:11, Andrew M.A. Cater wrote:
>>>>> On Tue, Jun 21, 2022 at 11:55:56AM -0400, gene heskett wrote:
>>>>>> Greetings all;
>>>>>> 
>>>>>> So how am I supposed to read these installed docs?
>>>>>> 
>>>>>> Thanks all.
>>>>>> 
>>>>>> Cheers, Gene Heskett.
>>>>>> -- 
>>>>>> "There are four boxes to be used in defense of liberty:
>>>>>>   soap, ballot, jury, and ammo. Please use in that order."
>>>>>> -Ed Howdershelt (Author, 1940)
>>>>>> If we desire respect for the law, we must first make the law respectable.
>>>>>>   - Louis D. Brandeis
>>>>>> 
>>>>>> From a web browser?
>>>>> 
>>>>> file:///usr/share/doc/apache2-doc
>>>>> 
>>>>> That's three slashes - file:// - two slashes - and then the filesystem 
>>>>> path.
>>>>> 
>>>>> Hope this helps, with every good wish, as ever,
>>>>> 
>>>>> Andy Cater
>>>> And that works, the third slash is new to me.
>>>> 
>>>> So now the only thing I've changed from the default install is in
>>>> /etc/apache2/envvars
>>>> for usr and grp to be www-data. But now it won't restart.
>>>> journalctl -xe reports:
>>>> Jun 21 12:46:16 coyote apachectl[286443]: AH00526: Syntax error on line
>>>> 63 of /etc/apache2/conf-enabled/security.conf:
>>>> Jun 21 12:46:16 coyote apachectl[286443]: Invalid command 'Header', [...]
>>> In my (unedited) version of that file:
>>> 
>>> [...]
>>> 61 # Requires mod_headers to be enabled.
>>> 62 #
>>> 63 #Header set X-Content-Type-Options: "nosniff"
>>> 
>>> If line 63 is required un-commented, then
>>> 
>>> $ sudo a2enmod headers
>>> $ sudo systemctl restart apache2
>>> 
>>> should do the trick.
>> After I found it with locate/ /usr/sbin is not in su's $PATH
>> That fixed the error, and I uncommented the stanza in apache2.conf
>> that points to the directory I want the server to access, and
>> localhost:port# displays the default startup page ok.
>> 
>> dig "my-site-name" returns the proper ipv4 address.
> 
>>  I just used the address:6309 and it worked. So I edited the
>> address bar to use the registered name:6309 and hit F5,
>> a couple times, and that works.
> 
> Do you see a page titled "Apache2 Debian Default Page" with the Debian logo?
> 
> If so it's probably configured in
> 
> /etc/apache2/sites-available/000-default.conf
> 
> or 
> 
> /etc/apache2/sites-available/default-ssl.conf for https version
> 
> as Debian uses name-based virtual hosts with a config file structure which 
> does not correspond to the Apache docs afaics, and I can't find any Debian 
> docs on the subject.
> 
> https://httpd.apache.org/docs/2.4/configuring.html
> https://httpd.apache.org/docs/2.4/vhosts/
> 
> 000-default is already enabled (though the other for https may not be) if 
> you're seeing the page I referred to above.
> 
> $ sudo a2ensite filename (without .conf)
> 
> is the command you would use to enable an "available" configuration (which 
> creates a symlink in ../sites-enabled),


> but you may find it easier just to edit the existing 000-default.conf file.

According to comments in my apache2.conf there needs to be a directory stanza 
there too for each directory not already declared which you want Apache to be 
able to access contents under.

>  You can create another (or iirc just extend it) if you want to add other 
> (domain-)name-based sites in future.
> 
> * in the virtualhost tag as in "*:portNo" means "all domains", so these would 
> need to be specified if >1.
> 
> This tutorial (amongst others I'm sure) explains the Debian approach:
> 
> https://vitux.com/debian-apache/
> 
> You may find that putting a suitable  stanza around your 
> directory stanza in apache2.conf works (eg. copy the relevant parts from 
> 000-default), though I think you would at least need to disable 000-default 
> if you do. For that:
> 
> $ sudo a2dissite 000-default
> 
> I think th

Re: I *think* I found the apache2 docs, but it's in .html and Icannot getfirefox to access it using "file:"+ /path/to/filedir

[Gareth Evans]

> On 21 Jun 2022, at 22:37, Gareth Evans  wrote:
> 
> 
> 
>> On 21 Jun 2022, at 22:12, Gareth Evans  wrote:
>> 
>> On Tue 21 Jun 2022, at 20:16, gene heskett  wrote:
>>>> On 6/21/22 14:09, Gareth Evans wrote:
>>>> On Tue 21 Jun 2022, at 18:06, gene heskett  wrote:
>>>>> On 6/21/22 12:11, Andrew M.A. Cater wrote:
>>>>>>> On Tue, Jun 21, 2022 at 11:55:56AM -0400, gene heskett wrote:
>>>>>>>> Greetings all;
>>>>>>>> 
>>>>>>>> So how am I supposed to read these installed docs?
>>>>>>>> 
>>>>>>>> Thanks all.
>>>>>>>> 
>>>>>>>> Cheers, Gene Heskett.
>>>>>>>> -- 
>>>>>>>> "There are four boxes to be used in defense of liberty:
>>>>>>>>  soap, ballot, jury, and ammo. Please use in that order."
>>>>>>>> -Ed Howdershelt (Author, 1940)
>>>>>>>> If we desire respect for the law, we must first make the law 
>>>>>>>> respectable.
>>>>>>>>  - Louis D. Brandeis
>>>>>>>> 
>>>>>>>> From a web browser?
>>>>>>> 
>>>>>>> file:///usr/share/doc/apache2-doc
>>>>>>> 
>>>>>>> That's three slashes - file:// - two slashes - and then the filesystem 
>>>>>>> path.
>>>>>>> 
>>>>>>> Hope this helps, with every good wish, as ever,
>>>>>>> 
>>>>>>> Andy Cater
>>>>>> And that works, the third slash is new to me.
>>>>>> 
>>>>>> So now the only thing I've changed from the default install is in
>>>>>> /etc/apache2/envvars
>>>>>> for usr and grp to be www-data. But now it won't restart.
>>>>>> journalctl -xe reports:
>>>>>> Jun 21 12:46:16 coyote apachectl[286443]: AH00526: Syntax error on line
>>>>>> 63 of /etc/apache2/conf-enabled/security.conf:
>>>>>> Jun 21 12:46:16 coyote apachectl[286443]: Invalid command 'Header', [...]
>>>>> In my (unedited) version of that file:
>>>>> 
>>>>> [...]
>>>>> 61 # Requires mod_headers to be enabled.
>>>>> 62 #
>>>>> 63 #Header set X-Content-Type-Options: "nosniff"
>>>>> 
>>>>> If line 63 is required un-commented, then
>>>>> 
>>>>> $ sudo a2enmod headers
>>>>> $ sudo systemctl restart apache2
>>>>> 
>>>>> should do the trick.
>>> After I found it with locate/ /usr/sbin is not in su's $PATH
>>> That fixed the error, and I uncommented the stanza in apache2.conf
>>> that points to the directory I want the server to access, and
>>> localhost:port# displays the default startup page ok.
>>> 
>>> dig "my-site-name" returns the proper ipv4 address.
>> 
>>> I just used the address:6309 and it worked. So I edited the
>>> address bar to use the registered name:6309 and hit F5,
>>> a couple times, and that works.
>> 
>> Do you see a page titled "Apache2 Debian Default Page" with the Debian logo?
>> 
>> If so it's probably configured in
>> 
>> /etc/apache2/sites-available/000-default.conf
>> 
>> or 
>> 
>> /etc/apache2/sites-available/default-ssl.conf for https version
>> 
>> as Debian uses name-based virtual hosts with a config file structure which 
>> does not correspond to the Apache docs afaics, and I can't find any Debian 
>> docs on the subject.
>> 
>> https://httpd.apache.org/docs/2.4/configuring.html
>> https://httpd.apache.org/docs/2.4/vhosts/
>> 
>> 000-default is already enabled (though the other for https may not be) if 
>> you're seeing the page I referred to above.
>> 
>> $ sudo a2ensite filename (without .conf)
>> 
>> is the command you would use to enable an "available" configuration (which 
>> creates a symlink in ../sites-enabled),
> 
> 
>> but you may find it easier just to edit the existing 000-default.conf file.
> 

> According to comments in my apache2.conf there needs to be a directory stanza 
> there too for each directory not already declared which you want Apache to be 
> able to access contents under.

Re-reading yesterdays emails it 

Re: I *think* I found the apache2 docs, but it's in .html and Icannot getfirefox to access it using "file:"+ /path/to/filedir

[Gareth Evans]

On Wed 22 Jun 2022, at 18:22, gene heskett  wrote:
> On 6/22/22 10:45, Gareth Evans wrote:
>>
>>> On 21 Jun 2022, at 22:37, Gareth Evans  wrote:
>>>
>>> 
>>>
>>>> On 21 Jun 2022, at 22:12, Gareth Evans  wrote:
>>>>
>>>> On Tue 21 Jun 2022, at 20:16, gene heskett  wrote:
>>>>>> On 6/21/22 14:09, Gareth Evans wrote:
>>>>>> On Tue 21 Jun 2022, at 18:06, gene heskett  wrote:
>>>>>>> On 6/21/22 12:11, Andrew M.A. Cater wrote:
>>>>>>>>> On Tue, Jun 21, 2022 at 11:55:56AM -0400, gene heskett wrote:
>>>>>>>>>> Greetings all;
>>>>>>>>>>
>>>>>>>>>> So how am I supposed to read these installed docs?
>>>>>>>>>>
>>>>>>>>>> Thanks all.
>>>>>>>>>>
>>>>>>>>>> Cheers, Gene Heskett.
>>>>>>>>>> -- 
>>>>>>>>>> "There are four boxes to be used in defense of liberty:
>>>>>>>>>>   soap, ballot, jury, and ammo. Please use in that order."
>>>>>>>>>> -Ed Howdershelt (Author, 1940)
>>>>>>>>>> If we desire respect for the law, we must first make the law 
>>>>>>>>>> respectable.
>>>>>>>>>>   - Louis D. Brandeis
>>>>>>>>>>
>>>>>>>>>>  From a web browser?
>>>>>>>>> file:///usr/share/doc/apache2-doc
>>>>>>>>>
>>>>>>>>> That's three slashes - file:// - two slashes - and then the 
>>>>>>>>> filesystem path.
>>>>>>>>>
>>>>>>>>> Hope this helps, with every good wish, as ever,
>>>>>>>>>
>>>>>>>>> Andy Cater
>>>>>>>> And that works, the third slash is new to me.
>>>>>>>>
>>>>>>>> So now the only thing I've changed from the default install is in
>>>>>>>> /etc/apache2/envvars
>>>>>>>> for usr and grp to be www-data. But now it won't restart.
>>>>>>>> journalctl -xe reports:
>>>>>>>> Jun 21 12:46:16 coyote apachectl[286443]: AH00526: Syntax error on line
>>>>>>>> 63 of /etc/apache2/conf-enabled/security.conf:
>>>>>>>> Jun 21 12:46:16 coyote apachectl[286443]: Invalid command 'Header', 
>>>>>>>> [...]
>>>>>>> In my (unedited) version of that file:
>>>>>>>
>>>>>>> [...]
>>>>>>> 61 # Requires mod_headers to be enabled.
>>>>>>> 62 #
>>>>>>> 63 #Header set X-Content-Type-Options: "nosniff"
>>>>>>>
>>>>>>> If line 63 is required un-commented, then
>>>>>>>
>>>>>>> $ sudo a2enmod headers
>>>>>>> $ sudo systemctl restart apache2
>>>>>>>
>>>>>>> should do the trick.
>>>>> After I found it with locate/ /usr/sbin is not in su's $PATH
>>>>> That fixed the error, and I uncommented the stanza in apache2.conf
>>>>> that points to the directory I want the server to access, and
>>>>> localhost:port# displays the default startup page ok.
>>>>>
>>>>> dig "my-site-name" returns the proper ipv4 address.
>>>>> I just used the address:6309 and it worked. So I edited the
>>>>> address bar to use the registered name:6309 and hit F5,
>>>>> a couple times, and that works.
>>>> Do you see a page titled "Apache2 Debian Default Page" with the Debian 
>>>> logo?
> yes
>
>>>> If so it's probably configured in
>>>>
>>>> /etc/apache2/sites-available/000-default.conf
>>>>
>>>> or
>>>>
>>>> /etc/apache2/sites-available/default-ssl.conf for https version
> I'd like to get this working if possible.
>>>>
>>>> as Debian uses name-based virtual hosts with a config file structure which 
>>>> does not correspond to the Apache docs afaics, and I can't find any Debian 
>>>> docs on the subject.
>>>>
>>>> https://httpd.apache.org/docs/2

Re: I *think* I found the apache2 docs, but it's in .html and Icannot getfirefox to access it using "file:"+ /path/to/filedir

[Gareth Evans]

On Wed 22 Jun 2022, at 21:16, gene heskett  wrote:
> On 6/22/22 10:45, Gareth Evans wrote:
> [and I sniped a few kilobytes of.]
>
> I think I've got it, but I did find what may be a bug in mod auth_plain.
>
> Its asking for a username and pw, but nothing seems to satisfy it

I didn't see you had replied before sending my previous message, please ignore.

Can't find anything about mod_auth_plain but if you mean mod_auth_basic this 
requires usernames/passwords to be set up, not looking at /etc/passwd

https://www.howtogeek.com/devops/how-to-setup-basic-http-authentication-on-apache/

This also has a link to setting up LetsEncrypt.

> , so
> I disabled it, no man page hat I can find, and now its showing me
> the directory I want as the root of this server, with one subdir
> I can click on, and the first file I put there.
>
> However I need to compose an explanatory README to go with it as
> I had to invent my own method of installing it on a u-booting rpi.  Its a
> preempt-rt kernel needed to run the armhf version of linuxcnc from
> the buildbot. I run the bleeding edge development version on all 4
> of my machines I've built or rebuilt. I play the part of the caged
> canary in the coal mine, checking for showstoppers as development
> is ongoing and has been since the net arrived. Its a NIST project, re-
> done in gpl and was once on the no export list. See at linuxcnc.org.
>
> So the plain text version is working and you should be able to see it at
>  (or something like that)

Yes.

>
> That file in the armhf subdir is just under 30 megabytes, so if paying
> for the bandwidth, don't click on it.
>
> Making progress, I think, Thanks Gareth.
>
> However, if there is a way to implement a OTP so I can keep track of the 
> users,
> I could use some help with that as long as I don't setup a universal pw 
> the bots
> can use. What I'd like is a true OTP with a 2 week lifetime.  Can that 
> be done?

I see there are various offerings (web search for "apache otp") but there 
doesn't seem to be an official offering.

I would imagine just using a password would keep the bots away.  Are they that 
determined?

Best wishes,
Gareth

>
> Take care and stay well.
>
> Cheers, Gene Heskett.
> -- 
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis

Re: I *think* I found the apache2 docs, but it's in .html and Icannotgetfirefox to access it using "file:"+ /path/to/filedir

[Gareth Evans]

On Wed 22 Jun 2022, at 22:42, gene heskett  wrote:
> On 6/22/22 16:51, Gareth Evans wrote:
>> On Wed 22 Jun 2022, at 21:16, gene heskett  wrote:
>>> On 6/22/22 10:45, Gareth Evans wrote:
>>> [and I sniped a few kilobytes of.]
>>>
>>> I think I've got it, but I did find what may be a bug in mod auth_plain.
>>>
>>> Its asking for a username and pw, but nothing seems to satisfy it
>> I didn't see you had replied before sending my previous message, please 
>> ignore.
>>
>> Can't find anything about mod_auth_plain but if you mean mod_auth_basic this 
>> requires usernames/passwords to be set up, not looking at /etc/passwd
>>
>> https://www.howtogeek.com/devops/how-to-setup-basic-http-authentication-on-apache/
>>
>> This also has a link to setting up LetsEncrypt.
>>
>>> , so
>>> I disabled it, no man page hat I can find, and now its showing me
>>> the directory I want as the root of this server, with one subdir
>>> I can click on, and the first file I put there.
>>>
>>> However I need to compose an explanatory README to go with it as
>>> I had to invent my own method of installing it on a u-booting rpi.  Its a
>>> preempt-rt kernel needed to run the armhf version of linuxcnc from
>>> the buildbot. I run the bleeding edge development version on all 4
>>> of my machines I've built or rebuilt. I play the part of the caged
>>> canary in the coal mine, checking for showstoppers as development
>>> is ongoing and has been since the net arrived. Its a NIST project, re-
>>> done in gpl and was once on the no export list. See at linuxcnc.org.
>>>
>>> So the plain text version is working and you should be able to see it at
>>>  (or something like that)
>> Yes.
> Good, so I'll quit tinkering for today.
>>
>>> That file in the armhf subdir is just under 30 megabytes, so if paying
>>> for the bandwidth, don't click on it.
>>>
>>> Making progress, I think, Thanks Gareth.
>>>
>>> However, if there is a way to implement a OTP so I can keep track of the
>>> users,
>>> I could use some help with that as long as I don't setup a universal pw
>>> the bots
>>> can use. What I'd like is a true OTP with a 2 week lifetime.  Can that
>>> be done?
>> I see there are various offerings (web search for "apache otp") but there 
>> doesn't seem to be an official offering.
>>

>> I would imagine just using a password would keep the bots away.  Are they 
>> that determined?
>
> Some are, bing and mj12 seem to be the untrainable offenders. mj12 moves 
> theirs around
> in their huge address space about weekly so they got the /16 treatment 
> several times.
>
>   bing moves heirs about monthly. By the time those two seacrate drives 
> puked, my iptables
> rules were about 200 lines deep.

OK, but I mean do the non-robots.txt-compliant bots actually try to submit 
passwords?  

I was wondering why you are interested in OTP/scheduled password regeneration 
for this use case, and whether a simple (or not so simple) password may be 
sufficient for bandwidth preservation purposes.

Thanks
G

>
> I think its called netfilter now, so I expect I better find out how to 
> use it.
>
> In the meantime,  a man page for robots.txt would be nice  but I expect
> DDG can find that..
>> Best wishes,
>> Gareth
> Take care and stay well.
>
> Cheers, Gene Heskett.
> -- 
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis

Re: I *think* I found the apache2 docs, but it's in .html andIcannotgetfirefox to access it using "file:"+ /path/to/filedir

[Gareth Evans]

> On 23 Jun 2022, at 01:46, gene heskett  wrote:
> 
> On 6/22/22 19:39, Gareth Evans wrote:
>>> On Wed 22 Jun 2022, at 22:42, gene heskett  wrote:
>>> On 6/22/22 16:51, Gareth Evans wrote:
>>>> On Wed 22 Jun 2022, at 21:16, gene heskett  wrote:
>>>>> On 6/22/22 10:45, Gareth Evans wrote:
>>>>> [and I sniped a few kilobytes of.]
>>>>> 
>>>>> I think I've got it, but I did find what may be a bug in mod auth_plain.
>>>>> 
>>>>> Its asking for a username and pw, but nothing seems to satisfy it
>>>> I didn't see you had replied before sending my previous message, please 
>>>> ignore.
>>>> 
>>>> Can't find anything about mod_auth_plain but if you mean mod_auth_basic 
>>>> this requires usernames/passwords to be set up, not looking at /etc/passwd
>>>> 
>>>> https://www.howtogeek.com/devops/how-to-setup-basic-http-authentication-on-apache/
>>>> 
>>>> This also has a link to setting up LetsEncrypt.
>>>> 
>>>>> , so
>>>>> I disabled it, no man page hat I can find, and now its showing me
>>>>> the directory I want as the root of this server, with one subdir
>>>>> I can click on, and the first file I put there.
>>>>> 
>>>>> However I need to compose an explanatory README to go with it as
>>>>> I had to invent my own method of installing it on a u-booting rpi.  Its a
>>>>> preempt-rt kernel needed to run the armhf version of linuxcnc from
>>>>> the buildbot. I run the bleeding edge development version on all 4
>>>>> of my machines I've built or rebuilt. I play the part of the caged
>>>>> canary in the coal mine, checking for showstoppers as development
>>>>> is ongoing and has been since the net arrived. Its a NIST project, re-
>>>>> done in gpl and was once on the no export list. See at linuxcnc.org.
>>>>> 
>>>>> So the plain text version is working and you should be able to see it at
>>>>>  (or something like that)
>>>> Yes.
>>> Good, so I'll quit tinkering for today.
>>>>> That file in the armhf subdir is just under 30 megabytes, so if paying
>>>>> for the bandwidth, don't click on it.
>>>>> 
>>>>> Making progress, I think, Thanks Gareth.
>>>>> 
>>>>> However, if there is a way to implement a OTP so I can keep track of the
>>>>> users,
>>>>> I could use some help with that as long as I don't setup a universal pw
>>>>> the bots
>>>>> can use. What I'd like is a true OTP with a 2 week lifetime.  Can that
>>>>> be done?
>>>> I see there are various offerings (web search for "apache otp") but there 
>>>> doesn't seem to be an official offering.
> I haven't done that DDG search, preferring to rely more on the real users 
> experience.
> The idea being that if the bot figures its worth in, and has his master ask 
> for a OTP,
> the 1 or 2 week expiry would eventually run them off. I figure that the 
> botmasters
> patience would be used up and I would get blacklisted, based on TANSTAAFL.
> 
> They aren't using much bandwidth now, and despite the weird port #, several 
> of them
> have already started looking at me.
> 
> I know of two others working on machines to be run by rpi4's, using my kernel 
> cuz
> the foundation would never approve, but all the other machines are being 
> worked on,
> I think I am the only one on the planet actually doing it.  And I did it 
> first with a rpi3b
> but its tongue was dragging on the floor doing it. The rpi4b can run the 
> machine while building
> the next git pull of linuxcnc.  A huge difference in the efficiency between 
> that and a wintel box..
> 
> With linuxcnc not running, or with it running but F2 toggled off. power draw 
> for the pi,
> interfacing and its lcd monitor is about 22 watts. Those machines running on 
> wintel
> boxes are drawing over 200 watts each with the machine powered down.
> 
>> OK, but I mean do the non-robots.txt-compliant bots actually try to submit 
>> passwords? 
> 
> If enough of us do it in self defense, I look for then to grow the code to do 
> it.
> I don't object to them indexing my site, but on a 10 megabit cable connection,
> they use up all my upload bw on a 24/7 basis when they try to mirror it. That 
> in
> my lookup table, is a DDS. So them and the ca

Re: I *think* I found the apache2 docs, but it's in .html andIcannotgetfirefox to access it using "file:"+ /path/to/filedir

[Gareth Evans]

> On 23 Jun 2022, at 21:49, gene heskett  wrote:
> 
> On 6/23/22 16:08, Gareth Evans wrote:
>> OK.  That's not something I can help with from scratch, but I will watch 
>> with interest for further discussion.
>> 
>> Best wishes,
>> G
> Well, it working in plain http, so until they get to be a nuisance, I have 
> other irons
> smoking in the fire. Like some fine tuning of the gui fpr one of my cnc'd 
> machines.
> 
> See at the 6040-stf subdir at the link in my sig.
> 
> That machine is about to start making a screw out of hard maple, made to be 
> the
> screw of a combo with a 3d printed nut assembly for a woodworking workbenches
> leg vise. If it works I'll adv in Fine WoodWorking as the only other maker of 
> such
> has quietly vanished about 15 years back up the log.
> 
> He may have missed morning roll call as will I, probably too soon, but I am 
> 87 and
> alone now.
> 
> And I intend to have fun till I miss that famous roll call.  If I can make a 
> few sheckles
> doing it, that's even better. :o)>
> 
> Thank you for the help, Gareth, take care and stay well.

You're welcome, you too.
Gareth

> 
> 
> Cheers, Gene Heskett.
> 
> -- 
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/>
> 

Re: non installed printer can not be removed

[Gareth Evans]

On Thu 16 Jun 2022, at 22:13, Hans  wrote:
> Hi folks,
>
> I am struggeling with a little problem, I can not explain. 
>
> A friend of mine uses a printer (Samsung SL-C480FW), which is connected to 
> the 
> router with wireless. However, although there are no drivers and no ppd-files 
> installed, the printer is seen by cups (and also by system-printer-config) 
> but 
> can not be used (think, because the missing ppd-file).
>
> When this is installed, udev-entries and so on are set, then the printer is 
> seen for example with ipp://192.168.*.*. 
>

> However, printing does not work, although the printer gets data, but then 
> hangs. I believe, this is a driver problem (because this appeared, since my 
> friend got a new router (FritzBox).

I submitted a bug report re my own issue to Debian, and was asked to report 
upstream, which I have now done.  Hans may like to follow this or perhaps add 
details of his experience, which I suspect is a result of the same problem.

https://github.com/OpenPrinting/cups-filters/issues/472

Best wishes
Gareth

>
> I hope, for this I will find a solution, so hints are welcome, buut not the 
> reason for this thread.
>
> Much more I am interested, to know, why I can not delete the printer in CUPS 
> or system-config-printer? Any printer I add, can be deleted, but the last 
> entry can not be deleted. 
>
> What is wrong? Why does the kernel see the correct printer, and where does it 
> get its information? It is not connected at the USB-port, so no information 
> could be taken from this.
>
> Any ideas?
>
> Thanks for any help!
>
> Best regards
>
> Hans

CUPS bugfix vs upgrade?

[Gareth Evans]

After troubleshooting assistance from the Debian Printing team, I was advised 
to report my non-printing driverless printer issue upstream, which I have done.

https://github.com/OpenPrinting/cups-filters/issues/472

Given that driverless printing works in CUPS 2.4 (on Ubuntu 22.04) are they 
likely to fix 2.3.3 in Debian stable, rather than just suggest Debian updates 
cups[-filters/whatever] in stable?

That is, assuming Canonical hasn't just fixed whatever the issue is in Ubuntu.

Does anyone know if cups 2.4 in Debian testing is in a suitable state to 
consider (exceptionally) adding to stable?

Alternatively, is it advisable to downgrade to a known-working version from 
Buster?

Thanks,
Gareth

Re: nft newbie

[Gareth Evans]

Having found ufw suited my needs I have only dabbled with firewalld / 
firewall-config / firewall-applet over the years.

Having noticed the recommendation for firewalld on the debian wiki re nftables 

https://wiki.debian.org/nftables#Use_firewalld

I installed it and had a look at the default ruleset with

$ sudo nft list ruleset

If, as I understand, nftables default policy is accept, 

"NOTE: If no policy is explicitly selected, the default policy accept will be 
used."
https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains

firewalld doesn't seem to "drop all input unless allowed" by default, as ufw's 
ruleset with only port 22 opened suggests it does.

If there is no drop by default, why add "policy accept" for related/established 
as it does?  Doesn't this happen anyway?

Isn't this less secure, as it seems?

The nftables wiki suggests "policy drop" for input, but the examples are rather 
restrictive.

https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_workstation

https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server

nmap from another machine confirms only port 22 is open via firewalld (which is 
the default) but is default acceptance in other respects a security risk?

I haven't included rulesets but happy to provide if wanted.

Thanks,
Gareth

Re: nft newbie

[Gareth Evans]

On Sat  9 Jul 2022, at 07:17, Gareth Evans  wrote:
[...]
> If there is no drop by default, why add "policy accept" for 
> related/established as it does?  Doesn't this happen anyway?

I suppose this probably modifies behaviour for otherwise closed ports (which 
would make sense for a firewall!) but I can't find much of a high-level 
overview in documentation - man nft, wiki.

I would still be grateful for thoughts from experienced nft users if any issues 
seem to arise from the lack of qualified "policy drop" in input.  Also for any 
good nft/netfilter overview articles etc.

Thanks,
Gareth

Re: nft newbie

[Gareth Evans]

On Sat  9 Jul 2022, at 10:05, Roger Price  wrote:
> On Sat, 9 Jul 2022, Gareth Evans wrote:
>
>> Also for any good nft/netfilter overview articles etc.
>
> Have you seen "Mastering Linux Security and Hardening", 2nd Edition, Donald 
> A. 
> Tevault, chapter 4.  Suitable for those of us who read this newbie thread.
>
> Roger

Thanks Roger, that also suggests "policy drop" in its nftables examples.

I've just noticed the nftables wiki mentions an nftables users mailing list, 

https://wiki.nftables.org/wiki-nftables/index.php/Main_Page

which might be useful too.

Thanks,
Gareth

Re: Debian 11: MTA Exim4 not listening to fetchmail

[Gareth Evans]

On Sun 10 Jul 2022, at 15:38, Roger Price  wrote:
[...]
> I removed the ipv6.disable=1 and rebooted, but this made no difference.

I'm not sure if there may be other issues here too, but did you update-grub 
before rebooting?

If not, does /etc/hosts currently contain 

localhost ::1 

?

If so, it seems ipv6 is still disabled while localhost is associated with an 
ipv6 address, which may have some bearing according to these [not entirely 
pertinent] sources:

https://stackoverflow.com/questions/67173756/socket-address-family-not-supported-by-protocol
https://unix.stackexchange.com/questions/407663/ipv6-socket-creation-failed-address-family-not-supported-by-protocol
https://github.com/netdata/netdata/issues/1282

Hope that helps.

Gareth

Re: Debian 11: MTA Exim4 not listening to fetchmail

[Gareth Evans]

On Sun 10 Jul 2022, at 17:12, Gareth Evans  wrote:

> https://unix.stackexchange.com/questions/407663/ipv6-socket-creation-failed-address-family-not-supported-by-protocol

FWIMBW, this explains how to disable ipv6 for exim4 (albeit on Deb 9) though 
I'm not sure the advice re hosts file is universally applicable.

Re: Debian 11: MTA Exim4 not listening to fetchmail

[Gareth Evans]

On Sun 10 Jul 2022, at 18:28, Greg Wooledge  wrote:

> Mine contains these lines:
>
> unicorn:~$ grep ::1 /etc/hosts
> ::1 localhost ip6-localhost ip6-loopback
> ff02::1 ip6-allnodes
>
> They were put there by Debian.  I didn't touch them.

[I got the ::1 and localhost the wrong way around in my earlier reply.]


$ sudo fuser 25/tcp
25/tcp:   3778

$ ps -p 3778 -o comm=
exim4

$ cat /etc/hosts
127.0.0.1   localhost
127.0.0.1   hostname
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

$ telnet localhost 25
Trying ::1...
Connected to localhost.

$ sudo ss -lnt | grep :25
LISTEN 0  20 127.0.0.1:25 0.0.0.0:*  
LISTEN 0  20 [::1]:25[::]:*


$ sudo reboot 
- set boot arg ipv6.disable=1
- NB ipv6 addresses still in /etc/hosts

$ telnet localhost 25
Trying 127.0.0.1...
Trying ::1...
telnet: Unable to connect to remote host: Address family not supported by 
protocol
  

$ sudo ss -lnt | grep :25
$ 


Just out of interest:

Now, comment out ipv6 in /etc/hosts

$ cat /etc/hosts
127.0.0.1   localhost
127.0.0.1   hostname
#::1localhost ip6-localhost ip6-loopback
#ff02::1ip6-allnodes
#ff02::2ip6-allrouters


$ sudo reboot 
- set boot arg ipv6.disable=1

$ telnet localhost 25
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
  ^^ ???
$ sudo nft list ruleset
$

$ ss -lnt | grep :25
$ 

$ ps -aux | grep exim
gives only "grep exim" - exim4 is not running

Does exim4 require ipv6?

I can't find any obvious such config with

sudo grep -Ri ipv6 /etc/exim4
sudo grep -Ri ip6 /etc/exim4
etc. etc.


In Roger's case, telnet seems to be outputting the same error as exim4 is panic 
logging, which occurs when ipv6 is disabled and "::1 ..." exists in /etc/hosts. 
 Coincidence?

"When certain serious errors occur, Exim writes entries to its panic log. If 
the error is sufficiently disastrous, Exim bombs out afterwards"
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-log_files.html

This suggests exim4 may not be listening having written to the panic log even 
if my ipv6 requirement is the result of some oddity.

Again:

On Sun 10 Jul 2022, at 15:38, Roger Price  wrote:
> I removed the ipv6.disable=1 and rebooted, but this made no difference.

IIUC, without a

$ sudo update-grub

before reboot, ipv6 is still disabled, assuming Roger described exactly what he 
did there.

Does this seem a reasonable assessment?

Best wishes,
Gareth

Re: nft newbie

[Gareth Evans]

On Sun 10 Jul 2022, at 06:25, Gareth Evans  wrote:

> Thanks Roger, that also suggests "policy drop" in its nftables examples.

As someone on firewalld-users kindly pointed out, there is

> table inet firewalld {
> chain filter_INPUT {
[...]
> reject with icmpx admin-prohibited   <--- catch-all reject
> }

which seems equivalent to ufw's qualified "policy drop".

Panic over.
G

Re: nft newbie

[Gareth Evans]

On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies  
wrote:

> drop and reject are not equivalent.

Fair enough

[...]
> In most cases it's a best practice to configure all chains with
> _policy drop_ and then add rules for the traffic that you want to
> allow 

All the nftables and PF howtos I have found take this approach.

Why is it best practice?  Is there any security advantage over rejection?  

Thanks,
Gareth

Re: nft newbie

[Gareth Evans]

> On 12 Jul 2022, at 11:31, mick crane  wrote:
> On 2022-07-12 10:33, Gareth Evans wrote:
>> On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies
> 
>>> In most cases it's a best practice to configure all chains with
>>> _policy drop_ and then add rules for the traffic that you want to
>>> allow
>> All the nftables and PF howtos I have found take this approach.
>> Why is it best practice?  Is there any security advantage over rejection?
> I think it is just that 'reject' tells the remote system there is something 
> listening.
> mick
> 
Oh yes (!), thanks.  A few other points (from a quick web search) here

https://www.coresentinel.com/reject-versus-drop/

including potential for REJECT to facilitate DDoS on asymmetric links - so it 
surprises me again (perhaps this time sensibly?) as the firewalld default.

Incidentally (I mainly have Gene in mind) it might be worth pointing out that 
nftables has individual and mass conversion commands for iptables 
rules/rulesets - perhaps useful if you're in a rush or just to see equivalence

https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables

Best wishes
Gareth

Re: avahi-daemon allow/deny interfaces question

[Gareth Evans]

> On 11 Jul 2022, at 17:48, Ram Ramesh  wrote:
[...]
> . However, my new machine has this daemon running which notices that $extif 
> does not have much activity and disables it after some timeout idle time.

>  Today I noticed that my $extif is vanishing and /var/log/daemon.log shows 
> some avahi-daemon messages about that interface being disabled/withdrawn or 
> some such thing.

Hi Ramesh,

Please could you post some example daemon.log entries and any surrounding 
entries that seem related?

Also is there anything in 

/var/log/syslog


that seems to relate?

Perhaps

$ sudo cat /var/log/syslog | grep x

where x = the interface name concerned.

Thanks,
Gareth

Re: avahi-daemon allow/deny interfaces question

[Gareth Evans]

On Wed 13 Jul 2022, at 01:21, Ram Ramesh  wrote:
> Do you know a simple way to disable autopowerdown of 
> just this usb NIC? May be there is something that I can do with ethtool?

I wonder if powertop may be of use here.  

It has a "tunables" section where (I think) power-saving features can be 
toggled between "good" (on?) or "bad" (off?) by pressing Enter or Space when 
selected, though neither man powertop nor its (github) website 

01.org/powertop

explains the significance  or difference between "good" and "bad", but maybe 
worth trying?

Best wishes,
Gareth

Re: cups broken

[Gareth Evans]

> On 13 Jul 2022, at 18:21, gene heskett  wrote:
> I give up, the driverless printer cups installs automaticaly cannot be 
> deleted and has
> taken over from the brother drivers that work, preventing me from using the 
> printer at all.
> 
> So how do I disable the driverless junk? Is that a separate package that is 
> removable?
> cups doesn't even offer to disable this non-working garbage.
> Thanks for any good clues.

Hi Gene, 

Out of interest, which model printer(s) has the issue?

There are options in

/etc/cups/cupsd.conf

to disable automatic queue creation for autodetected IPP/dns-sd/etc/etc 
printers.

You may find that

# lpinfo -v

copy the ipp:// url for the printer concerned

Then

# lpadmin -p QUEUENAME -v IPP_URL_HERE -E -m everywhere

produces a functional queue

Thanks
Gareth

> 
> Cheers, Gene Heskett.
> -- 
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> Genes Web page 

Re: cups broken

[Gareth Evans]

On Wed 13 Jul 2022, at 20:36, Brian  wrote:
> On Wed 13 Jul 2022 at 20:12:28 +0100, Gareth Evans wrote:
[...]
>> 
>> Hi Gene, 
>> 
>> Out of interest, which model printer(s) has the issue?
>> 
>> There are options in
>> 
>> /etc/cups/cupsd.conf
>> 
>> to disable automatic queue creation for autodetected IPP/dns-sd/etc/etc 
>> printers.
>

> No such options exist in cupsd.conf.

Hi Brian,

I meant cups-browsed.conf at least as regards IPP network printer queues, which 
I think might remain helpful despite revision of the problem description.  I 
had momentarily confused DNS-SD as being one of whatever everywhere, driverless 
etc are.

$ cat /etc/cups/cups-browsed.conf

# Set CreateIPPPrinterQueues to "No" to not auto-create print queues
# for IPP network printers.

# CreateIPPPrinterQueues No
# CreateIPPPrinterQueues LocalOnly
# CreateIPPPrinterQueues Everywhere
# CreateIPPPrinterQueues AppleRaster
# CreateIPPPrinterQueues Everywhere AppleRaster
# CreateIPPPrinterQueues Driverless
# CreateIPPPrinterQueues All

Best wishes,
Gareth

Re: cups broken

[Gareth Evans]

> On 13 Jul 2022, at 22:04, gene heskett  wrote:
> On 7/13/22 15:15, Gareth Evans wrote:
>> [...]
>> Out of interest, which model printer(s) has the issue?
> Brother MFC-J6920DW A huge tabloid capable printer/scanner

>> # lpinfo -v
> first off, none of that stuff is available to the user unless he has hacked 
> his $PATH 

You only have to do this once as root/sudo to set up the queue

QUEUENAME is whatever you want to call the printer queue.

So, eg:

# lpadmin -p J6920 -v  ipp://Brother%20MFC-J6920DW._ipp._tcp.local/  -E -m 
everywhere

Before and after you execute the above, what is output of:

$ driverless

?

Adding an everywhere queue via lpadmin may fix this:

> using the everywhere default, the printer goes
> busy for about the time the print job should take, 20 minutes or so, never 
> moves any
> thing looking for paper, and at the end of the receiving data time, reverts 
> to its idle screen.

but it will be interesting to see about the tray selection issue.

Thanks,
Gareth

 

Re: avahi-daemon allow/deny interfaces question

[Gareth Evans]

On Thu 14 Jul 2022, at 01:03, Ram Ramesh  wrote:
[...]
> I take back some of what I said. It is both - I mean usb 
> autosupend+avahi_daemon. I need to keep the adaptor from autosuspending 
> and tell avahi-daemon not to disable the interface in the OS.
>
> I also found the power/control entry in /sys/bus/usb/ for my usb 
> NIC. It is not in the usual place. lsusb does not list my usb ethernet 
> adapter at all. I had to manually search to find it and set its 
> power/control to "on"
>
> With all this done, so far my net is up and running fine. Will wait a 
> couple days with a couple of reboots to make sure I have captured all 
> fixes in some boot scripts. After that this problem can be thought of as 
> solved.

Hi Ramesh,

There are numerous reports (mostly old, afaics) of the issue you describe, but 
with various suggested reasons.  

I suspect the avahi related part is a consequence rather than a cause - I 
didn't think avahi was capable of disabling interfaces, the message looks like 
it's updating a table/list (etc) and "...no longer relevant..." messages appear 
in my syslog if I deliberately disconnect from wifi.

Please can you provide syslog extracts from just before and during a time when 
this has happened, using:

$ sudo cat /var/log/syslog | grep -i -E "avahi|network"
(must be capital -E and no spaces around the | inside the speech marks)

Is there anything that seems relevant in

$ sudo dmesg -T

?

Out of interest, did you try running for a while with just the power management 
tweak?

Thanks,
Gareth

Re: cups broken

[Gareth Evans]

On Thu 14 Jul 2022, at 02:08, gene heskett  wrote:

> it printed a test page

Good.  I'm afraid I don't know of a workaround for tray selection.

This site 

https://productz.com/en/brother-mfc-j6920dw/p/LZbAV

suggests the printer concerned is airprint/fax-capable, and given:

> On Wed 13 Jul 2022, at 18:21, gene heskett  wrote:
> 
> using the everywhere default, the printer goes busy for about the time the
> print job should take, 20 minutes or so, never moves any thing looking for
> paper, and at the end of the receiving data time, reverts to its idle screen.

I suspect this is the third case we've seen of what seems to be a 
fax+driverless printing bug in cups.

As well as 

$ lpadmin [...] everywhere

"IPP Eveywhere" printers/queues added via cups web interface (localhost:631) 
also seem to work.

I have reported the problem upstream after help from the Debian printing team, 
but no  response from upstream yet.

Best wishes,
Gareth

root crontab @reboot for loop fails

[Gareth Evans]

Hello,

$ sudo crontab -l | grep reboot
[...]
[1] @reboot sleep 10; nmcli c up 
[2] @reboot for f in $(zfs list -t snap -o name|grep reboot); do zfs destroy 
$f;done
[3] @reboot zfs snap -r rpool@reboot

[1] succeeds, but [2,3] do not.

Any ideas why would be gratefully received.

Many thanks,
Gareth

Re: root crontab @reboot for loop fails

[Gareth Evans]

$ sudo crontab -l
[...]
@reboot for f in $(/usr/sbin/zfs list -t snap -o name|grep reboot); do 
/usr/sbin/zfs destroy $f;done
@reboot /usr/sbin/zfs snap -r rpool@reboot


Prepending "/usr/sbin/" to "zfs" doesn't make a difference.

Thanks,
Gareth

Re: root crontab @reboot for loop fails

[Gareth Evans]

Hi Greg,

On Sat 16 Jul 2022, at 04:07, Greg Wooledge  wrote:

[...]

> "Well, read the email that cron sends you and see what the errors are."

[amongst others]
/bin/sh: 1: zfs: not found

suggests the need for /usr/sbin/zfs

It seems reasonable that /usr/sbin/* should be available to root crontab.  

Why isn't root's $PATH available to root crontab? ie. including the link /sbin 
-> /usr/sbin?

> "All your crontab entries run in parallel. 

OK thanks.  Is this documented?  

$ man crontab

then

/parallel
[ie search for "parallel"]

returns nothing.

> "If you wanted to run a bunch of commands a boot time, without setting
> up systemd units for them, and proper dependencies, why didn't you just
> use /etc/rc.local?"

I was of the impression (which I think it is fair to say has been created) that 
systemd had done away with /etc/rc.local, and crontab @reboot is much simpler 
than systemd units and whatever dependencies there may be.

> Figure out whether your commands are allowed to run in parallel [...]

They are not.

> If they're not, use a *script* [...]

With /usr/bin/zfs, that's working, thank you.

Best wishes,
Gareth

Re: root crontab @reboot for loop fails

[Gareth Evans]

On Sat 16 Jul 2022, at 05:30, Gareth Evans  wrote:

> Why isn't root's $PATH available to root crontab? ie. including the 
> link /sbin -> /usr/sbin?

By which I mean: why can't root crontab do everything sudo can do?

Thanks
G

Re: root crontab @reboot for loop fails

[Gareth Evans]

> On 16 Jul 2022, at 14:39, Anssi Saari  wrote:
> 
> Tixy  writes:
> 
>> rc.local is still run on the latest Debian stable. You need to make
>> sure it's a proper executable, i.e. starts with a shebang like
>> '#!/bin/sh' and the file has execute permissions.
> 
> Yes and that's because the systemd package contains the rc-local.service
> which just runs /etc/rc.local. With a ConditionFileIsExecutable too
> which I wasn't aware of before.

Thanks all, that was both helpful and informative
Gareth

Re: Three unsolvable Problems Printer II

[Gareth Evans]

> On 25 Jul 2022, at 13:03, Schwibinger Michael  wrote:
> 
> 
> Hello
> Ist the best way to repair
> the self check?
> 
> HP 600

Hi Sophie, please would you confirm the exact model - eg Deskjet 600, OfficeJet 
600, something else?

If you can't tell from looking at the machine, then running the command

lpinfo -v

in a terminal should tell you.

Thanks,
Gareth

Re: Three unsolvable Problems Printer II

[Gareth Evans]

On Wed 27 Jul 2022, at 22:28, Gareth Evans  wrote:
>> On 25 Jul 2022, at 13:03, Schwibinger Michael  wrote:
>>  
>> Hello
>> Ist the best way to repair
>> the self check?
>> 
>> HP 600
> 
> Hi Sophie, please would you confirm the exact model - eg Deskjet 600, 
> OfficeJet 600, something else?
> 
> If you can't tell from looking at the machine, then running the command

> lpinfo -v

...that perhaps should have been...

sudo lpinfo -v

If you see an error about not being in the sudo group, then run the command

su -

and enter the root password, then run the command

lpinfo -v

again

Thanks,
Gareth