Re: Stretch: problème avec Ethernet Controller RTL8111

[Jean Louis Giraud Desrondiers]

Bonjour,
> 
> serait il possible d'installer wicd (?) car sur mon ordi portable
> c'est le seul moyen que j'ai trouvé d'activer la carte wifi

encore mieux selon moi : connman (j'ai eu plein de problème de
configuration avec wicd et avec connman ma connexion a été établie en
deux coups de cuiller à pot)
> 
> slt
> bernard
> 


-- 
Cordialement, 

Jean Louis Giraud Desrondiers 

Re: Metalink s a Debian 9

[Narcis Garcia]

__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 22/02/18 a les 21:23, Juanjo Benages ha escrit:
> El 22/02/18 a las 09:07, Narcis Garcia escribió:
>> Algú ha aconseguir descarregar fitxers utilitzant un «metalink»?
>> He provat amb wget i aria2c sense èxit. Ambdós donen errors estranys.
>>
>> Un exemple de descàrrega:
>> https://files.kde.org/kdenlive/unstable/kdenlive-18.04-beta1.AppImage.mirrorlist
>>
>>
>>
>> Per més informació:
>> https://es.wikipedia.org/wiki/Metalink
>>
> Jo sí puc am l'aria2. He probat:
> http://files.kde.org/kdenlive/unstable/kdenlive-18.04-beta1.AppImage.meta4
> 

Quina sintaxi has fet servir exactament?

Re: CT-based firewall rules?

[john doe]

On 2/23/2018 2:07 AM, Rodary Jacques wrote:

When I reboot, what program  is responsible for  "CT-based  firewall rule" (dixit 
jounalctl). I would like to have my own firewall rules, and for now, I must flush those 
"CT-based  firewall rules" before  I set my owns.
Again it's not too important, since I don't reboot very often, but I would 
appreciate not to have to spend quite a lot of time to change default setup 
each time I reboot.
I already got rid of bind9.service (I have my own DNS config but I need named 
of course), Avahi-daemon package (I don't need multicast DNS).
I know the good solution would be to build my own packages with my own choices, 
but I haven't the necessary knowledge.



Are you talking about this message:

https://bbs.archlinux.org/viewtopic.php?id=224647

"nf_conntrack: default automatic helper assignment has been turned off 
for security reasons and CT-based  firewall rule not found. Use the 
iptables CT target to attach helpers instead."


It's always better to have the message in question! :)

As a dirty workaroungd, '/etc/rc.local' could be useful.

--
John Doe

The white man -- Who he is

[thetruthbeforeus]

Truth about the white man: http://youtu.be/Foi_LbdMjXU
I think all my fellow FLOSS programmers should take a moment to join the 
discussion, to take a good look at just WHO the white man is and how his 
essence negatively or positively affects the people of the world, and if 
any accord can be reached so he realizes what he is doing and why.

Re: Stretch: problème avec Ethernet Controller RTL8111

[Bernard Schoenacker]

- Mail original -
> De: "Bernard" 
> À: "debian-user-french@lists.debian.org Debian" 
> 
> Cc: "humbert olivier 1" 
> Envoyé: Vendredi 23 Février 2018 00:53:14
> Objet: Re: Stretch: problème avec Ethernet Controller RTL8111
> 
> humbert.olivie...@free.fr wrote:
>  >> Je viens d'installer Stretch sur mon nouveau desktop. A
>  >> l'installation,
>  >> impossible d'avoir une connexion filiaire Ethernet, j'ai dû me
>  >> contenter
>  >> d'une connexion WiFi. Une fois installé, toujours pas de
>  >> connexion.
>  >> Le contrôleur graphique me dit : "Réseau" "Filiaire" "câble
>  >> débranché",
>  >> ce qui n'est évidemment pas le cas.
>  >>
>  >>
>  >
>  > Bonjour Bernard, et merci pour le diagnostic plutôt complet.
>  >
>  > Le message qui tilte mes yeux est :
>  >  
>  >> unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)
>  >>
>  >
>  > ce qui semble signifier que le fichier de ce micro logiciel qui
> probablement, contrôle
>  > l'interface ethernet en question n'est pas présent sur ton
>  > système.
>  >
>  > Une recherche rapide sur https://packages.debian.org/ nous indique
> que ce fichier rtl8168g-2.fw
>  > appartient au paquet firmware-realtek qui est dans la section
>  > non-libre.
>  > (voir : https://packages.debian.org/stretch/firmware-realtek )
>  >
>  > Est-il installé sur ta machine ?
>  > Olivier
>  >  
> 
> Merci pour cette info. Je viens d'ajouter ce qu'il fallait à mon
> fichier
> /etc/apt/sources.list et, après un apt-update, j'ai pu installer le
> paquet firmware-realtek. Malheureusement çà ne fonctionne toujours
> pas,
> après deux reboot. Le rapport dans /var/log messages a changé:
> 
> ...
> kernel firmware directory  manager : kernel firmware directory
> '/lib/firmware' changed
> .
> firmware : direct-loading firmware rtl_nic/rtl8168g-2.fw
> enp2s0 link down
> enp2s0 link is not ready
> using nl80211 for WiFi device control
> ...
> 
> donc, apparemment le firmware a bien été chargé cette fois-ci, mais
> cela
> n'a pas suffit à activer la connexion Ethernet !
> 
> Que puis-je tenter maintenant ?
> 
> 


bonjour,

serait il possible d'installer wicd (?) car sur mon ordi portable
c'est le seul moyen que j'ai trouvé d'activer la carte wifi

slt
bernard

Re: Re: [partial resolution] Re: Problem withj dd

[Andy Smith]

Hi Jacques,

On Fri, Feb 23, 2018 at 02:46:47AM +0100, Rodary Jacques wrote:
> 1/ No the same removable device doesn't always receive the same /dev/sdX.If 
> you unmount  it ( umount /dev/sdX) and plug it again, it can be called 
> /dev/sdY (I suppose the kernel keeps tne name in memory for some time). 

You might find it more convenient to use the device aliases in the
/dev/disk/by-* directories as these can be based on some persistent
property of your removable device such as its label, serial number,
or which port it is plugged into etc.

Cheers,
Andy

Re: Re: [partial resolution] Re: Problem withj dd

[Rodary Jacques]

1/ No the same removable device doesn't always receive the same /dev/sdX.If you 
unmount  it ( umount /dev/sdX) and plug it again, it can be called /dev/sdY (I 
suppose the kernel keeps tne name in memory for some time). 
2/ use "mount" without arguments., plug your flash drive and run "mount" again: 
the new /dev/sdX  (or /dev/sdXn) is your drive (or mounted partition). Unmount 
it with "umount /dev/sdX(n)" and run dd with  "dd if=input-image of=/dev/sdX 
[options]" without the partition number if there was one. All this as root of 
course.
Good luck. Jacques

Re: Debian 9 Image Magick/display xwd(1) format

[Cindy-Sue Causey]

On 2/22/18, Brian  wrote:
> On Thu 22 Feb 2018 at 13:35:20 -0800, John Conover wrote:
>>
>> xwd > myfile
>> display myfile
>>
>> gives:
>>
>> "display-im6.q16: no decode delegate for this image format `' @
>> error/constitute.c/ReadImage/504."
>>
>> Anything else read the file and do file conversions?
>
> xwd > myfile.xwd
> display myfile.xwd
>
> works here.


I test drove this. It failed twice, and I wrote a response. Then I
decided to try it one more time. It worked.. *that time*..

The first two attempts just sat there spinning their wheels. Never
having done this, I figured it might be like other commands where
you're supposed to keep going while the first is running.

Nope. *grin*

The cursor changed to the crosshair during the first two runs. I
couldn't get into any other program during those moments. I finally
CTRL+C'd to exit.

I thought to verify if anything resembling a file was created.
Something size "0" was sitting there.

Then I ran "xwd > myfile.xwd" a third time, and that's when it worked.
Just ran "display myfile.xwd", and a very nice copy of my top XFCE4
toolbar/panel displayed via Magick..

But it did take 3 tries before it did anything

PS I just ran it a fourth time... It didn't work again

PPS I ran it a FIFTH time... and tried clicking another program while
it appeared to be failing again. Computer beeped the sound I've come
to recognize as part of Magick from just having played with Magick
this week..

THEN... I went back to my terminal, and the command had completed its
run. "display" displayed a second very nice resolution'ed copy of the
top toolbar/panel.

*hm* :D

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

CT-based firewall rules?

[Rodary Jacques]

When I reboot, what program  is responsible for  "CT-based  firewall rule" 
(dixit jounalctl). I would like to have my own firewall rules, and for now, I 
must flush those "CT-based  firewall rules" before  I set my owns.
Again it's not too important, since I don't reboot very often, but I would 
appreciate not to have to spend quite a lot of time to change default setup 
each time I reboot.
I already got rid of bind9.service (I have my own DNS config but I need named 
of course), Avahi-daemon package (I don't need multicast DNS).
I know the good solution would be to build my own packages with my own choices, 
but I haven't the necessary knowledge.
Jacques

Re: Debian 9 Image Magick/display xwd(1) format

[Brian]

On Thu 22 Feb 2018 at 13:35:20 -0800, John Conover wrote:

> 
> xwd > myfile
> display myfile
> 
> gives:
>  
> "display-im6.q16: no decode delegate for this image format `' @
> error/constitute.c/ReadImage/504."
> 
> Anything else read the file and do file conversions?

xwd > myfile.xwd
display myfile.xwd

works here.

-- 
Brian.

Super (Mod4) + L behavior for MATE

[Matt Zagrabelny]

Greetings,

Just upgraded to MATE 1.20.0 (Debian Sid) and I'm noticing something that I
had not before...

If I hit Super + L, I get a screen lock. However, screen lock is bound to
Ctrl + Alt + L.

Anyone have ideas as to what is up?

Thanks!

-m

Re: /etc/X11/default-display-manager : quelle commande pour la modification ?

[Jean-Marc]

Sat, 17 Feb 2018 18:11:02 +0100
Jean-Marc  écrivait :

> Sat, 17 Feb 2018 09:53:03 +0100
> Randy11  écrivait :
> 

Toute petite question : est-ce résolu ?


Jean-Marc 


pgpFqZfHyzKox.pgp
Description: PGP signature

Re: Stretch: problème avec Ethernet Controller RTL8111

[Bernard]

humbert.olivie...@free.fr wrote:
>> Je viens d'installer Stretch sur mon nouveau desktop. A l'installation,
>> impossible d'avoir une connexion filiaire Ethernet, j'ai dû me contenter
>> d'une connexion WiFi. Une fois installé, toujours pas de connexion.
>> Le contrôleur graphique me dit : "Réseau" "Filiaire" "câble débranché",
>> ce qui n'est évidemment pas le cas.
>>
>>
>

> Bonjour Bernard, et merci pour le diagnostic plutôt complet.
>
> Le message qui tilte mes yeux est :
>  
>> unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)
>>
>
> ce qui semble signifier que le fichier de ce micro logiciel qui 
probablement, contrôle

> l'interface ethernet en question n'est pas présent sur ton système.
>
> Une recherche rapide sur https://packages.debian.org/ nous indique 
que ce fichier rtl8168g-2.fw

> appartient au paquet firmware-realtek qui est dans la section non-libre.
> (voir : https://packages.debian.org/stretch/firmware-realtek )
>
> Est-il installé sur ta machine ?
> Olivier
>  


Merci pour cette info. Je viens d'ajouter ce qu'il fallait à mon fichier
/etc/apt/sources.list et, après un apt-update, j'ai pu installer le
paquet firmware-realtek. Malheureusement çà ne fonctionne toujours pas,
après deux reboot. Le rapport dans /var/log messages a changé:

...
kernel firmware directory  manager : kernel firmware directory
'/lib/firmware' changed
.
firmware : direct-loading firmware rtl_nic/rtl8168g-2.fw
enp2s0 link down
enp2s0 link is not ready
using nl80211 for WiFi device control
...

donc, apparemment le firmware a bien été chargé cette fois-ci, mais cela
n'a pas suffit à activer la connexion Ethernet !

Que puis-je tenter maintenant ?

Re: Debian 9 Image Magick/display xwd(1) format

[Thomas Schmitt]

Hi,

have a look at
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853262

So does this work ?

  display xwd:myfile


Only if still not work:

John Conover wrote:
> I don't know if its a compile time configuration issue, or the file
> format has been depreciated, or what

That's why i asked about the output of program "file".
If xwd of Debian 9 is to blame, then "file" will tell something different
than with my file.


> My Debian 8 works OK, too.

What happens if you try to read the xwd file from Debian 9 by the
"display" program of Debian 8 ?
What happens vice versa ?


Have a nice day :)

Thomas

Re: problems with manual page usermod.8 and useradd.8

[Greg Wooledge]

On Thu, Feb 22, 2018 at 05:09:34PM -0500, Roberto C. Sánchez wrote:
> I have seen this used on old UNIX or BSD systems to create a second root
> account. For example, the standard default root account is set to use
> some old sh or csh implementation. Somebody installs bash (probably in
> /usr/local) and wants to be able to log in as root and have that be the
> default shell. However it might be dangerous to change root's default
> shell, so you create a second account called 'toor' with user ID 0 and
> the same home directory as root and set its default shell to
> /usr/local/bin/bash (or whatever). Then administrators are able to log
> in as 'toor' to get bash as the default shell.

I've seen variants of this as well, but usually you do it by running vipw
to edit the passwd file (or its BSD equivalent) directly.  Who's got
time to waste learning a bunch of obscure useradd or usermod options? :)

