Re: Bug?

[David Christensen]

On 7/14/24 00:57, Richard Bostrom wrote:

Executing this script halts it after the tar with the following message.

--
#!/bin/sh
tar -zcvf bak.tar.gz /home/user/Documents &&
gpg -r backup@user.local -e bak.tar.gz &&
rm -rf bak.tar.gz &&
rsync -vac --delete /home/user/Documents/bak.tar.gz.gpg /media/user/6548-2136 
& -rf bak.tar.gz.gpg

tar: file changed as we read it.
--



Assuming your script is named /home/user/script and your current working 
directory is /home/user, please run the following commands in a terminal 
and post the complete console session -- prompts, commands entered, 
output displayed:


$ cat /etc/debian_version; uname -a

$ cd

$ pwd

$ ls -l bak.tar.gz*

$ ls -l /media/user/6548-2136

$ cat script

$ sh -x script

$ ls -l bak.tar.gz*

$ ls -l /media/user/6548-2136


David

Re: Bug?

[Nicolas George]

Richard Bostrom (12024-07-14):
> tar -zcvf bak.tar.gz /home/user/Documents &&

Information missing: what is the current directory.

> gpg -r backup@user.local -e bak.tar.gz &&
> rm -rf bak.tar.gz &&

> rsync -vac --delete /home/user/Documents/bak.tar.gz.gpg /media/user/6548-2136 
> & -rf bak.tar.gz.gpg

Fortunately, we have the information: the current directory is
/home/user/Documents.

> tar: file changed as we read it.

The message says it exactly as it is.

Solution: do not use the directory you are trying to backup as a
directory for temporary files at the same time.

Regards,

-- 
  Nicolas George

Re: Bug processo di installazione debian 32 bit

[Stanislav Vlasov]

вс, 30 июн. 2024 г. в 17:23, Uno Qualsiasi :
>
> Buongiorno vi contatto per segnalare un problema nel processo di 
> installazione di debian 12.5.0 dvd iso 32 bit, ossia che quando arriva al 
> momento di eseguire “grub-install” su disco primario mi fa errore. Su 
> qualsiasi pf 32 bit lo provi è fa lo stesso problema.
> Inviato da Uno qualsiasi

Most of us are not maintainers. This is a user mailing list and
sending bugs here is a very long way.
I think your target is https://www.debian.org/Bugs/Reporting which
describes how to send bugs by email to maintainers.

-- 
Stanislav

Re: Bug processo di installazione debian 32 bit

[Michael Kjörling]

On 30 Jun 2024 09:11 +0200, from unoqualsiasi...@icloud.com (Uno Qualsiasi):
> Buongiorno vi contatto per segnalare un problema nel processo di 
> installazione di debian 12.5.0 dvd iso 32 bit, ossia che quando arriva al 
> momento di eseguire “grub-install” su disco primario mi fa errore. Su 
> qualsiasi pf 32 bit lo provi è fa lo stesso problema.
> Inviato da Uno qualsiasi

This is the English-language debian-user mailing list.

You may be interested in debian-italian. 
https://lists.debian.org/debian-italian/

Please note that no Debian users' mailing list is the correct venue to
report bugs. For that, see .

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: [BUG] Acentuação de "ç" inconsistente entre ISO DVD e Live

[Yuri Musachio]

Gustavo, bom dia!

Posso estar enganado, mas ACHO que você esta usando o layout errado. Realmente 
como você mencionou, utilizando "´ + c" no layout "English (US, alt. intl.)" o 
resultado será "ć".
Para você utilizar o "ç" é necessário utilizar o layout "English (US, intl., 
with dead keys)" e usar as teclas "alt + ," para ter o resultado esperado. 
Ainda assim, neste layout que eu informei, usando as teclas "´ + c" o resultado 
será "ć".
Espero que consiga agora utilizar o layout correto e o "ç"... Concordo que é 
chato se acostumar, mas eu também utilizava o "Option + c" no Mac pra fazer "ç" 
(o qual eu prefiro por usar apenas uma mão), e tenho usado de boa.

