Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[elvis]

Old ways die hard, disk space is cheap! these days

On 10/5/20 1:53 pm, The Wanderer wrote:

On 2020-05-09 at 23:36, Andy Smith wrote:


Hi Rick,

On Sat, May 09, 2020 at 08:05:48PM -0700, Rick Thomas wrote:

What's the best way to increase the size of /boot ?

There is no easy way. If you boot into a live/rescue environment and
run parted you *may* be able to shrink your LVM and grow your /boot
but it's a procedure fraught with danger; make sure you have
excellent backups first.

I am not 100% sure that parted can handle partitions that are used as
LVM PVs.


I can easily create a gig or so of space by a shrink/resize of
/home, but how do I add that space to /dev/sda2 ?

This won't work because your /home is an LVM logical volume. Its
actual extents could be all over sda3.


I can't just move up the end of /dev/sda2 = start of /dev/sda3
without backing up and restoring, can I?

parted can move partitions about, so if you run it from outside your
install and it does support LVM PV then it might work. You'd
basically have to shift everything up the disk, making your PV (sda3)
slightly smaller in the process.

I really wouldn't like to try it myself. With the backup that you'll
need you may as well just reinstall as even if parted can do this it
will take some time for it to rewrite all that data.

In theory I *think* it should be possible to shrink /home, shrink the
LV, shrink the PV, then expand /boot - but the practice may be quite
different from the theory.

https://unix.stackexchange.com/questions/479545/how-to-shrink-a-physical-volume
has detailed instructions on how to do one part of the process, and
indicates that gparted can indeed handle LVM PVs - but whether it's
suitable for the actual scenario at hand here probably depends on how
you've got your PVs and LVs set up, and I don't know enough about that
to make a recommendation, aside from being very careful with backups no
matter what.

(I'm also up late, so don't necessarily trust me to have things right at
the moment; double-check before going ahead, and if in doubt, don't.)


This is a great example of why it's not good to be stingy with the
size of /boot.

Definitely. My current system started out with around 4-8 TB of usable
space (across all partitions, after RAID overhead) when I first built
it, and I have fully 22GB allocated to /boot. That's ridiculous overkill
- even 1GB would probably have been more than I'm likely to ever need
here, and 2GB would definitely have - but I'd far rather have erred on
the side of too much than too little.



And yet your 22GB hasn't cracked the $1 mark on a cost effective drive.







--
All that glitters has a high refractive index.

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[elvis]

On 11/5/20 8:53 am, Rick Thomas wrote:


On Sun, May 10, 2020, at 12:30 PM, David Christensen wrote:


As for using GRML, I have never heard of it.  The Debian Installer can
get the job done.

GRML [1]  says: "Grml is a bootable live system (Live-CD) based on Debian. Grml 
includes a collection of GNU/Linux software especially for system administrators. Users 
don't have to install anything on fixed storage. Grml is especially well suited for 
administrative tasks like installation, deployment and system rescue. Read more..."

There's also Debian Live, which also has all the features I'll need to do a 
full backup, repartition, and restore.  The installer in rescue mode is more 
limited than either of these alternatives.



Buy a cheap SSD and put boot and root on that. A WD green 120GB cost $39 
AUD.






Rick

[1] http://grml.org


--
Nuclear weapons can wipe out life on Earth, if used properly

Re: Le seul livre disponible en français sur le site de Debian est un livre sur Debian 8

[Marc Chantreux]

salut,

> Le message ci-dessous est-il sérieux?

pourquoi ne le serait-t'il pas?

> Que vaut le bouquin dont il fait état?

le cahier de l'admin a été une référence francophone
pendant longtemps. je me souviens que mes élèves
l'achetaient spontanément.

l'auteur a fondé Freexian qui est entre autre en charge
du programme LTS.

http://www.freexian.com/services/debian-lts.html

il n'a probablement plus trop de temps pour son bonquin.

cordialement,
marc

Re: Le seul livre disponible en français sur le site de Debian est un livre sur Debian 8

[TScholler]

Bonjour à toutes et tous
Le message ci-dessous est-il sérieux?
Que vaut le bouquin dont il fait état?
Quelqu'un-e pourrait-il-elle en donner un avis?
D'avance merci.
Bon dé-confinement à celles et ceux qui sont concerné-es,
Courage et patience aux autres
TS


Le 23/03/2020 à 08:56, Hamdy Abou El Anein a écrit :

Bonjour,

Le seul livre disponible sur le site de Debian est sur Debian 8.

https://www.debian.org/doc/books.fr.html#french

Je vous propose de le remplacer par cet ouvrage : Le guide complet de 
Linux Debian 10 Buster.


https://medium.com/@hamdyabouelanein/le-guide-complet-de-linux-debian-10-buster-ee5994d1a01e

Meilleures salutations.

*Hamdy Abou El Anein*
Founder / Linux system engineer
Daylightlinux.ch

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Tom Dial]

On 5/10/20 03:07, Rick Thomas wrote:
> On Sun, May 10, 2020, at 1:17 AM, David Christensen wrote:
>> On 2020-05-09 22:05, Will Mengarini wrote:
>>> * Rick Thomas  [20-05/09=Sa 20:05 -0700]:
 What's the best way to increase the size of /boot?
>>> By creating a reliable backup and reformatting the disk to
>>> the new format.  I've never found it to be cost-effective
>>> to try anything else. 
>> +1

As Charles Curley suggested, 248M usually is enough to hold a reasonable
number of kernels, configs, and initrd files, along with the contents of
/boot/grub. It might be worthwhile to examine it for extraneous files.

But if /boot turns out to need more space, you could unmount /dev/sda1
and /dev/sda2, remount /dev/sda2 on (for example) /mnt, move its
contents to /boot, remount /dev/sda1, and reinstall grub.

After finishing, you could make an LVM physical volume on /dev/sda2 and
add it to one of the other volume groups, although both seem to have
plenty of space.

Regards
Tom Dial

> 
> Yeah, that's probably what I'll do.  Fortunately, it's an amd64 machine, so 
> I'll be able to use GRML to do the work.
> Enjoy!
> Rick
> 

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Rick Thomas]

On Sun, May 10, 2020, at 12:30 PM, David Christensen wrote:

> As for using GRML, I have never heard of it.  The Debian Installer can 
> get the job done.  

GRML [1]  says: "Grml is a bootable live system (Live-CD) based on Debian. Grml 
includes a collection of GNU/Linux software especially for system 
administrators. Users don't have to install anything on fixed storage. Grml is 
especially well suited for administrative tasks like installation, deployment 
and system rescue. Read more..."

There's also Debian Live, which also has all the features I'll need to do a 
full backup, repartition, and restore.  The installer in rescue mode is more 
limited than either of these alternatives.

Rick

[1] http://grml.org

Re: Booter sur un adaptateur M.2 PCI-e x4 et éclaircicement sur initrd

[benoit]

Bonjour,
Merci pour votre réponse,

‐‐‐ Original Message ‐‐‐
Le dimanche 10 mai 2020 12:34, Basile Starynkevitch  
a écrit :

> Pour moi, il s'agit de configurer GRUB et probablement le BIOS ou UEFI de la 
> carte mère.
>
> Quand initrd démarre, le noyau est déjà chargé, et initrd s'occupe des 
> modules du noyau.
>
> Personnellement je suggère plutôt un petit disque SSD avec interface SATA. Ca 
> doit pas coûter plus cher que l'adaptateur.

En effet si le plus rapide des SSD sur sata 3 peut écrire jusqu'à 540 Mo/s je 
ne suis pas sûr d'être gagnant avec un «disque» NVMe écrivant à 600 Mo/s (pour 
les plus lents du marché).

Mais des «disques» NVMe plus rapide sur PCI 3.0 écrivent à 2300 Mo/s.

Comme le Samsung SSD 970 EVO NVMe M.2 250 Go pour plus ou moins 100 €

https://www.ldlc.com/fr-be/fiche/PB00265389.html

https://www.samsung.com/fr/memory-storage/970-evo-nvme-m2-ssd/MZ-V7E250BW/

