Re: df -h shows insufficient precision

[Erik Christiansen]

On 26.08.18 12:25, Zenaan Harkness wrote:
> A regular itchy annoyance for years now:
> 
> df shows bytes, df -h shows only one decimal place, so e.g. on a
> 1.8TiB drive "1.6T" is the free space, but that resolution/ precision
> is insufficient.

For more than 3 decades I've just used "df -k". OK, even on smaller
disks than yours, that's a lot of digits, so a bit of mental juggling:

$ df -k
Filesystem1K-blocks Used Available Use% Mounted on
/dev/sda9 293477416 15376432 263193184   6% /home

Better is "df -m". On larger disks, you'll have more digits than here:

$ df -m
Filesystem1M-blocks Used Available Use% Mounted on
/dev/sda928660015017257025   6% /home

> Of course I can fire up bc, set scale=20 and do some
> powers of 1024 division, but that's all very clunky.
> 
> How hard would it be to add an option to bc, to choose the number of
> decimal places to use in the output, or the number of digits of
> precision to display?

Harder than putting the output of df -k through two lines of awk in a
shell function, I figure.

Erik

My wired connection doesn't work suddenly (Debian sid)

[Vinícius Couto]

Hi,

I use Debian sid and some weeks ago, a upgrade in some package caused a
strange thing.

I use my computer, when my wired connection down. Sometimes only the IPv4,
sometimes all the connections.
The symbol of the wired connection says that the connection is working.
When i disable to use a wireless connection in the same network, it works.


When i use dmesg | grep r8169
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 :02:00.0 eth0: RTL8168evl/8111evl at 0x(ptrval), ..., XID
... IRQ ..
r8169 :02:00.0 eth0: jumbo features [frames: 9200 bytes, tx
checksumming: ko]
r8169 :02:00.0 enp2s0: renamed from eth0
r8169 :02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw

dmesg | grep enp2s0
TCP: enp2s0: Driver has suspect GRO implementation, TCP performance may be
compromised.

What is happening to my computer?

Reggard,

Re: processing order for configuration files in /etc/network/interfaces.d

[Martin T]

On Thu, Aug 23, 2018 at 6:04 PM  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, Aug 23, 2018 at 05:31:57PM +0300, Martin T wrote:
> > Hi!
> >
> > According to "man interfaces", the ifup brings the named interfaces up
> > in the order listed in /etc/network/interfaces file. However, what is
> > the order for files in /etc/network/interfaces.d/? Alphabetical, i.e
> > same as "ls -l /etc/network/interfaces.d/"?
>
> I assume the files there are invoked by run-parts (man interfaces(5) at
> least hints at that). In that case yes, they are run in lexical order.
>
> But I'd double-check the run-parts part (heh). I've been caught spewing
> nonsense here ;-)
>
> Cheers
> - -- tomás
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlt+zN8ACgkQBcgs9XrR2kbV9wCeKwl3eILQA2d5rA6QgDKIIwQy
> 5scAn1NM68w35jLdQxrcD6F1dqCNpRpI
> =JRHj
> -END PGP SIGNATURE-
>

Tomas,

I added "pre-up echo $IFACE >> /tmp/interfaces_test" line to each
interface configuratio file in /etc/network/interfaces.d/ and looks
like the invoke order is not lexical. I have four files in
/etc/network/interfaces.d/:

# ls -l /etc/network/interfaces.d/
total 16
-rw-r--r-- 1 root root 338 Aug 26 14:10 br0
-rw-r--r-- 1 root root 555 Aug 26 14:10 eth0
-rw-r--r-- 1 root root  96 Aug 26 14:09 eth0.100
-rw-r--r-- 1 root root 109 Aug 26 14:09 lo
#

However, the content of the /tmp/interfaces_test is alwayse(I rebooted
the machine 5 times) following:

# cat /tmp/interfaces_test
br0
lo
eth0
eth0.100
#

