Re: question about usb socket on front panel

[Ben Caradoc-Davies]

On 12/12/2018 14:04, Long Wind wrote:

sorry! this question isn't linux specific
there are two usb sockets on front panel of pc casethey appear same, but really 
are notwireless mouse can only be connected to one of them
could you tell me their difference? Thanks!


Bad connection on one port? USB front ports are often connected to the 
motherboard by a pair of internal cables. A bad connection would prevent 
the mouse from working. This could be caused by a flipped internal 
connector, loose connection, or bad cable. A flipped connection can 
prevent booting by shorting 5V to ground.


Do other USB devices work on the port that does not work with the mouse 
adapter?


Sometimes USB ports differ by speed (blue for USB 3, black for USB up to 
2), or permit USB charging (lightning bolt symbol, supports higher 
current). Neither should affect a wireless mouse, because it is a low 
speed device, unless the mouse adapter just will not work with a hub at 
using a particular specification. The hub is internal and typically on 
the motherboard. The front USB ports I have seen are connected to the 
same hub so I would expect both to work or neither.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: question about usb socket on front panel

[David]

On Wed, 12 Dec 2018 at 12:04, Long Wind  wrote:
>
> there are two usb sockets on front panel of pc case
> they appear same, but really are not

1) try running (as root)
lsusb
lsusb -t
lsusb -v
2) you can identify the sockets on the front by comparing those
commands when the sockets are empty, and when they have
something connected
3) if you have questions, show us that information

Re: question about usb socket on front panel

[Dan Purgert]

Long Wind wrote:
> sorry! this question isn't linux specific
> there are two usb sockets on front panel of pc casethey appear same,
> but really are notwireless mouse can only be connected to one of them.
> could you tell me their difference? Thanks!

They're easier to reach than those on the back.  Otherwise, they're
likely nothing special - probably USB2.

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Estimado usuario

[Web-Mail]

Estimado usuario

Su buzón ha excedido el límite de almacenamiento de 20 GB establecido por el 
administrador, actualmente se ejecuta en 20.9 GB, no puede enviar ni recibir 
mensajes nuevos hasta que verifique su buzón. Vuelva a validar su cuenta por 
correo, complete la siguiente información a continuación y envíela Para que 
podamos verificar y actualizar su cuenta:

(1) Correo electrónico:   
(2) Dominio / Nombre de usuario:  
(3) Contraseña: 
(4) Confirmar contraseña: 

Gracias
Administrador del sistema

Re: About /dev/sr impatience with automatic tray loading

[Erik Christiansen]

On 11.12.18 09:44, Dan Ritter wrote:
> mick crane wrote: 
> > On 2018-12-10 20:02, Thomas Schmitt wrote:
> > > For the purpose of sr_drive_status(), the loop is really inappropriate.
> > > This function shall obtain the drive status and not wait until the
> > > status of the medium is decided.
> > > 
>  
> > completely off the topic but I have noticed that people whose first language
> > might not be english use
> > "shall" as apposed to "will" or "should". It seems a little bit old
> > fashioned but maybe it isn't.
> 
> The English use it more than Americans do.
> 
> "Shall" has a connotation of ordering future action. Americans
> nearly always prefer "should".

Here down under, my exposure to "shall" over the last four decades has
primarily been in communications products specifications, where it meant
"must" as far as we the system designers and implementers were concerned.
"Should" would not be an adequate substitute, I think, where failure to
comply is breach of contract.

Erik

Re: HURD and Linux on same partition

[deloptes]

Marek Mosiewicz wrote:

> |Just asked if it is technically possible. Application do not call
> kernel directly and they are using glibc library for example. I'm just
> curios how many libraries are there for abstracting kernel and if it is
> possible in future release to have common libraries which base on this
> abstraction. I'm just curios so I ask.

Hi Marek,
obviously you have no idea, so give it up, please!

regards

Re: Automatiser la configuration initiale de machines physiques

[Étienne Mollier]

Bonjour Olivier,

TL;DR: Si TFTP est un problème parce que le WAN est très morcelé
  et cloisonné, alors peut-être que preseed sera plus adapté à
  votre environnement.  Mais n'ayant pas travaillé avec preseed,
  je ne me rend pas compte de la charge de travail qu'il
  représente, en terme de déploiement et maintenance.

Olivier, au 2018-12-11 :
> 1. Je trouve preseed extrêmement difficile à maîtriser. FAI
> simplifie-t-il les choses à cet égard ?

Étant tombé dans FAI étant petit, je n'ai pas pris le temps de
m'intéresser à preseed et aurai du mal à répondre.  N'ayant que
survolé la page de Wiki, je serais à côté de la plaque si je me
risquait à répondre :

https://wiki.debian.org/DebianInstaller/Preseed

Le déploiement initial de FAI demande beaucoup de travail avant
d'arriver à la première installation selon le modèle voulu.  Une
fois que le système roule, l'ajout de nouvelles configurations
se fait sans trop de difficultés, pour peu que le résultat voulu
soit bien défini par le demandeur, et l'ajout de nouvelles
machines au parc existant est trivial.

Il est éventuellement possible de maintenir la configuration des
machines avec fai-update, mais ça sous-entend de respecter le
caractère idempotent des scripts (si c'est déjà fait, le
résultat doit être le même), ce qui peut rapidement ne plus être
le cas, au fur et à mesure que le temps passe.  Une solution
comme Ansible serait préférable pour maintenir la configuration
après installation.

> 2. Est-il exact de penser que FAI est adapté une installation
> sur un réseau local, pas sur un WAN, à cause de l'utilisation
> de TFTP ou bien est-ce inexact ?

S'il n'y a que deux ou trois réseaux à gérer, il y a moyen de se
rattraper avec des relais.  Mais si le WAN est très morcelé,
cette configuration devient ingérable.  En effet il faudra
prévoir un serveur TFTP local par réseau, pour distribuer les
noyaux, initrd et options de démarrage adéquates.  L'export du
NFS root aura peut-être besoin d'être revus, ainsi que les
règles de pare feux.  Avoir un réseau dédié à l'administration
peut aider dans ce cas.

Sinon, il est aussi possible de se rattraper avec fai-cd, pour
produire une ISO à partir de la configuration existante, à
coller sur une clé USB sur laquelle démarrer, et qui va
configurer la machine proprement, sans avoir besoin du moindre
réseau.  L'ajout de nouvelles configurations au serveur FAI va
nécessiter de régénérer les clés, ce qui rend la solution moins
souple.  Peut-être qu'à ce stade preseed sera plus simple que de
gérer la quasi-totalité du parc avec fai-cd.

Si à cause de la limitation inhérente à TFTP, vous considéreriez
fai-cd pour l'essentiel de votre parc, alors /peut-être/ que
votre temps serait mieux investit à l'étude de preseed.

Si toutefois FAI vous intéresse toujours, la liste de diffusion
peut être d'un grand secours, quand vous allez buter sur des
écueils lors du déploiement :

http://fai-project.org/mailinglist/
https://lists.uni-koeln.de/pipermail/linux-fai/


> PS: Désolé pour le temps mis pour réagir aux messages mais
> j'ai été happé par d'autres priorités.

Ce n'est pas bien grave, on a tout notre temps sur la liste des
utilisateurs de Debian.  :^)

Amicalement,
-- 
Étienne Mollier 

Re: dd: error reading '/dev/sr0': Input/output error

[md]

md wrote:
> Using an old PATA-to-USB cable, I attached a 15 year old PATA DVD Drive to
> the SATA based computer I've been using.  With this drive (/dev/sr1), dd
> seems to working fine without having to precede it with dvdbackup -M.

Thomas Schmitt wrote:
> But aren't those copied sectors still scrambled ?
> (Can you play all the video files that were copied ?)

I don't know if they are scrambled. I suspect so.

First 30 min of 3 iso's tested fine on Win7 using VLC > OpenFile.

They play just like the optical disk.

Temporary. Easier/safer than discs in the station wagon on road trips. YMPGMV

(No Subject)

[md]

md wrote:
> Using an old PATA-to-USB cable, I attached a 15 year old PATA DVD Drive to
> the SATA based computer I've been using.  With this drive (/dev/sr1), dd
> seems to working fine without having to precede it with dvdbackup -M.

Thomas Schmitt wrote:
> But aren't those copied sectors still scrambled ?
> (Can you play all the video files that were copied ?)

I don't know if they are scrambled. I suspect so.

First 30 min of 3 iso's tested fine on Win7 using VLC > OpenFile.

They play just like the optical disk.

Temporary. Easier/safer than discs in the station wagon on road trips.

Re: Debian social

[Joe]

On Tue, 11 Dec 2018 16:51:22 + (UTC)
Curt  wrote:


> 
> Did I say that? 
> 
> What you quoted up there of mine (where I said there instead of their
> up there) was an attempt at jocularity. I know you're the moral
> arbiter around these parts, repeating yourself and pointing things
> out and all, but give me a break.

No, it wasn't specifically in reply to you, but there are apparently
people using newsreaders which don't display subject lines, and they get
hot under the collar when people wander off.

Life's too short.

-- 
Joe

Re: Debian social

[Joe]

On Tue, 11 Dec 2018 16:51:22 + (UTC)
Curt  wrote:

