Re: [gentoo-user] Root device as UUID not properly detected

[João Miguel]

On Wed, Oct 07, 2015 at 12:17:51PM +0200, J. Roeleveld wrote:
> > > > > 2. USB port is not supported by kernel
> > > > I'm not sure what you mean. Is there any option I should enable for
> > > > genkernel? I read on the Wiki page that
> > > It works with Arch, are you using the same kernel options now with Gentoo?
> > Yeah, I tried many more here actually, with Arch I only need APPEND root=...
> > (no rootfstype, ro, rw, rootdelay, etc.).
> What about kernel config?
I was not sure about this, but
https://wiki.archlinux.org/index.php/Kernel_parameters says:

   There are three ways to pass options to the kernel and thus control its
behaviour:
   1. When building the kernel. See Kernel Compilation for details.
   2. When starting the kernel (usually, when invoked from a boot loader).
   3. At runtime (through the files in /proc and /sys). See sysctl for details.

So I'm using 2.

> > > > > 3. You don't use root_delay as boot option
> > > > If that's what I think it is, I tell syslinux to wait 5 seconds.
> > (turns out it's not what I thought it was, though I did try root_delay, it
> > is actually rootdelay...)
> > > How do you tell it that?
> > Here's my syslinux.cfg with more comments:
> > PROMPT 1
> > TIMEOUT 50  # <-- here
> That timeout is for the prompt, eg. how long the bootloader waits.
Yes, but I do tell it to wait (and as I said, I didn't know what rootdelay
was).
> It will not have any effect for the drivers in the kernel to finish detecting 
> the USB devices.
> > APPEND rootdelay=5 root=UUID="6fc386ff-8342-42a2-be02-51a6eccf8430" 
> > rootfstype=ext4
No, but this --^^^-- should.

> Did you test with the PARTUUID value ("9c...") instead of the other one?
> 
> Also, I always ended up setting the rootdelay to 10 or higher. (It's in 
> seconds, not minutes)
New append line:
APPEND rootdelay=15 root=PARTUUID="9c4f6479-9dd7-4a8f-86f2-f1320cc15aa5" 
rootfstype=ext4

Again, I see no difference using rootdelay. With PARTUUID though, I get "Could
not find the root device in ." right away, rather than "Could not find the root
device in UUID=...". With PARTUUID, I can't boot it anywhere without manually
writing the UUID (not PARTUUID) or device file. Though on my system, the
following works:

 # mount PARTUUID="9c4f6479-9dd7-4a8f-86f2-f1320cc15aa5" /mnt/pen

So now I'm even more confused. Everything about this pen works, as does
everything in the PCs I tried. Syslinux also works. It's somewhere after
loading the modules, in the initrd.

Thinking of it now, I remember the PC that never finds the root device
requires intel microcode early, which is loaded along with the initrd.

Because of this problem I need to turn many PCs on and off a few times
in a row, and I noticed that the pendrive blinks at least on BIOS, when
syslinux is finding initrd and the kernel, and when the machine finds
the root device. Now, what I noticed is that in the VM, it blinks right
away (as it finds root right away); in many PCs it takes a while to
blink, only blinking after the 1st attempt on mounting to newroot has
been done; and in some others it never blinks.

> > > I never used an initrd when building my own USB sticks.
> > I don't know, I always used an initrd. Though I must say, that is the
> > phase of starting the PC I understand the worst.
> On the machines where I use an initrd, I write my own scripts as I find the 
> creators (genkernel, dracut) to not be intelligent enough.
The thing is, I'm less intelligent than those creators. I'm not very
familiar with the way that early boot phase works, much less with
writing scripts to make it work.  Unless you have an idea of how I can
use the scripts to solve this problem. In Arch I use mkinitcpio. I'm
aware it is available for Gentoo as well, nonetheless using genkernel is
killing two birds with one stone, it should be a simpler solution, so
I'd like to go with that one. If it works for a Gentoo recovery drive,
why shouldn't it work for this one?

> > > I was talking about:
> > > rootdelay=  [KNL] Delay (in seconds) to pause before
> > > attempting to
> > > mount the root filesystem
> > > (See the file "kernel-parameters.txt" in the kernel Documentation)
> > (I'm guessing I'm not supposed to include this in the boot loader config...)
> The "rootdelay=..."  part needs to be added to the boot loader config.
Ah, then I'm glad I did. Although it seems to do nothing really...

Sorry for the large response. I probably forgot something, took a while
amidst writing and testing.
João Miguel

Re: [gentoo-user] strange TCP timeout errors

[Alan McKinnon]

On 07/10/2015 21:42, brettrse...@gmail.com wrote:
> YyyyYYuIU
> Sent from my Verizon Wireless BlackBerry


Hmm, interesting reply. I'm wondering if it has something to
do with:

1. verizon
2. dodgy 3g
3. crapberry. oops, sorry: blackberry

Or maybe it's because y, u and i are in a row on the keyboard, shift and
enter are adjacent, and you have a over-friendly cat?

:-)

> 
> -Original Message-
> From: Alan McKinnon 
> Date: Wed, 7 Oct 2015 20:39:42 
> To: 
> Reply-to: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] strange TCP timeout errors
> 
> On 07/10/2015 17:55, Grant wrote:
>>> I've attached a PNG from Munin showing the TCP timeout errors on my
>>> Gentoo server over the past month.  The data is expressed in timeouts
>>> per second and that rate is shown to be steadily increasing over the
>>> past month.  That seems strange to me.  Munin doesn't show any other
>>> data point increasing like this over the time period.  Any ideas?
>>>
>>> - Grant
>>>
>>
>> weird - does it reset on an interface restart or reboot?
>
> this would be my test #1


 I rebooted and the rate of errors has dropped off to almost nothing.


>> Can you verify its not an artefact within munin (how?)
>
> In theory, a misconfigured graph can do this. Munin can draw many
> different types of graph, including cumulative values. Even for a data
> type like this which is X events per unit time, if you tell munin to add
> them all up, it will do so and graph it.
>
> Qucik test is to look at the graph config.


 This graph lives in the "network" section of the munin web interface.
 There is no matching section in /etc/munin/plugin-conf.d/munin-node so
 it should be be using the default config.

 Any ideas based on this new info?