Best,
On Jun 6 2024, at 12:43 am, Gustavo Júnior  wrote:
> Olá,
> Procurei por formas de reportar essa ocorrência no site do Debian, e vi que 
> era recomendado mandar um e-mail para problemas em que o pacote causador é 
> desconhecido. Espero que haja alguma explicação.
>
>
> Esse é um problema que eu venho tendo ultimamente. Eu sempre adorei a 
> instalação em DVD, porque ela dá apenas o software essencial para colocar 
> minha máquina em funcionamento, e sempre fez o Debian rodar em qualquer 
> computador que eu colocasse, por ser bastante leve.
> Agora, recentemente, eu estou usando um novo laptop rodando Debian instalado 
> com a ISO do DVD que tem um layout de teclado americano, e como um usuário 
> brasileiro, eu preciso digitar cedilhas (ç) com bastante frequência. Isso 
> pode ser feito pressionando (' + “c”). Para isso, eu abri o GNOME Settings e 
> escolhi o Inglês , que funcionou em todas as outras 
> instalações do GNOME antes disso, mas não consigo fazê-lo funcionar agora, 
> dando-me ć sempre que eu tento digitar o ç da forma citada anteriormente.
> Reinstalando o Debian com o ISO live, eu consigo a saída desejada (ç) 
> realizando o mesmo processo. Pesquisei um pouco na web e vi que este é um 
> problema relatado por muitas pessoas em fóruns também, mas em versões antigas 
> do Ubuntu, principalmente, mas a correção proposta frequentemente nesses 
> fóruns 
> (https://askubuntu.com/questions/1291492/cedilha-getting-%C4%87-rather-than-%C3%A7-after-upgrade-to-20-10)
>  não funciona para alguns aplicativos, incluindo a barra de pesquisa do GNOME.
> Porque isso acontece na instalação do DVD e, por um acaso, há algum software 
> para baixar ou ajuste que eu precise realizar para obter uma correção 
> consistente? É algo a ser corrigido na próxima versão?
>
> PASSOS PARA REPRODUZIR
> 1) Faça o download do DVD ISO do Debian 12.5.
> 2) Faça uma instalação offline do sistema operacional com o layout do teclado 
> em Português do Brasil e escolha o GNOME como DE (faça os outros passos como 
> quiser).
> 3) Após a instalação, adicione o Inglês (EUA intern. alt.) à configuração nas 
> Configurações do Gnome.
> 4) Tente digitar um “ç” utilizando (' + "c") e acabará obtendo ć.
>
> Fazer o mesmo em uma instalação do GNOME com a ISO live não deve causar o 
> mesmo problema.
>
> Grato pela atenção.
> Att, Gustavo Júnior.
>
>

Re: Bug: Tab completion for pdf files with blanks in path

[Max Nikulin]

On 30/01/2024 12:50, David Wright wrote:

On 30/01/2024 02:51, David Wright wrote:

. Press HOME,
. Type any letter that makes a "wrong" command name (eg aokular),
. Press END,

[...]

However, using my "wrong" command method, Tab Tab lists are complete
all the way down the path. You can then correct the command in order
to prune the Tab Tab listing to include just the candidates
(and in preparation for actually executing the command, of course).


I used a trick with a non-existing command till I figured out that 
[Alt+/] may complete paths for real commands. Pressed twice it gives 
list of candidates, so I do not see any difference from Tab Tab. Perhaps 
I just use it rarely enough, so I believe that moving cursor is less 
convenient. 2 keys instead of single Tab is not a problem, anyway I use 
[Ctrl+/] (undo) frequently enough.


Concerning the bug, maybe upstream is aware of it
https://github.com/scop/bash-completion/issues

Re: Bug: Tab completion for pdf files with blanks in path

[David Wright]

On Tue 30 Jan 2024 at 10:34:21 (+0700), Max Nikulin wrote:
> On 30/01/2024 02:51, David Wright wrote:
> > . Press HOME,
> > . Type any letter that makes a "wrong" command name (eg aokular),
> > . Press END,
> 
> The escape "Esc /" workaround has been posted in this thread already.

Yes, I believe I posted it.

But if you have a long path with many ambiguous branches along the
way, using Esc / gets very tedious because you get no help with
choosing what character to write next. Tab Tab doesn't do anything
until you reach a directory with "candidates" in it (ie files with
appropriate extensions).

But even then, Tab Tab does the wrong thing. It only lists the
candidates, not any directories that can continue the path further.

However, using my "wrong" command method, Tab Tab lists are complete
all the way down the path. You can then correct the command in order
to prune the Tab Tab listing to include just the candidates
(and in preparation for actually executing the command, of course).

> It uses built-in readline path completion instead of BASH programmable
> completion. It may be available as [Alt+/] (in xterm it requires
> xterm*vt100.metaSendsEscape: true)
> 
> [Ctrl+A] and [Ctrl+E] are alternatives for [Home] and [End].
> 
> For details see the BASH manual
> 
> info '(bash) Commands For Completion'
> 
> "complete-filename" function and other sections related to readline
> and completion.
> https://www.gnu.org/software/bash/manual/html_node/Commands-For-Completion.html#index-complete_002dfilename-_0028M_002d_002f_0029

To Greg: Thanks for explaining Michael's true motives.

Cheers,
David.

Re: Bug: Tab completion for pdf files with blanks in path

[Max Nikulin]

On 30/01/2024 02:51, David Wright wrote:

. Press HOME,
. Type any letter that makes a "wrong" command name (eg aokular),
. Press END,


The escape "Esc /" workaround has been posted in this thread already. It 
uses built-in readline path completion instead of BASH programmable 
completion. It may be available as [Alt+/] (in xterm it requires 
xterm*vt100.metaSendsEscape: true)


[Ctrl+A] and [Ctrl+E] are alternatives for [Home] and [End].

For details see the BASH manual

info '(bash) Commands For Completion'

"complete-filename" function and other sections related to readline and 
completion.

https://www.gnu.org/software/bash/manual/html_node/Commands-For-Completion.html#index-complete_002dfilename-_0028M_002d_002f_0029

Re: Bug: Tab completion for pdf files with blanks in path

[Michael Kiermaier]

On 1/29/24 20:59, Greg Wooledge wrote:

complete -r isn't intended as a workaround.  It's intended as a diagnostic
step.

Seeing the problem go away when completion goes away means that the
problem is *in* the completion.  Thus, he knows which package to file
a bug report against.


Yes, I understood that 'complete -r' is for diagnostics.

I've submitted this bug report now:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061831

Thank you again for your help.

Re: Bug: Tab completion for pdf files with blanks in path

[Greg Wooledge]

On Mon, Jan 29, 2024 at 01:51:19PM -0600, David Wright wrote:
> On Mon 29 Jan 2024 at 19:31:50 (+0100), Michael Kiermaier wrote:
> > Thank you for your responses! After 'complete -r' the problem
> > disappears. I should add that I never touched the autocomplete settings.
> 
> No, but you lose your so-called component (2) filtering.
> 
> For me, a better workaround is, when the directory path gets "stuck":
> 
> . Press HOME,
> . Type any letter that makes a "wrong" command name (eg aokular),
> . Press END,
> . Press TAB and carry on using completion for directory/filenames,
> . Once you reach the right directory, and if you need filtering,
>   press HOME DELETE END and you've got filtering back again.
> . Obviously press HOME DELETE if you didn't do the previous step.
> 
> > I will submit a bug report for the package bash-completion.

complete -r isn't intended as a workaround.  It's intended as a diagnostic
step.

Seeing the problem go away when completion goes away means that the
problem is *in* the completion.  Thus, he knows which package to file
a bug report against.

Re: Bug: Tab completion for pdf files with blanks in path

[David Wright]

On Mon 29 Jan 2024 at 19:31:50 (+0100), Michael Kiermaier wrote:
> On 1/29/24 18:59, Greg Wooledge wrote:
> > On Tue, Jan 30, 2024 at 12:05:24AM +0700, Max Nikulin wrote:
> > > On 29/01/2024 19:40, Greg Wooledge wrote:
> > > > Let me test that as well
> > > [...]
> > > > unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file
> > > 
> > > "okular" is important here. Only limited set of file name suffixes are
> > > allowed for some commands. You do not need to have okular installed,
> > > completion rules are part of bash-completion.
> > 
> > That's my point as well.  I'm trying to get the OP to determine whether
> > it's the programmable completion for "okular" in particular that's at
> > fault, or bash itself (hint: it's not).
> 
> Thank you for your responses! After 'complete -r' the problem
> disappears. I should add that I never touched the autocomplete settings.

No, but you lose your so-called component (2) filtering.

For me, a better workaround is, when the directory path gets "stuck":

. Press HOME,
. Type any letter that makes a "wrong" command name (eg aokular),
. Press END,
. Press TAB and carry on using completion for directory/filenames,
. Once you reach the right directory, and if you need filtering,
  press HOME DELETE END and you've got filtering back again.
. Obviously press HOME DELETE if you didn't do the previous step.

> I will submit a bug report for the package bash-completion.

Cheers,
David.

Re: Bug: Tab completion for pdf files with blanks in path

[Michael Kiermaier]

On 1/29/24 18:59, Greg Wooledge wrote:

On Tue, Jan 30, 2024 at 12:05:24AM +0700, Max Nikulin wrote:

On 29/01/2024 19:40, Greg Wooledge wrote:

Let me test that as well

[...]

unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file


"okular" is important here. Only limited set of file name suffixes are
allowed for some commands. You do not need to have okular installed,
completion rules are part of bash-completion.


That's my point as well.  I'm trying to get the OP to determine whether
it's the programmable completion for "okular" in particular that's at
fault, or bash itself (hint: it's not).


Thank you for your responses! After 'complete -r' the problem
disappears. I should add that I never touched the autocomplete settings.

I will submit a bug report for the package bash-completion.

Re: Bug: Tab completion for pdf files with blanks in path

[David Wright]

On Mon 29 Jan 2024 at 12:59:39 (-0500), Greg Wooledge wrote:
> On Tue, Jan 30, 2024 at 12:05:24AM +0700, Max Nikulin wrote:
> > On 29/01/2024 19:40, Greg Wooledge wrote:
> > > Let me test that as well
> > [...]
> > > unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file
> > 
> > "okular" is important here. Only limited set of file name suffixes are
> > allowed for some commands. You do not need to have okular installed,
> > completion rules are part of bash-completion.
> 
> That's my point as well.  I'm trying to get the OP to determine whether
> it's the programmable completion for "okular" in particular that's at
> fault, or bash itself (hint: it's not).
> 
> In my demonstration, all programmable completions were disabled.  I
> never use them to begin with.  So, in my demonstration, the command
> name is completely irrelevant.

No, it's pretty much any command that wants to match particular
extensions, like xpdf, dvips, unzip, etc. Obviously bash-completion
should always attempt to match directories as it doesn't know what
they might contain.

Cheers,
David.

Re: Bug: Tab completion for pdf files with blanks in path

[Greg Wooledge]

On Tue, Jan 30, 2024 at 12:05:24AM +0700, Max Nikulin wrote:
> On 29/01/2024 19:40, Greg Wooledge wrote:
> > Let me test that as well
> [...]
> > unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file
> 
> "okular" is important here. Only limited set of file name suffixes are
> allowed for some commands. You do not need to have okular installed,
> completion rules are part of bash-completion.

That's my point as well.  I'm trying to get the OP to determine whether
it's the programmable completion for "okular" in particular that's at
fault, or bash itself (hint: it's not).

In my demonstration, all programmable completions were disabled.  I
never use them to begin with.  So, in my demonstration, the command
name is completely irrelevant.

Re: Bug: Tab completion for pdf files with blanks in path

[Max Nikulin]

On 29/01/2024 19:40, Greg Wooledge wrote:

Let me test that as well

[...]

unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file


"okular" is important here. Only limited set of file name suffixes are 
allowed for some commands. You do not need to have okular installed, 
completion rules are part of bash-completion.

Re: Bug: Tab completion for pdf files with blanks in path

[David Wright]

On Mon 29 Jan 2024 at 07:40:13 (-0500), Greg Wooledge wrote:
> On Mon, Jan 29, 2024 at 09:32:18AM +0100, Michael Kiermaier wrote:
> > I would like to run okular opening the pdf file
> > ~/dir1\ with\ blanks/dir2/file.pdf
> > via command line. In konsole I type
> > okular ~/dir1\ with\ blanks/
> > and hit the tab key twice for autocomplete. But I won't get offered
> > dir2. After adding more letters like
> 
> My first question would be: does the problem still occur if you disable
> bash-completion?  Open a new instance of bash and run "complete -r" to
> remove all programmable completions.  See if the problem still occurs.
> Then close that instance of bash.
> 
> > okular ~/dir1\ with\ blanks/di
> > to make the completion to dir2 unique
> 
> Oh, there's more than one subdir?  Let me test that as well
> 
> Yeah, even with both dir1 and dir2 (each containing a file), I still get
> the expected behavior in bash without bash-completion in the picture.
> 
> unicorn:~$ cd /tmp
> unicorn:/tmp$ mkdir -p 'dir with blanks'/dir2
> unicorn:/tmp$ touch "$_"/file
> 
> (first experiments with tab completion, not shown)
> 
> unicorn:/tmp$ mkdir -p 'dir with blanks'/dir1
> unicorn:/tmp$ touch "$_"/otherfile
> unicorn:/tmp$ xyz dir\ with\ blanks/dir
> dir1/ dir2/ 
> unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file 
> 
> I'm assuming whatever issue you're seeing is the result of a
> bash-completion bug, not a bash bug.  If you can confirm that, then
> you'll know which package to file a bug against.

Unless I missed a bit in the OP, the bug is actually worse.
Type di and press TAB, and bash-completion gives you
dir\ with\ blanks/ ok. But now rub out the "nks/" at the end
and press TAB. It fails to complete even that directory name.

However, there's a workaround, which you really have to know
about if you're a bash-completion user, and that is:

  ESCAPE /

AFAICT you won't get the list of possibilities as you would normally,
but it should autocomplete as far as the string remains unique.

Cheers,
David.

Re: Bug: Tab completion for pdf files with blanks in path

[Greg Wooledge]

On Mon, Jan 29, 2024 at 09:32:18AM +0100, Michael Kiermaier wrote:
> I would like to run okular opening the pdf file
>   ~/dir1\ with\ blanks/dir2/file.pdf
> via command line. In konsole I type
> okular ~/dir1\ with\ blanks/
> and hit the tab key twice for autocomplete. But I won't get offered
> dir2. After adding more letters like

My first question would be: does the problem still occur if you disable
bash-completion?  Open a new instance of bash and run "complete -r" to
remove all programmable completions.  See if the problem still occurs.
Then close that instance of bash.

>   okular ~/dir1\ with\ blanks/di
> to make the completion to dir2 unique

Oh, there's more than one subdir?  Let me test that as well

Yeah, even with both dir1 and dir2 (each containing a file), I still get
the expected behavior in bash without bash-completion in the picture.

unicorn:~$ cd /tmp
unicorn:/tmp$ mkdir -p 'dir with blanks'/dir2
unicorn:/tmp$ touch "$_"/file

(first experiments with tab completion, not shown)

unicorn:/tmp$ mkdir -p 'dir with blanks'/dir1
unicorn:/tmp$ touch "$_"/otherfile
unicorn:/tmp$ xyz dir\ with\ blanks/dir
dir1/ dir2/ 
unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file 

I'm assuming whatever issue you're seeing is the result of a
bash-completion bug, not a bash bug.  If you can confirm that, then
you'll know which package to file a bug against.

Re: Bug on upgrade to bookworm with Apache/PHP?

[Charles Curley]

On Sat, 30 Dec 2023 17:50:03 +
Andrew Wood  wrote:

> Found the following issue when running an upgrade.
> 
> Apache refuses to restart with error:
> 
> apache2_reload: Your configuration is broken. Not restarting Apache 2
> apache2_reload: apache2: Syntax error on line 146 of 
> /etc/apache2/apache2.conf: Syntax error on line 3 of 
> /etc/apache2/mods-enabled/php7.4.load: Cannot load 
> /usr/lib/apache2/modules/libphp7.4.so into server: 
> /usr/lib/apache2/modules/libphp7.4.so: cannot open shared object
> file: No such file or directory
> 
> 
> This is because the php7.4 files have now been replaced with php8.2
> 
> Specifically sym linsk in  /etc/apache2/mods-enabled/ which link to  
> /etc/apache2/mods-available/
> php7.4.conf -> ../mods-available/php7.4.conf
> php7.4.load -> ../mods-available/php7.4.load
> 
> Should be removed and replaced with a link to
> 
> php8.2.conf -> ../mods-available/php8.2.conf
> php8.2.load -> ../mods-available/php8.2.load
> 
> 
> Is this known about?
> 
> Andrew
> 

You might want to disable any php 7.4 modules and enable php8.2.conf
and php8.2.load.

root@hawk:/etc/apache2# ls mods-enabled/
access_compat.load  autoindex.load  mpm_prefork.conf  setenvif.load
alias.conf  deflate.confmpm_prefork.load  socache_shmcb.load
alias.load  deflate.loadnegotiation.conf  ssl.conf
auth_basic.load dir.confnegotiation.load  ssl.load
authn_core.load dir.loadphp8.2.conf   status.conf
authn_file.load env.loadphp8.2.load   status.load
authz_core.load filter.load reqtimeout.conf   userdir.conf
authz_host.load headers.loadreqtimeout.load   userdir.load
authz_user.load mime.conf   rewrite.load
autoindex.conf  mime.load   setenvif.conf
root@hawk:/etc/apache2# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Bug on upgrade to bookworm with Apache/PHP?

[Dan Ritter]

Andrew Wood wrote: 
> This is because the php7.4 files have now been replaced with php8.2
> 
> Specifically sym linsk in  /etc/apache2/mods-enabled/ which link to 
> /etc/apache2/mods-available/
> php7.4.conf -> ../mods-available/php7.4.conf
> php7.4.load -> ../mods-available/php7.4.load
> 
> Should be removed and replaced with a link to
> 
> php8.2.conf -> ../mods-available/php8.2.conf
> php8.2.load -> ../mods-available/php8.2.load
> 
> 
> Is this known about?


Yes. It is not an error, per se, because it is possible that a
person would want to keep the php7 system around a bit longer,
and not yet install the php8 system.

It is just part of the decisions that a sysadmin has to make for
their systems.

-dsr-

Re: Bug report

[Dan Ritter]

Iman Hajibagheri wrote: 
> Hello
> My laptop model is asus zenbook duo ux481 and I installed ubuntu desktop
> After installation, when I log in to my account for the first time, a
> welcome to ubuntu tab appears. I click on the help improve ubuntu section.
> My laptop stops after the yes option and the operating system crashes. I
> think this is due to the detection of the hardware of the second monitor.
> It happens because whenever I get lshw or other hardware ls, the same thing
> happens.
> And it does not have the ability to adjust the brightness and other
> features for the second screen.

This is the Debian users mailing list.

Ubuntu support is here: https://ubuntu.com/community/support

Re: Bug#1056998: cdrom: Installation media changes after booting it

[Nicholas Geovanis]

On Mon, Dec 4, 2023, 3:30 AM Thomas Schmitt  wrote:

> .
> This seems to indicate that the firmware has a stake in the problem ...
>
> > Both the Thinkpad E14 Gen 5s had the same specifications and type number,
> > differing only in that the one with corruption of the installer has 24GB
> of
> > memory (16GB installed in the slot, 8GB soldered) and the other only has
> 8GB
> > soldered. They both have the same BIOS version, R2AET32W(1.07).
>
> ... but the trigger would have to be very subtle.
>
> > This seems to be really interesting because the corruption only happened
> on
> > certain computers, and it would stay that way on repeated attempts.
>


FWIW check the BIOS L[123] cache settings and consider changing them to
more conservative "slower" values if possible. And you have different RAM
models and configurations, could there be one DIMM in the mix that is
running overclocked?

Have a nice day :)
>
> Thomas
>

Grüß Gott :-)

Re: bug report

[Greg Wooledge]

On Sun, Sep 24, 2023 at 11:13:44AM +, Sarah Marsh wrote:
> I am emailing to find information on how to file a bug report with Debian.

https://www.debian.org/Bugs/Reporting

> I received a message on my command line to file a report for the issue that I
> am having with the command line and the Computer itself.  The website says to
> file through the command line but my commands do not work,

We can't help you with that, if you don't tell us what commands you
ran, and what their output was.

In any case, if the "reportbug" command won't work for you, you can just
send a properly formatted email to the appropriate address, as described
on the page above.

Please note that the message you sent to debian-user was NOT properly
formatted for this kind of task.  It was just one gigantic line of
text.  (I reformatted it in my reply.)  The bug reporting system is
going to need separate lines of text, containing the package name and
the package version.

Re: bug report question

[Dan Purgert]

On Sep 07, 2023, duh_gently...@simplelogin.com wrote:
> Thank you for your advice!

No problem.

> 
> lspci says:
> 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models
> 00h-0fh) PCIe GPP Bridge

Okay so it's the root PCI bridge on the motherboard.  Are there any
BIOS/UEFI updates available?

> 
> The only 2 PCIe devices I have are my video card and my m.2 drive. I have
> had different kernel versions as I have had this problem for at least 6
> months (debian testing)... so I can't really say when it all started.

What kernel are you running right now?


-- 
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860


signature.asc
Description: PGP signature

Re: bug report question

[duh_gently889]

Thank you for your advice!

lspci says:
00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-0fh) PCIe GPP Bridge


The only 2 PCIe devices I have are my video card and my m.2 drive. I 
have had different kernel versions as I have had this problem for at 
least 6 months (debian testing)... so I can't really say when it all 
started.


But for me, at least a half-solution would be to stop these errors being 
logged, so that I can shut down the computer properly. When the root 
file system is full, many programs stop working, and even after a 
reboot, the user interface will not start.


On 07/09/2023 12.24, Dan Purgert - dan at djph.net wrote:

On Sep 07, 2023, duh_gently...@simplelogin.com wrote:

Hello,

I'd like to submit a bug, but I'm not quite sure which package it
should be.
I could not find anything similar in the bugtracker.

The problem occurs every 10-20 times. After the system has been suspended
and then resumed, the following message is written to kern.log and syslog:

2023-09-07T09:43:21.264297+02:00 host kernel: [527584.040221] pcieport
:00:01.3: PME: Spurious native interrupt!
[...]

I accept that the message may indicate a valid problem, but having so many
log messages is not OK either. Currently, when this happens, I am
forced to manually delete the log file and reboot.

At first glance, it seems to be hardware related. What device is plugged
into that PCIe slot (or is it the PCIe Root)?


In no particular order:

   - Check for a BIOS/UEFI update
   - Check with an older kernel
   - Check for an updated kernel module / driver
   - Reboot and revert to the previously working kernel revision / patch

Re: bug report question

[Dan Purgert]

On Sep 07, 2023, duh_gently...@simplelogin.com wrote:
> Hello,
> 
> I'd like to submit a bug, but I'm not quite sure which package it
> should be.
> I could not find anything similar in the bugtracker.
> 
> The problem occurs every 10-20 times. After the system has been suspended
> and then resumed, the following message is written to kern.log and syslog:
> 
> 2023-09-07T09:43:21.264297+02:00 host kernel: [527584.040221] pcieport
> :00:01.3: PME: Spurious native interrupt!
> [...]
> 
> I accept that the message may indicate a valid problem, but having so many
> log messages is not OK either. Currently, when this happens, I am
> forced to manually delete the log file and reboot.

At first glance, it seems to be hardware related. What device is plugged
into that PCIe slot (or is it the PCIe Root)?


In no particular order:

  - Check for a BIOS/UEFI update
  - Check with an older kernel
  - Check for an updated kernel module / driver
  - Reboot and revert to the previously working kernel revision / patch



-- 
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860


signature.asc
Description: PGP signature

Re: bug gefixed, wat te doen

[Geert Stappers]

In-Reply-To: <8fd40dfa-6fe1-7888-daaf-08012c726...@vandervlis.nl>
X-Previous-Subject: Re: libdvd-pkg’s postinst script is broken

On Mon, Sep 04, 2023 at 11:28:03PM +0200, Paul van der Vlis wrote:
> 
> Nu heb ik de bug gefixed volgens mij. Maar wat te doen met het resultaat?

Toevoegen aan het bugreport.

Door middel van een e-mail naar het B.R.
Stel BR heeft nummer NNN, e-mail dan naar  n...@bugs.debian.org


Wat voorbeelden:
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081#47
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081#57

Inderdaad, het hoeft niet in 1 keer goed.

Zie ook https://www.debian.org/Bugs/server-request#introduction


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: Bug with audio muting - which package?

[Stanislav Vlasov]

пн, 5 июн. 2023 г. в 05:36, Paul Martz :

> If I mute audio in the desktop, then reboot into console mode, the SpeakUp 
> screen reading software is also muted. I think this is a bug - muting the 
> desktop should be a desktop property and should not affect the console screen 
> reader. But I’m not sure which package I should file the bug against. Any 
> help would be appreciated. Thanks.

You may try to bugreport for pulseaudio, but i think this bug will be
rejected — pulseaudio (sound service) and alsa (hardware interface) is
systemwide, not desktop-only.

-- 
Stanislav

Re: Bug Clamav #1027130

[Lamourec Alain]

Bonjour

Je n'utilise pas clamav. J'en éprouve pas le besoin.
Sur le lien, ce bug est résolu pour la version 1.0.0 (Debian Sid)

Donc pour ta version, il doit encore existé.
Comme mentionné, il faudrait rester à la version 
0.103.7+dfsg-0+deb11u1 pour ne pas l'avoir.


A+

Sil writes:


Bonjour la liste,

J'ai une alerte de bug grave pour la mise à jour des paquets 
Clamav
sur une installation stable amd64.  Elle fait référence à ce bug 
:


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

libclamav9: LibClamAV Error: Can't verify database integrity

Je ne comprend pas tout et ai l'impression que ce bug soit 
corrigé. Le
bug est déclaré sur la version 0.103.7 qui est déjà installée 
sur mon 
système et la mise à jour me propose de passer en 0.103.8.


Avez-vous fait la mise à jour ? Êtes-vous impactés ? Est-ce un
problème avec apt-listbugs ?

Par avance merci

Sil



--
Lamourec Alain

Re: Bug após atualização do sistema Debian 11.7

[Wiliam Freitas]

Olá, Hebert.

Uma pena que precisou formatar para resolver, mas ainda bem que 
resolveu! O importante é funcionar.


Há alguns diretórios de caches no sistema que armazenam configurações da 
interface. Uma possível causa para o problema que teve é ter ocorrido 
algum erro de configuração nesses arquivos relacionados à interface.


Então, uma alternativa para esse tipo de problema, de interface gráfica, 
é criar outro usuário no sistema e ver se nesse novo usuário as 
funcionalidades estão ok. A se confirmar esse cenário, bastaria tratar 
ou simplesmente remover esses caches/configurações.


Fica pra próxima. Um abraço!

Wiliam Freitas,

https://linuxzilla.com.br

Em 30/04/2023 21:14, HEBERT LIMA escreveu:

Olá, obrigado pelo retorno! Havia tentando o htop anteriormente, mas o 
consumo de memória aparentava estar normal. Ao executar o glxgears eu 
via que o FPS não estava mais o mesmo. Então acabei  formatando, 
fazendo backup e atualizando novamente o Debian. Desta vez tudo correu 
bem e seguirei fazendo o backup antes de qualquer atualização.


Obrigado!




Hebert Thallys Pecorelli

http://lattes.cnpq.br/8251714580488742

Faculdade de Farmácia - UFRJ
Cidade Universitária, Rio de Janeiro, RJ
21941-909


Em dom, 30 de abr de 2023 13:30, Leandro Guimarães Faria Corcete DUTRA 
 escreveu:


Le 29/04/2023 à 18:31, hebert.thallys.pecore...@gmail.com a écrit :
> o sistema ficou extremamente lento
> para tarefas simples e e programas ficaram extremamente lentos.

O comando htop, por exemplo, deve mostrar quais processos estão
consumindo mais memória e processamento.


> Gostaria de saber qual atualização causou isto

Dentro de /var/log tem um registro das atualizações, creio que é um
dpkg.log ou algo assim.  Comparar isso com as primeiras linhas do
htop
deve ajudar a localizar o problema.



-- 
/¯\ +55 (61) 3216 3613                 mailto:l...@dutras.org

\ / +55 (61) 3546 7191 xmpp:leand...@jabber.org

  X  +55 (61) 99302 2691          matrix:user/l...@matrix.org
/ \ Brazil GMT−3 https://useplaintext.email/#why-plaintext

Re: Bug após atualização do sistema Debian 11.7

[HEBERT LIMA]

Olá, obrigado pelo retorno! Havia tentando o htop anteriormente, mas o
consumo de memória aparentava estar normal. Ao executar o glxgears eu via
que o FPS não estava mais o mesmo. Então acabei  formatando, fazendo backup
e atualizando novamente o Debian. Desta vez tudo correu bem e seguirei
fazendo o backup antes de qualquer atualização.

Obrigado!




Hebert Thallys Pecorelli

http://lattes.cnpq.br/8251714580488742

Faculdade de Farmácia - UFRJ
Cidade Universitária, Rio de Janeiro, RJ
21941-909



Em dom, 30 de abr de 2023 13:30, Leandro Guimarães Faria Corcete DUTRA <
l...@dutras.org> escreveu:

> Le 29/04/2023 à 18:31, hebert.thallys.pecore...@gmail.com a écrit :
> > o sistema ficou extremamente lento
> > para tarefas simples e e programas ficaram extremamente lentos.
>
> O comando htop, por exemplo, deve mostrar quais processos estão
> consumindo mais memória e processamento.
>
>
> > Gostaria de saber qual atualização causou isto
>
> Dentro de /var/log tem um registro das atualizações, creio que é um
> dpkg.log ou algo assim.  Comparar isso com as primeiras linhas do htop
> deve ajudar a localizar o problema.
>
>
>
> --
> /¯\ +55 (61) 3216 3613 mailto:l...@dutras.org
> \ / +55 (61) 3546 7191xmpp:leand...@jabber.org
>   X  +55 (61) 99302 2691  matrix:user/l...@matrix.org
> / \ Brazil GMT−3 https://useplaintext.email/#why-plaintext
>
>

Re: Bug após atualização do sistema Debian 11.7

[Leandro Guimarães Faria Corcete DUTRA]

Le 29/04/2023 à 18:31, hebert.thallys.pecore...@gmail.com a écrit :

o sistema ficou extremamente lento
para tarefas simples e e programas ficaram extremamente lentos.


O comando htop, por exemplo, deve mostrar quais processos estão 
consumindo mais memória e processamento.




Gostaria de saber qual atualização causou isto


Dentro de /var/log tem um registro das atualizações, creio que é um 
dpkg.log ou algo assim.  Comparar isso com as primeiras linhas do htop 
deve ajudar a localizar o problema.




--
/¯\ +55 (61) 3216 3613 mailto:l...@dutras.org
\ / +55 (61) 3546 7191xmpp:leand...@jabber.org
 X  +55 (61) 99302 2691  matrix:user/l...@matrix.org
/ \ Brazil GMT−3 https://useplaintext.email/#why-plaintext

Re: "Bug" in Debian Installer?

[David Wright]

On Fri 21 Apr 2023 at 23:05:53 (+0700), Max Nikulin wrote:
> On 21/04/2023 11:26, David Wright wrote:
> > On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote:
> > 
> > > Opt-out variant for ESP sounds reasonable for me. However I am unsure
> > > if it is possible to complete installation with no ESP at all.
> > 
> > If you mean: to install Grub but not write to the ESP,
> 
> No, I did not go so far. I wrote about partitioning screen.

Understood; I wasn't sure.

> It is
> possible to select ESP partition and mark it "Do not use". My
> expectation is that it should prevent installing grub to ESP. However
> it is easy to forget about the "K" flag (partition will be used by
> installer).

I haven't tried removing all the flags to see what warning might result,
and whether there would even be any attempt to install grub-* (the
packages called grub-*, not writing grub.cfg or placing Grub code in
NVRAM). It does help to have the grub packages available to make
changes later.

> My point is that if a partition is marked for usage as ESP then it is
> not "without explicit notification and permission".

Agreed: it reinforces/confirms the point that the user asked the d-i
to install a Debian system.

> > ┌─┤ [!] Install the GRUB boot loader ├──┐
> 
> Is it shown in the case of default debconf priority or it is necessary
> to switch to "low"?

IDK. As I said, "I think you can …", which I wrote because I think I
did just that. (I was doing something very similar to what the OP was
doing, using a PC with dual-booting Windows/Debian to install Debian
onto a portable drive, without screwing up the dual-boot.

> Frankly speaking, from this text it is unclear for me if the question
> is related to putting files to EFI/debian or to creation of new
> Boot NVRAM variable with possible modification of BootOrder.

Sure. I was hacking, and keeping a close eye on VC4. (Using more is
hard work compared with less.)

> > │ The following other operating systems have been detected on this  │
> > │ computer: Debian GNU/Linux 11 (bullseye)  │
> > │   │
> > │ If all of your operating systems are listed above, then it should be  │
> > │ safe to install the boot loader to your primary drive (UEFI   │
> > │ partition/boot record).
> 
> Side note. I do not think it is safe to install *Debian* boot loader
> when another *Debian* is detected. It will overwrite
> EFI/debian/grub.cfg and so will make earlier installed debian not
> bootable. Either I missed something or it is fragile to manage grub
> configuration shared by 2 independent debian (or other linux
> distributions) systems.

That's why I wrote about "playing tricks" below. Felix mentioned
using GRUB_DISTRIBUTOR to avoid having the same name used twice.

> > Bullseye had a misfeature where it would, even on a BIOS machine,
> > solicit installing to the fallback location.
> 
> Do you mean installing grub to EFI/BOOT (layout for removable
> storage)?

Yes. The nomenclature is very confusing IMO.

> I have an almost 10 years old HP laptop with buggy firmware.
> The easiest way to make linux bootable is to put grub into EFI/BOOT
> (and remove fbx64.efi fallback binary that attempts to adjust Boot
> and ignored BootOrder on each boot). It is possible to select any boot
> entry from F9 menu, but by default it boots from EFI/BOOT/bootx64.efi.

But this was a BIOS machine, so there's no UEFI/EFI. The buster d-i
seemed not to realise that, even though it knew it had an MBR:

┌───┤ [!] Install the GRUB boot loader on a hard disk ├───┐
│ │
│ You need to make the newly installed system bootable, by installing │
│ the GRUB boot loader on a bootable device. The usual way to do this │
│ is to install GRUB on the master boot record of your first hard │
↑↑
│ drive. If you prefer, you can install GRUB elsewhere on the drive, or   │
│ to another drive, or even to a floppy.  │
│ │
│ Device for boot loader installation:│

 ┌──┤ [.] Install the GRUB boot loader on a hard disk ├──┐
 │   │
 │ It seems that this computer is configured to boot via EFI, but maybe  │

 │ that configuration will not work for booting from the hard drive. │
 │ Some EFI firmware implementations do not meet the EFI specification   │
 │ (i.e. they are buggy!) and do not support proper configuration of │
 │ boot options from system hard drives. │
 │   │
 

Re: "Bug" in Debian Installer?

[Max Nikulin]

On 21/04/2023 11:26, David Wright wrote:

On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote:


Opt-out variant for ESP sounds reasonable for me. However I am unsure
if it is possible to complete installation with no ESP at all.


If you mean: to install Grub but not write to the ESP,


No, I did not go so far. I wrote about partitioning screen. It is 
possible to select ESP partition and mark it "Do not use". My 
expectation is that it should prevent installing grub to ESP. However it 
is easy to forget about the "K" flag (partition will be used by installer).


My point is that if a partition is marked for usage as ESP then it is 
not "without explicit notification and permission".



┌─┤ [!] Install the GRUB boot loader ├──┐


Is it shown in the case of default debconf priority or it is necessary 
to switch to "low"?


Frankly speaking, from this text it is unclear for me if the question is 
related to putting files to EFI/debian or to creation of new Boot 
NVRAM variable with possible modification of BootOrder.



│ The following other operating systems have been detected on this  │
│ computer: Debian GNU/Linux 11 (bullseye)  │
│   │
│ If all of your operating systems are listed above, then it should be  │
│ safe to install the boot loader to your primary drive (UEFI   │
│ partition/boot record).


Side note. I do not think it is safe to install *Debian* boot loader 
when another *Debian* is detected. It will overwrite EFI/debian/grub.cfg 
and so will make earlier installed debian not bootable. Either I missed 
something or it is fragile to manage grub configuration shared by 2 
independent debian (or other linux distributions) systems.



Bullseye had a misfeature where it would, even on a BIOS machine,
solicit installing to the fallback location.


Do you mean installing grub to EFI/BOOT (layout for removable storage)? 
I have an almost 10 years old HP laptop with buggy firmware. The easiest 
way to make linux bootable is to put grub into EFI/BOOT (and remove 
fbx64.efi fallback binary that attempts to adjust Boot and ignored 
BootOrder on each boot). It is possible to select any boot entry from F9 
menu, but by default it boots from EFI/BOOT/bootx64.efi.



2. On a laptop having ESP partitions on 2 disks, both ones are marked
for usage as ESP. I am unsure if it causes installation error later or
grub is installed on both ones (taking into account single /boot/efi
mount point).


I would assume not, as people complain about this as a single point of
failure in UEFI booting. I haven't tried repeating "Install the GRUB
boot loader" from the Main Menu, but I don't see why it shouldn't
work. But I don't think that that would get you two entries in NVRAM
without playing some tricks.


On that HP laptop I manually installed grub to second ESP. The result is 
2 indistinguishable entries in F9 boot menu. The text is taken from 
shim/BOOTX64.CSV, no other hints displayed.

Re: "Bug" in Debian Installer?

[David Wright]

On Fri 21 Apr 2023 at 09:48:43 (+0700), Max Nikulin wrote:

> Opt-out variant for ESP sounds reasonable for me. However I am unsure
> if it is possible to complete installation with no ESP at all.

If you mean: to install Grub but not write to the ESP, I think you can
do this by saying Yes to:

┌─┤ [!] Install the GRUB boot loader ├──┐
│   │
│ The following other operating systems have been detected on this  │
│ computer: Debian GNU/Linux 11 (bullseye)  │
│   │
│ If all of your operating systems are listed above, then it should be  │
│ safe to install the boot loader to your primary drive (UEFI   │
│ partition/boot record). When your computer boots, you will be able to │
│ choose to load one of these operating systems or the newly installed  │
│ Debian system.│
│   │
│ Install the GRUB boot loader to your primary drive?   │

and Go Back to:

┌──┤ [!] Install the GRUB boot loader ├───┐
│ │
│ You need to make the newly installed system bootable, by installing │
│ the GRUB boot loader on a bootable device. The usual way to do this │
│ is to install GRUB to your primary drive (UEFI partition/boot   │
│ record). You may instead install GRUB to a different drive (or  │
│ partition), or to removable media.  │
│ │
│   Device for boot loader installation:  │

If there was already a working Grub on the disk, then it should be
straightforward to boot by editing one of its menu entries.
With anything less than that, it helps to be familiar with the Grub
rescue prompt.

> What may be considered as issues from my point of view:
> 1. From the disks overview screen it is not immediately obvious that
> installer is going to write to ESP partitions.

If, by disks overview, you mean the screen quoted just above, then no,
it is less obvious than ISTR in the past (up to buster), where MBR was
explicitly mentioned on BIOS machines.

Bullseye had a misfeature where it would, even on a BIOS machine,
solicit installing to the fallback location. I don't know whether
it was the presence of a GPT disk that caused this offer (I have no
MBR disks to try out instead), or whether it was a belt and braces
(suspenders) approach for mitigating buggy UEFI implementations.

If you forget which mode you booted with, then sure-fire confirmation
is given by   # ls /sys/firmware/efi   in VC2/VC3, which is present
only for UEFI. (Doesn't count as obvious, though.)

> 2. On a laptop having ESP partitions on 2 disks, both ones are marked
> for usage as ESP. I am unsure if it causes installation error later or
> grub is installed on both ones (taking into account single /boot/efi
> mount point).

I would assume not, as people complain about this as a single point of
failure in UEFI booting. I haven't tried repeating "Install the GRUB
boot loader" from the Main Menu, but I don't see why it shouldn't
work. But I don't think that that would get you two entries in NVRAM
without playing some tricks.

Cheers,
David.

Re: "Bug" in Debian Installer?

[Max Nikulin]

On 4/15/23 15:51, David Christensen wrote:
>  "Debian GNU/Linux UEFI Installer menu" -> "Install"

On 18/04/2023 15:51, David Christensen wrote:

On 4/17/23 21:47, David Wright wrote:

As in "Permission to break an egg, sir"? Did not pressing Enter in
reply to "Install" imply something?


d-i modifying a disk without explicit notification and permission is 
unacceptable.


d-i modifying NVRAM without explicit notification and permission is 
unacceptable.


These modifications happen at the last installation steps, so they 
hardly could be considered as unintended at least in the case of default 
(not expert) install.


I have tried bookworm RC1 netinst. "Detect disks" + manual partitioning 
detects existing ESP and selects it for ESP. I think, it is reasonable 
default action. I aborted installation, so I can say nothing concerning 
install grub stage.


Perhaps, preparing disk for another machine, you did not expect that you 
have to create another EFI System Partition, to choose it to use as ESP 
and to explicitly tell installer that existing ESP should not be used.


Opt-out variant for ESP sounds reasonable for me. However I am unsure if 
it is possible to complete installation with no ESP at all.


What may be considered as issues from my point of view:
1. From the disks overview screen it is not immediately obvious that 
installer is going to write to ESP partitions.
2. On a laptop having ESP partitions on 2 disks, both ones are marked 
for usage as ESP. I am unsure if it causes installation error later or 
grub is installed on both ones (taking into account single /boot/efi 
mount point).



Do you contribute to d-i?


No, I do not. You may check if your case has been discussed on the 
installer mailing list or in the bug tracker.


I am not sure that the topic starter faced the same issue as you are 
trying to rise since quite few details have been provided so far.

Re: "Bug" in Debian Installer?

[Max Nikulin]

On 18/04/2023 11:47, David Wright wrote:

On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote:


I have never seen a document that completely and accurately explains,
in computer engineering and science terms, the design and
implementation of the boot processes for Debian (or FreeBSD, or
Windows, or macOS) for all the possible combinations of BIOS, UEFI,
MBR, and GPT; including work-arounds such as "protective MBR", "BIOS
Boot Partition", etc..  If anyone knows of such, please provide a
citation.

You might start with:

   https://www.rodsbooks.com/gdisk/whatsgpt.html


The site by Roderick W. Smith contains a lot of invaluable information 
from "first hands" of a developer of a boot loader and of GPT fdisk. 
Sometimes however I had difficulties however to find details related to 
particular question.


Concerning UEFI I have the following links in my notes:

https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/
Adam Williamson. UEFI boot: how does that actually work, then? 
2014-01-25 21:07


https://en.opensuse.org/openSUSE:UEFI
About UEFI

https://www.rodsbooks.com/linux-uefi/
Roderick W. Smith. Linux on UEFI:
A Quick Installation Guide

I do not think a document that "completely and accurately explains..." 
exists at all.

Re: "Bug" in Debian Installer?

[Roy J. Tellason, Sr.]

On Tuesday 18 April 2023 12:47:44 am David Wright wrote:
> > I have never seen a document that completely and accurately explains,
> > in computer engineering and science terms, the design and
> > implementation of the boot processes for Debian (or FreeBSD, or
> > Windows, or macOS) for all the possible combinations of BIOS, UEFI,
> > MBR, and GPT; including work-arounds such as "protective MBR", "BIOS
> > Boot Partition", etc..  If anyone knows of such, please provide a
> > citation.
> 
> You might start with:
> 
>   https://www.rodsbooks.com/gdisk/whatsgpt.html
> 

Thanks for that...

It's clarified some things that I've been wondering about.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: "Bug" in Debian Installer?

[David Christensen]

On 4/17/23 21:47, David Wright wrote:

On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote:



I have never seen a document that completely and accurately explains,
in computer engineering and science terms, the design and
implementation of the boot processes for Debian (or FreeBSD, or
Windows, or macOS) for all the possible combinations of BIOS, UEFI,
MBR, and GPT; including work-arounds such as "protective MBR", "BIOS
Boot Partition", etc..  If anyone knows of such, please provide a
citation.


You might start with:

   https://www.rodsbooks.com/gdisk/whatsgpt.html



Thank you for the link.



I will expand my statement to: d-i should inform the user and obtain
their permission before making changes to a computer.


As in "Permission to break an egg, sir"? Did not pressing Enter in
reply to "Install" imply something?



d-i modifying a disk without explicit notification and permission is 
unacceptable.



d-i modifying NVRAM without explicit notification and permission is 
unacceptable.



Do you contribute to d-i?


David

Re: "Bug" in Debian Installer?

[David Wright]

On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote:
> On 4/17/23 07:41, David Wright wrote:
> > On Mon 17 Apr 2023 at 01:27:45 (-0700), David Christensen wrote:
> > > On 4/16/23 22:08, Max Nikulin wrote:
> > > > On 17/04/2023 09:18, David Christensen wrote:
> > > > > On 4/16/23 03:41, Max Nikulin wrote:
> > > > > > On 16/04/2023 05:51, David Christensen wrote:
> > > > > > > When I moved the 2.5" SATA SSD to a homebrew Intel
> > > > > > > DQ67SW computer and configured BIOS Setup:
> > > > > > > 
> > > > > > >   "Boot" -> "UEFI Boot" -> "Enable"
> > > > > > > 
> > > > > > > The SSD would not boot.
> > > > > > 
> > > > > > New boot entry usually should be created in such case from
> > > > > > EFI Shell,
> > > > 
> > > > I have realized that you may be confused by difference of MBR vs.
> > > > UEFI behavior. For MBR it is enough to choose a disk to boot in
> > > > BIOS, for UEFI it is necessary to add boot entries through EFI
> > > > variables in firmware. Boot entry consists of disk, partition (EFI
> > > > System partition) and path of an .efi file on this partition.
> > > > 
> > > > If so, you may suggest an additional subsection to
> > > > https://wiki.debian.org/UEFI#Troubleshooting_common_issues
> > > 
> > > Are you saying that d-i modifies the CMOS settings of UEFI computers?
> > 
> > I think the preferred name is NVRAM, but yes.
> 
> So, in addition to modifying disks without notifying me or obtaining
> my permission, d-i modified, or attempted to modify, NVRAM settings
> without notifying me or obtaining my permission.

When you run the d-i, there are steps that are generally irrevocable.
Examples would be partitioning, writing random data for an encrypted
filesystem, and writing the MBR. (If you boot the d-i from the hard
disk itself, you have no medium with which to boot the machine when
you screw up the MBR.) I don't think adding material to the ESP, or
running efibootmgr are necessarily seen that way.

> That is disappointing, but thank you for the information.
> 
> 
> > 
> > > > > > > I later discovered that the first install created a
> > > > > > > directory and put files into the Dell's ESP (!).  I
> > > > > > > did not select this, nor do I desire it.  This is a
> > > > > > > defect with d-i:
> > > > > > 
> > > > > > Why do you think it is wrong?
> > > > > 
> > > > > Because OS installers should not modify a disk unless the user
> > > > > authorizes it.
> > > > 
> > > > I agree if a computer is booted into MBR/BIOS/Compatibility mode
> > > > or if expert install is selected. For regular UEFI install it is a
> > > > trade-off since multiple OS loaders may coexist without conflicts.
> > > > User should be asked if new OS should be booted by default
> > > > (BootOrder), adding files to ESP is quite safe.
> > > 
> > > d-i should always ask before writing to disk.
> > 
> > You will certainly be used to this because of years of BIOS/MBR
> > experience. There's always a question of where to install Grub
> > because you might make another OS unbootable, or you might want
> > Grub placed on a particular partition.
> > 
> > With UEFI booting, that doesn't typically come into play, so to
> > provoke your question, you'd probably need low priority/Expert
> > Install, which I don't think you asked for.
> 
> 
> I asked for "Install":
> 
> On 4/15/23 15:51, David Christensen wrote:
> >  "Debian GNU/Linux UEFI Installer menu" -> "Install"

AIUI, from the first menu, that gives you Priority=medium.

> > > > > Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install
> > > > > on February 2, 2020:
> > > > > 
> > > > >   Install GRUB into master boot record    Yes
> > > > >   Device  /dev/sda
> > > > > 
> > > > > That was the proper way to do it.
> > > > 
> > > > Am I right that it was not UEFI install? Certainly overwriting of
> > > > MBR must be acknowledged by the user.
> > > 
> > > The point is that d-i asked before writing to disk.
> > 
> > Yes, it's MBR.
> > 
> > > > > > > The SSD would not boot.
> > 
> > I asked about the partitioning scheme earlier, but no response.
> 
> 
> Here is the current system disk configuration.  It should match the
> failed installation, except that I added the fifth "scratch" partition
> and file system later:
> 
> 2023-04-17 14:21:39 root@taz ~
> # parted /dev/sda u s p free
> Model: ATA INTEL SSDSC2CW06 (scsi)
> Disk /dev/sda: 117231408s
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
> 
> Number  Start   End Size   File system  Name   Flags
> 34s 2047s   2014s  Free Space
>  1  2048s   1953791s1951744s   fat32ESPboot,
> esp
>  2  1953792s3907583s1953792s   ext4 taz_boot
>  3  3907584s5861375s1953792staz_swap_crypt
>  4  5861376s29298687s   23437312s   taz_root_crypt
>  5  29298688s   117229567s  87930880s   taz_scratch_crypt

Re: "Bug" in Debian Installer?

[David Christensen]

On 4/17/23 03:35, Max Nikulin wrote:

My point is that UEFI and MBR install may have different behavior. You 
might underestimate role of implicit conventions and agreements.



I used to think that d-i would inform me and get my permission before 
making changes to my computer.



It is unfortunate that Debian has shattered that belief, but thank you 
for the information.



David

Re: "Bug" in Debian Installer?

[David Christensen]

On 4/17/23 07:41, David Wright wrote:

On Mon 17 Apr 2023 at 01:27:45 (-0700), David Christensen wrote:

On 4/16/23 22:08, Max Nikulin wrote:

On 17/04/2023 09:18, David Christensen wrote:

On 4/16/23 03:41, Max Nikulin wrote:

On 16/04/2023 05:51, David Christensen wrote:

When I moved the 2.5" SATA SSD to a homebrew Intel
DQ67SW computer and configured BIOS Setup:

  "Boot" -> "UEFI Boot" -> "Enable"

The SSD would not boot.


New boot entry usually should be created in such case from
EFI Shell,


I have realized that you may be confused by difference of MBR vs.
UEFI behavior. For MBR it is enough to choose a disk to boot in
BIOS, for UEFI it is necessary to add boot entries through EFI
variables in firmware. Boot entry consists of disk, partition (EFI
System partition) and path of an .efi file on this partition.

If so, you may suggest an additional subsection to
https://wiki.debian.org/UEFI#Troubleshooting_common_issues


Are you saying that d-i modifies the CMOS settings of UEFI computers?


I think the preferred name is NVRAM, but yes.



So, in addition to modifying disks without notifying me or obtaining my 
permission, d-i modified, or attempted to modify, NVRAM settings without 
notifying me or obtaining my permission.



That is disappointing, but thank you for the information.





I later discovered that the first install created a
directory and put files into the Dell's ESP (!).  I
did not select this, nor do I desire it.  This is a
defect with d-i:


Why do you think it is wrong?


Because OS installers should not modify a disk unless the user
authorizes it.


I agree if a computer is booted into MBR/BIOS/Compatibility mode
or if expert install is selected. For regular UEFI install it is a
trade-off since multiple OS loaders may coexist without conflicts.
User should be asked if new OS should be booted by default
(BootOrder), adding files to ESP is quite safe.


d-i should always ask before writing to disk.


You will certainly be used to this because of years of BIOS/MBR
experience. There's always a question of where to install Grub
because you might make another OS unbootable, or you might want
Grub placed on a particular partition.

With UEFI booting, that doesn't typically come into play, so to
provoke your question, you'd probably need low priority/Expert
Install, which I don't think you asked for.



I asked for "Install":

On 4/15/23 15:51, David Christensen wrote:
>  "Debian GNU/Linux UEFI Installer menu" -> "Install"





Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install
on February 2, 2020:

  Install GRUB into master boot record    Yes
  Device  /dev/sda

That was the proper way to do it.


Am I right that it was not UEFI install? Certainly overwriting of
MBR must be acknowledged by the user.


The point is that d-i asked before writing to disk.


Yes, it's MBR.


The SSD would not boot.


I asked about the partitioning scheme earlier, but no response.



Here is the current system disk configuration.  It should match the 
failed installation, except that I added the fifth "scratch" partition 
and file system later:


2023-04-17 14:21:39 root@taz ~
# parted /dev/sda u s p free
Model: ATA INTEL SSDSC2CW06 (scsi)
Disk /dev/sda: 117231408s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End Size   File system  Name 
  Flags

34s 2047s   2014s  Free Space
 1  2048s   1953791s1951744s   fat32ESP 
   boot, esp

 2  1953792s3907583s1953792s   ext4 taz_boot
 3  3907584s5861375s1953792staz_swap_crypt
 4  5861376s29298687s   23437312s   taz_root_crypt
 5  29298688s   117229567s  87930880s   taz_scratch_crypt
117229568s  117231374s  1807s  Free Space

2023-04-17 14:25:51 root@taz ~
# mount | egrep 'boot|mapper' | sort
/dev/mapper/sda4_crypt on / type ext4 (rw,relatime,errors=remount-ro)
/dev/mapper/sda5_crypt on /scratch type ext4 (rw,relatime)
/dev/sda1 on /boot/efi type vfat 
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

/dev/sda2 on /boot type ext4 (rw,relatime)

2023-04-17 14:27:06 root@taz ~
# swapon
NAME  TYPE  SIZE USED PRIO
/dev/dm-1 partition 954M   0B   -2



I'll hazard a guess that the second disk had no ESP on it, so the
original installer set up a dual boot system for Windows and Debian
by adding an entry to the original disk's ESP. No need to quiz the
operator as there would be with a Windows MBR.

When you took the second disk out, it was unbootable as there was
no ESP on it. (That's my guess.) 



During the failed installation, d-i put the directory and files onto the 
primary disk:


On 4/15/23 15:51, David Christensen wrote:
> 2023-04-15 15:10:34 root@taz ~
> # ls -ld /mnt/nvme0n1p1/EFI/debian
> drwxr-xr-x 2 root root 4096 Mar 16 22:19 

Re: "Bug" in Debian Installer?

[David Wright]

On Mon 17 Apr 2023 at 01:27:45 (-0700), David Christensen wrote:
> On 4/16/23 22:08, Max Nikulin wrote:
> > On 17/04/2023 09:18, David Christensen wrote:
> > > On 4/16/23 03:41, Max Nikulin wrote:
> > > > On 16/04/2023 05:51, David Christensen wrote:
> > > > > When I moved the 2.5" SATA SSD to a homebrew Intel
> > > > > DQ67SW computer and configured BIOS Setup:
> > > > > 
> > > > >  "Boot" -> "UEFI Boot" -> "Enable"
> > > > > 
> > > > > The SSD would not boot.
> > > > 
> > > > New boot entry usually should be created in such case from
> > > > EFI Shell,
> > 
> > I have realized that you may be confused by difference of MBR vs.
> > UEFI behavior. For MBR it is enough to choose a disk to boot in
> > BIOS, for UEFI it is necessary to add boot entries through EFI
> > variables in firmware. Boot entry consists of disk, partition (EFI
> > System partition) and path of an .efi file on this partition.
> > 
> > If so, you may suggest an additional subsection to
> > https://wiki.debian.org/UEFI#Troubleshooting_common_issues
> 
> Are you saying that d-i modifies the CMOS settings of UEFI computers?

I think the preferred name is NVRAM, but yes.

> > > > > I later discovered that the first install created a
> > > > > directory and put files into the Dell's ESP (!).  I
> > > > > did not select this, nor do I desire it.  This is a
> > > > > defect with d-i:
> > > > 
> > > > Why do you think it is wrong?
> > > 
> > > Because OS installers should not modify a disk unless the user
> > > authorizes it.
> > 
> > I agree if a computer is booted into MBR/BIOS/Compatibility mode
> > or if expert install is selected. For regular UEFI install it is a
> > trade-off since multiple OS loaders may coexist without conflicts.
> > User should be asked if new OS should be booted by default
> > (BootOrder), adding files to ESP is quite safe.
> 
> d-i should always ask before writing to disk.

You will certainly be used to this because of years of BIOS/MBR
experience. There's always a question of where to install Grub
because you might make another OS unbootable, or you might want
Grub placed on a particular partition.

With UEFI booting, that doesn't typically come into play, so to
provoke your question, you'd probably need low priority/Expert
Install, which I don't think you asked for.

> > > Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install
> > > on February 2, 2020:
> > > 
> > >  Install GRUB into master boot record    Yes
> > >  Device  /dev/sda
> > > 
> > > That was the proper way to do it.
> > 
> > Am I right that it was not UEFI install? Certainly overwriting of
> > MBR must be acknowledged by the user.
> 
> The point is that d-i asked before writing to disk.

Yes, it's MBR.

> > > > > The SSD would not boot.

I asked about the partitioning scheme earlier, but no response.
I'll hazard a guess that the second disk had no ESP on it, so the
original installer set up a dual boot system for Windows and Debian
by adding an entry to the original disk's ESP. No need to quiz the
operator as there would be with a Windows MBR.

When you took the second disk out, it was unbootable as there was
no ESP on it. (That's my guess.) So you zeroed it and reinstalled.

My experience, from having a mixed bag of BIOS/UEFI computers with
GPT disks, has been to always create a BIOS Boot Partition (3MB,
at the start, giving 4MB alignment for the rest of the drive), and
always create a potential ESP ½GB immediately following. On a BIOS
machine, it can make an extra swap as they have less memory anyway,
but the disk is then suitable for conversion to a UEFI environment.
With GPT, you don't have to worry about running out of primary
partitions.

I have one ESP-less laptop, dating from 2004, so I don't think
I'll be moving its 60GB GPT disk into a different machine when
it finally dies.

I did convert one BIOS laptop to UEFI without even reinstalling its
Debian, with encouragement from Felix. That was back in 2022-02 too.

From the UEFI wiki:

 "Once the normal installation process has been completed, the second
  major component with UEFI support comes into play: grub-installer.
  It will install the grub-efi bootloader to the right location in the
  ESP and will use efibootmgr to register that bootloader with the
  firmware. On correctly-working systems, this should work without
  needing any user interaction. This module will automatically find
  the ESP and install its files in the right place, leaving no space
  for confusion on where boot files are saved (as can happen with
  MBR/MS-DOS systems)."

Cheers,
David.

Re: "Bug" in Debian Installer?

[Max Nikulin]

On 17/04/2023 15:27, David Christensen wrote:

On 4/16/23 22:08, Max Nikulin wrote:

On 17/04/2023 09:18, David Christensen wrote:

On 4/16/23 03:41, Max Nikulin wrote:

On 16/04/2023 05:51, David Christensen wrote:
When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer 

...

The SSD would not boot.


New boot entry usually should be created in such case from EFI Shell, 


I have realized that you may be confused by difference of MBR vs. UEFI 
behavior. For MBR it is enough to choose a disk to boot in BIOS, for 
UEFI it is necessary to add boot entries through EFI variables in 
firmware. Boot entry consists of disk, partition (EFI System 
partition) and path of an .efi file on this partition.


Are you saying that d-i modifies the CMOS settings of UEFI computers?


I am unsure concerning precise meaning of CMOS in this context. UEFI 
provides non-volatile storage. Kernel exposes it as 
/sys/firmware/efi/efivars/ . For boot specific variables there is the 
efibootmgr tool. To make firmware aware of a bootable .efi file it is 
necessary to save it location to a variable like Boot. The role of 
the BootOrder variable is to define in which order boot entries are tried.


To make newly installed system bootable, the installer needs to call 
efibootmgr to adjust Boot and BootOrder variables.


At least HP laptops have no menu entry to configure Boot variables 
(OK, single entry may be configured in a rather inconvenient way) and 
shipped without EFI shell. That is why if installer does not modify the 
variables, Debian is not bootable.
I later discovered that the first install created a directory and 
put files into the Dell's ESP (!).  I did not select this, nor do I 
desire it.  This is a defect with d-i:


Why do you think it is wrong?


Because OS installers should not modify a disk unless the user 
authorizes it.


I agree if a computer is booted into MBR/BIOS/Compatibility mode or if 
expert install is selected. For regular UEFI install it is a trade-off 
since multiple OS loaders may coexist without conflicts. User should 
be asked if new OS should be booted by default (BootOrder), adding 
files to ESP is quite safe.


d-i should always ask before writing to disk.


I am not motivated enough to try debian installer in a similar 
configuration, even in a VM. Could you, please, confirm that after 
manual partitioning no one was configured as a ESP to be mounted at 
/boot/efi?


My expectations is the following. At the partitioning stage installer 
detects available ESP and if just single one is recognized it is 
configured by default as /boot/efi mount point. If this configuration 
option is not changed by the user, it is considered as acknowledgment to 
write files to the EFI/debian folder on this partition.


I do not have strong opinion, but I consider it as acceptable that if 
expert install is not enabled then installer may write files to ESP. It 
simplifies procedure for regular installs.


Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on 


 Install GRUB into master boot record    Yes
 Device  /dev/sda


Am I right that it was not UEFI install? Certainly overwriting of MBR 
must be acknowledged by the user.


The point is that d-i asked before writing to disk.


My point is that UEFI and MBR install may have different behavior. You 
might underestimate role of implicit conventions and agreements.

Re: "Bug" in Debian Installer?

[David Christensen]

On 4/16/23 22:08, Max Nikulin wrote:

On 17/04/2023 09:18, David Christensen wrote:

On 4/16/23 03:41, Max Nikulin wrote:

On 16/04/2023 05:51, David Christensen wrote:
When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer 
and configured BIOS Setup:


 "Boot" -> "UEFI Boot" -> "Enable"

The SSD would not boot.


New boot entry usually should be created in such case from EFI Shell, 


I have realized that you may be confused by difference of MBR vs. UEFI 
behavior. For MBR it is enough to choose a disk to boot in BIOS, for 
UEFI it is necessary to add boot entries through EFI variables in 
firmware. Boot entry consists of disk, partition (EFI System partition) 
and path of an .efi file on this partition.


If so, you may suggest an additional subsection to
https://wiki.debian.org/UEFI#Troubleshooting_common_issues



Are you saying that d-i modifies the CMOS settings of UEFI computers?


I later discovered that the first install created a directory and 
put files into the Dell's ESP (!).  I did not select this, nor do I 
desire it.  This is a defect with d-i:


Why do you think it is wrong?


Because OS installers should not modify a disk unless the user 
authorizes it.


I agree if a computer is booted into MBR/BIOS/Compatibility mode or if 
expert install is selected. For regular UEFI install it is a trade-off 
since multiple OS loaders may coexist without conflicts. User should be 
asked if new OS should be booted by default (BootOrder), adding files to 
ESP is quite safe.



d-i should always ask before writing to disk.


Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on 
February 2, 2020:


 Install GRUB into master boot record    Yes
 Device  /dev/sda

That was the proper way to do it.


Am I right that it was not UEFI install? Certainly overwriting of MBR 
must be acknowledged by the user.



The point is that d-i asked before writing to disk.


David

Re: "Bug" in Debian Installer?

[Max Nikulin]

On 17/04/2023 09:18, David Christensen wrote:

On 4/16/23 03:41, Max Nikulin wrote:

On 16/04/2023 05:51, David Christensen wrote:
When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer 
and configured BIOS Setup:


 "Boot" -> "UEFI Boot" -> "Enable"

The SSD would not boot.


New boot entry usually should be created in such case from EFI Shell, 


I have realized that you may be confused by difference of MBR vs. UEFI 
behavior. For MBR it is enough to choose a disk to boot in BIOS, for 
UEFI it is necessary to add boot entries through EFI variables in 
firmware. Boot entry consists of disk, partition (EFI System partition) 
and path of an .efi file on this partition.


If so, you may suggest an additional subsection to
https://wiki.debian.org/UEFI#Troubleshooting_common_issues

I later discovered that the first install created a directory and put 
files into the Dell's ESP (!).  I did not select this, nor do I 
desire it.  This is a defect with d-i:


Why do you think it is wrong?


Because OS installers should not modify a disk unless the user 
authorizes it.


I agree if a computer is booted into MBR/BIOS/Compatibility mode or if 
expert install is selected. For regular UEFI install it is a trade-off 
since multiple OS loaders may coexist without conflicts. User should be 
asked if new OS should be booted by default (BootOrder), adding files to 
ESP is quite safe.


Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on 
February 2, 2020:


     Install GRUB into master boot record    Yes
     Device  /dev/sda

That was the proper way to do it.


Am I right that it was not UEFI install? Certainly overwriting of MBR 
must be acknowledged by the user.

Re: "Bug" in Debian Installer?

[David Christensen]

On 4/16/23 03:41, Max Nikulin wrote:

On 16/04/2023 05:51, David Christensen wrote:
I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst 
CD, booted the CD, and installed Debian:


 "Debian GNU/Linux UEFI Installer menu" -> "Install"
 ...
 "Partitioning method" -> "Manual" -> <2.5" SATA SSD>


Perhaps at this point installer detected EFI system partition that was 
used to install grub:


In the past, d-i "Install" would prompt me regarding GRUB.  This time, 
it did not.

...
When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and 
configured BIOS Setup:


 "Boot" -> "UEFI Boot" -> "Enable"

The SSD would not boot.


New boot entry usually should be created in such case from EFI Shell, by 
efibootmgr, etc. Some firmware allows to choose an .efi file 
(EFI/debian/shimx64.efi) to boot. I do not remember which grub or shim 
script creates EFI boot entry.


I later discovered that the first install created a directory and put 
files into the Dell's ESP (!).  I did not select this, nor do I desire 
it.  This is a defect with d-i:


Why do you think it is wrong?



Because OS installers should not modify a disk unless the user 
authorizes it.



Here are my notes from a debian-9.9.0-amd64-xfce-CD-1 install on 
February 2, 2020:


Install GRUB into master boot recordYes
Device  /dev/sda


That was the proper way to do it.


David

Re: "Bug" in Debian Installer?

[Max Nikulin]

On 16/04/2023 05:51, David Christensen wrote:
I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst CD, 
booted the CD, and installed Debian:


     "Debian GNU/Linux UEFI Installer menu" -> "Install"
     ...
     "Partitioning method" -> "Manual" -> <2.5" SATA SSD>


Perhaps at this point installer detected EFI system partition that was 
used to install grub:


In the past, d-i "Install" would prompt me regarding GRUB.  This time, 
it did not.

...
When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and 
configured BIOS Setup:


     "Boot" -> "UEFI Boot" -> "Enable"

The SSD would not boot.


New boot entry usually should be created in such case from EFI Shell, by 
efibootmgr, etc. Some firmware allows to choose an .efi file 
(EFI/debian/shimx64.efi) to boot. I do not remember which grub or shim 
script creates EFI boot entry.


I later discovered that the first install created a directory and put 
files into the Dell's ESP (!).  I did not select this, nor do I desire 
it.  This is a defect with d-i:


Why do you think it is wrong? EFI system partition is designed to 
contain boot loaders from multiple vendors. A conflict may happen due to 
EFI/BOOT/bootx64.efi, but it is for removable media and for buggy 
firmware (as a workaround).



# ls -l /mnt/nvme0n1p1/EFI/debian
total 5892
-rwxr-xr-x 1 root root 108 Mar 16 22:19 BOOTX64.CSV
-rwxr-xr-x 1 root root   84648 Mar 16 22:19 fbx64.efi


Fallback should create boot entries listed in BOOTX64.CSV if some 
problem with boot is detected. I am unsure concerning changing boot 
order. However this file is invoked by shimx64.efi or grubx64.efi 
(loaded by shim) and I do not expect that shim is booted with no user 
action when a disk is installed into another computer.



-rwxr-xr-x 1 root root 121 Mar 16 22:19 grub.cfg
-rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi
-rwxr-xr-x 1 root root  845480 Mar 16 22:19 mmx64.efi
-rwxr-xr-x 1 root root  934240 Mar 16 22:19 shimx64.efi

So, I agree that d-i "Install" choice has bug(s) when installing Debian 
into a computer with multiple storage devices.


I do not think multiple storage devices is an issue. I suspect that you 
are not happy that by default Debian installer picked existing EFI 
system partition.


Were you trying to prepare a disk for another computer? Did you created 
ESP on that disk and specified mount point? Anyway likely it is a reason 
to enable low priority configuration questions.

Re: "Bug" in Debian Installer? S.W.A.G.

[Jude DaShiell]

7My reason for suggesting changing debconf priority to low was that
perhaps additional questions might have uncovered some strangeness in the
installer.  It was not intended to fix this bug but only as a means to
further analyze the bug.  Apparently those on this list failed to
understand but that's understandable since trolls don't attempt to think
through future probable outcomes of other's proposed actions.


-- Jude  "There are four boxes to be used in
defense of liberty: soap, ballot, jury, and ammo. Please use in that
order." Ed Howdershelt 1940.

On Sun, 16 Apr 2023, Geert Stappers wrote:

> On Sat, Apr 15, 2023 at 07:09:58PM -0400, rhkra...@gmail.com wrote:
> > On Sat, Apr 15, 2023 at 03:37:54PM -0400, Greg Wooledge wrote:
> > > On Sat, Apr 15, 2023 at 07:20:58PM +0200, Geert Stappers wrote:
> > > > [1] I needed a websearch on S.W.A.G.   Did find
> > > > - Sharing Warmth Around the Globe
> > > > -   
> > > > -   
> > > >
> > > } Stopped searching upon
> > > > Something We All Get (tired of hearing)
> > >
> > > I think it's either "Stupid Wild-Ass Guess" or "Silly Wild-Ass Guess".
>
> Yeah, I think it is.
>
>
> > In my experience (and usage) it was "Scientific Wild Ass Guess".
>
> Acknowledge on scientific usage and scientific experience.
>
>
> First appearance of S.W.A.G. in this thread was in a top post.
> That made it a Silly Wild Ass Guess.
>
> Follow up message ( debconf/priority was not changed ) made
> it a Stupid Wild Ass Guess.
>
> Back to "Sharing Warmth Around the Globe":
>
> Replying below previous text helps understanding each other.
>
>
> Regards
> Geert Stappers
>

Re: "Bug" in Debian Installer? S.W.A.G.

[Geert Stappers]

On Sat, Apr 15, 2023 at 07:09:58PM -0400, rhkra...@gmail.com wrote:
> On Sat, Apr 15, 2023 at 03:37:54PM -0400, Greg Wooledge wrote:
> > On Sat, Apr 15, 2023 at 07:20:58PM +0200, Geert Stappers wrote:
> > > [1] I needed a websearch on S.W.A.G.   Did find
> > > - Sharing Warmth Around the Globe
> > > -   
> > > -   
> > > 
> > } Stopped searching upon
> > > Something We All Get (tired of hearing)
> > 
> > I think it's either "Stupid Wild-Ass Guess" or "Silly Wild-Ass Guess".

Yeah, I think it is.


> In my experience (and usage) it was "Scientific Wild Ass Guess".
 
Acknowledge on scientific usage and scientific experience.


First appearance of S.W.A.G. in this thread was in a top post.
That made it a Silly Wild Ass Guess.

Follow up message ( debconf/priority was not changed ) made
it a Stupid Wild Ass Guess.

Back to "Sharing Warmth Around the Globe":

Replying below previous text helps understanding each other.


Regards
Geert Stappers
-- 
Silence is hard to parse

Re: "Bug" in Debian Installer?

[Jude DaShiell]

d-i makes no distinction between nvme and usb.  Maybe another problem is
the chosen installation destination might not be passed to the code that
does the grub install.


-- Jude  "There are four boxes to be used in
defense of liberty: soap, ballot, jury, and ammo. Please use in that
order." Ed Howdershelt 1940.

On Sat, 15 Apr 2023, David Wright wrote:

> On Sat 15 Apr 2023 at 15:51:46 (-0700), David Christensen wrote:
> > On 4/15/23 02:36, Andrew Wood wrote:
> > > Ive just used the Debian 11 installer ISO running from a USB stick
> > > to do an install (AMD64/UEFI) on another USB stick to use as a
> > > 'portable PC'.
> > >
> > > When it got to the Grub install stage I was expecting it to ask me
> > > which disk I wanted Grub installed on as it has in the past but
> > > instead it did not.
> > >
> > > When I came to reboot the PC I found not only had it put Grub on
> > > the USB it had also put on the PCs NVMe SSD overwriting the
> > > Windows bootloader on there.
> > >
> > > Surely it should have prompted which disk I wanted it on? I
> > > thought it was only Windows that trashed other peoples bootloaders
> > > ;)
> >
> > I recently had a similarly confusing experience with a Dell Precision
> > 3630 with an NVMe PCIe SSD, Windows 10 Pro, and BIOS Setup configured
> > as follows:
> >
> > "System Configuration" -> "SATA Operation" -> "AHCI"
> >
> >
> > I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst
> > CD, booted the CD, and installed Debian:
> >
> > "Debian GNU/Linux UEFI Installer menu" -> "Install"
> > ...
> > "Partitioning method" -> "Manual" -> <2.5" SATA SSD>
> > ...
>
> What was the partitioning layout you used on this disk at that time?
>
> > In the past, d-i "Install" would prompt me regarding GRUB.  This time,
> > it did not.
> >
> >
> > When d-i was complete, the computer could boot either Windows or
> > Debian, with suitable BIOS Setup
> >
> > "General" -> "Boot Sequence"
> >
> >
> > When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and
> > configured BIOS Setup:
> >
> > "Boot" -> "UEFI Boot" -> "Enable"
> >
> > The SSD would not boot.
> >
> >
> > I zeroed the SSD and installed Debian again.  The SSD now works in
> > both computers.
> >
> >
> > I later discovered that the first install created a directory and put
> > files into the Dell's ESP (!).  I did not select this, nor do I desire
> > it.  This is a defect with d-i:
> >
> > 2023-04-15 15:10:34 root@taz ~
> > # ls -ld /mnt/nvme0n1p1/EFI/debian
> > drwxr-xr-x 2 root root 4096 Mar 16 22:19 /mnt/nvme0n1p1/EFI/debian
> >
> > 2023-04-15 15:10:36 root@taz ~
> > # ls -l /mnt/nvme0n1p1/EFI/debian
> > total 5892
> > -rwxr-xr-x 1 root root 108 Mar 16 22:19 BOOTX64.CSV
> > -rwxr-xr-x 1 root root   84648 Mar 16 22:19 fbx64.efi
> > -rwxr-xr-x 1 root root 121 Mar 16 22:19 grub.cfg
> > -rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi
> > -rwxr-xr-x 1 root root  845480 Mar 16 22:19 mmx64.efi
> > -rwxr-xr-x 1 root root  934240 Mar 16 22:19 shimx64.efi
> >
> >
> > So, I agree that d-i "Install" choice has bug(s) when installing
> > Debian into a computer with multiple storage devices.
>
> Cheers,
> David.
>
>

Re: "Bug" in Debian Installer?

[David Wright]

On Sat 15 Apr 2023 at 15:51:46 (-0700), David Christensen wrote:
> On 4/15/23 02:36, Andrew Wood wrote:
> > Ive just used the Debian 11 installer ISO running from a USB stick
> > to do an install (AMD64/UEFI) on another USB stick to use as a
> > 'portable PC'.
> > 
> > When it got to the Grub install stage I was expecting it to ask me
> > which disk I wanted Grub installed on as it has in the past but
> > instead it did not.
> > 
> > When I came to reboot the PC I found not only had it put Grub on
> > the USB it had also put on the PCs NVMe SSD overwriting the
> > Windows bootloader on there.
> > 
> > Surely it should have prompted which disk I wanted it on? I
> > thought it was only Windows that trashed other peoples bootloaders
> > ;)
> 
> I recently had a similarly confusing experience with a Dell Precision
> 3630 with an NVMe PCIe SSD, Windows 10 Pro, and BIOS Setup configured
> as follows:
> 
> "System Configuration" -> "SATA Operation" -> "AHCI"
> 
> 
> I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst
> CD, booted the CD, and installed Debian:
> 
> "Debian GNU/Linux UEFI Installer menu" -> "Install"
> ...
> "Partitioning method" -> "Manual" -> <2.5" SATA SSD>
> ...

What was the partitioning layout you used on this disk at that time?

> In the past, d-i "Install" would prompt me regarding GRUB.  This time,
> it did not.
> 
> 
> When d-i was complete, the computer could boot either Windows or
> Debian, with suitable BIOS Setup
> 
> "General" -> "Boot Sequence"
> 
> 
> When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and
> configured BIOS Setup:
> 
> "Boot" -> "UEFI Boot" -> "Enable"
> 
> The SSD would not boot.
> 
> 
> I zeroed the SSD and installed Debian again.  The SSD now works in
> both computers.
> 
> 
> I later discovered that the first install created a directory and put
> files into the Dell's ESP (!).  I did not select this, nor do I desire
> it.  This is a defect with d-i:
> 
> 2023-04-15 15:10:34 root@taz ~
> # ls -ld /mnt/nvme0n1p1/EFI/debian
> drwxr-xr-x 2 root root 4096 Mar 16 22:19 /mnt/nvme0n1p1/EFI/debian
> 
> 2023-04-15 15:10:36 root@taz ~
> # ls -l /mnt/nvme0n1p1/EFI/debian
> total 5892
> -rwxr-xr-x 1 root root 108 Mar 16 22:19 BOOTX64.CSV
> -rwxr-xr-x 1 root root   84648 Mar 16 22:19 fbx64.efi
> -rwxr-xr-x 1 root root 121 Mar 16 22:19 grub.cfg
> -rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi
> -rwxr-xr-x 1 root root  845480 Mar 16 22:19 mmx64.efi
> -rwxr-xr-x 1 root root  934240 Mar 16 22:19 shimx64.efi
> 
> 
> So, I agree that d-i "Install" choice has bug(s) when installing
> Debian into a computer with multiple storage devices.

Cheers,
David.

Re: "Bug" in Debian Installer?

[rhkramer]

On Saturday, April 15, 2023 03:37:54 PM Greg Wooledge wrote:
> I think it's either "Stupid Wild-Ass Guess" or "Silly Wild-Ass Guess".

In my experience (and usage) it was "Scientific Wild Ass Guess".

-- 
rhk 
  
| No entity has permission to use this email to train an AI. 

Re: "Bug" in Debian Installer?

[David Christensen]

On 4/15/23 02:36, Andrew Wood wrote:
Ive just used the Debian 11 installer ISO running from a USB stick to do 
an install (AMD64/UEFI) on another USB stick to use as a 'portable PC'.


When it got to the Grub install stage I was expecting it to ask me which 
disk I wanted Grub installed on as it has in the past but instead it did 
not.


When I came to reboot the PC I found not only had it put Grub on the USB 
it had also put on the PCs NVMe SSD overwriting the Windows bootloader 
on there.


Surely it should have prompted which disk I wanted it on? I thought it 
was only Windows that trashed other peoples bootloaders ;)