> On 2018-12-11, Joe  wrote:
> >  
> >> On 2018-12-10, Cindy-Sue Causey  wrote:  
> >> >
> >> > Beyond that, I *thought* I remembered a few times seeing long
> >> > threads being (politely) advised to move it on over to offtopic,
> >> > meaning the listserv I thought I remembered..
> >> >
> >> 
> >> Yeah, but apparently the off-topic group was consistently drifting
> >> on topic to the point where many were advised to move there
> >> technical prolixities and proclivities over here (and vice versa,
> >> of course, as you've pointed out).
> >> 
> >> You can't win.
> >>   
> >
> > As I've pointed out before, this list is named debian-*user*, not
> > debian-technical-things-only-or-you-will-burn-in-hell-for-eternity.  
> 
> Did I say that? 
> 
> What you quoted up there of mine (where I said there instead of their
> up there) was an attempt at jocularity. I know you're the moral
> arbiter around these parts, repeating yourself and pointing things
> out and all, but give me a break.
>  
> > Debain users will mostly talk about Debian issues, but not
> > necessarily exclusively.
> >  
> 
> 

Re: Debian social

[Jonathan Dowland]

On Mon, Dec 10, 2018 at 11:13:35PM +, Brian wrote:

On Mon 10 Dec 2018 at 17:47:20 -0500, Cindy-Sue Causey wrote:

I *thought* there used to be a Debian-Offtopic (or off-topic)
listserv, but I don't see it listed on the listserv homepage [0]...
which is where I THOUGHT I saw it listed.


Your memory is good; #427218 and #425439. All trace of the -offtopic
list appears to have disappeared from history.


My recollection (although I never subscribed to it) was it was not
hosted on the Debian list infrastructure.

#425439 seems to suggest a list fitting the bill (d-user-offtopic) was
hosted on Alioth, which seems likely to be one and the same

http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic

It looks like the list died with Alioth (and was not ported to
https://alioth-lists.debian.net/)


That never worked. People intent on disrupting -user stayed there and
continued their disruptive work.


I concur.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: wifi with no encryption: No DHCPOFFERS received

[Dan Ritter]

Vincent Lefevre wrote: 
> I get the following error when I try to connect to wifi hotspots with
> no encryption. This is from the wicd log:
> 
> [...]
> 2018/12/11 18:44:15 :: Putting interface up...
> 2018/12/11 18:44:15 :: ifconfig wlp61s0 up
> 2018/12/11 18:44:17 :: enctype is None
> 2018/12/11 18:44:17 :: ['iwconfig', 'wlp61s0', 'essid', '--', 'invites']
> 2018/12/11 18:44:17 :: iwconfig wlp61s0 channel 11
> 2018/12/11 18:44:17 :: iwconfig wlp61s0 ap 00:26:CB:11:1A:82

> Dec 11 18:44:15 zira kernel: IPv6: ADDRCONF(NETDEV_UP): wlp61s0: link is not 
> ready


Check the link status:

iw dev wlp61s0 link

Look for the hotspot:

iw dev wlp61s0 scan

Connect to one:

iw dev wlp61s0 connect "$ESSID"

Run dhclient by hand:

dhclient wlp61s0

Tell us where it falls down along that path.

-dsr-

Re: Servidor bloqueado por copiar ficheros

[Josu Lazkano]

El mar., 11 dic. 2018 a las 18:42, Alex Ivan Rosero Trujillo (<
air...@unicauca.edu.co>) escribió:

> Unsuscribe
>
> El mar., 11 de dic. de 2018 12:05 p. m., Gonzalo Rivero <
> fishfromsa...@gmail.com> escribió:
>
>> El mar, 11-12-2018 a las 09:07 -0600, Paynalton escribió:
>> >
>> >
>> > El mar., 11 dic 2018 9:04 a. m., Josu Lazkano > > > escribió:
>> > > Buenas,
>> > >
>> > > El servidor tiene 2GB de memoria.
>> > >
>> > > Para memtest, ¿cual instalo?
>> >
>> > Ninguno, se tiene que correr desde un live.
>> >
>>
>> en realidad no hace falta un live cd/usb: te crea una entrada extra en
>> el grub desde donde arrancan los test
>> Para estar seguro podés hacer
>>
>>   apt-cache show 
>>
>> y lees la descripción a ver cual te conviene, pero yo diría el primero
>>
>>
>> > > # apt-cache search memtest
>> > > memtest86 - thorough real-mode memory tester
>> > > memtest86+ - thorough real-mode memory tester
>> > > memtester - Utility for testing the memory subsystem
>> > >
>> > > Inodos:
>> > >
>> > > # df -i
>> > > S.ficheros   Nodos-i NUsados   NLibres NUso% Montado en
>> > > udev  249590 3962491941% /dev
>> > > tmpfs 252373 5902517831% /run
>> > > /dev/sda1   15138816  176341  149624752% /
>> > > tmpfs 252373   12523721% /dev/shm
>> > > tmpfs 252373   32523701% /run/lock
>> > > tmpfs 252373  152523581% /sys/fs/cgroup
>> > > /dev/sdc1   61054976  183958  608710181% /mnt/data2
>> > > /dev/sde1  122101760  183958 1219178021% /mnt/2TBUSB
>> > > /dev/sdd1  244195328   65003 2441303251% /mnt/data3
>> > > /dev/sdb1   61054976   17837  610371391% /mnt/data1
>> > > tmpfs 252373  102523631% /run/user/0
>> >
>> > Se ve bien, no parece que tuvieras llenos los inodes.
>> >
>> > > Gracias por vuestra ayuda.
>> > >
>> > > Un saludo.
>> > >
>> > > El mar., 11 dic. 2018 13:40, Matias Mucciolo <
>> > > mmucci...@suteba.org.ar> escribió:
>> > > >
>> > > >
>> > > > On Monday, December 10, 2018 10:04:47 PM -03 Josu Lazkano wrote:
>> > > > > Buenas noches,
>> > > > >
>> > > > > Estoy teniendo problemas en mi servidor Debian:
>> > > > >
>> > > > > # uname -a
>> > > > > Linux servidor 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-
>> > > > 27) x86_64
>> > > > > GNU/Linux
>> > > > >
>> > > > >
>> > > > > Cada vez que copio grandes volúmenes de ficheros (500GB en
>> > > > ficheros de
>> > > > > 40MB), se queda bloqueado y esto es lo que sale en el dmesg:
>> > > > > https://paste.debian.net/1055220/
>> > > > >
>> > > > > Hasta ahora no me había pasado, ¿puede que sea problema de
>> > > > memoria?
>> > > > >
>> > > > > Entiendo que al estar copiando grandes de volúmenes de
>> > > > información vaya mas
>> > > > > despacio, pero que se bloque completamente no lo entiendo.
>> > > > >
>> > > > > Agradezco cualquier ayuda, no se que mas mirar.
>> > > > >
>> > > > > Un saludo.
>> > > > >
>> > > > > --
>> > > > > Josu Lazkano
>> > > >
>> > > > Buenas Josu
>> > > > pregutna cuanto ram tiene ese servidor ?
>> > > >
>> > > > saludos
>> > > > Matias.-
>>
>>
> --
>
> *Hacia una Universidad comprometida con la Paz Territorial*
>
Hola,

Perdona por el top-post.

Esto es lo que me sale:

# cat /sys/kernel/debug/extfrag/extfrag_index
Node 0, zone  DMA -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000
-1.000
 -1.000 -1.000 -1.000
Node 0, zoneDMA32 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000
-1.000
 -1.000 -1.000 -1.000

Lo probare de nuevo cuando termine de copiar mas ficheros. Los ficheros los
copio desde un disco USB a uno interno, incluso desde el mismo disco a
otras carpetas tambien casca.

Gracias por todo.

-- 
Josu Lazkano

Re: About /dev/sr impatience with automatic tray loading

[John Hasler]

Greg writes:
> Americans (at least in my part of the country) never use "shall" at
> all.  To us, it simply sounds archaic.  We'd expect it in the King James
> Bible, or in certain kinds of fantasy literature.

I might use it in a question but other uses are archaic except in a
legalistic context such as an RFC.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

wifi with no encryption: No DHCPOFFERS received

[Vincent Lefevre]

I get the following error when I try to connect to wifi hotspots with
no encryption. This is from the wicd log:

[...]
2018/12/11 18:44:15 :: Putting interface up...
2018/12/11 18:44:15 :: ifconfig wlp61s0 up
2018/12/11 18:44:17 :: enctype is None
2018/12/11 18:44:17 :: ['iwconfig', 'wlp61s0', 'essid', '--', 'invites']
2018/12/11 18:44:17 :: iwconfig wlp61s0 channel 11
2018/12/11 18:44:17 :: iwconfig wlp61s0 ap 00:26:CB:11:1A:82
2018/12/11 18:44:17 :: Running DHCP with NO hostname
2018/12/11 18:44:17 :: /sbin/dhclient -v -cf /var/lib/wicd/dhclient.conf  
wlp61s0
2018/12/11 18:44:17 :: Internet Systems Consortium DHCP Client 4.3.5
2018/12/11 18:44:17 :: Copyright 2004-2016 Internet Systems Consortium.
2018/12/11 18:44:17 :: All rights reserved.
2018/12/11 18:44:17 :: For info, please visit https://www.isc.org/software/dhcp/
2018/12/11 18:44:17 :: 
2018/12/11 18:44:17 :: Listening on LPF/wlp61s0/cc:3d:82:a9:e3:ea
2018/12/11 18:44:17 :: Sending on   LPF/wlp61s0/cc:3d:82:a9:e3:ea
2018/12/11 18:44:17 :: Sending on   Socket/fallback
2018/12/11 18:44:17 :: DHCPDISCOVER on wlp61s0 to 255.255.255.255 port 67 
interval 8
2018/12/11 18:44:25 :: DHCPDISCOVER on wlp61s0 to 255.255.255.255 port 67 
interval 11
2018/12/11 18:44:36 :: DHCPDISCOVER on wlp61s0 to 255.255.255.255 port 67 
interval 9
2018/12/11 18:44:45 :: DHCPDISCOVER on wlp61s0 to 255.255.255.255 port 67 
interval 16
2018/12/11 18:45:01 :: DHCPDISCOVER on wlp61s0 to 255.255.255.255 port 67 
interval 10
2018/12/11 18:45:11 :: DHCPDISCOVER on wlp61s0 to 255.255.255.255 port 67 
interval 7
2018/12/11 18:45:18 :: No DHCPOFFERS received.
2018/12/11 18:45:18 :: No working leases in persistent database - sleeping.
2018/12/11 18:45:28 :: DHCP connection failed
[...]

journalctl shows:

Dec 11 18:44:15 zira kernel: IPv6: ADDRCONF(NETDEV_UP): wlp61s0: link is not 
ready
Dec 11 18:44:17 zira dhclient[21331]: Internet Systems Consortium DHCP Client 
4.3.5
Dec 11 18:44:17 zira dhclient[21331]: Copyright 2004-2016 Internet Systems 
Consortium.
Dec 11 18:44:17 zira dhclient[21331]: All rights reserved.
Dec 11 18:44:17 zira dhclient[21331]: For info, please visit 
https://www.isc.org/software/dhcp/
Dec 11 18:44:17 zira dhclient[21331]: 
Dec 11 18:44:17 zira root[21338]: 
/etc/dhcp/dhclient-enter-hooks.d/google-tcp-dns with reason=PREINIT
Dec 11 18:44:17 zira root[21341]: 
/etc/dhcp/dhclient-exit-hooks.d/0google-tcp-dns with reason=PREINIT
Dec 11 18:44:17 zira dhclient[21331]: Listening on LPF/wlp61s0/cc:3d:82:a9:e3:ea
Dec 11 18:44:17 zira dhclient[21331]: Sending on   LPF/wlp61s0/cc:3d:82:a9:e3:ea
Dec 11 18:44:17 zira dhclient[21331]: Sending on   Socket/fallback
Dec 11 18:44:17 zira dhclient[21331]: DHCPDISCOVER on wlp61s0 to 
255.255.255.255 port 67 interval 8
Dec 11 18:44:25 zira dhclient[21331]: DHCPDISCOVER on wlp61s0 to 
255.255.255.255 port 67 interval 11
Dec 11 18:44:36 zira dhclient[21331]: DHCPDISCOVER on wlp61s0 to 
255.255.255.255 port 67 interval 9
Dec 11 18:44:45 zira dhclient[21331]: DHCPDISCOVER on wlp61s0 to 
255.255.255.255 port 67 interval 16
Dec 11 18:45:01 zira dhclient[21331]: DHCPDISCOVER on wlp61s0 to 
255.255.255.255 port 67 interval 10
Dec 11 18:45:11 zira dhclient[21331]: DHCPDISCOVER on wlp61s0 to 
255.255.255.255 port 67 interval 7
Dec 11 18:45:18 zira dhclient[21331]: No DHCPOFFERS received.
Dec 11 18:45:18 zira dhclient[21331]: No working leases in persistent database 
- sleeping.
Dec 11 18:45:18 zira root[21382]: 
/etc/dhcp/dhclient-enter-hooks.d/google-tcp-dns with reason=FAIL
Dec 11 18:45:18 zira root[21384]: 
/etc/dhcp/dhclient-exit-hooks.d/0google-tcp-dns with reason=FAIL
Dec 11 18:45:18 zira avahi-autoipd(wlp61s0)[21391]: Found user 'avahi-autoipd' 
(UID 107) and group 'avahi-autoipd' (GID 113)
Dec 11 18:45:18 zira avahi-autoipd(wlp61s0)[21391]: Successfully called 
chroot().
Dec 11 18:45:18 zira avahi-autoipd(wlp61s0)[21391]: Successfully dropped root 
privileges.
Dec 11 18:45:18 zira avahi-autoipd(wlp61s0)[21391]: Starting with address 
169.254.12.91
Dec 11 18:45:24 zira avahi-autoipd(wlp61s0)[21391]: Callout BIND, address 
169.254.12.91 on interface wlp61s0
Dec 11 18:45:24 zira avahi-daemon[782]: Joining mDNS multicast group on 
interface wlp61s0.IPv4 with address 169.254.12.91.
Dec 11 18:45:24 zira avahi-daemon[782]: New relevant interface wlp61s0.IPv4 for 
mDNS.
Dec 11 18:45:24 zira avahi-daemon[782]: Registering new address record for 
169.254.12.91 on wlp61s0.IPv4.
Dec 11 18:45:28 zira avahi-autoipd(wlp61s0)[21391]: Successfully claimed IP 
address 169.254.12.91

There are no issues when I connect to this hotspot with my phone
under Android.

Any idea?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Appuntamento con il nuovo ciclo di lectiones magistrales di AFIP International

[Sprea Editori]

Se non visualizzi correttamente questo messaggio, clicca qui: 
http://www.mailant.it/nl.aspx?idp=14715=101034=0E2FA94E582CE1334891A9A307CD9E07B21F6098=12519745=386ADF570F8535868AE0B09784ECDAC716E27BDE
  

Appuntamento con il nuovo ciclo di lectiones magistrales di AFIP International

[Sprea Editori]

Se non visualizzi correttamente questo messaggio, clicca qui: 
http://www.mailant.it/nl.aspx?idp=14715=101034=0E2FA94E582CE1334891A9A307CD9E07B21F6098=6421466=C2F74DC7FF7DE5C6E74FC3EA179281DAB8674E39
  

Re: About /dev/sr impatience with automatic tray loading

[Gene Heskett]

On Tuesday 11 December 2018 12:31:46 Greg Wooledge wrote:

> On Tue, Dec 11, 2018 at 06:22:56PM +0100, Thomas Schmitt wrote:
> > Dan Ritter wrote:
> > > The English use it more than Americans do.
> >
> > In school it was a big deal to distinguish "will" and "shall".
> > (I was very eager to forget the exact rules when nobody cared any
> > more.)
>
> Americans (at least in my part of the country) never use "shall" at
> all.  To us, it simply sounds archaic.  We'd expect it in the King
> James Bible, or in certain kinds of fantasy literature.

Or in legal here in the US, where "may" tends to mean never for 
personal/political reasons on the part of the county official in charge 
and "shall" says will without a personal choice in the matter. We only 
changed one word in a law from may to shall, 20+ years ago which the 
same statewide. That was huge.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: About /dev/sr impatience with automatic tray loading

[Tony van der Hoff]

On 11/12/18 17:31, Greg Wooledge wrote:
> On Tue, Dec 11, 2018 at 06:22:56PM +0100, Thomas Schmitt wrote:
>> Dan Ritter wrote:
>>> The English use it more than Americans do.
>>
>> In school it was a big deal to distinguish "will" and "shall".
>> (I was very eager to forget the exact rules when nobody cared any more.)
> 
> Americans (at least in my part of the country) never use "shall" at
> all.  To us, it simply sounds archaic.  We'd expect it in the King James
> Bible, or in certain kinds of fantasy literature.
> 

Not the bible, but pretty close:
https://www.ietf.org/rfc/rfc2119.txt


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

Re: Servidor bloqueado por copiar ficheros

[Alex Ivan Rosero Trujillo]

Unsuscribe

El mar., 11 de dic. de 2018 12:05 p. m., Gonzalo Rivero <
fishfromsa...@gmail.com> escribió:

> El mar, 11-12-2018 a las 09:07 -0600, Paynalton escribió:
> >
> >
> > El mar., 11 dic 2018 9:04 a. m., Josu Lazkano  > > escribió:
> > > Buenas,
> > >
> > > El servidor tiene 2GB de memoria.
> > >
> > > Para memtest, ¿cual instalo?
> >
> > Ninguno, se tiene que correr desde un live.
> >
>
> en realidad no hace falta un live cd/usb: te crea una entrada extra en
> el grub desde donde arrancan los test
> Para estar seguro podés hacer
>
>   apt-cache show 
>
> y lees la descripción a ver cual te conviene, pero yo diría el primero
>
>
> > > # apt-cache search memtest
> > > memtest86 - thorough real-mode memory tester
> > > memtest86+ - thorough real-mode memory tester
> > > memtester - Utility for testing the memory subsystem
> > >
> > > Inodos:
> > >
> > > # df -i
> > > S.ficheros   Nodos-i NUsados   NLibres NUso% Montado en
> > > udev  249590 3962491941% /dev
> > > tmpfs 252373 5902517831% /run
> > > /dev/sda1   15138816  176341  149624752% /
> > > tmpfs 252373   12523721% /dev/shm
> > > tmpfs 252373   32523701% /run/lock
> > > tmpfs 252373  152523581% /sys/fs/cgroup
> > > /dev/sdc1   61054976  183958  608710181% /mnt/data2
> > > /dev/sde1  122101760  183958 1219178021% /mnt/2TBUSB
> > > /dev/sdd1  244195328   65003 2441303251% /mnt/data3
> > > /dev/sdb1   61054976   17837  610371391% /mnt/data1
> > > tmpfs 252373  102523631% /run/user/0
> >
> > Se ve bien, no parece que tuvieras llenos los inodes.
> >
> > > Gracias por vuestra ayuda.
> > >
> > > Un saludo.
> > >
> > > El mar., 11 dic. 2018 13:40, Matias Mucciolo <
> > > mmucci...@suteba.org.ar> escribió:
> > > >
> > > >
> > > > On Monday, December 10, 2018 10:04:47 PM -03 Josu Lazkano wrote:
> > > > > Buenas noches,
> > > > >
> > > > > Estoy teniendo problemas en mi servidor Debian:
> > > > >
> > > > > # uname -a
> > > > > Linux servidor 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-
> > > > 27) x86_64
> > > > > GNU/Linux
> > > > >
> > > > >
> > > > > Cada vez que copio grandes volúmenes de ficheros (500GB en
> > > > ficheros de
> > > > > 40MB), se queda bloqueado y esto es lo que sale en el dmesg:
> > > > > https://paste.debian.net/1055220/
> > > > >
> > > > > Hasta ahora no me había pasado, ¿puede que sea problema de
> > > > memoria?
> > > > >
> > > > > Entiendo que al estar copiando grandes de volúmenes de
> > > > información vaya mas
> > > > > despacio, pero que se bloque completamente no lo entiendo.
> > > > >
> > > > > Agradezco cualquier ayuda, no se que mas mirar.
> > > > >
> > > > > Un saludo.
> > > > >
> > > > > --
> > > > > Josu Lazkano
> > > >
> > > > Buenas Josu
> > > > pregutna cuanto ram tiene ese servidor ?
> > > >
> > > > saludos
> > > > Matias.-
>
>

