Re: Predictable network device names [was: Please help me identify package so I can report an important bug
On Thu, Jun 13, 2024 at 06:59:49AM +0200, Kamil Jońca wrote: > to...@tuxteam.de writes: [...] > > and of course, if you are using a desktop environment and NetworkManager > > or systemd-networkd, it's probably better to go with the flow and let > > them do. > > About year ago none of them was able to handle my config. > (Some interfaces used by vms , and proper snat for them.) I've supported those only for pretty bog standard setups. Mainly end users who have to cope with longer stretches without local friendly hackers. I don't believe they are useful for special situations or knowledgeable users. Cheers -- t signature.asc Description: PGP signature
Re: Predictable network device names [was: Please help me identify package so I can report an important bug
to...@tuxteam.de writes: > On Thu, Jun 13, 2024 at 06:30:27AM +0200, to...@tuxteam.de wrote: > > [following up on myself, bad style, I know] > >> For my laptop, I very much prefer to say "sudo ifup eth0" than to >> say "sudo ifup en0ps&&@*#!☠" thankyouverymuch :) > > and of course, if you are using a desktop environment and NetworkManager > or systemd-networkd, it's probably better to go with the flow and let > them do. About year ago none of them was able to handle my config. (Some interfaces used by vms , and proper snat for them.) KJ -- http://wolnelektury.pl/wesprzyj/teraz/
Predictable network device names [was: Please help me identify package so I can report an important bug
On Thu, Jun 13, 2024 at 06:30:27AM +0200, to...@tuxteam.de wrote: [following up on myself, bad style, I know] > For my laptop, I very much prefer to say "sudo ifup eth0" than to > say "sudo ifup en0ps&&@*#!☠" thankyouverymuch :) and of course, if you are using a desktop environment and NetworkManager or systemd-networkd, it's probably better to go with the flow and let them do. Cheers -- t signature.asc Description: PGP signature
Re: Please help me identify package so I can report an important bug
On Wed, Jun 12, 2024 at 03:16:41PM -0400, Greg Wooledge wrote: > On Wed, Jun 12, 2024 at 09:01:44PM +0200, to...@tuxteam.de wrote: [...] > > Mine loks like this: > > > > GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0" > > People who are thinking of doing this should take a moment to consider > whether it will be better or worse than the default. Absolutely. I did, and I decided that in my case, this is the better choice... > For a machine that has exactly one ethernet interface, this is a vast > improvement over the default. Your interface will always be named > "eth0" no matter what crazy things happen on the PCI bus. ...but it's not always, as you say. > For a machine with multiple interfaces, however, the original problem > that "predictable interface names" were supposed to solve is still an > issue. The kernel may not assign the names in the same order every > time you boot. In that situation, "net.ifnames=0" is not likely to > be an improvement. You'd be better off using systemd.link(5) files to > customize your interface names according to your own specific needs. I think PCI is not the worst offender. The worst is if you have a bunch of adapters hanging off an USB tree. Then, as they say, God does play dice :-) Back Then (TM) (I think it was a Debian 3.x aka Sarge), a bunch of us cobbled a "router thingy" together on some off-the-shelf hardware. It had four Ethernets hanging off whatever PC bus was fashionable back then (too lazy to look it up). Not many of those were sold, luckily :-) One was for "the bad Internet", the other three for "the inside". Our big fear was that, after a BIOS upgrade the interfaces would come up in a mangled order. That would have been a good application of this scheme (provided it works at all: I'm somewhat sceptic. Hardware and firmware are known to do... things). We ended up going by the card's MAC addresses, at the price of having a set up step on assembly. But then, if you change one Ethernet card... Alas, you can't do it right. For my laptop, I very much prefer to say "sudo ifup eth0" than to say "sudo ifup en0ps&&@*#!☠" thankyouverymuch :) Cheers -- t signature.asc Description: PGP signature
Re: Please help me identify package so I can report an important bug
Richard wrote: > Good catch. With the title of this thread and not seeing any proper > description of what's actually wrong on GitHub, I figured the change > of the adapter name was meant. Yes, with MAC randomization, that's > what you'll get. But it's nothing Debian defaults to. So question is, > can this be disabled on Proxmox? But with this hint, it should be > easy enough to figure out if this can be deactivated on the affected > systems, and if not the bug reports must be against these issues, as > Debian itself doesn't do such things. If it is an issue with Debian > preventing the disablement, the devs need to talk to each other. > > Richard > > Am Mi., 12. Juni 2024 um 17:10 Uhr schrieb Jeffrey Walton < > noloa...@gmail.com>: > > > The random MAC address discussed in the bug report (with mention of > > Network Manager) could be > > < > > https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ > > > > >. > > > > Jeff I think before anybody else suggests anything, they should read https://lore.kernel.org/netdev/20240326092459.gg403...@kernel.org/T/
Re: Please help me identify package so I can report an important bug
On Wed, Jun 12, 2024 at 09:01:44PM +0200, to...@tuxteam.de wrote: > No need. You can have your traditional names (I do). Just add > "net.ifnames=0" (if necessry separated by a space, should > other stuff be already there) to your GRUB_CMDLINE_LINUX_DEFAULT > in your /etc/default/grub, then ru update-grub. > > Mine loks like this: > > GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0" People who are thinking of doing this should take a moment to consider whether it will be better or worse than the default. For a machine that has exactly one ethernet interface, this is a vast improvement over the default. Your interface will always be named "eth0" no matter what crazy things happen on the PCI bus. For a machine with multiple interfaces, however, the original problem that "predictable interface names" were supposed to solve is still an issue. The kernel may not assign the names in the same order every time you boot. In that situation, "net.ifnames=0" is not likely to be an improvement. You'd be better off using systemd.link(5) files to customize your interface names according to your own specific needs. > > > https://wiki.debian.org/NetworkInterfaceNames
Re: Please help me identify package so I can report an important bug
On Wed, Jun 12, 2024 at 02:30:40PM -0400, Roy J. Tellason, Sr. wrote: > On Wednesday 12 June 2024 06:54:54 am Richard wrote: > > But also, just > > searching the web for this topic, you should have come across this > > answering your questions: https://wiki.debian.org/NetworkInterfaceNames > > > > Wow. Just wow... > > That sort of thing just drives me crazy! :-) > > I can see sticking with older versions of some things. No need. You can have your traditional names (I do). Just add "net.ifnames=0" (if necessry separated by a space, should other stuff be already there) to your GRUB_CMDLINE_LINUX_DEFAULT in your /etc/default/grub, then ru update-grub. Mine loks like this: GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0" Cheers -- t signature.asc Description: PGP signature
Re: Please help me identify package so I can report an important bug
On Wednesday 12 June 2024 06:54:54 am Richard wrote: > But also, just > searching the web for this topic, you should have come across this > answering your questions: https://wiki.debian.org/NetworkInterfaceNames > Wow. Just wow... That sort of thing just drives me crazy! :-) I can see sticking with older versions of some things. -- 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: Please help me identify package so I can report an important bug
Good catch. With the title of this thread and not seeing any proper description of what's actually wrong on GitHub, I figured the change of the adapter name was meant. Yes, with MAC randomization, that's what you'll get. But it's nothing Debian defaults to. So question is, can this be disabled on Proxmox? But with this hint, it should be easy enough to figure out if this can be deactivated on the affected systems, and if not the bug reports must be against these issues, as Debian itself doesn't do such things. If it is an issue with Debian preventing the disablement, the devs need to talk to each other. Richard Am Mi., 12. Juni 2024 um 17:10 Uhr schrieb Jeffrey Walton < noloa...@gmail.com>: > The random MAC address discussed in the bug report (with mention of > Network Manager) could be > < > https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ > >. > > Jeff >
Re: Please help me identify package so I can report an important bug
On Wed, Jun 12, 2024 at 10:33 AM Richard wrote: > > Question is, does it make that much sense to report it to Debian directly? > Are you encountering this issue on Debian itself or > Armbian/Raspbian/whatever? You reported this to the Raspberry Pi GitHub, so > I'd expect them to take this up with the upstream devs themselves, so by the > time Trixie is being released, it may already be included. > > But besides that, what you describe in the first link sounds to me not like a > bug, but as a well thought-through decision. Network adapter names like eth0 > have been dropped with Debian 11 (I think, maybe even 10). So don't get your > hopes up too high to ever see this coming back. But also, just searching the > web for this topic, you should have come across this answering your > questions: https://wiki.debian.org/NetworkInterfaceNames The random MAC address discussed in the bug report (with mention of Network Manager) could be <https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/>. Jeff
Re: Please help me identify package so I can report an important bug
Question is, does it make that much sense to report it to Debian directly? Are you encountering this issue on Debian itself or Armbian/Raspbian/whatever? You reported this to the Raspberry Pi GitHub, so I'd expect them to take this up with the upstream devs themselves, so by the time Trixie is being released, it may already be included. But besides that, what you describe in the first link sounds to me not like a bug, but as a well thought-through decision. Network adapter names like eth0 have been dropped with Debian 11 (I think, maybe even 10). So don't get your hopes up too high to ever see this coming back. But also, just searching the web for this topic, you should have come across this answering your questions: https://wiki.debian.org/NetworkInterfaceNames Richard Am Mi., 12. Juni 2024 um 12:43 Uhr schrieb Peter Goodall < pjgood...@gmail.com>: > Hello, > > This bug, or a close relative, has already been reported in > https://github.com/raspberrypi/bookworm-feedback/issues/239 > as 'Predictable network names broken for ASIX USB ethernet in kernel > 6.6.20' > > I added a comment reporting my experience in Proxmox here: > > https://github.com/raspberrypi/bookworm-feedback/issues/239#issuecomment-2162166863 > > Because it happens in proxmox and rpi I assume its Debian or higher. I > have not reported a Debian bug before... > > Thanks, > --Peter G >
Please help me identify package so I can report an important bug
Hello, This bug, or a close relative, has already been reported in https://github.com/raspberrypi/bookworm-feedback/issues/239 as 'Predictable network names broken for ASIX USB ethernet in kernel 6.6.20' I added a comment reporting my experience in Proxmox here: https://github.com/raspberrypi/bookworm-feedback/issues/239#issuecomment-2162166863 Because it happens in proxmox and rpi I assume its Debian or higher. I have not reported a Debian bug before... Thanks, --Peter G
Re: [BUG] Acentuação de "ç" inconsistente entre ISO DVD e Live
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.
>
>
[BUG] Acentuação de "ç" inconsistente entre ISO DVD e Live
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
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: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
On Wed Apr 24, 2024 at 1:50 PM BST, Richard wrote: > upon gathering my thoughts for answering to you I found the solution to > this: update-initramfs can't handle the case that crypttab ends in the line > of the last entry and not in a new line character. I think there either > should be a fix for this or at least a way to handle this case with a much > clearer error message. So I'll probably open a bug report for the package > and the maintainer can decide if that should be forwarded upstream. Such a > rather trivial case shouldn't be resulting in such fatal errors. That's very interesting. I'd definitely suggest filing a bug for this, if there isn't one already. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
On 26/04/2024 12:56, David Wright wrote: On Fri 26 Apr 2024 at 11:27:24 (+0900), John Crawley wrote: Innocent question: what difference does the comment make vs just ending the file with an empty line? Nothing for the computer, but visibility for me. Say you print the file on paper. All you see is white space after the end of the printed text. Is there an empty line? Or take, for instance, my example above, and think back to those VDUs, as we called them, where the firmware added a newline as soon as the cursor reached the right side of the screen, without waiting to see whether the next character was itself a newline or not.¹ So using an empty line approach, you might find yourself looking at a screen like: Last character position on the screen ---↓ swap LABEL= … … … … … … … … … … … … … … … … … … … … … =512 $ Now, is that an empty line before the prompt, or did the terminal add the extra newline itself because the swap line was exactly 80 characters long? Thanks! And nano is worse: to know you've reached the bottom, you have to check the cursor doesn't advance when you pound on the downarrow key. Yes, that's what I usually do. :) -- John
Last line [was: Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition]
On 26/04/2024 10:56, David Wright wrote: Editor examples: a windowed emacs buffer has a ≣ decoration at the extreme left edge after the last line of text, so that you can distinguish an absence of lines from empty lines. Perhaps that decoration should be explicitly enabled. However it reminded me the following: (info "(elisp) Library-Headers") https://www.gnu.org/software/emacs/manual/html_node/elisp/Library-Headers.html "D.8 Conventional Headers for Emacs Libraries" ‘;;; filename ends here’ This is the footer line; it appears at the very end of the file. Its purpose is to enable people to detect truncated versions of the file from the lack of a footer line. As to some ignored line at the end of a file: https://mywiki.wooledge.org/BashFAQ/005#Handling_newlines_.28or_lack_thereof.29_at_the_end_of_a_file "2.1.1. Handling newlines (or lack thereof) at the end of a file" in BASH FAQ "How can I use array variables?" `read` returns false when it reads the last line of a file. This presents a problem: if the file contains a trailing newline, then read will be false when reading/assigning that final line, otherwise, it will be false when reading/assigning the last line of data. Without a special check for these cases, no matter what logic is used, you will always end up either with an extra blank element in the resulting array, or a missing final element.
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
On Fri 26 Apr 2024 at 11:27:24 (+0900), John Crawley wrote: > On 24/04/2024 22:37, David Wright wrote: > > On Wed 24 Apr 2024 at 14:50:36 (+0200), Richard wrote: > > > upon gathering my thoughts for answering to you I found the solution to > > > this: update-initramfs can't handle the case that crypttab ends in the > > > line > > > of the last entry and not in a new line character. I think there either > > > should be a fix for this or at least a way to handle this case with a much > > > clearer error message. So I'll probably open a bug report for the package > > > and the maintainer can decide if that should be forwarded upstream. Such a > > > rather trivial case shouldn't be resulting in such fatal errors. > > > > Some time at the end of the last century, I remember some startup script > > that cat'd its configuration file for that very reason. It taught me > > the habit of always finishing files with a blank comment line: > > > > $ cat /etc/crypttab > > # > > swapLABEL=cryptswap /dev/urandom > > swap,offset=2048,cipher=aes-xts-plain64,size=512 > > # > > $ > > > > Innocent question: what difference does the comment make vs just ending the > file with an empty line? Nothing for the computer, but visibility for me. Say you print the file on paper. All you see is white space after the end of the printed text. Is there an empty line? Or take, for instance, my example above, and think back to those VDUs, as we called them, where the firmware added a newline as soon as the cursor reached the right side of the screen, without waiting to see whether the next character was itself a newline or not.¹ So using an empty line approach, you might find yourself looking at a screen like: Last character position on the screen ---↓ swap LABEL= … … … … … … … … … … … … … … … … … … … … … =512 $ Now, is that an empty line before the prompt, or did the terminal add the extra newline itself because the swap line was exactly 80 characters long? Editor examples: a windowed emacs buffer has a ≣ decoration at the extreme left edge after the last line of text, so that you can distinguish an absence of lines from empty lines. However, a non-windowed emacs in an xterm has no such decoration: you have to provoke an "end of buffer" message to be certain where the file ends. And nano is worse: to know you've reached the bottom, you have to check the cursor doesn't advance when you pound on the downarrow key. ¹ IIRC, there's a terminfo capability, am, to work around this. Cheers, David.
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
On 24/04/2024 22:37, David Wright wrote: On Wed 24 Apr 2024 at 14:50:36 (+0200), Richard wrote: upon gathering my thoughts for answering to you I found the solution to this: update-initramfs can't handle the case that crypttab ends in the line of the last entry and not in a new line character. I think there either should be a fix for this or at least a way to handle this case with a much clearer error message. So I'll probably open a bug report for the package and the maintainer can decide if that should be forwarded upstream. Such a rather trivial case shouldn't be resulting in such fatal errors. Some time at the end of the last century, I remember some startup script that cat'd its configuration file for that very reason. It taught me the habit of always finishing files with a blank comment line: $ cat /etc/crypttab # swapLABEL=cryptswap /dev/urandom swap,offset=2048,cipher=aes-xts-plain64,size=512 # $ Innocent question: what difference does the comment make vs just ending the file with an empty line? -- John
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
On Wed 24 Apr 2024 at 14:50:36 (+0200), Richard wrote: > upon gathering my thoughts for answering to you I found the solution to > this: update-initramfs can't handle the case that crypttab ends in the line > of the last entry and not in a new line character. I think there either > should be a fix for this or at least a way to handle this case with a much > clearer error message. So I'll probably open a bug report for the package > and the maintainer can decide if that should be forwarded upstream. Such a > rather trivial case shouldn't be resulting in such fatal errors. Some time at the end of the last century, I remember some startup script that cat'd its configuration file for that very reason. It taught me the habit of always finishing files with a blank comment line: $ cat /etc/crypttab # swapLABEL=cryptswap /dev/urandom swap,offset=2048,cipher=aes-xts-plain64,size=512 # $ Cheers, David.
Re: [SOLVED] Trouble/bug with initramfs-tools adding encrypted swap partition
Hi Michel, upon gathering my thoughts for answering to you I found the solution to this: update-initramfs can't handle the case that crypttab ends in the line of the last entry and not in a new line character. I think there either should be a fix for this or at least a way to handle this case with a much clearer error message. So I'll probably open a bug report for the package and the maintainer can decide if that should be forwarded upstream. Such a rather trivial case shouldn't be resulting in such fatal errors. Best Richard On Wed, Apr 24, 2024, 14:23 Michel Verdier wrote: > On 2024-04-23, Richard wrote: > > > luks-775ea946-6797-4c4d-a042-72924309f3d2 > > UUID=775ea946-6797-4c4d-a042-72924309f3d2 /crypto_keyfile.bin > > luks,keyscript=/bin/cat > > luks-78362aa3-760c-41de-b911-6531b684e3f7 > > UUID=78362aa3-760c-41de-b911-6531b684e3f7 /crypto_keyfile.bin > > luks,keyscript=/bin/cat > > initramfs extract line from /etc/crypttab to create its own crypttab > as you have seen in main/cryptroot/crypttab, and only for rootfs, not for > swap > > > Now, is this a bug in the package or am I missing something? And how do I > > create a working initramfs now? > > swap is usually mounted after rootfs is mounted, thus using > /etc/crypttab. If you want to resume from swap you have to follow > paragraph 2.2.1 on > https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption > > If you don't need to resume you can follow the much easier chapter 1 on > the same url, using /dev/urandom as a keyfile. > > >
Re: Trouble/bug with initramfs-tools adding encrypted swap partition
Hello Hans, this is exactly what I did. To be precise, I followed this guide [1], with the difference that instead of "crypt" I used the actual name, luks- (Disks thanksfully shows everything relevant). It's not the first time I'm doing this. Yet I experience the errors mentioned. Sure, I'm not using the -u flag with update-initramfs as I see no point in updating what's already broken, I just use -ck all. But that shouldn't make a difference. Best Richard [1]: https://wiki.debian.org/GrubEFIReinstall Am Mi., 24. Apr. 2024 um 08:35 Uhr schrieb Hans : > Am Dienstag, 23. April 2024, 22:26:17 CEST schrieb Richard: > > Hi Richard, > > this is, what I am doing when this happens: > > 1. booting into a live system (any new is working, I prefer kali-linux) > > 2. If you are using encrypted filesystems, open it. But you have to name > it like it is named in /etc/crypttab of the defective system > > 3. Now mount the device with root-filesystem to /mnt > > 4. If you have /boot as a separated partition, mount it to /mnt/boot > > 5. Now mount needed system directories to /mnt > > mount --bind /sys /mnt/sys > > mount --bind /proc /mnt/proc > > mount --bind /dev /mnt/dev > > 6. If everything is mounted correct, you can chroot into the mounted system > > chroot /mnt > > 7. Now you can create a new initrd > > update-initramfs -u > > > > 8. exit the chroot and reboot. > > > -- > > > Note: > > 1. if you have encrypted filesystems, check in the chroot the files > > /etc/crypttab > > /etc/cryptsetup-initramfs/conf-hook > > In conf-hook check the last line, the parm "ASKPASS=Y" should be commented > out. > > 2. You can check the UUID of every partition with the command > > blkid /dev/sda1 > > and compare it with the entries in /etc/fstab, /etc/crypttab and > everywhere else it is used. > > 3. In chroot, you can of course also create a new initrd, using > > update-initramfs -c -k all > > 4. Please remember, when you have encrypted partitions, then the UUID of > the device is other, than the partitions, you later mount. Example: > > blkid /dev/sda3 > > UUID=1234556-dfre-3456. > > Now > > cryptsetup luksOpen /dev/sda3 crypt_sda3 > > blkid /dev/mapper/crypt_sda3 > > UUID=9876g54-765g-87hg > > Watch this, when changing any UUIDs in /etc/fstab or anywhere else. > > Last but not least: Hope this helps, good luck! > > Best > > Hans > > > >
Re: Trouble/bug with initramfs-tools adding encrypted swap partition
On 2024-04-23, Richard wrote: > luks-775ea946-6797-4c4d-a042-72924309f3d2 > UUID=775ea946-6797-4c4d-a042-72924309f3d2 /crypto_keyfile.bin > luks,keyscript=/bin/cat > luks-78362aa3-760c-41de-b911-6531b684e3f7 > UUID=78362aa3-760c-41de-b911-6531b684e3f7 /crypto_keyfile.bin > luks,keyscript=/bin/cat initramfs extract line from /etc/crypttab to create its own crypttab as you have seen in main/cryptroot/crypttab, and only for rootfs, not for swap > Now, is this a bug in the package or am I missing something? And how do I > create a working initramfs now? swap is usually mounted after rootfs is mounted, thus using /etc/crypttab. If you want to resume from swap you have to follow paragraph 2.2.1 on https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption If you don't need to resume you can follow the much easier chapter 1 on the same url, using /dev/urandom as a keyfile.
Re: Trouble/bug with initramfs-tools adding encrypted swap partition
Am Dienstag, 23. April 2024, 22:26:17 CEST schrieb Richard: Hi Richard, this is, what I am doing when this happens: 1. booting into a live system (any new is working, I prefer kali-linux) 2. If you are using encrypted filesystems, open it. But you have to name it like it is named in / etc/crypttab of the defective system 3. Now mount the device with root-filesystem to /mnt 4. If you have /boot as a separated partition, mount it to /mnt/boot 5. Now mount needed system directories to /mnt mount --bind /sys /mnt/sys mount --bind /proc /mnt/proc mount --bind /dev /mnt/dev 6. If everything is mounted correct, you can chroot into the mounted system chroot /mnt 7. Now you can create a new initrd update-initramfs -u 8. exit the chroot and reboot. Note: 1. if you have encrypted filesystems, check in the chroot the files /etc/crypttab /etc/cryptsetup-initramfs/conf-hook In conf-hook check the last line, the parm "ASKPASS=Y" should be commented out. 2. You can check the UUID of every partition with the command blkid /dev/sda1 and compare it with the entries in /etc/fstab, /etc/crypttab and everywhere else it is used. 3. In chroot, you can of course also create a new initrd, using update-initramfs -c -k all 4. Please remember, when you have encrypted partitions, then the UUID of the device is other, than the partitions, you later mount. Example: blkid /dev/sda3 UUID=1234556-dfre-3456. Now cryptsetup luksOpen /dev/sda3 crypt_sda3 blkid /dev/mapper/crypt_sda3 UUID=9876g54-765g-87hg Watch this, when changing any UUIDs in /etc/fstab or anywhere else. Last but not least: Hope this helps, good luck! Best Hans
Trouble/bug with initramfs-tools adding encrypted swap partition
Hi, I've just set up a new computer with Debian Testing. I initially set it up without a swap partition, but I want to add it now. The partition has already been created as a LUKS2 partition, but I can't get update-initramfs to add it so it will automatically be decrypted at boot (both have same passphrase, but opposed to using the bootup passphrase or ask for a separate one, I'm only asked much later by grub. Running update-initramfs -ck all gives me this error: update-initramfs: Generating /boot/initrd.img-6.6.15-amd64 cryptsetup: WARNING: target 'luks-78362aa3-760c-41de-b911-6531b684e3f7' not found in /etc/crypttab but /etc/crypttab has these two lines, just like I did on my old device: luks-775ea946-6797-4c4d-a042-72924309f3d2 UUID=775ea946-6797-4c4d-a042-72924309f3d2 /crypto_keyfile.bin luks,keyscript=/bin/cat luks-78362aa3-760c-41de-b911-6531b684e3f7 UUID=78362aa3-760c-41de-b911-6531b684e3f7 /crypto_keyfile.bin luks,keyscript=/bin/cat So it clearly doesn't miss from the crypttab. Though I can'ft check if the second partition has a crypto_keyfile.bin, as it is a swap partition and I have no idea how to look inside. For completeness, that's the fstab: UUID=F5D8-8C91/boot/efi vfat defaults,noatime 0 2 /dev/mapper/luks-775ea946-6797-4c4d-a042-72924309f3d2 / btrfs subvol=/@,defaults,noatime,space_cache=v2,autodefrag,discard,compress=zstd:4 0 0 /dev/mapper/luks-775ea946-6797-4c4d-a042-72924309f3d2 /home btrfs subvol=/@home,defaults,noatime,space_cache=v2,autodefrag,discard,compress=zstd:4 0 0 /dev/mapper/luks-78362aa3-760c-41de-b911-6531b684e3f7 swap swap defaults,noatime,discard 0 0 tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 and this is the command line in /etc/default/grub (of course I did run update-grub afterward): GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=UUID=775ea946-6797-4c4d-a042-72924309f3d2:luks-775ea946-6797-4c4d-a042-72924309f3d2 root=/dev/mapper/luks-775ea946-6797-4c4d-a042-72924309f3d2 splash resume=/dev/mapper/luks-78362aa3-760c-41de-b911-6531b684e3f7" I even created the file /etc/initramfs-tools/conf.d/resume containing the line "RESUME=UUID=luks-78362aa3-760c-41de-b911-6531b684e3f7", also no change. In the meantime, I also tried adding the initramfs option in crypttab, yet no change. Upon inspecting the created initramfs by unpacking it with unmkinitramfs, I can see the initramfs does contain crypttab twice. The one in main/etc/crypttab is identical to the one in my system, but the one in main/cryptroot/crypttab is missing the second entry of the swap partition. Also, since then I've done a reboot and now when gdm would load I'm only greeted by a strange white screen telling my something happened the system can't recover from and that I should talk to my admin (or something like that). I was still able to switch tty. So while I'm not sure if that's even related, I tried to remove the swap partition from fstab, crypttab, grub and the resume file. But the same error kept happening over and over again. So I booted to a live USB (of 12.5), chrooted into the system without mounting the swap partition to try to run "update-initramfs -ck all" from there. But now it even refuses to find the root partition in crypttab. Now, is this a bug in the package or am I missing something? And how do I create a working initramfs now? Best Richard
Re: Help to report a bug related to a usb3 lan adapter driver
On Mon, 15 Apr 2024 20:57:00 +0200 user7415 same wrote: > I had a discussion in stack exchange related to the problem that is > well explained here: > https://unix.stackexchange.com/questions/774594/debian-12-all-of-sudden-my-usb3-lan-adapter-get-assigned-random-mac-address-ea > > For what I understood the problem was fixed in 6.8, but I'm using > debian 12 that will never use that so much new kernel I guess, could > you help me to report officially the bug so that the upstream channel > will correct it by the 6.1.0-22 version ? Bookwom backports has linux-image-6.6.13+bpo-amd64. You might try that. https://backports.debian.org/ It just so happens I have one of the same beasties. I just plugged it in to a machine running kernel 6.6.13+bpo-amd64, unplugged it, waited 20 seconds, and plugged it in to another machine running kernel 6.5.0-0.deb12.4-amd64. I then plugged it into a machine with 6.6.13+bpo-amd64. All three times I got a MAC address of 8c:ae:4c:d6:22:17. So either of those kernels might well work for you. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Help to report a bug related to a usb3 lan adapter driver
Hello, I'm not very skilled in what concerns to kernel patching and compiling. I had a discussion in stack exchange related to the problem that is well explained here: https://unix.stackexchange.com/questions/774594/debian-12-all-of-sudden-my-usb3-lan-adapter-get-assigned-random-mac-address-ea For what I understood the problem was fixed in 6.8, but I'm using debian 12 that will never use that so much new kernel I guess, could you help me to report officially the bug so that the upstream channel will correct it by the 6.1.0-22 version ? Thank you very much!
Bug#735496: initramfs-tools fails because of missing keyutils package
Hola, doncs això que sembla que aquest "bug" torna a estar present. https://lists.debian.org/debian-kernel/2014/01/msg00218.html M'estic barallant amb una arrencada dual d'una linkat i una debian totes dues amb les particions arrel i swap xifrades. Per no haver de posar dues vegades el password de xifrat es pot configurar el fitxer /etc/crypttab i posteriorment executar update-initramfs -u però surt un missatge d'error: E: /usr/share/initramfs-tools/hooks/cryptkeyctl failed with return 1. Instal·lant el paquet keyutils es soluciona. Vagi bé -- - 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: How to file a Debian bug report? was: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
On 2 Apr 2024 10:27 +0200, from jch...@student.ethz.ch (Jonathan Chung): > Can someone help me to file a bug report? https://www.debian.org/Bugs/Reporting -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Debian 12.5.0 amd64 and OpenZFS bug #15526
On Mon 25/03/2024 at 23:40, David Christensen wrote: > On 3/25/24 15:05, Gareth Evans wrote: >> On Fri 22/03/2024 at 21:01, Gareth Evans wrote: >>> As anyone interested can see from the ref to #15933 in the below, there >>> seems to have been considerable effort in getting to grips with this bug >>> (actually multiple bugs), and it looks like a fix may be forthcoming, >>> though not sure at the time of writing if there may be some further >>> polishing first >>> >>> https://github.com/openzfs/zfs/pull/16019 >> >> https://github.com/openzfs/zfs/issues/15933 >> >> is now closed as completed with fix >> >> https://github.com/openzfs/zfs/commit/102b468b5e190973fbaee6fe682727eb33079811 >> >> which for the moment necessarily adds synchronous writes. >> >> FYI. >> Gareth > > > Thank you for keeping an eye on this. > > > Looking at the github commit, the C code makes me worry -- it does not > appear to use traditional C/C++ thread-safe programming techniques such > as I learned in CS and used when I did systems programming (e.g. guard > functions, critical sections, locks, semaphores, etc.). > Do I need to > look at more enclosing code to see such, are those techniques missing, > are there some newer techniques I do not understand, or something else? I don't know, I will have a look too, though my C[++] is almost as rusty as my Rust :) G
Re: Debian 12.5.0 amd64 and OpenZFS bug #15526
On 3/25/24 15:05, Gareth Evans wrote: On Fri 22/03/2024 at 21:01, Gareth Evans wrote: As anyone interested can see from the ref to #15933 in the below, there seems to have been considerable effort in getting to grips with this bug (actually multiple bugs), and it looks like a fix may be forthcoming, though not sure at the time of writing if there may be some further polishing first https://github.com/openzfs/zfs/pull/16019 https://github.com/openzfs/zfs/issues/15933 is now closed as completed with fix https://github.com/openzfs/zfs/commit/102b468b5e190973fbaee6fe682727eb33079811 which for the moment necessarily adds synchronous writes. FYI. Gareth Thank you for keeping an eye on this. Looking at the github commit, the C code makes me worry -- it does not appear to use traditional C/C++ thread-safe programming techniques such as I learned in CS and used when I did systems programming (e.g. guard functions, critical sections, locks, semaphores, etc.). Do I need to look at more enclosing code to see such, are those techniques missing, are there some newer techniques I do not understand, or something else? David
Re: Debian 12.5.0 amd64 and OpenZFS bug #15526
On Fri 22/03/2024 at 21:01, Gareth Evans wrote: > As anyone interested can see from the ref to #15933 in the below, there seems > to have been considerable effort in getting to grips with this bug (actually > multiple bugs), and it looks like a fix may be forthcoming, though not sure > at the time of writing if there may be some further polishing first > > https://github.com/openzfs/zfs/pull/16019 https://github.com/openzfs/zfs/issues/15933 is now closed as completed with fix https://github.com/openzfs/zfs/commit/102b468b5e190973fbaee6fe682727eb33079811 which for the moment necessarily adds synchronous writes. FYI. Gareth
Re: Debian 12.5.0 amd64 and OpenZFS bug #15526
> On 27 Feb 2024, at 23:47, Gareth Evans wrote: > On Tue 27/02/2024 at 22:52, David Christensen > wrote: >> ... >> These appear to be the ZFS packages for the available Debian releases: >> >> https://packages.debian.org/buster/zfs-dkms >> >> busterzfs-dkms (0.7.12-2+deb10u2) >> buster-backportszfs-dkms (2.0.3-9~bpo10+1) >> bullseyezfs-dkms (2.0.3-9+deb11u1) >> bullseye-backportszfs-dkms (2.1.11-1~bpo11+1) >> bookwormzfs-dkms (2.1.11-1) >> bookworm-backportszfs-dkms (2.2.2-4~bpo12+1) >> trixiezfs-dkms (2.2.2-4) >> >> >> The question is, how far back to go? Is OpenZFS 2.1.x buggy? OpenZFS >> 2.0.x? What is 0.7.12 -- OpenZFS, ZFS-on-Linux, or something else -- >> and is it buggy? > > This seems to be very "involved"! The discussion in #15526 suggests a > coreutils upgrade (particularly re. "cp") in combination with the addition of > the zpool block cloning feature seems to have triggered the issue, which may > have gone undetected for some time. > >>> After downgrading coreutils from 9.3 to 8.32, I am no longer able to >>> reproduce this corruption. >> This seems to solve the corruption issue on my end too. > -- https://github.com/openzfs/zfs/issues/15526#issuecomment-1810472547 > > See also > https://www.reddit.com/r/zfs/comments/1826lgs/psa_its_not_block_cloning_its_a_data_corruption/ > > Debian users can't follow the gentoo/emerge-based reproduction/trigger steps > for build of golang in > https://github.com/openzfs/zfs/issues/15526 (for zfs 2.2.0) > and > https://github.com/openzfs/zfs/issues/15933 (for 2.2.3) > > If anyone can recommend steps to debianise these (15933 seem most likely to > be useful, and slightly different), I would be happy to test openzfs 2.2.2-4 > from bookworm-backports on deb 12.5 > > Given that the original gentoo reporter, who seems to have tested > extensively, considered the issue closed after upgrade to openzfs 2.2.2 > > https://bugs.gentoo.org/917224#c26 > > I wonder if the 2.2.3 issue is similar/related, or perhaps there are multiple > triggers. > > Watching with interest. > > Best wishes, > Gareth > As anyone interested can see from the ref to #15933 in the below, there seems to have been considerable effort in getting to grips with this bug (actually multiple bugs), and it looks like a fix may be forthcoming, though not sure at the time of writing if there may be some further polishing first https://github.com/openzfs/zfs/pull/16019
Re: Question about what package to report bug
Le 06/03/2024 à 18:19, ke6jti a écrit : Hi, I have a possible kernel regression for a usb-dvb tuner card. I know the error in dmesg points to kernel : au0828 but I am not sure what package this belongs to. I think it belongs to v4l(video for linux) but I am still not sure what specific v4l package. Thanks for you help. apt-file shows au0828.ko comes in the linux-image-* packages. So report the bug for the one you use.
Question about what package to report bug
Hi, I have a possible kernel regression for a usb-dvb tuner card. I know the error in dmesg points to kernel : au0828 but I am not sure what package this belongs to. I think it belongs to v4l(video for linux) but I am still not sure what specific v4l package. Thanks for you help.
test of a gnuplot bug visible with Pango 1.52 (Debian/unstable)
Hi, Since the upgrade of the Pango library to 1.52 in Debian/unstable, I'm seeing an annoying bug in gnuplot with the wxt terminal. The issue can be reproduced with the following command: echo 'set terminal wxt; plot x' | gnuplot -persist A window appears, but it is not drawn and it cannot be deleted by gnuplot. One can destroy it, but the gnuplot process is still running (in background). I can observe this bug with the FVWM window manager, with both manual placement and immediate placement (manual placement can make the problem worse). I don't think that this is a bug in Pango: the commit that introduces the change of behavior does some optimization in threading, which probably makes Pango a bit faster, which triggers a race condition (note that conversely, if I use ssh, even "ssh localhost", this makes the problem disappear). Details in my bug reports: https://sourceforge.net/p/gnuplot/bugs/2693/ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064982 Can anyone else reproduce this issue, in particular with other window managers? -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: which package to file a bug report ?
On Tue Feb 27, 2024 at 7:12 AM GMT, Frank Weißer wrote: > So we are at my original question: Which package to file a bug report ? Package "debian-installer", I think; and/or submit an installation report, which can be done with reportbug against the "installation-report" pseudo package. See <https://d-i.debian.org/manual/en.amd64/ch05s04.html#submit-bug> -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Debian 12.5.0 amd64 and OpenZFS bug #15526
On Tue 27/02/2024 at 22:52, David Christensen wrote: > ... > These appear to be the ZFS packages for the available Debian releases: > > https://packages.debian.org/buster/zfs-dkms > > busterzfs-dkms (0.7.12-2+deb10u2) > buster-backports zfs-dkms (2.0.3-9~bpo10+1) > bullseye zfs-dkms (2.0.3-9+deb11u1) > bullseye-backportszfs-dkms (2.1.11-1~bpo11+1) > bookworm zfs-dkms (2.1.11-1) > bookworm-backportszfs-dkms (2.2.2-4~bpo12+1) > trixiezfs-dkms (2.2.2-4) > > > The question is, how far back to go? Is OpenZFS 2.1.x buggy? OpenZFS > 2.0.x? What is 0.7.12 -- OpenZFS, ZFS-on-Linux, or something else -- > and is it buggy? This seems to be very "involved"! The discussion in #15526 suggests a coreutils upgrade (particularly re. "cp") in combination with the addition of the zpool block cloning feature seems to have triggered the issue, which may have gone undetected for some time. >> After downgrading coreutils from 9.3 to 8.32, I am no longer able to >> reproduce this corruption. > This seems to solve the corruption issue on my end too. -- https://github.com/openzfs/zfs/issues/15526#issuecomment-1810472547 See also https://www.reddit.com/r/zfs/comments/1826lgs/psa_its_not_block_cloning_its_a_data_corruption/ Debian users can't follow the gentoo/emerge-based reproduction/trigger steps for build of golang in https://github.com/openzfs/zfs/issues/15526 (for zfs 2.2.0) and https://github.com/openzfs/zfs/issues/15933 (for 2.2.3) If anyone can recommend steps to debianise these (15933 seem most likely to be useful, and slightly different), I would be happy to test openzfs 2.2.2-4 from bookworm-backports on deb 12.5 Given that the original gentoo reporter, who seems to have tested extensively, considered the issue closed after upgrade to openzfs 2.2.2 https://bugs.gentoo.org/917224#c26 I wonder if the 2.2.3 issue is similar/related, or perhaps there are multiple triggers. Watching with interest. Best wishes, Gareth
Re: Debian 12.5.0 amd64 and OpenZFS bug #15526
On 2/26/24 20:52, Gareth Evans wrote: Replied to OP by mistake, reposting to list. On Sun 25/02/2024 at 05:34, David Christensen wrote: debian-user: Is Debian 12.5.0 amd64 affected by OpenZFS bug #15526? https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso https://packages.debian.org/bookworm/zfs-dkms https://github.com/openzfs/zfs/issues/15526 Hi David, Given the complexity of the issues, I'm not sure if this truly answers your question, but https://github.com/openzfs/zfs/issues/15933 seems to suggest that or a similar issue is still ongoing with Open ZFS 2.2.3, which is later than the version currently available from bookworm or bookworm-backports. It seems bookworm-backports might eventually provide the solution, if at all, per the Debian wiki on ZFS: "it is recommended by Debian ZFS on Linux Team to install ZFS related packages from Backports archive. Upstream stable patches will be tracked and compatibility is always maintained." https://wiki.debian.org/ZFS Currently: $ apt policy zfs-dkms zfs-dkms: Installed: 2.2.2-4~bpo12+1 Candidate: 2.2.2-4~bpo12+1 Version table: *** 2.2.2-4~bpo12+1 100 100 https://deb.debian.org/debian bookworm-backports/contrib amd64 Packages 100 https://deb.debian.org/debian bookworm-backports/contrib i386 Packages 100 /var/lib/dpkg/status 2.1.11-1 500 500 https://deb.debian.org/debian bookworm/contrib amd64 Packages 500 https://deb.debian.org/debian bookworm/contrib i386 Packages Hope that helps. Gareth That you for citing OpenZFS bug #15933. These appear to be the ZFS packages for the available Debian releases: https://packages.debian.org/buster/zfs-dkms buster zfs-dkms (0.7.12-2+deb10u2) buster-backportszfs-dkms (2.0.3-9~bpo10+1) bullseyezfs-dkms (2.0.3-9+deb11u1) bullseye-backports zfs-dkms (2.1.11-1~bpo11+1) bookwormzfs-dkms (2.1.11-1) bookworm-backports zfs-dkms (2.2.2-4~bpo12+1) trixie zfs-dkms (2.2.2-4) The question is, how far back to go? Is OpenZFS 2.1.x buggy? OpenZFS 2.0.x? What is 0.7.12 -- OpenZFS, ZFS-on-Linux, or something else -- and is it buggy? David
Re: which package to file a bug report ?
Marco Moock: Am Fri, 23 Feb 2024 13:59:41 +0100 schrieb Frank Weißer : The installer does format it as ext4, but shows ext2 and places that in fstab, what ends up in emergency mode. That's why I'm here That is definitely a bug. So we are at my original question: Which package to file a bug report ? readU Frank
Re: Debian 12.5.0 amd64 and OpenZFS bug #15526
On Tue 27/02/2024 at 04:52, Gareth Evans wrote: > https://github.com/openzfs/zfs/issues/15933 > > seems to suggest that or a similar issue is still ongoing with Open ZFS > 2.2.3 ... I wonder if that might be a regression, since what I think is the same issue as openzfs #15526 appeared to be resolved in ZFS 2.2.2 "I've been unable to reproduce this after upgrading to zfs-2.2.2" https://bugs.gentoo.org/917224 I imagine openzfs problems (and solutions) are likely to be the same across distributions? Kind regards, G
Re: Debian 12.5.0 amd64 and OpenZFS bug #15526
Replied to OP by mistake, reposting to list. On Sun 25/02/2024 at 05:34, David Christensen wrote: > debian-user: > > Is Debian 12.5.0 amd64 affected by OpenZFS bug #15526? > > https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso > > https://packages.debian.org/bookworm/zfs-dkms > > https://github.com/openzfs/zfs/issues/15526 Hi David, Given the complexity of the issues, I'm not sure if this truly answers your question, but https://github.com/openzfs/zfs/issues/15933 seems to suggest that or a similar issue is still ongoing with Open ZFS 2.2.3, which is later than the version currently available from bookworm or bookworm-backports. It seems bookworm-backports might eventually provide the solution, if at all, per the Debian wiki on ZFS: "it is recommended by Debian ZFS on Linux Team to install ZFS related packages from Backports archive. Upstream stable patches will be tracked and compatibility is always maintained." https://wiki.debian.org/ZFS Currently: $ apt policy zfs-dkms zfs-dkms: Installed: 2.2.2-4~bpo12+1 Candidate: 2.2.2-4~bpo12+1 Version table: *** 2.2.2-4~bpo12+1 100 100 https://deb.debian.org/debian bookworm-backports/contrib amd64 Packages 100 https://deb.debian.org/debian bookworm-backports/contrib i386 Packages 100 /var/lib/dpkg/status 2.1.11-1 500 500 https://deb.debian.org/debian bookworm/contrib amd64 Packages 500 https://deb.debian.org/debian bookworm/contrib i386 Packages Hope that helps. Gareth
Debian 12.5.0 amd64 and OpenZFS bug #15526
debian-user: Is Debian 12.5.0 amd64 affected by OpenZFS bug #15526? https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso https://packages.debian.org/bookworm/zfs-dkms https://github.com/openzfs/zfs/issues/15526 David
Re: which package to file a bug report ?
Am Fri, 23 Feb 2024 13:59:41 +0100 schrieb Frank Weißer : > First of all: I use german during installation; but I doubt that is > relevant. Try to reproduce it in English if you like. > Marco Moock: > > Am 22.02.2024 schrieb Frank Weißer : > > > >> I only choose ext2 for formatting the encrypted partition, because > >> nothing else is offered. > > > > That is really strange. If I did install Debian 12, it offered me a > > list of different file systems, including ext2/3/4. > > > It does on non-crypt partitions, but not if I choose 'physical volume > for encryption' there; then afterwards I only have the choices to use > it as ext2, swap or lvm or leave it unused for the encrypted > partition. I chose manual partitioning and I created the LUKS container manually and then created an ext4 partition inside. > >> Despite that the partition in fact is getting formatted ext4, so > >> the entry ext2 in /etc/fstab leads into emergency mode. > > > > Does the installer format it as ext4, but shows ext2 and places > > that in fstab? > > Or do you format it manually? > > > The installer does format it as ext4, but shows ext2 and places that > in fstab, what ends up in emergency mode. That's why I'm here That is definitely a bug.
Re: Where to report print driver bug
Am Fri, 23 Feb 2024 14:47:41 -0500 schrieb James Klaas : > "Generic PCL 6/PCL XL Printer Foomatic/pxlcolor (recommended)" Do you know the file that provides that? If so, you apt-file search "file" to find the package that provides it.
Where to report print driver bug
I was going to submit a bug for this but I don't know what package I should report the bug against. Debian bugreport says: Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem. If you don't know what package the bug is in, please contact debian-user@lists.debian.org for assistance. I have a Dell 2130cn, which is a PCL6 compatible printer. CUPS/Print manager says "Generic PCL 6/PCL XL Printer Foomatic/pxlcolor (recommended)" is the recommended driver and the only PCL6 driver that actually prints in color as far as I can tell. However, sometime in the past year or two (maybe between Bullseye and Bookworm), this driver no longer allows me to print in duplex. I was able to print in duplex from Windows, so I decided to try a different driver. I tried both "Generic PCL 6/PCL XL Printer - CUPS+Gutenprint v5.3.4" and "Generic PCL 6/PCL XL Printer Foomatic/hpijs-pcl5c" They both print in duplex, but do not print in color. I would like to submit a bug report, but I do not know if I should only submit one for printer-driver-pxljr, which I think provides pxlcolor or something more generic.
Re: which package to file a bug report ?
First of all: I use german during installation; but I doubt that is relevant. Marco Moock: Am 22.02.2024 schrieb Frank Weißer : I only choose ext2 for formatting the encrypted partition, because nothing else is offered. That is really strange. If I did install Debian 12, it offered me a list of different file systems, including ext2/3/4. It does on non-crypt partitions, but not if I choose 'physical volume for encryption' there; then afterwards I only have the choices to use it as ext2, swap or lvm or leave it unused for the encrypted partition. Despite that the partition in fact is getting formatted ext4, so the entry ext2 in /etc/fstab leads into emergency mode. Does the installer format it as ext4, but shows ext2 and places that in fstab? Or do you format it manually? The installer does format it as ext4, but shows ext2 and places that in fstab, what ends up in emergency mode. That's why I'm here
Re: which package to file a bug report ?
Am 22.02.2024 schrieb Frank Weißer : > I only choose ext2 for formatting the encrypted partition, because > nothing else is offered. That is really strange. If I did install Debian 12, it offered me a list of different file systems, including ext2/3/4. > Despite that the partition in fact is getting formatted ext4, so the > entry ext2 in /etc/fstab leads into emergency mode. Does the installer format it as ext4, but shows ext2 and places that in fstab? Or do you format it manually? > I think the partitioning tool in installer should offer to format the > encrypted partition in ext4, as LUKS (?) does, instead of ext2 and > must write ext4 to /etc/fstab, as this is, how it ends up. LUKS is only a container and doesn't care about the file system inside. After opening it, it is a file under /dev/mapper that can be formatted like /dev/sdXY.
Re: which package to file a bug report ?
Marco Moock: Am 22.02.2024 um 13:18:48 Uhr schrieb Frank Weißer: I use to encrypt my swap and /var/tmp partitions during installation. That is LUKS. the partition tool in debian installer offers me randomized keys for that and has 'delete partition' set to 'yes', which costs lot of time, not necessary on new hdd/ssd and - my opinion - on randomized keys. I propose switching to 'no', when selecting randomized keys. Why? A user can rather easy select what he wants. As I said: My opinion; if you miss setting 'no' you have to wait a lot of time... Further I can select ext2 or swap for partition format. That is really strange. swap is only for the special-purpose swap partition. Yes, I choose it for the swap partition I use ext2 for /var/tmp, but - in /etc/crypttab the marker 'tmp' is missing for the /var/tmp partition Which marker? This one: frank@pc:~$ cat /etc/crypttab sda4_crypt /dev/sda4 /dev/urandom cipher=aes-xts- plain64,size=256,swap,discard sda5_crypt /dev/sda5 /dev/urandom cipher=aes-xts- plain64,size=256,tmp,discard ^^^ crypttab is only for decrypting the partition and creating a device file for the encrypted one. - in /etc/fstab ext2 is set instead of ext4, that cryptsetup defaults to. So on reboot I end up in emergency mode. If you format it in ext2, choose that. Or was that an automatic decision by the installer? I only choose ext2 for formatting the encrypted partition, because nothing else is offered. Despite that the partition in fact is getting formatted ext4, so the entry ext2 in /etc/fstab leads into emergency mode. I think the partitioning tool in installer should offer to format the encrypted partition in ext4, as LUKS (?) does, instead of ext2 and must write ext4 to /etc/fstab, as this is, how it ends up.
Re: which package to file a bug report ?
Am 22.02.2024 um 13:18:48 Uhr schrieb Frank Weißer: > I use to encrypt my swap and /var/tmp partitions during installation. That is LUKS. > the partition tool in debian installer offers me randomized keys for > that and has 'delete partition' set to 'yes', which costs lot of > time, not necessary on new hdd/ssd and - my opinion - on randomized > keys. I propose switching to 'no', when selecting randomized keys. Why? A user can rather easy select what he wants. > Further I can select ext2 or swap for partition format. That is really strange. swap is only for the special-purpose swap partition. > I use ext2 for /var/tmp, but > - in /etc/crypttab the marker 'tmp' is missing for the /var/tmp > partition Which marker? crypttab is only for decrypting the partition and creating a device file for the encrypted one. > - in /etc/fstab ext2 is set instead of ext4, that cryptsetup defaults > to. So on reboot I end up in emergency mode. If you format it in ext2, choose that. Or was that an automatic decision by the installer? -- Gruß Marco Spam und Werbung bitte an ichschickerekl...@cartoonies.org
which package to file a bug report ?
Hello! I use to encrypt my swap and /var/tmp partitions during installation. the partition tool in debian installer offers me randomized keys for that and has 'delete partition' set to 'yes', which costs lot of time, not necessary on new hdd/ssd and - my opinion - on randomized keys. I propose switching to 'no', when selecting randomized keys. Further I can select ext2 or swap for partition format. I use ext2 for /var/tmp, but - in /etc/crypttab the marker 'tmp' is missing for the /var/tmp partition - in /etc/fstab ext2 is set instead of ext4, that cryptsetup defaults to. So on reboot I end up in emergency mode. What package have I to file the bug report against? Please apologize my poor english. Kind regards readU Frank
Re: shred bug? [was: Unidentified subject!]
On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: What Thomas was trying to do is to get a cheap, fast random number generator. Shred seems to have such. You're better off with /dev/urandom, it's much easier to understand what it's trying to do, vs the rather baroque logic in shred. In fact, there's nothing in shred's documenation AFAICT that suggests it should be used as a random number generator. For pure speed, playing games with openssl enc and /dev/zero will generally win. If speed doesn't matter, we're back to /dev/urandom as the simplest and most direct solution. FWIW, the main use for shred in 2024 is: to be there so someone's old script doesn't break. There's basically no good use case for it, and it probably shouldn't have gotten into coreutils in the first place. The multipass pattern stuff is cargo-cult voodoo--a single overwrite with zeros will be as effective as anything else--and on modern storage/filesystems there's a good chance your overwrite won't overwrite anything anyway. Probably the right answer is a kernel facility (userspace can't guarantee anything). If you're really sure that overwrites work on your system, `shred -n0 -z` will be the fastest way to do that. The docs say don't do that because SSDs might optimize that away, but SSDs probably aren't overwriting anything anyway (also mentioned in the docs). ¯\_(ツ)_/¯
Re: shred bug? [was: Unidentified subject!]
On Tue 13 Feb 2024 at 11:21:08 (-0500), Greg Wooledge wrote: > On Tue, Feb 13, 2024 at 09:35:11AM -0600, David Wright wrote: > > On Tue 13 Feb 2024 at 07:15:48 (-0500), Greg Wooledge wrote: > > > On Mon, Feb 12, 2024 at 11:01:47PM -0600, David Wright wrote: > > > > … but not much. For me, "standard output" is /dev/fd/1, yet it seems > > > > unlikely that anyone is going to use >&1 in the manner of the example. > > > > > > Standard output means "whatever file descriptor 1 points to". That > > > could be a file, a pipe, a terminal (character device), etc. > > > > Why pick on 1? > > It's the definition. Standard input is FD 0, standard output is FD 1, > and standard error is FD 2. > > > . It demonstrates the shell syntax element required (&) in order to > > avoid truncating the file, rather than shred overwriting it. > > You are confused. You're making assumptions about shell syntax that > are simply not true. You're right. I was looking too hard at the right side of the > and neglecting the implied left side. It's always worth running these things past your eyes. Thanks for the clear exposition that followed. Cheers, David.
Re: shred bug? [was: Unidentified subject!]
On Tue, Feb 13, 2024 at 01:03:44PM -0800, David Christensen wrote: > On 2/13/24 09:40, debian-u...@howorth.org.uk wrote: > > Greg Wooledge wrote: > > > > > Shred will determine the size of the file, then write data to the > > > file, rewind, write data again, etc. On a traditional hard drive, > > > that will overwrite the original private information. On modern > > > devices, it may not. > > > > Thanks for the excellent explanation :) > > > > One nitpick. You say "On a traditional hard drive, that will overwrite > > the original private information" but that's not quite true. It also > > needs to be a "traditional" file system! That is, not journalled or COW. > > > > So nowadays I would expect shred not to work unless you got very > > lucky, or planned carefully. > > > Perhaps zerofree(8)? On a SATA, it won't get at (some) of the spare blocks, since it doesn't know that they are there. If your data is so sensitive that you don't want it to escape, your best bet seems to plan ahead and not let it hit your media unencrypted. Use LUKS. And oh, use argon2id as key derivation function [1] these days. Cheers [1] https://mjg59.dreamwidth.org/66429.html -- t signature.asc Description: PGP signature
Re: shred bug? [was: Unidentified subject!]
On 2/13/24 16:00, David Christensen wrote: On 2/13/24 11:31, gene heskett wrote: Next experiment is a pair of 4T Silicon Power SSD's When they & the startech usb3 adapters arrive. I'll get that NAS built for amanda yet. 2.5" SATA SSD's and SATA to USB adapter cables for $187.97 + $10.99 = $198.96 each set? https://www.amazon.com/dp/B0BVLRFFWQ https://www.amazon.com/dp/B00HJZJI84 Why not external USB drives for $192.99? https://www.amazon.com/dp/B0C6XVZS4K For $7 more, you can get the "Pro edition" in black with two cables: https://www.amazon.com/dp/B0C69QD5NK You could plug those into the two USB-C 3.1 Gen 2 ports on your Asus PRIME Z370-A II motherboard. Maybe, but these sata types have the the mounting bolts the usb versions don't. And fits the drive adapters I already have that put both in one drive tray. Not to mention if Taiwan has a similar product, I tend to buy it. So are the 4 2T gigastones I'll fill the next 2 drawers with so I should wind up with a 16T backup server's LVM. with a 1/2T Samsung 870 as a holding disk. Running a bpi-m5 headless, maybe < 20 watts. Whats not to like? David . Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: shred bug? [was: Unidentified subject!]
On 2/13/24 09:40, debian-u...@howorth.org.uk wrote: Greg Wooledge wrote: Shred will determine the size of the file, then write data to the file, rewind, write data again, etc. On a traditional hard drive, that will overwrite the original private information. On modern devices, it may not. Thanks for the excellent explanation :) One nitpick. You say "On a traditional hard drive, that will overwrite the original private information" but that's not quite true. It also needs to be a "traditional" file system! That is, not journalled or COW. So nowadays I would expect shred not to work unless you got very lucky, or planned carefully. Perhaps zerofree(8)? David
Re: shred bug? [was: Unidentified subject!]
On 2/13/24 11:31, gene heskett wrote: Next experiment is a pair of 4T Silicon Power SSD's When they & the startech usb3 adapters arrive. I'll get that NAS built for amanda yet. 2.5" SATA SSD's and SATA to USB adapter cables for $187.97 + $10.99 = $198.96 each set? https://www.amazon.com/dp/B0BVLRFFWQ https://www.amazon.com/dp/B00HJZJI84 Why not external USB drives for $192.99? https://www.amazon.com/dp/B0C6XVZS4K For $7 more, you can get the "Pro edition" in black with two cables: https://www.amazon.com/dp/B0C69QD5NK You could plug those into the two USB-C 3.1 Gen 2 ports on your Asus PRIME Z370-A II motherboard. David
Re: shred bug? [was: Unidentified subject!]
On 2/13/24 14:44, Thomas Schmitt wrote: Hi, Gene Heskett wrote: Next experiment is a pair of 4T Silicon Power SSD's When f3 has (hopefully) given its OK, the topic of a full write-and-read test will come up again. I'm looking forward to all the spin-off topics. I'll have to admit it has been quite educational. Now, can I remember it next week? YTBD.> Have a nice day :) You too Thomas. Take care and stay well. Thomas Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: shred bug? [was: Unidentified subject!]
Hi, Gene Heskett wrote: > Next experiment is a pair of 4T Silicon Power SSD's When f3 has (hopefully) given its OK, the topic of a full write-and-read test will come up again. I'm looking forward to all the spin-off topics. Have a nice day :) Thomas
Re: shred bug? [was: Unidentified subject!]
Hi, Greg Wooledge wrote: > Heh. Don't forget your own attempts to use a shredder as a PRNG stream. My original idea was to watch a minimal shred run by teeing its work into a checksummer. But then topic drift came in. So we got a farm show of random generators and a discussion about what exactly is a bug in shred's documentation. Plus the shell programming webinar. And a diagnosis about a rightously failed attempt to change the partition table type from MBR/DOS to GPT. And this all because Gene Heskett was adventurous enough to buy a cheap fake USB disk. Have a nice day :) Thomas
Re: shred bug? [was: Unidentified subject!]
On 2/13/24 12:56, Thomas Schmitt wrote: Hi, Greg Wooledge wrote: Let me write out the example again, but with the bug fixed, and then explain what each line does, [... lecture about advanced shell programming ...] And this all because Gene Heskett was adventurous enough to buy a cheap fake USB disk. :)) Guilty as charged, Thomas. My advantage is that it won't affect the length of the ladder up my side of the hog. If I save someone else from getting bit by that fraud I'm pleased. Next experiment is a pair of 4T Silicon Power SSD's When they & the startech usb3 adapters arrive. I'll get that NAS built for amanda yet. Have a nice day :) You too. Thomas Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: shred bug? [was: Unidentified subject!]
On Tue, Feb 13, 2024 at 06:54:58PM +0100, Thomas Schmitt wrote: > Greg Wooledge wrote: > > Let me write out the example again, but with the bug fixed, and then > > explain what each line does, [... lecture about advanced shell > > programming ...] > > And this all because Gene Heskett was adventurous enough to buy a cheap > fake USB disk. :)) Heh. Don't forget your own attempts to use a shredder as a PRNG stream. Shell redirections can be complicated, so this topic is going to come up once in a while. The example in the shred info page is fairly unintuitive, so it deserves a bit of explanation. I imagine most readers who saw it simply accepted it as written, which is why the bug went undiscovered for two decades.
Re: shred bug? [was: Unidentified subject!]
Hi, Greg Wooledge wrote: > Let me write out the example again, but with the bug fixed, and then > explain what each line does, [... lecture about advanced shell > programming ...] And this all because Gene Heskett was adventurous enough to buy a cheap fake USB disk. :)) Have a nice day :) Thomas
Re: shred bug? [was: Unidentified subject!]
Greg Wooledge wrote: > Shred will determine the size of the file, then write data to the > file, rewind, write data again, etc. On a traditional hard drive, > that will overwrite the original private information. On modern > devices, it may not. Thanks for the excellent explanation :) One nitpick. You say "On a traditional hard drive, that will overwrite the original private information" but that's not quite true. It also needs to be a "traditional" file system! That is, not journalled or COW. So nowadays I would expect shred not to work unless you got very lucky, or planned carefully.
Re: shred bug? [was: Unidentified subject!]
On Tue, Feb 13, 2024 at 09:35:11AM -0600, David Wright wrote: > On Tue 13 Feb 2024 at 07:15:48 (-0500), Greg Wooledge wrote: > > On Mon, Feb 12, 2024 at 11:01:47PM -0600, David Wright wrote: > > > … but not much. For me, "standard output" is /dev/fd/1, yet it seems > > > unlikely that anyone is going to use >&1 in the manner of the example. > > > > Standard output means "whatever file descriptor 1 points to". That > > could be a file, a pipe, a terminal (character device), etc. > > Why pick on 1? It's the definition. Standard input is FD 0, standard output is FD 1, and standard error is FD 2. > . It demonstrates the shell syntax element required (&) in order to > avoid truncating the file, rather than shred overwriting it. You are confused. You're making assumptions about shell syntax that are simply not true. > > > >A FILE of ‘-’ denotes standard output. The intended use of this is > > > >to shred a removed temporary file. For example: > > > > > > > > i=$(mktemp) > > > > exec 3<>"$i" > > > > rm -- "$i" > > > > echo "Hello, world" >&3 > > > > shred - >&3 > > > > exec 3>- > Ironic that it truncates a file, and then immediately warns against > truncating a file instead of shredding it. No. This is not what it does (if we fix the bug). Let me write out the example again, but with the bug fixed, and then explain what each line does, because apparently there is a LOT of misunderstanding here. i=$(mktemp) exec 3<>"$i" rm -- "$i" echo "Hello, world" >&3 shred - >&3 exec 3>&- The first line runs mktemp(1), which is a GNU coreutils program that creates a temporary file, and then writes its name to standard output. The shell syntax grabs that name and stores it in the variable "i". So, after line 1, we have an (empty) temporary file, which was created by a child process that has terminated. We have its name in a variable. Creation of temporary files works a little bit differently in shell scripts than it does in regular programs. In most other languages, you would call a library function that creates the temporary file (keeping it open), optionally unlinks it, and returns the open file descriptor to you for use. But you can't do that in a shell script that needs an external program to do the file creation. So we have this slightly clumsy approach. The second line opens this file for reading and writing, and ensures that file descriptor 3 points to it. It's important to understand that while "exec 3>$i" would have truncated the file's contents, "exec 3<>$i" does not. Of course, there wasn't any content to truncate, since it was created empty, but that's not the important part. The important part is that this FD is opened for read+write, allowing the temporary file to be used for storage *and* retrieval. We aren't doing any retrieval in this example, but it could be done, with specialized tools. The third line unlinks the file from the file system. However, the shell still has an open file descriptor which points to the file. Therefore, the file is still accessible through this FD. Its inode is not recycled, and any blocks containing file content are not marked for reuse. This "unlink before using" technique is traditional on Unix systems. It allows you to bypass setting up an exit handler to clean up the temporary file. Once the open file descriptor is closed, the file system will mark the inode and any blocks as ready for reuse. Even if the script is killed by SIGKILL, that cleanup will still happen. The fourth line writes some content via the open file descriptor 3. At this point, our unlinked file now has data in it. Presumably this data is super private, and we don't want anyone to be able to recover it. When the script exits, the open file descriptor will close, and the file system will mark the file's blocks as reusable, but it won't *actually* reuse them until something else comes along and claims them. But that's what shred is designed for. The fifth line calls shred(1), instructing it to destroy the content that's in the unlinked file. Since the file is unlinked, it has no name, and therefore shred can't be *given* a name. However, we have a file descriptor that points to it. So, what we *can* do is point standard output to the file (that's what >&3 does), and then tell shred to destroy the file that's pointed to by stdout. Shred will determine the size of the file, then write data to the file, rewind, write data again, etc. On a traditional hard drive, that will overwrite the original private information. On modern devices, it may not.
Re: shred bug? [was: Unidentified subject!]
On Tue 13 Feb 2024 at 07:15:48 (-0500), Greg Wooledge wrote: > On Mon, Feb 12, 2024 at 11:01:47PM -0600, David Wright wrote: > > … but not much. For me, "standard output" is /dev/fd/1, yet it seems > > unlikely that anyone is going to use >&1 in the manner of the example. > > Standard output means "whatever file descriptor 1 points to". That > could be a file, a pipe, a terminal (character device), etc. Why pick on 1? > > I might write something like: "The option ‘-’ shreds the file specified > > by the redirection ‘>’", though there could be a better name for ‘>’. > > You're assuming the program will be used from a shell. This is *usually* > going to be true, but nothing prevents you from writing a C program > which closes stdout, opens a file, ensures that it's using FD 1, > and then calls "shred -". The documentation has to support this use > case as well. /As well/ — which is why I wrote N in place of 1. The original bug report (which I hadn't seen until Thomas' post) says: "If you redirect output to a file it will work. Shredding a tty doesn't make much sense, after all." https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175#10 Now, you can't write "If you redirect output to a file it will work" in a man page—it needs recasting into something more like what I wrote above, which contains two key points: . It points out that '-' is an option, not a filename or a stand-in for one, and it doesn't use the word standard, which is totally irrelevant in the circumstances. . It demonstrates the shell syntax element required (&) in order to avoid truncating the file, rather than shred overwriting it. I think that getting the "&" into the man page would be helpful to anybody who doesn't look at the info page for the example. It might have shortened the early part of this thread as well. As for C programmers, neither FD number nor truncation is relevant. Sure, you can pick 1. But you don't have to document that for shred. And truncation is an accident that can occur because of shell's redirect syntax: there's no equivalent in programs. > > >A FILE of ‘-’ denotes standard output. The intended use of this is > > >to shred a removed temporary file. For example: > > > > > > i=$(mktemp) > > > exec 3<>"$i" > > > rm -- "$i" > > > echo "Hello, world" >&3 > > > shred - >&3 > > > exec 3>- > > > > I can see that the last line truncates the "anonymous" file, > > No, that's not what it does at all. In fact, that last line is > written incorrectly. It should say "exec 3>&-" and what that does > is close file descriptor 3, which was previously opened on line 2. > > What it actually does *as written* is create/truncate a file whose > name is "-", close the previously opened FD 3, and make FD 3 point > to the file named "-". > > unicorn:~$ exec 3>- > unicorn:~$ ls -ld -- - > -rw-r--r-- 1 greg greg 0 Feb 13 07:12 - > unicorn:~$ ls -l /dev/fd/3 > l-wx-- 1 greg greg 64 Feb 13 07:12 /dev/fd/3 -> /home/greg/- > > This is an obvious bug in the info page. I wonder how many years > this has gone unnoticed. Well spotted. That's what an experienced eye brings to a line like that, whereas I assumed it meant something beyond my experience, and searched for it. Ironic that it truncates a file, and then immediately warns against truncating a file instead of shredding it. Cheers, David.
Re: shred bug? [was: Unidentified subject!]
Hi, "info shred" says: > > > i=$(mktemp) > > > exec 3<>"$i" > > > rm -- "$i" > > > echo "Hello, world" >&3 > > > shred - >&3 > > > exec 3>- Greg Wooledge wrote: > In fact, that last line is > written incorrectly. It should say "exec 3>&-" and what that does > is close file descriptor 3, which was previously opened on line 2. > [...] > This is an obvious bug in the info page. I wonder how many years > this has gone unnoticed. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175#36 of 22 Dec 2005 states: "I'll assume that this is now adequately explained in the info page (below). If not then please reopen. // Thomas Hood [...] exec 3>-" The bug report is from 02 Aug 2002 and states that the info page contains the short and broad promise which we can still see in "man shred". So we can assume a bug age of 18 to 22 years. Have a nice day :) Thomas
Re: shred bug? [was: Unidentified subject!]
On Tue, Feb 13, 2024 at 07:36:14AM -0500, Greg Wooledge wrote: > On Tue, Feb 13, 2024 at 07:15:48AM -0500, Greg Wooledge wrote: > > This is an obvious bug in the info page. I wonder how many years > > this has gone unnoticed. > > I've filed Bug#1063837 for it. <https://bugs.debian.org/1063837> Well, thanks for doing TRT :-) Cheers -- t signature.asc Description: PGP signature
Re: shred bug? [was: Unidentified subject!]
On Tue, Feb 13, 2024 at 07:15:48AM -0500, Greg Wooledge wrote: > This is an obvious bug in the info page. I wonder how many years > this has gone unnoticed. I've filed Bug#1063837 for it. <https://bugs.debian.org/1063837>
Re: shred bug? [was: Unidentified subject!]
On Mon, Feb 12, 2024 at 11:01:47PM -0600, David Wright wrote: > … but not much. For me, "standard output" is /dev/fd/1, yet it seems > unlikely that anyone is going to use >&1 in the manner of the example. Standard output means "whatever file descriptor 1 points to". That could be a file, a pipe, a terminal (character device), etc. > I might write something like: "The option ‘-’ shreds the file specified > by the redirection ‘>’", though there could be a better name for ‘>’. You're assuming the program will be used from a shell. This is *usually* going to be true, but nothing prevents you from writing a C program which closes stdout, opens a file, ensures that it's using FD 1, and then calls "shred -". The documentation has to support this use case as well. > >A FILE of ‘-’ denotes standard output. The intended use of this is > >to shred a removed temporary file. For example: > > > > i=$(mktemp) > > exec 3<>"$i" > > rm -- "$i" > > echo "Hello, world" >&3 > > shred - >&3 > > exec 3>- > > I can see that the last line truncates the "anonymous" file, No, that's not what it does at all. In fact, that last line is written incorrectly. It should say "exec 3>&-" and what that does is close file descriptor 3, which was previously opened on line 2. What it actually does *as written* is create/truncate a file whose name is "-", close the previously opened FD 3, and make FD 3 point to the file named "-". unicorn:~$ exec 3>- unicorn:~$ ls -ld -- - -rw-r--r-- 1 greg greg 0 Feb 13 07:12 - unicorn:~$ ls -l /dev/fd/3 l-wx-- 1 greg greg 64 Feb 13 07:12 /dev/fd/3 -> /home/greg/- This is an obvious bug in the info page. I wonder how many years this has gone unnoticed.
Re: shred bug? [was: Unidentified subject!]
On Mon, Feb 12, 2024 at 10:07:45PM +0100, Thomas Schmitt wrote: > Hi, > > > https://en.wikipedia.org/wiki/Everything_is_a_file > > But, there is more than one kind of file. > > "All files are equal. > But some files are more equal than others." > > (George Orwell in his dystopic novel "Server Farm".) :-D Yesterday I was on the brink of quoting that. Great minds and all of that... Reality though is, that if you don't design your file with magical properties from the get-go, you will keep stumbling on stuff you want to model and which don't fit the real life file design you chose. And yes, Plan 9, as someone else noted in this thread, takes that to a bigger extreme: in their windowing system, windows are files, too -- you can remove a window by deleting the corresponding file. Cheers -- t signature.asc Description: PGP signature
Re: shred bug? [was: Unidentified subject!]
On Sun 11 Feb 2024 at 09:16:00 (-0600), David Wright wrote: > On Sun 11 Feb 2024 at 09:54:24 (-0500), Greg Wooledge wrote: > > On Sun, Feb 11, 2024 at 03:45:21PM +0100, to...@tuxteam.de wrote: > > > Still there's the discrepancy between doc and behaviour. > > > > There isn't. The documentation says: > > > > SYNOPSIS > >shred [OPTION]... FILE... > > > > DESCRIPTION > >Overwrite the specified FILE(s) repeatedly, in order to make it > > harder > >for even very expensive hardware probing to recover the data. > > > >If FILE is -, shred standard output. > > > > In every sentence, the word FILE appears. There's nothing in there > > which says "you can operate on a non-file". > > > > Once you grasp what the command is *intended* to do (rewind and overwrite > > a file repeatedly), it makes absolutely perfect sense that it should > > only operate on rewindable file system objects. > > > > If you want it to write a stream of data instead of performing its normal > > operation (rewinding and rewriting), that's a new feature. > > > > If you'd prefer the documentation to say explicitly "only regular files > > and block devices are allowed", that would be an upstream documentation > > *clarification* request. > > Perhaps info puts it better? … but not much. For me, "standard output" is /dev/fd/1, yet it seems unlikely that anyone is going to use >&1 in the manner of the example. I might write something like: "The option ‘-’ shreds the file specified by the redirection ‘>’", though there could be a better name for ‘>’. >A FILE of ‘-’ denotes standard output. The intended use of this is >to shred a removed temporary file. For example: > > i=$(mktemp) > exec 3<>"$i" > rm -- "$i" > echo "Hello, world" >&3 > shred - >&3 > exec 3>- I can see that the last line truncates the "anonymous" file, but where is that construction documented¹, and how would one parse the syntax elements FD > - to make them mean truncate? >However, the command ‘shred - >file’ does not shred the contents of >FILE, since the shell truncates FILE before invoking ‘shred’. Use >the command ‘shred file’ or (if using a Bourne-compatible shell) the >command ‘shred - 1<>file’ instead. ¹ the string ">-" doesn't appear in /usr/share/doc/bash/bashref.pdf, ver 5.1, for example. Cheers, David.
Re: shred bug? [was: Unidentified subject!]
On 12/02/2024 05:41, David Christensen wrote: Apparently, shred(1) has both an info(1) page (?) and a man(1) page. The obvious solution is to write one document that is complete and correct, and use it everywhere -- e.g. DRY. https://www.gnu.org/prep/standards/html_node/Man-Pages.html 6.9 Man Pages in "GNU Coding Standards" In the GNU project, man pages are secondary. It is not necessary or expected for every GNU program to have a man page, but some of them do. A standalone man page is not the same as a section in a document describing the whole bundle. Notice that man uses direct formatting, not logical markup. E.g. there is no dedicated structure for links to other man pages. They were not designed as hypertext documents, they are to be printed on paper. In this sense texinfo is a more advanced format. P.S. I admit that in some cases "man bash" may be more convenient for searching than an info browser.
Re: shred bug? [was: Unidentified subject!]
Hi, > https://en.wikipedia.org/wiki/Everything_is_a_file > But, there is more than one kind of file. "All files are equal. But some files are more equal than others." (George Orwell in his dystopic novel "Server Farm".) Have a nice day :) Thomas
Re: shred bug? [was: Unidentified subject!]
On 2/12/24 08:50, Curt wrote: On 2024-02-11, wrote: On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote: [...] If FILE is -, shred standard output. =20 In every sentence, the word FILE appears. There's nothing in there which says "you can operate on a non-file". Point taken, yes. I thought everything was a file. "Everything is a file" is a design feature of the Unix operating system: https://en.wikipedia.org/wiki/Everything_is_a_file But, there is more than one kind of file. And, not every program supports every kind of file. The manual page for find(1) provides a shopping list of file types it supports: 2024-02-12 12:32:13 dpchrist@laalaa ~ $ man find | egrep -A 20 '^ .type c' -type c File is of type c: b block (buffered) special c character (unbuffered) special d directory p named pipe (FIFO) f regular file l symbolic link; this is never true if the -L option or the -follow option is in ef- fect, unless the symbolic link is broken. If you want to search for symbolic links when -L is in effect, use -xtype. s socket As for shred(1), the argument FILE is conventionally a regular file. We are discussing the special case described in the manual page: If FILE is -, shred standard output. David
Re: shred bug? [was: Unidentified subject!]
On Mon, Feb 12, 2024 at 04:50:50PM -, Curt wrote: > On 2024-02-11, wrote: > > > > > > On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote: > > > > [...] > > > >>If FILE is -, shred standard output. > >>=20 > >> In every sentence, the word FILE appears. There's nothing in there > >> which says "you can operate on a non-file". > > > > Point taken, yes. > > I thought everything was a file. An anonymous pipe(2) in memory between two processes isn't even close to a file. Also, you're confusing Linux and Plan 9. Linux has a bunch of things that aren't files, such as network interfaces.
Re: shred bug? [was: Unidentified subject!]
On 2024-02-11, wrote: > > > On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote: > > [...] > >>If FILE is -, shred standard output. >>=20 >> In every sentence, the word FILE appears. There's nothing in there >> which says "you can operate on a non-file". > > Point taken, yes. I thought everything was a file.
Re: shred bug? [was: Unidentified subject!]
On 2/11/24 06:54, Greg Wooledge wrote: On Sun, Feb 11, 2024 at 03:45:21PM +0100, to...@tuxteam.de wrote: On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: [...] What Thomas was trying to do is to get a cheap, fast random number generator. Shred seems to have such. Well... I certainly wouldn't call it a bug. Maybe a feature request. Still there's the discrepancy between doc and behaviour. There isn't. The documentation says: SYNOPSIS shred [OPTION]... FILE... I interpret the above line to be a prototype for invoking the shred(1) program: * "shred" is the program name * "[OPTION]..." is one or more option specifiers that may be omitted. Each should be described below. * "FILE..." is one or more argument specifies that should be file system paths (strings). DESCRIPTION Overwrite the specified FILE(s) repeatedly, in order to make it harder for even very expensive hardware probing to recover the data. If FILE is -, shred standard output. I interpret the above line at face value -- if the caller provides a dash as the argument, shred(1) will operate on standard output. In every sentence, the word FILE appears. There's nothing in there which says "you can operate on a non-file". Dash is not a file, yet the above sentence says shred(1) can operate on it. Once you grasp what the command is *intended* to do (rewind and overwrite a file repeatedly), it makes absolutely perfect sense that it should only operate on rewindable file system objects. An expert may infer what you have stated, but I prefer manual pages that are explicit. The GNU project must have found a need for the FILE='-' feature, otherwise it would not exist. The manual page should describe that need (e.g. why) and how to properly use shred(1) to solve the need. If you want it to write a stream of data instead of performing its normal operation (rewinding and rewriting), that's a new feature. Humans are (in)famous for doing unexpected things. If you'd prefer the documentation to say explicitly "only regular files and block devices are allowed", that would be an upstream documentation *clarification* request. Apparently, shred(1) has both an info(1) page (?) and a man(1) page. The obvious solution is to write one document that is complete and correct, and use it everywhere -- e.g. DRY. David
Re: shred bug? [was: Unidentified subject!]
On Sun 11 Feb 2024 at 09:54:24 (-0500), Greg Wooledge wrote: > On Sun, Feb 11, 2024 at 03:45:21PM +0100, to...@tuxteam.de wrote: > > On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: > > > On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: > > > > [...] > > > > > > What Thomas was trying to do is to get a cheap, fast random number > > > > generator. Shred seems to have such. > > > > > > Well... I certainly wouldn't call it a bug. Maybe a feature request. > > > > Still there's the discrepancy between doc and behaviour. > > There isn't. The documentation says: > > SYNOPSIS >shred [OPTION]... FILE... > > DESCRIPTION >Overwrite the specified FILE(s) repeatedly, in order to make it harder >for even very expensive hardware probing to recover the data. > >If FILE is -, shred standard output. > > In every sentence, the word FILE appears. There's nothing in there > which says "you can operate on a non-file". > > Once you grasp what the command is *intended* to do (rewind and overwrite > a file repeatedly), it makes absolutely perfect sense that it should > only operate on rewindable file system objects. > > If you want it to write a stream of data instead of performing its normal > operation (rewinding and rewriting), that's a new feature. > > If you'd prefer the documentation to say explicitly "only regular files > and block devices are allowed", that would be an upstream documentation > *clarification* request. Perhaps info puts it better? A FILE of ‘-’ denotes standard output. The intended use of this is to shred a removed temporary file. For example: i=$(mktemp) exec 3<>"$i" rm -- "$i" echo "Hello, world" >&3 shred - >&3 exec 3>- However, the command ‘shred - >file’ does not shred the contents of FILE, since the shell truncates FILE before invoking ‘shred’. Use the command ‘shred file’ or (if using a Bourne-compatible shell) the command ‘shred - 1<>file’ instead. Cheers, David.
Re: shred bug? [was: Unidentified subject!]
Hi, to...@tuxteam.de wrote: > Still there's the discrepancy between doc and behaviour. Depends at which documentation you look. Obviously stemming from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175#36 i read in https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html "A file of ‘-’ denotes standard output. The intended use of this is to shred a removed temporary file. For example: [shell wizzardry]" It works as long as stdout is connected to a data file, or block device, or directory, or symbolic link, or to a character device that is not a terminal. (Maybe it refuses later on some of these types, but not at the location with the message "invalid file type". I wonder if i can connect stdout to a symbolic link instead of its target.) The bug would thus have to be filed against the man page https://sources.debian.org/src/coreutils/9.4-3/man/shred.1/ which says only "If FILE is \-, shred standard output." The info empire of coreutils says what above web manual says. https://sources.debian.org/src/coreutils/9.4-3/doc/coreutils.texi/#L10705 Have a nice day :) Thomas
Re: shred bug? [was: Unidentified subject!]
On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote: [...] >If FILE is -, shred standard output. > > In every sentence, the word FILE appears. There's nothing in there > which says "you can operate on a non-file". Point taken, yes. Cheers -- t signature.asc Description: PGP signature
Re: shred bug? [was: Unidentified subject!]
On Sun, Feb 11, 2024 at 03:45:21PM +0100, to...@tuxteam.de wrote: > On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: > > On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: > > [...] > > > > What Thomas was trying to do is to get a cheap, fast random number > > > generator. Shred seems to have such. > > > > Well... I certainly wouldn't call it a bug. Maybe a feature request. > > Still there's the discrepancy between doc and behaviour. There isn't. The documentation says: SYNOPSIS shred [OPTION]... FILE... DESCRIPTION Overwrite the specified FILE(s) repeatedly, in order to make it harder for even very expensive hardware probing to recover the data. If FILE is -, shred standard output. In every sentence, the word FILE appears. There's nothing in there which says "you can operate on a non-file". Once you grasp what the command is *intended* to do (rewind and overwrite a file repeatedly), it makes absolutely perfect sense that it should only operate on rewindable file system objects. If you want it to write a stream of data instead of performing its normal operation (rewinding and rewriting), that's a new feature. If you'd prefer the documentation to say explicitly "only regular files and block devices are allowed", that would be an upstream documentation *clarification* request.
Re: shred bug? [was: Unidentified subject!]
On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: > On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: [...] > > What Thomas was trying to do is to get a cheap, fast random number > > generator. Shred seems to have such. > > Well... I certainly wouldn't call it a bug. Maybe a feature request. Still there's the discrepancy between doc and behaviour. Cheers -- t signature.asc Description: PGP signature
Re: shred bug? [was: Unidentified subject!]
On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote: > On Sat, Feb 10, 2024 at 07:10:54PM -0500, Greg Wooledge wrote: > > On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: > > > 2024-02-10 16:03:50 dpchrist@laalaa ~ > > > $ shred -s 1K - | wc -c > > > shred: -: invalid file type > > > 0 > > > > > > > > > It looks like a shred(1) needs a bug report. > > > > I'm confused what you expected this command to do. You wanted to > > "destroy" (by overwriting with random data) a pipe to wc? What > > would that even look like? > > What Thomas was trying to do is to get a cheap, fast random number > generator. Shred seems to have such. Well... I certainly wouldn't call it a bug. Maybe a feature request.
Re: shred bug?
Hi, debian-u...@howorth.org.uk wrote: > Maybe it is unstated but mandatory to use -n 1 as well? > And optionally -s N? Naw. It just doesn't want to work pipes. Initially i tried with these options: shred -n 1 -s 1K -v - | sha256sum as preparation for a proposal to Gene Heskett, like: shred -n 1 -s 204768K -v - | tee /dev/sdm1 | sha256sum > I expect reading the code would tell. My code analysis is in https://lists.debian.org/msgid-search/1162291656137153...@scdbackup.webframe.org to...@tuxteam.de found bug 155175 from 2002, which explains why. See https://lists.debian.org/msgid-search/zcdxzya0ayrmp...@tuxteam.de Have a nice day :) Thomas
Re: shred bug? [was: Unidentified subject!]
David Christensen wrote: > On 2/10/24 16:10, Greg Wooledge wrote: > > On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: > >> 2024-02-10 16:03:50 dpchrist@laalaa ~ > >> $ shred -s 1K - | wc -c > >> shred: -: invalid file type > >> 0 > >> > >> > >> It looks like a shred(1) needs a bug report. > > > > I'm confused what you expected this command to do. You wanted to > > "destroy" (by overwriting with random data) a pipe to wc? What > > would that even look like? > > > > The basic premise of shred is that it determines the size of the > > file, then writes data over it, rewinds it, and repeats this a few > > times. A pipe to a process has no size, and can't be rewound. > > > > Declaring a pipe to be an "invalid file type" for shredding sounds > > pretty reasonable to me. > > > The documentation is confusing: > > On 2/10/24 16:05, David Christensen wrote: > > 2024-02-10 16:03:42 dpchrist@laalaa ~ > > $ man shred | grep 'If FILE is -' > > If FILE is -, shred standard output. Maybe it is unstated but mandatory to use -n 1 as well? And optionally -s N? I expect reading the code would tell. First time I've read the man page properly. Interesting point about COW filesystems such as btrfs :)
Re: shred bug? [was: Unidentified subject!]
On Sat, Feb 10, 2024 at 07:10:54PM -0500, Greg Wooledge wrote: > On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: > > 2024-02-10 16:03:50 dpchrist@laalaa ~ > > $ shred -s 1K - | wc -c > > shred: -: invalid file type > > 0 > > > > > > It looks like a shred(1) needs a bug report. > > I'm confused what you expected this command to do. You wanted to > "destroy" (by overwriting with random data) a pipe to wc? What > would that even look like? What Thomas was trying to do is to get a cheap, fast random number generator. Shred seems to have such. > The basic premise of shred is that it determines the size of the file, > then writes data over it, rewinds it, and repeats this a few times. > A pipe to a process has no size, and can't be rewound. That's right: stdout is a (potentially) infinite file, so only one pass (-n 1, as Thomas put in the command line) really makes sense. Unless you are into transfinite numbers, that is :-) > Declaring a pipe to be an "invalid file type" for shredding sounds > pretty reasonable to me. This is one of those cases of the toolmaker knowing better than the tool user. One of the things I like UNIX is that this attitude isn't that widespread (it is slowly spreading, alas). I much prefer those tool makers who say "surprise me". Of course, helping people to not shoot themselves in the foot is also a honourable endeavour. So "you are trying to shred a pipe. Use option -f for that (see the manual page" would be fully OK in my book. I don't like opinionated software. It's messy enough as it is when people have opinions :-) Cheers -- t signature.asc Description: PGP signature
Re: Debian weather bug
> > I have a bug report but am not sure which package it should be filed > > against. The Weather Report application, version 1.24.1, is affected, > > as is the weather reported by the Clock application, version 1.24.1, in > > the MATE desktop environment. Neither reports the correct weather, and > > the log files contain the error "Failed to get METAR data." I suspect > > the issue is related to a URL change described in these two threads: > > > > > > https://www.reddit.com/r/flying/comments/179zm7o/for_those_of_you_who_made_metar_live/ > >https://www.reddit.com/r/flying/comments/179bmcj/metar_map_issues/ > > > > How should this be reported? > > > > Update: the following are relevant lines from /var/log/syslog: > >Oct 19 18:10:09 debian mateweather-app[3922]: Failed to get METAR data: > 404 Not Found. >Oct 19 18:10:09 debian mateweather-app[3922]: Failed to get IWIN forecast > data: 404 Not Found >Oct 19 18:10:09 debian mateweather-app[3922]: Source ID 50501 was not > found when attempting to remove it >Oct 19 18:14:54 debian mateweather-app[3922]: Failed to get METAR data: > 404 Not Found. >Oct 19 18:14:54 debian mateweather-app[3922]: Source ID 50562 was not > found when attempting to remove it >Oct 19 18:23:55 debian clock-applet[3927]: Failed to get METAR data: 404 > Not Found. > > Note that two different applications are affected by this bug. The latest upgrade of the packages libmateweather-common and libmateweather1 (both to version 1.24.1-1+deb11u1) has fixed the problem; the two weather applications are now functioning properly. Best regards, Greg Marks signature.asc Description: PGP signature
Re: shred bug? [was: Unidentified subject!]
On 2/10/24 16:10, Greg Wooledge wrote: On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: 2024-02-10 16:03:50 dpchrist@laalaa ~ $ shred -s 1K - | wc -c shred: -: invalid file type 0 It looks like a shred(1) needs a bug report. I'm confused what you expected this command to do. You wanted to "destroy" (by overwriting with random data) a pipe to wc? What would that even look like? The basic premise of shred is that it determines the size of the file, then writes data over it, rewinds it, and repeats this a few times. A pipe to a process has no size, and can't be rewound. Declaring a pipe to be an "invalid file type" for shredding sounds pretty reasonable to me. The documentation is confusing: On 2/10/24 16:05, David Christensen wrote: > 2024-02-10 16:03:42 dpchrist@laalaa ~ > $ man shred | grep 'If FILE is -' > If FILE is -, shred standard output. David
Re: shred bug? [was: Unidentified subject!]
On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote: > 2024-02-10 16:03:50 dpchrist@laalaa ~ > $ shred -s 1K - | wc -c > shred: -: invalid file type > 0 > > > It looks like a shred(1) needs a bug report. I'm confused what you expected this command to do. You wanted to "destroy" (by overwriting with random data) a pipe to wc? What would that even look like? The basic premise of shred is that it determines the size of the file, then writes data over it, rewinds it, and repeats this a few times. A pipe to a process has no size, and can't be rewound. Declaring a pipe to be an "invalid file type" for shredding sounds pretty reasonable to me.
Re: shred bug? [was: Unidentified subject!]
On 2/10/24 04:40, to...@tuxteam.de wrote: On Sat, Feb 10, 2024 at 11:38:21AM +0100, Thomas Schmitt wrote: [...] But shred(1) on Debian 11 refuses on "-" contrary to its documentation: shred: -: invalid file type A non-existing file path causes "No such file or directory". Hmm. This looks like a genuine bug: the man page mentions it. Also, /dev/stdout as target runs into the very same problem. Cheers Testing: 2024-02-10 16:01:54 dpchrist@laalaa ~ $ cat /etc/debian_version ; uname -a 11.8 Linux laalaa 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux 2024-02-10 16:02:34 dpchrist@laalaa ~ $ bash --version | head -n 1 GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu) 2024-02-10 16:02:48 dpchrist@laalaa ~ $ shred --version | head -n 1 shred (GNU coreutils) 8.32 2024-02-10 16:03:42 dpchrist@laalaa ~ $ man shred | grep 'If FILE is -' If FILE is -, shred standard output. 2024-02-10 16:03:50 dpchrist@laalaa ~ $ shred -s 1K - | wc -c shred: -: invalid file type 0 It looks like a shred(1) needs a bug report. David
Re: shred bug?
On Sat, Feb 10, 2024 at 02:58:06PM +0100, Thomas Schmitt wrote: > Hi, > > to...@tuxteam.de wrote: > > Ah, it seems to be this one, from 2002: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175 > > So it's not a bug but a feature. :( > > I'm riddling over the code about the connection to an old graphics > algorithm (Bresenham's Algorithm) and how shred produces a random pattern > at all. This [1] perhaps? It's not a good random generator (and not crypto, by a long stretch) but it's pretty well equidistributed, ain't it? Cheers [1] https://en.wikipedia.org/wiki/Lehmer_random_number_generator -- t signature.asc Description: PGP signature
Re: shred bug?
Hi, to...@tuxteam.de wrote: > Ah, it seems to be this one, from 2002: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175 So it's not a bug but a feature. :( I'm riddling over the code about the connection to an old graphics algorithm (Bresenham's Algorithm) and how shred produces a random pattern at all. Have a nice day :) Thomas
Re: shred bug?
On 2/10/24 08:32, Thomas Schmitt wrote: Hi, i wrote: shred: -: invalid file type to...@tuxteam.de wrote: Hmm. This looks like a genuine bug: the man page mentions it. Even the help text in https://sources.debian.org/src/coreutils/9.4-3/src/shred.c/ says If FILE is -, shred standard output. The name "-" is recognized in line 1257 and leads to a call of wipefd() in line 958. The error messages there look different from above. So i hop from line 973 to do_wipefd() and find the message in line 845. fd is supposed to be 1 (= stdout). fstat(2) was successful but now this condition snaps: if ((S_ISCHR (st.st_mode) && isatty (fd)) || S_ISFIFO (st.st_mode) || S_ISSOCK (st.st_mode)) The problem seems to be in the S_ISFIFO part. In a little test program fstat() reports about fd==1: st.st_mode= 010600 , S_ISFIFO(st.st_mode)= 1 (st_mode shown in octal as in man 2 fstat.) It looks like the test expects a pipe(2) file descriptor to be classified as S_ISCHR and !isatty(). Without redirection through a pipe, fd 1 has st.st_mode 20620, S_ISCHR, and isatty()==1. The isatty() result is indeed a good reason, not to flood stdout by a zillion random bytes. Does anybody have an old GNU/Linux system where a file descriptor from pipe(2) is classified as character device (S_IFCHR, S_ISCHR) ? What about dash?
Re: shred bug?
Hi, i wrote: > > shred: -: invalid file type to...@tuxteam.de wrote: > Hmm. This looks like a genuine bug: the man page mentions it. Even the help text in https://sources.debian.org/src/coreutils/9.4-3/src/shred.c/ says If FILE is -, shred standard output. The name "-" is recognized in line 1257 and leads to a call of wipefd() in line 958. The error messages there look different from above. So i hop from line 973 to do_wipefd() and find the message in line 845. fd is supposed to be 1 (= stdout). fstat(2) was successful but now this condition snaps: if ((S_ISCHR (st.st_mode) && isatty (fd)) || S_ISFIFO (st.st_mode) || S_ISSOCK (st.st_mode)) The problem seems to be in the S_ISFIFO part. In a little test program fstat() reports about fd==1: st.st_mode= 010600 , S_ISFIFO(st.st_mode)= 1 (st_mode shown in octal as in man 2 fstat.) It looks like the test expects a pipe(2) file descriptor to be classified as S_ISCHR and !isatty(). Without redirection through a pipe, fd 1 has st.st_mode 20620, S_ISCHR, and isatty()==1. The isatty() result is indeed a good reason, not to flood stdout by a zillion random bytes. Does anybody have an old GNU/Linux system where a file descriptor from pipe(2) is classified as character device (S_IFCHR, S_ISCHR) ? Does anybody have an idea why shred would want to exclude fifos ? (What ciould shred do with a non-tty character device that cannot be done with a fifo ?) Have a nice day :) Thomas
Re: shred bug? [was: Unidentified subject!]
On Sat, Feb 10, 2024 at 01:40:35PM +0100, to...@tuxteam.de wrote: > On Sat, Feb 10, 2024 at 11:38:21AM +0100, Thomas Schmitt wrote: > > [...] > > > But shred(1) on Debian 11 refuses on "-" contrary to its documentation: > > shred: -: invalid file type > > A non-existing file path causes "No such file or directory". > > Hmm. This looks like a genuine bug: the man page mentions it. > > Also, /dev/stdout as target runs into the very same problem. Ah, it seems to be this one, from 2002: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175 which is archived. The argument seems to be that shred on stdout doesn't make any sense, because the shell would truncate the file anyway when you did shred - > /this/file/to/be/shredded ... which, of course, undermines shred's purpose. It seems they hadn't your sneaky use case in mind :-) Cheers -- t signature.asc Description: PGP signature
shred bug? [was: Unidentified subject!]
On Sat, Feb 10, 2024 at 11:38:21AM +0100, Thomas Schmitt wrote: [...] > But shred(1) on Debian 11 refuses on "-" contrary to its documentation: > shred: -: invalid file type > A non-existing file path causes "No such file or directory". Hmm. This looks like a genuine bug: the man page mentions it. Also, /dev/stdout as target runs into the very same problem. Cheers -- t signature.asc Description: PGP signature
Re: NUC freeazing due to kernel bug
Tim Janssen wrote: > I use debian server on my NUC to run a low powered home server. It freezes > every 2-3 days what looks to be a kernel bug. From a lot of testing it only > occurs when the ethernet cable is inserted and it seems it has to do > something with low power mode (c-states). These issues have been reported > ever since kernel 5.10. I wonder if the debian devs are aware of this issue > and if a fix is undereway. Things that you really ought to tell us: - CPU? - model or motherboard identifier? - have you tried disabling low C states in BIOS? - you say it's been reported across major kernel releases -- what bug numbers? - are there any log entries written before it freezes? - can you avoid it by not unplugging/replugging the ethernet cable? - what ethernet NIC is in use? - have you run htop or another means to disable power saving on the NIC? ...and probably a dozen other things, but start there. -dsr-
NUC freeazing due to kernel bug
Dear Sir/Madam, I use debian server on my NUC to run a low powered home server. It freezes every 2-3 days what looks to be a kernel bug. From a lot of testing it only occurs when the ethernet cable is inserted and it seems it has to do something with low power mode (c-states). These issues have been reported ever since kernel 5.10. I wonder if the debian devs are aware of this issue and if a fix is undereway. Best regards, Tim Janssen
Re: Bug: Tab completion for pdf files with blanks in path
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
