Re: shred bug? [was: Unidentified subject!]

[tomas]

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: usrmerge on root NFS will not be run automatically

[fabjunkm...@gmail.com]

Very unimpressed with the so called "fix" for #842145 of just blocking
running the script on nfs mount rather than fixing the script to work
properly with nfs.

The problem with the script is that it does not ignore the .nfs*
files. An explanation of these files is available here:

https://unix.stackexchange.com/questions/348315/nfs-mount-device-or-resource-busy

I am not a programmer so will not share my crappy attempt at getting
the script to work. I will describe a workaround I did and maybe that
may help someone come up with their own workaround for system with nfs
root (where the nfs server is not running linux). Or even better maybe
the package maintainer might adjust the script within usrmerge to work
properly with nfs using these ideas.

- Starting from bullseye (I rolled back to a snapshot pre-install of
usrmerge), downloaded src of usrmerge to get access to the
convert-usrmerge script.

- modify script to try and get it to ignore/avoid changing any objects
with ".nfs000" in its name

- run the script so it hopefully completes successfully (In my case it
did not fully complete. It made most of the changes but I still had
some directories in root such as /lib - probably from mistakes in my
code changes)

- rebooted nfs client to clear open file handles on nfs which would
remove .nfs000* files

- ran the original unmodified script which this time completed
successfully including converting eg /lib to a symlink. I think this
worked as most of the files had moved and symlinks created so there
was not much left for it to do except sort out the remaining few
moves/symlinks.

- installed usrmerge package which this time completed (it detected
the merge completed and did not complain about nfs)

>From there I expect it should be safe to upgrade to bookworm without
usrmerge breaking the upgrade (not tested yet).

good luck

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Tue, Feb 13, 2024 at 09:47:52PM -0500, Gremlin wrote:
> This is from a script installed by a package that does a
> dpkg-reconfigure locales to set the locale on the machine.

What package?  What script?

> BTW where is LANGUAGE defined in the "standards/conventions"?

It's a GNUism.

https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html

Re: Does "LC_ALL=C" work on all shells?

[Gremlin]

On 2/13/24 21:22, Max Nikulin wrote:

On 14/02/2024 07:56, Gremlin wrote:

Gremlin (12024-02-13):


cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8


Found this in a shell script:

LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC 
LC_ALL=$LOC LANGUAGE=$LOC


Do not do it for LANGUAGE, it should obey another conventions

     LANGUAGE=en_US:en

Its value is a list of languages, not a locale. This variable may affect 
messages generated by some applications, especially GUI ones, even when 
LC_ALL is set.







I get your point but I didn't do it, git blame others.

This is from a script installed by a package that does a
dpkg-reconfigure locales to set the locale on the machine.

BTW where is LANGUAGE defined in the "standards/conventions"?

Re: Does "LC_ALL=C" work on all shells?

[Max Nikulin]

On 14/02/2024 07:56, Gremlin wrote:

Gremlin (12024-02-13):


cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8


Found this in a shell script:

LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC 
LANGUAGE=$LOC


Do not do it for LANGUAGE, it should obey another conventions

LANGUAGE=en_US:en

Its value is a list of languages, not a locale. This variable may affect 
messages generated by some applications, especially GUI ones, even when 
LC_ALL is set.

Re: grub-pc error when upgrading from buster to bullseye

[John Boxall]

On 2024-02-12 15:14, Greg Wooledge wrote:


According to

it uses debconf's database.  That page includes instructions for viewing
the device and changing it.



I had just started looking into the grub-pc package before I saw this. 
I'll be able to test this out sometime tomorrow.



I can't verify this on my machine, because mine uses UEFI.



Will advise. Thank you Greg!

--
Regards,

John Boxall

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Tue, Feb 13, 2024 at 07:56:46PM -0500, Gremlin wrote:
> Found this in a shell script:
> 
> LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC
> LANGUAGE=$LOC

In *what* shell script?

Re: Does "LC_ALL=C" work on all shells?

[Gremlin]

On 2/13/24 19:29, Gremlin wrote:

On 2/13/24 17:48, Nicolas George wrote:

Gremlin (12024-02-13):

Oh like debian does?

cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8


I do not observe this, even after “sudo dpkg-reconfigure locales”. Can
you explain how you reached this state?


I will try:

Upon investigation, I can not determine which package
/etc/default/locale belongs too.

dpkg -S /etc/default/locale
dpkg-query: no path found matching pattern /etc/default/locale

dpkg-query -S /etc/default/locale
dpkg-query: no path found matching pattern /etc/default/locale


apt-file search /etc/default/locale

returns nothing

apt-file search locale|grep '/etc/default'

nothing

cruft-ng doesn't find it

This is going no where fast.




Found this in a shell script:

LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC 
LANGUAGE=$LOC

Re: Does "LC_ALL=C" work on all shells?

[Andy Smith]

Hi,