>>>
>>> A few :-)
>>>
>>>
>>> I can't find the plugin that delivers that graph though. Maybe I just
>>> don't have it, maybe it comes from contrib/
>>>
>>> What's your USE for munin?
>>
>>
>> USE="apache cgi http mysql ssl syslog -asterisk -dhcpd -doc -ipmi
>> -ipv6 -irc -java -memcached -minimal -postgres (-selinux) {-test}"
>>
>>
>>> What do you have in "ls -al /etc/munin/plugins/"  ?
> 
> 
> It's as I thought - your data is accurate but rrd has been given a
> completely wrong method to derive the graphs.
> 
> Munin graphs for section "Network" do not have to be in a file called
> "network" - it's just a category and the plugin defines what web-page
> section it must be in. In your case, the relevant plugin is
> netstat_multi which doesn't often get installed. It's data source is
> "netstat -s" so grep that output for "timeout" to see it.
> 
> Timeouts are cumulative counters, they do not get less till they wrap
> around. So to scale them, the plugin gets the rrd file to subtract
> previous reading from current reading and divide by the time interval to
> get the timeouts/sec. This is all done inside rrd when the data files
> are updated (it's quite a lot of magic)
> 
> That plugin sets the graph type to DERIVE
> (/etc/munin/plugins/netstat_multi around line 190. I feel it should be
> GAUGE or COUNTER.
> 
> The proper reference on rrd is
> http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html
> and the munin docs are
> https://munin.readthedocs.org/en/latest/index.html
> 
> You must edit the plugin file and IIRC recreate the rrd, you will lose
> all past info (can't be helped).
> 
> 
> [snip ls output]
> 
> 
>> P.S. Any other good plugins you'd recommend?
> 
> http://gallery.munin-monitoring.org/
> 
> Monitoring is highly site-specific so recommendations aren't usually
> worth much, but that gallery has LOTS of contributed plugins
> 


-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] kernel panick in 4.2.1 from gentoo-sources

[covici]

Hi.  I am getting some kind of kernel panick in 4.2.1 -- it boots up OK,
to a virtual console with a framebuffer, but after half a minute or so,
I get the kernel panick -- now nothing is preserved in the logs, so how
do I get any information about what happened -- serial console or other
means?  Can I do a console over the network without additional hardware?

The reason I went with that kernel is because I want to try btrfs and
they develop fast, so it looked from Google searching that I should be
on 4.2 or thereabouts.  The btrfs programs I emerged did say 4.2.

So, I would like to go on two paths at once -- find out about the
panick, and maybe go to a lower kernel as well, but I was concerned
about btrfs if I do that.  I have not created the pool yet.

Thanks in advance for any suggestions.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] kernel panick in 4.2.1 from gentoo-sources

[covici]

Rich Freeman  wrote:

> On Wed, Oct 7, 2015 at 4:13 PM,   wrote:
> > Hi.  I am getting some kind of kernel panick in 4.2.1 -- it boots up OK,
> > ...
> > how
> > do I get any information about what happened -- serial console or other
> > means?  Can I do a console over the network without additional hardware?
> 
> That is pretty simple actually.
> 
> Set CONFIG_NETCONSOLE=y/m in your kernel config if it is not already set.
> add to your kernel command line:
> netconsole=@192.168.0.10/eth0,@192.168.0.5/1c:6f:65:ab:07:b2
> 
> (The first set of values is port@src-ip/interface.  The second set of
> values is port@dest-ip/MAC.  This is low-level code in the kernel so
> it is just sending raw UDP packets - the routine sending them has no
> idea what your interface IP is, and it can't use ARP.)
> 
> On the destination machine, run "nc -u -l -p "
> 
> That will listen for console output and dump it to stdout.  You'll get
> everything that goes to dmesg on the remote machine, including
> BUG/PANIC/etc output.  It works fine even if the disks stop syncing.
> 
> >
> > The reason I went with that kernel is because I want to try btrfs and
> > they develop fast, so it looked from Google searching that I should be
> > on 4.2 or thereabouts.  The btrfs programs I emerged did say 4.2.
> >
> 
> If you're having btrfs issues on such a recent kernel you should
> probably at least run all the backports that are available for it.
> 
> There are undoubtedly many btrfs issues in 4.2.1 that have been fixed
> in 4.2.3, so you should probably be running this version if you want
> to stick with 4.2.
> 
> Personally, I've been sticking with 3.18 until 4.1 quiets down.  There
> are usually regressions in any new kernel version with btrfs.
> 
> > So, I would like to go on two paths at once -- find out about the
> > panick, and maybe go to a lower kernel as well, but I was concerned
> > about btrfs if I do that.  I have not created the pool yet.
> 
> Generally speaking the btrfs on-disk format is stable, so for the most
> part you can switch back and forth between versions without issue.  If
> you want to go to a really old kernel series like maybe 3.12 there
> might be a few optional btrfs features that won't work, but in general
> I'd stick with something newer.
> 
> So, if you want to be bleeding-edge then stick with the bleeding edge
> and run the latest stable.  If you want something longterm I'd stick
> with the 1st-2nd most recent longterm.  4.1 is still pretty new, but
> I'm close to switching over to it.
> 
> You'd need to post the details of the panic to know more - the btrfs
> list is probably the best place.  But again I'd confirm the panic on
> the latest release in the series you're running so as to not waste
> time on issues that may already be fixed.


Thanks much -- 4.2.1 wqas what I just got using gentoo-sources, I will
sync and try again, maybe go to 4.1 and see what happens.  I heard 3.19
was the first version where btrfs actually worked, and I have 3.18 here,
this is why I was trying the newer kernel.  So, what is the latest lts
kernel these days anyway?

Thanks again.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] Re: workstation iptables

[Mick]

On Wednesday 07 Oct 2015 14:23:39 James wrote:
> Mick  gmail.com> writes:
> > > http://gentoo-en.vfose.ru
> > > /wiki/IptablesIptables_and_stateful_firewalls#State_basics
> > 
> > Start iptables, run the script, stop iptables with '/etc/init.d/iptables
> > >
> 
> stop' which will save your rules to /var/lib/iptables/rules-save,
> 
> 
> after starting  iptables, I ran /etc/firewall.sh (the previously published
> script) and the stop with the syntax above::
> 
> cat /var/lib/iptables/rules-save
> # Generated by iptables-save v1.4.21 on Wed Oct  7 09:13:59 2015
> *mangle
> 
> :PREROUTING ACCEPT [16022765:14170972269]
> :INPUT ACCEPT [16022479:14170935323]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [19311825:1508198446]
> :POSTROUTING ACCEPT [19311825:1508198446]
> 
> COMMIT
> # Completed on Wed Oct  7 09:13:59 2015
> # Generated by iptables-save v1.4.21 on Wed Oct  7 09:13:59 2015
> *filter
> 
> :INPUT DROP [471:17192]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [722751:44404539]
> 
> [740388:740719942] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> COMMIT
> # Completed on Wed Oct  7 09:13:59 2015
> 
> 
> was the ouput.

Are you sure that restarting iptables did not produce errors on the CLI?  The 
script you are using is somewhat old and the iptables syntax has changed since 
then.  

Have a look here:

 https://wiki.gentoo.org/wiki/Iptables


Your single rule line above should therefore look like this:

 -A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

but before this rule you should specify a default policy for your INPUT and 
other chains - ideally one to DROP all packets coming in and allow all going 
out; e.g.

 -P INPUT DROP
 -P FORWARD DROP
 -P OUTPUT ACCEPT

Also, to accept any INPUT packets on interfaces other than eth0, you would 
precede these lines with:

 -A INPUT ! -i eth0 -j ACCEPT


More details on syntax can be found in 'man iptables-extensions'.  You will 
need to modify your script accordingly for this new syntax.  To see if you are 
getting syntax errors run each rule on the CLI first, e.g.

 /sbin/iptables -A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j 
ACCEPT

and check that it takes with:

 /sbin/iptables -L -v -n

NOTE: The order in which you add iptables rules on the CLI is the order in 
which they will end up listed in /var/lib/iptables/rules-save.


BTW, I recall a thread posted for a firewall script within the last couple of 
years, but can't recall exactly who was the contributor.  Have a quick search 
in Gmane to see if you can find it.


> sysctl is not set up. I did find this page on that::
> https://wiki.gentoo.org/wiki/Procfs
> 
> Any suggestions on setting up sysctl for iptables and other future
> usage?

According to the URL you posted above you should use /etc/sysctl.d/local.conf, 
rather than the legacy /etc/sysctl.conf which I suggested.  Apologies for a 
bum steer.  Use your previous URL for stateful firewalls to see what sysctl 
settings you need to add here.


> > nmap -A -T4 -P0 -vvv -p1-65535 XXX.XX.XXX.XX
> 
> Worked flawlessly. Very precise syntax (thanks). Here are the highlights::
> 
> Not shown: 65534 closed ports

Not good.  Unless you have set up a default policy to REJECT packets, this 
shows ports that are not firewalled, but happen to be closed (no service is 
running there).  If you had a DROP policy/rule for INPUT packets it should say 
"65534 filtered ports".


> PORT   STATE SERVICE VERSION
> 22/tcp open  ssh OpenSSH 5.9p1-hpn13v11lpk (protocol 2.0)

Not good.  Unless you have also defined a rule for allowing connections to 
port 22, this shows an open port, to which a service (ssh) is currently 
listening for incoming connections.

If you want to only allow ssh connections from some local address 
192.168.1.27, you can try adding a rule for it like this:

-A INPUT -s 192.168.1.27/32 -i eth0 -p tcp -m conntrack --ctstate NEW -m mac 
--mac-source 67:35:AC:34:89:48 -m conntrack --ctorigdstport 22 -j ACCEPT


> Not bad for a quick workstation firewall(s). After I get sysctl setup,
> I'll test a few other verssions and post again. Then wikify these
> for community consumption.

Your script needs more work.  Look first at the iptables URL I posted above, 
which has the modern syntax.  Also, either define a default INPUT chain policy 
to DROP or REJECT packets, or end your script with rules to drop all other 
packets, not already accepted by previous rules:

-A INPUT -i eth0 -j DROP

PS.  Instead of running some script, you can always specify your rules in your 
/var/lib/iptables/rules-save and also back it up.  Then use this file to 
change settings as you see fit and reload/start the firewall for the settings 
to take.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] kernel panick in 4.2.1 from gentoo-sources