Même sans viser un tel budget pour atteindre les 2300 Mo/s, si je trouve ça 
d'occase, un «disque» NVMe ne deviendrait-il pas plus intéressant afin décupler 
la vitesse d'écriture pour un budget raisonnable par rapport à des SSD sur SATA 
3 ?

À condition de trouver du matos d'occase (qui nécessitera peut-être un 
adaptateur a $16)…

Quant à ma motivation de ce bidouillage DIY, c'est d'éviter de consommer du 
matos neuf sachant ce que ça implique (écologie, droits du travail là ou c'est 
extrait puis fabriqué), même si je complique un peu les choses. Mais faut aussi 
que ça fonctionne ! ;-)

D'où ma question sur la possibilité de booter sur un tel adaptateur sur slot 
PCI (est-ce que l’UEFI va le détecter?) et si pas, comment contourner le 
problème lors de l'installation de l'OS ?

Merci d'avance.

--

Benoit

Re: Why do I have so many packages to upgrade with Debian 10.4?

[Liam O'Toole]

On Sun, 10 May, 2020 at 22:03:20 +0200, l0f...@tuta.io wrote:
> Hi,
> 
> My /etc/apt/sources.list contains links to buster, buster/updates, 
> buster-updates and buster-backports repositories. I run apt update / apt 
> upgrade very frequently.
> 
> As you may know, Debian 10.4 was out yesterday.
> Now, apt list --upgradable shows me 90+ packages to be upgraded.
> 
> I thought there would be  a lot less to upgrade because I would  have 
> upgraded the most part already thanks to my repositories (especially 
> buster/updates and buster-updates). Maybe it's the case because I don't know 
> the total number of upgrades provided with 10.4 but I still don't understand 
> why I have so many ones.
> Could someone explain that to me please?
> 
> Thank you in advance :)
> Best regards,
> l0f4r0
> 

The release notes[1] mention lots of updates in the section
"Miscellaneous Bugfixes". Those will account for most of the upgrades
you are seeing now.  Assuming you've been updating regularly, most or
all of the updates in the section "Security Updates" will not apply.

1: https://www.debian.org/News/2020/20200509

Re: [SOLUCIONADO] Pasar o recoger salida de comandos a variables.

[Daniel Cialdella Converti]

Quizás les sirva.
Dejo los links. Disculpen los errores cometidos, estoy todavía aprendiendo
como hacer estos videos.


Intro
https://www.youtube.com/watch?v=xcHXF7_JDfo

Uso diario de Xubuntu
https://www.youtube.com/watch?v=MAAGjY6rONQ

On Sun, May 10, 2020 at 11:48 PM Suso Gonzalez  wrote:

> UNSUSCRIBE
>
> Obtener Outlook para Android 
>
> --
> *From:* Ramses 
> *Sent:* Sunday, May 10, 2020 11:33:36 AM
> *To:* Lista-Debian 
> *Subject:* Re: [SOLUCIONADO] Pasar o recoger salida de comandos a
> variables.
>
> El 10 de mayo de 2020 10:04:36 CEST, Ramses 
> escribió:
> >Buenos días,
> >
> >Cuando he necesito recoger la salida de un comando para después
> >tratarla, lo he hago siempre así:
> >
> ># PRUEBA=$(ls -la)
> >
> >No me muestra la salida por Consola pero con un "echo $PRUEBA" imprimo
> >el contenido.
> >
> >Pero me he he encontrado con una curiosidad con NetCat.
> >
> >Si hago un:
> >
> ># PRUEBA=$(nc -z -v -w5 80.80.80.80 22)
> >
> >Me muestra la salida por Consola y si hago un "echo $PRUEBA" me muestra
> >la variable vacía.
> >
> >¿Sabe alguien por qué ocurre esto con NetCat y cómo tendría que hacerlo
> >para recoger la salida en una variable?
> >
> >
> >Saludos y gracias,
> >
> >Ramsés
>
> Buenas, me respondo yo mismo.
>
> Se ve que NetCat está sacando la salida por STDERR en vez de por STDOUT,
> por lo que se puede solucionar así:
>
> # PRUEBA=$(nc -z -v -w5 80.80.80.80 22 2 >&1)
>
>
> Saludos,
>
> Ramsés
>
>

-- 

   \\- -//
   ( @ @ )
oOOo-(_)-oOOo?
??
? From my TI 99 4/a - a bit delayed  ?
? During delivery no animals harmed  ?
??
? Linkedin / URL / DEBIAN / BLOG ?
??
? https://www.youtube.com/user/dcialdella
? https://es.linkedin.com/in/dcialdella
  ?
? https://dockertips.com 
   ?
? https://itprofesionales.blogspot.com    ?
? https://www.debian.org/consultants/#ES ?
??
oOOo-(_)-oOOo?
??oOoOoOoOo???
   Changed 2017-07.

Re: [SOLUCIONADO] Pasar o recoger salida de comandos a variables.

[Suso Gonzalez]

UNSUSCRIBE

Obtener Outlook para Android


From: Ramses 
Sent: Sunday, May 10, 2020 11:33:36 AM
To: Lista-Debian 
Subject: Re: [SOLUCIONADO] Pasar o recoger salida de comandos a variables.

El 10 de mayo de 2020 10:04:36 CEST, Ramses  escribió:
>Buenos días,
>
>Cuando he necesito recoger la salida de un comando para después
>tratarla, lo he hago siempre así:
>
># PRUEBA=$(ls -la)
>
>No me muestra la salida por Consola pero con un "echo $PRUEBA" imprimo
>el contenido.
>
>Pero me he he encontrado con una curiosidad con NetCat.
>
>Si hago un:
>
># PRUEBA=$(nc -z -v -w5 80.80.80.80 22)
>
>Me muestra la salida por Consola y si hago un "echo $PRUEBA" me muestra
>la variable vacía.
>
>¿Sabe alguien por qué ocurre esto con NetCat y cómo tendría que hacerlo
>para recoger la salida en una variable?
>
>
>Saludos y gracias,
>
>Ramsés

Buenas, me respondo yo mismo.

Se ve que NetCat está sacando la salida por STDERR en vez de por STDOUT, por lo 
que se puede solucionar así:

# PRUEBA=$(nc -z -v -w5 80.80.80.80 22 2 >&1)


Saludos,

Ramsés

Re: Pasar o recoger salida de comandos a variables.

[Suso Gonzalez]

UNSUSCRIBE

Obtener Outlook para Android


From: Ramses 
Sent: Sunday, May 10, 2020 10:04:36 AM
To: Lista-Debian 
Subject: Pasar o recoger salida de comandos a variables.

Buenos días,

Cuando he necesito recoger la salida de un comando para después tratarla, lo he 
hago siempre así:

# PRUEBA=$(ls -la)

No me muestra la salida por Consola pero con un "echo $PRUEBA" imprimo el 
contenido.

Pero me he he encontrado con una curiosidad con NetCat.

Si hago un:

# PRUEBA=$(nc -z -v -w5 80.80.80.80 22)

Me muestra la salida por Consola y si hago un "echo $PRUEBA" me muestra la 
variable vacía.

¿Sabe alguien por qué ocurre esto con NetCat y cómo tendría que hacerlo para 
recoger la salida en una variable?


Saludos y gracias,

Ramsés

Re: Why do I have so many packages to upgrade with Debian 10.4?

[didier gaumet]

Hello,

I am not sure of it but perhaps this is linked to the absence of
proposed-updates in your sources.list:
 https://www.debian.org/releases/proposed-updates

Re: Múltiples cuentas de correo con mutt

[Roberto C . Sánchez]

On Sun, May 10, 2020 at 04:01:37PM -0500, Germán Avendaño Ramírez wrote:
> Cordial saludo
> 
> He intentado configurar mu4e para múltiples cuentas de correo y no he
> podido hallar la manera.
> 
> Pregunto si conocen alguna guía, para usar múltiples cuentas de correo,
> mediante mutt. Gracias
> 
Hola Germán,

No sé si hay alguna guía, pero yo simplemente organizo mis cuentas por
bandejas y entonces uso 'folder-hook' en ~/.muttrc de tal manera:

folder-hook personal set from=...
folder-hook personal set spoolfile=...
folder-hook personal set imap_user=...
folder-hook personal set imap_pass=...
folder-hook personal set smtp_url=...
folder-hook personal set smtp_pass=...
folder-hook trabajo set from=...
folder-hook trabajo set spoolfile=...
folder-hook trabajo set imap_user=...
folder-hook trabajo set imap_pass=...
folder-hook trabajo set smtp_url=...
folder-hook trabajo set smtp_pass=...

Entonces, cuando entro a la bandeja personál mutt queda configurado para
enviar y recibir a través de los servidoers IMAP/SMTP de mi cuenta
personál y cuando entro a la bandeja del trabajo con los servidoers
IMAP/SMTP de mi cuenta del trabajo.  También por haber configurado
«from=...» al redactar un mensaje, mutt lo muestra con la dirección que
corresponde a la cuenta que has asociado con esa bandeja.

Lo demás quizás puedes configurar a lo normal, usando 'folder-hook' para
cualquier cosa que tiene que cambiar cuando cambias de una bandeja a
otra.

Si acaso tienes varias configuraciones y quieres que algo quede en algún
estado por defecto, puedes hacer algo parecido a esto:

folder-hook personal set signature="~/.signature_personal"
folder-hook . set signature="~/.signature"

Eso te configura la firma de ~/.signature_personal cuando entras a la
bandeja personál y de ~/.signature cuando entras a cualquier otra
bandeja.

Saludos,

-Roberto

-- 
Roberto C. Sánchez

Múltiples cuentas de correo con mutt

[Germán Avendaño Ramírez]

Cordial saludo

He intentado configurar mu4e para múltiples cuentas de correo y no he
podido hallar la manera.

Pregunto si conocen alguna guía, para usar múltiples cuentas de correo,
mediante mutt. Gracias

Atentamente,

-- 
Germán Avendaño Ramírez
Lic. Mat. U.D., M.Sc. U.N
Delegado ADE
Canal Telegram https://t.me/ManchoDistritoProfes

Why do I have so many packages to upgrade with Debian 10.4?

[l0f4r0]

Hi,

My /etc/apt/sources.list contains links to buster, buster/updates, 
buster-updates and buster-backports repositories. I run apt update / apt 
upgrade very frequently.

As you may know, Debian 10.4 was out yesterday.
Now, apt list --upgradable shows me 90+ packages to be upgraded.

I thought there would be  a lot less to upgrade because I would  have upgraded 
the most part already thanks to my repositories (especially buster/updates and 
buster-updates). Maybe it's the case because I don't know the total number of 
upgrades provided with 10.4 but I still don't understand why I have so many 
ones.
Could someone explain that to me please?

Thank you in advance :)
Best regards,
l0f4r0

Re: Booter sur un adaptateur M.2 PCI-e x4 et éclaircicement sur initrd

[Étienne Mollier]

benoit, on 2020-05-10 18:38:39 +:
> D'où ma question sur la possibilité de booter sur un tel
> adaptateur sur slot PCI (est-ce que l’UEFI va le détecter?) et
> si pas, comment contourner le problème lors de l'installation
> de l'OS ?

Bonsoir,

Ma station de travail professionnelle démarre sur un NVMe
raccordé via un tel adaptateur.  Toutefois, elle a une carte
mère récente, et peut-être que ça joue sur la compatibilité.

Admettons qu'une carte mère ne prenne pas en charge la détection
de périphériques de stockage raccordés en PCIe/M.2.  Il reste
possible d'installer l'ESP (ou le secteur d'amorçage) sur une
petite clé USB, dont le démarrage devrait être pris nativement
en charge par les cartes mères depuis bien quinze ans, si ce
n'est davantage.  Le Grub installé dedans sera normalement
capable d'allers chercher le noyau et l'initrd dans le NVMe.  Il
faudra juste penser à laisser la clé branchée pour le démarrage
et les mises à jour de Grub.  Ça fait certes un peu bricolage,
mais ça me parait un peu plus économique que le SSD raccordé en
SATA, et ce quelle que soit la devise considérée : Joule, Euro,
dioxide de carbone, etc.

Bonne soirée,
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/


signature.asc
Description: PGP signature

Re: Wetransfer of alternatief om bestanden via terminal te versturen.

[Geert Stappers]

On Sun, May 10, 2020 at 08:37:30PM +0200, Koen Wybo wrote:
> Dag iedereen,
> 
> 
> Er zijn verschillende online diensten zoals wetransfer.com die je toelaten
> om bestanden met elkaar te delen. Op de website moet je vervolgens je
> emailadres, ontvanger-email invullen en vervolgens het bestand selecteren.
> Mijn vraag is: hoe kun je dit automatiseren zodat alles vanuit terminal kan
> ingevoerd worden en in een script kan geplaatst worden.
> 
> Dit hoeft niet noodzakelijk met wetransfer te zijn, het kan gerust ook met
> een andere gratis dienst.
> 
> Ik heb reeds het pythonprogramma we-transfer uitgeprobeerd zonder succes.
> 
> Transfer.sh lukt maar genereert op het einde een unieke code om te
> downloaden. Dit vraagt dus extra tussenkomst van de eindgebruiker.
> 
> 
> Alle hulp is welkom.
> 

Ik las in de vraag "wget, maar dan de andere kant op"

En verhip.


$ apt search wput
Bezig met sorteren... Klaar
Volledige tekst doorzoeken... Klaar
wput/stable 0.6.2+git20130413-8 amd64
  tiny wget-like ftp-client for uploading files


Er is ook fiche  8^)


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[David Christensen]

On 2020-05-10 02:07, Rick Thomas wrote:



On Sun, May 10, 2020, at 1:17 AM, David Christensen wrote:

On 2020-05-09 22:05, Will Mengarini wrote:

* Rick Thomas  [20-05/09=Sa 20:05 -0700]:

What's the best way to increase the size of /boot?

By creating a reliable backup and reformatting the disk to
the new format.  I've never found it to be cost-effective
to try anything else.

+1


Yeah, that's probably what I'll do.  Fortunately, it's an amd64 machine, so 
I'll be able to use GRML to do the work.



I advise that you put your operating system on one drive and your data 
on other drives (e.g. RAID file server), and that you keep your system 
drive image small enough to fit on a "16 GB" device -- HDD, SSD, USB 
flash drive, SD card, etc..



As for using GRML, I have never heard of it.  The Debian Installer can 
get the job done.  That said, I have about a half dozen machines and 
have been feeling the need for installation and deployment automation. 
I have heard of Puppet more than once.  Lucas [1] recommends Ansible 
[2], so I will probably try that.



David


[1] https://mwl.io/

[2] https://www.ansible.com/

Re: debsecan does not report a vulnerability?

[Ihor Antonov]

On Sunday, 10 May 2020 08:18:29 PDT Victor Sudakov wrote:
> Have I asked in the wrong list? Which list would be more appropriate?

Hi Victor,

I think this is the right list. But it seems that the message got lost somehow 
in the high volume. I have not used debescan personally, so I am replying 
simply 
to keep this thread alive hoping to get it more visibility
 
> Victor Sudakov wrote:
> > Dear Colleagues,

> > There is something about debsecan I don't understand, can you please
> > clarify for me?
> > 
> > CVE-2020-1967 was fixed in version 1.1.1d-0+deb10u3, I have
> > 1.1.1d-0+deb10u2 installed, but for some reason debsecan does not report
> > the vulnerable package:
> > 
> > # dpkg -l | grep openssl
> > ii  openssl   1.1.1d-0+deb10u2 amd64  
> >  Secure Sockets Layer toolkit - cryptographic utility # debsecan --suite
> > buster | grep CVE-2020-1967
> > #
> > 
> > What am I doing wrong?
> > 
> > I'm familiar with FreeBSD's "pkg audit", maybe I'm misusing debsecan?

---
Ihor Antonov

Wetransfer of alternatief om bestanden via terminal te versturen.

[Koen Wybo]

Dag iedereen,


Er zijn verschillende online diensten zoals wetransfer.com die je 
toelaten om bestanden met elkaar te delen. Op de website moet je 
vervolgens je emailadres, ontvanger-email invullen en vervolgens het 
bestand selecteren. Mijn vraag is: hoe kun je dit automatiseren zodat 
alles vanuit terminal kan ingevoerd worden en in een script kan 
geplaatst worden.