Regards

Andrew



I recently had a similarly confusing experience with a Dell Precision 
3630 with an NVMe PCIe SSD, Windows 10 Pro, and BIOS Setup configured as 
follows:


"System Configuration" -> "SATA Operation" -> "AHCI"


I installed a 2.5" SATA SSD, inserted a debian-11.6.0-amd64-netinst CD, 
booted the CD, and installed Debian:


"Debian GNU/Linux UEFI Installer menu" -> "Install"
...
"Partitioning method" -> "Manual" -> <2.5" SATA SSD>
...

In the past, d-i "Install" would prompt me regarding GRUB.  This time, 
it did not.



When d-i was complete, the computer could boot either Windows or Debian, 
with suitable BIOS Setup


"General" -> "Boot Sequence"


When I moved the 2.5" SATA SSD to a homebrew Intel DQ67SW computer and 
configured BIOS Setup:


"Boot" -> "UEFI Boot" -> "Enable"

The SSD would not boot.


I zeroed the SSD and installed Debian again.  The SSD now works in both 
computers.



I later discovered that the first install created a directory and put 
files into the Dell's ESP (!).  I did not select this, nor do I desire 
it.  This is a defect with d-i:


2023-04-15 15:10:34 root@taz ~
# ls -ld /mnt/nvme0n1p1/EFI/debian
drwxr-xr-x 2 root root 4096 Mar 16 22:19 /mnt/nvme0n1p1/EFI/debian