On Tue, Feb 13, 2024 at 07:29:37PM -0500, Gremlin wrote:
> Upon investigation, I can not determine which package
> /etc/default/locale belongs too.

dpkg -S and apt-file will only find files that are actually shipped
in packages. Files that are created or used by maintainer scripts
but not actually shipped by a package will not be found by these
commands.

You can look in all the maintainer scripts to see where it's
mentioned:

$ grep -r /etc/default/locale /var/lib/dpkg/info

which leads me to believe it may be most relevant to the "locales"
package, but this does not enlighten us to how any particular entry
may have been added to that file.

I guess at some point something called update-locale with LC_ALL=C
or something.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Does "LC_ALL=C" work on all shells?

[Gremlin]

On 2/13/24 17:48, Nicolas George wrote:

Gremlin (12024-02-13):

Oh like debian does?

cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8


I do not observe this, even after “sudo dpkg-reconfigure locales”. Can
you explain how you reached this state?


I will try:

Upon investigation, I can not determine which package
/etc/default/locale belongs too.

dpkg -S /etc/default/locale
dpkg-query: no path found matching pattern /etc/default/locale

dpkg-query -S /etc/default/locale
dpkg-query: no path found matching pattern /etc/default/locale


apt-file search /etc/default/locale

returns nothing

apt-file search locale|grep '/etc/default'

nothing

cruft-ng doesn't find it

This is going no where fast.

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Tue, Feb 13, 2024 at 11:48:04PM +0100, Nicolas George wrote:
> Gremlin (12024-02-13):
> > Oh like debian does?
> > 
> > cat /etc/default/locale
> > #  File generated by update-locale
> > LANG=en_US.UTF-8
> > LANGUAGE=en_US.UTF-8
> > LC_ALL=en_US.UTF-8
> 
> I do not observe this, even after “sudo dpkg-reconfigure locales”. Can
> you explain how you reached this state?

Indeed.  That is NOT normal.

unicorn:~$ cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8

Re: Does "LC_ALL=C" work on all shells?

[Nicolas George]

Gremlin (12024-02-13):
> Oh like debian does?
> 
> cat /etc/default/locale
> #  File generated by update-locale
> LANG=en_US.UTF-8
> LANGUAGE=en_US.UTF-8
> LC_ALL=en_US.UTF-8

I do not observe this, even after “sudo dpkg-reconfigure locales”. Can
you explain how you reached this state?

-- 
  Nicolas George

Re: Does "LC_ALL=C" work on all shells?

[Gremlin]

On 2/13/24 16:45, Greg Wooledge wrote:

On Tue, Feb 13, 2024 at 01:21:20PM -0800, John Conover wrote:

 egrep ALL .bashrc
 LC_ALL=C


This has gone pretty far off the rails, but here we are.  Let's address
this.

DO NOT set LC_ALL in your .bashrc or equivalent files.  This is a horrible
idea.  LC_ALL should only be used in single commands as a full-powered
override, for example when you want to report a bug, and need the output
to be normalized to the "C" locale.


Oh like debian does?

cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8

locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

Re: Debian Mobile cont'd from about 10 yeaes ago furey2310....

[Jeffrey Walton]

On Tue, Feb 13, 2024 at 4:27 PM Patrick Furey  wrote:
>
> Can it be downloaded to usb, SD  and installed  at boot options via ADB?
>
> I did successfully install the code via termux on 2 phones but that termux 
> wasnt rooted i believe and my charging was subsequently ruined on my android 
> o/s
>
> The code is there on termux (terminal)

Also see .

Nowadays, I think folks install LineageOS or another Android related
fork. See .

Jeff

Re: Does "LC_ALL=C" work on all shells?

[Nicolas George]

Will Mengarini (12024-02-13):
> * Greg Wooledge  [24-02/13=Tu 15:59 -0500]:
> > In csh, you need to use env.  Like this:


> What Greg posted also works, because it's an
> invocation of the 'env' command, not csh syntax.

Yes. What made Greg's statement false was not the fact that it does not
work but the verb “need”.

> What you posted also works, but it runs the command in a subshell of
> csh, so I doubt it gains efficiency over running the command under env.

env is also executed in a subshell, but unlike what I posted, env will
also require an exec() and probably some dynamic linking.

-- 
  Nicolas George

Re: Does "LC_ALL=C" work on all shells?

[Will Mengarini]

> On Tue, Feb 13, 2024 at 09:47:38PM +0100, Franco Martelli wrote:
>> ~# LC_ALL=C apt install
>> [... works on ...] all shells other than bash? csh, korn, dash, zsh ...

* Greg Wooledge  [24-02/13=Tu 15:59 -0500]:
> [...] all the Bourne family shells [...]
>
> In csh, you need to use env.  Like this:
>
> % env LC_ALL=C apt install
>
> This works in all shells, at the cost of being slightly less efficient.