[Rich Freeman]

On Wed, Oct 7, 2015 at 4:13 PM,   wrote:
> Hi.  I am getting some kind of kernel panick in 4.2.1 -- it boots up OK,
> ...
> how
> do I get any information about what happened -- serial console or other
> means?  Can I do a console over the network without additional hardware?

That is pretty simple actually.

Set CONFIG_NETCONSOLE=y/m in your kernel config if it is not already set.
add to your kernel command line:
netconsole=@192.168.0.10/eth0,@192.168.0.5/1c:6f:65:ab:07:b2

(The first set of values is port@src-ip/interface.  The second set of
values is port@dest-ip/MAC.  This is low-level code in the kernel so
it is just sending raw UDP packets - the routine sending them has no
idea what your interface IP is, and it can't use ARP.)

On the destination machine, run "nc -u -l -p "

That will listen for console output and dump it to stdout.  You'll get
everything that goes to dmesg on the remote machine, including
BUG/PANIC/etc output.  It works fine even if the disks stop syncing.

>
> The reason I went with that kernel is because I want to try btrfs and
> they develop fast, so it looked from Google searching that I should be
> on 4.2 or thereabouts.  The btrfs programs I emerged did say 4.2.
>

If you're having btrfs issues on such a recent kernel you should
probably at least run all the backports that are available for it.

There are undoubtedly many btrfs issues in 4.2.1 that have been fixed
in 4.2.3, so you should probably be running this version if you want
to stick with 4.2.

Personally, I've been sticking with 3.18 until 4.1 quiets down.  There
are usually regressions in any new kernel version with btrfs.

> So, I would like to go on two paths at once -- find out about the
> panick, and maybe go to a lower kernel as well, but I was concerned
> about btrfs if I do that.  I have not created the pool yet.

Generally speaking the btrfs on-disk format is stable, so for the most
part you can switch back and forth between versions without issue.  If
you want to go to a really old kernel series like maybe 3.12 there
might be a few optional btrfs features that won't work, but in general
I'd stick with something newer.

So, if you want to be bleeding-edge then stick with the bleeding edge
and run the latest stable.  If you want something longterm I'd stick
with the 1st-2nd most recent longterm.  4.1 is still pretty new, but
I'm close to switching over to it.

You'd need to post the details of the panic to know more - the btrfs
list is probably the best place.  But again I'd confirm the panic on
the latest release in the series you're running so as to not waste
time on issues that may already be fixed.

-- 
Rich

Re: [gentoo-user] kernel panick in 4.2.1 from gentoo-sources

[Rich Freeman]

On Wed, Oct 7, 2015 at 8:34 PM,   wrote:
> Rich Freeman  wrote:
>
>> On Wed, Oct 7, 2015 at 7:13 PM,   wrote:
>> >
>> > Thanks much -- 4.2.1 wqas what I just got using gentoo-sources, I will
>> > sync and try again, maybe go to 4.1 and see what happens.  I heard 3.19
>> > was the first version where btrfs actually worked, and I have 3.18 here,
>> > this is why I was trying the newer kernel.  So, what is the latest lts
>> > kernel these days anyway?
>> >
>>
>> btrfs has been continually improved, but it has been working
>> reasonably well for raid0/1 or single disk since maybe the 3.12 days.
>>
>> Current kernel versions are posted at https://kernel.org/
> How can I tell which ones are long term support?

They say longterm next to them.  :)