2023-04-15 15:10:36 root@taz ~
# ls -l /mnt/nvme0n1p1/EFI/debian
total 5892
-rwxr-xr-x 1 root root 108 Mar 16 22:19 BOOTX64.CSV
-rwxr-xr-x 1 root root   84648 Mar 16 22:19 fbx64.efi
-rwxr-xr-x 1 root root 121 Mar 16 22:19 grub.cfg
-rwxr-xr-x 1 root root 4150720 Mar 16 22:19 grubx64.efi
-rwxr-xr-x 1 root root  845480 Mar 16 22:19 mmx64.efi
-rwxr-xr-x 1 root root  934240 Mar 16 22:19 shimx64.efi


So, I agree that d-i "Install" choice has bug(s) when installing Debian 
into a computer with multiple storage devices.



David

Re: "Bug" in Debian Installer?

[Greg Wooledge]

On Sat, Apr 15, 2023 at 07:20:58PM +0200, Geert Stappers wrote:
> [1] I needed a websearch on S.W.A.G.   Did find
> - Sharing Warmth Around the Globe
> - Sealed With A Gift
> - Stolen Without A Gun
> - So What? Another Giveaway?
> - Sub-Watershed Advisory Group
> - Some Women Are Great
> - Souvenirs Wearables and Gifts
> 
> Stop searching upon
> Something We All Get (tired of hearing)