Dit hoeft niet noodzakelijk met wetransfer te zijn, het kan gerust ook 
met een andere gratis dienst.


Ik heb reeds het pythonprogramma we-transfer uitgeprobeerd zonder succes.

Transfer.sh lukt maar genereert op het einde een unieke code om te 
downloaden. Dit vraagt dus extra tussenkomst van de eindgebruiker.



Alle hulp is welkom.


Koen Wybo

Re: stretch -> buster upgrade fails

[Sven Hartge]

Tony van der Hoff  wrote:

> E: Problem executing scripts APT::Update::Post-Invoke-Success 'if 
> /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then 
> appstreamcli refresh-cache > /dev/null; fi'
> E: Sub-process returned an error code

> I don't know where to find a verbose log. Any suggestions as to how tp 
> proceed please?

What happens when you run

 appstreamcli refresh-cache

manually as root?

Grüße,
S!

-- 
Sigmentation fault. Core dumped.

stretch -> buster upgrade fails

[Tony van der Hoff]

hi,

I've just tried to upgrade a workstation on my network from stretch to 
buster. I changed all references to stretch in sources.list to buster,

and ran apt-get upgrade,with the following results:

root@debian-jane:~# apt-get update
Get:1 http://security.debian.org/debian-security buster/updates 
InRelease [65.4 kB]

Get:2 http://ftp.uk.debian.org/debian buster InRelease [121 kB]
Get:3 http://ftp.uk.debian.org/debian buster-updates InRelease [49.3 kB]
Get:4 http://security.debian.org/debian-security buster/updates/main 
amd64 Packages [197 kB]
Get:5 http://security.debian.org/debian-security buster/updates/main 
Translation-en [106 kB]
Get:6 http://security.debian.org/debian-security buster/updates/non-free 
amd64 Packages [552 B]
Get:7 http://security.debian.org/debian-security buster/updates/non-free 
Translation-en [344 B]
Get:8 http://ftp.uk.debian.org/debian buster/main amd64 Packages [7,905 
kB]

Get:9 http://ftp.uk.debian.org/debian buster/main Translation-en [5,969 kB]
Get:10 http://ftp.uk.debian.org/debian buster/main amd64 DEP-11 Metadata 
[3,807 kB]
Get:11 http://ftp.uk.debian.org/debian buster/main DEP-11 64x64 Icons 
[7,596 kB]
Get:12 http://ftp.uk.debian.org/debian buster/main DEP-11 128x128 Icons 
[12.8 MB]
Get:13 http://ftp.uk.debian.org/debian buster/contrib amd64 Packages 
[51.0 kB]
Get:14 http://ftp.uk.debian.org/debian buster/contrib Translation-en 
[44.7 kB]
Get:15 http://ftp.uk.debian.org/debian buster/contrib amd64 DEP-11 
Metadata [11.5 kB]
Get:16 http://ftp.uk.debian.org/debian buster/contrib DEP-11 64x64 Icons 
[110 kB]
Get:17 http://ftp.uk.debian.org/debian buster/contrib DEP-11 128x128 
Icons [226 kB]
Get:18 http://ftp.uk.debian.org/debian buster/non-free amd64 Packages 
[87.7 kB]
Get:19 http://ftp.uk.debian.org/debian buster/non-free Translation-en 
[88.9 kB]
Get:20 http://ftp.uk.debian.org/debian buster/non-free amd64 DEP-11 
Metadata [9,096 B]
Get:21 http://ftp.uk.debian.org/debian buster/non-free DEP-11 64x64 
Icons [38.3 kB]
Get:22 http://ftp.uk.debian.org/debian buster/non-free DEP-11 128x128 
Icons [6,725 B]
Get:23 http://ftp.uk.debian.org/debian buster-updates/main amd64 
Packages [7,380 B]
Get:24 http://ftp.uk.debian.org/debian buster-updates/main 
Translation-en [5,166 B]
Fetched 39.3 MB in 14s (2,792 kB/s) 

The AppStream system cache was updated, but some errors were detected, 
which might lead to missing metadata. Refer to the verbose log for more 
information.

Reading package lists... Done
E: Problem executing scripts APT::Update::Post-Invoke-Success 'if 
/usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then 
appstreamcli refresh-cache > /dev/null; fi'

E: Sub-process returned an error code

I don't know where to find a verbose log. Any suggestions as to how tp 
proceed please?


--
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |

Re: Boot script

[Thomas Schmitt]

Hi,

Jan Wilmans wrote:
> I've created a bootable USB stick that boot debian 10

By which procedure, exactly ?
There are several which produce quite different outcome.


> how can I insert it into the USB sticks read only filesystem?

If you have an ISO 9660 filesystem on the base device of the stick
and did not add new partitions, then you could use multi-session
or re-pack the ISO.

It might become tricky, nevertheless. Consider to install Debian on
a USB stick and to customize it as any other Debian system, rather
than putting an ISO image onto the stick.


That said, multi-session works like this:

  cp debian-10.0.0-amd64-xfce.iso test.iso

  file_or_tree_on_disk=...path...
  path_in_iso=...path...

  xorriso -dev test.iso \
  -map "$file_or_tree_on_disk" "$path_in_iso" \
  -boot_image any replay

(You may work directly on the stick by an address like
  -dev stdio:/dev/sdd
but for first experiments i'd advise a disk file as test object.)

Repacking is discussed on

  https://wiki.debian.org/RepackBootableISO


Have a nice day :)

Thomas

Re: gnome-disk-utility User Session Defaults issue

[David Wright]

On Fri 08 May 2020 at 22:34:30 (-0400), Default User wrote:
> On 2020-05-08, David Wright (deb...@lionunicorn.co.uk) wrote:
> 
> > But I'm surprised: which partitioner did you use, and which installer?
> 
> David, I Originally installed Debian as Stable using the Debian 9
> netinst installer, a day or two before the initial Debian 10 release.
> What timing. I used the partitioner built into the Debian installer.
> I have not changed the partitioning since.  After installation, I
> immediately upgraded to Unstable and have been running Unstable since
> then.

Thanks. I hadn't realised the d-i would do that by default. (I've
never used it to actually partition a disk, but only to allow the
partitioner to rewrite the LABELs and UUIDs when creating the
filesystems etc during installation.)

> > So it would be sensible to change them to something sane. I never
> > stray beyond ASCII alphanumerics, though windows uses _ as well.
> 
> Well, if I must change the labels to "something sane", how about:
> /dev/sda1 as ROOTPART
> /dev/sda2 as [not labeled]
> /dev/sda5 as SWAPPART
> /dev/sda6 as HOMEPART
> 
> > # e2label for partitions 1 and 6,
> > # swaplabel for 5.
> 
> I am not conversant with either e2label or swaplabel.  I will have to
> check those out tomorrow.
> 
> Anyway, are labels even needed anymore?  These days everyone and
> everything wants to use UUID numbers for partitions, to the seeming
> exclusion of all else.

Well, UUIDs are very useful for the installer because it doesn't
have to worry about collisions when it makes up names on the fly.
And for the person with one computer/drive, or with hundreds,
that probably suffices, and LABELs may not be useful, certainly
not needed.

What may be of more concern to the latter group is the identity of
the disks themselves, and the /dev/disk/by-id is usually of help
here because it should correspond with what's printed on the disk.
(But beware of external caddies, where the number printed on the
container may refer to the caddy rather than the disk inside.)

But LABELs give you the opportunity to logically label the filesystems
with names that are human-friendly. All my disks are labelled
physically (marker pen on the case top, label on the edge that's still
visible when the drive is in situ) with a short name, and all the
filesystem LABELs consist of the name and the partition number
(which is stable, of course).

This is because I have a small number of disks (my N has never
exceeded the alphabet), and these disks have been swapped¹ between
multiple computers (which themselves are more of a commodity to me).

Your new naming scheme avoids the problem of character set, but
doesn't scale above N=1, so it wouldn't work for me. For example,
all my system disks contain two Debian root filesystems, typically
one generation apart. And "PART" isn't useful, like calling a dog
"fido animal".