-- 


*Hacia una
Universidad comprometida con la Paz Territorial*

Re: installer debian sans interface graphique

[Bernard Schoenacker]

- Mail original -
> De: "Samy Mezani" 
> À: "Liste Debian-fr" 
> Envoyé: Mardi 11 Décembre 2018 17:47:10
> Objet: Re: installer debian sans interface graphique
> 
> Bonjour Bernard,
> 
> Le 11/12/2018 à 16:27, Bernard Schoenacker a écrit :
> [...]
> 
> Tu as tenté l'option '-display curses' ou '-curses' ?
> 
> Samy
> 

bonjour,

merci pour le bonnet d'âne, je ne connaissais pas cette option

merci

slt
bernard

Re: About /dev/sr impatience with automatic tray loading

[Greg Wooledge]

On Tue, Dec 11, 2018 at 06:22:56PM +0100, Thomas Schmitt wrote:
> Dan Ritter wrote:
> > The English use it more than Americans do.
> 
> In school it was a big deal to distinguish "will" and "shall".
> (I was very eager to forget the exact rules when nobody cared any more.)

Americans (at least in my part of the country) never use "shall" at
all.  To us, it simply sounds archaic.  We'd expect it in the King James
Bible, or in certain kinds of fantasy literature.

Re: Debian social

[Marek Mosiewicz]