(Seriously, I believe the actual purpose of useradd/usermod is for
package post-install commands, not human use.  Humans can just edit
the file manually.  Plus you get to clean up the ordering of the UIDs
and such while you're in there.)

Re: Debian 9 Image Magick/display xwd(1) format

[John Conover]

Thanks, Thomas.

My Debian 8 works OK, too. But the Image Magick for Debian 9 does not
read files made by xwd(1).

I don't know if its a compile time configuration issue, or the file
format has been depreciated, or what-but it doesn't work on Debian 9.

Thanks,

John

Thomas Schmitt writes:
> Hi,
> 
> John Conover wrote:
> > xwd > myfile
> > display myfile
> > "display-im6.q16: no decode delegate for this image format
> 
> This works for me in Debian 8. Even old xv can read the file, albeit with
> wrong background color.
> 
> What do you get from
> 
>   file myfile
> 
> In my test it says
>   myfile: XWD X Window Dump image data, "xterm", 484x316x24
> 
> 
> Have a nice day :)
> 
> Thomas

-- 

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

Re: problems with manual page usermod.8 and useradd.8

[Michael Fothergill]

On 22 February 2018 at 21:12, MarkusHiereth  wrote:

> Hello,
>
> when updating the German translations of the shadow package, I
> encountered strange things in the documentation. For example an option
> --non-unique for the commands useradd and usermod. With the first, the
> system administrator is able to force the system to create a new user
> with an ID that already exists, which is related to another user.
>
> One effect I would expect after using useradd with this option is that
> files and directories are owned by two persons - as the UID of a file
> indicates the owner.
>
> Has anybody an idea about the purpose of such an option?
>

​Perhaps it was created for people suffering from multiple personality
disorder.

Who knows

Cheers

MF​


>
> >From my point of view it is necessary that the respective manual pages
> explain why one might use such an option and / or warn what a mess
> might be created with it.
>
> On the debian IRC channel, one comment on this problem was, Linux is a
> friendly operating system. It will not prevent users from shooting
> themselves in the foot.
>
> Please cc your posts to my mail addresse as I am not a subscriber of
> this list.
>
> Best regards
> Markus
>
>

Re: problems with manual page usermod.8 and useradd.8

[David Wright]

On Thu 22 Feb 2018 at 22:12:44 (+0100), MarkusHiereth wrote:
> Hello,
> 
> when updating the German translations of the shadow package, I
> encountered strange things in the documentation. For example an option
> --non-unique for the commands useradd and usermod. With the first, the
> system administrator is able to force the system to create a new user
> with an ID that already exists, which is related to another user.
> 
> One effect I would expect after using useradd with this option is that
> files and directories are owned by two persons - as the UID of a file
> indicates the owner.

Well, yes, the UID/GID is how the system keeps track of who owns what.

> Has anybody an idea about the purpose of such an option?

I'm afraid the purpose is defined by the imagination of the person
who sets it up that way. Typical for computers, people find uses.
Different login identities but sharing the same files could be one
reason. Whatever.

> >From my point of view it is necessary that the respective manual pages
> explain why one might use such an option and / or warn what a mess
> might be created with it.

The way to avoid a mess is to use adduser. useradd is for those who
know what they're doing.

> On the debian IRC channel, one comment on this problem was, Linux is a
> friendly operating system. It will not prevent users from shooting
> themselves in the foot.

That's true. But it also has the philosophy of not preventing things
just for the sake of it.

Cheers,
David.

Re: problems with manual page usermod.8 and useradd.8

[Roberto C . Sánchez]

On Thu, Feb 22, 2018 at 10:12:44PM +0100, MarkusHiereth wrote:
> 
> Has anybody an idea about the purpose of such an option?
> 
Hi Markus,

I have seen this used on old UNIX or BSD systems to create a second root
account. For example, the standard default root account is set to use
some old sh or csh implementation. Somebody installs bash (probably in
/usr/local) and wants to be able to log in as root and have that be the
default shell. However it might be dangerous to change root's default
shell, so you create a second account called 'toor' with user ID 0 and
the same home directory as root and set its default shell to
/usr/local/bin/bash (or whatever). Then administrators are able to log
in as 'toor' to get bash as the default shell.

I have never implemented such a scheme myself, I just recall having seen
it on some very old systems I used a long time ago.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: stretch and DNS name resolution service for other devices on a LAN

[David Wright]

On Tue 23 Jan 2018 at 20:56:31 (+0100), Pascal Hambourg wrote:
> Le 23/01/2018 à 18:08, David Wright a écrit :
> >
> >[My Laptop] --- wireless connection IPv4 --- [Router] --- Internet Modem
> >  | / |
> >  | CAT5 cable IPv6/  |
> >  |   /   | wireless/wired
> >[My Desktop] --- wireless connection IPv4 __/| connections
> >  | IPv4
> >  |
> > [TVs]
> >
> >>Both devices will allocate themselves an address in the 'link local' range,
> >>and these addresses can then be used for communicating between the devices.
> 
> They can, but they should not be used with application-layer
> protocols. Really. IPv6 link local addresses are not meant for this.

Well, I won't argue with this as I don't know what they were
originally meant for. However, I don't see why I have them if I'm
not allowed to use them when I find a good reason to. I didn't pay
good money just to stare at the numbers in  ip address show.
You see, Greg only considered IPv6 in terms of the number of addresses
in the IPv4 private ranges, whereas I have this other valuable use.

> On disadvantage is that these addresses are not globally unique (the
> link local prefix exists on all interfaces) and must be appended
> with an interface name.

Not an issue here. The only change I have made since you commented
on this in August 2016 is that I now sed the output of
ip -o link show
to pick up the name of the ethernet interface. (The file that defines
my IPv6 functions is shared with wheezy/jessie/stretch hosts, and
"eth0" doesn't cut it any more.)

> The second disadvantage is that if the
> interface is replaced for whatever reason, the interface name may
> change and the MAC address will change. The link local addresses is
> based on the MAC addresses, so it will change too.

Well, as the MAC addresses are all configured in my router, having
to edit a MAC in one bash file and push it out to my hosts is hardly
a burden after logging in to the router and typing or pasting things
there. (I hate systems that barely allow you time to sneeze before
they require logging in again.)

> IMO, simple
> static configuration with a ULA prefix, or with a global prefix if
> you own one, would be much reliable.

So what would be involved in setting that up? I have no idea where
to start. I can't believe it's as simple as 1,2,3 below.

> So Andy is right : you could use IPv4 for this. But rather with
> static configuration than unpredictable APIPA assignments.

Of course I could, but then I've got to interfere with the routing
table to prevent the file transfers going through the default
wireless interface. The whole point of plugging in a CAT5 cable is
to avoid hogging wireless bandwidth.

If I use IPv6, this is all I have to do to transfer large files at
CAT5 speeds:

1) plug a CAT5 cable into ethernet ports at each machine,
2) on the source, type:   6 
3) when finished, remove the cable.

The wireless interface is unaware of any change, so I can still use
the WAN, or even connect to the other host through its normal wireless
route and, say, initiate transfers in the opposite direction (which
has the advantage that such a connection stays up after the cable has
been removed).

Cheers,
David.

Re: Debian 9 Image Magick/display xwd(1) format

[Thomas Schmitt]

Hi,

John Conover wrote:
> xwd > myfile
> display myfile
> "display-im6.q16: no decode delegate for this image format

This works for me in Debian 8. Even old xv can read the file, albeit with
wrong background color.

What do you get from

  file myfile

In my test it says
  myfile: XWD X Window Dump image data, "xterm", 484x316x24


Have a nice day :)

Thomas

problems with manual page usermod.8 and useradd.8

[MarkusHiereth]

Hello,

when updating the German translations of the shadow package, I
encountered strange things in the documentation. For example an option
--non-unique for the commands useradd and usermod. With the first, the
system administrator is able to force the system to create a new user
with an ID that already exists, which is related to another user.

One effect I would expect after using useradd with this option is that
files and directories are owned by two persons - as the UID of a file
indicates the owner.

Has anybody an idea about the purpose of such an option?

>From my point of view it is necessary that the respective manual pages
explain why one might use such an option and / or warn what a mess
might be created with it.

On the debian IRC channel, one comment on this problem was, Linux is a
friendly operating system. It will not prevent users from shooting
themselves in the foot.

Please cc your posts to my mail addresse as I am not a subscriber of
this list.

Best regards
Markus

Re: Boot Order Change

[Felix Miata]

Dan Norton composed on 2018-02-22 16:05 (UTC-0500):

> Installs of both stretch and buster modify the boot order such that
> "debian" is first under "UEFI Boot Sources". After installation, the
> bios menu has to be edited in order to boot from DVD or CD or USB
> drive. Also "Hard Drive" has been replaced with "debian".

> The PC is:
> Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012

> Apparently it is deliberate, so what is the reason for this?

AFAICT, it depends on the particular BIOS design and settings therein, how it's
designed to react to what it finds in the EFI partition, particularly if there
is more than one entry there. Brand name PCs tend to offer fewer BIOS options.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Debian 9 Image Magick/display xwd(1) format

[John Conover]

xwd > myfile
display myfile

gives:
 
"display-im6.q16: no decode delegate for this image format `' @
error/constitute.c/ReadImage/504."

Anything else read the file and do file conversions?

Thanks,

John

-- 

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

Boot Order Change

[Dan Norton]

Installs of both stretch and buster modify the boot order such that
"debian" is first under "UEFI Boot Sources". After installation, the
bios menu has to be edited in order to boot from DVD or CD or USB
drive. Also "Hard Drive" has been replaced with "debian".

The PC is:
Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012

Apparently it is deliberate, so what is the reason for this?

 - Dan

Re: Fwd: Re: Unknown URL

[Stephen P. Molnar]

On 02/22/2018 03:13 PM, Reco wrote:

Hi.

On Thu, Feb 22, 2018 at 02:36:36PM -0500, Stephen P. Molnar wrote:

On 02/22/2018 01:59 PM, Reco wrote:

Hi.

On Thu, Feb 22, 2018 at 01:40:45PM -0500, Stephen P. Molnar wrote:

2) redone:

root@AbNormal:/home/comp#
root@AbNormal:/home/comp# ip a d 2600:1700:4280:3690::46/128 dev enp2s0
root@AbNormal:/home/comp#
root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte
packets
   1  * * *

That either means that AT is doing something very clever, or I
don't understand what's going on. Or both.

Ok, next part. Reset your network settings.

Check your IPv6 "readiness" by visiting [1] and performing appropriate
link clicks according to [2].

Oh, and the file - /tmp/fastly.pcap . I'm still interested in it.

[1] http://www.att.com/esupport/ipv6.jsp

[2] 
https://rolande.wordpress.com/2014/05/16/enabling-ipv6-on-my-home-network-part-2-att/

The missing file is attached.

The contents are different from what I hoped for. Two TCP IPv4 packets,
and that's it. Does not clarify things at all.



OK.

I went to URL #1  and ran their compatibility test.  The result was:

Alert!
Unfortunately, we are unable to access Troubleshoot & Resolve at this time.
For further assistance, please visit att.com/esupport
.

Translating from AT lingua that's probably means that you should not
have IPv6, or that /60 block they assigned to you does not function.
Or not. I suggest you to clear it with them.



However, when I logged in to my router it showed the Broadband configured
rot all ports 1 through 4 and being 'Auto', and IPv6 is shown as 'On' for
IPv6, DHCPv6 and DHPv6 Prefix Delegation and with the Router Advertisement
MTU WITH A VALUE OF 1500.

That's unusual. For IPv6 it should be 1480 if they are still using
tunnel. But it does not explain traceroute problem (a typical traceroute
packet size is much smaller).


I need to think about it. I have that feeling that I'm missing something
trivial.

Reco



I will appreciate your further thoughts.

Frankly, I don't have much confidence as far as AT being of any help.  
The installer that Upgraded us to a fiber optic network was quite 
knowledgeable, but had played with Linux a bit in the past but got 
discouraged.


At this ;point by day is done.

More tomorrow.

--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Metalink s a Debian 9

[Juanjo Benages]

El 22/02/18 a las 09:07, Narcis Garcia escribió:

Algú ha aconseguir descarregar fitxers utilitzant un «metalink»?
He provat amb wget i aria2c sense èxit. Ambdós donen errors estranys.

Un exemple de descàrrega:
https://files.kde.org/kdenlive/unstable/kdenlive-18.04-beta1.AppImage.mirrorlist


Per més informació:
https://es.wikipedia.org/wiki/Metalink


Jo sí puc am l'aria2. He probat:
http://files.kde.org/kdenlive/unstable/kdenlive-18.04-beta1.AppImage.meta4

Re: Fwd: Re: Unknown URL

[Reco]

Hi.

On Thu, Feb 22, 2018 at 02:36:36PM -0500, Stephen P. Molnar wrote:
> 
> On 02/22/2018 01:59 PM, Reco wrote:
> > Hi.
> > 
> > On Thu, Feb 22, 2018 at 01:40:45PM -0500, Stephen P. Molnar wrote:
> > >2) redone:
> > > 
> > > root@AbNormal:/home/comp#
> > > root@AbNormal:/home/comp# ip a d 2600:1700:4280:3690::46/128 dev enp2s0
> > > root@AbNormal:/home/comp#
> > > root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
> > > traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte
> > > packets
> > >   1  * * *
> > That either means that AT is doing something very clever, or I
> > don't understand what's going on. Or both.
> > 
> > Ok, next part. Reset your network settings.
> > 
> > Check your IPv6 "readiness" by visiting [1] and performing appropriate
> > link clicks according to [2].
> > 
> > Oh, and the file - /tmp/fastly.pcap . I'm still interested in it.
> > 
> > [1] http://www.att.com/esupport/ipv6.jsp
> > 
> > [2] 
> > https://rolande.wordpress.com/2014/05/16/enabling-ipv6-on-my-home-network-part-2-att/
> 
> The missing file is attached.

The contents are different from what I hoped for. Two TCP IPv4 packets,
and that's it. Does not clarify things at all.


> OK.
> 
> I went to URL #1  and ran their compatibility test.  The result was:
> 
> Alert!
> Unfortunately, we are unable to access Troubleshoot & Resolve at this time.
> For further assistance, please visit att.com/esupport
> .