I think it's either "Stupid Wild-Ass Guess" or "Silly Wild-Ass Guess".

Re: "Bug" in Debian Installer?

[Geert Stappers]

On Sat, Apr 15, 2023 at 06:24:34PM +0100, Andrew Wood wrote:
> On 15/04/2023 18:20, Geert Stappers wrote:
> > On Sat, Apr 15, 2023 at 11:02:02AM -0400, Jude DaShiell wrote:
> > > On Sat, 15 Apr 2023, Geert Stappers wrote:
> > > > On Sat, Apr 15, 2023 at 10:36:14AM +0100, Andrew Wood wrote:
> > > > > 
> > > > > Surely it should have prompted which disk I wanted it on?
> > > >
> > > > Yes.  And it does. Normally.
> > > >
> > > Priority of questions asked was not set to low in the
> > > main menu.  I routinely change that to low when doing a debian install and
> > > preserve logs for future reference.  Default priority if memory serves is
> > > medium.
> > 
> > Time will tell if original poster shares information
> > on whether or not if priority for debian-install was changed.
> 
> Nothing was changed. I dont even know what that is.

Quoting debian-installer manual:


debconf/priority (priority)

This parameter sets the lowest priority of messages to be displayed.

The default installation uses priority=high. This means that both
high and critical priority messages are shown, but medium and low
priority messages are skipped. If problems are encountered, the
installer adjusts the priority as needed.

If you add priority=medium as boot parameter, you will be shown the
installation menu and gain more control over the installation. When
priority=low is used, all messages are shown (this is equivalent to
the expert boot method). With priority=critical, the installation
system will display only critical messages and try to do the right
thing without fuss.



> Ive installed Debian on many  systems over the past 12 years

Acknowledge.


> and have never altered a 'priority' in the installer.
 
Make it possible to answer the question from the subject line.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: "Bug" in Debian Installer?

[Jude DaShiell]

You've never seen debian main menu in the installer.  That's selection 19
on that main menu and selection 21 helps big time with debugging since you
choose that to save log files and selection 3 under that will save logs to
/var/log/installer directory.  Two ways to get to main menu.  First and
slowest is to hit < sign several times until the menu comes up once
installer started.  Second, use boot options and a enter i enter x enter I
think will put you in the installer main menu when the installer comes up.
I usually do a  i  s  "There are four boxes to be used in
defense of liberty: soap, ballot, jury, and ammo. Please use in that
order." Ed Howdershelt 1940.

On Sat, 15 Apr 2023, Andrew Wood wrote:

>
> On 15/04/2023 18:20, Geert Stappers wrote:
> > Time will tell if original poster shares information
> > on whether or not if priority for debian-install was changed.
>
>
> Nothing was changed. I dont even know what that is. Ive installed Debian on
> many  systems over the past 12 years and have never altered a 'priority' in
> the installer.
>
>
>

Re: "Bug" in Debian Installer?

[Andrew Wood]

On 15/04/2023 18:20, Geert Stappers wrote:

Time will tell if original poster shares information
on whether or not if priority for debian-install was changed.



Nothing was changed. I dont even know what that is. Ive installed Debian 
on many  systems over the past 12 years and have never altered a 
'priority' in the installer.

Re: "Bug" in Debian Installer?

[Geert Stappers]

On Sat, Apr 15, 2023 at 11:02:02AM -0400, Jude DaShiell wrote:
> On Sat, 15 Apr 2023, Geert Stappers wrote:
> > On Sat, Apr 15, 2023 at 10:36:14AM +0100, Andrew Wood wrote:
> > > Ive just used the Debian 11 installer ISO running from a USB stick to do 
> > > an
> > > install (AMD64/UEFI) on another USB stick to use as a 'portable PC'.
> > >
> > > When it got to the Grub install stage I was expecting it to ask me which
> > > disk I wanted Grub installed on as it has in the past but instead it did
> > > not.
> >
> > Way before "grub install" should have been asked
> >
> >On which disk to install
> >
> >
> > > When I came to reboot the PC I found not only had it put Grub on the USB 
> > > it
> > > had also put on the PCs NVMe SSD overwriting the Windows bootloader on
> > > there.
> >
> > I do read "two devices were effected", I think it is the same error of
> >
> >
> >On which disk to install
> >
> >
> >
> > > Surely it should have prompted which disk I wanted it on?
> >
> > Yes.  And it does. Normally.
> >
> 
> A s.w.a.g. here.  

[1]


> Priority of questions asked was not set to low in the
> main menu.  I routinely change that to low when doing a debian install and
> preserve logs for future reference.  Default priority if memory serves is
> medium.

Time will tell if original poster shares information
on whether or not if priority for debian-install was changed.


> > Please make it possible to reproduce what is encountered.
> > Yeah, I would like to known what happened
> > and I say right now there is not enough information to reproduce.

So we might be able to answer the question

 "Bug" in Debian Installer?

stated in the Subject line.



Groeten
Geert Stappers

[1] I needed a websearch on S.W.A.G.   Did find
- Sharing Warmth Around the Globe
- Sealed With A Gift
- Stolen Without A Gun
- So What? Another Giveaway?
- Sub-Watershed Advisory Group
- Some Women Are Great
- Souvenirs Wearables and Gifts

Stop searching upon
Something We All Get (tired of hearing)

-- 
Super Wacky And Great

Re: "Bug" in Debian Installer?

[Andrew Wood]

On 15/04/2023 14:12, Geert Stappers wrote:


Way before "grub install" should have been asked

On which disk to install

  
I do read "two devices were effected", I think it is the same error of



On which disk to install


If you mean did it install Debian on the NVme ssd then no, the Windows 
paritition was not touched.


I was able to restore the Windows bootloader from the Win 11 ISO command 
line and boot again. I could even boot Windows from the Grub menu having 
booted Grub from the USB, but with the USB removed the NVMe SSD just 
gave a Grub prompt.

Re: "Bug" in Debian Installer?

[Jude DaShiell]

A s.w.a.g. here.  Priority of questions asked was not set to low in the
main menu.  I routinely change that to low when doing a debian install and
preserve logs for future reference.  Default priority if memory serves is
medium.


-- Jude  "There are four boxes to be used in
defense of liberty: soap, ballot, jury, and ammo. Please use in that
order." Ed Howdershelt 1940.

On Sat, 15 Apr 2023, Geert Stappers wrote:

> On Sat, Apr 15, 2023 at 10:36:14AM +0100, Andrew Wood wrote:
> > Ive just used the Debian 11 installer ISO running from a USB stick to do an
> > install (AMD64/UEFI) on another USB stick to use as a 'portable PC'.
> >
> > When it got to the Grub install stage I was expecting it to ask me which
> > disk I wanted Grub installed on as it has in the past but instead it did
> > not.
>
> Way before "grub install" should have been asked
>
>On which disk to install
>
>
> > When I came to reboot the PC I found not only had it put Grub on the USB it
> > had also put on the PCs NVMe SSD overwriting the Windows bootloader on
> > there.
>
> I do read "two devices were effected", I think it is the same error of
>
>
>On which disk to install
>
>
>
> > Surely it should have prompted which disk I wanted it on?
>
> Yes.  And it does. Normally.
>
>
> Please make it possible to reproduce what is encountered.
> Yeah, I would like to known what happened
> and I say right now there is not enough information to reproduce.
>
>
> Groeten
> Geert Stappers
>

Re: "Bug" in Debian Installer?

[Geert Stappers]

On Sat, Apr 15, 2023 at 10:36:14AM +0100, Andrew Wood wrote:
> Ive just used the Debian 11 installer ISO running from a USB stick to do an
> install (AMD64/UEFI) on another USB stick to use as a 'portable PC'.
> 
> When it got to the Grub install stage I was expecting it to ask me which
> disk I wanted Grub installed on as it has in the past but instead it did
> not.

Way before "grub install" should have been asked

   On which disk to install

 
> When I came to reboot the PC I found not only had it put Grub on the USB it
> had also put on the PCs NVMe SSD overwriting the Windows bootloader on
> there.

I do read "two devices were effected", I think it is the same error of


   On which disk to install


 
> Surely it should have prompted which disk I wanted it on?

Yes.  And it does. Normally.


Please make it possible to reproduce what is encountered.
Yeah, I would like to known what happened
and I say right now there is not enough information to reproduce.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: quite the end of an era: Re: Bug#931659: transition: rm python2

[Steve McIntyre]

Greg wrote:
>On Wed, Jan 11, 2023 at 10:42:31PM +, Tim Woodall wrote:
>> On Tue, 10 Jan 2023, songbird wrote:
>> 
>> >  kudoes to everyone who helped with this in getting it done, finding
>> > bugs, fixing problems, converting code, updating docs and testing.  :)
>> > 
>> 
>> What does debian use for moinmoin? Is the debian wiki stuck on buster?
>
>I was wondering exactly the same thing, a few months ago.  I asked on
>the Libera #debian IRC channel, and nobody knew.  (Fair enough.)
>
> shows the Python version:
>2.7.16 (default, Oct 10 2019, 22:02:15) [GCC 8.3.0]
>
>This is precisely the same as mine shows, and mine is running on buster.
>So my tentative conclusion is that wiki.debian.org is still hosted on
>a buster machine (virtual or physical).  I'm wondering what the path
>forward is for us.

Correct, we're still on buster for now.

I'm *hoping* to move forwards to moin 2 on python 3 at some point
soon, and Paul Boddie has been doing some great work on the ackaging
front there. But there's a bit more work needed yet all round.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Re: quite the end of an era: Re: Bug#931659: transition: rm python2

[Greg Wooledge]

On Wed, Jan 11, 2023 at 10:42:31PM +, Tim Woodall wrote:
> On Tue, 10 Jan 2023, songbird wrote:
> 
> >  kudoes to everyone who helped with this in getting it done, finding
> > bugs, fixing problems, converting code, updating docs and testing.  :)
> > 
> 
> What does debian use for moinmoin? Is the debian wiki stuck on buster?

I was wondering exactly the same thing, a few months ago.  I asked on
the Libera #debian IRC channel, and nobody knew.  (Fair enough.)

 shows the Python version:
2.7.16 (default, Oct 10 2019, 22:02:15) [GCC 8.3.0]

This is precisely the same as mine shows, and mine is running on buster.
So my tentative conclusion is that wiki.debian.org is still hosted on
a buster machine (virtual or physical).  I'm wondering what the path
forward is for us.

Re: quite the end of an era: Re: Bug#931659: transition: rm python2

[Tim Woodall]

On Tue, 10 Jan 2023, songbird wrote:


 kudoes to everyone who helped with this in getting it done, finding
bugs, fixing problems, converting code, updating docs and testing.  :)



What does debian use for moinmoin? Is the debian wiki stuck on buster?

quite the end of an era: Re: Bug#931659: transition: rm python2

[songbird]

  kudoes to everyone who helped with this in getting it done, finding
bugs, fixing problems, converting code, updating docs and testing.  :)


  songbird

Re: BUG FIREFOX-ESR 102.1, al cargar chat messegnger en facebook

[Gerardo Braica]

Saludos Dennis.

Yo estoy usando la version 107 en dos equipos y no tengo problemas.
Si quieres probar solamente tienes que agregar el repositorio de MX a los
sources y lo vera inmediatamente. Espero sirva.

|deb http://mxrepo.com/mx/repo/ bullseye main non-free


|
El 7/12/22 a las 01:57, Dennis Erazo escribió:
Saludos equipo de Debian 11 bullseyes, tegno instalado en mi maquina 
esta version, el bug seria en el navegador firefox-esr la ultima 
version ya que posee un bug, en el chat de messenger de facebook, ya 
que se cierre inesperadamente, la pestaña con la red social, y se 
cierra el navegador, ahorit tuve que retorceder a la version 91 que 
estaba po defecto, ya que esta version funciona completamentebien, 
favor arreglar ese bug en la sigiente actualizacion del navegador... 
Gracias, adiconal a esto, se siente con la nueva version como medio 
lento la mquina, lo cual no pasa en la version anterior que esta de 
fabrica.