* Nicolas George  [24-02/13=Tu 22:04 +0100]:
> No, ( setenv var something ; command ) works with csh.

What Greg posted also works, because it's an
invocation of the 'env' command, not csh syntax.

What you posted also works, but it runs the command in a subshell of
csh, so I doubt it gains efficiency over running the command under env.

Re: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Tue, Feb 13, 2024 at 01:21:20PM -0800, John Conover wrote:
> egrep ALL .bashrc
> LC_ALL=C

This has gone pretty far off the rails, but here we are.  Let's address
this.

DO NOT set LC_ALL in your .bashrc or equivalent files.  This is a horrible
idea.  LC_ALL should only be used in single commands as a full-powered
override, for example when you want to report a bug, and need the output
to be normalized to the "C" locale.

In your everyday operations, you should use the LANG variable for the
locale that most closely matches your needs, and individual LC_*
variables (such as LC_TIME) for specific overrides.  Setting it up this
way allows you to override with LC_ALL when needed, *and* it allows you
to fine-tune your preferences.

For example, let's say you wanted the C locale for most things, but
the en_US.utf8 locale for one particular setting (let's say LC_TIME).
You can do this with:

LANG=C LC_TIME=en_US.utf8

but if you try it this way:

LC_ALL=C LC_TIME=en_US.utf8

then it won't work, because LC_ALL overrides everything.  Your LC_TIME
setting will have no effect.

Of course, *none* of this is relevant to the original question, which
was about the shell syntax for overriding environment variables on a
single command.

Re: shred bug? [was: Unidentified subject!]

[gene heskett]

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: Does "LC_ALL=C" work on all shells?

[Nicolas George]

John Conover (12024-02-13):
> > variable LC_ALL to "C" inline of the command e.g.:
   ^
> egrep ALL .bashrc
> LC_ALL=C
> 
> set | egrep ALL
> LC_ALL=C
> 
> dash
> set | egrep ALL

You missed part of the question, what you are showing is not “inline of
the command”.

-- 
  Nicolas George

Re: Does "LC_ALL=C" work on all shells?

[John Conover]

Franco Martelli writes:
> 
> If I want English output of an application I set the environment 
> variable LC_ALL to "C" inline of the command e.g.:
>
.
.
.
> 
> So the question is: does anybody know if this syntax works on all shells 
> other than bash? csh, korn, dash, zsh …
> 

Hi Franco.

egrep ALL .bashrc
LC_ALL=C

set | egrep ALL
LC_ALL=C

dash
set | egrep ALL

So, apparently not, (I don't have it set in /etc/profile, which is
read when dash is invoked; initializing in ~/.profile would work,
too. Probably the same in csh, korn, zsh ...)

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: Does "LC_ALL=C" work on all shells?

[Nicolas George]

Greg Wooledge (12024-02-13):
> This syntax works in all the Bourne family shells, which is all of the
> above *except* csh.
> 
> In csh, you need to use env.

No, ( setenv var something ; command ) works with csh.

> % env LC_ALL=C apt install
> 
> This works in all shells, at the cost of being slightly less efficient.

And even without a shell.

Regards,

-- 
  Nicolas George

Re: shred bug? [was: Unidentified subject!]

[David Christensen]

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!]

[David Christensen]

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: Does "LC_ALL=C" work on all shells?

[Greg Wooledge]

On Tue, Feb 13, 2024 at 09:47:38PM +0100, Franco Martelli wrote:
> ~# LC_ALL=C apt install

> So the question is: does anybody know if this syntax works on all shells
> other than bash? csh, korn, dash, zsh …

This syntax works in all the Bourne family shells, which is all of the
above *except* csh.

In csh, you need to use env.  Like this:

% env LC_ALL=C apt install

This works in all shells, at the cost of being slightly less efficient.

Re: Does "LC_ALL=C" work on all shells?

[Nicolas George]

Franco Martelli (12024-02-13):
> This is useful when it's needed to submit a bug report or to speak with
> other people in one international mailing list like this :) (apropos sorry
> for my English).

Your English does not look bad. And therefore you would probably be
better making this the default. Translations of software are often
mediocre or worse. (I remember when the French translation of df broke
the alignment of columns.) Use the software in its original version and
you will not have to guess if you misunderstood or if the translator
did.

> So the question is: does anybody know if this syntax works on all shells
> other than bash? csh, korn, dash, zsh …

apt-get install csh
csh
LC_CTYPE=C ls /doesnotexist
^D
apt-get purge csh

Repeat with other shells. And then tell us what you found out.

Regards,

-- 
  Nicolas George

Does "LC_ALL=C" work on all shells?

[Franco Martelli]

Hi,

If I want English output of an application I set the environment 
variable LC_ALL to "C" inline of the command e.g.:


~# LC_ALL=C apt install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

If I don't set the variable the apt command return output localized:

~# apt install
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