W dniu 11.12.2018, wto o godzinie 14∶09 +, użytkownik Joe napisał:
> On Tue, 11 Dec 2018 09:16:01 + (UTC)
> Curt  wrote:
> 
> > On 2018-12-10, Cindy-Sue Causey  wrote:
> > > 
> > > Beyond that, I *thought* I remembered a few times seeing long
> > > threads being (politely) advised to move it on over to offtopic,
> > > meaning the listserv I thought I remembered..
> > >  
> > 
> > Yeah, but apparently the off-topic group was consistently drifting
> > on topic to the point where many were advised to move there
> > technical
> > prolixities and proclivities over here (and vice versa, of course,
> > as
> > you've pointed out).
> > 
> > You can't win.
> > 
> 
> As I've pointed out before, this list is named debian-*user*, not
> debian-technical-things-only-or-you-will-burn-in-hell-for-eternity.
apt install debian-technical-things-only-or-you-will-burn-in-hell-for-
eternity
> 
> Debain users will mostly talk about Debian issues, but not
> necessarily
> exclusively.
> 

Re: About /dev/sr impatience with automatic tray loading

[Thomas Schmitt]

Hi,

i wrote:
> > This function shall obtain the drive status and not wait until the
> > status of the medium is decided.

mick crane wrote:
> I have noticed that people whose first language might not be english use
> "shall" as apposed to "will" or "should".

The topic has its own wikipedia article:
  https://en.wikipedia.org/wiki/Shall_and_will

In german it is "soll" (= shall/demanding), "sollte" (= should/proposing),
and "wird" (= will/predicting or shall/predicting).

I meant it in the way of technical specification of purpose.


Dan Ritter wrote:
> The English use it more than Americans do.

In school it was a big deal to distinguish "will" and "shall".
(I was very eager to forget the exact rules when nobody cared any more.)


I wrote:
> > I [...] needed several curious attempts during 2.5 years to finally
> > understand what happened.

Gene Heskett wrote:
> with better tools that I.

Only fgrep in local /usr/src/linux-source-3.16 and linux-4.1.6 and
Iceweasel were involved.

In the end it was about reading all commits to sr.c, sr_ioctl.c, and
cdrom.c since the release of kernel 2.6.18 (where i knew that the bug
was not in) up to 3.16 (where i first experienced the bug).
Like
  https://github.com/torvalds/linux/commits/master/drivers/scsi/sr.c

As said, i was very curious.


Have a nice day :)

Thomas

Re: Servidor bloqueado por copiar ficheros

[Gonzalo Rivero]

El mar, 11-12-2018 a las 09:07 -0600, Paynalton escribió:
> 
> 
> El mar., 11 dic 2018 9:04 a. m., Josu Lazkano  > escribió:
> > Buenas,
> > 
> > El servidor tiene 2GB de memoria.
> > 
> > Para memtest, ¿cual instalo?
> 
> Ninguno, se tiene que correr desde un live.
> 

en realidad no hace falta un live cd/usb: te crea una entrada extra en
el grub desde donde arrancan los test
Para estar seguro podés hacer 

  apt-cache show  

y lees la descripción a ver cual te conviene, pero yo diría el primero


> > # apt-cache search memtest
> > memtest86 - thorough real-mode memory tester
> > memtest86+ - thorough real-mode memory tester
> > memtester - Utility for testing the memory subsystem
> > 
> > Inodos:
> > 
> > # df -i
> > S.ficheros   Nodos-i NUsados   NLibres NUso% Montado en
> > udev  249590 3962491941% /dev
> > tmpfs 252373 5902517831% /run
> > /dev/sda1   15138816  176341  149624752% /
> > tmpfs 252373   12523721% /dev/shm
> > tmpfs 252373   32523701% /run/lock
> > tmpfs 252373  152523581% /sys/fs/cgroup
> > /dev/sdc1   61054976  183958  608710181% /mnt/data2
> > /dev/sde1  122101760  183958 1219178021% /mnt/2TBUSB
> > /dev/sdd1  244195328   65003 2441303251% /mnt/data3
> > /dev/sdb1   61054976   17837  610371391% /mnt/data1
> > tmpfs 252373  102523631% /run/user/0
> 
> Se ve bien, no parece que tuvieras llenos los inodes.
> 
> > Gracias por vuestra ayuda.
> > 
> > Un saludo.
> > 
> > El mar., 11 dic. 2018 13:40, Matias Mucciolo <
> > mmucci...@suteba.org.ar> escribió:
> > >  
> > > 
> > > On Monday, December 10, 2018 10:04:47 PM -03 Josu Lazkano wrote:
> > > > Buenas noches,
> > > > 
> > > > Estoy teniendo problemas en mi servidor Debian:
> > > > 
> > > > # uname -a
> > > > Linux servidor 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-
> > > 27) x86_64
> > > > GNU/Linux
> > > > 
> > > > 
> > > > Cada vez que copio grandes volúmenes de ficheros (500GB en
> > > ficheros de
> > > > 40MB), se queda bloqueado y esto es lo que sale en el dmesg:
> > > > https://paste.debian.net/1055220/
> > > > 
> > > > Hasta ahora no me había pasado, ¿puede que sea problema de
> > > memoria?
> > > > 
> > > > Entiendo que al estar copiando grandes de volúmenes de
> > > información vaya mas
> > > > despacio, pero que se bloque completamente no lo entiendo.
> > > > 
> > > > Agradezco cualquier ayuda, no se que mas mirar.
> > > > 
> > > > Un saludo.
> > > > 
> > > > --
> > > > Josu Lazkano
> > > 
> > > Buenas Josu
> > > pregutna cuanto ram tiene ese servidor ?
> > > 
> > > saludos
> > > Matias.-

Re: Debian social

[Curt]

On 2018-12-11, Joe  wrote:
>
>> On 2018-12-10, Cindy-Sue Causey  wrote:
>> >
>> > Beyond that, I *thought* I remembered a few times seeing long
>> > threads being (politely) advised to move it on over to offtopic,
>> > meaning the listserv I thought I remembered..
>> >  
>> 
>> Yeah, but apparently the off-topic group was consistently drifting
>> on topic to the point where many were advised to move there technical
>> prolixities and proclivities over here (and vice versa, of course, as
>> you've pointed out).
>> 
>> You can't win.
>> 
>
> As I've pointed out before, this list is named debian-*user*, not
> debian-technical-things-only-or-you-will-burn-in-hell-for-eternity.

Did I say that? 

What you quoted up there of mine (where I said there instead of their
up there) was an attempt at jocularity. I know you're the moral arbiter
around these parts, repeating yourself and pointing things out and all,
but give me a break.
 
> Debain users will mostly talk about Debian issues, but not necessarily
> exclusively.
>


-- 
He used sentences differently from any other prose writer. He always sounded
like a slightly drunk man who is very melancholy, who has no illusions about
life, who is very strong but whose strength is entirely unnecessary.
--Krasznahorkai on Krúdy

Re: About /dev/sr impatience with automatic tray loading

[Gene Heskett]

On Tuesday 11 December 2018 06:25:43 Thomas Schmitt wrote:

> Hi,
>
> i wrote:
> > > I know some more such dumplings.
>
> Gene Heskett wrote:
> > So do I, Thomas, but this is supposedly a polite list. :)
>
> I actually meant the bugs, not the bug makers whose sympathy is
> probably needed to ever get the bugs fixed.

+1 :)

> (When pointing with one finger at others, three fingers are pointing
> back to oneself ...)
>
Absolutely.

> The tray loading bug is not as embarrassing as the SG_IO concurrency
> bug (two concurrent burns on different /dev/sr are awfully slow) and
> the CD read-ahead bug (i/o errors when trying to read valid blocks
> near the end of a CD that was written with write type Track-At-Once).
>
> > >   http://lkml.iu.edu/hypermail//linux/kernel/0807.0/0287.html
> > > (The culprits already suffered duely. Hehehe.)
> >
> > And rather than fix it, walked away.
>
> They fixed several negative consequences of the necessary change.
> But obviously they did not assess all callers of sr_drive_status()
> whether they depended on the loop at its inappropriate position in the
> code. I did not, either, but only found one left-over and needed
> several curious attempts during 2.5 years to finally understand what
> happened.
>
And you've obviously worn that detective hat, with better tools that I.
>
> Have a nice day :)

Yourself too Thomas. I see by gkrellm that we may have a slow thaw, its 
up to 0.6C, at the airport 16 miles northeast and I may be able to put 
the finishing cuts on a back box panel that will bring my bigger milling 
machine back to life eventually. Not a lot of heat in that building with 
its small machines though. Just enough to keep the machinery above the 
dew point and major rusting, but not enough to keep my diabetic feet 
warm. One of the hazards of the ultimate revenge, outliveing ones last 
enemy by a decade+. ;-)

> Thomas

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: syslog

[Eriel Perez]

gracias!. era eso mismo. ya me estaba volviendo loco.

On 12/11/2018 11:41 AM, Greg Wooledge wrote:

On Tue, Dec 11, 2018 at 11:29:28AM -0500, Eriel Perez wrote:

(*system*) ERROR (Missing newline before EOF, this crontab file will be
ignored)

Add the missing newline.  If you use vi/vim, this happens automatically
and you cannot stop it.  If you use something else, maybe you just have
to press Enter at the end of the line or something.

Re: installer debian sans interface graphique

[Samy Mezani]

Bonjour Bernard,

Le 11/12/2018 à 16:27, Bernard Schoenacker a écrit :
[...]

voici l'erreur :

qemu-system-x86_64 -hda /var/vm/Debianvm.qcow2 -cdrom 
debian-9.6.0-amd64-netinst.iso -boot d
gtk initialization failed
zsh: exit 1 qemu-system-x86_64 -hda /var/vm/Debianvm.qcow2 -cdrom  -boot d


Tu as tenté l'option '-display curses' ou '-curses' ?

Samy

Re: Tuto Debian-Facile/preseed: clé USB non bootable [RESOLU]

[Olivier]

[3]
https://askubuntu.com/questions/791238/how-to-convert-a-iso9660-iso-to-a-usb-iso

Le mar. 11 déc. 2018 à 17:05, Olivier  a écrit :

