Re: How can we change the keyboard layout?

[hw]

On Sun, 2024-02-11 at 10:35 -0600, David Wright wrote:
> On Wed 07 Feb 2024 at 06:58:39 (+0100), hw wrote:
> > [...]
> > > It's also obvious that "change the keyboard layout" is ambiguous,
> > > and you didn't intend to mean switching between two layouts.
> > 
> > It's not at all obvious, and it's not really ambiguous.  Changing the
> > keyboard layout has always been about changing the keybaord layout and
> > never about switching between different keyboards or between different
> > layouts.  That only came up much later when such a feature was added
> > to some so-called desktop environments, and it's a very short sighted
> > feature since it omits a way of changing they keyboard layouts, which
> > is a far more important feature.
> 
> It seems quite important when you're used to typing in more than
> one language, and want your layout to match what you're used to.

Sure it is, and when you do that, it's even more important to be able
to change the layout because you have to do it for all the languages
you're used to typing in --- and for all the keyboards you're using.
I'd use multiple keyboards if I had to do that and just change between
keyboards.

I don't know if that's possible, but I expect it to be possible since
USB makes it easily possible to have multiple keyboards connected at
the same time.  So like in gnome settings, all the connected keyboards
need to show up so that I can pick a layout for each and then change
their layouts as I need them.  If that doesn't work it's a bug.

Actually, I just tried it and it doesn't work :(  The German keyboard
gets an US layout just like the US keyboard; it doesn't show up in
gnome settings, and there is no way to select a keyboard and to pick a
layout for it.  That really sucks --- I can only assume that
developers don't want to have to do anything with keyboard layouts,
which might explain why it has always been a nightmare to get a
keyboard to work right and still is.

> > > > [...]
> > > My 2014 keyboard appears to identify itself correctly as a K520. My
> > > old IBM M says it's an "AT Translated Set 2 keyboard", which seems
> > > reasonable for a keyboard dating from 1988.
> > 
> > I can see USB keyboards identifying themselves, but keyboards with
> > PS/2 or DIN connectors?  How does your keyboard from 1988 connect?
> 
> PS/2. IIRC it came with a genuine IBM PS/2 computer.

Where does it show up?  Where does the information originate from?
Perhaps the information is merely an assumption some of the involved
the software makes and not something the keyboard tells it.

> > > In 26 years, the number of keys has increased considerably, from 102
> > > to 107, plus six audiovisual buttons. Two of the extra keys are
> > > shifting ones (win and fn).
> > 
> > 10% more keys isn't considerably more.  Can you show me a keyboard
> > with 122 keys that has all keys usable and unique rather than sending
> > key combinations instead?
> 
> That would be difficult:

That's what I've been saying :)  Years ago I read an article about
keyboards and it said that due to hardware restrictions, only so many
keys can be handled so that keyboards with 122 keys don't really work:
Either the controller in the keyboard key combinations, or the keys do
nothing.  Apparently such keyboards seem to come from terminals that
could use all the keys while PC hardware can not.

About 20 years ago I've seen a machine with terminals running some HP
Unix that had keyboards like that.  They were networked through token
ring coax cables and had been used to run some CAD software which had
been replaced with, IIRC, autocad, but there were still files people
sometimes needed to retrieve from them, via NFS IIRC.  They were nice
keyboards and had connectors that wouldn't fit any PC.

> I've never had a 122 key keyboard, or even seen one. You have
> one. In terms of xev output, are there duplicate keys? Which ones,
> and how does xev identify them?

I don't know if there are duplicate keys.  I didn't try out all the
key to find any, and I haven't noticed any.

When I press F18, for example, wev says:

,
| [11:  wl_data_device] selection: id: 4278190081
| [13:  wl_pointer] motion: time: 665008611; x, y: 617.781250, 467.316406
| [13:  wl_pointer] frame
| [14: wl_keyboard] key: serial: 270273; time: 665012185; key: 50; state: 1 
(pressed)
|   sym: Shift_L  (65505), utf8: ''
| [14: wl_keyboard] modifiers: serial: 270274; group: 0
|   depressed: 0001: Shift 
|   latched: 
|   locked: 0010: Mod2 
| [14: wl_keyboard] key: serial: 270275; time: 665012185; key: 72; state: 1 
(pressed)
|   sym: F6   (65475), utf8: ''
| [14: wl_keyboard] key: serial: 270276; time: 665012313; key: 50; state: 0 
(released)
|   sym: Shift_L  (65505), utf8: ''
| [14: wl_keyboard] modifiers: serial: 270277; group: 0
|   

Re: netselect-apt falla

[Narcis Garcia]

El 12/2/24 a les 21:38, Alex Muntada ha escrit:

Hola Narcis,


Did not found any valid hosts (you requested 10)
netselect was unable to find a mirror, this probably means that
you are behind a firewall and it is blocking ICMP and/or
UDP traceroute. Or the servers test are actively blocking
ICMP and/or UDP traceroute probes.


Crec que avui en dia és força normal filtrar aquest tipus de
sondes de xarxa per evitar abusos.


-> El router d'Internet no està filtrant la comunicació per UDP
ni ICMP.


El teu potser no, però els dels miralls segurament sí.


-> Si provo a verificar manualment els servidors amb el simple
«netselect» només té èxit si afegeixo l'opció -I
però el «netselect-apt» no admet l'opció -I


https://manpages.debian.org/bookworm/netselect-apt/netselect-apt.1.en.html#O

The OPTIONS provided are added, verbatim, to netselect when it is
run. Here you can provide a (quoted) list of options for netselect.



Gràcies, funciona!
(no havia llegit prou bé la pàgina del manual, i allà estava la solució)

--

Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should remove and omit any @, dot and mailto combinations against 
automated addresses collectors.

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

[tomas]

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

[David Wright]

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: Stretch vers Bullseye - Probleme lors du apt full-upgrade

[Jeffrey Walton]

On Mon, Feb 12, 2024 at 8:57 PM Gilles Mocellin
 wrote:
>
> Le lundi 12 février 2024, 19:23:39 CET Hugues MORIN-TRENEULE a écrit :
> > Salut
> >
> > Merci pour l'info
> >
> > Malheureusement même si j'entrevois de quoi tu parles, je ne sais pas trop
> > comment faire en pratique.
> >
> > Donc si je comprends bien, maintenant que j'ai fait de la place, il faut
> > que je relance la commande apt full-upgrade
> > Mais avant cela, je dois killer le pid de apt et faire un dpkg-reconfigure.
> >
> > Pour trouver le pid d'apt, c'est à l'aide de la commande ps?
> > Et apres kill "n° de pid"
> >
> > Est ce qu'il y a autre chose a faire pour killer le processus d'apt?
>
> Le plus simple c'est avec killall, et à mon avis il doit y avoir des enfants
> d'apt, en dpkg (avec sudo si tu n'es pas root) :
> killall dpkg
> killall apt
>
> Pour voir s'il en reste :
> ps -ef | grep apt
> ps -ef | grep dpkg
>
> Evidemment, ces commandes font aussi apparaitre le grep lui même.
>
> > Ensuite dpkg-reconfigure
>
> Je pense que c'est plutôt :
> dpkg --configure -a
> Quand l'install a été interrompue (notez les espaces, c'est bien la commande
> dpkg et non la commande dpkg-reconfigure.
>
> > et enfin apt full-upgrade
> >
> > Est ce que cela vous semble OK

debian-users-french is probably a better list for this discussion,
.

Jeff

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

[Max Nikulin]

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: [ *** ] Job anacron.service/stop running (15min 49s / no limit)

[Max Nikulin]

On 13/02/2024 03:16, Rainer Dorsch wrote:


I will check the anacron
status before the next reboot.


Try it now. It is a good chance that you have a stuck job already 
(waiting for read on a file descriptor leaked from the parent, etc.).

Re: 6.1.0-18 i NVIDIA

[Jordi]

Bones, al final he instal.lat el nucli 6.5.0-0.deb12.4-amd64 de debian
backports i els controladors de NVIDIA es compilen bé.
Sembla que funciona correctament i per ara ho deixaré així.
Salutacions
Jordi

El dg. 11 de 02 de 2024 a les 16:40 +0100, en/na Vicen Rodriguez va
escriure:
> Bon dia:
> 
> Jo he tingut el mateix problema.
> 6.1.0-13-amd64, 6.1.0-16-amd64 i 6.1.0-17-amd64 no tenen aquest
> problema.
> 
> L'intent d'actualització a 6.1.0-18-amd64 genera l'error.
> 
> Cercant una mica, les recomanacions que he trobat per intentar
> esquivar
> el problema han estat quedar-se a 6.1.0-17-amd64 o deixar de fer
> servir
> el nvidia-driver i passar-se a nouveau.
> De moment, segueixo a 6.1.0-17-amd64.
> 
> Salut,
> 
> Vicen
> 
> El dom, 11-02-2024 a las 10:07 +0100, Narcis Garcia escribió:
> > Bon dia;
> > 
> > Debian 11 (old/Stable) per a Linux utilitza el nucli 5.10
> > Debian 12 (Stable) per a Linux utilitza el nucli 6.1
> > Debian 12 (Backports) per a Linux disposa del nucli 6.5
> > 
> > Entenc que et refereixes en tot moment a Linux 6.1.0-18
> > Amb quins nuclis ho has provat sense problema?
> > 
> > 
> > El 11/2/24 a les 10:01, Jordi ha escrit:
> > > Bon dia, ahir vaig actualitzar el debian i ara a l'intentar
> > > compilar
> > > els controladors de NVIDIA em surt el següent error : GPL-
> > > incompatible
> > > module nvidia.ko uses GPL-only symbol rcu_read_unlock. Això passa
> > > amb
> > > el nucli 6.0.1-18. Cap controlador NVIDIA es pot compilar amb
> > > aquest
> > > nucli i tots els controladors es compilen en altres nuclis.
> > > 
> > > Hi ha alguna referència a aquest tema en alguna llista però no he
> > > trobat com solventar-ho. Algú sap com fer-ho, no sé, pot ser
> > > afegint
> > > algun paràmetre a /etc/default/grub   ??
> > > 
> > > Salutacions
> > > 
> > > Jordi
> > >   
> > > 
> > 
> 

Re: Fast Random Data Generation (Was: Re: Unidentified subject!)

[David Christensen]

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.)



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?)



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

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.



David

Re: Fast Random Data Generation (Was: Re: Unidentified subject!)

[Jeffrey Walton]

On Mon, Feb 12, 2024 at 3:02 PM 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
> >>
> >> Before knowing about `fio` this way my way to benchmark SSDs :)
> >>
> >> Example:
> >>
> >> | $ big4 -b /dev/null 100 GiB
> >> | Ma_Sys.ma Big 4.0.2, Copyright (c) 2014, 2019, 2020 Ma_Sys.ma.
> >> | For further info send an e-mail to ma_sys...@web.de.
>
> [...]
>
> >> | 99.97% +8426 MiB 7813 MiB/s 102368/102400 MiB
> >> | Wrote 102400 MiB in 13 s @ 7812.023 MiB/s
> >
> >
> > What algorithm did you implement?
>
> I copied the algorithm from here:
> https://www.javamex.com/tutorials/random_numbers/numerical_recipes.shtml
>
> I found it during the development of another application where I needed a
> lot of random data for simulation purposes :)

A PRNG for a simulation has different requirements than a PRNG for
cryptographic purposes. A simulation usually needs numbers fast from a
uniform distribution. Simulations can use predictable numbers. Often a
Linear Congurential Generator (LCG) will do just fine even though they
were broken about 35 years ago. See Also see Joan Boyer's Inferring
Sequences Produced by Pseudo-Random Number Generators,
.

A cryptographic application will have more stringent requirements. A
cryptographic generator may (will?) take longer to generate a number,
the numbers need to come from a uniform distribution, and the numbers
need to be prediction resistant. You can read about the cryptographic
qualities of random numbers in NIST SP800-90 and friends.

> My implementation code is here:
> https://github.com/m7a/bo-big/blob/master/latest/Big4.java
>
> 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/
>
> >> Secure Random can be obtained from OpenSSL:
> >>
> >> | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 
> >> 1024
> >> * 1024)); done
> >> |
> >> | real0m49.288s
> >> | user0m44.710s
> >> | sys0m4.579s
> >>
> >> Effectively 2078 MiB/s (quite OK for single-threaded operation). It is not
> >> designed to generate large amounts of random data as the size is limited by
> >> integer range...

Jeff

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

[Thomas Schmitt]

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

[David Christensen]

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: Combining Distro DVD's

[Thomas Schmitt]

Hi,

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.

The initial situation will depend much on the distro ...
But given that Debian is about the last one i know with all its packages
in DVD images, i assume you mean the Debian installer ISO sets. Like
  https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd/


> 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.

There is the dilemma that unpacking the first ISO into the USB stick's
filesystem will not enable the copied boot stuff, and that putting the
first ISO plainly onto the stick (e.g. by dd) will leave you with a
read-only filesystem on the stick.