This is useful when it's needed to submit a bug report or to speak with 
other people in one international mailing list like this :) (apropos 
sorry for my English).


So the question is: does anybody know if this syntax works on all shells 
other than bash? csh, korn, dash, zsh …


Thanks in advance, kind regards
--
Franco Martelli

Re: shred bug? [was: Unidentified subject!]

[gene heskett]

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!]

[Thomas Schmitt]

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!]

[Thomas Schmitt]

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!]

[gene heskett]

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!]

[Greg Wooledge]

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: Erreur nvidia suite upgrade noyau 6.1.0-18

[ajh-valmer]

On Tuesday 13 February 2024 18:34:04 Bernard S. wrote:
> Hallo Wache,
> Es tut mir leid, maintenant, il suffit de supprimer les noyaux anciens 
> à la main pour que tout rentre dans l'ordre...

Encore une fois, c'est qui "Wache" et pourquoi ce début en prose germanique ?
Comme bien exprimé ci-dessous, je n'ai aucun noyau  6.1.0-18 dans mon /boot/
(Merci de m'aider, mais ça fait 2 fois que tu ne lis pas complètement mes 
requêtes. En général je fais attention d'être précis sur la ML afin d'éviter 
trop de mails).
Sans doute en purgeant les headers 6.1.0-18 ?

> De: "ajh-valmer" 
> Envoyé: Mardi 13 Février 2024 18:22:49
> Objet: Re: Erreur nvidia suite upgrade noyau 6.1.0-18
> Je vais arrêter de vous embêter avec mes déboires,
> sauf qu'il peut servir l'expérience des membres de cette ML.
> Maintenant, je ne peux plus upgrader vers le noyau  6.1.0-18,
> alors que mon système n'est qu'en noyau 6.1.0-17 (répertoire /boot/).
> # apt update ,  apt upgrade ,  apt dist-upgrade , apt full-upgrade 
> avec purge de nvidia,
> n'émet aucun message d'erreur, comme si l'upgrade avait atteint son
> maximum du moment.
> Lu sur des forums anglais, allemand..., je ne suis pas le seul à avoir 
> ce problème sans trouver un "resolved" (une solution).

Debian Mobile cont'd from about 10 yeaes ago furey2310....

[Patrick Furey]

Can it be downloaded to usb, SD  and installed  at boot options via ADB?
I did successfully install the code via termux on 2 phones but that termux 
wasnt rooted i believe and my charging was subsequently ruined on my android 
o/s
The code is there on termux (terminal)
Regards
Patrick Shaun Furey.

Sent from Yahoo Mail on Android

Re: Erreur nvidia suite upgrade noyau 6.1.0-18

[zithro]

On 13 Feb 2024 18:22, ajh-valmer wrote:

Errors were encountered while processing:
  linux-image-6.1.0-18-amd64
  linux-image-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)


Sans logs, c'est "ma voiture a un bruit, c'est quoi ?" ;)

Télécharge manuellement le nouveau kernel et installe-le en mode debug :
(DL en user, install en root)

$ apt-get download linux-image-6.1.0-18-amd64
# dpkg -D13 -i linux-image-6.1.0-18-amd64.deb

Augmenter "D" augmente les détails.
Voir "man dpkg" ou "dpkg --debug=help" pour les chiffres utiles.

Quelques autres pistes:
- dkms
- apt pinning
- vérifier l'état des paquets (dpkg --audit, etc).
(- espace disque dans /boot ou /lib)


--
++
zithro / Cyril

Re: shred bug? [was: Unidentified subject!]

[Thomas Schmitt]

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: Re: Problemas con el controlador no libre de NVidia en la 12.5

[JA CM]

Buenas noches
En el hilo relacionado con los problemas de un usb-c mostraba los log de
apt y mostraba, entre otras cosas, lo siguiente:
___
Start-Date: 2024-02-11  17:52:08
Commandline: apt upgrade
Requested-By: joe (1000)
Error: Sub-process /usr/bin/dpkg returned an error code (1)
End-Date: 2024-02-11  17:53:06

Esto se produce en mi equipo al intentar cargar del
linux-headers-6.1.0-17-amd64:amd64 6.1.76-1 al
linux-headers-6.1.0-18-amd64:amd64 6.1.76-1 y, te envía a los logs de
instalación del driver oficial (nonfree). Es decir no se llega a completar
la instalación, el mismo sistema detiene la actualización.

Algo que me está haciendo replantearme instalar Nouveau

Re: debian-cd baking process

[Steve McIntyre]

On Tue, Feb 13, 2024 at 06:12:47PM +0100, Kevin Price wrote:
>Dear Steve:
>
>Am 18.01.24 um 00:37 schrieb Steve McIntyre:
>> Kevin Price wrote:
>>> I'm not quite sure where to address this to,
>
>> Argh, that's my code in the debian-cd package. "reportbug debian-cd"
>> should do the right thing...
>
>Thank you for your help, I should have known. So I've now filed
>https://bugs.debian.org/1063858 . Please accept my apology for being
>slow in doing that.