(BTW bear in mind that LABELs are labelling the filesystems.
With GPT disks, you also get the opportunity to name the partitions
themselves, which can be useful.)

> > You might end up having to post to Gnome lists, so having them changed
> > may save embarrassment.
> 
> Could you please suggest an appropriate Gnome "mailing list"?

Google can. Typing   gnome mailing lists   yields
https://mail.gnome.org/mailman/listinfo
as the first hit. But remember, I don't use any DE, so they're
of no more than passing interest to me.

> I wrote (today):
> 
> > Maybe I am getting ahead of myself, but I wonder - what would happen if I
> > just either deleted the entire /dev/disk directory, or at least some
> > part(s) of it.
> >
> > After all, it just seems to be full of various zero-byte files.  Would the
> > /dev/disk directory just rebuild itself upon reboot, hopefully with
> > "correct" files?
> 
> > > No, I wouldn't do that. I'm not sure which files you think are
> > > incorrect, but these files should be left to be kept up-to-date
> > > by the OS, below the level of Gnome.
> 
> : (

No need to be sad. I just don't think these links are relevant to your
problem, and you don't want to lay waste your system by confusing some
process deep within the OS that happens to use them.

¹ For example, faye was bought as an upgrade for a desktop PC
(Pentium II), then moved to a second drive in a tower (Pentium III),
then into a loaned (redundant) Dell Optiplex, and when the PSU died
in March, I found a twin to replace it. Faye's two root filesystems
have flipped back and forth between sarge, etch, lenny, squeeze,
wheezy, jessie, stretch and buster over the years.

Cheers,
David.

Re: debsecan does not report a vulnerability?

[Victor Sudakov]

Have I asked in the wrong list? Which list would be more appropriate?

Victor Sudakov wrote:
> Dear Colleagues,
> 
> There is something about debsecan I don't understand, can you please clarify 
> for me?
> 
> CVE-2020-1967 was fixed in version 1.1.1d-0+deb10u3, I have
> 1.1.1d-0+deb10u2 installed, but for some reason debsecan does not report
> the vulnerable package:
> 
> # dpkg -l | grep openssl
> ii  openssl   1.1.1d-0+deb10u2 amd64
> Secure Sockets Layer toolkit - cryptographic utility
> # debsecan --suite buster | grep CVE-2020-1967
> # 
> 
> What am I doing wrong?
> 
> I'm familiar with FreeBSD's "pkg audit", maybe I'm misusing debsecan?
> 
> -- 
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> 2:5005/49@fidonet http://vas.tomsk.ru/



-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[David Wright]

On Sun 10 May 2020 at 16:30:56 (+0200), Sven Hartge wrote:
> David Wright  wrote:
> 
> > If the answer is many, you could shrink some of them by rebuilding
> > their initrd.img files with MODULES=dep, which could reduce each
> > kernel's size from ~40M to <10M.
> 
> While this will reduce this initrd size, you should also mention the
> consequences of doing this:
> 
>  It only includes the modules update-initramfs thinks are needed to boot
>  the system.
> 
> But this also results in two important consequences:
> 
> 1) You lose portability of the system. By only including the modules
>needed to boot in the current hardware this may limit your ability to
>boot the system on different hardware.
> 
> 2) MODULES=dep is a codepath less tested. In my experience this can lead
>to modules missing which are needed for successful boot, resulting in
>a failed or incomplete boot.

That's why I wrote "some".

We have no idea what this machine/disk is used for, nor how many
kernels is considered reasonable. But with ~240M available, we're in
the realm of compromise. The suggestion has already been made to
backup (then presumably remove) some kernels. Copying the initrd.img
files before rebuilding as dep is even easier. Were a disaster to
befall, the OP has already mentioned having GRML available. Gigs
of space is available in the df listing presented. So expanding
/boot just doesn't seem urgent enough to be done at five in the
morning.

Cheers,
David.

Re: ping -a $HOST, afmelding

[Geert Stappers]

On Sun, May 10, 2020 at 04:04:43PM +0200, Vincent Lammens wrote:
> Op 2020-05-10 om 15:08 schreef Geert Stappers:
> > 
> > Hoi,
> > 
> > De manual page van `ping` zegt onder andere.
> > 
> > -a Audible ping.
> > 
> > 
> > Wat zou dat moeten doen?   Wat doet het bij jullie?
> > 
> 
> Als ik het goed heb zou het wel een bell-sound moeten weergeven, al hoor
> ik hem ook niet. Hoor je een geluidje als je bv in bash op de backspace
> blijft drukken als er niets ingetypt is? (daar hoor ik een geluidje)

Nope, geen bliepje bij op backspace blijven drukken in shell.
(dat bliepje zal ik ook niet missen)

Uitvoeren van

  /usr/bin/echo -e "\a"

dat is met de  a  van alert, levert ook geen bliepje.
(een bliepje wat ik wel zal missen nu ik weet dat het er niet meer is)


Ik heb nu beter weet van  waarom er bij `ping -a $HOST` niets te horen
is.  Dank.



Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Sven Hartge]

David Wright  wrote:

> If the answer is many, you could shrink some of them by rebuilding
> their initrd.img files with MODULES=dep, which could reduce each
> kernel's size from ~40M to <10M.

While this will reduce this initrd size, you should also mention the
consequences of doing this:

 It only includes the modules update-initramfs thinks are needed to boot
 the system.

But this also results in two important consequences:

1) You lose portability of the system. By only including the modules
   needed to boot in the current hardware this may limit your ability to
   boot the system on different hardware.

2) MODULES=dep is a codepath less tested. In my experience this can lead
   to modules missing which are needed for successful boot, resulting in
   a failed or incomplete boot.

Grüße,
Sven

-- 
Sigmentation fault. Core dumped.

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[David Wright]