So you'd need to invest some extra expertise.
Either for making a bootable USB stick with read-write filesystem from
the first ISO, or for merging the ISOs into a single ISO. In the former
case you need knowledge about booting Debian (by GRUB, i guess). In the
latter case you need xorriso.


> But then what do I
> do with the additional media? Surely there will be some files with the same
> name among the individual pieces of media, and some will probably contain
> the same info while others probably will not.

They should be either either merged or discarded, depending on their
meaning and on their importance for your final result. I.e. whether you
merged the ISOs or you extracted to a writable filesystem and installed
a bootloader yourself.

The way of merging multiple Debian DVD ISOs of the same release and
CPU architecture to a single ISO by xorriso is described in

  https://wiki.debian.org/MergeDebianIsos

(The script merge_debian_isos would also be the source to learn about
the proper handling of files with expected name collision.)


I leave it to others to elaborate the ways of creating a bootable USB
stick with writable filesystem and the content of Debian DVD 1 with
work-ready installer software. Then it's an adventure on its own to
add all the packages from the other DVD images and to properly care
for their non-package files.


Have a nice day :)

Thomas

Re: netselect-apt falla

[Alex Muntada]

Hola Narcis,

> Did not found any valid hosts (you requested 10)
> netselect was unable to find a mirror, this probably means that
> you are behind a firewall and it is blocking ICMP and/or
> UDP traceroute. Or the servers test are actively blocking
> ICMP and/or UDP traceroute probes.

Crec que avui en dia és força normal filtrar aquest tipus de
sondes de xarxa per evitar abusos.

> -> El router d'Internet no està filtrant la comunicació per UDP
> ni ICMP.

El teu potser no, però els dels miralls segurament sí.

> -> Si provo a verificar manualment els servidors amb el simple
> «netselect» només té èxit si afegeixo l'opció -I
> però el «netselect-apt» no admet l'opció -I

https://manpages.debian.org/bookworm/netselect-apt/netselect-apt.1.en.html#O

The OPTIONS provided are added, verbatim, to netselect when it is
run. Here you can provide a (quoted) list of options for netselect.

Salut,
Alex

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



signature.asc
Description: PGP signature

Re: [ *** ] Job anacron.service/stop running (15min 49s / no limit)

[Rainer Dorsch]

Hi David and Max,

many thanks for the precise and very helpful answers. I will check the anacron 
status before the next reboot.

Thanks again
Rainer

Am Montag, 12. Februar 2024, 05:20:16 CET schrieb David Wright:
> On Sun 11 Feb 2024 at 20:41:51 (+), Darac Marjal wrote:
> > On 11/02/2024 11:21, Rainer Dorsch wrote:
> > > - How do I set a timeout/limit for anacron, that it cannot block forever
> > > during a reboot?
> > 
> > It may be germane to point out that anacron.service already explicitly
> > sets "TimeoutStopSec=Infinity". So, in the opinion of the developers,
> > the service shouldn't be prematurely killed. Of course you, as the
> > system administrator, always have the right to countermand that sort
> > of decision, but it would be curious to find out why the developers
> > thought they needed to override the systemd default in the first
> > place?
> 
> Bug #915379 explains all: long-running cron jobs, like backups, can
> get killed, and there was also an issue with exim.
> 
> There's mention there of an anacron replacement called cronie, but
> I don't know what the status of this is, besides being in trixie.
> 
> Cheers,
> David.


-- 
Rainer Dorsch
http://bokomoko.de/

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

[Greg Wooledge]

On Mon, Feb 12, 2024 at 09:04:01PM +0100, Thomas Schmitt wrote:
> Hi,
> 
> John Boxall wrote:
> > I am aware that the label and uuid (drive and partition) are replicated on
> > the cloned drive, but I can't find the model number (in text format) stored
> > anywhere on the drive.
> 
> Maybe the grub-pc package takes its configuration from a different drive
> which is attached to the system ?

According to

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

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

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

[Thomas Schmitt]

Hi,

John Boxall wrote:
> I am aware that the label and uuid (drive and partition) are replicated on
> the cloned drive, but I can't find the model number (in text format) stored
> anywhere on the drive.

Maybe the grub-pc package takes its configuration from a different drive
which is attached to the system ?

Somewhat wayward idea:
Does the initrd contain the inappropirate address ?
(I don't see much connection between initrd and grub-pc. But initrd is a
classic hideout for obsolete paths after modification of boot procedures.)


Have a nice day :)

Thomas

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

[John Boxall]

On 2024-02-12 09:34, Thomas Schmitt wrote:


The disk/by-id file names are made up from hardware properties.
I believe to see in the name at least: Manufacturer, Model, Serial Number.

So you will have to find the configuration file which knows that
/dev/disk/by-id address and change it either to the new hardware id or
to a /dev/disk/by-uuid address, which refers to the cloned disk content.


Have a nice day :)

Thomas



Thank you Thomas. That is what I am trying to find as I have searched 
for both the SSD drive model number and the WWN on the cloned HDD but 
can't find anything.


I am aware that the label and uuid (drive and partition) are replicated 
on the cloned drive, but I can't find the model number (in text format) 
stored anywhere on the drive.


I will keep looking.

--
Regards,

John Boxall

Re: Combining Distro DVD's

[Nicolas George]

Steve Matzura (12024-02-12):
> 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? Surely there will be some files with the same
> name among the individual pieces of media, and some will probably contain
> the same info while others probably will not. What do I have to watch for
> and make sure I don't overwrite, but add to, when extracting files from the
> additional disks to bag it all up and make a single medium which contains
> everything in one place?

If the live media are compatible with GRUB's loopback mechanism, you can
follow these instructions:

https://nsup.org/~george/comp/live_iso_usb/grub_hybrid.html
https://nsup.org/~george/comp/live_iso_usb/

Regards,

-- 
  Nicolas George

Re: Erreur nvidia suite upgrade noyau 6.1.0-18

[ajh-valmer]

On Sunday 11 February 2024 11:43:32 Michel Verdier wrote:
> Le 10 février 2024 ajh-valmer a écrit :
> > Je ne peux donc pas augmenter la résolution avec ce pilote "Nouveau".
> > On dirait que c'est le pilote "Vesa" qui a pris la main, pas "Nouveau"...
> As-tu regardé dans les log ? Le pilote utilisé est indiqué clairement :
Je vais voir.

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é...
Bonne soirée.

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

[zithro]

On 12 Feb 2024 08:00, Hugues MORIN-TRENEULE wrote:

Bonjour a tous