No worries, thanks for prodding. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
'There is some grim amusement in watching Pence try to run the typical
 "politician in the middle of a natural disaster" playbook, however
 incompetently, while Trump scribbles all over it in crayon and eats some
 of the pages.'   -- Russ Allbery

Re: shred bug? [was: Unidentified subject!]

[debian-user]

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: Fast Random Data Generation (Was: Re: Unidentified subject!)

[Linux-Fan]

David Christensen writes:


On 2/12/24 08:30, Linux-Fan wrote:

David Christensen writes:


On 2/11/24 02:26, Linux-Fan wrote:

I wrote a program to automatically generate random bytes in multiple threads:
https://masysma.net/32/big4.xhtml


What algorithm did you implement?


I copied the algorithm from here:
https://www.javamex.com/tutorials/random_numbers/numerical_recipes.shtml


That Java code uses locks, which implies it uses global state and cannot be  
run multi-threaded (?).  (E.g. one process with one JVM.)


Indeed, the example code uses locks which is bad from a performance point of  
view. That is why _my_ implementation works without this fine-grained  
locking and instead ensures that each thread uses its own instance as to  
avoid the lock. IOW: I copied the algorithm but of course adjusted the code  
to my use case.


My version basically runs as follows:

* Create one queue of ByteBuffers
* Create multiple threads
   * Each thread runs their own RNG instance
   * Upon finishing the creation of a buffer, it enqueues
 the resulting ByteBuffer into the queue (this is the only
 part where multiple threads access concurrently)
* The main thread dequeues from the queue and writes the
  buffers to the output file

Is it possible to obtain parallel operation on an SMP machine with multiple  
virtual processors?  (Other than multiple OS processes with one PRNG on one  
JVM each?)


Even the locked random could be instantiated multiple times (each instance  
gets their own lock) and this could still be faster than running just  
one of it. However, since the computation itself is fast, I suppose the  
performance hit from managing the locks could be significant. Multiple OS  
processes would also work, but is pretty uncommon in Java land AFAIR.


I found it during the development of another application where I needed a  
lot of random data for simulation purposes :)


My implementation code is here:
https://github.com/m7a/bo-big/blob/master/latest/Big4.java


See the end of that file to compare with the “Numerical Recipes” RNG linked  
further above to observe the difference wrt. locking :)



If I were to do it again today, I'd probably switch to any of these PRNGS:

* https://burtleburtle.net/bob/rand/smallprng.html
* https://www.pcg-random.org/


Hard core.  I'll let the experts figure it out; and then I will use their  
libraries and programs.


IIRC one of the findings of PCG was that the default RNGs of many  
programming languages and environments are surprisingly bad. I only arrived at  
using a non-default implementation after facing some issues with the Java  
integrated ThreadLocalRandom ”back then” :)


It may indeed be worth pointing out (as Jeffrey Walton already mentioned in  
another subthread) that these RNGs discussed here are _not_ cryptographic  
RNGs. I think for disk testing purposes it is OK to use fast non- 
cryptographic RNGs, but other applications may have higher demands on their  
RNGs.


HTH
Linux-Fan

öö

[...]


pgpLYMPAsjGtj.pgp
Description: PGP signature

Re: Erreur nvidia suite upgrade noyau 6.1.0-18

[Bernard Schoenacker]

Hallo Wache,

Es tut mir leid, maintenant, il suffit de supprimer les noyaux anciens 
à la main pour que tout rentre dans l'ordre...

Merci

@+
Bernard 

- Mail original -
De: "ajh-valmer" 
À: debian-user-french@lists.debian.org
Envoyé: Mardi 13 Février 2024 18:22:49
Objet: Re: Erreur nvidia suite upgrade noyau 6.1.0-18

On Monday 12 February 2024 20:14:04 ajh-valmer wrote:
> Avant, j'ai purgé nvidia depuis le noyau 6.1.0-17,
> pour faire un upgrade => noyau 6.1.0-18 et tenter à nouveau :
> # apt update
> # apt upgrade
> Errors were encountered while processing:
>  linux-image-6.1.0-18-amd64
>  linux-image-amd64
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Je ne peux pas upgrader le système, je suis encore coincé...

Bonsoir à tous,
Je vais arrêter de vous embêter avec mes déboires,
sauf qu'il peut servir l'expérience des membres de cette ML.

Maintenant, je ne peux plus upgrader vers le noyau  6.1.0-18,
alors que mon système n'est qu'en noyau 6.1.0-17 (répertoire /boot/).
# apt update ,  apt upgrade ,  apt dist-upgrade , apt full-upgrade 
avec purge de nvidia,
n'émet aucun message d'erreur, comme si l'upgrade avait atteint son
maximum du moment.
Lu sur des forums anglais, allemand..., je ne suis pas le seul à avoir 
ce problème sans trouver un "resolved" (une solution).