On Sat 09 May 2020 at 20:05:48 (-0700), Rick Thomas wrote:
> I recently did a "apt update ; apt upgrade" and it died for lack of space in 
> /boot when trying to install the latest kernel.
> 
> I purged a couple of old kernel packages (still present in the 'stable' repo, 
> so they weren't obsolete) to make enough space and tried again.  Worked this 
> time, but I would have liked to have the old kernels around as fallbacks just 
> in case of a regression...
> 
> Here's the disk layout:
> 
> rbthomas@milli:~$ lsblk
> NAME  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> sda 8:00 111.8G  0 disk 
> ├─sda1  8:10   512M  0 part /boot/efi
> ├─sda2  8:20   244M  0 part /boot
> └─sda3  8:30 111.1G  0 part 
>   ├─debian--vg-root   253:0028G  0 lvm  /
>   ├─debian--vg-swap_1 253:10   7.9G  0 lvm  [SWAP]
>   └─debian--vg-home   253:20  75.2G  0 lvm  /home
> sdb 8:16   1   239G  0 disk 
> └─sdb1  8:17   1   239G  0 part /media/rbthomas/Spare
> mmcblk0   179:00 238.3G  0 disk 
> └─mmcblk0p1   179:10 238.3G  0 part /media/rbthomas/Downloads
> rbthomas@milli:~$ 
> 
> rbthomas@milli:~$ df -HTP | grep -v tmpfs
> Filesystem  Type  Size  Used Avail Use% Mounted on
> /dev/mapper/debian--vg-root ext4   30G  9.9G   19G  36% /
> /dev/sda2   ext2  248M   78M  158M  34% /boot
> /dev/sda1   vfat  536M  144k  536M   1% /boot/efi
> /dev/mapper/debian--vg-home ext4   79G  4.4G   71G   6% /home
> /dev/sdb1   ext4  252G   63M  239G   1% 
> /media/rbthomas/Spare
> /dev/mmcblk0p1  ext4  251G   63M  238G   1% 
> /media/rbthomas/Downloads
> rbthomas@milli:~$ 
> 
> 
> What's the best way to increase the size of /boot ?
> 
> I can easily create a gig or so of space by a shrink/resize of /home, but how 
> do I add that space to /dev/sda2 ?
> 
> I can't just move up the end of /dev/sda2 = start of /dev/sda3 without 
> backing up and restoring, can I?

Apparently you have at least two kernels in under 80M, so one wonders
how many you need to have available for booting at any one moment.

If the answer is many, you could shrink some of them by rebuilding
their initrd.img files with MODULES=dep, which could reduce each
kernel's size from ~40M to <10M.

75G for /home is pretty small (the only disk I have that small is a
2004 laptop) so I'd look for an opportunity to repartition in the
near to mid-term. (Is this one that you've converted to sysv, for
example, or is it encrypted—excuses like that.)

All of which assumes that you actually need a separate /boot …
… and that you didn't repartition it already, before dawn.

Cheers,
David.

Re: Re: Re: Mouse awfully slow on Debian 10 on certain machines

[Jörg Kampmann]

> Hello list, I did some further research. In particular I used the 
live-ISO-image of


> Buster (amd64) >on DVD and bootet the system. And I found the following:

> Mouse still is irrational. It works fine, when no application has 
started after logging.
> When then an application is started (in this case Firefox of the DVD) 
the mouse mostly does not
> move. It jumps. And when there is a button something similar, the 
mouse behaves even worse. I

> did not dig >into the "InputClass" because I did not find it


So any help is urgently needed.


I did some further research with live-CD's, as well with x86 as amd64:
Results on both versions:

mouse behaves normal after booting system and log in (when no application runs) 
- first thing I saw was:

"*Oh no, something has gone wrong*" (I think this is no problem) so I continued 
and got the normal
user screen. I pressed right button for settings:

The mouse was a bit jumping and when I moved to the group of background 
pictures (via click) the
mouse from picture to picture (from one background picture to the neighbouring one) is 
"sticky".
this occurs on each "border" of the pictures.

Then I started an application.

I chose Firefox as application and started it. here the mouse was more or less 
fixed ... also
keyboard typing was not possible. The mouse behaved as if stuck to the mousepad.

Then I started another application:
the mouse disappeared when moved from neutral background to the window of the 
application.

I have the impression the applications hinder the mouse to move. could this be 
a priority problem?

kind regards
Jörg

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[rhkramer]

On Sunday, May 10, 2020 05:07:24 AM Rick Thomas wrote:

> > > * Rick Thomas  [20-05/09=Sa 20:05 -0700]:
> > >> What's the best way to increase the size of /boot?

> Yeah, that's probably what I'll do.  Fortunately, it's an amd64 machine, so
> I'll be able to use GRML to do the work. Enjoy!

Another option: it looks like there is room in your ~240 MB /boot for two 
kernels -- why not back up older kernels to somewhere else (somewhere in 
/home, /, or an external device and just keep the current and the previous 
kernel in /boot.

Then on your next fresh install, make a bigger /boot... (or just leave it in / 
(particularly as I'm not sure of the implications of needing /usr during 
boot)).

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[G2PC]

> Je n'ai pas regardé en détail la différence entre les deux, mais je pense
> que tu fais fausse route. Peu importe la façon dont il va être lancé, il
> est préférable de n'avoir qu'un seul script (qui pourra éventuellement
> s'adapter à son contexte d'exécution).
>
> Là encore, il arrivera sûrement un jour où tu feras une modification dans
> l'un et que tu oublieras de reporter dans l'autre et ce sera le drame.
>
> Sébastien

Oui je me dis la même, faut que je revois ça, sans les nausées et les
migraines.

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Rick Thomas]

On Sun, May 10, 2020, at 3:22 AM, Andrei POPESCU wrote:
> On Du, 10 mai 20, 02:02:45, Rick Thomas wrote:
> > So... Here's another question:
> > 
> > Why is the default size of /boot, as created by the installer, so 
> > small?  Disk (even SSD) is cheap enough these days that the default 
> > size could be as much as a GB without great pain.
> > 
> > Has this been thought about by the PTBs?  Was there a discussion of 
> > possibly raising the default?  Maybe I missed it...
> 
> A quick search in the BTS reveals #893886 and #951709 (both fixed in 
> git).

Thanks for the pointers, Andrei!   Do you think those changes will get into 
Bullseye before it's released?
Rick

Re: Booter sur un adaptateur M.2 PCI-e x4 et éclaircicement sur initrd

[Basile Starynkevitch]

On 5/10/20 12:22 PM, benoit wrote:

Bonjour,

Dans ma recherche d'une carte mère d'occase, je me demande : si elle 
n'a pas d'interface NVMe M.2 et que j'utilise un adaptateur M.2 sur un 
slot PCI-e x4 comme celui-ci :

https://www.riitop.com/collections/msata-ssd-adapter/products/m-2-nvme-ssd-to-pci-e-3-0-x16-adapter-card-convetor-full-speed-m-key-2230-2242-2260-2280-mm-pcie-m-2-nvme-ssd

Sera-t-il bootable ?

Si pas et que je place uniquement la partition /boot sur un ssd sur 
l'interface sata et le reste du système  sur le «disque» NVMe M.2, 
cette stratégie de contournement fonctionnera-t-elle pour le démarrage 
du système ?
Si ça suffit à contourner une éventuelle impossibilité de booter sur 
l'adaptateur NVMe M.2, est-ce que le ralentissement du temps de 
démarrage du système sera-t-il significatif ou imperceptible ?


En consultant la doc d'/initrd je ne comprend pas bien si je peux le 
configurer pour aller chercher /le noyau sur un autre disque. //

https://wiki.debian.org/fr/Initrd



Pour moi, il s'agit de configurer GRUB et probablement le BIOS ou UEFI 
de la carte mère.



Quand initrd démarre, le noyau est déjà chargé, et initrd s'occupe des 
modules du noyau.



Personnellement je suggère plutôt un petit disque SSD avec interface 
SATA. Ca doit pas coûter plus cher que l'adaptateur.


--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France; 
(mobile phone: cf my web page / voir ma page web...)

Booter sur un adaptateur M.2 PCI-e x4 et éclaircicement sur initrd

[benoit]

Bonjour,

Dans ma recherche d'une carte mère d'occase, je me demande : si elle n'a pas 
d'interface NVMe M.2 et que j'utilise un adaptateur M.2 sur un slot PCI-e x4 
comme celui-ci :
https://www.riitop.com/collections/msata-ssd-adapter/products/m-2-nvme-ssd-to-pci-e-3-0-x16-adapter-card-convetor-full-speed-m-key-2230-2242-2260-2280-mm-pcie-m-2-nvme-ssd

Sera-t-il bootable ?

Si pas et que je place uniquement la partition /boot sur un ssd sur l'interface 
sata et le reste du système  sur le «disque» NVMe M.2, cette stratégie de 
contournement fonctionnera-t-elle pour le démarrage du système ?
Si ça suffit à contourner une éventuelle impossibilité de booter sur 
l'adaptateur NVMe M.2, est-ce que le ralentissement du temps de démarrage du 
système sera-t-il significatif ou imperceptible ?

En consultant la doc d'initrd je ne comprend pas bien si je peux le configurer 
pour aller chercher le noyau sur un autre disque.
https://wiki.debian.org/fr/Initrd

Merci d'avance

--

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Andrei POPESCU]

On Du, 10 mai 20, 02:02:45, Rick Thomas wrote:
> So... Here's another question:
> 
> Why is the default size of /boot, as created by the installer, so 
> small?  Disk (even SSD) is cheap enough these days that the default 
> size could be as much as a GB without great pain.
> 
> Has this been thought about by the PTBs?  Was there a discussion of 
> possibly raising the default?  Maybe I missed it...

A quick search in the BTS reveals #893886 and #951709 (both fixed in 
git).

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


signature.asc
Description: PGP signature

Re: Pasar o recoger salida de comandos a variables.

[Ramses]