Translating from AT lingua that's probably means that you should not
have IPv6, or that /60 block they assigned to you does not function.
Or not. I suggest you to clear it with them.


> However, when I logged in to my router it showed the Broadband configured
> rot all ports 1 through 4 and being 'Auto', and IPv6 is shown as 'On' for
> IPv6, DHCPv6 and DHPv6 Prefix Delegation and with the Router Advertisement
> MTU WITH A VALUE OF 1500.

That's unusual. For IPv6 it should be 1480 if they are still using
tunnel. But it does not explain traceroute problem (a typical traceroute
packet size is much smaller).


I need to think about it. I have that feeling that I'm missing something
trivial.

Reco

Re: Fwd: Re: Unknown URL

[Stephen P. Molnar]

On 02/22/2018 01:59 PM, Reco wrote:

Hi.

On Thu, Feb 22, 2018 at 01:40:45PM -0500, Stephen P. Molnar wrote:

   2) redone:

root@AbNormal:/home/comp#
root@AbNormal:/home/comp# ip a d 2600:1700:4280:3690::46/128 dev enp2s0
root@AbNormal:/home/comp#
root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte
packets
  1  * * *

That either means that AT is doing something very clever, or I
don't understand what's going on. Or both.

Ok, next part. Reset your network settings.

Check your IPv6 "readiness" by visiting [1] and performing appropriate
link clicks according to [2].

Oh, and the file - /tmp/fastly.pcap . I'm still interested in it.

[1] http://www.att.com/esupport/ipv6.jsp

[2] 
https://rolande.wordpress.com/2014/05/16/enabling-ipv6-on-my-home-network-part-2-att/

Reco



Reco

The missing file is attached.

OK.

I went to URL #1  and ran their compatibility test.  The result was:

Alert!
Unfortunately, we are unable to access Troubleshoot & Resolve at this 
time. For further assistance, please visit att.com/esupport 
.


However, when I logged in to my router it showed the Broadband 
configured rot all ports 1 through 4 and being 'Auto', and IPv6 is shown 
as 'On' for IPv6, DHCPv6 and DHPv6 Prefix Delegation and with the Router 
Advertisement MTU WITH A VALUE OF 1500.


Broadband Status shows:

Broadband Connection Source ETHERNET
Broadband ConnectionUp
Broadband IPv4 Address  162.237.98.238
Gateway IPv4 Address162.237.96.1
MAC Address 3c:04:61:b3:3c:21
Primary DNS 
Secondary DNS   
Primary DNS Name
Secondary DNS Name  
MTU 1500

--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1



fastly.pcap
Description: application/vnd.tcpdump.pcap

Re: Fwd: Re: Unknown URL

[Reco]

Hi.

On Thu, Feb 22, 2018 at 01:40:45PM -0500, Stephen P. Molnar wrote:
>   2) redone:
> 
> root@AbNormal:/home/comp#
> root@AbNormal:/home/comp# ip a d 2600:1700:4280:3690::46/128 dev enp2s0
> root@AbNormal:/home/comp#
> root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
> traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte
> packets
>  1  * * *

That either means that AT is doing something very clever, or I
don't understand what's going on. Or both.

Ok, next part. Reset your network settings.

Check your IPv6 "readiness" by visiting [1] and performing appropriate
link clicks according to [2].

Oh, and the file - /tmp/fastly.pcap . I'm still interested in it.

[1] http://www.att.com/esupport/ipv6.jsp

[2] 
https://rolande.wordpress.com/2014/05/16/enabling-ipv6-on-my-home-network-part-2-att/

Reco

Re: Fwd: Re: Unknown URL

[Stephen P. Molnar]

On 02/22/2018 01:37 PM, Reco wrote:

Hi.

On Thu, Feb 22, 2018 at 01:17:58PM -0500, Stephen P. Molnar wrote:

The next lies are keyed to you numbered request:

1)  root@AbNormal:/home/comp# ping -c2 fe80::3e04:61ff:feb3:3c20%enp2s0
PING fe80::3e04:61ff:feb3:3c20%enp2s0(fe80::3e04:61ff:feb3:3c20%enp2s0) 56
data bytes
64 bytes from fe80::3e04:61ff:feb3:3c20%enp2s0: icmp_seq=1 ttl=64 time=0.258
ms
64 bytes from fe80::3e04:61ff:feb3:3c20%enp2s0: icmp_seq=2 ttl=64 time=0.201
ms

--- fe80::3e04:61ff:feb3:3c20%enp2s0 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 0.201/0.229/0.258/0.032 ms

So, that seems ok.


2)  root@AbNormal:/home/comp# ip a d 2600:1700:4280:3690::46/128
Not enough information: "dev" argument is required.
root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte
packets

And that's my mistake. Should be this:

ip a d 2600:1700:4280:3690::46/128 dev enp2s0

traceroute -n 2a04:4e42:b::204


3)  root@AbNormal:/home/comp# ip -6 ro d 2600:1700:4280:3690::/60
root@AbNormal:/home/comp#
root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte
packets
  1  * * *

Was worth a try, but this is not it.

Come thinking about it, please also run this:

ip ro get 2a04:4e42:b::204

Reco



  2) redone:

root@AbNormal:/home/comp#
root@AbNormal:/home/comp# ip a d 2600:1700:4280:3690::46/128 dev enp2s0
root@AbNormal:/home/comp#
root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte 
packets

 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *


root@AbNormal:/home/comp# ip ro get 2a04:4e42:b::204
2a04:4e42:b::204 from :: via fe80::3e04:61ff:feb3:3c20 dev enp2s0 proto 
static src 2600:1700:4280:3690:800c:68fc:ea2c:23c0 metric 100 pref medium

root@AbNormal:/home/comp#

--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Fwd: Re: Unknown URL

[Reco]

Hi.

On Thu, Feb 22, 2018 at 01:17:58PM -0500, Stephen P. Molnar wrote:
> The next lies are keyed to you numbered request:
> 
> 1)  root@AbNormal:/home/comp# ping -c2 fe80::3e04:61ff:feb3:3c20%enp2s0
> PING fe80::3e04:61ff:feb3:3c20%enp2s0(fe80::3e04:61ff:feb3:3c20%enp2s0) 56
> data bytes
> 64 bytes from fe80::3e04:61ff:feb3:3c20%enp2s0: icmp_seq=1 ttl=64 time=0.258
> ms
> 64 bytes from fe80::3e04:61ff:feb3:3c20%enp2s0: icmp_seq=2 ttl=64 time=0.201
> ms
> 
> --- fe80::3e04:61ff:feb3:3c20%enp2s0 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1003ms
> rtt min/avg/max/mdev = 0.201/0.229/0.258/0.032 ms

So, that seems ok.

> 2)  root@AbNormal:/home/comp# ip a d 2600:1700:4280:3690::46/128
> Not enough information: "dev" argument is required.
> root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
> traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte
> packets

And that's my mistake. Should be this:

ip a d 2600:1700:4280:3690::46/128 dev enp2s0

traceroute -n 2a04:4e42:b::204

> 3)  root@AbNormal:/home/comp# ip -6 ro d 2600:1700:4280:3690::/60
> root@AbNormal:/home/comp#
> root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
> traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte
> packets
>  1  * * *

Was worth a try, but this is not it.

Come thinking about it, please also run this:

ip ro get 2a04:4e42:b::204

Reco

Re: Fwd: Re: Unknown URL

[The Wanderer]

On 2018-02-22 at 13:17, Stephen P. Molnar wrote:

> On 02/22/2018 12:52 PM, Reco wrote:

>>  Hi.
>>
>> On Thu, Feb 22, 2018 at 12:29:12PM -0500, Stephen P. Molnar wrote:
>>
>>> After installing tcpdump I got:
>>> root@AbNormal:/home/comp# tcpdump -ni any -s0 -w /tmp/fastly.pcap tcp port
>>> 80 or icmp6 or \
 udp port 53
>>> tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size
>>> 262144 bytes
>>> ^C6 packets captured
>>> 6 packets received by filter
>>> 0 packets dropped by kernel
>>> root@AbNormal:/home/comp#
>>
>> The file. Please send the file.

> what file?

At a guess, the file created by that command:
/tmp/fastly.pcap

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Fwd: Re: Unknown URL

[Stephen P. Molnar]

On 02/22/2018 12:52 PM, Reco wrote:

Hi.

On Thu, Feb 22, 2018 at 12:29:12PM -0500, Stephen P. Molnar wrote:

After installing tcpdump I got:
root@AbNormal:/home/comp# tcpdump -ni any -s0 -w /tmp/fastly.pcap tcp port
80 or icmp6 or \

udp port 53

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size
262144 bytes
^C6 packets captured
6 packets received by filter
0 packets dropped by kernel
root@AbNormal:/home/comp#

The file. Please send the file.   < what file?


The next part *looks* normal, but it ain't.


root@AbNormal:/home/comp# ip a l
2: enp2s0:  mtu 1500 qdisc pfifo_fast state
UP group default qlen 1000
 link/ether bc:ee:7b:5e:83:36 brd ff:ff:ff:ff:ff:ff

..

 inet6 2600:1700:4280:3690::46/128 scope global dynamic
valid_lft 1201940sec preferred_lft 1201940sec
 inet6 2600:1700:4280:3690:800c:68fc:ea2c:23c0/64 scope global temporary
dynamic
valid_lft 597140sec preferred_lft 78692sec
 inet6 2600:1700:4280:3690:beee:7bff:fe5e:8336/64 scope global mngtmpaddr
noprefixroute dynamic
valid_lft 1209054sec preferred_lft 1209054sec

These are your usual run-of-the-mill IPv6 addresses procured via RA,
except for 2600:1700:4280:3690::46/128.
I fail to imagine why would *anyone* provide a /128 address via RA.
Unless they are controlled by aliens or work for IBM, of course.



root@AbNormal:/home/comp# ip ro l table all

..

2600:1700:4280:3690::46 dev enp2s0 proto kernel metric 256  expires
1201893sec pref medium
2600:1700:4280:3690::/64 dev enp2s0 proto ra metric 100  pref medium
2600:1700:4280:3690::/60 via fe80::3e04:61ff:feb3:3c20 dev enp2s0 proto ra
metric 100  pref medium

..

These are, well, uncommon.
2600:1700:4280:3690::46 is there because you have /128 address.
/64 route is there because you have IPv6 addresses with the same mask
assigned.
/60 route was provided you by RA. Probably means that your ISP is
generous, and by itself it could be the source of your trouble.



default via fe80::3e04:61ff:feb3:3c20 dev enp2s0 proto static metric 100
pref medium

And this is your "default gateway" route.



root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte
packets
  1  * * *

This is bad. Your IPv6 traffic cannot pass even a default gateway.

Meaning, I require a couple of additional tests.

1) ping -c2 fe80::3e04:61ff:feb3:3c20%enp2s0

Should work, but never hurts to check.

2) ip a d 2600:1700:4280:3690::46/128

traceroute -n 2a04:4e42:b::204

3) ip -6 ro d 2600:1700:4280:3690::/60

traceroute -n 2a04:4e42:b::204




Reco



Reco

Please see comment at top of your reply.

The next lies are keyed to you numbered request:

1)  root@AbNormal:/home/comp# ping -c2 fe80::3e04:61ff:feb3:3c20%enp2s0
PING fe80::3e04:61ff:feb3:3c20%enp2s0(fe80::3e04:61ff:feb3:3c20%enp2s0) 
56 data bytes
64 bytes from fe80::3e04:61ff:feb3:3c20%enp2s0: icmp_seq=1 ttl=64 
time=0.258 ms
64 bytes from fe80::3e04:61ff:feb3:3c20%enp2s0: icmp_seq=2 ttl=64 
time=0.201 ms


--- fe80::3e04:61ff:feb3:3c20%enp2s0 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 0.201/0.229/0.258/0.032 ms


2)  root@AbNormal:/home/comp# ip a d 2600:1700:4280:3690::46/128
Not enough information: "dev" argument is required.
root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte 
packets

 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

3)  root@AbNormal:/home/comp# ip -6 ro d 2600:1700:4280:3690::/60
root@AbNormal:/home/comp#
root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte 
packets

 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

I'm not sure if I got the  2) commands correctly

Steve

--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Fedora has a boot option that forces the installer to recognize a drive as GPT, can this be added to Debians installer?

[David Wright]

On Thu 22 Feb 2018 at 18:56:11 (+0100), Erwan David wrote:
> Le 02/22/18 à 18:07, Roberto C. Sánchez a écrit :
> > On Thu, Feb 22, 2018 at 04:15:43PM +, Indo Neh wrote:
> >>There is a boot option in Fedora 'inst.gpt' which forces the Fedora 26
> >>Anaconda installer to recognize a drive as a GPT drive for the purposes 
> >> of
> >>the Anaconda installer setting up the drive with a GPT partition table.
> >>
> >>[1]https://rhinstaller.github.io/anaconda/boot-options.html#inst-gpt
> >>
> >>Could this somehow be added to Ubiquity as this option is useful for
> > Ubiquity is the Ubuntu installer.
> >
> > It has been a while since I did a fresh Debian install, but the Debian
> > Installer Manual [0] says:
> >
> > The latter becomes important when booting debian-installer on a UEFI
> > system with CSM because debian-installer checks whether it was
> > started on a BIOS- or on a native UEFI system and installs the
> > corresponding bootloader.
> >
> > That seems to indicate that you should not even have to tell the Debian
> > installer, as it will detect whether to use GPT or not.
> >
> > Regards,
> >
> > -Roberto
> >
> > [0] https://www.debian.org/releases/stable/amd64/install.txt.en
> 
> 
> It's not the same. You can have a GPT partitionned drive on a bios
> machine, those are completely different features (even if some OSes only
> support GPT on UEFI machines and MS-DOS partitionning on BIOS ones)

Yes, but is it not sensible to leave it up to the user to partition it
with GPT themselves? Otherwise, you may have people who go to the
trouble of conducting an installation onto a GPT disk and finding out
at the very end of the process that the system is never going to be
able to boot.