Bonne soirée.

Re: simple virt-manager setup

[Michael Kjörling]

On 13 Feb 2024 18:10 +0100, from fnat...@gmx.net (Felix Natter):
> regarding virt-manager (qemu/kvm):
> 
> Can I safely choose the "NAT" network type for a new VM 
> in virt-manager (Debian12):

Yes. Doing so should create a new network interface named virbr[0-9]
and assign an IPv4 address range to it which will be used for VM
purposes.

> Can I safely say yes to
> "Do you want to bring it up?"? (is it undoable?)

Yes, it is undoable. You can either use virt-manager -> connection
details -> virtual networks (select the network and then click the
stop button below the list) or you can use

$ sudo virsh net-list --all

$ sudo virsh net-destroy network-name

Despite the scary action name, virsh net-destroy only stops the
network; it doesn't actually deconfigure it. (For that, you use virsh
net-undefine. There is also virsh net-autostart.) See the virsh(1) man
page.

If you want to be extra certain, you can dump your firewall rules just
before you bring up the KVM network so that you can restore them
without a reboot.


> If I choose NAT, can multiple VMs connect to each other
> and with the host?

I know that VMs can talk to the host through a KVM NAT interface. I
haven't tested whether they can talk to each other, but I would expect
so.

If you are using nftables on the host, you might find my blog post at
https://michael.kjorling.se/blog/2022/linux-kvm-host-nftables-guest-networking/
helpful if VMs can't talk to the network. I have received some
feedback that there are easier solutions, but try as I did at the time
I couldn't find them, and what I wrote up there Works For Me (tm).


> (I would like to avoid making many changes that I don't understand
> to a productive server)

Very understandable, and prudent.

You may want to consider subscribing to
https://lists.libvirt.org/archives/list/us...@lists.libvirt.org/;
subscription is mailto:users-j...@lists.libvirt.org.

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

Re: Erreur nvidia suite upgrade noyau 6.1.0-18

[ajh-valmer]

On Monday 12 February 2024 20:14:04 ajh-valmer wrote:
> Avant, j'ai purgé nvidia depuis le noyau 6.1.0-17,
> pour faire un upgrade => noyau 6.1.0-18 et tenter à nouveau :
> # apt update
> # apt upgrade
> Errors were encountered while processing:
>  linux-image-6.1.0-18-amd64
>  linux-image-amd64
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Je ne peux pas upgrader le système, je suis encore coincé...

Bonsoir à tous,
Je vais arrêter de vous embêter avec mes déboires,
sauf qu'il peut servir l'expérience des membres de cette ML.

Maintenant, je ne peux plus upgrader vers le noyau  6.1.0-18,
alors que mon système n'est qu'en noyau 6.1.0-17 (répertoire /boot/).
# apt update ,  apt upgrade ,  apt dist-upgrade , apt full-upgrade 
avec purge de nvidia,
n'émet aucun message d'erreur, comme si l'upgrade avait atteint son
maximum du moment.
Lu sur des forums anglais, allemand..., je ne suis pas le seul à avoir 
ce problème sans trouver un "resolved" (une solution).

Bonne soirée.

Re: debian-cd baking process

[Kevin Price]

Dear Steve:

Am 18.01.24 um 00:37 schrieb Steve McIntyre:
> Kevin Price wrote:
>> I'm not quite sure where to address this to,

> Argh, that's my code in the debian-cd package. "reportbug debian-cd"
> should do the right thing...

Thank you for your help, I should have known. So I've now filed
https://bugs.debian.org/1063858 . Please accept my apology for being
slow in doing that.

Cheers
-- 
Kevin Price

simple virt-manager setup

[Felix Natter]

Dear debian users,

regarding virt-manager (qemu/kvm):

Can I safely choose the "NAT" network type for a new VM 
in virt-manager (Debian12): Can I safely say yes to
"Do you want to bring it up?"? (is it undoable?)

If I choose NAT, can multiple VMs connect to each other
and with the host?

If not, can you suggest a tutorial for creating the necessary
bridge device for type=bridge?
(I would like to avoid making many changes that I don't understand
to a productive server)

Many Thanks and Best Regards,
Felix
-- 
Felix Natter

Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade

[zithro]

On 13 Feb 2024 10:31, Hugues MORIN-TRENEULE wrote:

@zithro / Cyril: je me suis trompé en écrivant, j'upgrade de bien de
 Stretch à Buster ;-)


Tant mieux ;)
C'est toujours bon de préciser pour les futurs lecteurs !