Stable ones will have releases for a few months typically.

Gentoo-sources keywording tends to lag a bit, though I thought they
were going to change that.  I tend to just keep my own git clone of
the kernel tree and checkout from tags.

-- 
Rich

Re: [gentoo-user] kernel panick in 4.2.1 from gentoo-sources

[covici]

Rich Freeman  wrote:

> On Wed, Oct 7, 2015 at 8:34 PM,   wrote:
> > Rich Freeman  wrote:
> >
> >> On Wed, Oct 7, 2015 at 7:13 PM,   wrote:
> >> >
> >> > Thanks much -- 4.2.1 wqas what I just got using gentoo-sources, I will
> >> > sync and try again, maybe go to 4.1 and see what happens.  I heard 3.19
> >> > was the first version where btrfs actually worked, and I have 3.18 here,
> >> > this is why I was trying the newer kernel.  So, what is the latest lts
> >> > kernel these days anyway?
> >> >
> >>
> >> btrfs has been continually improved, but it has been working
> >> reasonably well for raid0/1 or single disk since maybe the 3.12 days.
> >>
> >> Current kernel versions are posted at https://kernel.org/
> > How can I tell which ones are long term support?
> 
> They say longterm next to them.  :)
> 
> Stable ones will have releases for a few months typically.
> 
> Gentoo-sources keywording tends to lag a bit, though I thought they
> were going to change that.  I tend to just keep my own git clone of
> the kernel tree and checkout from tags.

Do you bother with the gentoo patches?

I have the kernel tree and none of the tags say longterm, do I have the
wrong tree or  something?The url I have is
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] kernel panick in 4.2.1 from gentoo-sources

[covici]

Rich Freeman  wrote:

> On Wed, Oct 7, 2015 at 7:13 PM,   wrote:
> >
> > Thanks much -- 4.2.1 wqas what I just got using gentoo-sources, I will
> > sync and try again, maybe go to 4.1 and see what happens.  I heard 3.19
> > was the first version where btrfs actually worked, and I have 3.18 here,
> > this is why I was trying the newer kernel.  So, what is the latest lts
> > kernel these days anyway?
> >
> 
> btrfs has been continually improved, but it has been working
> reasonably well for raid0/1 or single disk since maybe the 3.12 days.
> 
> Current kernel versions are posted at https://kernel.org/
How can I tell which ones are long term support?


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] kernel panick in 4.2.1 from gentoo-sources

[Rich Freeman]

On Wed, Oct 7, 2015 at 7:13 PM,   wrote:
>
> Thanks much -- 4.2.1 wqas what I just got using gentoo-sources, I will
> sync and try again, maybe go to 4.1 and see what happens.  I heard 3.19
> was the first version where btrfs actually worked, and I have 3.18 here,
> this is why I was trying the newer kernel.  So, what is the latest lts
> kernel these days anyway?
>

btrfs has been continually improved, but it has been working
reasonably well for raid0/1 or single disk since maybe the 3.12 days.

Current kernel versions are posted at https://kernel.org/

-- 
Rich

Re: [gentoo-user] strange TCP timeout errors

[brettrsears]

YyyyYYuIU
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Alan McKinnon 
Date: Wed, 7 Oct 2015 20:39:42 
To: 
Reply-to: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] strange TCP timeout errors

On 07/10/2015 17:55, Grant wrote:
>> I've attached a PNG from Munin showing the TCP timeout errors on my
>> Gentoo server over the past month.  The data is expressed in timeouts
>> per second and that rate is shown to be steadily increasing over the
>> past month.  That seems strange to me.  Munin doesn't show any other
>> data point increasing like this over the time period.  Any ideas?
>>
>> - Grant
>>
>
> weird - does it reset on an interface restart or reboot?

 this would be my test #1
>>>
>>>
>>> I rebooted and the rate of errors has dropped off to almost nothing.
>>>
>>>
> Can you verify its not an artefact within munin (how?)

 In theory, a misconfigured graph can do this. Munin can draw many
 different types of graph, including cumulative values. Even for a data
 type like this which is X events per unit time, if you tell munin to add
 them all up, it will do so and graph it.

 Qucik test is to look at the graph config.