El 10 de mayo de 2020 11:45:45 CEST, "Camaleón"  escribió:
>El 2020-05-10 a las 10:04 +0200, Ramses escribió:
>
>> Buenos días,
>> 
>> Cuando he necesito recoger la salida de un comando para después
>tratarla, lo he hago siempre así:
>> 
>> # PRUEBA=$(ls -la)
>> 
>> No me muestra la salida por Consola pero con un "echo $PRUEBA"
>imprimo el contenido.
>> 
>> Pero me he he encontrado con una curiosidad con NetCat.
>> 
>> Si hago un:
>> 
>> # PRUEBA=$(nc -z -v -w5 80.80.80.80 22)
>> 
>> Me muestra la salida por Consola y si hago un "echo $PRUEBA" me
>muestra la variable vacía.
>> 
>> ¿Sabe alguien por qué ocurre esto con NetCat y cómo tendría que
>hacerlo para recoger la salida en una variable?
>
>Ni idea... ¡esto es linux avanzado! :-P
>
>La explicación la tienes aquí:
>
>
>passing output of a netcat command to a variable or piping through read
>
>utility
>
>
>
>Y ciertamente, enviar a la salida estándar funciona:
>
>sm01@stt008:~$ PRUEBA=$(nc -z -v -w5 80.80.80.80 22 2>&1); echo $PRUEBA
>80.80.80.80: inverse host lookup failed: Unknown host (UNKNOWN)
>[80.80.80.80] 22 (ssh) : Connection timed out
>
>sm01@stt008:~$ PRUEBA=$(nc -z -v -w5 80.80.80.80 22 2>&1); echo $PRUEBA
>> Escritorio/prueba.txt
>sm01@stt008:~$ cat Escritorio/prueba.txt
>80.80.80.80: inverse host lookup failed: Unknown host (UNKNOWN)
>[80.80.80.80] 22 (ssh) : Connection timed out
>
>Saludos,

Sí, sí, ya había encontrado esa solución.

Nos hemos cruzado el correo por el camino...


Gracias,

Ramsés

Re: Pasar o recoger salida de comandos a variables.

[Camaleón]

El 2020-05-10 a las 10:04 +0200, Ramses escribió:

> Buenos días,
> 
> Cuando he necesito recoger la salida de un comando para después tratarla, lo 
> he hago siempre así:
> 
> # PRUEBA=$(ls -la)
> 
> No me muestra la salida por Consola pero con un "echo $PRUEBA" imprimo el 
> contenido.
> 
> Pero me he he encontrado con una curiosidad con NetCat.
> 
> Si hago un:
> 
> # PRUEBA=$(nc -z -v -w5 80.80.80.80 22)
> 
> Me muestra la salida por Consola y si hago un "echo $PRUEBA" me muestra la 
> variable vacía.
> 
> ¿Sabe alguien por qué ocurre esto con NetCat y cómo tendría que hacerlo para 
> recoger la salida en una variable?

Ni idea... ¡esto es linux avanzado! :-P

La explicación la tienes aquí:


passing output of a netcat command to a variable or piping through read 
utility



Y ciertamente, enviar a la salida estándar funciona:

sm01@stt008:~$ PRUEBA=$(nc -z -v -w5 80.80.80.80 22 2>&1); echo $PRUEBA
80.80.80.80: inverse host lookup failed: Unknown host (UNKNOWN) [80.80.80.80] 
22 (ssh) : Connection timed out

sm01@stt008:~$ PRUEBA=$(nc -z -v -w5 80.80.80.80 22 2>&1); echo $PRUEBA > 
Escritorio/prueba.txt
sm01@stt008:~$ cat Escritorio/prueba.txt
80.80.80.80: inverse host lookup failed: Unknown host (UNKNOWN) [80.80.80.80] 
22 (ssh) : Connection timed out

Saludos,

-- 
Camaleón 

Re: [SOLUCIONADO] Pasar o recoger salida de comandos a variables.

[Ramses]

El 10 de mayo de 2020 10:04:36 CEST, Ramses  escribió:
>Buenos días,
>
>Cuando he necesito recoger la salida de un comando para después
>tratarla, lo he hago siempre así:
>
># PRUEBA=$(ls -la)
>
>No me muestra la salida por Consola pero con un "echo $PRUEBA" imprimo
>el contenido.
>
>Pero me he he encontrado con una curiosidad con NetCat.
>
>Si hago un:
>
># PRUEBA=$(nc -z -v -w5 80.80.80.80 22)
>
>Me muestra la salida por Consola y si hago un "echo $PRUEBA" me muestra
>la variable vacía.
>
>¿Sabe alguien por qué ocurre esto con NetCat y cómo tendría que hacerlo
>para recoger la salida en una variable?
>
>
>Saludos y gracias,
>
>Ramsés

Buenas, me respondo yo mismo.

Se ve que NetCat está sacando la salida por STDERR en vez de por STDOUT, por lo 
que se puede solucionar así:

# PRUEBA=$(nc -z -v -w5 80.80.80.80 22 2 >&1)


Saludos,

Ramsés

Boot script

[Jan Wilmans]

I've created a bootable USB stick that boot debian 10 (buster), and i would
like to customize my rc.local to do and apt-get update and install icecc
then start iceccd  finally run top.

Its a simple script, but how can I insert it into the USB sticks read only
filesystem?


On Sun, May 10, 2020, 11:23 Jan Wilmans  wrote:

> If you look carefully of the last page, the radio button for writing the
> boot record to disk is by default is to ,NOT write the boot record. You
> have to change it to 'yes' before you continue!
>
> If you dont, then ofcourse it reboots and since nothing changed in the
> boot sequence it boots the iso again...
>
> On Sun, May 10, 2020, 07:54 Keith Bainbridge  wrote:
>
>> On 10/5/20 1:24 pm, Harry Brown wrote:
>> > Hey guys,
>> >
>> > I'm having a bit of an issue here while installing KaliLinux and I was
>> > wondering if you guys can help out.
>> >
>> > I installed *Oracle VirtualBox* on my *Windows 10* and downloaded *Kali
>> > Linux 64bit ISO file*, Then I created a new virtual machine *(Debian
>> > 64bit)*and started installing KaliLinux.
>> > Everything was great and almost 5GB of packages were downloaded and
>> > installed, the final step is to reboot so KaliLinux can run.
>> > I clicked on Finish Installation (after all packages and files were
>> > installed ) and it showed me a message saying that Kali will run after
>> > the machine reboot.
>> >
>> > Guess what! *The machine rebooted and it took me back to the first
>> > installation page again*, I didn't know what happened or if I did
>> > something wrong so I clicked "Install" again and followed the steps.
>> > And I had to wait **again for the 5GB of packages to be downloaded and
>> > installed ( which was frustrating ).
>> > Installation was finished and the machine rebooted and nothing
>> happened.
>> > *it took me back to the first installation page once again.*
>> > *
>> > *
>> > I know it's a long email (sorry about that), But I needed to make sure
>> > that you guys are fully aware of what's the issue so you can help.
>> >
>> > Thanks in advance,
>> >
>> > HB.
>> >
>>
>>
>> Good afternoon Harry
>>
>> I sometimes have to go into the settings for the virtual device and
>> untick the other boot options - CD and floppy from memory.
>>
>> --
>> Keith Bainbridge
>>
>> ke1th3...@zoho.com
>> +61 (0)447 667 468
>>
>>

Re: Kali Linux installation failure on VirtualBox

[Jan Wilmans]

If you look carefully of the last page, the radio button for writing the
boot record to disk is by default is to ,NOT write the boot record. You
have to change it to 'yes' before you continue!

If you dont, then ofcourse it reboots and since nothing changed in the boot
sequence it boots the iso again...

On Sun, May 10, 2020, 07:54 Keith Bainbridge  wrote:

> On 10/5/20 1:24 pm, Harry Brown wrote:
> > Hey guys,
> >
> > I'm having a bit of an issue here while installing KaliLinux and I was
> > wondering if you guys can help out.
> >
> > I installed *Oracle VirtualBox* on my *Windows 10* and downloaded *Kali
> > Linux 64bit ISO file*, Then I created a new virtual machine *(Debian
> > 64bit)*and started installing KaliLinux.
> > Everything was great and almost 5GB of packages were downloaded and
> > installed, the final step is to reboot so KaliLinux can run.
> > I clicked on Finish Installation (after all packages and files were
> > installed ) and it showed me a message saying that Kali will run after
> > the machine reboot.
> >
> > Guess what! *The machine rebooted and it took me back to the first
> > installation page again*, I didn't know what happened or if I did
> > something wrong so I clicked "Install" again and followed the steps.
> > And I had to wait **again for the 5GB of packages to be downloaded and
> > installed ( which was frustrating ).
> > Installation was finished and the machine rebooted and nothing happened.
> > *it took me back to the first installation page once again.*
> > *
> > *
> > I know it's a long email (sorry about that), But I needed to make sure
> > that you guys are fully aware of what's the issue so you can help.
> >
> > Thanks in advance,
> >
> > HB.
> >
>
>
> Good afternoon Harry
>
> I sometimes have to go into the settings for the virtual device and
> untick the other boot options - CD and floppy from memory.
>
> --
> Keith Bainbridge
>
> ke1th3...@zoho.com
> +61 (0)447 667 468
>
>

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Rick Thomas]