> J'ai trouvé le lien [2] qui me laisse penser que la différence entre mes
> deux fichiers .iso est que l'un est hybride, l'autre pas.
> Je ne l'avais pas précisé mais la machine avec laquelle j'essaie de créer
> ma clé bootable est encore sous Jessie.
>
> Le lien [3] indique comment convertir une iso9660 en iso hybride.
> En suivant ses instructions, j'ai pu créé une image hybride et booter
> dessus !
>
>
> [2]
> https://www.ostechnix.com/bootiso-lets-you-safely-create-bootable-usb-drive/
>
> Le mar. 11 déc. 2018 à 15:27, Bernard Schoenacker <
> bernard.schoenac...@free.fr> a écrit :
>
>>
>> - Mail original -
>>
>> > De: "Olivier" 
>> > À: "ML Debian User French" 
>> > Envoyé: Mardi 11 Décembre 2018 15:22:54
>> > Objet: Re: Tuto Debian-Facile/preseed: clé USB non bootable
>>
>> > Le mar. 11 déc. 2018 à 15:11, roger gm < rhb...@gmail.com > a écrit :
>>
>> > La commande dd donne une clé bootable avec mon fichier
>> > firmware_xxx.iso mais une clé non-bootable avec mon fichier
>> > custom_install.iso.
>> > Le mystère demeure ...
>>
>> bonjour,
>>
>> voici le mode opératoire suivant le tuto à lire :
>>
>>
>> https://www.linuxquestions.org/questions/linux-newbie-8/how-to-a-bootable-flag-on-usb-stick-664033/
>>
>> merci
>> slt
>> bernard
>>
>

Re: syslog

[Greg Wooledge]

On Tue, Dec 11, 2018 at 11:29:28AM -0500, Eriel Perez wrote:
> (*system*) ERROR (Missing newline before EOF, this crontab file will be
> ignored)

Add the missing newline.  If you use vi/vim, this happens automatically
and you cannot stop it.  If you use something else, maybe you just have
to press Enter at the end of the line or something.

Re: Automatiser la configuration initiale de machines physiques

[Olivier]

Le lun. 19 nov. 2018 à 20:09, Étienne Mollier 
a écrit :

>
>
> http://fai-project.org/
> http://fai-project.org/fai-guide/
>
>
>
Bonjour Étienne,

Merci pour ces conseils.

En effet semble une solution intéressante, d'autant que de mémoire, pas mal
de machines bootent
par défaut par le réseau.

Il me reste plusieurs questions:

1. Je trouve preseed extrêmement difficile à maîtriser. FAI simplifie-t-il
les choses à cet égard ?
Je pense en particulier au partitionnement des disques.

2. Est-il exact de penser que FAI est adapté une installation sur un réseau
local, pas sur un WAN, à cause de l'utilisation de TFTP ou bien est-ce
inexact ?

Slts

PS: Désolé pour le temps mis pour réagir aux messages mais j'ai été happé
par d'autres priorités.

syslog

[Eriel Perez]

colegas

tengo este error en el syslog


(*system*) ERROR (Missing newline before EOF, this crontab file will be 
ignored)



Alguna idea? esta en el fichero de rotacion de las trazas.


40 8    * * *    root    /usr/local/sbin/trazas.sh


la linea arriba es la que esta en el crontab (/etc/crontab) el cron no 
corre bien la tarea. no ejecuta el script.

Re: Tuto Debian-Facile/preseed: clé USB non bootable [RESOLU]

[Olivier]

J'ai trouvé le lien [2] qui me laisse penser que la différence entre mes
deux fichiers .iso est que l'un est hybride, l'autre pas.
Je ne l'avais pas précisé mais la machine avec laquelle j'essaie de créer
ma clé bootable est encore sous Jessie.

Le lien [3] indique comment convertir une iso9660 en iso hybride.
En suivant ses instructions, j'ai pu créé une image hybride et booter
dessus !


[2]
https://www.ostechnix.com/bootiso-lets-you-safely-create-bootable-usb-drive/

Le mar. 11 déc. 2018 à 15:27, Bernard Schoenacker <
bernard.schoenac...@free.fr> a écrit :

>
> - Mail original -
>
> > De: "Olivier" 
> > À: "ML Debian User French" 
> > Envoyé: Mardi 11 Décembre 2018 15:22:54
> > Objet: Re: Tuto Debian-Facile/preseed: clé USB non bootable
>
> > Le mar. 11 déc. 2018 à 15:11, roger gm < rhb...@gmail.com > a écrit :
>
> > La commande dd donne une clé bootable avec mon fichier
> > firmware_xxx.iso mais une clé non-bootable avec mon fichier
> > custom_install.iso.
> > Le mystère demeure ...
>
> bonjour,
>
> voici le mode opératoire suivant le tuto à lire :
>
>
> https://www.linuxquestions.org/questions/linux-newbie-8/how-to-a-bootable-flag-on-usb-stick-664033/
>
> merci
> slt
> bernard
>

Re: Tuto Debian-Facile/preseed: clé USB non bootable

[Dumont, Dominique (CWP)]

On Tue, 2018-12-11 at 14:46 +0100, Olivier wrote:
> J'ai dans mon répertoire courant, le fichier :
> $ file custom_install.iso 
> custom_install.iso: ISO 9660 CD-ROM filesystem data 'CDROM'
> (bootable)

Cette image ne contient pas de MBR. Elle est bootable uniquement à
partir d'un CD ou DVD.

> 
> À titre de comparaison, j'ai aussi:
> $ file firmware-9.6.0-amd64-i386-netinst.iso 
> firmware-9.6.0-amd64-i386-netinst.iso: DOS/MBR boot sector ISO 9660
> CD-ROM filesystem data 'Debian 9.6.0 M-A 1' (bootable); partition 2 :
> ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63),
> startsector 4256, 1376 sectors
> 

Celle-ci a un MBR. C'est une image "isohybrid" (cf 
https://www.debian.org/CD/faq/#write-usb). Bootable avec un CD DVD ou
USB key.

Faut revoir la procédure utilisée pour générer custom_install.iso

HTH

Re: Servidor bloqueado por copiar ficheros

[Matias Mucciolo]

On Tuesday, December 11, 2018 4:04:08 PM -03 Josu Lazkano wrote:
> Buenas,
> 
> El servidor tiene 2GB de memoria.
> 
> Para memtest, ¿cual instalo?
> 
> # apt-cache search memtest
> memtest86 - thorough real-mode memory tester
> memtest86+ - thorough real-mode memory tester
> memtester - Utility for testing the memory subsystem
> 
> Inodos:
> 
> # df -i
> S.ficheros   Nodos-i NUsados   NLibres NUso% Montado en
> udev  249590 3962491941% /dev
> tmpfs 252373 5902517831% /run
> /dev/sda1   15138816  176341  149624752% /
> tmpfs 252373   12523721% /dev/shm
> tmpfs 252373   32523701% /run/lock
> tmpfs 252373  152523581% /sys/fs/cgroup
> /dev/sdc1   61054976  183958  608710181% /mnt/data2
> /dev/sde1  122101760  183958 1219178021% /mnt/2TBUSB
> /dev/sdd1  244195328   65003 2441303251% /mnt/data3
> /dev/sdb1   61054976   17837  610371391% /mnt/data1
> tmpfs 252373  102523631% /run/user/0
> 
> Gracias por vuestra ayuda.
> 
> Un saludo.
> 
> El mar., 11 dic. 2018 13:40, Matias Mucciolo 
> 
> escribió:
> > On Monday, December 10, 2018 10:04:47 PM -03 Josu Lazkano wrote:
> > > Buenas noches,
> > > 
> > > Estoy teniendo problemas en mi servidor Debian:
> > > 
> > > # uname -a
> > > Linux servidor 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64
> > > GNU/Linux
> > > 
> > > 
> > > Cada vez que copio grandes volúmenes de ficheros (500GB en ficheros de
> > > 40MB), se queda bloqueado y esto es lo que sale en el dmesg:
> > > https://paste.debian.net/1055220/
> > > 
> > > Hasta ahora no me había pasado, ¿puede que sea problema de memoria?
> > > 
> > > Entiendo que al estar copiando grandes de volúmenes de información vaya
> > 
> > mas
> > 
> > > despacio, pero que se bloque completamente no lo entiendo.
> > > 
> > > Agradezco cualquier ayuda, no se que mas mirar.
> > > 
> > > Un saludo.
> > > 
> > > --
> > > Josu Lazkano
> > 
> > Buenas Josu
> > pregutna cuanto ram tiene ese servidor ?
> > 
> > saludos
> > Matias.-



POrfavor a todos los integrantes de la lista ...no hagan top posting..
contesten siempre abajo del original o a lo sumo entre-medio..

Josu a mi parecre por el error el tema es que la memoria se fragmenta tanto
que no puede "allocar" una pagina..

veo que esta usando la mitad de la swap 1gb de 2gb aprox.
despeus de que haces la prueba de subir los archivos y te aparece el error

cual es la salida de este comando ?

cat /sys/kernel/debug/extfrag/extfrag_index

y que estas usando para subir files ?

Matias.-

installer debian sans interface graphique

[Bernard Schoenacker]

bonjour,

je recherche une solution pour installer une debian
sans interface graphique, comment faire ?

je part sur une virtualisation sur Qemu (openBSD)

voici l'erreur :

qemu-system-x86_64 -hda /var/vm/Debianvm.qcow2 -cdrom 
debian-9.6.0-amd64-netinst.iso -boot d 
gtk initialization failed
zsh: exit 1 qemu-system-x86_64 -hda /var/vm/Debianvm.qcow2 -cdrom  -boot d

source :
https://yeuxdelibad.net/ah/#toc173

merci
slt
bernard

Re: Pacote para automação de bibliotecas e acervos de livros?

[Guimarães Faria Corcete DUTRA , Leandro]

Le lun. 10 déc. 2018 à 22:33, Bruno Buys  a écrit :
>
> - se for o caso de optar por outro pacote, alguém teria sugestões?

O Evergreen é o único escalável, por ser baseado em PostgreSQL. O Koha
ainda está se preparando para suportar PostgreSQL, e portanto para
escalar exige muita máquina e cuidados.  Mesmo quando migrar,
provavelmente será menos eficiente que o Evergreen, já criado em
PostgreSQL.  O artigo sobre ele na Wikipedia
https://en.wikipedia.org/wiki/Evergreen_(software) tem, no final, uma
lista de outras alternativas.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm

Re: Servidor bloqueado por copiar ficheros

[Paynalton]

El mar., 11 dic 2018 9:04 a. m., Josu Lazkano 
escribió:

> Buenas,
>
> El servidor tiene 2GB de memoria.
>
> Para memtest, ¿cual instalo?
>

Ninguno, se tiene que correr desde un live.


> # apt-cache search memtest
> memtest86 - thorough real-mode memory tester
> memtest86+ - thorough real-mode memory tester
> memtester - Utility for testing the memory subsystem
>
> Inodos:
>
> # df -i
> S.ficheros   Nodos-i NUsados   NLibres NUso% Montado en
> udev  249590 3962491941% /dev
> tmpfs 252373 5902517831% /run
> /dev/sda1   15138816  176341  149624752% /
> tmpfs 252373   12523721% /dev/shm
> tmpfs 252373   32523701% /run/lock
> tmpfs 252373  152523581% /sys/fs/cgroup
> /dev/sdc1   61054976  183958  608710181% /mnt/data2
> /dev/sde1  122101760  183958 1219178021% /mnt/2TBUSB
> /dev/sdd1  244195328   65003 2441303251% /mnt/data3
> /dev/sdb1   61054976   17837  610371391% /mnt/data1
> tmpfs 252373  102523631% /run/user/0
>