>>>
>>>
>>> This graph lives in the "network" section of the munin web interface.
>>> There is no matching section in /etc/munin/plugin-conf.d/munin-node so
>>> it should be be using the default config.
>>>
>>> Any ideas based on this new info?
>>
>> A few :-)
>>
>>
>> I can't find the plugin that delivers that graph though. Maybe I just
>> don't have it, maybe it comes from contrib/
>>
>> What's your USE for munin?
> 
> 
> USE="apache cgi http mysql ssl syslog -asterisk -dhcpd -doc -ipmi
> -ipv6 -irc -java -memcached -minimal -postgres (-selinux) {-test}"
> 
> 
>> What do you have in "ls -al /etc/munin/plugins/"  ?


It's as I thought - your data is accurate but rrd has been given a
completely wrong method to derive the graphs.

Munin graphs for section "Network" do not have to be in a file called
"network" - it's just a category and the plugin defines what web-page
section it must be in. In your case, the relevant plugin is
netstat_multi which doesn't often get installed. It's data source is
"netstat -s" so grep that output for "timeout" to see it.

Timeouts are cumulative counters, they do not get less till they wrap
around. So to scale them, the plugin gets the rrd file to subtract
previous reading from current reading and divide by the time interval to
get the timeouts/sec. This is all done inside rrd when the data files
are updated (it's quite a lot of magic)

That plugin sets the graph type to DERIVE
(/etc/munin/plugins/netstat_multi around line 190. I feel it should be
GAUGE or COUNTER.

The proper reference on rrd is
http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html
and the munin docs are
https://munin.readthedocs.org/en/latest/index.html

You must edit the plugin file and IIRC recreate the rrd, you will lose
all past info (can't be helped).


[snip ls output]


> P.S. Any other good plugins you'd recommend?

http://gallery.munin-monitoring.org/

Monitoring is highly site-specific so recommendations aren't usually
worth much, but that gallery has LOTS of contributed plugins

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Root device as UUID not properly detected

[J. Roeleveld]

On Tuesday, October 06, 2015 11:03:04 PM João Miguel wrote:
> > > > Possible causes:
> > > > 1. USB stick doesn't work as boot device
> > 
> > Ok, so scratch that one.
> 
> Okay, done.
> 
> > > > 2. USB port is not supported by kernel
> > > 
> > > I'm not sure what you mean. Is there any option I should enable for
> > > genkernel? I read on the Wiki page that
> > 
> > It works with Arch, are you using the same kernel options now with Gentoo?
> 
> Yeah, I tried many more here actually, with Arch I only need APPEND root=...
> (no rootfstype, ro, rw, rootdelay, etc.).

What about kernel config?

> > > > 3. You don't use root_delay as boot option
> > > 
> > > If that's what I think it is, I tell syslinux to wait 5 seconds.
> 
> (turns out it's not what I thought it was, though I did try root_delay, it
> is actually rootdelay...)
> 
> > How do you tell it that?
> 
> Here's my syslinux.cfg with more comments:
> PROMPT 1
> TIMEOUT 50# <-- here

That timeout is for the prompt, eg. how long the bootloader waits.
It will not have any effect for the drivers in the kernel to finish detecting 
the USB devices.

> DEFAULT gentoo
> 
> LABEL gentoo
> LINUX ../kernel-genkernel-x86-4.0.5-gentoo
> INITRD ../initramfs-genkernel-x86-4.0.5-gentoo
> APPEND rootdelay=5 root=UUID="6fc386ff-8342-42a2-be02-51a6eccf8430"
> rootfstype=ext4 #   ^^--- I added this just now because you said so,
> though in the last message I had root_delay # Neither of those has any
> effect (conditions 2 and 3 I told you about remain as they were) # (as I
> thought this has nthing to do with the bootloader)
> # pen (normalmente /dev/sdb4): UUID="6fc386ff-8342-42a2-be02-51a6eccf8430"
> TYPE="ext4" PARTLABEL="Root Gentoo GNU/Linux"
> PARTUUID="9c4f6479-9dd7-4a8f-86f2-f1320cc15aa5"

Hmm...
I see 2 different UUIDs in your comments.
Did you test with the PARTUUID value ("9c...") instead of the other one?

Also, I always ended up setting the rootdelay to 10 or higher. (It's in 
seconds, not minutes)

> > I never used an initrd when building my own USB sticks.
> 
> I don't know, I always used an initrd. Though I must say, that is the
> phase of starting the PC I understand the worst.

On the machines where I use an initrd, I write my own scripts as I find the 
creators (genkernel, dracut) to not be intelligent enough.

> > I was talking about:
> > rootdelay=  [KNL] Delay (in seconds) to pause before
> > attempting to
> > 
> > mount the root filesystem
> > 
> > (See the file "kernel-parameters.txt" in the kernel Documentation)
> 
> (I'm guessing I'm not supposed to include this in the boot loader config...)

The "rootdelay=..."  part needs to be added to the boot loader config.

--
Joost

[gentoo-user] Re: crossdev issues

[James]

Ralf  writes:


> I have some issues building an armv7a toolchain using crossdev.

You'll find much more expertise on the gentoo embedded IRC channel
for these sorts of issues and in depth expertise on the arm platforms.

hth,
James

Re: [gentoo-user] strange TCP timeout errors

[Grant]

>>> I've attached a PNG from Munin showing the TCP timeout errors on my
>>> Gentoo server over the past month.  The data is expressed in timeouts
>>> per second and that rate is shown to be steadily increasing over the
>>> past month.  That seems strange to me.  Munin doesn't show any other
>>> data point increasing like this over the time period.  Any ideas?
>>>
>>> - Grant
>>>
>>
>> weird - does it reset on an interface restart or reboot?
>
> this would be my test #1


I rebooted and the rate of errors has dropped off to almost nothing.


>> Can you verify its not an artefact within munin (how?)
>
> In theory, a misconfigured graph can do this. Munin can draw many
> different types of graph, including cumulative values. Even for a data
> type like this which is X events per unit time, if you tell munin to add
> them all up, it will do so and graph it.
>
> Qucik test is to look at the graph config.


This graph lives in the "network" section of the munin web interface.
There is no matching section in /etc/munin/plugin-conf.d/munin-node so
it should be be using the default config.

Any ideas based on this new info?

- Grant

[gentoo-user] Re: workstation iptables

[James]

Mick  gmail.com> writes:


> > http://gentoo-en.vfose.ru
> > /wiki/IptablesIptables_and_stateful_firewalls#State_basics

> Start iptables, run the script, stop iptables with '/etc/init.d/iptables >
stop' which will save your rules to /var/lib/iptables/rules-save, 


after starting  iptables, I ran /etc/firewall.sh (the previously published 
script) and the stop with the syntax above::

cat /var/lib/iptables/rules-save 
# Generated by iptables-save v1.4.21 on Wed Oct  7 09:13:59 2015
*mangle
:PREROUTING ACCEPT [16022765:14170972269]
:INPUT ACCEPT [16022479:14170935323]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [19311825:1508198446]
:POSTROUTING ACCEPT [19311825:1508198446]
COMMIT
# Completed on Wed Oct  7 09:13:59 2015
# Generated by iptables-save v1.4.21 on Wed Oct  7 09:13:59 2015
*filter
:INPUT DROP [471:17192]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [722751:44404539]
[740388:740719942] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Wed Oct  7 09:13:59 2015


was the ouput. 


> or
> run 'iptables-save /var/lib/iptables/rules-save'.  Add any sysctl changes
> to /etc/sysctl.conf, so that they are permanent.  Re-run the script if 
> you want to change things in it.


sysctl is not set up. I did find this page on that::
https://wiki.gentoo.org/wiki/Procfs

Any suggestions on setting up sysctl for iptables and other future
usage?



> > Any improvements in this basic workstation firewall
> > everything out, nothing in?

> Yes, but such improvements are suggested in subsequent scripts on the 
> same page, e.g. ICMP handling, selective logging, etc.  If all you want
> is "a basic firewall using iptables" for the IPv4 workspace, then what 
> you have will do the job.

I'll test out these mods and give the scripts an added sequential character 
in the name so there can be different ones for easy deployment.

The idea is to keep it as simple as possible, test out scripts and ideas
and put something easy to set up on the gentoo wiki, for all to enjoy.


> > Any good tools to quickly test this firewall from another local
> > workstation?

> nmap -A -T4 -P0 -vvv -p1-65535 XXX.XX.XXX.XX

Worked flawlessly. Very precise syntax (thanks). Here are the highlights::

Not shown: 65534 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh OpenSSH 5.9p1-hpn13v11lpk (protocol 2.0)


Not bad for a quick workstation firewall(s). After I get sysctl setup,
I'll test a few other verssions and post again. Then wikify these
for community consumption.

Thanks

James

Re: [gentoo-user] strange TCP timeout errors

[Alan McKinnon]

On 07/10/2015 14:58, Grant wrote:
 I've attached a PNG from Munin showing the TCP timeout errors on my
 Gentoo server over the past month.  The data is expressed in timeouts
 per second and that rate is shown to be steadily increasing over the
 past month.  That seems strange to me.  Munin doesn't show any other
 data point increasing like this over the time period.  Any ideas?

 - Grant

>>>
>>> weird - does it reset on an interface restart or reboot?
>>
>> this would be my test #1
> 
> 
> I rebooted and the rate of errors has dropped off to almost nothing.
> 
> 
>>> Can you verify its not an artefact within munin (how?)
>>
>> In theory, a misconfigured graph can do this. Munin can draw many
>> different types of graph, including cumulative values. Even for a data
>> type like this which is X events per unit time, if you tell munin to add
>> them all up, it will do so and graph it.
>>
>> Qucik test is to look at the graph config.
> 
> 
> This graph lives in the "network" section of the munin web interface.
> There is no matching section in /etc/munin/plugin-conf.d/munin-node so
> it should be be using the default config.
> 
> Any ideas based on this new info?

A few :-)


I can't find the plugin that delivers that graph though. Maybe I just
don't have it, maybe it comes from contrib/

What's your USE for munin?
What do you have in "ls -al /etc/munin/plugins/"  ?


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] persistent /run/* ownership/permissions

[Alan McKinnon]

On 07/10/2015 18:27, Grant wrote:
> I have to chown munin:nginx and chmod g+x on directory /run/munin/
> after every reboot.  The munin list suggests altering the initscript
> but is there a better way?


There are ways, but I wouldn't call them better.

/run is often a tmpfs so the dir has to be mkdir'ed somehow after reboot
anyway. The initscript is the perfect place to do it. There's lots of
examples in most /etc/init.d, so I suggest submit a working patch to b.g.o.


-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] OT:: free pop3 mail box?

[James]

Folks,

I do not want gmail or any other big (brother) organization email.
I just need a simple pop3 (small) email box, in case my
(underconstruction) email server is not happy. Low traffic.
Temporary is fine too.

Suggestions most welcome.

Tia,
James

Re: [gentoo-user] strange TCP timeout errors

[Grant]

> I've attached a PNG from Munin showing the TCP timeout errors on my
> Gentoo server over the past month.  The data is expressed in timeouts
> per second and that rate is shown to be steadily increasing over the
> past month.  That seems strange to me.  Munin doesn't show any other
> data point increasing like this over the time period.  Any ideas?
>
> - Grant
>

 weird - does it reset on an interface restart or reboot?
>>>
>>> this would be my test #1
>>
>>
>> I rebooted and the rate of errors has dropped off to almost nothing.
>>
>>
 Can you verify its not an artefact within munin (how?)
>>>
>>> In theory, a misconfigured graph can do this. Munin can draw many
>>> different types of graph, including cumulative values. Even for a data
>>> type like this which is X events per unit time, if you tell munin to add
>>> them all up, it will do so and graph it.
>>>
>>> Qucik test is to look at the graph config.
>>
>>
>> This graph lives in the "network" section of the munin web interface.
>> There is no matching section in /etc/munin/plugin-conf.d/munin-node so
>> it should be be using the default config.
>>
>> Any ideas based on this new info?
>
> A few :-)
>
>
> I can't find the plugin that delivers that graph though. Maybe I just
> don't have it, maybe it comes from contrib/
>
> What's your USE for munin?


USE="apache cgi http mysql ssl syslog -asterisk -dhcpd -doc -ipmi
-ipv6 -irc -java -memcached -minimal -postgres (-selinux) {-test}"


> What do you have in "ls -al /etc/munin/plugins/"  ?


# ls -al /etc/munin/plugins/
total 8
drwxr-xr-x 2 munin munin 4096 Aug 26 13:22 .
drwxr-xr-x 7 root  root  4096 Aug 27 08:42 ..
-rw-r--r-- 1 root  root 0 Aug 23 18:10 .keep_net-analyzer_munin-0
lrwxrwxrwx 1 root  root42 Jun 16  2013 apache_accesses ->
/usr/libexec/munin/plugins/apache_accesses
lrwxrwxrwx 1 root  root43 Jun 16  2013 apache_processes ->
/usr/libexec/munin/plugins/apache_processes
lrwxrwxrwx 1 root  root40 Jun 16  2013 apache_volume ->
/usr/libexec/munin/plugins/apache_volume
lrwxrwxrwx 1 root  root30 Jun 16  2013 cpu -> /usr/libexec/munin/plugins/cpu
lrwxrwxrwx 1 root  root29 Jun 16  2013 df -> /usr/libexec/munin/plugins/df
lrwxrwxrwx 1 root  root35 Jun 16  2013 df_inode ->
/usr/libexec/munin/plugins/df_inode
lrwxrwxrwx 1 root  root36 Jun 21  2013 diskstat_ ->
/usr/libexec/munin/plugins/diskstat_
lrwxrwxrwx 1 root  root36 Jun 16  2013 diskstats ->
/usr/libexec/munin/plugins/diskstats
lrwxrwxrwx 1 root  root34 Jun 16  2013 entropy ->
/usr/libexec/munin/plugins/entropy
lrwxrwxrwx 1 root  root32 Jun 16  2013 forks ->
/usr/libexec/munin/plugins/forks
lrwxrwxrwx 1 root  root34 Jun 18  2013 hddtemp ->
/usr/libexec/munin/plugins/hddtemp
lrwxrwxrwx 1 root  root35 Jun 18  2013 hddtemp2 ->
/usr/libexec/munin/plugins/hddtemp2
lrwxrwxrwx 1 root  root43 Jun 18  2013 hddtemp_smartctl ->
/usr/libexec/munin/plugins/hddtemp_smartctl
lrwxrwxrwx 1 root  root35 Jun 18  2013 hddtempd ->
/usr/libexec/munin/plugins/hddtempd
lrwxrwxrwx 1 root  root30 Jun 21  2013 if_enp2s2f0 ->
/usr/libexec/munin/plugins/if_
lrwxrwxrwx 1 root  root34 Jun 21  2013 if_err_enp2s2f0 ->
/usr/libexec/munin/plugins/if_err_
lrwxrwxrwx 1 root  root37 Jun 16  2013 interrupts ->
/usr/libexec/munin/plugins/interrupts
lrwxrwxrwx 1 root  root35 Jun 16  2013 irqstats ->
/usr/libexec/munin/plugins/irqstats
lrwxrwxrwx 1 root  root31 Jun 16  2013 load ->
/usr/libexec/munin/plugins/load
lrwxrwxrwx 1 root  root33 Jun 16  2013 lpstat ->
/usr/libexec/munin/plugins/lpstat
lrwxrwxrwx 1 root  root34 Jun 18  2013 meminfo ->
/usr/libexec/munin/plugins/meminfo
lrwxrwxrwx 1 root  root33 Jun 16  2013 memory ->
/usr/libexec/munin/plugins/memory
lrwxrwxrwx 1 root  root38 Jun 16  2013 munin_stats ->
/usr/libexec/munin/plugins/munin_stats
lrwxrwxrwx 1 root  root39 Jun 18  2013 munin_update ->
/usr/libexec/munin/plugins/munin_update
lrwxrwxrwx 1 root  root33 Jun 21  2013 mysql_bin_relay_log ->
/usr/libexec/munin/plugins/mysql_
lrwxrwxrwx 1 root  root33 Jun 21  2013 mysql_commands ->
/usr/libexec/munin/plugins/mysql_
lrwxrwxrwx 1 root  root33 Jun 21  2013 mysql_connections ->
/usr/libexec/munin/plugins/mysql_
lrwxrwxrwx 1 root  root33 Jun 21  2013 mysql_files_tables ->
/usr/libexec/munin/plugins/mysql_
lrwxrwxrwx 1 root  root33 Jun 21  2013 mysql_innodb_bpool ->
/usr/libexec/munin/plugins/mysql_
lrwxrwxrwx 1 root  root33 Jun 21  2013 mysql_innodb_bpool_act ->
/usr/libexec/munin/plugins/mysql_
lrwxrwxrwx 1 root  root33 Jun 21  2013 mysql_innodb_insert_buf ->
/usr/libexec/munin/plugins/mysql_
lrwxrwxrwx 1 root  root33 Jun 21  2013 mysql_innodb_io ->
/usr/libexec/munin/plugins/mysql_
lrwxrwxrwx 1 root  root33 Jun 21  2013 mysql_innodb_io_pend ->
/usr/libexec/munin/plugins/mysql_
lrwxrwxrwx 1 root  root33 Jun 21  2013 mysql_innodb_log ->
/usr/libexec/munin/plugins/mysql_
lrwxrwxrwx 1 root  root33 

[gentoo-user] persistent /run/* ownership/permissions

[Grant]

I have to chown munin:nginx and chmod g+x on directory /run/munin/
after every reboot.  The munin list suggests altering the initscript
but is there a better way?

- Grant

Re: [gentoo-user] strange TCP timeout errors

[Alan McKinnon]

On 07/10/2015 17:55, Grant wrote:
>> I've attached a PNG from Munin showing the TCP timeout errors on my
>> Gentoo server over the past month.  The data is expressed in timeouts
>> per second and that rate is shown to be steadily increasing over the
>> past month.  That seems strange to me.  Munin doesn't show any other
>> data point increasing like this over the time period.  Any ideas?
>>
>> - Grant
>>
>
> weird - does it reset on an interface restart or reboot?

 this would be my test #1
>>>
>>>
>>> I rebooted and the rate of errors has dropped off to almost nothing.
>>>
>>>
> Can you verify its not an artefact within munin (how?)

 In theory, a misconfigured graph can do this. Munin can draw many
 different types of graph, including cumulative values. Even for a data
 type like this which is X events per unit time, if you tell munin to add
 them all up, it will do so and graph it.

 Qucik test is to look at the graph config.
>>>
>>>
>>> This graph lives in the "network" section of the munin web interface.
>>> There is no matching section in /etc/munin/plugin-conf.d/munin-node so
>>> it should be be using the default config.
>>>
>>> Any ideas based on this new info?
>>
>> A few :-)
>>
>>
>> I can't find the plugin that delivers that graph though. Maybe I just
>> don't have it, maybe it comes from contrib/
>>
>> What's your USE for munin?
> 
> 
> USE="apache cgi http mysql ssl syslog -asterisk -dhcpd -doc -ipmi
> -ipv6 -irc -java -memcached -minimal -postgres (-selinux) {-test}"
> 
> 
>> What do you have in "ls -al /etc/munin/plugins/"  ?


It's as I thought - your data is accurate but rrd has been given a
completely wrong method to derive the graphs.

Munin graphs for section "Network" do not have to be in a file called
"network" - it's just a category and the plugin defines what web-page
section it must be in. In your case, the relevant plugin is
netstat_multi which doesn't often get installed. It's data source is
"netstat -s" so grep that output for "timeout" to see it.

Timeouts are cumulative counters, they do not get less till they wrap
around. So to scale them, the plugin gets the rrd file to subtract
previous reading from current reading and divide by the time interval to
get the timeouts/sec. This is all done inside rrd when the data files
are updated (it's quite a lot of magic)

That plugin sets the graph type to DERIVE
(/etc/munin/plugins/netstat_multi around line 190. I feel it should be
GAUGE or COUNTER.

The proper reference on rrd is
http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html
and the munin docs are
https://munin.readthedocs.org/en/latest/index.html

You must edit the plugin file and IIRC recreate the rrd, you will lose
all past info (can't be helped).


[snip ls output]


> P.S. Any other good plugins you'd recommend?

http://gallery.munin-monitoring.org/

Monitoring is highly site-specific so recommendations aren't usually
worth much, but that gallery has LOTS of contributed plugins

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] workstation iptables

[Tom H]

On Tue, Oct 6, 2015 at 3:14 PM, James  wrote:
>
> #!/bin/bash
> # A basic stateful firewall for a workstation or laptop that isn't running any
> # network services like a web server, SMTP server, ftp server, etc.
>
> if [ "$1" = "start" ]
> then
> echo "Starting firewall..."
> iptables -P INPUT DROP
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> elif [ "$1" = "stop" ]
> then
> echo "Stopping firewall..."
> iptables -F INPUT
> iptables -P INPUT ACCEPT
> fi

Since you're starting from scratch, you might want to replace "-m
state --state" by "-m conntrack --ctstate" because the former's
deprecated and is now an alias to the latter.

Re: [gentoo-user] workstation iptables

[Alon Bar-Lev]

On 6 October 2015 at 22:14, James  wrote:
>
> Hello,
>
> I just ran across this page:
>
> http://gentoo-en.vfose.ru/wiki/Iptables/Iptables_and_stateful_firewalls#State_basics
>
> It has a basic firewall using iptables.
> Not bad for a generic firewall on a openrc workstation.
> What is the best way to auto lauch this sort of firewall.sh ?
>
> Any improvements in this basic workstation firewall
> everything out, nothing in?
> A simple rule for ssh in only from the local lan
> (use 192.168.100.100 for example rule(s).
>
>

Hi,

I suggest you look into firehol package.
It creates iptables rules out of human readable policy.

Regards,
Alon

> ...
> firewall.sh
> ...
> #!/bin/bash
> # A basic stateful firewall for a workstation or laptop that isn't running any
> # network services like a web server, SMTP server, ftp server, etc.
>
> if [ "$1" = "start" ]
> then
> echo "Starting firewall..."
> iptables -P INPUT DROP
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> elif [ "$1" = "stop" ]
> then
> echo "Stopping firewall..."
> iptables -F INPUT
> iptables -P INPUT ACCEPT
> fi
> 
>
> just launched manually as a script.
>
>
> Any good tools to quickly test this firewall from another local workstation?
>
>
> wwr,
> James
>
>

Re: [gentoo-user] OT:: free pop3 mail box?

[wabenbau]

 wrote:

> James  wrote:
> 
> > Folks,
> > 
> > I do not want gmail or any other big (brother) organization email.
> > I just need a simple pop3 (small) email box, in case my
> > (underconstruction) email server is not happy. Low traffic.
> > Temporary is fine too.
> > 
> > Suggestions most welcome.
> > 
> > Tia,
> > James
> > 
> 
> Take a look at mailbox.org.

Sorry, I overlooked that you are searching a free mail provider.
Mailbox.org isn't free of charge, but it isn't expensive and they claim
to respect privacy.

--
Regards
wabe

Re: [gentoo-user] OT:: free pop3 mail box?

[wabenbau]

James  wrote:

> Folks,
> 
> I do not want gmail or any other big (brother) organization email.
> I just need a simple pop3 (small) email box, in case my
> (underconstruction) email server is not happy. Low traffic.
> Temporary is fine too.
> 
> Suggestions most welcome.
> 
> Tia,
> James
> 

Take a look at mailbox.org.

--
Regards
wabe