Donc je récapitule pour voir si j'ai bien compris: - ps pour trouver 
le PID d'apt - killall -9 "PID d'apt" - dpkg-reconfigure - apt 
upgrade --without-new-pkgs (=> Cette commande met à niveau les 
paquets qui peuvent l'être sans entraîner l'installation ou la 
suppression d'autres paquets. ) - apt full-upgrade


Ça vous semble correct ?


Oui ça devrait aller, lis bien les docs officiels de MàJ, à chaque
update majeur de version il y a des particularités (paquets obsolètes, etc).
Quand tu changes les sources, pense à enlever les backports, si tu les
utilises.
Si c'est une install avec GUI, essaie de faire l'update depuis
tty1/tty6, pas depuis X (vt7). Le serveur X -peut- redémarrer et te
perdre la fenêtre d'upgrade (donc le stopper en plein milieu).
Il est aussi recommandé d'utiliser "screen", pour parer à ce genre de
problèmes (lancer avec "screen -R upgrade", et récup avec la même
commande si ça coupe. Tu peux changer "upgrade" en hugues ou w/e).
La commande "script" est aussi recommandée, pour tout enregistrer.

J'ajoute quelques commandes qui peuvent être utiles avant de lancer
l'upgrade. Elles sont aussi  recommandées dans les "Release Notes", afin
de partir sur une base saine avant l'upgrade.
Certaines commandes sont équivalentes et donneront le même résultat.
Quant à quoi faire du résultat ... ça dépend ! Pas de recette miracle.
Mais ce n'est ni parce que tu n'as rien, ni parce que tu as des
résultats que c'est un gage de réussite (:

# lister les paquets obsolètes et "not-from-Debian"
apt list '~o'
# les purger - ATTENTION, purge=remove conf files
apt purge '~o'
apt list '?narrow(?installed, ?not(?origin(Debian)))'
apt-forktracer | sort

# vérif les paquets, surtout ceux en "hold"
dpkg --audit
dpkg --get-selections | grep 'hold$'
apt-mark showhold

# liens symboliques dans /etc qui pointent nulle part
symlinks -r /etc | grep dangling

# trouver les anciens fichiers config (ie. de paquets supprimés ou
d'anciennes versions de paquets mis à jour)
# (cette commande est affichée sur 2 lignes dans ce mail)
find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
-o -name '*.old*'
# equivalent
dpkg -l | grep ^rc
# les purger - ATTENTION, perte de données
apt purge $(dpkg -l | awk '/^rc/ { print $2 }')

Sinon, quelques paquets à installer avant l'upgrade si t'aimes bien tout
check :
deborphan
apt-forktracer
apt-listbugs
apt-listchanges

Bref, tu as presque toutes les armes, "pick your poison" comme disent
les ricains !
Perso, je préfère mettre toutes les chances de mon côté donc je lance 
toutes les commandes sur toutes les machines.

Certains risquent de dire que c'est too much. A toi de voir ;)

--
++
zithro / Cyril

Re: shred bug? [was: Unidentified subject!]

[Greg Wooledge]

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.

Finally, the sixth line closes file descriptor 3.  Doing this frees the
file's inode and blocks, allowing them to be reused by a future program.

The key to understanding this example is a firm grasp of the shell's
redirection syntax and semantics.

Let's start with what people normally see:  3>filename

That opens "filename" for writing with truncation, and ensures that 

Re: shred bug? [was: Unidentified subject!]

[David Wright]

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!]

[Thomas Schmitt]

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!]

[tomas]

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.  

Well, thanks for doing TRT :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: shred bug? [was: Unidentified subject!]

[Greg Wooledge]

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.  

Re: shred bug? [was: Unidentified subject!]

[Greg Wooledge]

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.

Fix for boot failure with testing stream and 6.6.13-amd64 kernel

[Sam Varghese]

This is a post meant to help anyone who finds his/her system unbootable 
- as I did - after updating to the latest version of the testing stream 
which comes with a 6.6.13-amd64 kernel.


When I updated last week, my system refused to boot. Checking revealed 
that the system-load-modules service was missing.


I then checked to see if the linux-headers for this version had been 
installed.


root@zizyphus:~# dpkg -l | grep linux-headers-6.6.13-amd64

Turns out it has not been installed.

Installing it also brings along a couple of other packages; these three 
packages fix the issue and make the machine bootable again.


Sam
--

(Sam Varghese)

Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade

[Hugues MORIN-TRENEULE]

Bonjour

Merci à tous pour votre aide :)

@zithro / Cyril: je me suis trompé en écrivant, j'upgrade de bien de
Stretch à Buster ;-)