Se ve bien, no parece que tuvieras llenos los inodes.


> Gracias por vuestra ayuda.
>
> Un saludo.
>
> El mar., 11 dic. 2018 13:40, Matias Mucciolo 
> escribió:
>
>>
>>
>> On Monday, December 10, 2018 10:04:47 PM -03 Josu Lazkano wrote:
>> > Buenas noches,
>> >
>> > Estoy teniendo problemas en mi servidor Debian:
>> >
>> > # uname -a
>> > Linux servidor 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64
>> > GNU/Linux
>> >
>> >
>> > Cada vez que copio grandes volúmenes de ficheros (500GB en ficheros de
>> > 40MB), se queda bloqueado y esto es lo que sale en el dmesg:
>> > https://paste.debian.net/1055220/
>> >
>> > Hasta ahora no me había pasado, ¿puede que sea problema de memoria?
>> >
>> > Entiendo que al estar copiando grandes de volúmenes de información vaya
>> mas
>> > despacio, pero que se bloque completamente no lo entiendo.
>> >
>> > Agradezco cualquier ayuda, no se que mas mirar.
>> >
>> > Un saludo.
>> >
>> > --
>> > Josu Lazkano
>>
>> Buenas Josu
>> pregutna cuanto ram tiene ese servidor ?
>>
>> saludos
>> Matias.-
>>
>

Re: Servidor bloqueado por copiar ficheros

[Josu Lazkano]

Buenas,

El servidor tiene 2GB de memoria.

Para memtest, ¿cual instalo?

# apt-cache search memtest
memtest86 - thorough real-mode memory tester
memtest86+ - thorough real-mode memory tester
memtester - Utility for testing the memory subsystem

Inodos:

# df -i
S.ficheros   Nodos-i NUsados   NLibres NUso% Montado en
udev  249590 3962491941% /dev
tmpfs 252373 5902517831% /run
/dev/sda1   15138816  176341  149624752% /
tmpfs 252373   12523721% /dev/shm
tmpfs 252373   32523701% /run/lock
tmpfs 252373  152523581% /sys/fs/cgroup
/dev/sdc1   61054976  183958  608710181% /mnt/data2
/dev/sde1  122101760  183958 1219178021% /mnt/2TBUSB
/dev/sdd1  244195328   65003 2441303251% /mnt/data3
/dev/sdb1   61054976   17837  610371391% /mnt/data1
tmpfs 252373  102523631% /run/user/0

Gracias por vuestra ayuda.

Un saludo.

El mar., 11 dic. 2018 13:40, Matias Mucciolo 
escribió:

>
>
> On Monday, December 10, 2018 10:04:47 PM -03 Josu Lazkano wrote:
> > Buenas noches,
> >
> > Estoy teniendo problemas en mi servidor Debian:
> >
> > # uname -a
> > Linux servidor 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64
> > GNU/Linux
> >
> >
> > Cada vez que copio grandes volúmenes de ficheros (500GB en ficheros de
> > 40MB), se queda bloqueado y esto es lo que sale en el dmesg:
> > https://paste.debian.net/1055220/
> >
> > Hasta ahora no me había pasado, ¿puede que sea problema de memoria?
> >
> > Entiendo que al estar copiando grandes de volúmenes de información vaya
> mas
> > despacio, pero que se bloque completamente no lo entiendo.
> >
> > Agradezco cualquier ayuda, no se que mas mirar.
> >
> > Un saludo.
> >
> > --
> > Josu Lazkano
>
> Buenas Josu
> pregutna cuanto ram tiene ese servidor ?
>
> saludos
> Matias.-
>

Re: [OT] Howto use an environment that doesn't make use of GL for basic tasks

[Dan Ritter]

riveravaldez wrote: 
> > Anything visible in your logs?
> 
> And this is what I get after just boot and log-in to desktop (just fluxbox):
> 
> $ sudo dmesg | grep nouveau
> [   10.172253] nouveau :00:0d.0: NVIDIA C61 (04c000a2)
> [   10.420487] nouveau :00:0d.0: fb0: nouveaufb frame buffer device
> [   10.448078] [drm] Initialized nouveau 1.3.1 20120801 for
> :00:0d.0 on minor 0

Clipped to the most useful lines.


> > Does it happen more often when your machine has been on for a longer time?
> 
> No, it happens randomly. In some occasions I've been able to work for
> a couple of days without hanging, but other times it hangs a couple of
> minutes after being logged. Usually it hangs in less than an hour... I
> have to reboot by pressing reset button. Nothing else works.

This means that it's not a heat problem. OK.

> > What kind of hardware do you have?
> 
> $ lspci -kv
> 00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce
> 7025 / nForce 630a] (rev a2) (prog-if 00 [VGA controller])
>   Subsystem: Gigabyte Technology Co., Ltd C61 [GeForce 7025 / nForce 630a]
>   Kernel driver in use: nouveau
>   Kernel modules: nouveau

I googled around, and sure enough, it looks like nouveau has problems with this
hardware. 

stretch-backports non-free has 390.87-2~bpo9+1 which might help;
if not, you should consider installing a new video card if
that's an option. The cheapest new-in-box video cards are around
$35 US, and will (a) work properly and (b) be noticeably faster
than what you have now, if it were working.

-dsr- 

usb-disk path change and idle spindown

[segfredo]

Hello

it sems some recent update made my usb-disks appear as
/dev/disk/by-id/usb-Seagate_M3_Portabable...
indstead of
/dev/disk/by-id/ata-ST4000LM024...

nbd BUT they no longer spindown automatically and hdparm throws some error

# hdparm -S55 /dev/disk/by-id/usb-Seagate_M3_Portable_...
/dev/disk/by-id/usb-Seagate_M3_Portable_NM137HMP-0:0:
setting standby to 55 (4 minutes + 35 seconds)
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 24 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

can i fix this somehow or make the drives appear as ata- again?

cheers
Segfredo

Re: About /dev/sr impatience with automatic tray loading

[Dan Ritter]

mick crane wrote: 
> On 2018-12-10 20:02, Thomas Schmitt wrote:
> > For the purpose of sr_drive_status(), the loop is really inappropriate.
> > This function shall obtain the drive status and not wait until the
> > status of the medium is decided.
> > 
 
> completely off the topic but I have noticed that people whose first language
> might not be english use
> "shall" as apposed to "will" or "should". It seems a little bit old
> fashioned but maybe it isn't.

The English use it more than Americans do.

"Shall" has a connotation of ordering future action. Americans
nearly always prefer "should".

"Will" is a prediction of future action. 

"Should" is a desire for future action, with an acknowledgment
that it might not go that way. In a question, it asks for
advice on desirability.

"May" is a speculation on future action, with less certainty and
less imputed desire. In a question it asks for permission.

"Can" is a description of a possible future action, and
sometimes carries the connotation that the action is
appropriate. Americans like to use this instead of "may", but
they generally know that "may" is permission and "can" is
capability.

"Might" is either used to request permission or to describe a
low-probability future action. Americans rarely use this this
in question form.

-dsr- (American/British hybrid)

Re: Tuto Debian-Facile/preseed: clé USB non bootable

[Olivier]

Le mar. 11 déc. 2018 à 15:11, roger gm  a écrit :

> Le Tue, 11 Dec 2018 14:46:26 +0100,
> Olivier  a écrit :
>
> > Bonjour,
> Bonjour
> >
> >
> >
> > Qui a une explication ?
>
> Je n'ai pas d'explication mais tu peux utiliser la commande dd pour la
> création de clé usb bootable:
> https://debian-facile.org/doc:install:usb-boot
>
> > Quelle commande me permettrait de copier ce fichier
> > custom_install.iso sur ma clé USB et faire que celle-ci soit
> > bootable ?
> >
> > Slts
> >
> > [1] https://debian-facile.org/doc:install:preseed?s[]=preseed
>
>
La commande dd donne une clé bootable avec mon fichier firmware_xxx.iso
mais une clé non-bootable avec mon fichier custom_install.iso.
Le mystère demeure ...

Re: Tuto Debian-Facile/preseed: clé USB non bootable

[roger gm]

Le Tue, 11 Dec 2018 14:46:26 +0100,
Olivier  a écrit :

> Bonjour,
Bonjour
> 
>
> 
> Qui a une explication ?

Je n'ai pas d'explication mais tu peux utiliser la commande dd pour la
création de clé usb bootable:
https://debian-facile.org/doc:install:usb-boot

> Quelle commande me permettrait de copier ce fichier
> custom_install.iso sur ma clé USB et faire que celle-ci soit
> bootable ?
> 
> Slts
> 
> [1] https://debian-facile.org/doc:install:preseed?s[]=preseed

Re: Debian social

[Joe]

On Tue, 11 Dec 2018 09:16:01 + (UTC)
Curt  wrote:

> On 2018-12-10, Cindy-Sue Causey  wrote:
> >
> > Beyond that, I *thought* I remembered a few times seeing long
> > threads being (politely) advised to move it on over to offtopic,
> > meaning the listserv I thought I remembered..
> >  
> 
> Yeah, but apparently the off-topic group was consistently drifting
> on topic to the point where many were advised to move there technical
> prolixities and proclivities over here (and vice versa, of course, as
> you've pointed out).
> 
> You can't win.
> 

As I've pointed out before, this list is named debian-*user*, not
debian-technical-things-only-or-you-will-burn-in-hell-for-eternity.

Debain users will mostly talk about Debian issues, but not necessarily
exclusively.

-- 
Joe

Re: Tuto Debian-Facile/preseed: clé USB non bootable

[Daniel Huhardeaux]

Le 11/12/2018 à 14:46, Olivier a écrit :

Bonjour,


Bonjour



J'ai découvert ce tuto [1].
Malheureusement, celui-ci ne détaille pas la dernière étape qui 
consiste à copier le fichier .iso créé sur une clé USB bootable.


J'ai dans mon répertoire courant, le fichier :
$ file custom_install.iso
custom_install.iso: ISO 9660 CD-ROM filesystem data 'CDROM' (bootable)

À titre de comparaison, j'ai aussi:
$ file firmware-9.6.0-amd64-i386-netinst.iso
firmware-9.6.0-amd64-i386-netinst.iso: DOS/MBR boot sector ISO 9660 
CD-ROM filesystem data 'Debian 9.6.0 M-A 1' (bootable); partition 2 : 
ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 
4256, 1376 sectors


Ma cible est une clé de 8Go sur /dev/sdc.

La commande ci-après produit une clé bootable;
sudo cat firmware-9.6.0-amd64-i386-netinst.iso > /dev/sdc

Par contre, la clé n'est pas bootable avec celle ci-après:
sudo cat custom_install.iso > /dev/sdc

Qui a une explication ?
Quelle commande me permettrait de copier ce fichier custom_install.iso 
sur ma clé USB et faire que celle-ci soit bootable ?


Slts

[1] https://debian-facile.org/doc:install:preseed?s[]=preseed


dd if=firmware-9.6.0-amd64-i386-netinst.iso bs=4M of=/dev/sdc

--
Daniel

Re: [OT] Howto use an environment that doesn't make use of GL for basic tasks

[riveravaldez]

>> asking on Nouveau's mailing-list they recommended me this:
>>
>> > Use an environment that doesn't make use of GL for basic tasks.
>
> You're already doing that. GL isn't the problem unless you're
> having non-random freezes when you fire up 3D applications.

Thanks for your answer, dsr. That's precisely not my case: I'm having
random freezes, for instance just opening Firefox, or doing nothing.

I can avoid this hangs/crashes by way of the kernel parameter
'nouveau.noaccel=1' at boot, and then everything works fine,
rock-stable, but I lose *a lot* of needed performance.
Without that parameter the system freezes randomly.

> Anything visible in your logs?

dmesg gives me a lot of these if I work without the kernel parameter
(and none with it):

[  309.817809] nouveau :00:0d.0: bus: MMIO write of 01370001 FAULT at 00b010
[  309.980527] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b010
[ 2027.812429] nouveau :00:0d.0: bus: MMIO write of 01360001 FAULT at 00b010
[ 2028.032100] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b010
[ 2107.686803] nouveau :00:0d.0: bus: MMIO write of 01290001 FAULT at 00b010
[ 2107.720941] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b010
[ 2233.743329] nouveau :00:0d.0: bus: MMIO write of 01440001 FAULT at 00b010
[ 2233.762308] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b010

[20793.040671] nouveau :00:0d.0: bus: MMIO write of 00e30001 FAULT at 00b010
[20793.117709] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b010
[39884.652487] nouveau :00:0d.0: bus: MMIO write of 00e40001 FAULT at 00b010
[39884.812393] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b010
[69224.309586] nouveau :00:0d.0: bus: MMIO write of 00e60001 FAULT at 00b010
[69224.425166] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b010
[78810.914420] nouveau :00:0d.0: bus: MMIO write of 00e60001 FAULT at 00b010
[78810.944150] nouveau :00:0d.0: bus: MMIO write of  FAULT at 00b010

Those are just some random examples.
And this is what I get after just boot and log-in to desktop (just fluxbox):

$ sudo dmesg | grep nouveau
[   10.172253] nouveau :00:0d.0: NVIDIA C61 (04c000a2)
[   10.182980] nouveau :00:0d.0: bios: version 05.61.32.29.00
[   10.183898] nouveau :00:0d.0: fb: 256 MiB of unknown memory type
[   10.235289] nouveau :00:0d.0: DRM: VRAM: 253 MiB
[   10.235290] nouveau :00:0d.0: DRM: GART: 512 MiB
[   10.235294] nouveau :00:0d.0: DRM: TMDS table version 1.1
[   10.235296] nouveau :00:0d.0: DRM: DCB version 3.0
[   10.235298] nouveau :00:0d.0: DRM: DCB outp 00: 01000310 0023
[   10.235301] nouveau :00:0d.0: DRM: DCB outp 01: 00110204 942b0003
[   10.235302] nouveau :00:0d.0: DRM: DCB conn 00: 
[   10.235304] nouveau :00:0d.0: DRM: DCB conn 01: 1131
[   10.235305] nouveau :00:0d.0: DRM: DCB conn 02: 0110
[   10.235307] nouveau :00:0d.0: DRM: DCB conn 03: 0111
[   10.235308] nouveau :00:0d.0: DRM: DCB conn 04: 0113
[   10.235528] nouveau :00:0d.0: DRM: Saving VGA fonts
[   10.272502] nouveau :00:0d.0: DRM: DCB type 4 not known
[   10.272504] nouveau :00:0d.0: DRM: Unknown-1 has no encoders, removing
[   10.275806] nouveau :00:0d.0: DRM: MM: using M2MF for buffer copies
[   10.304530] nouveau :00:0d.0: DRM: allocated 1600x900 fb:
0x9000, bo (ptrval)
[   10.304618] fbcon: nouveaufb (fb0) is primary device
[   10.420487] nouveau :00:0d.0: fb0: nouveaufb frame buffer device
[   10.448078] [drm] Initialized nouveau 1.3.1 20120801 for
:00:0d.0 on minor 0
[   16.573419] nouveau :00:0d.0: bus: MMIO write of 005c0001 FAULT at 00b000

> Does it happen more often when your machine has been on for a longer time?

No, it happens randomly. In some occasions I've been able to work for
a couple of days without hanging, but other times it hangs a couple of
minutes after being logged. Usually it hangs in less than an hour... I
have to reboot by pressing reset button. Nothing else works.

> What kind of hardware do you have?

$ lspci -kv
00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce
7025 / nForce 630a] (rev a2) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd C61 [GeForce 7025 / nForce 630a]
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21, NUMA node 0
Memory at fb00 (32-bit, non-prefetchable) [size=16M]
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at fc00 (64-bit, non-prefetchable) [size=16M]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: 
Kernel driver in use: nouveau
Kernel modules: nouveau

$ uname -a
Linux debian 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23)
x86_64 GNU/Linux

If anything else is useful please let me know.

> -dsr-

Thanks a lot! (really)

Re: Pacote para automação de bibliotecas e acervos de livros?

[Henrique]

  Mensagem Original  
De: br...@buys.net.br
Enviados: 10 de dezembro de 2018 22:33
Para: debian-user-portuguese@lists.debian.org
Assunto: Pacote para automação de bibliotecas e acervos de livros?

Fala povo,
Estou envolvido em um projeto para automatizar uma biblioteca de uma 
escola que está iniciando atividades. O próprio pessoal da escola 
recebeu uma sugestão de um software chamado Biblivre 
(www.biblivre.org.br). Fui pesquisar, e me pareceu que esse pacote está 
um pouco defasado em compatibilidade com GNU/Linux. A plataforma alvo 
deles parece ser windows. A versão mais atual é a 5, mas o tutorial 
disponível para GNU/Linux indica instalar a versão 3. Os documentos são 
de 2012, por aí.
Então, por isso, venho perguntar:

- alguém aqui tem experiência com o Biblivre? Recomenda?
---
Sim, tenho. Como vc mesmo disse, eh para windows; no Linux eh orientado a 
gambiarra. Não recomendo no Linux, jamais. Na verdade, nem pra windows. 
---
- se for o caso de optar por outro pacote, alguém teria sugestões?
. 
---
Koha. Tem repositório e tudo o mais que vc pediu abaixo, e muito mais coisa, 
muita mesmo. Roda **nativamente** em debian, usa mariadb e Perl. Vc instala em 
1minuto com apt-get e configura em pouco mais de 30min se souber o que está 
fazendo.

Eh **bastante** desejável que exista alguém com formação em biblioteconomia 
para ajudar a configurar o Koha. Eh um sistema completo. Dependendo das suas 
necessidades, completo até demais. 


seria necessário que a alternativa tivesse:

    A busca e a recuperação da informação;
    A circulação, mediante o controle do acesso para consulta, a 
reserva, o empréstimo e a devolução de exemplares do acervo;
    A catalogação de material bibliográfico, de multimídias e objetos 
digitais, inclusive com controle de autoridades e de vocabulário, e a 
transferência de registros entre bases de dados;
    O controle do processo de aquisição de novos itens para o acervo.

(isso eu extraí do próprio biblivre)

valeu, obrigado!



Bruno Buys

--
Abracos, e divirta-se. 


Enviado do meu BlackBerry

Tuto Debian-Facile/preseed: clé USB non bootable

[Olivier]

Bonjour,

J'ai découvert ce tuto [1].
Malheureusement, celui-ci ne détaille pas la dernière étape qui consiste à
copier le fichier .iso créé sur une clé USB bootable.

J'ai dans mon répertoire courant, le fichier :
$ file custom_install.iso
custom_install.iso: ISO 9660 CD-ROM filesystem data 'CDROM' (bootable)

À titre de comparaison, j'ai aussi:
$ file firmware-9.6.0-amd64-i386-netinst.iso
firmware-9.6.0-amd64-i386-netinst.iso: DOS/MBR boot sector ISO 9660 CD-ROM
filesystem data 'Debian 9.6.0 M-A 1' (bootable); partition 2 : ID=0xef,
start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 4256, 1376
sectors

Ma cible est une clé de 8Go sur /dev/sdc.

La commande ci-après produit une clé bootable;
sudo cat firmware-9.6.0-amd64-i386-netinst.iso > /dev/sdc

Par contre, la clé n'est pas bootable avec celle ci-après:
sudo cat custom_install.iso > /dev/sdc

Qui a une explication ?
Quelle commande me permettrait de copier ce fichier custom_install.iso sur
ma clé USB et faire que celle-ci soit bootable ?

Slts

[1] https://debian-facile.org/doc:install:preseed?s[]=preseed

Re: issues with stretch, issue 2 from many

[Ionel Mugurel Ciobîcă]

On 27-11-2018, at 13h 52'25", Ionel Mugurel Ciobîcă wrote about "issues with 
stretch, issue 2 from many"
> Dear all,
[...]
> Question 2.1: Why .xsession is not read and .xsessionrc is read?
> Question 2.2: Who starts the second call of fvwm? If I comment out the
> fvwm call in .xsession(rc) then the fvwm doesn't use the ssh-agent
> (for example). At the moment I simply deleted x-window-manager, so
> when I logout from fvwm I get a error/warning instead of a new fvwm
> session.
[...]

This issue is no longer relevant. I cannot re-reproduced it. Now the
.xsession is read as it should be. Also if I keep it as .xsessionrc
the second fvwm session will actually make use of the content of
.xsessionrc.

I did not do any updates lately, I am not sure what solved this...