Je reviens vers vous car je ne sais pas comment m'y prendre pour réparer un
crash lors d'un apt full-upgrade lors d'un passage de Stretch a Bullseye.


Ca fonctionne peut-être, mais ce n'est pas la manière recommandée !
Seulement l'update de "version" à "version +1" l'est.

Donc tu devrais faire :
1. stretch -> buster
2. buster -> bullseye

Pour l'avoir fait récemment, les étapes sont quasi les mêmes donc c'est 
pas trop chiant, et c'est plus sûr (ie. tu risques moins d'erreurs).
Fais un doc avec juste les commandes pour aller plus vite. Si tu veux 
les miens je peux te les filer.


--
++
zithro / Cyril

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

[nicolas . patrois]

On 12/02/2024 19:23:39, Hugues MORIN-TRENEULE wrote:

> Pour trouver le pid d'apt, c'est à l'aide de la commande ps?
> Et apres kill "n° de pid"

> Est ce qu'il y a autre chose a faire pour killer le processus d'apt?

Tu peux tuer un processus en utilisant son nom avec la commande killall, qui 
s’utilise comme kill.
killall firefox
killall -9 firefox

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

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

[Hugues MORIN-TRENEULE]

Salut

Merci pour l'info

Malheureusement même si j'entrevois de quoi tu parles, je ne sais pas trop
comment faire en pratique.

Donc si je comprends bien, maintenant que j'ai fait de la place, il faut
que je relance la commande apt full-upgrade
Mais avant cela, je dois killer le pid de apt et faire un dpkg-reconfigure.

Pour trouver le pid d'apt, c'est à l'aide de la commande ps?
Et apres kill "n° de pid"

Est ce qu'il y a autre chose a faire pour killer le processus d'apt?

Ensuite dpkg-reconfigure
et enfin apt full-upgrade

Est ce que cela vous semble OK

Très cordialement
Hugues


Le lun. 12 févr. 2024 à 18:49, Alain RICHARD  a écrit :

> J’ai fait récemment un apt full-upgrade de Debian 12 à Debian 13 (Trixie)
> et mon Pc s’est éteint (fausse manœuvre) et après avoir rebooté, le système
> m’a pas laissé recommencer la même commande. J’ai du killer le Pid de apt
> et faire un dpkg —reconfigure -à et ça a été.
>
>
> Le 12 févr. 2024 à 17:14, Hugues MORIN-TRENEULE  a
> écrit :
>
> 
> Salut
>
>
> C'est un système qui à l'origine avait été installé en Wheezy ou Jessie et
> que j'ai upgradé.
> Je n'avais pas autant de connaissance que maintenant et il m'avait semblé
> plus judicieux de faire une partition par montage.
> Je me disais que ca serait surement plus simple de restaurer le système en
> cas de crash avec cette manière de faire.
> Avec le recul, aujourd'hui, je ne ferai que des partitions pour /home,
> /var et /opt.
>
>
> Sinon concernant le "ménage", j'ai supprimé les anciens kernel dans /boot.
> J'ai supprimé aussi les dossiers modules concernés dans /lib/module.
>
> Voila le nouvel etat de mon systeme de fichiers:
>
> df -TPh
> Filesystem Type  Size  Used Avail Use% Mounted on
> udev   devtmpfs  2.0G 0  2.0G   0% /dev
> tmpfs  tmpfs 396M  7.5M  389M   2% /run
> /dev/sda1  ext4  1.8G  661M  1.1G  39% /
> /dev/sda8  ext4   28G  7.2G   19G  28% /usr
> tmpfs  tmpfs 2.0G 0  2.0G   0% /dev/shm
> tmpfs  tmpfs 5.0M  4.0K  5.0M   1% /run/lock
> tmpfs  tmpfs 2.0G 0  2.0G   0% /sys/fs/cgroup
> /dev/sdc1  ext4  916G  583G  287G  68% /mnt/data2
> /dev/sdb1  fuseblk   299G  285G   14G  96% /mnt/data
> /dev/sda10 ext4   28G  2.7G   24G  11% /opt
> /dev/sda7  ext4  1.8G   72K  1.7G   1% /tmp
> /dev/sda9  ext4   19G  6.5G   11G  38% /var
> /dev/sda3  ext4   73G  5.0G   65G   8% /home
> /dev/sda5  ext4  920M  232M  625M  28% /boot
> tmpfs  tmpfs 396M 0  396M   0% /run/user/0
> /dev/sdd1  vfat  7.5G  366M  7.2G   5% /root/corsair
>
> df -i
> Filesystem   Inodes  IUsedIFree IUse% Mounted on
> udev 502193490   5017031% /dev
> tmpfs506243848   5053951% /run
> /dev/sda1122160  15831   106329   13% /
> /dev/sda8   1831424 311408  1520016   18% /usr
> tmpfs506243  1   5062421% /dev/shm
> tmpfs506243  4   5062391% /run/lock
> tmpfs506243 16   5062271% /sys/fs/cgroup
> /dev/sdc1  61054976  13288 610416881% /mnt/data2
> /dev/sdb1  14184328   6185 141781431% /mnt/data
> /dev/sda10  1831424797  18306271% /opt
> /dev/sda7122160 28   1221321% /tmp
> /dev/sda9   1220608  18510  12020982% /var
> /dev/sda3   4890624  68947  48216772% /home
> /dev/sda5 61056392606641% /boot
> tmpfs506243 11   5062321% /run/user/0
> /dev/sdd1 0  00 - /root/corsair
>
> du -h -d 1
> 2.7G ./opt
> 417M ./root
> 6.5G ./var
> 0 ./sys
> 16K ./lost+found
> 16M ./etc
> 7.5M ./run
> 12K ./media
> 4.0K ./lib64
> 5.0G ./home
> 7.2G ./usr
> 13M ./sbin
> 12M ./bin
> 68K ./tmp
> 564M ./lib
> 868G ./mnt
> 6.1M ./lib32
> 4.0K ./srv
> 232M ./boot
> 0 ./dev
> 4.0K ./.cache
> 0 ./proc
> 890G .
>
> Est ce que cela vous semble suffisant pour l'upgrade?
>
> Et dans l'affirmative, que faut-il faire ensuite?
> Je n'en ai pas la moindre idée et je ne voudrai pas exécuter de commande
> qui pourrait faire empirer le probleme.
>
> Très cordialement
> Hugues
>
>
> Le lun. 12 févr. 2024 à 13:22, Michel Verdier  a écrit :
>
>> Le 12 février 2024 Hugues MORIN-TRENEULE a écrit :
>>
>> > J'ai effectivement vu ce message mais je n'en avais pas compris la
>> raison.
>> > Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et
>> > /boot son bien "chargées".
>> > Est ce que le problème pourrait provenir de la?
>>
>> Le message repéré par Alban porte sur /lib donc ton /
>> qui n'a que 127Mo de libre. La taille des modules varie selon les
>> kernels. Chez moi ça prend dans les 80Mo. Et il faut compter des fichiers
>> temporaires pendant l'installation. Déjà fais peut-être le ménage dans
>> les kernels que tu n'utilise pas, ton /boot semble pas mal rempli. Ce
>> n'est pas gênant pour /boot qui a de la marge mais ça libérera aussi de
>> la place sur /
>>
>> > 

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