Cheers,
David.

Re: Fedora has a boot option that forces the installer to recognize a drive as GPT, can this be added to Debians installer?

[Erwan David]

Le 02/22/18 à 18:07, Roberto C. Sánchez a écrit :
> On Thu, Feb 22, 2018 at 04:15:43PM +, Indo Neh wrote:
>>There is a boot option in Fedora 'inst.gpt' which forces the Fedora 26
>>Anaconda installer to recognize a drive as a GPT drive for the purposes of
>>the Anaconda installer setting up the drive with a GPT partition table.
>>
>>[1]https://rhinstaller.github.io/anaconda/boot-options.html#inst-gpt
>>
>>Could this somehow be added to Ubiquity as this option is useful for
> Ubiquity is the Ubuntu installer.
>
> It has been a while since I did a fresh Debian install, but the Debian
> Installer Manual [0] says:
>
> The latter becomes important when booting debian-installer on a UEFI
> system with CSM because debian-installer checks whether it was
> started on a BIOS- or on a native UEFI system and installs the
> corresponding bootloader.
>
> That seems to indicate that you should not even have to tell the Debian
> installer, as it will detect whether to use GPT or not.
>
> Regards,
>
> -Roberto
>
> [0] https://www.debian.org/releases/stable/amd64/install.txt.en


It's not the same. You can have a GPT partitionned drive on a bios
machine, those are completely different features (even if some OSes only
support GPT on UEFI machines and MS-DOS partitionning on BIOS ones)

Re: domain names, was: hostname

[David Wright]

In case it's not clear,
hostname:foo (in /etc/hostname),
domain:  example.com (name of a registered domain),
domain name: I'll try to avoid,
domainname:  foo.example.com (also variously called FQDN, canonical hostname).

On Mon 19 Feb 2018 at 18:39:02 (+), Brian wrote:
> On Mon 19 Feb 2018 at 10:23:56 -0600, David Wright wrote:
> 
> > On Mon 19 Feb 2018 at 12:28:03 (+), Jeremy Nicoll wrote:
> > > On Thu, 15 Feb 2018, at 16:21, Dan Purgert wrote:
> > > 
> > > > > Later, once you understand how a local network works, you can come
> > > > > up with a theme.  Or some convention that lets you identify the
> > > > > computer by its name.  The name that you have chosen.
> > > 
> > > Machine-naming makes sense to me - having done that with a variety
> > > of (blush) Windows machines in my LAN.  I've toyed with versions of 
> > > Linux, and used a few live-CD ones over the years, and I'm fairly sure
> > > that as well as being asked to supply a hostname I've also been asked 
> > > to supply a domain value.
> > > 
> > > What, on a home LAN, is that used for?
> > 
> > Nothing,

I ought to elaborate: giving an empty answer to the name of the domain
results in the domainname being the same as the hostname. So in places
where one might expect to see a domainname, just the hostname is seen.
It's difficult to use the domain's name for anything because it is empty.

> > with the possible exceptions of:
> > 
> > . avoiding this message at boot up:
> >   Mon Feb 19 04:58:38 2018: [] Starting MTA:hostname --fqdn did not 
> > return a fully qualified name,
> >   Mon Feb 19 04:58:38 2018: dc_minimaldns will not work. Please fix your 
> > /etc/hosts setup.

I've never worked out exactly what it is that "will not work".
Having any string as a domain will make exim4 very happy because
there will be a dot in the canonical hostname in /etc/hosts.

> > . satisfying a broken smarthost¹,
 ² later …

> > . causing some discussion here.

It certainly did that.

> > However, even though bug #504427 has never been answered, I don't
> > think I'm seeing this message any more except on wheezy (as above).
> > So here I have:
> > 
> > $ cat /etc/mailname 
> > alum
> 
> Debian's exim4 README says that mailname should be a FQDN. I find that
> useful for sending mail to "anotheruser".

Sorry, but I haven't been able to work out what you mean.
Is "anotheruser" a username on the same system, somebody or
some machine on the LAN, or something different?

This is a genuine query. If I'm missing out on some useful aspect
of writing in a domain, I'd like to know what it is so I can try
using it. (I have a spare domain registration handy as it happens.)

> But mailname has nothing to
> do with domain as enquired about by Jeremy Nicoll.

The contents of /etc/mailname is the answer to this question:
"It should be the single, fully qualified domainname (FQDN)."
so, because the domain is empty, the FQDN will be the same as
the hostname. I was merely showing that to be the case here.

As pointed out elsewhere, mailname can be used to generate
Message-IDs (mutt does) which might not be globally unique,
not something to concern most home users, and it can be
mitigated. It's also used as the envelope-from, it appears,
between the mail client and exim which can rewrite it.
I guess that if you submit mail directly from, say, mutt to
a remote smarthost, it would be a good idea to place an
email address into /etc/mailname.

> > $ head /etc/hosts
> > # /root/hosts-1-local-template
> > # List of local hosts.
> > # Adjust the two lines for this host when installing.
> > # Check the IPv6 lines occasionally because they change them.
> > 
> > 127.0.0.1   localhost
> > 127.0.1.1   alum
> 
> alum is the canonical_hostname. It is used by exim to HELO with. Many
> mail servers will not accept mail directly from you because it is not a
> FQDN.

This is why I wrote "broken" at ². The OP wrote "on a home LAN",
in which case it's unlikely that they relay mail to mail servers
on port 25. More likely is that they use a smarthost with a mail
submission system on port 587 or possibly 465 (though 25 is
allowed for broken senders³).

As submission involves obligatory authentication, there's no reason
to reject a submission just because the HELO has no dot in it. And
even if a sender screws up the envelope-from, it's likely that the
mail submission knows a valid email address associated with the
authenticator's registration details.

> > 192.168.1.1 router
> > 192.168.1.2 roku2w
> > $ 
> > 
> > I've sometimes wondered what other people dream up as their
> > domainnames; that is, people who don't have a legitimate reason
> > to put something like example.com.
> 
> Whatever is dreamt up as a domain name is put into /etc/hosts by the
> installer as
> 
> 127.0.1.1   alum.dreamtupalum

And what is the benefit for the mail submission system in being woken
up with   HELO alum.dreamtup   rather than   HELO alum   ?
Extra brownie 

Re: BIND and iptables config

[David Wright]

On Fri 16 Feb 2018 at 08:53:27 (-0500), Henning Follmann wrote:
> On Fri, Feb 16, 2018 at 04:26:14AM +0100, Rodary Jacques wrote:
> > Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit :
> > > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote:
> > > > With NetworkManager, /etc/network/interfaces has only the loopbak 
> > > > interface, and I can't use wicd which can't deal with two wired 
> > > > interfaces. And, Henning Follmann, my English is too poor to explain 
> > > > clearly my setup which is the standard one when your ISP gives you one 
> > > > routable address and you want your home LAN to have access to internet.
> > > > Thanks for your interest anyway.
> > > > Jacques
> > > > 
> > > 
> > > Hello,
> > > no your english was good enough to describe your setup. And I would say
> > > that 90% of "us" have a form of "dialup" with on routable ip address and a
> > > NAT setup.
> > > First bind is not "standard" in this kind of situation and makes things
> > > overly complicated. I would recommend dnsmasq instead. It is much more
> > > staight forward for a NAT box to setup. It will also provide you with a
> > > dhcp server.
> > > And in your situation you also want to disable/avoid the NetworkManager. 
> > I told before that wiced can't deal with two wired interfaces.
> 
> That is not true, but lets ignore this for now.

I would be interested to know how you do this. I can't even see a way
to make wicd make connections on two interfaces at the same time where
one is wired and the other wireless. As soon as you select one
interface, the other gets disconnected. Do you have some CLI magic
that makes it keep the first connection going?

Cheers,
David.

Re: Fwd: Re: Unknown URL

[Reco]

Hi.

On Thu, Feb 22, 2018 at 12:29:12PM -0500, Stephen P. Molnar wrote:
> After installing tcpdump I got:
> root@AbNormal:/home/comp# tcpdump -ni any -s0 -w /tmp/fastly.pcap tcp port
> 80 or icmp6 or \
> > udp port 53
> tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size
> 262144 bytes
> ^C6 packets captured
> 6 packets received by filter
> 0 packets dropped by kernel
> root@AbNormal:/home/comp#

The file. Please send the file.


The next part *looks* normal, but it ain't.

> root@AbNormal:/home/comp# ip a l
> 2: enp2s0:  mtu 1500 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether bc:ee:7b:5e:83:36 brd ff:ff:ff:ff:ff:ff
...
> inet6 2600:1700:4280:3690::46/128 scope global dynamic
>valid_lft 1201940sec preferred_lft 1201940sec
> inet6 2600:1700:4280:3690:800c:68fc:ea2c:23c0/64 scope global temporary
> dynamic
>valid_lft 597140sec preferred_lft 78692sec
> inet6 2600:1700:4280:3690:beee:7bff:fe5e:8336/64 scope global mngtmpaddr
> noprefixroute dynamic
>valid_lft 1209054sec preferred_lft 1209054sec

These are your usual run-of-the-mill IPv6 addresses procured via RA,
except for 2600:1700:4280:3690::46/128.
I fail to imagine why would *anyone* provide a /128 address via RA.
Unless they are controlled by aliens or work for IBM, of course.


> root@AbNormal:/home/comp# ip ro l table all
...
> 2600:1700:4280:3690::46 dev enp2s0 proto kernel metric 256  expires
> 1201893sec pref medium
> 2600:1700:4280:3690::/64 dev enp2s0 proto ra metric 100  pref medium
> 2600:1700:4280:3690::/60 via fe80::3e04:61ff:feb3:3c20 dev enp2s0 proto ra
> metric 100  pref medium
...

These are, well, uncommon.
2600:1700:4280:3690::46 is there because you have /128 address.
/64 route is there because you have IPv6 addresses with the same mask
assigned.
/60 route was provided you by RA. Probably means that your ISP is
generous, and by itself it could be the source of your trouble.


> default via fe80::3e04:61ff:feb3:3c20 dev enp2s0 proto static metric 100
> pref medium

And this is your "default gateway" route.


> root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
> traceroute to 2a04:4e42:b::204 (2a04:4e42:b::204), 30 hops max, 80 byte
> packets
>  1  * * *

This is bad. Your IPv6 traffic cannot pass even a default gateway.

Meaning, I require a couple of additional tests.

1) ping -c2 fe80::3e04:61ff:feb3:3c20%enp2s0

Should work, but never hurts to check.

2) ip a d 2600:1700:4280:3690::46/128

traceroute -n 2a04:4e42:b::204

3) ip -6 ro d 2600:1700:4280:3690::/60

traceroute -n 2a04:4e42:b::204

Reco

RE: Wheezy to Stretch

[Kleene, Steven (kleenesj)]

On Wednesday, February 21, 2018 12:45 PM, I wrote:

> I am running Wheezy (v7 = oldoldstable) and intend to replace it with a fresh
> install of Stretch (v9 = stable) before Wheezy's support runs out on May
> 31st.  I will try the default systemd installation and see how I like it.
> ...
> I know systemd doesn't have inittab.  Will the default installation leave me
> with a terminal interface whenever I boot?  If not, how will I accomplish
> that?

On Wednesday, February 21, 2018 1:11 PM,Greg Wooledge [wool...@eeg.ccf.org] 
replied:

> The default target of systemd in Debian is "graphical.target", which
> means that if you have installed a Display Manager (gdm3, lightdm,
> etc.) it will be started at boot time.
>
> If you don't want that, the other default target you can use is
> named "multi-user.target".  This one will not run a Display Manager.
>
> You can check your default target by running "systemctl get-default".
>
> You can set your default target by running "systemctl set-default foo".

That sounds like just what I need to know.  Thanks to you and to all of the
others who followed up with helpful discussions.

From: deloptes [delop...@gmail.com]
Sent: Thursday, February 22, 2018 12:35 PM
To: debian-user@lists.debian.org
Subject: Re: Wheezy to Stretch

Roberto C. Sánchez wrote:

> Just keep in mind that we all have different experiences and different
> reasons for thinking and believing the things that we think and believe.

I can only support this (in fact all your writing, but removed most of it to
make it easier to read).

12+ Years ago I had difficulties upgrading Debian and started following the
release notes. After this it was very easy to do an upgrade, because most
of the problems one would face during upgrade were already covered in the
release notes.
Even in the past few releases on one machine or type of setup it would work
and on another it would not and again the release notes were very helpful
to find a way out.

I would recommend anyone who wants to do an upgrade to follow the release
notes and contribute if facing problems.

regards

Re: Anyone using AMD Radeon R9 270x under Debian other than vesa drivers.

[Sven Joachim]

On 2018-02-22 15:57 +0100, Dominique Dumont wrote:

> On Tuesday, 20 February 2018 11:40:49 CET terryc wrote:
>> i've just finshed trying amdgp, radeon 7 ati drivers under wheezy and
>> stretch and it is a total wipeout. All ii can get working is a copied
>> default single screen under vesa driver.
>
> Can you make sure that radeon kernel module is loaded ?

What is really needed is the firmware for the card, contained in the
firmware-amd-graphics package (since stretch, older Debian releases
shipped it in firmware-linux-nonfree).  After installing that package
from non-free and rebooting the card should work fine.

Cheers,
   Sven

Re: Wheezy to Stretch

[deloptes]

Roberto C. Sánchez wrote:

> Just keep in mind that we all have different experiences and different
> reasons for thinking and believing the things that we think and believe.

I can only support this (in fact all your writing, but removed most of it to
make it easier to read).

12+ Years ago I had difficulties upgrading Debian and started following the
release notes. After this it was very easy to do an upgrade, because most
of the problems one would face during upgrade were already covered in the
release notes.
Even in the past few releases on one machine or type of setup it would work
and on another it would not and again the release notes were very helpful
to find a way out.

I would recommend anyone who wants to do an upgrade to follow the release
notes and contribute if facing problems.