I thought that ifup processes those files in order which they appear
in /etc/network/interfaces.d/*, but this does not seem to be true. Any
other ideas?


thanks,
Martin

Re: My wired connection doesn't work suddenly (Debian sid)

[Reco]

Hi.

On Sun, Aug 26, 2018 at 07:42:31AM -0300, Vinícius Couto wrote:
> Hi,
> 
> I use Debian sid and some weeks ago, a upgrade in some package caused a
> strange thing.
> 
> I use my computer, when my wired connection down. Sometimes only the IPv4,
> sometimes all the connections.

Yet another NetworkManager fault, most likely. The thing lives to its
reputation once more.


> The symbol of the wired connection says that the connection is working.
> When i disable to use a wireless connection in the same network, it works.

Of all the ways to test network connection you just used the least
informative one. Please share the output of "ip a l" and "ip ro l" next
time this happens.


> When i use dmesg | grep r8169
> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> r8169 :02:00.0 eth0: RTL8168evl/8111evl at 0x(ptrval), ..., XID
> ... IRQ ..
> r8169 :02:00.0 eth0: jumbo features [frames: 9200 bytes, tx
> checksumming: ko]

Pretty normal.

> r8169 :02:00.0 enp2s0: renamed from eth0

That's systemd thing.

> r8169 :02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw

And here you've used non-free blob, which is most likely completely
unnecessary. But it's unlikely that any of these are somehow related to
your problem.


> dmesg | grep enp2s0
> TCP: enp2s0: Driver has suspect GRO implementation, TCP performance may be
> compromised.

And that says that your NIC has problematic Generic Receive Offload
implementation, yet kernel enabled it.
Try "ethtool -K enp2s0 gro off" if it bothers you, but it'll unlikely
will have any visible effect.

> What is happening to my computer?

Network Manager. See above.

Reco

Re: My wired connection doesn't work suddenly (Debian sid)

[Gene Heskett]

On Sunday 26 August 2018 08:55:55 Reco wrote:

>   Hi.
>
> On Sun, Aug 26, 2018 at 07:42:31AM -0300, Vinícius Couto wrote:
> > Hi,
> >
> > I use Debian sid and some weeks ago, a upgrade in some package
> > caused a strange thing.
> >
> > I use my computer, when my wired connection down. Sometimes only the
> > IPv4, sometimes all the connections.
>
> Yet another NetworkManager fault, most likely. The thing lives to its
> reputation once more.
>
> > The symbol of the wired connection says that the connection is
> > working. When i disable to use a wireless connection in the same
> > network, it works.
>
> Of all the ways to test network connection you just used the least
> informative one. Please share the output of "ip a l" and "ip ro l"
> next time this happens.
>
Why do I have to read a mailing list to learn how to use these  new ip 
tools. Those two examples tell me more than than 20 readings of the man 
page, thank you Reco.

> > When i use dmesg | grep r8169
> > r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> > r8169 :02:00.0 eth0: RTL8168evl/8111evl at 0x(ptrval),
> > ..., XID ... IRQ ..
> > r8169 :02:00.0 eth0: jumbo features [frames: 9200 bytes, tx
> > checksumming: ko]
>
> Pretty normal.
>
> > r8169 :02:00.0 enp2s0: renamed from eth0
>
> That's systemd thing.
>
> > r8169 :02:00.0: firmware: direct-loading firmware
> > rtl_nic/rtl8168e-3.fw
>
> And here you've used non-free blob, which is most likely completely
> unnecessary. But it's unlikely that any of these are somehow related
> to your problem.
>
> > dmesg | grep enp2s0
> > TCP: enp2s0: Driver has suspect GRO implementation, TCP performance
> > may be compromised.
>
> And that says that your NIC has problematic Generic Receive Offload
> implementation, yet kernel enabled it.
> Try "ethtool -K enp2s0 gro off" if it bothers you, but it'll unlikely
> will have any visible effect.
>
> > What is happening to my computer?
>
> Network Manager. See above.
>
> Reco

Rant mode ON

What I have never understood about N-M is why it tears down a perfectly 
good, working connection, and spends 5 minutes trying to establish a new 
one, and failing, leaving the poor user no way to ask a mailing list for 
help. Thats unforgivable and unforgiven here. Theres some keywords 
(mentioned in the man page in obtuse language IIRC) to use in e-n-i to 
tell N_M to keep its malicious hands off a given interface, but you have 
to read between the lines with your logical superpowers to detect them. 
There now, but for the longest time removing its starter script via 
chkconfig or removing N-M with the package manager, not possible a 
decade ago without its dependencies tearing down the system so I used mc 
for that, nuking the binaries. So its getting better, but as can be seen 
above its not perfect yet for folks needing portability. And I've used 
WICD for that in past years when I needed my old lappy to give me email 
and browsing from a motel room 950 miles from home while I was out 
playing visiting tv engineer. But my old lappy has a busted bcm4318 
based radio that not even the windows xp drivers could make work, so I'm 
glad the motel had radios I could plug into its net port.

Thanks for reading this far.

/Rant mode OFF

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

iproute, NM, customary Sunday rant (was: Re: My wired

[Reco]

connection doesn't work suddenly (Debian sid))
Reply-To: 
In-Reply-To: <201808260940.37925.ghesk...@shentel.net>

On Sun, Aug 26, 2018 at 09:40:37AM -0400, Gene Heskett wrote:
> On Sunday 26 August 2018 08:55:55 Reco wrote:
> > > The symbol of the wired connection says that the connection is
> > > working. When i disable to use a wireless connection in the same
> > > network, it works.
> >
> > Of all the ways to test network connection you just used the least
> > informative one. Please share the output of "ip a l" and "ip ro l"
> > next time this happens.
> >
> Why do I have to read a mailing list to learn how to use these  new ip 
> tools. Those two examples tell me more than than 20 readings of the man 
> page, thank you Reco.

You're welcome. It's how I learn stuff - commit into memory two or three
'use in all cases' invocations of the tool, and slowly learn the rest.
One can easily tell a good manpage from a bad one - a good manpage have
those two or three invocations in EXAMPLES section. A bad manpage lacks
EXAMPLES. An abysmal manpage tells you the name of the tool, and that's
it (most of the binaries shipped with GNOME belong in this category).

iproute2 is an excellent, versatile tool. Sadly whoever wrote the tool
hated to write documentation, hence the manpages of questionable
quality.


> > Network Manager. See above.
> 
> Rant mode ON
> 
> What I have never understood about N-M is why it tears down a perfectly 
> good, working connection, and spends 5 minutes trying to establish a new 
> one, and failing, leaving the poor user no way to ask a mailing list for 
> help. Thats unforgivable and unforgiven here.

They called the thing NetworkMangler for a reason. It's also known as
NotworkManager, and there's a reason for this too.


> Theres some keywords 
> (mentioned in the man page in obtuse language IIRC) to use in e-n-i to 
> tell N_M to keep its malicious hands off a given interface, but you have 
> to read between the lines with your logical superpowers to detect them. 

It's easily explained. NM is a RedHat project. More users = more
testing. The best testing is provided by paying customers, so modern
RHEL is unthinkable without NM (yes, it's possible to disable the thing,
and yes, they won't tell you how).

Debian project strived all these years to deviate from upstream as
little as possible, so in this case NM is forced down the throat to any
DE user RedHat style.
Luckily here, in Debian, we have sid, and what's more important - those
poor souls that are willing to use sid on everyday's basis. That
includes OP, and that's commendable to say the least - unearthing nasty
bugs so us, stable users, won't have to.


> There now, but for the longest time removing its starter script via 
> chkconfig or removing N-M with the package manager, not possible a 
> decade ago without its dependencies tearing down the system so I used mc 
> for that, nuking the binaries.

While I prefer "don't install what you don't need approach", I fail to
see why a simple "apt-get purge network-manager" did not to work for
you.

Reco

iproute, NM and ifupdown (was: My wired connection doesn't work suddenly (Debian sid))

[Pascal Hambourg]

Le 26/08/2018 à 15:40, Gene Heskett a écrit :



Why do I have to read a mailing list to learn how to use these  new ip
tools.


"New" ? iproute has been around for more that 20 years !


Theres some keywords
(mentioned in the man page in obtuse language IIRC) to use in e-n-i to
tell N_M to keep its malicious hands off a given interface, but you have
to read between the lines with your logical superpowers to detect them.


No, there is no obscure keyword and nothing between the lines.
By default, NM does not manage any interface configured in 
/etc/network/interfaces. So all you have to do is configure your 
interface with an "iface" stanza in /etc/network/interfaces as usual so 
that it is managed by ifupdown and not by NM.

Re: iproute, NM, customary Sunday rant (was: Re: My wired

[Gene Heskett]

On Sunday 26 August 2018 10:04:38 Reco wrote:

> connection doesn't work suddenly (Debian sid))
> Reply-To:
> In-Reply-To: <201808260940.37925.ghesk...@shentel.net>
>
> On Sun, Aug 26, 2018 at 09:40:37AM -0400, Gene Heskett wrote:
> > On Sunday 26 August 2018 08:55:55 Reco wrote:
> > > > The symbol of the wired connection says that the connection is
> > > > working. When i disable to use a wireless connection in the same
> > > > network, it works.
> > >
> > > Of all the ways to test network connection you just used the least
> > > informative one. Please share the output of "ip a l" and "ip ro l"
> > > next time this happens.
> >
> > Why do I have to read a mailing list to learn how to use these  new
> > ip tools. Those two examples tell me more than than 20 readings of
> > the man page, thank you Reco.
>
> You're welcome. It's how I learn stuff - commit into memory two or
> three 'use in all cases' invocations of the tool, and slowly learn the
> rest. One can easily tell a good manpage from a bad one - a good
> manpage have those two or three invocations in EXAMPLES section. A bad
> manpage lacks EXAMPLES. An abysmal manpage tells you the name of the
> tool, and that's it (most of the binaries shipped with GNOME belong in
> this category).
>
> iproute2 is an excellent, versatile tool. Sadly whoever wrote the tool
> hated to write documentation, hence the manpages of questionable
> quality.
>
> > > Network Manager. See above.
> >
> > Rant mode ON
> >
> > What I have never understood about N-M is why it tears down a
> > perfectly good, working connection, and spends 5 minutes trying to
> > establish a new one, and failing, leaving the poor user no way to
> > ask a mailing list for help. Thats unforgivable and unforgiven here.
>
> They called the thing NetworkMangler for a reason. It's also known as
> NotworkManager, and there's a reason for this too.
>
> > Theres some keywords
> > (mentioned in the man page in obtuse language IIRC) to use in e-n-i
> > to tell N_M to keep its malicious hands off a given interface, but
> > you have to read between the lines with your logical superpowers to
> > detect them.
>
> It's easily explained. NM is a RedHat project. More users = more
> testing. The best testing is provided by paying customers, so modern
> RHEL is unthinkable without NM (yes, it's possible to disable the
> thing, and yes, they won't tell you how).

Figures. I got tired of being one of RedHats lab rats, so I bailed on 
fedora at about F3. Mandrake had lots less near fatal diseases, but LCNC 
moved to ununtu, and since wheezy, to debian.

> Debian project strived all these years to deviate from upstream as
> little as possible, so in this case NM is forced down the throat to
> any DE user RedHat style.
> Luckily here, in Debian, we have sid, and what's more important -
> those poor souls that are willing to use sid on everyday's basis. That
> includes OP, and that's commendable to say the least - unearthing
> nasty bugs so us, stable users, won't have to.
>
> > There now, but for the longest time removing its starter script via
> > chkconfig or removing N-M with the package manager, not possible a
> > decade ago without its dependencies tearing down the system so I
> > used mc for that, nuking the binaries.
>
> While I prefer "don't install what you don't need approach", I fail to
> see why a simple "apt-get purge network-manager" did not to work for
> you.
>
That was a *buntu thing, started about 06:4 lts, which is what linuxcnc 
ran on a decade and change back. Eventually the guys in charge got tired 
of the churn from lts to lts, and moved to debian stable right after 
wheezy came out. They made lcnc run on the pi with jessie and have an 
experimental amd64 image spun for stretch which I am about to try, me 
being the designated canary in the coal mine I guess. But its hidden as 
they will want to have some shakedown users reports in before they 
respin an official release for folks who are making a living with it.

I'm waiting on a 4 drive qc cage from Newegg. My 3 drive cage now needs 3 
or 4 layers of scotch tape added to the back of the sda door to reliably 
connect a new 2T drive. Installing the 4 drive cage will require a bit 
of steel surgery on this tower, but will be worth it just from the 
improved drive cooling.  So I'm still on sdb, the wheezy install until 
that new cage is installed. sdd, my amandatapes drive, is currently in 
an oem shelf out of sight under the floppy slot, and running at 40C, too 
warm for spinning rust IMO. sdc is the old 1T drive amanda has been 
using since forever but I just 2 days ago gave it a 2T as the 1T was 
approaching, and occasionally exceeding 90% use. Although I've 
considered mounting it as /home and may at some point in the future, its 
had an immortal pill for years and years now. Spin hours will be past 
75,000 within the month.

Thanks Reco

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and am

Re: processing order for configuration files in /etc/network/interfaces.d

[David Wright]

On Sun 26 Aug 2018 at 15:41:05 (+0300), Martin T wrote:
> On Thu, Aug 23, 2018 at 6:04 PM  wrote:
> > On Thu, Aug 23, 2018 at 05:31:57PM +0300, Martin T wrote:
> > > According to "man interfaces", the ifup brings the named interfaces up
> > > in the order listed in /etc/network/interfaces file. However, what is
> > > the order for files in /etc/network/interfaces.d/? Alphabetical, i.e
> > > same as "ls -l /etc/network/interfaces.d/"?
> >
> > I assume the files there are invoked by run-parts (man interfaces(5) at
> > least hints at that). In that case yes, they are run in lexical order.
> >
> > But I'd double-check the run-parts part (heh). I've been caught spewing
> > nonsense here ;-)
> I added "pre-up echo $IFACE >> /tmp/interfaces_test" line to each
> interface configuratio file in /etc/network/interfaces.d/ and looks
> like the invoke order is not lexical. I have four files in
> /etc/network/interfaces.d/:
> 
> # ls -l /etc/network/interfaces.d/
> total 16
> -rw-r--r-- 1 root root 338 Aug 26 14:10 br0
> -rw-r--r-- 1 root root 555 Aug 26 14:10 eth0
> -rw-r--r-- 1 root root  96 Aug 26 14:09 eth0.100
> -rw-r--r-- 1 root root 109 Aug 26 14:09 lo
> #
> 
> However, the content of the /tmp/interfaces_test is alwayse(I rebooted
> the machine 5 times) following:
> 
> # cat /tmp/interfaces_test
> br0
> lo
> eth0
> eth0.100
> #
> 
> I thought that ifup processes those files in order which they appear
> in /etc/network/interfaces.d/*, but this does not seem to be true. Any
> other ideas?

You need to post your evidence, starting with your /etc/network/interfaces
file. You say you're using ifup, so we can perhaps discount this paragraph:

   Currently, "source-directory" isn't supported by
   network-manager and guessnet.

but we don't know whether you're using "source-directory" or "source",
for example. The former might not be expected to run eth0.100 at all.
There's conflicting evidence on the web about such matters.

If you care about the order in which these files are sourced,
for the time being I would source them individually in the order you
want. I'm not sure where the lexical sorting is documented, but man
interfaces(5) does not yield much when searched for "lex", "sort"
and "order".

I'd be interested to find the script(s) that the system is using to
select configuration files for execution, and to see if it agrees
with the documentation (which is a bit lax here).

Cheers,
David.

pactl and bluetooth

[Mark Fletcher]

Hello the list

I'm running stretch amd64, upgraded from at least jessie and I think 
wheezy -- memory's a bit hazy now. I use Gnome on this machine.

Every time I reboot I find I can't connect my bluetooth headphones to 
the computer. In the Gnome bluetooth applet, when I click the slide 
button to connect, it immediately slides from ON to OFF without seeming 
to do anything.

A while back the archives of this list helped me discover that in order 
to fix this I need to run as root:

pactl load-module module-bluetooth-discover

Doing this immediately makes it possible to connect the headphones.

Can anyone point me at documentation of how I could arrange things so 
this happens automatically and I don't have to type it by hand? I know 
there's a way but I am struggling to find, or remember, how.

Thanks

Mark

Re: iproute, NM and ifupdown (was: My wired connection doesn't work suddenly (Debian sid))

[Gene Heskett]

On Sunday 26 August 2018 10:24:35 Pascal Hambourg wrote:

> Le 26/08/2018 à 15:40, Gene Heskett a écrit :
> > Why do I have to read a mailing list to learn how to use these  new
> > ip tools.
>
> "New" ? iproute has been around for more that 20 years !
>
> > Theres some keywords
> > (mentioned in the man page in obtuse language IIRC) to use in e-n-i
> > to tell N_M to keep its malicious hands off a given interface, but
> > you have to read between the lines with your logical superpowers to
> > detect them.
>
> No, there is no obscure keyword and nothing between the lines.

Oh? And you wrote that manpage I suppose, and you don't make mistakes...

You may be able to read it, knowing what you "intended" to write. But 
others aren't mind readers.

But we can add 2+2 and get a quite precisely defined 4.00.

> By default, NM does not manage any interface configured in
> /etc/network/interfaces. So all you have to do is configure your
> interface with an "iface" stanza in /etc/network/interfaces as usual
> so that it is managed by ifupdown and not by NM.

I have had N-M tear down a well configured staticly defined eth0 on 
dozens of occasions, despite using the iface designation in my e-n-i's. 
Most recently on a stretch install on a rock64 I had to erect immutable 
attributes to resolv.conf after making it a real file, and e-n-i to make 
networking Just Work.

It may not do it today, things do get improved but my linux experience 
dates to RH5.0 and 1998 and its been something I've had to edit e-n-i 
and then quickly make it immutable, ditto for making /etc/resolv.conf a 
real file and immutable ever since N-M was made virtually mandatory. My 
networking is not portable and with the exception of my ancient lappy 
will never be.

Theres a reason my /etc/hosts files are 20+ lines long, and my 
resolv.conf has a "search hosts nameserver" line in it, which N-M always 
removes if it can. The real file, made immutable fixes that too

N-M is helpless when there is not a dhcp server or a dhcp server that 
only recognizes the MAC of one machine for security reasons.

Based on my experience at making N-M work, you might want to get a 
shorter horse.

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

problem with amd64 architecture

[Pierre Frenkiel]

hi,
 get a amd64 deb package (franz, to name it), and converted it to i386,
 using the recommended sequence:

   dpkg-deb -x ../paquet_amd64.deb .
   dpkg -e ../paquet_amd64.deb
   in DEBIAN/control, replaced amd64 by i386
   dpkg-deb -b . ../paquet_i386.deb

but after installing the resulting .deb. I still get a amd64 binary.
What did I miss?
Is there a way to convert the binary itself to i386?

best regards,
--
Pierre Frenkiel

Re: problem with amd64 architecture

[Reco]

Hi.

On Sun, Aug 26, 2018 at 06:24:59PM +0200, Pierre Frenkiel wrote:
> hi,
>  get a amd64 deb package (franz, to name it), and converted it to i386,
>  using the recommended sequence:
> 
>dpkg-deb -x ../paquet_amd64.deb .
>dpkg -e ../paquet_amd64.deb
>in DEBIAN/control, replaced amd64 by i386
>dpkg-deb -b . ../paquet_i386.deb

So you haven't touch the contents of package itself.


> but after installing the resulting .deb. I still get a amd64 binary.
> What did I miss?

See above. No magic here, files provided by package stayed the same.


> Is there a way to convert the binary itself to i386?

If the binary was produced by compiling conventional ASM/C/C++ source -
no. Rebuild from the source is required.

Reco

Re: df -h shows insufficient precision

[Ionel Mugurel Ciobîcă]

On 26-08-2018, at 01h 08'57", Roberto C. Sánchez wrote about "Re: df -h shows 
insufficient precision"
> > > Have you looked at the -k and -B options?  Also, di has the -d option
> > 
> > I assume you mean "du"?
> > 
> No.  I actually meant 'di':
> 

That is useful! I already made an alias df to point at "di -m -x tmpfs -s s".

Thank you.

 Ionel

Re: "accept_ra 1" vs "accept_ra 2" in interfaces configuration-file

[Martin T]

On Wed, Aug 22, 2018 at 2:02 AM Andy Smith  wrote:
>
> Hi Martin,
>
> On Wed, Aug 22, 2018 at 01:06:32AM +0300, Martin T wrote:
> > In addition, "accept_ra" with a value of 2 should ensure that RA
> > messages are accepted even if forwarding for that interface is
> > enabled, shouldn't it?
>
> Yes, it should.
>
> That's the way it's documented and our use case is what it's meant
> to serve, so if it's not behaving that way for you then I think it
> is a bug and should be reported upstream in the kernel bugzilla.
>
> Cheers,
> Andy
>

Hi Andy,

I did some additional tests and made following observations:

1) For IPv6 one can't enable/disable routing for specific
interface(s). It is either off(/proc/sys/net/ipv6/conf/all/forwarding
is 0) or on(/proc/sys/net/ipv6/conf/all/forwarding is 1).
2) /proc/sys/net/ipv6/conf//forwarding controls simply
if interface sends out RS messages and accepts RA messages

Also, I found a post from David Miller in 2001(!) where he told pretty
much the same: https://bugzilla.redhat.com/show_bug.cgi?id=38533

This means that I set the accept_ra in interfaces file to 1 for
eth0(ISP-facing interface) and added those two lines to sysctl.conf:

net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eth0.forwarding=0


Martin

Re: iproute, NM and ifupdown

[Pascal Hambourg]

Le 26/08/2018 à 17:24, Gene Heskett a écrit :

On Sunday 26 August 2018 10:24:35 Pascal Hambourg wrote:


Le 26/08/2018 à 15:40, Gene Heskett a écrit :


Theres some keywords
(mentioned in the man page in obtuse language IIRC) to use in e-n-i
to tell N_M to keep its malicious hands off a given interface, but
you have to read between the lines with your logical superpowers to
detect them.


No, there is no obscure keyword and nothing between the lines.


Oh? And you wrote that manpage I suppose, and you don't make mistakes...


Irrelevant.


You may be able to read it, knowing what you "intended" to write. But
others aren't mind readers.


Maybe I was not clear enough. Let me rephrase a bit.

Contrary to what you wrote, there is no obscure keyword to use in 
/etc/network/interfaces to tell NetworkManager to keep its hands off a 
given interface.



By default, NM does not manage any interface configured in
/etc/network/interfaces. So all you have to do is configure your
interface with an "iface" stanza in /etc/network/interfaces as usual
so that it is managed by ifupdown and not by NM.


I have had N-M tear down a well configured staticly defined eth0 on
dozens of occasions, despite using the iface designation in my e-n-i's.
Then it is a bug which should be reported and fixed. It is not intended 
behaviour.



Most recently on a stretch install on a rock64 I had to erect immutable
attributes to resolv.conf after making it a real file, and e-n-i to make
networking Just Work.


/etc/resolv.conf is a rather different topic, because it is not related 
to a specific interface and may be written by several pieces of 
software, including but not limited to NetworkManager when configuring 
*any* interface. I would suggest using resolvconf but I suspect you 
would not like it either.

Re: iproute, NM and ifupdown

[Gene Heskett]

On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:

> Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> > On Sunday 26 August 2018 10:24:35 Pascal Hambourg wrote:
> >> Le 26/08/2018 à 15:40, Gene Heskett a écrit :
> >>> Theres some keywords
> >>> (mentioned in the man page in obtuse language IIRC) to use in
> >>> e-n-i to tell N_M to keep its malicious hands off a given
> >>> interface, but you have to read between the lines with your
> >>> logical superpowers to detect them.
> >>
> >> No, there is no obscure keyword and nothing between the lines.
> >
> > Oh? And you wrote that manpage I suppose, and you don't make
> > mistakes...
>
> Irrelevant.

If you didn't write it, I apologize for venting at the wrong person.
>
> > You may be able to read it, knowing what you "intended" to write.
> > But others aren't mind readers.
>
> Maybe I was not clear enough. Let me rephrase a bit.
>
> Contrary to what you wrote, there is no obscure keyword to use in
> /etc/network/interfaces to tell NetworkManager to keep its hands off a
> given interface.
>
> >> By default, NM does not manage any interface configured in
> >> /etc/network/interfaces. So all you have to do is configure your
> >> interface with an "iface" stanza in /etc/network/interfaces as
> >> usual so that it is managed by ifupdown and not by NM.
> >
> > I have had N-M tear down a well configured staticly defined eth0 on
> > dozens of occasions, despite using the iface designation in my
> > e-n-i's.
>
> Then it is a bug which should be reported and fixed. It is not
> intended behaviour.
>
Any fusses I have posted to bugzilla have all been "won't fix" in just a 
few minutes. You'd think its tailor was Dupont. Teflon suits IOW.
> > Most recently on a stretch install on a rock64 I had to erect
> > immutable attributes to resolv.conf after making it a real file, and
> > e-n-i to make networking Just Work.
>
> /etc/resolv.conf is a rather different topic, because it is not
> related to a specific interface and may be written by several pieces
> of software, including but not limited to NetworkManager when
> configuring *any* interface. I would suggest using resolvconf but I
> suspect you would not like it either.
Ohkaay, but where's the docs on this mysterious resolvconf?

What we do have is missing (wheezy) or horribly incomplete (jessie). 

But I'll have to take that back, my apologies. I just read the stretch 
version on that rock64.  And as man pages go, its decent. And I'll have 
to do some experimenting as its possible I can train it to behave.

And curious I blink compared the jessie vs stretch versions, stretch's is 
both longer AND more complete, and two different authors and formatted 
completely different. And wheezy doesn't even have the man page. I don't 
even know if it should, maybe not for wheezy, lots of water has been 
recycled since those installs were made, so I'll plead oldtimers.

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

Re: processing order for configuration files in /etc/network/interfaces.d

[Martin T]

Hi David,

> You need to post your evidence, starting with your /etc/network/interfaces
> file. You say you're using ifup, so we can perhaps discount this paragraph:
>
>Currently, "source-directory" isn't supported by
>network-manager and guessnet.
>
> but we don't know whether you're using "source-directory" or "source",
> for example.

I'm using "source":

# cat /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/*
#

> If you care about the order in which these files are sourced,
> for the time being I would source them individually in the order you
> want.

Yes, this is probably a good idea. However, ideally, "man interfaces"
should state in which order files in /etc/network/interfaces.d/ are
processed.


Martin

linux 4.19 scsi-mq default?

[Boyan Penkov]

Hello folks,

Likely not the exact right list to ask, but likely someone here knows — did 
scsi-mq by default make it into linux 4.19?

http://lkml.iu.edu/hypermail/linux/kernel/1807.0/02224.html 


Cheers!
--
Boyan Penkov
www.boyanpenkov.com

Buster: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20180313/dspkginit-414)

[local10]

Hi,

Am getting the following errors on boot and, probably due to the errors, KDE 
cannot start (kde-plasma-desktop package was installed). The snapshot was from 
August 20, 2018 was used for buster installation.

Any ideas? Thanks


Aug 26 21:31:55 tstsrv kernel: [    0.032672] ACPI: Added _OSI(Module Device)
Aug 26 21:31:55 tstsrv kernel: [    0.032672] ACPI: Added _OSI(Processor Device)
Aug 26 21:31:55 tstsrv kernel: [    0.032672] ACPI: Added _OSI(3.0 _SCP 
Extensions)
Aug 26 21:31:55 tstsrv kernel: [    0.032672] ACPI: Added _OSI(Processor 
Aggregator Device)
Aug 26 21:31:55 tstsrv kernel: [    0.032672] ACPI: Added _OSI(Linux-Dell-Video)
Aug 26 21:31:55 tstsrv kernel: [    0.037417] ACPI: 2 ACPI AML tables 
successfully acquired and loaded
Aug 26 21:31:55 tstsrv kernel: [    0.037567] ACPI Error: AE_NOT_FOUND, While 
resolving a named reference package element - LNKC (20180313/dspkginit-414)
Aug 26 21:31:55 tstsrv kernel: [    0.037603] ACPI Error: AE_NOT_FOUND, While 
resolving a named reference package element - LNKD (20180313/dspkginit-414)
Aug 26 21:31:55 tstsrv kernel: [    0.037636] ACPI Error: AE_NOT_FOUND, While 
resolving a named reference package element - LNKA (20180313/dspkginit-414)
Aug 26 21:31:55 tstsrv kernel: [    0.037668] ACPI Error: AE_NOT_FOUND, While 
resolving a named reference package element - LNKB (20180313/dspkginit-414)
Aug 26 21:31:55 tstsrv kernel: [    0.037704] ACPI Error: AE_NOT_FOUND, While 
resolving a named reference package element - LNKD (20180313/dspkginit-414)
Aug 26 21:31:55 tstsrv kernel: [    0.037735] ACPI Error: AE_NOT_FOUND, While 
resolving a named reference package element - LNKA (20180313/dspkginit-414)
...
...
Aug 26 21:31:55 tstsrv kernel: [    0.038889] ACPI Error: AE_NOT_FOUND, While 
resolving a named reference package element - LNKC (20180313/dspkginit-414)
Aug 26 21:31:55 tstsrv kernel: [    0.038923] ACPI Error: AE_NOT_FOUND, While 
resolving a named reference package element - LNKD (20180313/dspkginit-414)
Aug 26 21:31:55 tstsrv kernel: [    0.040638] ACPI: Interpreter enabled
Aug 26 21:31:55 tstsrv kernel: [    0.040655] ACPI: (supports S0 S3 S4 S5)
Aug 26 21:31:55 tstsrv kernel: [    0.040656] ACPI: Using IOAPIC for interrupt 
routing
Aug 26 21:31:55 tstsrv kernel: [    0.040711] PCI: Using host bridge windows 
from ACPI; if necessary, use "pci=nocrs" and report a bug
Aug 26 21:31:55 tstsrv kernel: [    0.040824] ACPI: Enabled 5 GPEs in block 00 
to 1F
Aug 26 21:31:55 tstsrv kernel: [    0.045473] ACPI: PCI Root Bridge [PCI0] 
(domain  [bus 00-ff])
Aug 26 21:31:55 tstsrv kernel: [    0.045478] acpi PNP0A03:00: _OSC: OS 
supports [ExtendedConfig ASPM ClockPM Segments MSI]
Aug 26 21:31:55 tstsrv kernel: [    0.045482] acpi PNP0A03:00: _OSC failed 
(AE_NOT_FOUND); disabling ASPM
Aug 26 21:31:55 tstsrv kernel: [    0.045701] PCI host bridge to bus :00

Re: processing order for configuration files in /etc/network/interfaces.d

[Zenaan Harkness]

On Sun, Aug 26, 2018 at 09:36:30PM +0300, Martin T wrote:
> Hi David,
> 
> > You need to post your evidence, starting with your /etc/network/interfaces
> > file. You say you're using ifup, so we can perhaps discount this paragraph:
> >
> >Currently, "source-directory" isn't supported by
> >network-manager and guessnet.
> >
> > but we don't know whether you're using "source-directory" or "source",
> > for example.
> 
> I'm using "source":
> 
> # cat /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/*
> #
> 
> > If you care about the order in which these files are sourced,
> > for the time being I would source them individually in the order you
> > want.
> 
> Yes, this is probably a good idea. However, ideally, "man interfaces"
> should state in which order files in /etc/network/interfaces.d/ are
> processed.

It should indeed, and it should also be in lexical order according to
"C" utf-8 "locale", in a manner similar to "run-parts".

Perhaps you could raise a bug for this - it certainly feels
appropriate to do so.

Re: Buster: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20180313/dspkginit-414)

[Brad Rogers]

On Mon, 27 Aug 2018 03:49:14 +0200 (CEST)
local10  wrote:

Hello local10,

>Am getting the following errors on boot and, probably due to the
>errors, KDE cannot start (kde-plasma-desktop package was installed).

The two things are unrelated.  The error on boot is "annoying but
harmless", according what I've read, after a *very* cursory search
(translation: you could have done this yourself).

The failure to start SDDM/KDE is probably due to entropy issues, and has
been discussed on this list recently.
Options are:
Wait until SDDM starts (can be up to three minutes)
Mash on keyboard until SDDM starts (takes a few seconds)
Install 'haveged' to increase entropy during boot process

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Why do they try to hide our past pulling down houses and build car parks
Bricks & Mortar - The Jam


pgpZmeu4ToSlU.pgp
Description: OpenPGP digital signature