[Greg Wooledge]

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

[Curt]

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

[Linux-Fan]

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

Before knowing about `fio` this way my way to benchmark SSDs :)

Example:

| $ big4 -b /dev/null 100 GiB
| Ma_Sys.ma Big 4.0.2, Copyright (c) 2014, 2019, 2020 Ma_Sys.ma.
| For further info send an e-mail to ma_sys...@web.de.


[...]


| 99.97% +8426 MiB 7813 MiB/s 102368/102400 MiB
| Wrote 102400 MiB in 13 s @ 7812.023 MiB/s



What algorithm did you implement?


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

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

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/


Secure Random can be obtained from OpenSSL:

| $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024  
* 1024)); done

|
| real    0m49.288s
| user    0m44.710s
| sys    0m4.579s

Effectively 2078 MiB/s (quite OK for single-threaded operation). It is not  
designed to generate large amounts of random data as the size is limited by  
integer range...



Thank you for posting the openssl(1) incantation.


You're welcome.

[...]

HTH
Linux-Fan

öö


pgpjvuqb6Fy1L.pgp
Description: PGP signature

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

[Hugues MORIN-TRENEULE]

Salut


C'est un système qui à l'origine avait été installé en Wheezy ou Jessie et
que j'ai upgradé.
Je n'avais pas autant de connaissance que maintenant et il m'avait semblé
plus judicieux de faire une partition par montage.
Je me disais que ca serait surement plus simple de restaurer le système en
cas de crash avec cette manière de faire.
Avec le recul, aujourd'hui, je ne ferai que des partitions pour /home, /var
et /opt.


Sinon concernant le "ménage", j'ai supprimé les anciens kernel dans /boot.
J'ai supprimé aussi les dossiers modules concernés dans /lib/module.

Voila le nouvel etat de mon systeme de fichiers:

df -TPh
Filesystem Type  Size  Used Avail Use% Mounted on
udev   devtmpfs  2.0G 0  2.0G   0% /dev
tmpfs  tmpfs 396M  7.5M  389M   2% /run
/dev/sda1  ext4  1.8G  661M  1.1G  39% /
/dev/sda8  ext4   28G  7.2G   19G  28% /usr
tmpfs  tmpfs 2.0G 0  2.0G   0% /dev/shm
tmpfs  tmpfs 5.0M  4.0K  5.0M   1% /run/lock
tmpfs  tmpfs 2.0G 0  2.0G   0% /sys/fs/cgroup
/dev/sdc1  ext4  916G  583G  287G  68% /mnt/data2
/dev/sdb1  fuseblk   299G  285G   14G  96% /mnt/data
/dev/sda10 ext4   28G  2.7G   24G  11% /opt
/dev/sda7  ext4  1.8G   72K  1.7G   1% /tmp
/dev/sda9  ext4   19G  6.5G   11G  38% /var
/dev/sda3  ext4   73G  5.0G   65G   8% /home
/dev/sda5  ext4  920M  232M  625M  28% /boot
tmpfs  tmpfs 396M 0  396M   0% /run/user/0
/dev/sdd1  vfat  7.5G  366M  7.2G   5% /root/corsair

df -i
Filesystem   Inodes  IUsedIFree IUse% Mounted on
udev 502193490   5017031% /dev
tmpfs506243848   5053951% /run
/dev/sda1122160  15831   106329   13% /
/dev/sda8   1831424 311408  1520016   18% /usr
tmpfs506243  1   5062421% /dev/shm
tmpfs506243  4   5062391% /run/lock
tmpfs506243 16   5062271% /sys/fs/cgroup
/dev/sdc1  61054976  13288 610416881% /mnt/data2
/dev/sdb1  14184328   6185 141781431% /mnt/data
/dev/sda10  1831424797  18306271% /opt
/dev/sda7122160 28   1221321% /tmp
/dev/sda9   1220608  18510  12020982% /var
/dev/sda3   4890624  68947  48216772% /home
/dev/sda5 61056392606641% /boot
tmpfs506243 11   5062321% /run/user/0
/dev/sdd1 0  00 - /root/corsair

du -h -d 1
2.7G ./opt
417M ./root
6.5G ./var
0 ./sys
16K ./lost+found
16M ./etc
7.5M ./run
12K ./media
4.0K ./lib64
5.0G ./home
7.2G ./usr
13M ./sbin
12M ./bin
68K ./tmp
564M ./lib
868G ./mnt
6.1M ./lib32
4.0K ./srv
232M ./boot
0 ./dev
4.0K ./.cache
0 ./proc
890G .

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

Et dans l'affirmative, que faut-il faire ensuite?
Je n'en ai pas la moindre idée et je ne voudrai pas exécuter de commande
qui pourrait faire empirer le probleme.

Très cordialement
Hugues


Le lun. 12 févr. 2024 à 13:22, Michel Verdier  a écrit :

> Le 12 février 2024 Hugues MORIN-TRENEULE a écrit :
>
> > J'ai effectivement vu ce message mais je n'en avais pas compris la
> raison.
> > Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et
> > /boot son bien "chargées".
> > Est ce que le problème pourrait provenir de la?
>
> Le message repéré par Alban porte sur /lib donc ton /
> qui n'a que 127Mo de libre. La taille des modules varie selon les
> kernels. Chez moi ça prend dans les 80Mo. Et il faut compter des fichiers
> temporaires pendant l'installation. Déjà fais peut-être le ménage dans
> les kernels que tu n'utilise pas, ton /boot semble pas mal rempli. Ce
> n'est pas gênant pour /boot qui a de la marge mais ça libérera aussi de
> la place sur /
>
> > /dev/sda1  ext4  1.8G  1.6G  127M  93% /
> > /dev/sda8  ext4   28G  7.2G   19G  28% /usr
> > /dev/sda10 ext4   28G  2.7G   24G  11% /opt
> > /dev/sda7  ext4  1.8G   72K  1.7G   1% /tmp
> > /dev/sda9  ext4   19G  6.5G   11G  38% /var
> > /dev/sda3  ext4   73G  5.0G   65G   8% /home
> > /dev/sda5  ext4  920M  379M  478M  45% /boot
>
> Pourquoi avoir découpé sda en autant de partitions ? Ca n'augmente pas la
> sécurité et tu perds plein de place sur certaines alors que d'autres
> saturent.
>
>