--
*/Gerardo Braica
*/gbra...@gmail.com.ar
/*/*

Re: Bug - remote DNS monitoring

[Casey Deccio]

> On Aug 30, 2022, at 1:12 PM, Casey Deccio  wrote:
> 
> I am having trouble tracking down a bug in my monitoring setup.  It all 
> happened when I upgraded the monitored host (host B in my example below) to 
> bullseye.  Note that Host A is also running bullseye, but the problem didn't 
> show itself until Host B was upgraded.

With some help over at the bind-users mailing list [1], I discovered that 
nrpe-ng closes stdin when launching the command [2], and the new version of 
nslookup (invoked by check_dns) has issues when stdin is closed [3].

Redirecting stdin to /dev/null fixes the issue:

$ diff -u /usr/lib/python3/dist-packages/nrpe_ng/commands.py{.old,}
--- /usr/lib/python3/dist-packages/nrpe_ng/commands.py.old  2017-08-08 
13:05:02.0 -0600
+++ /usr/lib/python3/dist-packages/nrpe_ng/commands.py  2022-09-13 
17:00:36.767239885 -0600
@@ -85,6 +85,7 @@

 proc = tornado.process.Subprocess(
 run_args,
+stdin=subprocess.DEVNULL,
 stdout=tornado.process.Subprocess.STREAM,
 close_fds=True,
 env=env)

I've filed a bug report [4].

Thanks,
Casey

[1] https://lists.isc.org/pipermail/bind-users/2022-September/10.html
[2] https://github.com/bootc/nrpe-ng/blob/master/nrpe_ng/commands.py#L86
[3] https://github.com/libuv/libuv/blob/v1.x/src/unix/core.c#L602
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019718

Re: bug al actualizar Debian 11

[tomas]

On Thu, Sep 08, 2022 at 06:22:47PM -0400, José Eduardo Niño wrote:
> Hola. Soy José Niño.

Hola, José

esta lista comunica en inglés. Por consecuencia, la mayoría aquí
no podrá ayudarte.

En caso que prefieras comunicar en castellano: hay una lista en
castellano por aquí:

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

En cuanto a tu problema, si tu sistema operativo puede detectar
la SD después de arrancar de nuevo, yo buscaría primero en el
"desktop environment": parece que los drivers funcionan, ¿no?

Saludos
-- 
tomás


signature.asc
Description: PGP signature

Re: Bug - remote DNS monitoring

[Casey Deccio]

> On Aug 30, 2022, at 1:40 PM, Nicholas Geovanis  wrote:
> 
> When you run check_dns by hand on Host B, you don't say who you are logged-in 
> as. That can make a difference. Nagios runs its scripts in a known 
> environment which may be different than you expect.
> 


Thanks for the question.  I have run the check_dns script with:

 - an arbitrary, unprivileged user
 - the nagios user (also unprivileged)
 - root (gasp!)

They all work just fine.  Also, in every case, I run tcpdump, and I can see the 
DNS queries and responses going back and forth just fine.  In the strace 
messages, I can also see that the DNS messages were written and read properly.  
I think the issue is in nslookup, some time *after* the send/recv.  But I can't 
narrow it down much more than that.

Casey

Re: Bug - remote DNS monitoring

[Nicholas Geovanis]

On Tue, Aug 30, 2022, 2:13 PM Casey Deccio  wrote:

> Hi all,
>
> I am having trouble tracking down a bug in my monitoring setup.  It all
> happened when I upgraded the monitored host (host B in my example below) to
> bullseye.  Note that Host A is also running bullseye, but the problem
> didn't show itself until Host B was upgraded.
>
> Here is the setup:
>
> Host A (monitoring):
> Installed: nagios4, nrpe-ng
> IP address: 192.0.2.1
>
> Host B (monitored):
> Installed: nrpe-ng, monitoring-plugins-standard, bind9-dnsutils
> IP address: 192.0.2.2
>
> Host C (monitored through host B):
> Installed: bind9
> IP address: 192.0.2.3
> Configured to answer authoritatively for example.com on port 53.
>
>  nrpe
> over HTTPs  DNS
> Host A --> Host B -> Host C
>

When you run check_dns by hand on Host B, you don't say who you are
logged-in as. That can make a difference. Nagios runs its scripts in a
known environment which may be different than you expect.

On Host B, I run the following:
> sudo /usr/bin/python3 /usr/sbin/nrpe-ng --debug -f --config
> /etc/nagios/nrpe-ng.cfg
>
> While that is running, I run the following on Host A:
> /usr/lib/nagios/plugins/check_nrpe_ng -H 192.0.2.2 -c check_dns -a
> example.com 192.0.2.3 0.1 1.0
>
> The result of running the command on Host A is:
> DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address
>
> On Host B, I see the following debug output:
> 200 POST /v1/check/check_dns (192.0.2.1) 78.05ms
> Executing: /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3
> -A -w 0.1 -c 1.0
>
> When I run this exact command on Host B, I get:
> $ /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 -A -w 0.1
> -c 1.0
> DNS OK: 0.070 seconds response time. example.com returns
> 192.0.2.10,2001:db8::10|time=0.069825s;0.10;1.00;0.00
>
> Looks good!  When I run nslookup (run by check_dns), it looks good too:
> $ /usr/bin/nslookup -sil example.com 192.0.2.3
> Server: 192.0.2.3
> Address: 192.0.2.3#53
>
> Name: example.com
> Address: 192.0.2.10
> Name: example.com
> Address: 2001:db8::10
>
> After rerunning nrpe-ng with strace -f, I see something:
>
> [pid 1183842] write(2, "nslookup: ./src/unix/core.c:570:"..., 83) = 83
> ...
> [pid 1183841] read(4, "nslookup: ./src/unix/core.c:570:"..., 4096) = 83
>
> So it appears that the nslookup process is reporting an error.  But I
> cannot reproduce it outside of nrpe-ng.
>
> Any suggestions?
>
> Casey
>

Re: Bug 895378 has been fixed on Ubuntu, will it get to Debian?

[Richmond]

Richmond  writes:

> This bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895378
>
> sky2: sky2: did not recover correctly after waking up from S3
>
> seems to be fixed on Ubuntu here:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921
>
> Will this fix get to Debian? I guess it will go up to kernel maintainers
> and down again but I don't know how this works.

Fixed with this kernel command line parameter:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash sky2.disable_msi=1"

in file /etc/default/grub

run:

update-grub

Re: BUG: Debian 11 version of bibletime

[Andrei POPESCU]

On Ma, 21 dec 21, 05:31:31, Richard Owlett wrote:
> On 12/18/2021 08:55 AM, Andrei POPESCU wrote:
> > On Sb, 18 dec 21, 07:00:56, Richard Owlett wrote:
> > > > 
> > > > Please demonstrate this by showing us the actual run of apt-file as well
> > > > as the output of
> > > > 
> > > >   dpkg -L bibletime-data
> 
> At ~100 kB and > 1300 lines, too big for a news group.

Compressed it would probably be fine.

Anyway, this would point to all files being there, possibly not where 
you expected them, though. On a bullseye system the output of
`apt-file show bibletime-data | wc -l` gives 1296.

> > Care to provide these as well?
> 
> What sub-command of apt-file?

The ones you used to determine that something is missing for you ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: BUG: Debian 11 version of bibletime - was [Re: Problems with "Bible Time" and "Xiphos"]

[Curt]

On 2021-12-13, Richard Owlett  wrote:
>
> Further investigation of the Debian 11 filesystem shows that
> /usr/share/bibletime/docs does not exist.
>

That's probably because the handbook and howto in bullseye reside in

 /usr/share/doc/bibletime-data/bibletime/

according to the results of my brief investigation into the matter.
They're keeping us on our toes, I guess.

Hallelujah, brother.

Re: BUG: Debian 11 version of bibletime

[Richard Owlett]

On 12/18/2021 08:55 AM, Andrei POPESCU wrote:

On Sb, 18 dec 21, 07:00:56, Richard Owlett wrote:


Please demonstrate this by showing us the actual run of apt-file as well
as the output of

  dpkg -L bibletime-data


At ~100 kB and > 1300 lines, too big for a news group. Also I'm up 
against a data cap for another couple of weeks.


  
Care to provide these as well?


What sub-command of apt-file?

Re: BUG: Debian 11 version of bibletime

[Andrei POPESCU]

On Sb, 18 dec 21, 07:00:56, Richard Owlett wrote:
> > 
> > Please demonstrate this by showing us the actual run of apt-file as well
> > as the output of
> > 
> >  dpkg -L bibletime-data
 
Care to provide these as well?
 
> richard@debian-11:~$ su
> Password:
> root@debian-11:/home/richard# dpkg -l bibletime\*
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   Version  Architecture Description
> +++-==---==>
> ii  bibletime  3.0-5amd64bible study tool for Qt
> ii  bibletime-data 3.0-5all  Documentation and data for
> bibleti>
> un  bibletime-i18n   (no description available)
> lines 1-8/8 (END)
> 
> I see the same on Sid. In both cases Synaptic states the repository is
>http://deb.debian.org/debian
> 
> I've also found https://deb.debian.org/ which states:
> > The server deb.debian.org does not have packages itself, but the name has
> > SRV records in DNS that let apt in stretch and later find places.
> 
> The *LAST* package installed by Synaptic was bibletime. In which log-file do
> I look to find the *EXACT* URL bibletime was retrieved from.
> 
> IIRC there is some load sharing going on in the background which would
> account for me retrieving different files than others.

See https://packages.debian.org/bullseye/all/bibletime-data/download for 
the MD5 checksum (if you worry about integrity) and the SHA256 checksum 
(if you worry about tampering) of the .deb file.

You can compare these against the .deb file in /var/cache/apt/archives.

My money is on a match and this is a blind alley.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: BUG: Debian 11 version of bibletime

[Richard Owlett]

On 12/18/2021 04:05 AM, Andrei POPESCU wrote:

On Ma, 14 dec 21, 04:20:00, Richard Owlett wrote:

On 12/13/2021 08:10 PM, Felix Miata wrote:

Richard Owlett composed on 2021-12-13 12:18 (UTC-0600):


I reinstalled bibletime and xiphos.
Using bibletime I installed Bible, concordance, etc.
F1 and F2 do NOT display the appropriate help files.


Are you sure you installed everything bibletime /wants/?


I might be phrased as "I ordered it all but the the repository (i.e URL)
contacted did not contain all that is evidently residing at other URL's".

I.E. I used Synaptic to install
  bibletime  -- bible study tool for Qt
AND
  bibletime-data -- Documentation and data for bibletime


Please demonstrate this with the output of

 dpkg -l bibletime\*

  

When Erwan David (in Europe) performed "apt-file search bibletime" the
handbook files were displayed.

When I (in Missouri USA) run it against Debian 11 I do not see handbook
files. I *DO* see the handbook files when running it against Debian 10.



I've done a fresh install of Debian 11 using the same copy of dvd1.iso .
I then installed bibletime. F1 and F2 still do not work.
I also installed Sid. Bibletime installed properly there.



IOW I am convinced I am observing a repository problem, *NOT* operator
error.


Please demonstrate this by showing us the actual run of apt-file as well
as the output of

 dpkg -L bibletime-data



richard@debian-11:~$ su
Password:
root@debian-11:/home/richard# dpkg -l bibletime\*
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---==>
ii  bibletime  3.0-5amd64bible study tool for Qt
ii  bibletime-data 3.0-5all  Documentation and data for 
bibleti>

un  bibletime-i18n   (no description available)
lines 1-8/8 (END)

I see the same on Sid. In both cases Synaptic states the repository is
   http://deb.debian.org/debian

I've also found https://deb.debian.org/ which states:

The server deb.debian.org does not have packages itself, but the name has
SRV records in DNS that let apt in stretch and later find places. 


The *LAST* package installed by Synaptic was bibletime. In which 
log-file do I look to find the *EXACT* URL bibletime was retrieved from.


IIRC there is some load sharing going on in the background which would 
account for me retrieving different files than others.

Re: BUG: Debian 11 version of bibletime

[Andrei POPESCU]

On Ma, 14 dec 21, 04:20:00, Richard Owlett wrote:
> On 12/13/2021 08:10 PM, Felix Miata wrote:
> > Richard Owlett composed on 2021-12-13 12:18 (UTC-0600):
> > 
> > > I reinstalled bibletime and xiphos.
> > > Using bibletime I installed Bible, concordance, etc.
> > > F1 and F2 do NOT display the appropriate help files.  
> > > 
> > Are you sure you installed everything bibletime /wants/?
> 
> I might be phrased as "I ordered it all but the the repository (i.e URL)
> contacted did not contain all that is evidently residing at other URL's".
> 
> I.E. I used Synaptic to install
>  bibletime  -- bible study tool for Qt
>AND
>  bibletime-data -- Documentation and data for bibletime

Please demonstrate this with the output of

dpkg -l bibletime\*

 
> When Erwan David (in Europe) performed "apt-file search bibletime" the
> handbook files were displayed.
> 
> When I (in Missouri USA) run it against Debian 11 I do not see handbook
> files. I *DO* see the handbook files when running it against Debian 10.
> 
> IOW I am convinced I am observing a repository problem, *NOT* operator
> error.

Please demonstrate this by showing us the actual run of apt-file as well 
as the output of

dpkg -L bibletime-data


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: BUG: Debian 11 version of bibletime

[David Wright]

On Tue 14 Dec 2021 at 04:20:00 (-0600), Richard Owlett wrote:
> On 12/13/2021 08:10 PM, Felix Miata wrote:
> > Richard Owlett composed on 2021-12-13 12:18 (UTC-0600):
> > 
> > > I reinstalled bibletime and xiphos.
> > > Using bibletime I installed Bible, concordance, etc.
> > > F1 and F2 do NOT display the appropriate help files.
> > Are you sure you installed everything bibletime /wants/?
> 
> I might be phrased as "I ordered it all but the the repository (i.e
> URL) contacted did not contain all that is evidently residing at other
> URL's".
> 
> I.E. I used Synaptic to install
>  bibletime  -- bible study tool for Qt
>AND
>  bibletime-data -- Documentation and data for bibletime
> 
> When Erwan David (in Europe) performed "apt-file search bibletime" the
> handbook files were displayed.
> 
> When I (in Missouri USA) run it against Debian 11 I do not see
> handbook files. I *DO* see the handbook files when running it against
> Debian 10.
> 
> IOW I am convinced I am observing a repository problem, *NOT* operator
> error.

/tmp/btd $ ls -Glg /home/debian/bullseye/bibletime-data_3.0-5_all.deb 
-rw-r- 1 1180212 Nov 28  2020 
/home/debian/bullseye/bibletime-data_3.0-5_all.deb
/tmp/btd $ ar t /home/debian/bullseye/bibletime-data_3.0-5_all.deb 
debian-binary
control.tar.xz
data.tar.xz
/tmp/btd $ ar x /home/debian/bullseye/bibletime-data_3.0-5_all.deb 
/tmp/btd $ ls -Glg
total 1160
-rw-r--r-- 1   17536 Dec 14 09:25 control.tar.xz
-rw-r--r-- 1 1162484 Dec 14 09:25 data.tar.xz
-rw-r--r-- 1   4 Dec 14 09:25 debian-binary
/tmp/btd $ tar -Jtf /tmp/btd/data.tar.xz | grep /en/
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-config.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-intro.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-op-bookshelfmanager.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-op-output.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-op-parts.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-op-search.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-op.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-reference-shortcuts.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-reference-works.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-reference.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-start-firstrun.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/hdbk-term.html
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_back.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_bible.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_bible_add.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_bibletime.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_book.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_book_add.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_bookmark.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_books.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_cascade.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_checkbox.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_commentary.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_commentary_add.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_configure.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_configuresword.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_contents2.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_displayconfig.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_document_magnifier.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_exit.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_fileclose.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_find.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_folder_open.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_forward.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_lexicon.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_lexicon_add.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_light_bulb.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_sync.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_tile.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_tile_horiz.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_tile_vert.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_view_index.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_view_mag.png
./usr/share/doc/bibletime-data/bibletime/handbook/html/en/i_window_fullscreen.png

Re: BUG: Debian 11 version of bibletime - was [Re: Problems with "Bible Time" and "Xiphos"]

[Cindy Sue Causey]

(What I wrote below is) tl;dr :: Is localepurge installed on the
system(s) where the handbook is not reachable? I can't reproduce it
just this second (even though I thought I encountered it just a couple
hours ago during upgrade), but I swear I've seen docs occasionally
included in what is purged. On average, this is what is seen as the
localepurge's operation feedback:

localepurge: Disk space freed:   1564 KiB in /usr/share/locale
localepurge: Disk space freed:640 KiB in /usr/share/man
localepurge: Disk space freed:  0 KiB in /usr/share/tcltk
localepurge: Disk space freed:  0 KiB in /usr/share/help

I'm about "this sure" that I've additionally seen /usr/share/doc
appear there as a fifth line, too. Down below, I've posted file paths
for all four currently available bibletime-data versions. There's been
some change going on. In that case AND if something like localepurge
is installed, maybe there's a potential bug that needs addressed on
one end or the other.

On the "maybe not" side, I went ahead and installed bibletime on
Bookworm. Nothing at all was purged on the four above lines. BUT:
Maybe something's purged in earlier Debian releases...?? I don't have
any installed to test drive it.

My understanding of localepurge is that it's about purging materials
that are installed by default in some packages but that a User
declaring a language specific LANG might not ever need. Am saying that
because I noticed several language options in the bibletime handbook
directories. That provides a place where a glitch might result in a
needed language accidentally getting purged.

As a related aside, this webpage:

https://unix.stackexchange.com/questions/180400/is-it-safe-to-empty-usr-share-doc

Says it found this in localepurge's own docs:

"Please note, that this tool is a hack which is not integrated with
Debian's package management system and therefore is not for the faint
of heart. This program interferes with the Debian package management
and does provoke strange, but usually harmless, behaviour of programs
related with apt/dpkg like dpkg-repack, reportbug, etc. Responsibility
for its usage and possible breakage of your system therefore lies in
the sysadmin's (your) hands."


On 12/13/21, Kenneth Parker  wrote:
> On Mon, Dec 13, 2021 at 8:25 PM Richard Owlett  wrote:
>
>> On 12/13/2021 01:43 PM, Erwan David wrote:
>> > Le 13/12/2021 à 19:18, Richard Owlett a écrit :
>> >> [SNIP]
>> > apt-file search bibletime show that package bibletime-data contains a
>> > handbook and howto subdirectory in
>> >
>> > /usr/share/doc/bibletime-data
>>
>> NOT TRUE when running Debian 11 in southwest Missouri USA.
>>
>
> Is True with Debian 11, KDE.
> I am browsing the Handbook now.  Interesting.
>
> IS  TRUE when running Debian 10 in southwest Missouri USA.
>>
>> How do I identify/select physical repository that is being queried by my
>> run of apt-file?
>>
>
> Interesting!  Apt-File isn't installed by default.  (But I got it easily)
>
> Okay, apt-file is bigger than a bread basket.  So I will defer to the other
> apt-file experts.
>
> However, your symptom suggests that bibletime-data might not have been
> completely Installed.


A slightly minor "pain", but I just downloaded and peeked into all
four bibletime-data versions available in Debian's repositories. These
are the paths that resulted:

Stretch (oldoldstable)
bibletime-data_2.10.1-3_all/usr/share/bibletime/docs/handbook

Buster (oldstable)
bibletime-data_2.11.2-11_all/usr/share/bibletime/docs/handbook

Bullseye (stable)
bibletime-data_3.0-5_all/usr/share/doc/bibletime-data/bibletime/handbook

Bookworm (testing)/Sid (unstable)
bibletime-data_3.0.2-1_all/usr/share/doc/bibletime-data/handbook

Bookworm/Sid's pbibletime-data parent directory also contains this symlink:
bibletime-data_3.0.2-1_all/usr/share/doc/bibletime/handbook

There may be other symlinks that I missed, but that's enough for now.
Feels like they're toying with ways to do something like accommodate
for future growth (additions).

Change happens. Always copacetic here as long as maintainers have made
all appropriate respective alterations within the programming code so
that everything continues to function as expected. Since some members
are successfully reading their handbook here, sounds like that
happened so something else is glitching somewhere.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: BUG: Debian 11 version of bibletime

[Richard Owlett]

On 12/13/2021 08:10 PM, Felix Miata wrote:

Richard Owlett composed on 2021-12-13 12:18 (UTC-0600):


I reinstalled bibletime and xiphos.
Using bibletime I installed Bible, concordance, etc.
F1 and F2 do NOT display the appropriate help files.


Are you sure you installed everything bibletime /wants/?


I might be phrased as "I ordered it all but the the repository (i.e URL) 
contacted did not contain all that is evidently residing at other URL's".


I.E. I used Synaptic to install
 bibletime  -- bible study tool for Qt
   AND
 bibletime-data -- Documentation and data for bibletime

When Erwan David (in Europe) performed "apt-file search bibletime" the 
handbook files were displayed.


When I (in Missouri USA) run it against Debian 11 I do not see handbook 
files. I *DO* see the handbook files when running it against Debian 10.


IOW I am convinced I am observing a repository problem, *NOT* operator 
error.



It seems to be a QT app,
which may need qt components you don't have installed, but are not "required".
The following is from an installation with TDE, no Gnome, no Cinnamon, no XFCE,
no KDE, but does have a minimal amount of QT5 installed.

[snip installation report]

Re: BUG: Debian 11 version of bibletime - was [Re: Problems with "Bible Time" and "Xiphos"]

[Kenneth Parker]

On Mon, Dec 13, 2021 at 8:25 PM Richard Owlett  wrote:

> On 12/13/2021 01:43 PM, Erwan David wrote:
> > Le 13/12/2021 à 19:18, Richard Owlett a écrit :
> >> [SNIP]
> > apt-file search bibletime show that package bibletime-data contains a
> > handbook and howto subdirectory in
> >
> > /usr/share/doc/bibletime-data
>
> NOT TRUE when running Debian 11 in southwest Missouri USA.
>

Is True with Debian 11, KDE.
I am browsing the Handbook now.  Interesting.

IS  TRUE when running Debian 10 in southwest Missouri USA.
>
> How do I identify/select physical repository that is being queried by my
> run of apt-file?
>

Interesting!  Apt-File isn't installed by default.  (But I got it easily)

Okay, apt-file is bigger than a bread basket.  So I will defer to the other
apt-file experts.

However, your symptom suggests that bibletime-data might not have been
completely Installed.

Good luck!

Kenneth Parker

Re: BUG: Debian 11 version of bibletime - was [Re: Problems with "Bible Time" and "Xiphos"]

[Charles Curley]

On Mon, 13 Dec 2021 19:24:31 -0600
Richard Owlett  wrote:

> > Le 13/12/2021 à 19:18, Richard Owlett a écrit :  
> >> [SNIP]  
> > apt-file search bibletime show that package bibletime-data contains
> > a handbook and howto subdirectory in
> > 
> > /usr/share/doc/bibletime-data  
> 
> NOT TRUE when running Debian 11 in southwest Missouri USA.

I don't know what's going on in southwest Missouri, but in Wyoming it's
there, it's a directory with some 1200 files and directories in it, and
it's provided by package bibletime-data.

charles@hawk:~$ apt-file search bibletime-data
bibletime-data: 
/usr/share/doc/bibletime-data/bibletime/handbook/html/ar/hdbk-config.html
bibletime-data: 
/usr/share/doc/bibletime-data/bibletime/handbook/html/ar/hdbk-intro.html
bibletime-data: 
/usr/share/doc/bibletime-data/bibletime/handbook/html/ar/hdbk-op-bookshelfmanager.html
bibletime-data: 
/usr/share/doc/bibletime-data/bibletime/handbook/html/ar/hdbk-op-output.html
bibletime-data: 
/usr/share/doc/bibletime-data/bibletime/handbook/html/ar/hdbk-op-parts.html

bibletime-data: 
/usr/share/doc/bibletime-data/bibletime/handbook/html/ar/hdbk-config.html
bibletime-data: 
/usr/share/doc/bibletime-data/bibletime/handbook/html/ar/hdbk-intro.html
bibletime-data: 
/usr/share/doc/bibletime-data/bibletime/handbook/html/ar/hdbk-op-bookshelfmanager.html
bibletime-data: 
/usr/share/doc/bibletime-data/bibletime/handbook/html/ar/hdbk-op-output.html
bibletime-data: 
/usr/share/doc/bibletime-data/bibletime/handbook/html/ar/hdbk-op-parts.html
charles@hawk:~$

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: BUG: Debian 11 version of bibletime - was [Re: Problems with "Bible Time" and "Xiphos"]

[David Wright]

On Mon 13 Dec 2021 at 19:24:31 (-0600), Richard Owlett wrote:
> On 12/13/2021 01:43 PM, Erwan David wrote:
> > Le 13/12/2021 à 19:18, Richard Owlett a écrit :
> > > [SNIP]
> > apt-file search bibletime show that package bibletime-data
> > contains a handbook and howto subdirectory in
> > 
> > /usr/share/doc/bibletime-data
> 
> NOT TRUE when running Debian 11 in southwest Missouri USA.
> IS  TRUE when running Debian 10 in southwest Missouri USA.
> 
> How do I identify/select physical repository that is being queried by
> my run of apt-file?

I'm not sure how you've missed them. If you look in
/usr/share/doc/bibletime-data/ as suggested, apart from the obligatory
changelogs and copyright, there appears to be only one path to follow
and, remarkably, it's called bibletime: this contains the guide, the
howtos and a licence.

Looking at buster, I think they've corrected the docs location
/usr/share/bibletime/docs/ to /usr/share/doc/bibletime-data/.

As for your direct question, the usual place AIUI: /var/lib/apt/lists/.
Or, more pedantically, whichever repository you've pointed APT at
in your sources list.

Of course, everything may be different in KS.

Cheers,
David.

Re: BUG: Debian 11 version of bibletime

[Felix Miata]

Richard Owlett composed on 2021-12-13 12:18 (UTC-0600):

> I reinstalled bibletime and xiphos.
> Using bibletime I installed Bible, concordance, etc.
> F1 and F2 do NOT display the appropriate help files.  
> 
Are you sure you installed everything bibletime /wants/? It seems to be a QT 
app,
which may need qt components you don't have installed, but are not "required".
The following is from an installation with TDE, no Gnome, no Cinnamon, no XFCE,
no KDE, but does have a minimal amount of QT5 installed.

# inxi -Syz
System:
  Kernel: 5.10.0-9-amd64 x86_64 bits: 64 Desktop: Trinity R14.0.12
  Distro: Debian GNU/Linux 11 (bullseye)
# apt install bibletime bibletime-data bibletime-trinity tdeio-sword-trinity 
sword-dict-naves sword-text-kjv sword-comm-mhcc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libclucene-core1v5 libqt5printsupport5 libqt5qml5 libqt5qmlmodels5 
libqt5qmlworkerscript5 libqt5quick5 libqt5quickwidgets5 libqt5xml5 
libsword-common libsword1.9.0 qml-module-qtquick2
Suggested packages:
  bibletime-i18n-trinity qt5-qmltooling-plugins sword-dict-strongs-greek 
sword-dict-strongs-hebrew sword-comm-scofield sword-comm-tdavid
The following NEW packages will be installed:
  bibletime bibletime-data bibletime-trinity libclucene-core1v5 
libqt5printsupport5 libqt5qml5 libqt5qmlmodels5 libqt5qmlworkerscript5 
libqt5quick5 libqt5quickwidgets5 libqt5xml5
  libsword-common libsword1.9.0 qml-module-qtquick2 sword-comm-mhcc 
sword-dict-naves sword-text-kjv tdeio-sword-trinity
0 upgraded, 18 newly installed, 0 to remove and 31 not upgraded.
Need to get 14.8 MB of archives.
After this operation, 42.7 MB of additional disk space will be used.
Do you want to continue? [Y/n]
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: BUG: Debian 11 version of bibletime - was [Re: Problems with "Bible Time" and "Xiphos"]

[Richard Owlett]

On 12/13/2021 01:43 PM, Erwan David wrote:

Le 13/12/2021 à 19:18, Richard Owlett a écrit :

[SNIP]
apt-file search bibletime show that package bibletime-data contains a 
handbook and howto subdirectory in


/usr/share/doc/bibletime-data


NOT TRUE when running Debian 11 in southwest Missouri USA.
IS  TRUE when running Debian 10 in southwest Missouri USA.

How do I identify/select physical repository that is being queried by my 
run of apt-file?

Re: BUG: Debian 11 version of bibletime - was [Re: Problems with "Bible Time" and "Xiphos"]

[Erwan David]

Le 13/12/2021 à 19:18, Richard Owlett a écrit :

On 12/13/2021 09:09 AM, Kent West wrote:
On Mon, Dec 13, 2021 at 8:57 AM Richard Owlett  
wrote:



[snip]

I installed both programs to the Debian 11 partition of my secondary
machine. I ran into two problems.

1. In Xiphos, [snip]

2. Bible Time has Help options available via F1, F2, and F3. All report
 "Module not available".


I then installed both programs to the Debian 10 partition to check for
"operator error" &/or version differences. As I had tried to first use
Xiphos on the Debian 11 install, I started with Bible Time on the 
Debian
10 install. It happily went looking for online libraries. Installed 
what

I requested and they were available also to Xiphos.
ALSO F1, F2, and F3 work.


Doing "apt purge" of bibletime and xiphos did not remove related data 
files. As I had no other applications installed, I reinstalled Debian 
11 from scratch.


I reinstalled bibletime and xiphos.
Using bibletime I installed Bible, concordance, etc.
F1 and F2 do NOT display the appropriate help files.

Further investigation of the Debian 11 filesystem shows that
/usr/share/bibletime/docs does not exist.

[On Debian 10 system it exists with sub-directories .../handbook and 
.../howto .  F1 and F2 works there.]


How do I correctly file a bug report?

TIA



apt-file search bibletime show that package bibletime-data contains a 
handbook and howto subdirectory in


/usr/share/doc/bibletime-data

Re: BUG: Debian 11 version of bibletime - was [Re: Problems with "Bible Time" and "Xiphos"]

[Polyna-Maude Racicot-Summerside]

On 2021-12-13 1:18 p.m., Richard Owlett wrote:
> On 12/13/2021 09:09 AM, Kent West wrote:
>> On Mon, Dec 13, 2021 at 8:57 AM Richard Owlett 
>> wrote:
>>
>>> [snip]
>>>
>>> I installed both programs to the Debian 11 partition of my secondary
>>> machine. I ran into two problems.
>>>
>>> 1. In Xiphos, [snip]
>>>
>>> 2. Bible Time has Help options available via F1, F2, and F3. All report
>>>  "Module not available".
>>>
>>>
>>> I then installed both programs to the Debian 10 partition to check for
>>> "operator error" &/or version differences. As I had tried to first use
>>> Xiphos on the Debian 11 install, I started with Bible Time on the Debian
>>> 10 install. It happily went looking for online libraries. Installed what
>>> I requested and they were available also to Xiphos.
>>> ALSO F1, F2, and F3 work.
> 
> Doing "apt purge" of bibletime and xiphos did not remove related data
> files. As I had no other applications installed, I reinstalled Debian 11
> from scratch.
> 
> I reinstalled bibletime and xiphos.
> Using bibletime I installed Bible, concordance, etc.
> F1 and F2 do NOT display the appropriate help files.
> 
> Further investigation of the Debian 11 filesystem shows that
> /usr/share/bibletime/docs does not exist.
> 
Have you check for a bibletime-doc package ?
> [On Debian 10 system it exists with sub-directories .../handbook and
> .../howto .  F1 and F2 works there.]
> 
> How do I correctly file a bug report?
> 
> TIA
> 
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: BUG: Debian 11 version of bibletime - was [Re: Problems with "Bible Time" and "Xiphos"]

[Mindaugas Celiesius]

Hello. Please, check this https://wiki.debian.org/BugReport

2021-12-13 20:18, Richard Owlett rašė:

On 12/13/2021 09:09 AM, Kent West wrote:
On Mon, Dec 13, 2021 at 8:57 AM Richard Owlett  
wrote:



[snip]

I installed both programs to the Debian 11 partition of my secondary
machine. I ran into two problems.

1. In Xiphos, [snip]

2. Bible Time has Help options available via F1, F2, and F3. All report
 "Module not available".


I then installed both programs to the Debian 10 partition to check for
"operator error" &/or version differences. As I had tried to first use
Xiphos on the Debian 11 install, I started with Bible Time on the 
Debian
10 install. It happily went looking for online libraries. Installed 
what

I requested and they were available also to Xiphos.
ALSO F1, F2, and F3 work.


Doing "apt purge" of bibletime and xiphos did not remove related data 
files. As I had no other applications installed, I reinstalled Debian 
11 from scratch.


I reinstalled bibletime and xiphos.
Using bibletime I installed Bible, concordance, etc.
F1 and F2 do NOT display the appropriate help files.

Further investigation of the Debian 11 filesystem shows that
/usr/share/bibletime/docs does not exist.

[On Debian 10 system it exists with sub-directories .../handbook and 
.../howto .  F1 and F2 works there.]


How do I correctly file a bug report?

TIA

Re: Bug report help

[Andrew M.A. Cater]

On Mon, Nov 29, 2021 at 11:14:20PM -0500, Steven Sostrom wrote:
> I am having audio problems in Debian GNU/Linux bookworm/sid running on a
> Raspberry Pi 4.
> Kernel: Linux 5.15.0-1-arm64
> 

Hi Steven,

Any particular reason to be using Sid? 

Where did you source your download from?

It sounds like a kernel/audio subsystem interaction problem but we'd need 
more details, I think.

> I don't know that it is an issue with a package unless it is a firmware
> package.
> 
> Some of the audio devices cause applications to freeze or will play at a
> slower than normal speed. The Default (pulseaudio) device usually works.
> ALSA devices are more likely to fail.
> 
> Often, after a reboot, pulseaudio will not start. I have to keep rebooting
> until it works.
> 
> Steve

Re: Bug de newbie sur script ?

[ptilou]

Le vendredi 15 octobre 2021 à 19:20:04 UTC+2, Erwann Le Bras a écrit :
> bonsoir
> je ne comprends pas ta demande :(
> le "output_%0d.png" est je pense erroné ; ne veux-tu pas dire "output_$f.png"
> ou en enlevant le .AVI du fichier : "output_$(basename $f .AVI).png"
> cordialement
> Le 10/10/2021 à 08:29, ptilou a écrit :
> Slt,
> 
> Mon script :
> for f in *.AVI / 
> 
> do ./ffmpeg -i "$f" -r 25 output_%0d.png 
> 
> done
> 
> Et donc je voudrais au lieu de output avoir le résultat de $f et donc c’est 
> quoi la grammaire conjugaison ?
> 
> Le but est que chaque fichier fait repartir le fichier à 1 et donc ecrase le 
> précédent, mais pour une bonne gestion en posant ma question je pense qu’il 
> faut mettre le nom du fichier original, quelqu’un fait autrement, le but 
> après et de les faire passer dans des scripts de processing, pour l’in Je 
> n’ai que des saturations de couleurs !
> 
> Merci
> 
> — 
> Ptilou
> amitiés,
> -- 
> Erwann

En lieu et place de output, j’ai mie un “$f” et je garde, la mauvaise rédaction 
pour retrouver le film qui a servi à produire l’image.

Je me pose la question d’une nouvelle erreur, j’ai pour 14 mn de vidéo en MOV, 
font 18500 images, et donc est que il ne serait pas mieux de chercher un script 
qui extrait quand X pourcentage de l’image a changé ?

Je cherche su opencv, mais la mise en place me semble complexe, et je me 
demande si il existe pas quelque chose de plus legé (que opencv ?)

Sinon j’ai pensé mettre un cadre dans le style d’une pellicule avec 
Imagemagick, puis faire des planches contacte ?

Je cherche des idées avec dés modulation de couleurs ou de la commande 
grayscale ?

Donc ou y a t’il un forum sur opencv ?

— 
Ptilou

Re: Bug de newbie sur script ?

[Erwann Le Bras]

bonsoir

je ne comprends pas ta demande :(

le "output_%0d.png" est je pense erroné ; ne veux-tu pas dire 
"output_$f.png"


ou en enlevant le .AVI du fichier : "output_$(basename $f .AVI).png"

cordialement

Le 10/10/2021 à 08:29, ptilou a écrit :

Slt,

Mon script :
for f in *.AVI /

do ./ffmpeg -i "$f" -r 25 output_%0d.png

done

Et donc je voudrais au lieu de output avoir le résultat de $f et donc c’est 
quoi la grammaire conjugaison ?

Le but est que chaque fichier fait repartir le fichier à 1 et donc ecrase le 
précédent, mais pour une bonne gestion en posant ma question je pense qu’il 
faut mettre le nom du fichier original, quelqu’un fait autrement, le but après 
et de les faire passer dans des scripts de processing, pour l’in Je n’ai que 
des saturations de couleurs !

Merci

—
Ptilou


amitiés,

--

Erwann

Re: Bug a la instal·lació de postgresql?

[Toni Mas Soler]

Moltes gràcies per l'explicació.

Toni Mas
GPG 3F42A21D84D7E950

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

El diumenge, 3 de octubre 2021 a les 21:43, julio 
 va escriure:

> > Malauradament limitar l'ús de su no és suficient per evitar que
> > 

> > un usuari amb root es pugui convertir fàcilment en un altre o
> > 

> > executar ordres en nom d'un altre: a banda del runuser i setpriv,
> > 

> > qualsevol llenguatge de programació prou genèric permetrà cridar
> > 

> > les funcions del sistema per fer-ho sense passar pel PAM.
> 

> Cert.
> 

> > Se m'acut que la millor forma de què els alumnes tinguin root
> > 

> > però no interfereixin amb d'altres usuaris és que tinguin una
> > 

> > màquina virtual per cadascú.
> 

> Segurament Àlex, però som de la filosofia de que facin servir sistemes reals 
> i que els trenquin, com a sistema de capçalera, evidentment també fan servir 
> VMs i Dockers.
> 

> El problema realment és que es loguegin a una màquina on algun despistat ho 
> hagi fet prèviament, ja que s'haurà muntat per NFS (kerberitzat) el directori 
> d'aquest usuari despistat.
> 

> Potser el que s'hauria de fer és permetre la exportació de segons quins 
> directoris a segons quines IPs...
> 

> Merci per les bones idees.
> 

> Julio
> 

> > Salut,
> > 

> > Alex
> > 

> > --
> > 

> > ⢀⣴⠾⠻⢶⣦⠀
> > 

> > ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada al...@debian.org
> > 

> > ⢿⡄⠘⠷⠚⠋ Debian Developer  log.alexm.org
> > 

> > ⠈⠳⣄
> 

> Sent from my Android device with K-9 Mail. Please excuse my brevity.

signature.asc
Description: OpenPGP digital signature

Re: Bug a la instal·lació de postgresql?

[julio]

>
>Malauradament limitar l'ús de su no és suficient per evitar que
>un usuari amb root es pugui convertir fàcilment en un altre o
>executar ordres en nom d'un altre: a banda del runuser i setpriv,
>qualsevol llenguatge de programació prou genèric permetrà cridar
>les funcions del sistema per fer-ho sense passar pel PAM.
>

Cert.



>Se m'acut que la millor forma de què els alumnes tinguin root
>però no interfereixin amb d'altres usuaris és que tinguin una
>màquina virtual per cadascú.

Segurament Àlex, però som de la filosofia de que facin servir sistemes reals i 
que els trenquin, com a sistema de capçalera, evidentment també fan servir VMs 
i Dockers.
El problema realment és que es loguegin a una màquina on algun despistat ho 
hagi fet prèviament, ja que s'haurà muntat per NFS (kerberitzat) el directori 
d'aquest usuari despistat.
Potser el que s'hauria de fer és permetre la exportació de segons quins 
directoris a segons quines IPs...
Merci per les bones idees.
Julio

>Salut,
>Alex
>
>--
>  ⢀⣴⠾⠻⢶⣦⠀
>  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
>  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
>  ⠈⠳⣄
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Bug a la instal·lació de postgresql?

[Alex Muntada]

Hola, Julio

> Quan un d'aquests despistats del grup B, es logueja i s'oblida
> de fer kdestroy, el tiquet de kerberos roman durant unes hores
> a l'ordinador i en aquest moment, qualsevol usuari amb el compte
> local de root pot fer un `su -l usuari_despistat_del_grup_B`

Això és el que sospitava, gràcies per explicar-ho amb detall.

Malauradament limitar l'ús de su no és suficient per evitar que
un usuari amb root es pugui convertir fàcilment en un altre o
executar ordres en nom d'un altre: a banda del runuser i setpriv,
qualsevol llenguatge de programació prou genèric permetrà cridar
les funcions del sistema per fer-ho sense passar pel PAM.

Se m'acut que la millor forma de què els alumnes tinguin root
però no interfereixin amb d'altres usuaris és que tinguin una
màquina virtual per cadascú.

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: Bug a la instal·lació de postgresql?

[Julio Amorós]

Missatge de Alex Muntada  del dia dv., 1 d’oct. 2021 a
les 23:37:

> Hola, Julio
>
> > el problema amb Kerberos, és que si no fas un kdestroy o
> > l'elimines manualment de /tmp dura no se quantes hores i per
> > tant amb l'ordre que hem esmentat pots fer ...
>
> No entenc quina relació té l'expiració de sessions de kerberos
> amb el fet de no permetre que l'usuari root executi el su que
> vulgui. Ara ja sabem que també hi ha runuser i, mirant la seva
> pàgina de man, he vist que també hi ha setpriv, que ni tan sols
> utilitza pam.
>

La idea és:
- els usuaris del grup A fan servir els seus ordinadors amb un compte
ordinari ( contra un ldap+kerberos)  i amb el compte root local.
- els usuaris del grup B no han de fer servir el seu compte als ordinadors
del grup A, i ja estan avisats, però sempre hi ha algun despistat.

Quan un d'aquests despistats del grup B, es logueja i s'oblida de fer
kdestroy, el tiquet de kerberos roman durant unes hores a l'ordinador i en
aquest moment, qualsevol usuari amb el compte local de root pot fer un `su
-l usuari_despistat_del_grup_B`

No sé si m'explico :)

Julio


-- 
__


   -

   El 2003 el català era la llengua habitual del 46 % dels catalans. Al
   2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà.
   -

   El 3 de novembre representa el moment de l'any en el que les dones
   deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a
   eliminar aquesta data.
   -

   L’administració pública cada any es gasta milions d’euros en llicències
   de programari privatiu. Utilitzant programari lliure estalviem costos i
   incentivem l’economia local.

*La neutralitat davant les desigualtats acaba accentuant-les.*

Re: Bug in senddoc

[Tom Dial]

On 10/2/21 07:51, Alex wrote:
> Hello
> 
> 
> I found a bug and do not know if it belongs to the package libreoffice
> or apparmor!
> 
> When I want to send a document directly by E-mail in libreoffice, it
> doesn't work. I started libreoffice --calc in a shell and choose File->
> sned -> send document as e-mail, i got an error message in the shell:
> 
> /usr/lib/libreoffice/program/senddoc: 62: file: Permission denied
> /usr/lib/libreoffice/program/senddoc: 70: /usr/bin/thunderbird:
> Permission denied
> 
> I do some debugging (echo before line 62) and found out that it starts
> /usr/bin/thunderbird
> 
> When I uninstall appamor (aa-disable /etc/apparmor.d/usr.bin.thunderbird
> doesn't be suffisent), the message Permission denied disappears.
> 
> In the documentation, I read that every package has it's own profile for
> apparmor shipped in. Therefor my problem.
> 
The bug, if any, should be for LibreOffice. The behavior is a feature of
Apparmor and other Mandatory Access Control modules like SELinux and
possibly others, for which the default is to deny any access for which
there is no rule allowing it.

Regards,
Tom Dial
> 
> Thank you
> 
> 
> Al

Re: Bug a la instal·lació de postgresql?

[Alex Muntada]

Hola, Julio

> el problema amb Kerberos, és que si no fas un kdestroy o
> l'elimines manualment de /tmp dura no se quantes hores i per
> tant amb l'ordre que hem esmentat pots fer ...

No entenc quina relació té l'expiració de sessions de kerberos
amb el fet de no permetre que l'usuari root executi el su que
vulgui. Ara ja sabem que també hi ha runuser i, mirant la seva
pàgina de man, he vist que també hi ha setpriv, que ni tan sols
utilitza pam.

Ens pots explicar amb una mica més de detall el problema de fons?

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: Bug a la instal·lació de postgresql?

[Julio Amorós]

Hola,
molt interessant la conversa, com sempre.
Tens raó Àlex, això forma part d'una configuració extra que afegim (la
línia comentada del pam) per tant efectivament si algú té curiositat ... :)
I Toni, el problema amb Kerberos, és que si no fas un kdestroy o l'elimines
manualment de /tmp dura no se quantes hores i per tant amb l'ordre que hem
esmentat pots fer ...
Potser això també és configurable per a que quan un usuari tanqui la seva
darrera sessió s'elimini aquest ticket ¿?
De fet pensàvem provar-ho manualment a alguns ordinadors posant-ho al
logout (si nomes hi ha una sessió d'aquest usuari  => kdestroy) però vaja
...
Merci,
Julio

Missatge de Toni Mas Soler  del dia ds., 25 de
set. 2021 a les 21:26:

> Al man su/man runuser hi fa alguna referència. Però no entenc el motiu
> perquè és un forat de seguretat si s'usa kerberos (NOTA: jo no faig servir
> kerberos).
>
> Toni Mas
> GPG 3F42A21D84D7E950
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
>
> El dissabte, 25 de setembre 2021 a les 21:00, Eloi 
> va escriure:
>
> > El 25/9/21 a les 11:06, Alex Muntada ha escrit:
> >
> > > Hola, Eloi
> > >
> > > [...]
> > >
> > > > Una de les recomanacions que vaig llegir aleshores era usar la
> > > >
> > > > comanda "runuser" quan qui l'executa ja és root, doncs desescala
> > > >
> > > > a qualsevol usuari sense demanar autenticació mentre que la
> > > >
> > > > resta d'usuaris no la poden executar.
> > > >
> > > > Això no recordo haver-ho llegit però ho acabo de provar i
> > > >
> > > > funciona bé: no demana contrasenya encara que comenti l'entrada
> > > >
> > > > del pam_rootok al /etc/pam.d/runuser.
> >
> > Això és que em faig vell i/o no menjo prou cues de pansa :-)
> >
> > Jo tampoc he trobat el que recordo haver llegit, segurament deuria ser
> >
> > una font de tercers, que em deuria enganxar documentant-me i al final he
> >
> > acabat confonent els orígens. L'única referència explícita que he estat
> >
> > capaç de trobar amb DDG (DuckDuckGo, no Diari De Girona :-D) dins
> >
> > debian.org és la següent, que no és el que recordo haver llegit però que
> >
> > igualment apunta en la mateixa direcció:
> >
> > https://bugs.debian.org/890862
> >
> > Si trobo on redimonis vaig llegir-ho us ho faré saber.



-- 
__


   -

   El 2003 el català era la llengua habitual del 46 % dels catalans. Al
   2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà.
   -

   El 3 de novembre representa el moment de l'any en el que les dones
   deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a
   eliminar aquesta data.
   -

   L’administració pública cada any es gasta milions d’euros en llicències
   de programari privatiu. Utilitzant programari lliure estalviem costos i
   incentivem l’economia local.

*La neutralitat davant les desigualtats acaba accentuant-les.*

Re: Bug a la instal·lació de postgresql?

[Toni Mas Soler]

Al man su/man runuser hi fa alguna referència. Però no entenc el motiu perquè 
és un forat de seguretat si s'usa kerberos (NOTA: jo no faig servir kerberos).

Toni Mas
GPG 3F42A21D84D7E950

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

El dissabte, 25 de setembre 2021 a les 21:00, Eloi  va 
escriure:

> El 25/9/21 a les 11:06, Alex Muntada ha escrit:
>
> > Hola, Eloi
> >
> > [...]
> >
> > > Una de les recomanacions que vaig llegir aleshores era usar la
> > >
> > > comanda "runuser" quan qui l'executa ja és root, doncs desescala
> > >
> > > a qualsevol usuari sense demanar autenticació mentre que la
> > >
> > > resta d'usuaris no la poden executar.
> > >
> > > Això no recordo haver-ho llegit però ho acabo de provar i
> > >
> > > funciona bé: no demana contrasenya encara que comenti l'entrada
> > >
> > > del pam_rootok al /etc/pam.d/runuser.
>
> Això és que em faig vell i/o no menjo prou cues de pansa :-)
>
> Jo tampoc he trobat el que recordo haver llegit, segurament deuria ser
>
> una font de tercers, que em deuria enganxar documentant-me i al final he
>
> acabat confonent els orígens. L'única referència explícita que he estat
>
> capaç de trobar amb DDG (DuckDuckGo, no Diari De Girona :-D) dins
>
> debian.org és la següent, que no és el que recordo haver llegit però que
>
> igualment apunta en la mateixa direcció:
>
> https://bugs.debian.org/890862
>
> Si trobo on redimonis vaig llegir-ho us ho faré saber.

signature.asc
Description: OpenPGP digital signature

Re: Bug a la instal·lació de postgresql?

[Eloi]

El 25/9/21 a les 11:06, Alex Muntada ha escrit:

Hola, Eloi
[...]


Una de les recomanacions que vaig llegir aleshores era usar la
comanda "runuser" quan qui l'executa ja és root, doncs desescala
a qualsevol usuari sense demanar autenticació mentre que la
resta d'usuaris no la poden executar.

Això no recordo haver-ho llegit però ho acabo de provar i
funciona bé: no demana contrasenya encara que comenti l'entrada
del pam_rootok al /etc/pam.d/runuser.


Això és que em faig vell i/o no menjo prou cues de pansa :-)

Jo tampoc he trobat el que recordo haver llegit, segurament deuria ser 
una font de tercers, que em deuria enganxar documentant-me i al final he 
acabat confonent els orígens. L'única referència explícita que he estat 
capaç de trobar amb DDG (DuckDuckGo, no Diari De Girona :-D) dins 
debian.org és la següent, que no és el que recordo haver llegit però que 
igualment apunta en la mateixa direcció:


https://bugs.debian.org/890862

Si trobo on redimonis vaig llegir-ho us ho faré saber.