regards

Re: Fwd: Re: Unknown URL

[Stephen P. Molnar]

On 02/22/2018 12:02 PM, Reco wrote:

Hi.

On Thu, Feb 22, 2018 at 11:41:35AM -0500, Stephen P. Molnar wrote:

Then

root@AbNormal:/home/comp# apt-get update
Ign:1 http://debian.uchicago.edu/debian stretch InRelease
Hit:3 http://debian.uchicago.edu/debian stretch Release
Get:2 http://debian.uchicago.edu/debian stretch-updates InRelease [91.0 kB]
0% [Connecting to prod.debian.map.fastly.net (2a04:4e42:b::204)]

Perfect.



and

root@AbNormal:/home/comp# dpkg --print-foreign-architectures
i386

That looks about right.



Always glad to be able to help remove boredom!  Other than my comp chem
calculations, I find boredom to very boring.

At least one of us doing real science. I'm ashamed to mention what I do
for the living ???.

And now to the fun part. Please provide these:

tcpdump -ni any -s0 -w /tmp/fastly.pcap tcp port 80 or icmp6 or \
udp port 53

ip a l

ip ro l table all

traceroute -n 2a04:4e42:b::204


It should be noted that:

1) tcpdump should be run while you're invoking apt-get, with IPv6 stack
operational (i.e. no disable_ipv6 trick).

2) To terminate tcpdump use Ctrl+C. All its output will to to a file.

3) tcpdump will capture all tcp:80 (i.e. - HTTP), that's intentional.
This may, or may not be a privacy issue.

4) tcpdump requires CAP_NET_RAW and CAP_NET_ADMIN to function properly.
Meaning - you run it as root. Other commands should not require root.

5) If tcpdump is not installed there, use disable_ipv6 trick temporarily
to apt-get it.

Reco


Reco

After installing tcpdump I got:
root@AbNormal:/home/comp# tcpdump -ni any -s0 -w /tmp/fastly.pcap tcp 
port 80 or icmp6 or \

> udp port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture 
size 262144 bytes

^C6 packets captured
6 packets received by filter
0 packets dropped by kernel
root@AbNormal:/home/comp#


root@AbNormal:/home/comp# ip a l
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp2s0:  mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000

link/ether bc:ee:7b:5e:83:36 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.122/24 brd 192.168.1.255 scope global dynamic enp2s0
   valid_lft 78740sec preferred_lft 78740sec
inet6 2600:1700:4280:3690::46/128 scope global dynamic
   valid_lft 1201940sec preferred_lft 1201940sec
inet6 2600:1700:4280:3690:800c:68fc:ea2c:23c0/64 scope global 
temporary dynamic

   valid_lft 597140sec preferred_lft 78692sec
inet6 2600:1700:4280:3690:beee:7bff:fe5e:8336/64 scope global 
mngtmpaddr noprefixroute dynamic

   valid_lft 1209054sec preferred_lft 1209054sec
inet6 fe80::beee:7bff:fe5e:8336/64 scope link
   valid_lft forever preferred_lft forever
root@AbNormal:/home/comp#


root@AbNormal:/home/comp# ip ro l table all
default via 192.168.1.254 dev enp2s0 proto static metric 100
192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.122 
metric 100
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 
127.0.0.1

local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 
127.0.0.1
broadcast 192.168.1.0 dev enp2s0 table local proto kernel scope link src 
192.168.1.122
local 192.168.1.122 dev enp2s0 table local proto kernel scope host src 
192.168.1.122
broadcast 192.168.1.255 dev enp2s0 table local proto kernel scope link 
src 192.168.1.122
2600:1700:4280:3690::46 dev enp2s0 proto kernel metric 256  expires 
1201893sec pref medium

2600:1700:4280:3690::/64 dev enp2s0 proto ra metric 100  pref medium
2600:1700:4280:3690::/60 via fe80::3e04:61ff:feb3:3c20 dev enp2s0 proto 
ra metric 100  pref medium

fe80::3e04:61ff:feb3:3c20 dev enp2s0 proto static metric 100  pref medium
fe80::/64 dev enp2s0 proto kernel metric 256  pref medium
default via fe80::3e04:61ff:feb3:3c20 dev enp2s0 proto static metric 
100  pref medium
unreachable default dev lo proto kernel metric 4294967295  error -101 
pref medium

local ::1 dev lo table local proto none metric 0  pref medium
local 2600:1700:4280:3690::46 dev lo table local proto none metric 0  
pref medium
local 2600:1700:4280:3690:800c:68fc:ea2c:23c0 dev lo table local proto 
none metric 0  pref medium
local 2600:1700:4280:3690:beee:7bff:fe5e:8336 dev lo table local proto 
none metric 0  pref medium
local fe80::beee:7bff:fe5e:8336 dev lo table local proto none metric 0  
pref medium

ff00::/8 dev enp2s0 table local metric 256  pref medium
unreachable default dev lo proto kernel metric 4294967295  error -101 
pref medium

root@AbNormal:/home/comp#


root@AbNormal:/home/comp# traceroute -n 2a04:4e42:b::204
traceroute to 

Re: Fedora has a boot option that forces the installer to recognize a drive as GPT, can this be added to Debians installer?

[Roberto C . Sánchez]

On Thu, Feb 22, 2018 at 04:15:43PM +, Indo Neh wrote:
>There is a boot option in Fedora 'inst.gpt' which forces the Fedora 26
>Anaconda installer to recognize a drive as a GPT drive for the purposes of
>the Anaconda installer setting up the drive with a GPT partition table.
> 
>[1]https://rhinstaller.github.io/anaconda/boot-options.html#inst-gpt
> 
>Could this somehow be added to Ubiquity as this option is useful for

Ubiquity is the Ubuntu installer.

It has been a while since I did a fresh Debian install, but the Debian
Installer Manual [0] says:

The latter becomes important when booting debian-installer on a UEFI
system with CSM because debian-installer checks whether it was
started on a BIOS- or on a native UEFI system and installs the
corresponding bootloader.

That seems to indicate that you should not even have to tell the Debian
installer, as it will detect whether to use GPT or not.

Regards,

-Roberto

[0] https://www.debian.org/releases/stable/amd64/install.txt.en
-- 
Roberto C. Sánchez

Re: Fwd: Re: Unknown URL

[Reco]

Hi.

On Thu, Feb 22, 2018 at 11:41:35AM -0500, Stephen P. Molnar wrote:
> Then
> 
> root@AbNormal:/home/comp# apt-get update
> Ign:1 http://debian.uchicago.edu/debian stretch InRelease
> Hit:3 http://debian.uchicago.edu/debian stretch Release
> Get:2 http://debian.uchicago.edu/debian stretch-updates InRelease [91.0 kB]
> 0% [Connecting to prod.debian.map.fastly.net (2a04:4e42:b::204)]

Perfect.


> and
> 
> root@AbNormal:/home/comp# dpkg --print-foreign-architectures
> i386

That looks about right.


> Always glad to be able to help remove boredom!  Other than my comp chem
> calculations, I find boredom to very boring.

At least one of us doing real science. I'm ashamed to mention what I do
for the living ☺.

And now to the fun part. Please provide these:

tcpdump -ni any -s0 -w /tmp/fastly.pcap tcp port 80 or icmp6 or \
udp port 53

ip a l

ip ro l table all

traceroute -n 2a04:4e42:b::204


It should be noted that:

1) tcpdump should be run while you're invoking apt-get, with IPv6 stack
operational (i.e. no disable_ipv6 trick).

2) To terminate tcpdump use Ctrl+C. All its output will to to a file.

3) tcpdump will capture all tcp:80 (i.e. - HTTP), that's intentional.
This may, or may not be a privacy issue.

4) tcpdump requires CAP_NET_RAW and CAP_NET_ADMIN to function properly.
Meaning - you run it as root. Other commands should not require root.

5) If tcpdump is not installed there, use disable_ipv6 trick temporarily
to apt-get it.

Reco

Fedora has a boot option that forces the installer to recognize a drive as GPT, can this be added to Debians installer?

[Indo Neh]

There is a boot option in Fedora 'inst.gpt' which forces the Fedora 26
Anaconda installer to recognize a drive as a GPT drive for the purposes of
the Anaconda installer setting up the drive with a GPT partition table.

https://rhinstaller.github.io/anaconda/boot-options.html#inst-gpt