Re: Debian bookworm: reboot required

[Dan Ritter]

Klaus Singvogel wrote: 
> I'm not searching for kind of notifier, instead I want to lookup the reboot 
> by my own (shell) script, like via existance of a file.
> 
> I'll install unattended-upgrades now, and will see, if it helps at next 
> kernel installation.


I will note that while unattended-upgrades can be quite useful,
most individual users and small installations -- in my
experience -- prefer the default policy of apticron, which is to
download upgraded packages and send a mail notification, rather
than to install them automatically.

-dsr-

Re: Debian bookworm: reboot required

[Klaus Singvogel]

Hi Andy,

thanks for your helpful response.

Andy Smith wrote:
> On Mon, Feb 12, 2024 at 11:49:18AM +0100, Klaus Singvogel wrote:
> These files are created by the postinst script of individual Debian
> packages. See for example the output of:
> 
> $ grep reboot-required /var/lib/dpkg/info/*

On my Debian Bullseye machine, where I got also a new kernel, I see this:

# grep -l reboot-required /var/lib/dpkg/info/*
/var/lib/dpkg/info/dbus.postinst
/var/lib/dpkg/info/evolution-data-server.postinst
/var/lib/dpkg/info/gnome-shell.postinst

→ no kernel package.

But on this machine the content of reboot-required.pkgs is today (after I got a 
new kernel):

# cat /var/run/reboot-required.pkgs 
linux-image-5.10.0-28-amd64

So I doubt, that the file is only (!) created by /var/lib/dpkg/info/*, as the 
grep lacks of this output: linux-image.postinst

[...]
> None of my kernel-related packages have a postinst that creates
> these files, so I'm not sure that installing a kernel package has
> ever done that.

Agreed.

> I think if you install the unattended-upgrades package it will
> create those files after a kernel upgrade. I do not use that, which
> is why I see nothing cresting those files. Perhaps you have that
> installed elsewhere but not on this machine.

Yes! This was a good pointer. Indeed the unattended-upgrades was installed on 
my Bullseye host, but not on my Bookworm host.

> Are you thinking of update-notifier-common which used to be installed
> by default but was removed entirely in Debian jessie? An approximate
> replacement for this is the package "reboot-notifier".

I'm not searching for kind of notifier, instead I want to lookup the reboot by 
my own (shell) script, like via existance of a file.

I'll install unattended-upgrades now, and will see, if it helps at next kernel 
installation.

Thanks for your help. Great job.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: Debian bookworm: reboot required

[Andy Smith]

Hi,

On Mon, Feb 12, 2024 at 11:49:18AM +0100, Klaus Singvogel wrote:
> in the past Debian Distributions there were two files in the system, when a 
> reboot was necessary:
>   /run/reboot-required  /run/reboot-required.pkgs

These files are created by the postinst script of individual Debian
packages. See for example the output of:

$ grep reboot-required /var/lib/dpkg/info/*

> I installed today a new kernel under Debian Bookworm, which
> requires a reboot, but this system lacks of both files. They
> aren't present.

None of my kernel-related packages have a postinst that creates
these files, so I'm not sure that installing a kernel package has
ever done that.

I think if you install the unattended-upgrades package it will
create those files after a kernel upgrade. I do not use that, which
is why I see nothing cresting those files. Perhaps you have that
installed elsewhere but not on this machine.

> How can I find out, if there is a system reboot necessary, in a
> similar way, as it was possible in the past?

Are you thinking of update-notifier-common which used to be installed
by default but was removed entirely in Debian jessie? An approximate
replacement for this is the package "reboot-notifier".

On the same theme there is also "needrestart" which will tell you
which daemons need to be restarted after libraries have been
upgraded.

Thanks,
Andy

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

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

[Thomas Schmitt]

Hi,

John Boxall wrote:
>   Setting up grub-pc (2.06-3~deb11u6) ...
>   /dev/disk/by-id/ata-WDC_WDS100T2B0A-00SM50_21185R801540 does not
> exist, so cannot grub-install to it!
> What is confusing to me is that the error indicates the source SDD even
> though I have updated the boot images and installed grub on the cloned HDD.

The disk/by-id file names are made up from hardware properties.
I believe to see in the name at least: Manufacturer, Model, Serial Number.

So you will have to find the configuration file which knows that
/dev/disk/by-id address and change it either to the new hardware id or
to a /dev/disk/by-uuid address, which refers to the cloned disk content.


Have a nice day :)

Thomas

grub-pc error when upgrading from buster to bullseye

[John Boxall]

I am attempting to upgrade my laptop (Thinkpad X230) from buster to 
bullseye and have run into the error below. In order to ensure that all 
goes well and not to lose all of the tweaks I have added over time, I am 
performing the upgrade first on a cloned HDD (via "dd") of the working SDD.


apt-get -y upgrade --without-new-pkgs

Setting up grub-pc (2.06-3~deb11u6) ...
/dev/disk/by-id/ata-WDC_WDS100T2B0A-00SM50_21185R801540 does not
  exist, so cannot grub-install to it!
You must correct your GRUB install devices before proceeding:

DEBIAN_FRONTEND=dialog dpkg --configure grub-pc
dpkg --configure -a
dpkg: error processing package grub-pc (--configure):
installed grub-pc package post-installation script subprocess
 returned error exit status 1


All of the latest updates for buster have been applied before starting 
the process (below).


apt-get update;apt-get -y upgrade;apt-get -y dist-upgrade;

#shutdown, boot Debian live

#clone working SSD drive to an HDD  

#boot cloned drive

#login and open terminal session

#su to root

update-initramfs -u -k all

grub-install --recheck /dev/sda

apt-get update;apt-get -y upgrade;apt-get -y dist-upgrade;

#modify /etc/apt/source.list to point to bullseye
#modify all /etc/apt/source.list.d/* files to point to bullseye

apt-get update;apt-get -y upgrade --without-new-pkgs;

Running the recommended dpkg commands brings up the dialog to install 
grub and does complete successfully so that I can then run

"apt-get -y dist-upgrade", which also runs successfully.

What is confusing to me is that the error indicates the source SDD even 
though I have updated the boot images and installed grub on the cloned HDD.


Is there some other configuration file that needs to be updated/removed 
so that the grub-pc install works without intervention?


Source system info:

user:~$ uname -a
Linux laptop 4.19.0-26-amd64 #1 SMP Debian 4.19.304-1 (2024-01-09) 
x86_64 GNU/Linux


user:~$ cat /etc/debian_version
10.13

user:~$ lscpu
Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Address sizes:   36 bits physical, 48 bits virtual
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  2
Core(s) per socket:  2
Socket(s):   1
NUMA node(s):1
Vendor ID:   GenuineIntel
CPU family:  6
Model:   58
Model name:  Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
Stepping:9
CPU MHz: 1202.696
CPU max MHz: 3600.
CPU min MHz: 1200.
BogoMIPS:5786.44
Virtualization:  VT-x
L1d cache:   32K
L1i cache:   32K
L2 cache:256K
L3 cache:4096K
NUMA node0 CPU(s):   0-3
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl 
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor 
ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic 
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault 
epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid 
fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d



--
Regards,

John Boxall

Re: Erreur suite à un apt upgrade noyau 6.6.18

[Michel Verdier]

Le 12 février 2024 ajh-valmer a écrit :

> Encore un qui n'a pas lu mon mail sans chercher plus loin que le bout 
> de ses yeux :
>> xrandr --addmode VGA 1280x1024_60.00
>> xrandr --output VGA-0 --mode 1280x1024_60.00 :
> Réponse :
> xrandr: Failed to get size of gamma for output default
> xrandr: cannot find output "VGA"

Oui mais as-tu fais aussi et auparavant la commande xrandr *--newmode*
indiquée par Bernard ?

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

[Michel Verdier]

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

> J'ai effectivement vu ce message mais je n'en avais pas compris la raison.
> Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et
> /boot son bien "chargées".
> Est ce que le problème pourrait provenir de la?

Le message repéré par Alban porte sur /lib donc ton /
qui n'a que 127Mo de libre. La taille des modules varie selon les
kernels. Chez moi ça prend dans les 80Mo. Et il faut compter des fichiers
temporaires pendant l'installation. Déjà fais peut-être le ménage dans
les kernels que tu n'utilise pas, ton /boot semble pas mal rempli. Ce
n'est pas gênant pour /boot qui a de la marge mais ça libérera aussi de
la place sur /

> /dev/sda1  ext4  1.8G  1.6G  127M  93% /
> /dev/sda8  ext4   28G  7.2G   19G  28% /usr
> /dev/sda10 ext4   28G  2.7G   24G  11% /opt
> /dev/sda7  ext4  1.8G   72K  1.7G   1% /tmp
> /dev/sda9  ext4   19G  6.5G   11G  38% /var
> /dev/sda3  ext4   73G  5.0G   65G   8% /home
> /dev/sda5  ext4  920M  379M  478M  45% /boot

Pourquoi avoir découpé sda en autant de partitions ? Ca n'augmente pas la
sécurité et tu perds plein de place sur certaines alors que d'autres
saturent.

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

[Hugues MORIN-TRENEULE]

Bonjour


J'ai effectivement vu ce message mais je n'en avais pas compris la raison.
Néanmoins, au vue de df -TPh, je m’aperçois que ma partition racine et
/boot son bien "chargées".
Est ce que le problème pourrait provenir de la?

Voila le résultat des commandes demandées:

df -TPh
Filesystem Type  Size  Used Avail Use% Mounted on
udev   devtmpfs  2.0G 0  2.0G   0% /dev
tmpfs  tmpfs 396M  7.5M  389M   2% /run
/dev/sda1  ext4  1.8G  1.6G  127M  93% /
/dev/sda8  ext4   28G  7.2G   19G  28% /usr
tmpfs  tmpfs 2.0G 0  2.0G   0% /dev/shm
tmpfs  tmpfs 5.0M  4.0K  5.0M   1% /run/lock
tmpfs  tmpfs 2.0G 0  2.0G   0% /sys/fs/cgroup
/dev/sdc1  ext4  916G  583G  287G  68% /mnt/data2
/dev/sdb1  fuseblk   299G  285G   14G  96% /mnt/data
/dev/sda10 ext4   28G  2.7G   24G  11% /opt
/dev/sda7  ext4  1.8G   72K  1.7G   1% /tmp
/dev/sda9  ext4   19G  6.5G   11G  38% /var
/dev/sda3  ext4   73G  5.0G   65G   8% /home
/dev/sda5  ext4  920M  379M  478M  45% /boot
tmpfs  tmpfs 396M 0  396M   0% /run/user/0

df -i
Filesystem   Inodes  IUsedIFree IUse% Mounted on
udev 502193473   5017201% /dev
tmpfs506243823   5054201% /run
/dev/sda1122160  3689185269   31% /
/dev/sda8   1831424 311408  1520016   18% /usr
tmpfs506243  1   5062421% /dev/shm
tmpfs506243  4   5062391% /run/lock
tmpfs506243 16   5062271% /sys/fs/cgroup
/dev/sdc1  61054976  13288 610416881% /mnt/data2
/dev/sdb1  14184328   6185 141781431% /mnt/data
/dev/sda10  1831424797  18306271% /opt
/dev/sda7122160 28   1221321% /tmp
/dev/sda9   1220608  18509  12020992% /var
/dev/sda3   4890624  68947  48216772% /home
/dev/sda5 61056412606441% /boot
tmpfs506243 11   5062321% /run/user/0



Très cordialement
Hugues


Le lun. 12 févr. 2024 à 08:19, Alban Vidal  a
écrit :

> Bonjour Hugues,
>
> Dans les logs il ressort le message "failed to write (No space left on
> device)" qui signifie qu'il n'y a plus d'espace libre.
>
> Peux-tu nous transmettre le retour des commandes suivantes :
> df -TPh
> df -i
>
> Cordialement,
> Alban
>
>
> Le 12 février 2024 08:00:00 GMT+01:00, Hugues MORIN-TRENEULE <
> mor...@gmail.com> a écrit :
>
>> Bonjour a tous
>>
>>
>> Je reviens vers vous car je ne sais pas comment m'y prendre pour réparer
>> un crash lors d'un apt full-upgrade lors d'un passage de Stretch a Bullseye.
>>
>> Il y a quelques temps vos conseils et explications mon permis de de
>> mettre a jours mon Stretch afin de le préparer à l'upgrade vers Bullseye
>> (cf "Mise à jours et Update Stretch - Problème de dépôt" sur la liste =>
>> https://lists.debian.org/debian-user-french/2023/08/msg00289.html)
>>
>> En résumé, j'ai oublié de faire l'upgrade de mon stretch en temps et en
>> heure. Quand j'ai voulu le faire, les dépôts de mon sources.list n'étaient
>> plus valide. Votre aide m'a permis d'avoir les bons dépôts et de mettre a
>> jours mon Stretch à sa dernière version avant de lancer l'upgrade.
>> Jusque là aucun probleme.
>>
>> Une fois a jour, j'ai lancé la procédure d'upgrade de Stretch à Bullseye
>> en suivant pas à pas la procedure decrite par debian.org:
>>
>> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.fr.html
>>
>> Tout s'est bien passé jusqu'au apt full-upgrade (paragraphe 4.4.6).
>> J'ai fait les contrôles demandés, fait les sauvegardes.
>> J'ai utilisé a plusieurs reprises les procédures d'upgrade de debian.org
>> sans jamais rencontrer de probleme, c'est la 1ere fois que j'ai un crash
>> lors de celle-ci et je ne sais pas trop que faire car je ne maitrise pas du
>> tout le sujet.
>> J'ai bien entendu tenté de faire quelques recherches mais cela ne m'a
>> conduit a rien de concluant, soit ça n'a rien à voir, soit je ne comprends
>> pas ce que je lis...
>>
>> Le probleme est survenu à environ 45% de l'installation.
>> Voila le dernier message en console:
>> [...]
>> Selecting previously unselected package libnss-systemd:amd64.
>> Preparing to unpack .../345-libnss-systemd_241-7~deb10u10_amd64.deb ...
>> Unpacking libnss-systemd:amd64 (241-7~deb10u10) ...
>> Errors were encountered while processing:
>>
>>  
>> /tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>>
>>
>> J'ai trouvé 2 messages d'erreurs avant le crash définitif:
>>
>> [...]
>> Selecting previously unselected package linux-image-4.19.0-25-amd64.
>> Preparing to unpack
>> .../261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb ...
>> Unpacking linux-image-4.19.0-25-amd64 (4.19.289-2) ...
>> dpkg: error processing archive
>> /tmp/apt-dpkg-install-H5Vafy/261-linux-image-4.19.0-25-amd64_4.19.289-2_amd64.deb
>> (--unpack):
>> 

Debian bookworm: reboot required

[Klaus Singvogel]

Hello,

in the past Debian Distributions there were two files in the system, when a 
reboot was necessary:
/run/reboot-required  /run/reboot-required.pkgs

I installed today a new kernel under Debian Bookworm, which requires a reboot, 
but this system lacks of both files. They aren't present.

How can I find out, if there is a system reboot necessary, in a similar way, as 
it was possible in the past?

Thanks in advance.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: [ SOLUCIONADO][ Era (Sin título)] Compartir archivos con Samba

[Julián Daich]

El 12/2/24 a las 8:02, Julián Daich escribió:




Haciendo smsbpasswd -a logro entrar usando smb://usuario@IP_equipo, la 
opción n la estuvo ignorando. Entra solo al directorio personal en forma 
lectura, lo que es bastante peligroso. 


Comenté la entrada de [homes] en /etc/samba.smb.conf y ya no ocurre.

- Samba está usando la configuración de /etc/samba/smb.conf, pero ignora 
la de /etc/samba.smb.conf


Edité todo en /etc/samba.smb.conf y ahora funciona bien. El archivo 
/etc/samba/smb.conf resultó ser un error que copié de una guía en Internet



Saludos,

Julián

--
Julian Daich 

Re: Problema puerto usb-c

[Camaleón]

Lo mando a la lista.


El 2024-02-11 a las 20:13 +0100, JA CM escribió:

> Gracias por la ayuda camaleón, te contesto a las cuestiones que me planteas
> y te comento  otras:
> Es la única versión de Kernel que tengo 6.1.0-17-amd64, estoy pendiente
> de actualizar a la 6.1.0-17-amd64 pero por algún error de configuración no
> lo hace directamente. Tengo que mirarlo pero eso es otro cantar.

Hum... no sé por qué yo tengo 3 versiones guardadas:

root@noc11:~# dpkg -l | grep -i image
ii  linux-base   4.9 all
  Linux image base package
ii  linux-image-6.1.0-15-amd64   6.1.66-1amd64  
  Linux 6.1 for 64-bit PCs (signed)
ii  linux-image-6.1.0-17-amd64   6.1.69-1amd64  
  Linux 6.1 for 64-bit PCs (signed)
ii  linux-image-6.1.0-18-amd64   6.1.76-1amd64  
  Linux 6.1 for 64-bit PCs (signed)
ii  linux-image-amd646.1.76-1amd64  
  Linux for 64-bit PCs (meta-package)

¿Has instalado el sistema hace poco? :-?

> No tengo adaptador usb-c a usb 3.0 convencional, mañana me acercaré a
> una tienda de informática local a por uno.

Merece la pena que tengas uno, pero comprueba antes que el chipset del 
adaptador sea compatible con linux, no vaya a ser que añadamos otro 
problema :-)

> No he podido conectar otro dispositivo porque no tengo ninguno con esa
> salida. Lo que sé es que el puerto funciona, porque en Windows sí que
> trabaja.

Si funcionaba la cámara en linux, el puerto funciona. Seguramente se 
deba a un problema con el controlador de linux para USB-C (el kernel, 
en este caso).

> ___
> *usb 6-1 current rate 16000 is different from the runtime rate 48000*.
> Por lo que he buscado al respecto esto está relacionado con la frecuencia
> del sonido de la cámara.
> -
> *xhci_hcd :03:00.0: ERROR Transfer event TRB DMA ptr not part of
> current TD ep_index 2 comp_code 13*
> También está relacionado con la tarjeta de sonido, buscando en internet lo
> explicaban y me hizo darme cuenta que el :03:00.0 me indicaba la
> tarjeta de sonido que tengo que es la STRIX RAID DLX de ASUS como puede
> verse en la captura de la salida lsUSB
> -
> En cuanto a los enlaces que me das, te lo agradezco. Los había visto en las
> búsquedas y seguidos pero no me han conducido a la solución. No obstante
> muchas gracias.
> Añado un enlace más a pastebin con la salida de usb-devices donde se puede
> ver el driver usado por cada uno de los puertos..
> https://pastebin.com/gbxai0rs

Por lo que he leído en los foros, parece un problema generalizado con 
el puerto USB-C y el modelo de cámara web.

Saludos, 

-- 
Camaleón