Donc je récapitule pour voir si j'ai bien compris:
- ps pour trouver le PID d'apt
- killall -9 "PID d'apt"
- dpkg-reconfigure
- apt upgrade --without-new-pkgs (=> Cette commande met à niveau les
paquets qui peuvent l'être sans entraîner l'installation ou la suppression
d'autres paquets. )
- apt full-upgrade

Ça vous semble correct ?

Très cordialement
Hugues






Le mar. 13 févr. 2024 à 09:34, Michel Verdier  a écrit :

> Le 12 février 2024 Hugues MORIN-TRENEULE a écrit :
>
> > Avec le recul, aujourd'hui, je ne ferai que des partitions pour /home,
> /var
> > et /opt.
>
> /home et /opt il faut voir selon tes applis. Mais si /var est saturé ça
> bloque tout le système à cause des logs qui ne peuvent plus se faire.
>
> > Est ce que cela vous semble suffisant pour l'upgrade?
>
> Oui bien mieux, 1.1Go pour / me parait suffisant.
>
> > Et dans l'affirmative, que faut-il faire ensuite?
>
> Recommence avec le apt upgrade --without-new-pkgs
> S'il reste des packages non configurés apt te le dira et te donnera la
> commande à passer pour finir la configuration précédente.
>
>

Re: Combining Distro DVD's

[Keith Bainbridge]

Good evening All

I know some people just like a challenge. Who will use the result, though

I wonder if ventoy would achieve a similar result

There is a 32MB partition for efi; and the rest, which for me at present is:


ls /media/keith/Ventoy/
apps linuxmint-21.3-cinnamon-64bit-beta.iso
configfiles   lmde-6-cinnamon-64bit.iso
debian-live-12.4.0-amd64-cinnamon.iso 
manjaro-cinnamon-23.0.1-230921-linux65.iso

debian-testing-amd64-netinst.iso Win10_22H2_EnglishInternational_x64v1.iso
kali-linux-2023.4-installer-purple-amd64.iso
keith@lenv0 $

the iso's are just copied onto the main partition.

apps/ is my daily drivers that I keep on a separate partition. Things 
like firefox & thunderbird dev editions and a few appImages


configfiles/: .bashrc, _history _aliases  data for espanso

I boot to the USB and am offered the list of iso's to start, just like 
grubb on a multI boot system.  click the iso I want


I imagine that the subsequent iso's could be opened after you boot from 
the first iso.



Next project - get the iso to retain any changes I make



All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00

On 13/2/24 19:24, hw wrote:

On Mon, 2024-02-12 at 13:41 -0500, Steve Matzura wrote:

I thought it'd be a nice idea to combine any and all distribution media
for a release into a single medium--a USB drive, of course. I'd start by
creating my USB drive by extracting the first DVD to it, thereby
ensuring the boot block and boot material is where it should be. But
then what do I do with the additional media?
[...]


Maybe put a copy of a Debian mirror onto another partition.

Re: Combining Distro DVD's

[Andrew M.A. Cater]

On Tue, Feb 13, 2024 at 09:24:47AM +0100, hw wrote:
> On Mon, 2024-02-12 at 13:41 -0500, Steve Matzura wrote:
> > I thought it'd be a nice idea to combine any and all distribution media 
> > for a release into a single medium--a USB drive, of course. I'd start by 
> > creating my USB drive by extracting the first DVD to it, thereby 
> > ensuring the boot block and boot material is where it should be. But 
> > then what do I do with the additional media?
> > [...]
> 
> Maybe put a copy of a Debian mirror onto another partition.
> 

"All distribution media" - including source - is a very large USB stick.

If you want the DVD contents, for binaries on one architecture - say amd64,
 start with the 16G image or the Blu-Ray
and you've got it fairly well - you will need to use jigdo to do this..

There have been discussions on this a few times on the list - look back
and someone posted a script to do this.

>From experience: writing even 29G reliably to a USB3 stick takes a _long_
time. The odds of a bit error while writing much more go up significantly.

For Debian on a desert island - a laptop with a mirror on a 4G NVME would
be fine. Mirror is probably a more reliable way to go.

All the best,

Andy

Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade

[Michel Verdier]

Le 12 février 2024 Hugues MORIN-TRENEULE a écrit :

> Avec le recul, aujourd'hui, je ne ferai que des partitions pour /home, /var
> et /opt.

/home et /opt il faut voir selon tes applis. Mais si /var est saturé ça
bloque tout le système à cause des logs qui ne peuvent plus se faire.

> Est ce que cela vous semble suffisant pour l'upgrade?

Oui bien mieux, 1.1Go pour / me parait suffisant.

> Et dans l'affirmative, que faut-il faire ensuite?

Recommence avec le apt upgrade --without-new-pkgs
S'il reste des packages non configurés apt te le dira et te donnera la
commande à passer pour finir la configuration précédente.

Re: Combining Distro DVD's

[hw]

On Mon, 2024-02-12 at 13:41 -0500, Steve Matzura wrote:
> I thought it'd be a nice idea to combine any and all distribution media 
> for a release into a single medium--a USB drive, of course. I'd start by 
> creating my USB drive by extracting the first DVD to it, thereby 
> ensuring the boot block and boot material is where it should be. But 
> then what do I do with the additional media?
> [...]

Maybe put a copy of a Debian mirror onto another partition.