On Sun, May 10, 2020, at 1:17 AM, David Christensen wrote:
> On 2020-05-09 22:05, Will Mengarini wrote:
> > * Rick Thomas  [20-05/09=Sa 20:05 -0700]:
> >> What's the best way to increase the size of /boot?
> > By creating a reliable backup and reformatting the disk to
> > the new format.  I've never found it to be cost-effective
> > to try anything else. 
> +1

Yeah, that's probably what I'll do.  Fortunately, it's an amd64 machine, so 
I'll be able to use GRML to do the work.
Enjoy!
Rick

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Rick Thomas]

So... Here's another question:

Why is the default size of /boot, as created by the installer, so small?  Disk 
(even SSD) is cheap enough these days that the default size could be as much as 
a GB without great pain.

Has this been thought about by the PTBs?  Was there a discussion of possibly 
raising the default?  Maybe I missed it...

Stay safe and stay healthy!
Rick

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Will Mengarini]

* Rick Thomas  [20-05/09=Sa 20:05 -0700]:
> [...] died for lack of space in /boot [...]

Long ago I stopped bothering with a separate /boot, and behold, I yet
live.  ISTR the Debian installer doesn't default to creating one either.

If you really want a bastion filesystem for booting, I suggest it be /
(say 8G), because that'll also give you /bin, /lib, /etc, etc, without
which you can't troubleshoot system horkage anyway.  Then you can
put /home and /usr on the beta release of FunkyFS and have fun.  I'd
also put /tmp on the same partition as /home, because when I want to
rm $junk I typically do it with mv -t/tmp $junk for safety, which on
the same filesystem just edits directory entries, but on a different
one actually copies $junk, meh.  Make sure your bastion filesystem has
enough room for /var/spool; shouldn't be a problem unless you're one
of those people who likes 30G mailboxes, or are running a news server.

Stay safe, back up your files, and wash your hands.

> rbthomas@milli:~$ lsblk
> NAME  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> sda 8:00 111.8G  0 disk
> +-sda1  8:10   512M  0 part /boot/efi
> +-sda2  8:20   244M  0 part /boot
> +-sda3  8:30 111.1G  0 part
>   +-debian--vg-root   253:0028G  0 lvm  /
>   +-debian--vg-swap_1 253:10   7.9G  0 lvm  [SWAP]
>   +-debian--vg-home   253:20  75.2G  0 lvm  /home
> sdb 8:16   1   239G  0 disk
> +-sdb1  8:17   1   239G  0 part /media/rbthomas/Spare
> mmcblk0   179:00 238.3G  0 disk
> +-mmcblk0p1   179:10 238.3G  0 part /media/rbthomas/Downloads
> rbthomas@milli:~$
>
> rbthomas@milli:~$ df -HTP | grep -v tmpfs
> Filesystem  Type Size Used Avail Use% Mounted on
> /dev/mapper/debian--vg-root ext4  30G 9.9G   19G  36% /
> /dev/sda2   ext2 248M  78M  158M  34% /boot
> /dev/sda1   vfat 536M 144k  536M   1% /boot/efi
> /dev/mapper/debian--vg-home ext4  79G 4.4G   71G   6% /home
> /dev/sdb1   ext4 252G  63M  239G   1% /media/rbthomas/Spare
> /dev/mmcblk0p1  ext4 251G  63M  238G   1% 
> /media/rbthomas/Downloads
> rbthomas@milli:~$
>
> What's the best way to increase the size of /boot?

By creating a reliable backup and reformatting the disk to
the new format.  I've never found it to be cost-effective
to try anything else.  I don't even upgrade to new releases
anymore; I just nuke everything and do a fresh install.

> I can easily create a gig or so of space by a shrink/resize
> of /home, but how do I add that space to /dev/sda2?
>
> I can't just move up the end of /dev/sda2 = start of
> /dev/sda3 without backing up and restoring, can I?
>
> Any suggestions would be appreciated.

Consider the time you've spent posing this question, waiting for the
answers, and reading them.  Dump and reload might've finished already.

-- 
 Will Mengarini  
 Free software: the Source will be with you, always.
This will be a memorable month -- no matter how hard you try to forget it.
--Unix fortune cookie

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[David Christensen]

On 2020-05-09 22:05, Will Mengarini wrote:

* Rick Thomas  [20-05/09=Sa 20:05 -0700]:



What's the best way to increase the size of /boot?


By creating a reliable backup and reformatting the disk to
the new format.  I've never found it to be cost-effective
to try anything else. 


+1



I don't even upgrade to new releases
anymore; I just nuke everything and do a fresh install.


+1


David

Pasar o recoger salida de comandos a variables.

[Ramses]

Buenos días,

Cuando he necesito recoger la salida de un comando para después tratarla, lo he 
hago siempre así:

# PRUEBA=$(ls -la)

No me muestra la salida por Consola pero con un "echo $PRUEBA" imprimo el 
contenido.

Pero me he he encontrado con una curiosidad con NetCat.

Si hago un:

# PRUEBA=$(nc -z -v -w5 80.80.80.80 22)

Me muestra la salida por Consola y si hago un "echo $PRUEBA" me muestra la 
variable vacía.

¿Sabe alguien por qué ocurre esto con NetCat y cómo tendría que hacerlo para 
recoger la salida en una variable?


Saludos y gracias,

Ramsés

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Rick Thomas]

> Consider the time you've spent posing this question, waiting for the
> answers, and reading them.  Dump and reload might've finished already.

True, but I wouldn't have learned half so much and wouldn't have had a third so 
much had so much fun learning it!

Stay safe!

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Rick Thomas]

On Sat, May 9, 2020, at 9:10 PM, Charles Curley wrote:
> On Sat, 09 May 2020 20:05:48 -0700
> "Rick Thomas"  wrote:
> 
> > Filesystem  Type  Size  Used Avail Use% Mounted on
> > /dev/mapper/debian--vg-root ext4   30G  9.9G   19G  36% /
> > /dev/sda2   ext2  248M   78M  158M  34% /boot
> 
> Odd. That should be good for more than three kernels. I have:
> 
> root@jhegaala:~# df /boot/
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sda5   226M   92M  119M  44% /boot
> root@jhegaala:~#
> 
> with three kernels.
> 
> My /boot is ext4, but I doubt that makes enough difference to matter.
> My installation is not EFI. Would that make the difference?

The figures above are *after* I deleted the two previous kernel versions.  So 
yes, there's plenty of space there when this is taken.  It looks like each 
kernel/initrd combo takes 75-80 MB so three of them could take as much as 240 
MB, just a bit beyond the space available.

Stay well and stay safe!
Rick

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Andrei POPESCU]

On Sb, 09 mai 20, 22:05:40, Will Mengarini wrote:
> * Rick Thomas  [20-05/09=Sa 20:05 -0700]:
> > [...] died for lack of space in /boot [...]
>
> Long ago I stopped bothering with a separate /boot, and behold, I yet
> live.  ISTR the Debian installer doesn't default to creating one 
> either.

Agreed.

> If you really want a bastion filesystem for booting, I suggest it be /
> (say 8G), because that'll also give you /bin, /lib, /etc, etc, without
> which you can't troubleshoot system horkage anyway.  Then you can
> put /home and /usr on the beta release of FunkyFS and have fun.

Booting without /usr is not supported anymore and with usrmerge most of 
the stuff from / was moved to /usr anyway.

Unless you want to keep /usr read-only (except for package upgrades) 
and/or share it between systems there is no real need to have it on a 
separate partition.

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


signature.asc
Description: PGP signature