Could this somehow be added to Ubiquity as this option is useful for anyone
who wants to set up a drive on a BIOS-based system as a GPT drive without
having to manually partition the drive after manually setting it as GPT? It
makes the automated drive setup (e.g. encrypted LVM setup) very easy and
painless.
(I'm not subscribed to the list)

Fwd: Re: Unknown URL

[Stephen P. Molnar]

 Original Message 
Subject:Re: Unknown URL
Date:   Thu, 22 Feb 2018 11:31:08 -0500
From:   Stephen P. Molnar 
To: debian-user@lists.debian.org



On 02/22/2018 10:10 AM, Reco wrote:

Hi.

On Thu, Feb 22, 2018 at 10:04:30AM -0500, Stephen P. Molnar wrote:

The only reason I have it
is so that my wife can browse.  Here is my sources.list:

Check the contents of /etc/apt/sources.list.d . It's definitely there.

Just for the fun of it, invoke "dpkg -S" on the problematic file.



I definitely want the other two problems to be solved.

  I have some computational chemistry software that needs i386 libraries.

One thing at a time. First, purge the faulty Opera repo.

Then run "apt-get update". I'm interested in the new output.

Next provide the output of "dpkg --print-foreign-architectures", please.


Your help is really appreciated.

You're welcome. It's been a boring week, I could use some fun.

Reco



Reco

I had already removed Opera from /etc/apt/sources.list.d

/etc/apt/sources.list.dis empty.

Then

root@AbNormal:/home/comp# apt-get update
Ign:1 http://debian.uchicago.edu/debian stretch InRelease
Hit:3 http://debian.uchicago.edu/debian stretch Release
Get:2 http://debian.uchicago.edu/debian stretch-updates InRelease [91.0 kB]
0% [Connecting to prod.debian.map.fastly.net (2a04:4e42:b::204)]

and

root@AbNormal:/home/comp# dpkg --print-foreign-architectures
i386
root@AbNormal:/home/comp#

Always glad to be able to help remove boredom!  Other than my comp chem
calculations, I find boredom to very boring.


To add to my conclusion, I just i stalled Google Earth, 32 bit, with gdebi
(as root) and it installed all of the required 32 bit libraries!  Might this be 
a clue?
 --
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Unknown URL

[Stephen P. Molnar]

On 02/22/2018 10:10 AM, Reco wrote:

Hi.

On Thu, Feb 22, 2018 at 10:04:30AM -0500, Stephen P. Molnar wrote:

The only reason I have it
is so that my wife can browse.  Here is my sources.list:

Check the contents of /etc/apt/sources.list.d . It's definitely there.

Just for the fun of it, invoke "dpkg -S" on the problematic file.



I definitely want the other two problems to be solved.

  I have some computational chemistry software that needs i386 libraries.

One thing at a time. First, purge the faulty Opera repo.

Then run "apt-get update". I'm interested in the new output.

Next provide the output of "dpkg --print-foreign-architectures", please.


Your help is really appreciated.

You're welcome. It's been a boring week, I could use some fun.

Reco



Reco

I had already removed Opera from /etc/apt/sources.list.d

/etc/apt/sources.list.dis empty.

Then

root@AbNormal:/home/comp# apt-get update
Ign:1 http://debian.uchicago.edu/debian stretch InRelease
Hit:3 http://debian.uchicago.edu/debian stretch Release
Get:2 http://debian.uchicago.edu/debian stretch-updates InRelease [91.0 kB]
0% [Connecting to prod.debian.map.fastly.net (2a04:4e42:b::204)]

and

root@AbNormal:/home/comp# dpkg --print-foreign-architectures
i386
root@AbNormal:/home/comp#

Always glad to be able to help remove boredom!  Other than my comp chem 
calculations, I find boredom to very boring.


--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Were is gapcmon?

[Roberto C . Sánchez]

On Thu, Feb 22, 2018 at 03:19:36PM +, Juan R. de Silva wrote:
> On Wed, 21 Feb 2018 21:38:55 -0500, Roberto C. Sánchez wrote:
> 
> > That is a choice you have to make. If you run a firewall on your machine
> > and you do not expose the ports (3551 for apcupsd and 80 for httpd),
> > then there is no real concern. That said, if you do not want to worry
> > about a webserver, you can probably script something that retrieves that
> > data from the apcupsd process on port 3551. It should not require very
> > much effort at all.
> 
> Thanks, Roberto.
> 
I went poking around on my machine and found that if you install the
apcupsd-doc package, then you end with a bunch of examples in
/usr/share/doc/apcupsd/examples/. There appear to be examples at least
in C, Tcl, and shell. You might find something helpful there.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Specifying a device for sox output.

[Tomaž Šolc]

Hi

On 21. 02. 2018 03:19, pe...@easthope.ca wrote:

The two C-Media devices should be able to accept sox output. How
should one of them be specified?


See the manual page for sox ("man sox" in a terminal). Search for "audio
device". The output audio device for sox is set by setting the AUDIODEV
environment. e.g. "AUDIODEV=hw:0,0 play foo.wav" to play on card 0, 
device 0.


Use "aplay -l" to get a list of ALSA devices (you can't use /dev/snd/...
paths directly).


If ekiga is running, is contention possible?


Yes.


If so, is there a way to resolve it.


Use a sound server such as PulseAudio. If you have PulseAudio installed, 
usually the default ALSA device will route the audio through PulseAudio. 
In that case, the output audio device can be set somewhere in PulseAudio 
settings.


Best regards
Tomaž

Re: Were is gapcmon?

[Juan R. de Silva]

On Wed, 21 Feb 2018 21:38:55 -0500, Roberto C. Sánchez wrote:

> On Thu, Feb 22, 2018 at 02:04:12AM +, Juan R. de Silva wrote:
>> 
>> Ups, I've totaly missed that Marc said 'apcupsd'. In this case here are
>> my deep appologies to Marc and everybody Being over busy last couple of
>> days I was quite hasty in this case. Sorry.
>> 
> No problem. I certainly was not offended. It was an honest mistake.
> 
>> BTW. about apcupsd-cgi. I found that in order to use it I need to
>> install appache2. I never needed to run a server on my home desktop
>> before. Wouldn't it be a little overkill to install appache server only
>> to use apcupsd web interface?
>> 
> The dependency is 'apache2 | httpd', so you can use just about any web
> server since they all support CGI. You might find lighttpd simpler than
> apache2.
> 
>> I'm realy not sure I want to spend a lot of time on securing and then
>> maintaning the server. However I'm not realy familiar with the matter.
>> Is it over complicated or I'd rather use CLI to control apcuspd daemon?
>> 
> That is a choice you have to make. If you run a firewall on your machine
> and you do not expose the ports (3551 for apcupsd and 80 for httpd),
> then there is no real concern. That said, if you do not want to worry
> about a webserver, you can probably script something that retrieves that
> data from the apcupsd process on port 3551. It should not require very
> much effort at all.

Thanks, Roberto.

Re: Unknown URL

[Stephen P. Molnar]

On 02/22/2018 10:07 AM, Greg Wooledge wrote:

On Thu, Feb 22, 2018 at 10:04:30AM -0500, Stephen P. Molnar wrote:

I don't want the Opera repository, where is it?  The only reason I have it
is so that my wife can browse.  Here is my sources.list:

Look in /etc/apt/sources.list.d/*.list also.



That was it.

Thanks.

--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Unknown URL

[Reco]

Hi.

On Thu, Feb 22, 2018 at 10:04:30AM -0500, Stephen P. Molnar wrote:
> The only reason I have it
> is so that my wife can browse.  Here is my sources.list:

Check the contents of /etc/apt/sources.list.d . It's definitely there.

Just for the fun of it, invoke "dpkg -S" on the problematic file.


> I definitely want the other two problems to be solved.
> 
>  I have some computational chemistry software that needs i386 libraries.

One thing at a time. First, purge the faulty Opera repo.

Then run "apt-get update". I'm interested in the new output.

Next provide the output of "dpkg --print-foreign-architectures", please.

> Your help is really appreciated.

You're welcome. It's been a boring week, I could use some fun.

Reco

Re: Unknown URL

[Greg Wooledge]

On Thu, Feb 22, 2018 at 10:04:30AM -0500, Stephen P. Molnar wrote:
> I don't want the Opera repository, where is it?  The only reason I have it
> is so that my wife can browse.  Here is my sources.list:

Look in /etc/apt/sources.list.d/*.list also.

Re: Unknown URL

[Stephen P. Molnar]

On 02/22/2018 09:42 AM, Reco wrote:

Hi.

On Thu, Feb 22, 2018 at 09:19:38AM -0500, Stephen P. Molnar wrote:

Simple.

If you configured radvd or dhcpv6 - double-check your setup. You did it
wrong.
If you don't, but used "iface ??? inet6" stanzas in
/etc/network/interfaces - remove them.
If you use NetworkManager, so some other nonsense - convince it not no
configure IPv6 for you, or stop using them.
If anything else fails, try this:

sysctl -w net.ipv6.conf.all.disable_ipv6=1


Thanks for the detailed reply.

I used the installer defaults to configure the network interface.

"Installer defaults" is a very broad term, and the contents of your
installation can differ dramatically depending on the type of install
media used.
Besides it's really been awhile since I used Debian Installer CD1. I
prefer d-i over TFTP these days. More flexibility, less cruft this way.



Here are the contents of /etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

and /etc/networks/interfaces.d is empty.

And that means you're using NetworkManager, wicd, systemd-networkd,
connman or whatever they put in there by default. Not the conventional
ifupdown.



It would seem that there is another problem:  dpkg --add-architecture i386
(as root) no longer seems to work, although it did when I ran it yesterday
after reinstalling the OS.

To my best knowledge this particular invocation of dpkg does not involve
network communication in any way. Therefore it's a different problem.



However I just ran

sysctl -w net.ipv6.conf.all.disable_ipv6=1, as per your suggestion and got:


root@AbNormal:/home/comp# sysctl -w net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6 = 1
root@AbNormal:/home/comp# aprt update
-bash: aprt: command not found
root@AbNormal:/home/comp# apt update
Get:1 http://security.debian.org/debian-security stretch/updates InRelease 
[63.0 kB]
Ign:2 http://debian.uchicago.edu/debian stretch InRelease
Hit:3 http://debian.uchicago.edu/debian stretch-updates InRelease
Hit:4 http://debian.uchicago.edu/debian stretch Release
Get:5 http://security.debian.org/debian-security stretch/updates/contrib 
Sources [1,384 B]
Get:7 http://security.debian.org/debian-security stretch/updates/non-free 
Sources [772 B]
Get:8 http://security.debian.org/debian-security stretch/updates/main Sources 
[116 kB]
Get:9 http://security.debian.org/debian-security stretch/updates/main amd64 
Packages [325 kB]
Get:10 http://security.debian.org/debian-security stretch/updates/main i386 
Packages [326 kB]
Get:11 http://security.debian.org/debian-security stretch/updates/main 
Translation-en [144 kB]
Get:12 http://security.debian.org/debian-security stretch/updates/contrib i386 
Packages [1,776 B]
Get:13 http://security.debian.org/debian-security stretch/updates/contrib amd64 
Packages [1,776 B]
Get:14 http://security.debian.org/debian-security stretch/updates/contrib 
Translation-en [1,759 B]
Get:15 http://security.debian.org/debian-security stretch/updates/non-free 
amd64 Packages [1,268 B]
Get:16 http://security.debian.org/debian-security stretch/updates/non-free i386 
Packages [1,268 B]
Get:17 http://security.debian.org/debian-security stretch/updates/non-free 
Translation-en [481 B]
Get:19 https://deb.opera.com/opera-stable stable/non-free amd64 Packages [1,827 
B]
Err:19 https://deb.opera.com/opera-stable stable/non-free amd64 Packages
   Writing more data than expected (1832 > 1827)
   Hashes of expected file:
- Filesize:1827 [weak]
- SHA256:e53101f11ac6677a265465dc4ebcb85fc1de696d88ddc5440db29f448758a6ae
- SHA1:24da563907645d73682c218bffe94ebefa0ce284 [weak]
- MD5Sum:f339dab9748f817a448f3bf401e76b3a [weak]
   Release file created at: Thu, 22 Feb 2018 07:26:36 +
Fetched 985 kB in 1s (538 kB/s)
Reading package lists... Done
E: Failed to fetch 
https://deb.opera.com/opera-stable/dists/stable/non-free/binary-amd64/Packages.gz  
Writing more data than expected (1832 > 1827)
Hashes of expected file:
 - Filesize:1827 [weak]
 - SHA256:e53101f11ac6677a265465dc4ebcb85fc1de696d88ddc5440db29f448758a6ae
 - SHA1:24da563907645d73682c218bffe94ebefa0ce284 [weak]
 - MD5Sum:f339dab9748f817a448f3bf401e76b3a [weak]
Release file created at: Thu, 22 Feb 2018 07:26:36 +
E: Some index files failed to download. They have been ignored, or old ones 
used instead.

And that, ladies and gentlemen, shows us two things.
First one being - you IPv4 settings are working.
Second - those corporate drones at Opera are unable to setup a proper
Debian repository.



Then I ran apt update and got:

root@AbNormal:/home/comp# apt update
Ign:1 http://debian.uchicago.edu/debian stretch InRelease
Hit:2 http://debian.uchicago.edu/debian stretch-updates InRelease
Hit:3 http://debian.uchicago.edu/debian stretch Release

Re: Anyone using AMD Radeon R9 270x under Debian other than vesa drivers.

[Dominique Dumont]

On Tuesday, 20 February 2018 11:40:49 CET terryc wrote:
> i've just finshed trying amdgp, radeon 7 ati drivers under wheezy and
> stretch and it is a total wipeout. All ii can get working is a copied
> default single screen under vesa driver.

Can you make sure that radeon kernel module is loaded ?

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: Unknown URL

[Reco]

Hi.

On Thu, Feb 22, 2018 at 09:19:38AM -0500, Stephen P. Molnar wrote:
> > Simple.
> > 
> > If you configured radvd or dhcpv6 - double-check your setup. You did it
> > wrong.
> > If you don't, but used "iface ??? inet6" stanzas in
> > /etc/network/interfaces - remove them.
> > If you use NetworkManager, so some other nonsense - convince it not no
> > configure IPv6 for you, or stop using them.
> > If anything else fails, try this:
> > 
> > sysctl -w net.ipv6.conf.all.disable_ipv6=1
> > 
> 
> Thanks for the detailed reply.
> 
> I used the installer defaults to configure the network interface.

"Installer defaults" is a very broad term, and the contents of your
installation can differ dramatically depending on the type of install
media used.
Besides it's really been awhile since I used Debian Installer CD1. I
prefer d-i over TFTP these days. More flexibility, less cruft this way.


> Here are the contents of /etc/network/interfaces:
> 
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
> 
> source /etc/network/interfaces.d/*
> 
> # The loopback network interface
> auto lo
> iface lo inet loopback
> 
> and /etc/networks/interfaces.d is empty.

And that means you're using NetworkManager, wicd, systemd-networkd,
connman or whatever they put in there by default. Not the conventional
ifupdown.


> It would seem that there is another problem:  dpkg --add-architecture i386
> (as root) no longer seems to work, although it did when I ran it yesterday
> after reinstalling the OS.

To my best knowledge this particular invocation of dpkg does not involve
network communication in any way. Therefore it's a different problem.


> However I just ran
> 
> sysctl -w net.ipv6.conf.all.disable_ipv6=1, as per your suggestion and got:
> 
> 
> root@AbNormal:/home/comp# sysctl -w net.ipv6.conf.all.disable_ipv6=1
> net.ipv6.conf.all.disable_ipv6 = 1
> root@AbNormal:/home/comp# aprt update
> -bash: aprt: command not found
> root@AbNormal:/home/comp# apt update
> Get:1 http://security.debian.org/debian-security stretch/updates InRelease 
> [63.0 kB]
> Ign:2 http://debian.uchicago.edu/debian stretch InRelease
> Hit:3 http://debian.uchicago.edu/debian stretch-updates InRelease
> Hit:4 http://debian.uchicago.edu/debian stretch Release
> Get:5 http://security.debian.org/debian-security stretch/updates/contrib 
> Sources [1,384 B]
> Get:7 http://security.debian.org/debian-security stretch/updates/non-free 
> Sources [772 B]
> Get:8 http://security.debian.org/debian-security stretch/updates/main Sources 
> [116 kB]
> Get:9 http://security.debian.org/debian-security stretch/updates/main amd64 
> Packages [325 kB]
> Get:10 http://security.debian.org/debian-security stretch/updates/main i386 
> Packages [326 kB]
> Get:11 http://security.debian.org/debian-security stretch/updates/main 
> Translation-en [144 kB]
> Get:12 http://security.debian.org/debian-security stretch/updates/contrib 
> i386 Packages [1,776 B]
> Get:13 http://security.debian.org/debian-security stretch/updates/contrib 
> amd64 Packages [1,776 B]
> Get:14 http://security.debian.org/debian-security stretch/updates/contrib 
> Translation-en [1,759 B]
> Get:15 http://security.debian.org/debian-security stretch/updates/non-free 
> amd64 Packages [1,268 B]
> Get:16 http://security.debian.org/debian-security stretch/updates/non-free 
> i386 Packages [1,268 B]
> Get:17 http://security.debian.org/debian-security stretch/updates/non-free 
> Translation-en [481 B]
> Get:19 https://deb.opera.com/opera-stable stable/non-free amd64 Packages 
> [1,827 B]
> Err:19 https://deb.opera.com/opera-stable stable/non-free amd64 Packages
>   Writing more data than expected (1832 > 1827)
>   Hashes of expected file:
>- Filesize:1827 [weak]
>- SHA256:e53101f11ac6677a265465dc4ebcb85fc1de696d88ddc5440db29f448758a6ae
>- SHA1:24da563907645d73682c218bffe94ebefa0ce284 [weak]
>- MD5Sum:f339dab9748f817a448f3bf401e76b3a [weak]
>   Release file created at: Thu, 22 Feb 2018 07:26:36 +
> Fetched 985 kB in 1s (538 kB/s)
> Reading package lists... Done
> E: Failed to fetch 
> https://deb.opera.com/opera-stable/dists/stable/non-free/binary-amd64/Packages.gz
>   Writing more data than expected (1832 > 1827)
>Hashes of expected file:
> - Filesize:1827 [weak]
> - SHA256:e53101f11ac6677a265465dc4ebcb85fc1de696d88ddc5440db29f448758a6ae
> - SHA1:24da563907645d73682c218bffe94ebefa0ce284 [weak]
> - MD5Sum:f339dab9748f817a448f3bf401e76b3a [weak]
>Release file created at: Thu, 22 Feb 2018 07:26:36 +
> E: Some index files failed to download. They have been ignored, or old ones 
> used instead.

And that, ladies and gentlemen, shows us two things.
First one being - you IPv4 settings are working.
Second - those corporate drones at Opera are unable to setup a proper
Debian repository.


> Then I ran apt update and got:
> 
> root@AbNormal:/home/comp# apt update
> Ign:1 

Anyone using AMD Radeon R9 270x under Debian other than vesa drivers.

[terryc]

How?
As per subject I am trying to get something other than a basic single
screen screen running on this dual port GPU.

i've just finshed trying amdgp, radeon 7 ati drivers under wheezy and
stretch and it is a total wipeout. All ii can get working is a copied
default single screen under vesa driver.

I would prefer the open source, but on reverting to the AMD
proprietary, fglrx, it seems even that is now denied as Stretch no
longer meets the xorg conditions.

FYI. I've previously had a AMD HD7790 running earlier proprietary
driver. at this stage, it seems thatmy only alternastive to get this
working is to go proprietary under suppled packets for RH, Ubuntu, etc.

Re: Unknown URL

[Stephen P. Molnar]

On 02/21/2018 11:23 PM, Reco wrote:

Hi.

I prefer on-list communication.

On Wed, Feb 21, 2018 at 06:26:37PM -0500, Stephen P. Molnar wrote:

On 02/21/2018 04:03 PM, Reco wrote:

Hi.

On Wed, Feb 21, 2018 at 03:41:08PM -0500, Stephen P. Molnar wrote:

I have just installed Stretch and have what, to me at least, is an unknown
URL when I do apt update (as root).

[Connecting to prod.debian.map.fastly.net (2a04:4e42:b::204)]

That's because you have this in your sources.list:


debhttp://security.debian.org/debian-security/  stretch/updates main contrib

security.debian.org tries to redirect you to the mirrors that are
nearest to you.

It just so happens that your host has IPv6 address from somewhere, so
apt tries IPv6 first, then another, and finally falls back to IPv4.

For example, from here it looks like this:

$ wget -S --spiderhttp://security.debian.org
Spider mode enabled. Check if remote file exists.
--2018-02-21 23:56:33--http://security.debian.org/
Resolving security.debian.org (security.debian.org)...
2001:a78:5:1:216:35ff:fe7f:6ceb, 2a02:16a8:dc41:100::233,
217.196.149.233, ..
.
Connecting to security.debian.org
(security.debian.org)|2001:a78:5:1:216:35ff:fe7f:6ceb|:80
..

$ getent hosts 2001:a78:5:1:216:35ff:fe7f:6ceb
2001:a78:5:1:216:35ff:fe7f:6ceb lobos.debian.org

Therefore here security.debian.org = lobos.debian.org


Since prod.debian.map.fastly.net is reachable from here, I suggest you
to fix your IPv6 setup, or squash it altogether in case you don't
control it.

Reco



While I am most appreciative of your response, I don't have the fainest idea
as to what you are suggesting that I do when you say "Since
prod.debian.map.fastly.net is reachable from here, I suggest you to fix your
IPv6 setup, or squash it altogether in case you don't control it.

Simple.

If you configured radvd or dhcpv6 - double-check your setup. You did it
wrong.
If you don't, but used "iface ??? inet6" stanzas in
/etc/network/interfaces - remove them.
If you use NetworkManager, so some other nonsense - convince it not no
configure IPv6 for you, or stop using them.
If anything else fails, try this:

sysctl -w net.ipv6.conf.all.disable_ipv6=1

Reco


Reco

Thanks for the detailed reply.

I used the installer defaults to configure the network interface.

Here are the contents of /etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

and /etc/networks/interfaces.d is empty.

It would seem that there is another problem:  dpkg --add-architecture 
i386 (as root) no longer seems to work, although it did when I ran it 
yesterday after reinstalling the OS.


However I just ran

sysctl -w net.ipv6.conf.all.disable_ipv6=1, as per your suggestion and got:


root@AbNormal:/home/comp# sysctl -w net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6 = 1
root@AbNormal:/home/comp# aprt update
-bash: aprt: command not found
root@AbNormal:/home/comp# apt update
Get:1 http://security.debian.org/debian-security stretch/updates InRelease 
[63.0 kB]
Ign:2 http://debian.uchicago.edu/debian stretch InRelease
Hit:3 http://debian.uchicago.edu/debian stretch-updates InRelease
Hit:4 http://debian.uchicago.edu/debian stretch Release
Get:5 http://security.debian.org/debian-security stretch/updates/contrib 
Sources [1,384 B]
Get:7 http://security.debian.org/debian-security stretch/updates/non-free 
Sources [772 B]
Get:8 http://security.debian.org/debian-security stretch/updates/main Sources 
[116 kB]
Get:9 http://security.debian.org/debian-security stretch/updates/main amd64 
Packages [325 kB]
Get:10 http://security.debian.org/debian-security stretch/updates/main i386 
Packages [326 kB]
Get:11 http://security.debian.org/debian-security stretch/updates/main 
Translation-en [144 kB]
Get:12 http://security.debian.org/debian-security stretch/updates/contrib i386 
Packages [1,776 B]
Get:13 http://security.debian.org/debian-security stretch/updates/contrib amd64 
Packages [1,776 B]
Get:14 http://security.debian.org/debian-security stretch/updates/contrib 
Translation-en [1,759 B]
Get:15 http://security.debian.org/debian-security stretch/updates/non-free 
amd64 Packages [1,268 B]
Get:16 http://security.debian.org/debian-security stretch/updates/non-free i386 
Packages [1,268 B]
Get:17 http://security.debian.org/debian-security stretch/updates/non-free 
Translation-en [481 B]
Get:19 https://deb.opera.com/opera-stable stable/non-free amd64 Packages [1,827 
B]
Err:19 https://deb.opera.com/opera-stable stable/non-free amd64 Packages
  Writing more data than expected (1832 > 1827)
  Hashes of expected file:
   - Filesize:1827 [weak]
   - SHA256:e53101f11ac6677a265465dc4ebcb85fc1de696d88ddc5440db29f448758a6ae
   - SHA1:24da563907645d73682c218bffe94ebefa0ce284 [weak]
   - MD5Sum:f339dab9748f817a448f3bf401e76b3a [weak]
  Release 

Re: Wheezy to Stretch

[Roberto C . Sánchez]

On Wed, Feb 21, 2018 at 11:07:09PM -0800, Jimmy Johnson wrote:
> 
> First off you're quoting something you have read and not from any real
> experience.  

You have aboslutely no evidence to support your statement. I don't
think rhkramer has specifically stated whether he is basing his
statements on his own experience or what he read. However, others have
spoken up in this thread regarding your suggestion and the results are
mixed: some have tried and succeeded, while others have tried it and
failed.

> I can say this, I run 5 laptops and two desktops, one laptop is
> reaching it's end of life for kde plasma upstream, it's an older real IBM
> Thinkpad, while all the others are different makes and models, AMD and
> Intel, none are the same but they are running Wheezy, Jessie, Stretch,
> Buster, Sid, 14.04 lts, 16.04 lts, 18.04 lts and I test other systems of
> interest too and it keeps me busy, these are not virtual installs, they are
> real hardware installs and I fix my problems, that's how I learn, I've been
> doing this for more than 20 years, it's called experience, real experience.

I am not trying to minimize your experience, but by my count it is
likely that at most one or two of the systems you list might have been
subjected to a wheezy -> stretch upgrade. Now, you may have actually
tried it on all of them and then gone on to install different versions
or distros on them, but that is not really the point.

Your experience, though lengthy in terms of number of years, is
essentially anecdotal. If you approached this discussion saying that you
recommend the procedure after having attempted it on 10 server clusters
of 100 servers each in varying configurations, then that would be
different.

Put differently, I have done a fair amount of electrical work on my home
over the years. That, however, does not qualify me to read the national
eletrical code and respond with "those idiots have no idea what they are
saying." Many people, including Debian Developers, other Debian
contributors, and regular users have contributed to getting Debian to
where it is after more than 25 years. If you have a better approach,
please document it, publish it, post it to the appropriate mailing
lists, file wishlist bugs against the right packages, get others to test
it and reproduce your results, and then get it adopted by the project.
That is how consensus is built in a Free Software community.

Otherwise, please do others courtesy of being forthright by adding a
simple "I've done this one (or twice, or however many times) and it
worked for me and my configuration, but YMMV."

> No more or less than anybody else here, I don't know the OP or what his
> capabilities are and my time is limited, but when I see a post where I can
> help I will, what else can you ask from a fellow Linux User.

It is definitely a good thing to want to help fellow users. However,
please keep in mind that, as several others have pointed out, your
recommended course of action has some potential pitfalls. Beyond that,
it is even specifically discouraged in the official release notes. That
is not because some group of people sat around trying to think how they
could waste users' time and ruin their experience with Debian. Rather,
it was a concensus reached based on their collective knowledge and
experience. If you feel like that should be challenged, I have already
outlined the steps.

> Just one other
> thing, I'm not a joiner and I won't get held back. I'm done discussing this
> tread, unless the OP has a question for me. Your like a pack of wolf's ready
> to pounce on anything different than what you have read and some of you have
> not changed in the 20+ years I've been using Linux, you are bullies and mean
> to anyone different than you,
> 
I think you are perceiving personal attacks where none are being made.
It is common and natural to want to speak up when one hears bad advice
or advice without appropriate warnings being given. For example, if I
am talking with someone about how to reach some destination on foot and
say something like "and when you come to this busy intersection, just
close your eyes and start crossing the street and the cars will stop and
let you pass," it would not be at all surprising to hear that
challenged. We are taught from a young age that crossing the street is
dangerous and that there is a right way to do it.

Now, upgrading Debian is not dangerous like crossing the street (unlike
upgrading Windows or RedHat). However, for many users, a catastrophic
mishap during an upgrade would be very inconvenient. It might prevent
them from doing work, school, or some other important task. The other
participants in this thread are simply trying to be good netizens and
help their fellow user, same as you.

Please, continue lending assistance to your fellow users. As far as
places to find help, debian-user has always been one of the best places
for users of Debian (and even related distros) and has been around
longer than most other 

Re: [partial resolution] Re: Problem withj dd

[Brian]

On Thu 22 Feb 2018 at 06:45:47 +0300, Abdullah Ramazanoglu wrote:

> On Wed, 21 Feb 2018 12:39:28 -0600
> Richard Owlett  wrote:
> > On 02/21/2018 12:22 PM, Reco wrote:
> > > On Wed, Feb 21, 2018 at 11:39:42AM -0600, Richard Owlett wrote:  
> 
> > A variation of the "device does not always get the same /dev/??? 
> > designation".
> 
> You can find out what device it is mapped to from dmesg output.

I get:

  dmesg: read kernel buffer failed: Operation not permitted

Since dd has to be used as the superuser I suppose an extra command as
root is neither here nor there. OTOH, 'lsblk' works nicely for a user.

-- 
Brian.

Re: Wheezy to Stretch

[rhkramer]

On Thursday, February 22, 2018 02:07:09 AM Jimmy Johnson wrote:
> On 02/21/2018 07:02 PM, rhkra...@gmail.com wrote:
> > On Wednesday, February 21, 2018 03:40:51 PM Jimmy Johnson wrote:
> >> On 02/21/2018 10:47 AM, Roberto C. S�nchez wrote:
> >>> Note that upgrades skipping a release (e.g., wheezy -> stretch instead
> >>> of wheezy -> jessie -> stretch) are not supported. A fresh install
> >>> sounds like the better route in this case.
> >> 
> >> I know what I'm talking about and if I can do it anybody can do it,
> >> Debian has given us all the tools we need to upgrade any stable release
> >> to current stable release or higher for that matter, thank about it.
> >> Just start with a simple upgrade first before tackling the other things,
> >> it's not rocket science after all.
> > 
> > And what if their system has slightly different hardware or some other
> > difference such that your advice doesn't work?  (AFAICT, the fact that
> > Debian does not support an upgrade skipping a release means that little
> > or no testing has been done and there is an indeterminate amount of
> > risk.)
> 
> First off you're quoting something you have read and not from any real
> experience.  I can say this,

You are absolutely right about that--they (the developers) wrote that it is 
not supported.  Are you supporting it instead?

It's wonderful that it worked well for you, but can you (and will youi) 
guarantee that it will work well for others?

If so, why don't you contact Debian and offer to support such upgrades?

> I run 5 laptops and two desktops, one
> laptop is reaching it's end of life for kde plasma upstream, it's an
> older real IBM Thinkpad, while all the others are different makes and
> models, AMD and Intel, none are the same but they are running Wheezy,
> Jessie, Stretch, Buster, Sid, 14.04 lts, 16.04 lts, 18.04 lts and I test
> other systems of interest too and it keeps me busy, these are not
> virtual installs, they are real hardware installs and I fix my problems,
> that's how I learn, I've been doing this for more than 20 years, it's
> called experience, real experience. My main testing desktop has sid on
> sda15 and its probably broken with every release, been moved to more
> computers than I care to remember, but I fix it, clean it and keep
> going, so far this release, knock on wood and thinks to Debian upstream
> repairs have been minimal. Outside of machine language I'm not a coder,
> nor do I use machine language any longer.
> 
> > Will you stand behind the upgrade, and fix his system if there is a
> > problem? (Site visits are usually not cheap.)
> 
> No more or less than anybody else here, I don't know the OP or what his
> capabilities are and my time is limited, but when I see a post where I
> can help I will, what else can you ask from a fellow Linux User.  Just
> one other thing, I'm not a joiner and I won't get held back. I'm done
> discussing this tread, unless the OP has a question for me. 


> Your  like a
> pack of wolf's 

I am one person. 


> ready to pounce on anything different than what you have
> read and some of you have not changed in the 20+ years I've been using
> Linux, you are bullies and mean to anyone different than you, and I am
> different than you period.
> 
> Cheers,

Re: Stretch: problème avec Ethernet Controller RTL8111

[humbert . olivier . 1]

> Je viens d'installer Stretch sur mon nouveau desktop. A l'installation,
> impossible d'avoir une connexion filiaire Ethernet, j'ai dû me contenter
> d'une connexion WiFi. Une fois installé, toujours pas de connexion.
> Le contrôleur graphique me dit : "Réseau" "Filiaire" "câble débranché",
> ce qui n'est évidemment pas le cas. 
> 
> lspci me dit : Ethernet controller RTL8111/8168/8411 PCI Express Gigabit 
> Ethernet Controller... ... kernel driver in use : r8169. Kernel module r8169. 
> 
> Cet Ethernet Controller est partie intégrante de ma Carte mère Gigabyte 
> H110M-S2H 
> 
> Parmi les messages dans /var/log/messages, j'ai récupéré notamment notamment 
> ceux-ci : 
> ...
>  
> - ACPI FADT declares the system doesn't support PCIe ASPM, so disable it 
> . 
> r8169 :02:00.0 : can't disable ASPM ; OS doesn't have ASPM control 
> ...
>  
> r8169 :02:00.0 eth0: RTL8168g/8111g at  
> 28169... enp2s0: renamed from eth0 
>  
> enp2s0 link is not ready 
> Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2 
> unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2) 
> link down 
> 
> Merci d'avance pour votre assistance 
> 
> Bernard 


Bonjour Bernard, et merci pour le diagnostic plutôt complet.

Le message qui tilte mes yeux est :
> unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2) 

ce qui semble signifier que le fichier de ce micro logiciel qui probablement, 
contrôle
l'interface ethernet en question n'est pas présent sur ton système.

Une recherche rapide sur https://packages.debian.org/ nous indique que ce 
fichier rtl8168g-2.fw
appartient au paquet firmware-realtek qui est dans la section non-libre.
(voir : https://packages.debian.org/stretch/firmware-realtek )

Est-il installé sur ta machine ?
Olivier

Re: Stretch: problème avec Ethernet Controller RTL8111

[daniel huhardeaux]

Le 22/02/2018 à 12:58, bd a écrit :

Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2

Bonjour

https://packages.debian.org/fr/stretch/firmware-realtek

Vous n'avez pas activé le dépôt non-free

Cordialement

--
Daniel

Re: Need help debugging total system lockup, probably notebook power saving related

[Ondřej Grover]

Hi,

so far the i915.enable_rc6=0 option seems to have worked. No system hangs
with it so far. Haven't got a feel if battery run-time is worse, but the
difference probably isn't that bad.

Ondrej G.

On Wed, Feb 21, 2018 at 8:09 PM, Ondřej Grover 
wrote:

> Hi Henning,
> thanks for the tip.
>
> However, I've been experiencing this issue already before the
> spectre/meltdown bunch hit the fan.
> It does sound like it a bit, but likely is some different HW stuff.
> For now I'm experimenting with i915.enable_rc6=0. I hope it won't bog down
> the battery run-time too much.
>
> Ondrej G.
>
> On Wed, Feb 21, 2018 at 3:55 PM, Henning Follmann <
> hfollm...@itcfollmann.com> wrote:
>
>> On Wed, Feb 21, 2018 at 09:51:58AM +0100, Ondřej Grover wrote:
>> > Hello,
>> >
>> > I need help debugging random total system lock-ups.
>> > This is a notebook Acer Aspire V3-572G-78A running Debian Stretch with
>> > the 4.9.0-5-amd64 kernel.
>> >
>> > When running on battery (does not happen on AC power), usually after
>> > resuming from RAM, after some rather random time (can be a few minutes
>> to
>> > hours) the system suddenly locks up, the screen freezes, keyboard and
>> the
>> > click-pad don't react, sound keeps playing a ~2 second loop. The
>> computer
>> > does not react to magic SysRq combos (probably because the keyboard
>> doesn't
>> > react), or to pressing the power key. I cannot ping it nor ssh into it.
>> The
>> > notebook appears to stay in this state indefinitely (the screen does not
>> > blank). Only a ~10-sec power-key hold or removing the battery does a
>> hard
>> > reset.
>> >
>> > I believe this is a kernel-level lock-up in some hardware driver.
>> > Unfortunately, I haven't been able to find out which one, because the
>> log
>> > files (tried both syslog and journald) contain nothing out of the
>> ordinary
>> > just before the lock-up. Probably the IO locks-up as well.
>> >
>> > Netconsole isn't really an easy option, because I cannot reliably
>> reproduce
>> > this in a suitable controlled environment, which is further complicated
>> by
>> > the lack of polling support (required for netconsole) on the wireless
>> > interface.
>> >
>> > My suspects:
>> > - The integrated Intel graphics card with the i915 driver: always had
>> > issues with it (on linux-3.16 it used to crash/hang a lot), maybe the
>> gpu
>> > hangs are not properly detected anymore.
>> > - The hard disk sometimes loses APM levels after suspend (have to use
>> > pm_async == 0 to prevent errors after each suspend). Maybe this points
>> to a
>> > larger suspend/power-mgmt issue.
>> > - My iwlwifi interface sometimes crashes and only removing it from the
>> PCI
>> > bus and rescanning for it helps. But this procedure does not hang the
>> whole
>> > system.
>> >
>> > Any help, suggestions, pointers will be appreciated.
>> >
>>
>> Hello,
>> I do have some power management issues with 4.9.0-5-amd64. My issues seem
>> different than yours ( I cannot boot up with power plugged in) but it is
>> also a hard stop, no logs available. I really haven't figured out the
>> exact
>> cause however in my case they seem related to the spectre/meltdown fix in
>> the newest kernel.
>> You can switch that off by adding pti=off to
>> GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and running update-grub.
>>
>> It is no ideal solution, but maybe it helps narrowing down the issue.
>>
>>
>> -H
>>
>>
>> --
>> Henning Follmann   | hfollm...@itcfollmann.com
>>
>>
>

Stretch: problème avec Ethernet Controller RTL8111

[bd]

Bonjour à tous,
Je viens d'installer Stretch sur mon nouveau desktop. A l'installation, 
impossible d'avoir une connexion filiaire Ethernet, j'ai dû me contenter 
d'une connexion WiFi. Une fois installé, toujours pas de connexion. Le 
contrôleur graphique me dit : "Réseau" "Filiaire" "câble débranché", ce 
qui n'est évidemment pas le cas.


lspci me dit : Ethernet controller RTL8111/8168/8411 PCI Express Gigabit 
Ethernet Controller... ... kernel driver in use : r8169. Kernel module 
r8169.


Cet Ethernet Controller est partie intégrante de ma **Carte mère 
Gigabyte H110M-S2H **


Parmi les messages dans /var/log/messages, j'ai récupéré notamment 
notamment ceux-ci :

...
- ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
.
r8169 :02:00.0 : can't disable ASPM ; OS doesn't have ASPM control
...
r8169  :02:00.0  eth0: RTL8168g/8111g at 
28169... enp2s0: renamed from eth0

enp2s0 link is not ready
Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)
link down

Merci d'avance pour votre assistance

Bernard

Re: Stretch net install on EeePC - unable to resolve mirror host address

[Reco]

Hi.

On Thu, Feb 22, 2018 at 10:11:24AM +0100, Roger Price wrote:
> On Tue, 20 Feb 2018, Reco wrote:
> > On Tue, Feb 20, 2018 at 12:23:06PM +0100, Roger Price wrote:
> > > Later the installation hangs with the message:
> > > 
> > >  in-target: Failed to fetch
> > >  
> > > http://debian.mirrors.ovh.net/debian/dists/stretch/main/i18n/Translation-en
> > >  Cannot initiate the connection to debian.mirrors.ovh.net:80
> > >  (2001:41d0:202:100:213:32:5:7). - connect (101: Network is unreachable)
> > >  [IP 2001:41d0:202:100:213:32:5:7 80]
> > > 
> > > There is no mention of IPv4 and I do not have IPv6.
> > 
> > Of course you have IPv6, probably in the form of SLAAC/RA. How else
> > Linux kernel used in the installer would know which IPv6 address to use
> > and which IPv6 route to choose to 2001:41d0:202:100:213:32:5:7.
> 
> I have a TP-Link TL-WR1043ND v3 router sold as IPv6 capable. I selected
> SLAAC and the following was reported in the system log:
> 
>  Feb 19 23:41:47  IPv6 NOTICE  getSlaacParameters 477 sscanf address and 
> prefix error
>  Feb 19 23:43:32  IPv6 INFOIPv6 is not enabled.

Curious, but wonders cannot happen by themself.


> IPv6 management in the router has hung and I cannot select an alternative to
> SLAAC.

Thank you, added that particular model to my 'Do Not Buy Ever' list.


> On the EeePC Ctl-Alt-F3 /dev/tty3:
>  ~ # ip address
>  3: enp0s4:  ...
>...
>inet 10.218.0.100 scope global enp0s4
>inet6 fe80::22cf:30ff:fe10:43fd/64 scope link
> 
> The "fe" at the beginning of the IPv6 address says that this is not capable
> of working with the public IPv6 network.

There's one crucial detail that's missing here. I agree that fe80
designates link-local IPv6 (they don't put "scope link" there for
nothing), but what about routing?
I.e. I'm curious about the output of "ip -6 ro l".

Reco

Re: Wheezy to Stretch

[Liam O'Toole]

On 2018-02-21, Jimmy Johnson  wrote:

[...]

> I know what I'm talking about ...

Dude, you're talking to a Debian developer.

OP, if you're reading this, I urge you to follow the advice of Roberto
and other wiser heads.

-- 

Liam

Re: Wheezy to Stretch

[Andy Smith]

Hello,

On Thu, Feb 22, 2018 at 08:17:43AM +0100, deloptes wrote:
> Jimmy Johnson wrote:
> > I never said that!  But I do know what I'm talking about because I do
> > what I'm talking about constantly.
> 
> you have said that, because in the official upgrade notes, as Roberto
> pointed out, it says you can go only one level up at a time.

I too have done quite a few in-place upgrades where I've skipped
releases.

In an ideal world I will be deploying a virtual machine straight out
of config management so it's quicker to just destroy it and deploy a
new one than it is to upgrade an existing one. But occasionally I
have to work on some VMs where they're neglected snowflakes and the
goal is to bring them up to the current stable release.

Since I can just snapshot them and revert to that in the event of
catastrophe I am sometimes willing to give skipping a release a try.
If it goes terribly wrong I can revert the snapshot and do it one
release at a time like you're supposed to.

Most of the time it's worked fine. I still wouldn't recommend anyone
else to try it though, because some of the time it has gone very
badly.

IIRC there were some releases where you just couldn't skip through
them due to kernel and udev changes. It might have been when trying
to go from etch to squeeze without visiting lenny first.

Then other times there were problems with specific packages. Since
it is explicitly not supported to do this, it's no surprise that
some packages break when you try it. I'm surprised it works as well
as it does as often as it does.

It doesn't really save all that much time. I mean, it's only going
to be a reboot or two extra per release.

Or course the worst case is that something goes wrong but it's not
immediately obvious so you call the job done and only discover the
issue after a long period of time, maybe then not even being able to
prove it was some issue caused by the way you chose to upgrade as
opposed to something else you did in the intervening time. I've
never had that happen to me, but it seems like a risk that has to be
considered. As I mostly only ever try this on virtual machines they
are already quite simple things dedicated to a single task, and I
think that helps in spotting aberrant behaviour.

So yeah it mostly works, but even speaking as someone who does it,
it's not something I'd recommend without fully appreciating the
dangers. I've had it break badly!

Cheers,
Andy

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

Re: Stretch net install on EeePC - unable to resolve mirror host address

[Roger Price]

On Tue, 20 Feb 2018, Reco wrote:

On Tue, Feb 20, 2018 at 12:23:06PM +0100, Roger Price wrote:

Later the installation hangs with the message:

 in-target: Failed to fetch
 http://debian.mirrors.ovh.net/debian/dists/stretch/main/i18n/Translation-en
 Cannot initiate the connection to debian.mirrors.ovh.net:80
 (2001:41d0:202:100:213:32:5:7). - connect (101: Network is unreachable)
 [IP 2001:41d0:202:100:213:32:5:7 80]

There is no mention of IPv4 and I do not have IPv6.


Of course you have IPv6, probably in the form of SLAAC/RA. How else
Linux kernel used in the installer would know which IPv6 address to use
and which IPv6 route to choose to 2001:41d0:202:100:213:32:5:7.


I have a TP-Link TL-WR1043ND v3 router sold as IPv6 capable. I selected SLAAC 
and the following was reported in the system log:


 Feb 19 23:41:47  IPv6 NOTICE  getSlaacParameters 477 sscanf address and prefix 
error
 Feb 19 23:43:32  IPv6 INFOIPv6 is not enabled.

IPv6 management in the router has hung and I cannot select an alternative to 
SLAAC.


On the EeePC Ctl-Alt-F3 /dev/tty3:
 ~ # ip address
 3: enp0s4:  ...
   ...
   inet 10.218.0.100 scope global enp0s4
   inet6 fe80::22cf:30ff:fe10:43fd/64 scope link

The "fe" at the beginning of the IPv6 address says that this is not capable of 
working with the public IPv6 network.


On Tue, 20 Feb 2018, Brian wrote:

On Tue 20 Feb 2018 at 13:39:25 +, Curt wrote:

On 2018-02-20, Reco  wrote:


https://www.debian.org/releases/stable/i386/ch05s03.html.en

So I guess the 'netcfg/disable_autoconfig=true' as boot parameter would
allow for manual configuration of the network within the installer, thus
obviating the IPv6 conundrum.


I do not understand the netcfg/disable... notation.  It is not described in the 
debconf man page, neither in Joey Hess' tutorial at 
http://www.fifi.org/doc/debconf-doc/tutorial.html . In any case, the graphical 
installer asks the question.



Yet what installer *does* have that's /proc.

So, wait for the network autoconfiguration, switch to root vt, invoke:

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6


This fixed my problem.  I tried again to install, and set disable_ipv6 to 1 
before starting the step "Install the base system".  The installation of 
stretch/Xfce i386 was successful!  After booting, I set 
GRUB_CMDLINE_LINUX="ipv6.disable=1 net.ifnames=0" in /etc/default/grub and ran 
update-grub. (Maybe the net.ifnames=0 is not essential.) I also installed 
rt2860.bin needed for the WiFi.  I recovered the /home partition from an earlier 
installation of openSUSE 12.2, re-booted and I now have my EeePC running with 
stretch.  Thanks to all who commented in this thread.


I will not mark the subject [SOLVED] since the underlying problem of why wget 
fails with 12 mirrors out of 13 is not solved.


Roger