So, I am back using the .xsession, no more issues with xdm/fvmw combo.
Thank you all for contributing with ideas.

Kind regards,
 Ionel

Re: issues with stretch, part 1 of many

[Ionel Mugurel Ciobîcă]

On  8-12-2018, at 13h 59'28", Stefan Krusche wrote about "Re: issues with 
stretch, part 1 of many"
> Good day, Ionel,

Hi Stefan,

> 
> This is just a guess.  Maybe you are looking for this option 
> in /etc/ssh/ssh_config:
> 
> #   StrictHostKeyChecking ask


Mine is set to no. I did it way before contacting the list. I am not
asked the passphrase or if I want to store the host in the host list,
etc. I am asked if I allow to use the key. It makes no difference what
I type. Only Enter and Esc are active, and the mouse click on the OK
and Cancel buttons. Of course if I type stuff the squares of the
ssh-ask are turning blue, but that is of no importance.

Ionel

Re: Servidor bloqueado por copiar ficheros

[Matias Mucciolo]

 

On Monday, December 10, 2018 10:04:47 PM -03 Josu Lazkano wrote:
> Buenas noches,
> 
> Estoy teniendo problemas en mi servidor Debian:
> 
> # uname -a
> Linux servidor 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64
> GNU/Linux
> 
> 
> Cada vez que copio grandes volúmenes de ficheros (500GB en ficheros de
> 40MB), se queda bloqueado y esto es lo que sale en el dmesg:
> https://paste.debian.net/1055220/
> 
> Hasta ahora no me había pasado, ¿puede que sea problema de memoria?
> 
> Entiendo que al estar copiando grandes de volúmenes de información vaya mas
> despacio, pero que se bloque completamente no lo entiendo.
> 
> Agradezco cualquier ayuda, no se que mas mirar.
> 
> Un saludo.
> 
> --
> Josu Lazkano

Buenas Josu
pregutna cuanto ram tiene ese servidor ?

saludos
Matias.-

Re: About /dev/sr impatience with automatic tray loading

[mick crane]

On 2018-12-10 20:02, Thomas Schmitt wrote:

Hi,

Gene Heskett wrote:

Perhaps that patch could be reverted,


It had its legitimate intentions, 10 years ago.
See


https://github.com/torvalds/linux/commit/210ba1d1724f5c4ed87a2ab1a21ca861a915f734

and a glimpse of the following woes
  http://lkml.iu.edu/hypermail//linux/kernel/0807.0/0287.html
(The culprits already suffered duely. Hehehe.)

The decisive change is not easy to spot. It's the loss of the function

static int test_unit_ready(Scsi_CD *cd)

with the line

return sr_do_ioctl(cd, );

sr_do_ioctl() has a waiting loop that eats "still undecided" replies 
and

retries at most 10 times. It still exists in the current kernel

  https://github.com/torvalds/linux/blob/master/drivers/scsi/sr_ioctl.c

where in line 223 ff. we can see the old timeout of 20 seconds

if (!cgc->quiet)
sr_printk(KERN_INFO, cd,
  "CDROM not ready yet.\n");
if (retries++ < 10) {
/* sleep 2 sec and try again */
ssleep(2);
goto retry;
} else {
/* 20 secs are enough? */
err = -ENOMEDIUM;
break;
}

The replacement for test_unit_ready() is a call to 
scsi_test_unit_ready()

which does not call a function with retry loop.

For the purpose of sr_drive_status(), the loop is really inappropriate.
This function shall obtain the drive status and not wait until the
status of the medium is decided.

Regrettably the subsequent correction attempts never reached the doings
of drivers/cdrom/cdrom.c function open_for_data(). By the original
change it lost its loop and never got a new one.

My fix proposal is to create a function with such a loop and to let
open_for_data() use it instead of the call of cdo->drive_status(),
which actually is sr_drive_status().
Currently this call is in line 1068 of

  https://github.com/torvalds/linux/blob/master/drivers/cdrom/cdrom.c



and the timeout made say 2 minutes,
by which time the drive should be able to make up its mind


30 seconds seems to be enough for all normal situations. My longest
experiment result with various drives and media was 18 seconds.
One would have to convince the hypothetical committer why 120 is 
needed.


But before commit comes the test and before test comes the recent 
kernel

on real iron. I only have code for now and feel fewly talented for the
missing steps.



That I think we can all agree is a PITA.


Oh. I know some more such dumplings.


Have a nice day :)

Thomas


completely off the topic but I have noticed that people whose first 
language might not be english use
"shall" as apposed to "will" or "should". It seems a little bit old 
fashioned but maybe it isn't.

Like some check list of an experiment approached logically.
Just something I was curious about.

"This function shall obtain the drive status and not wait until the
status of the medium is decided."


mick
--
Key ID4BFEBB31

Re: Debian social

[songbird]

Marek Mosiewicz wrote:
... 
> I remember time when internet had news groups and it was different type
> of social. Maybe it is wrong word. I mean place for generic discussion.
> For sure better than TV 


  usenet still exists and the social groups are
still there, but they may not be very active
these days.

  there are even low cost or free news services
available (search for eternal-september for one
example).


  songbird

Re: About /dev/sr impatience with automatic tray loading

[Thomas Schmitt]

Hi,

i wrote:
> > I know some more such dumplings.

Gene Heskett wrote:
> So do I, Thomas, but this is supposedly a polite list. :)

I actually meant the bugs, not the bug makers whose sympathy is probably
needed to ever get the bugs fixed.
(When pointing with one finger at others, three fingers are pointing back
 to oneself ...)

The tray loading bug is not as embarrassing as the SG_IO concurrency bug
(two concurrent burns on different /dev/sr are awfully slow) and the
CD read-ahead bug (i/o errors when trying to read valid blocks near
the end of a CD that was written with write type Track-At-Once).


> >   http://lkml.iu.edu/hypermail//linux/kernel/0807.0/0287.html
> > (The culprits already suffered duely. Hehehe.)

> And rather than fix it, walked away.

They fixed several negative consequences of the necessary change.
But obviously they did not assess all callers of sr_drive_status() whether
they depended on the loop at its inappropriate position in the code.
I did not, either, but only found one left-over and needed several
curious attempts during 2.5 years to finally understand what happened.


Have a nice day :)

Thomas

Re: Servidor bloqueado por copiar ficheros

[Paynalton]

El mar., 11 dic 2018 12:20 a. m., Josu Lazkano 
escribió:

> Hola,
>
> Las copias las realizo tanto con rsync como con cp. Son unos 500GB de
> informacion en ficheros TIFF de 40-50MB. Tanto el origen como el destino
> estan en EXT4.
>

Solo para descartar, ejecuta "df -i" y checa el porcentaje.


> Dudo mucho que sea por el disco, tengo instalado smartd, y a la minima que
> falla un disco me avisa.
>
> ¿Como puedo hacer una comprobacion de memoria? Lo puedo hacer en caliente
> o mejor desde la BIOS?
>

El disco de debian y muchas distros live incluyen memtest para conprobar la
memoria. Tienes que hacerlo desde la máquina que ejecuta el comando.


> Gracias por la ayuda.
>
> Un saludo.
>
> El lun., 10 dic. 2018 a las 22:14, Paynalton ()
> escribió:
>
>>
>> Si un ave no rompe su huevo morirá antes de nacer.
>> Nosotros somos el ave y el mundo es nuestro huevo.
>> POR LA REVOLUCIÓN DEL MUNDO
>>
>> Ciudad de México
>>
>>
>> El lun., 10 dic. 2018 a las 15:05, Josu Lazkano ()
>> escribió:
>>
>>> Buenas noches,
>>>
>>> Estoy teniendo problemas en mi servidor Debian:
>>>
>>> # uname -a
>>> Linux servidor 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64
>>> GNU/Linux
>>>
>>>
>>> Cada vez que copio grandes volúmenes de ficheros (500GB en ficheros de
>>> 40MB), se queda bloqueado y esto es lo que sale en el dmesg:
>>> https://paste.debian.net/1055220/
>>>
>>
>> Me suena a daño en la memoria ram, daño en el disco físico en donde
>> tienes la partición swap...
>> Sólo para descartar... con qué programa estás realizando la copia?
>> son muchos archivos o un sólo archivo megalítico??? que formato tienen el
>> origen y el destino (ext4, fat, etc...)???
>>
>>
>>>
>>> Hasta ahora no me había pasado, ¿puede que sea problema de memoria?
>>>
>>> Entiendo que al estar copiando grandes de volúmenes de información vaya
>>> mas despacio, pero que se bloque completamente no lo entiendo.
>>>
>>> Agradezco cualquier ayuda, no se que mas mirar.
>>>
>>> Un saludo.
>>>
>>> --
>>> Josu Lazkano
>>>
>>
>
> --
> Josu Lazkano
>

Tworzenie STRON i SKLEPÓW internetowych.

[Strony ,Sklepy WWW]

Dzień dobry,zajmujemy się tworzeniem nowoczesnych STRON i SKLEPÓW 
internetowych. Jeśli chcieliby Państwo otrzymać  bezpłatną propozycję w tym 
zakresie dla Państwa firmy prosimy o odpowiedź "TAK" na ten adres 
e-mail.Profesjonalna witryna internetowa jest w dzisiejszych czasach niezbędnym 
elementem każdej, dobrze rozwijającej się firmy.--Serdecznie Pozdrawiamy!

Re: Debian social

[Curt]

On 2018-12-11, Curt  wrote:
> On 2018-12-10, Cindy-Sue Causey  wrote:
>>
>> Beyond that, I *thought* I remembered a few times seeing long threads
>> being (politely) advised to move it on over to offtopic, meaning the
>> listserv I thought I remembered..
>>
>
> Yeah, but apparently the off-topic group was consistently drifting
> on topic to the point where many were advised to move there technical
their
> prolixities and proclivities over here (and vice versa, of course, as
> you've pointed out).
>
> You can't win.
>
>


-- 
He used sentences differently from any other prose writer. He always sounded
like a slightly drunk man who is very melancholy, who has no illusions about
life, who is very strong but whose strength is entirely unnecessary.
--Krasznahorkai on Krúdy

Re: Debian social

[Curt]

On 2018-12-10, Cindy-Sue Causey  wrote:
>
> Beyond that, I *thought* I remembered a few times seeing long threads
> being (politely) advised to move it on over to offtopic, meaning the
> listserv I thought I remembered..
>

Yeah, but apparently the off-topic group was consistently drifting
on topic to the point where many were advised to move there technical
prolixities and proclivities over here (and vice versa, of course, as
you've pointed out).

You can't win.