Re: [gentoo-user] Re: help! IP blocking not working

[J. Roeleveld]

On September 6, 2016 10:57:54 PM GMT+02:00, Grant  wrote:
>> Hi, my site is being ravaged by an IP but dropping the IP via
>> shorewall is seeming to have no effect.  I'm using his IP from nginx
>> logs.  IP blocking in shorewall has always worked before.  What could
>> be happening?
>
>
>I'm blocking like this with the firewall running on the web server:
>
>/etc/shorewall/rules
>DROPnet:1.2.3.4  $FW
>
>Could shorewall/iptables see a different IP address than the one seen
>by nginx?
>
>- Grant

Did you reload the firewall rules?

--
Joost

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] help! IP blocking not working

[J. Roeleveld]

On September 6, 2016 10:17:53 PM GMT+02:00, Grant  wrote:
>Hi, my site is being ravaged by an IP but dropping the IP via
>shorewall is seeming to have no effect.  I'm using his IP from nginx
>logs.  IP blocking in shorewall has always worked before.  What could
>be happening?
>
>- Grant

Grant,

With shorewall it is quite easy. Ensure you have the blacklist enabled.
Then:
# shorewall block 1.2.3.4

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Mike Gilbert]

On Tue, Sep 6, 2016 at 6:03 PM, gevisz  wrote:
> 2016-09-07 0:32 GMT+03:00 Neil Bothwick :
>> On Wed, 7 Sep 2016 00:05:32 +0300, gevisz wrote:
>>
>>> >> But it seems that GRUB does not read fstab... :(
>>> >
>>> > It does not, because it has not loaded the kernel yet, so it cannot do
>>> > anything on the system.
>>>
>>> Oh, poor little Grand Unified Boot Loader!
>>>
>>> It cannot do anything! Even to read fstab by its grub-mkconfig script!
>>
>> We were talking about GRUB the bootloader, not grub-mkconfig the Linux
>> program to write grub.cfg. As you were asking whether you should run
>> grub-mkconfig again, it seems reasonable to assume that you haven't run
>> it since adding the disk, not that it should make a difference.
>>
>>> P.S. I usually run grub-mkconfig when kernel is already loaded!
>>>   And in my fstab all the disks are refered by UUID!
>>>
>>
>> grub-mkconfig doesn't care about the fstab of the running distro since it
>> scans your drives for all operating systems it can boot.
>>
>> Either look in grub.cfg to see what it going on or post it here along
>> with the exact error messages so others may try for you.
>>
>
> I have added the following line to the /etc/default/grub
>
> GRUB_CMDLINE_LINUX="root=UUID=44***"
>
> run
>
> # grub-mkconfig -o /boot/grub/grub.cfg
>
> and got in  the following entry
>
> ### BEGIN /etc/grub.d/10_linux ###
> menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class
> gnu --class os $menuentry_id_option 'gnulinux-simple-44***' {
> load_video
> insmod gzio
> insmod part_msdos
> insmod ext2
> set root='hd1,msdos3'
> if [ x$feature_platform_search_hint = xy ]; then
>   search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos3
> --hint-efi=hd1,msdos3 --hint-baremetal=ahci1,msdos3
> --hint='hd1,msdos3'  44***
> else
>   search --no-floppy --fs-uuid --set=root 44***
> fi
> echo'Loading Linux 4.4.6-gentoo ...'
> linux/boot/vmlinuz-4.4.6-gentoo root=/dev/sdb3 ro
> }
>
> wich, in my view, does not differ a lot from what was before.
>
> The 44*** denotes the UUID of my boot partition.
>
> Will try it tomorrow and report.
>

grub-mkconfig is not finding an initramfs, as evidenced by the lack of
an "initrd" in in grub.cfg.

If it is unable to find an initramfs, it will always output
root=/dev/sdX instead of root=UUID=...

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Dutch Ingraham]

On Wed, Sep 07, 2016 at 12:38:40AM +0100, Neil Bothwick wrote:
> On Tue, 6 Sep 2016 18:22:54 -0500, Dutch Ingraham wrote:
> 
> > > grub-mkconfig doesn't care about the fstab of the running distro
> > > since it scans your drives for all operating systems it can boot.
> > >   
> > Sorry if I missed something in this tome, but I was under the
> > impression that a seperate utility, os-prober (or something similar),
> > was needed to scan outside of the current partition.  Some distros do
> > not include this type of utility by default, but it has been 3 years
> > since I installed my Gentoo and I just don't remember.  Is this
> > off-topic?
> 
> os-prober scans for Windows and other non-Linux installations.

That's true, but it seems to imply it does not scan for Linux, which is not true
to my understanding.

os-prober is just a shell script, but a little dense for me to make conclusions
of; maybe you can make sense of it, if you have it.  However, the Ubuntu people 
say this:

"30_os-prober This script uses os-prober to search for Linux and other 
operating 
systems and places the results in the GRUB 2 menu.

   1.  The file's sections include options for Windows, Linux, OSX, and Hurd."

The full quote is here:
https://help.ubuntu.com/community/Grub2/Setup

My point was just to see if this information was helpful to the OP.  Like I
said, I kind-of lost track of this thread.  If it's not helpful, that's fine.

Re: [gentoo-user] [OT] Is it still advisable to partition a big hard drive?

[Volker Armin Hemmann]

Am 01.09.2016 um 11:01 schrieb Alan McKinnon:
> On 01/09/2016 09:18, gevisz wrote:
>> 2016-09-01 9:13 GMT+03:00 Alan McKinnon :
>>> On 01/09/2016 08:04, gevisz wrote:
> [snip]
>
>>> it will take about 5 seconds to partition it.
>>> And a few more to mkfs it.
>> Just to partition - may be, but I very much doubt
>> that it will take seconds to create a full-fledged
>> ext4 file system on these 5TB via USB2 connention.
>
> Do it. Tell me how long it tool.
>
> Discussing it without doing it and offering someone else's opinion is a
> 100% worthless activity
>
>> Even more: my aquiantance from the Window world
>> that recomended me this disc scared me that it may
>> take days...
> Mickey Mouse told me it takes microseconds. So what?
>
> Do it. Tell me how long it took.
>
 Is it still advisable to partition a big hard drive
 into smaller logical ones and why?
>>> The only reason to partition a drive is to get 2 or more
>>> smaller ones that differ somehow (size, inode ratio, mount options, etc)
>>>
>>> Go with no partition table by all means, but if you one day find you
>>> need one, you will have to copy all your data off, repartition, and copy
>>> your data back. If you are certain that will not happen (eg you will
>>> rather buy a second drive) then by all means dispense with partitions.
>>>
>>> They are after all nothing more than a Microsoft invention from the 80s
>>> so people could install UCSD Pascal next to MS-DOS
>> I definitely will not need more than one mount point for this hard drive
>> but I do remember some arguments that partitioning a large hard drive
>> into smaller logical ones gives me more safety in case a file system
>> suddenly will get corrupted because in this case I will loose my data
>> only on one of the logical partitions and not on the whole drive.
>>
>> Is this argument still valid nowadays?
> That is the most stupid dumbass argument I've heard in weeks.
> It doesn't even deserve a response.
>
> Who the fuck is promoting this shit?
>
>
people who had to deal with corrupted filesystems in the past?

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

On Tue, 6 Sep 2016 18:22:54 -0500, Dutch Ingraham wrote:

> > grub-mkconfig doesn't care about the fstab of the running distro
> > since it scans your drives for all operating systems it can boot.
> >   
> Sorry if I missed something in this tome, but I was under the
> impression that a seperate utility, os-prober (or something similar),
> was needed to scan outside of the current partition.  Some distros do
> not include this type of utility by default, but it has been 3 years
> since I installed my Gentoo and I just don't remember.  Is this
> off-topic?

os-prober scans for Windows and other non-Linux installations.


-- 
Neil Bothwick

Eat shit - 50 million flies can't be wrong
Use Microsoft . . . . .


pgpsQbYIDiOJ3.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Dutch Ingraham]

On Tue, Sep 06, 2016 at 10:32:35PM +0100, Neil Bothwick wrote:
> On Wed, 7 Sep 2016 00:05:32 +0300, gevisz wrote:
> 
> 
> grub-mkconfig doesn't care about the fstab of the running distro since it
> scans your drives for all operating systems it can boot.
> 
Sorry if I missed something in this tome, but I was under the impression that 
a seperate utility, os-prober (or something similar), was needed to scan outside
of the current partition.  Some distros do not include this type of utility by 
default, but it has been 3 years since I installed my Gentoo and I just don't
remember.  Is this off-topic?

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

On Wed, 7 Sep 2016 01:03:19 +0300, gevisz wrote:

> > grub-mkconfig doesn't care about the fstab of the running distro
> > since it scans your drives for all operating systems it can boot.
> >
> > Either look in grub.cfg to see what it going on or post it here along
> > with the exact error messages so others may try for you.
> >  
> 
> I have added the following line to the /etc/default/grub
> 
> GRUB_CMDLINE_LINUX="root=UUID=44***"

Why? Did you read the relevant section of the GRUB manual before doing
this?
 
> run
> 
> # grub-mkconfig -o /boot/grub/grub.cfg
> 
> and got in  the following entry
> 
> ### BEGIN /etc/grub.d/10_linux ###
> menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class
> gnu --class os $menuentry_id_option 'gnulinux-simple-44***' {
> load_video
> insmod gzio
> insmod part_msdos
> insmod ext2
> set root='hd1,msdos3'
> if [ x$feature_platform_search_hint = xy ]; then
>   search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos3
> --hint-efi=hd1,msdos3 --hint-baremetal=ahci1,msdos3
> --hint='hd1,msdos3'  44***
> else
>   search --no-floppy --fs-uuid --set=root 44***
> fi
> echo'Loading Linux 4.4.6-gentoo ...'
> linux/boot/vmlinuz-4.4.6-gentoo root=/dev/sdb3 ro
  ~~
> }
> 
> wich, in my view, does not differ a lot from what was before.

We'll have to take your word for that as you didn't post what you had
before, but things don't have to differ a lot to break.

However, the problem is clear in the menu you posted, it is using
root=/dev/sdb3. When you connect anther drive, they are renumbered and
that points to the wrong drive.

> The 44*** denotes the UUID of my boot partition.

Why obfuscate it? It's only a UUID not your online banking password.


-- 
Neil Bothwick

When you go to court you are putting yourself in the hands of 12 people
that were not smart enough to get out of jury duty.


pgp0VgQ6hzKru.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-07 0:32 GMT+03:00 Neil Bothwick :
> On Wed, 7 Sep 2016 00:05:32 +0300, gevisz wrote:
>
>> >> But it seems that GRUB does not read fstab... :(
>> >
>> > It does not, because it has not loaded the kernel yet, so it cannot do
>> > anything on the system.
>>
>> Oh, poor little Grand Unified Boot Loader!
>>
>> It cannot do anything! Even to read fstab by its grub-mkconfig script!
>
> We were talking about GRUB the bootloader, not grub-mkconfig the Linux
> program to write grub.cfg. As you were asking whether you should run
> grub-mkconfig again, it seems reasonable to assume that you haven't run
> it since adding the disk, not that it should make a difference.
>
>> P.S. I usually run grub-mkconfig when kernel is already loaded!
>>   And in my fstab all the disks are refered by UUID!
>>
>
> grub-mkconfig doesn't care about the fstab of the running distro since it
> scans your drives for all operating systems it can boot.
>
> Either look in grub.cfg to see what it going on or post it here along
> with the exact error messages so others may try for you.
>

I have added the following line to the /etc/default/grub

GRUB_CMDLINE_LINUX="root=UUID=44***"

run

# grub-mkconfig -o /boot/grub/grub.cfg

and got in  the following entry

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class
gnu --class os $menuentry_id_option 'gnulinux-simple-44***' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd1,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos3
--hint-efi=hd1,msdos3 --hint-baremetal=ahci1,msdos3
--hint='hd1,msdos3'  44***
else
  search --no-floppy --fs-uuid --set=root 44***
fi
echo'Loading Linux 4.4.6-gentoo ...'
linux/boot/vmlinuz-4.4.6-gentoo root=/dev/sdb3 ro
}

wich, in my view, does not differ a lot from what was before.

The 44*** denotes the UUID of my boot partition.

Will try it tomorrow and report.

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

On Wed, 7 Sep 2016 00:05:32 +0300, gevisz wrote:

> >> But it seems that GRUB does not read fstab... :(  
> >
> > It does not, because it has not loaded the kernel yet, so it cannot do
> > anything on the system.  
> 
> Oh, poor little Grand Unified Boot Loader!
> 
> It cannot do anything! Even to read fstab by its grub-mkconfig script!

We were talking about GRUB the bootloader, not grub-mkconfig the Linux
program to write grub.cfg. As you were asking whether you should run
grub-mkconfig again, it seems reasonable to assume that you haven't run
it since adding the disk, not that it should make a difference.

> P.S. I usually run grub-mkconfig when kernel is already loaded!
>   And in my fstab all the disks are refered by UUID!
> 

grub-mkconfig doesn't care about the fstab of the running distro since it
scans your drives for all operating systems it can boot.

Either look in grub.cfg to see what it going on or post it here along
with the exact error messages so others may try for you.


-- 
Neil Bothwick

Too many clicks spoil the browse.


pgpyn9Mz3Fcc0.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-07 0:07 GMT+03:00 Rich Freeman :
> On Tue, Sep 6, 2016 at 4:57 PM, gevisz  wrote:
>>
>> It seems that now I should edit /boot/grub/grub.cfg directly
>> without even knowing its commands.
>>
>
> Well, if nothing else you can certainly read it and see what it is
> putting in there.  If you page down you'll hit the actual menus which
> are readable enough.
>
> While the autogenerated menus are fairly complex, the reality is that
> grub2 is able to handle simple configuration files the same way that
> grub1 was.  The format is slightly different though.  So, that is
> always a fallback.  However, I'd check /etc/defaults/grub to make sure
> you don't have it set to suppress UUIDs.  That will, obviously,
> suppress UUIDs.
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
#
# To populate all changes in this file you need to regenerate your
# grub configuration file afterwards:
# 'grub2-mkconfig -o /boot/grub/grub.cfg'
#
# See the grub info page for documentation on possible variables and
# their associated values.

GRUB_DISTRIBUTOR="Gentoo"

# Default menu entry
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
# Boot the default entry this many seconds after the menu is displayed
GRUB_TIMEOUT=7
#GRUB_TIMEOUT_STYLE=menu

# Append parameters to the linux kernel command line
#GRUB_CMDLINE_LINUX=""
#
# Examples:
#
# Boot with network interface renaming disabled
# GRUB_CMDLINE_LINUX="net.ifnames=0"
#
# Boot with systemd instead of sysvinit (openrc)
# GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd"

# Append parameters to the linux kernel command line for non-recovery entries
#GRUB_CMDLINE_LINUX_DEFAULT=""

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal.
# Note that you can use only modes which your graphic card supports via VBE.
# You can see them in real GRUB with the command `vbeinfo'.
#GRUB_GFXMODE=640x480

# Set to 'text' to force the Linux kernel to boot in normal text
# mode, 'keep' to preserve the graphics mode set using
# 'GRUB_GFXMODE', 'WIDTHxHEIGHT'['xDEPTH'] to set a particular
# graphics mode, or a sequence of these separated by commas or
# semicolons to try several modes in sequence.
#GRUB_GFXPAYLOAD_LINUX=

# Path to theme spec txt file.
# The starfield is by default provided with use truetype.
# NOTE: when enabling custom theme, ensure you have required font/etc.
#GRUB_THEME="/boot/grub/themes/starfield/theme.txt"

# Background image used on graphical terminal.
# Can be in various bitmap formats.
#GRUB_BACKGROUND="/boot/grub/mybackground.png"

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to kernel
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY=true

# Uncomment to disable generation of the submenu and put all choices on
# the top-level menu.
# Besides the visual affect of no sub menu, this makes navigation of the
# menu easier for a user who can't see the screen.
#GRUB_DISABLE_SUBMENU=y

# Uncomment to play a tone when the main menu is displayed.
# This is useful, for example, to allow users who can't see the screen
# to know when they can make a choice on the menu.
#GRUB_INIT_TUNE="60 800 1"

Re: [gentoo-user] Re: help! IP blocking not working

[Alan McKinnon]

On 06/09/2016 22:57, Grant wrote:
>> Hi, my site is being ravaged by an IP but dropping the IP via
>> shorewall is seeming to have no effect.  I'm using his IP from nginx
>> logs.  IP blocking in shorewall has always worked before.  What could
>> be happening?
> 
> 
> I'm blocking like this with the firewall running on the web server:
> 
> /etc/shorewall/rules
> DROPnet:1.2.3.4  $FW
> 
> Could shorewall/iptables see a different IP address than the one seen by 
> nginx?


Most likely the file is configured but the firewall service wasn't
restarted or the rules no loaded.

Be careful with that one - it's all too easy to *think* you reloaded
them when you didn't and one's own confirmation bias kicks in. I see it
daily with everyone in my team (me included)

But as Jeremi pointed out. failsban is a far superior tool for this.
Ossec with it's active response is also good.
There are quite a few more tools in this space, and they all work much
the same way - scan logs looking for dodgy stuff going on the
dynamically apply a packet filter rule. The software also does it all
day every day, and that's a record you the human cannot hope to match :-)

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

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Alan McKinnon]

On 06/09/2016 23:05, gevisz wrote:
> 2016-09-06 22:54 GMT+03:00 Neil Bothwick :
>> On Tue, 6 Sep 2016 21:38:07 +0300, gevisz wrote:


>> grub-mkconfig should use UUIDs by default, unless you have uncommented
>>
>> #GRUB_DISABLE_LINUX_UUID=true
> 
> I did not. So, it is a bug in a almighty Grand Unified Boot Loader!



or the MUCH more likely: you did it wrong.
That's something you seem to do a lot of.
You might want to look into that.
Also the bit where you listen to others who have done it right.

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

Re: [gentoo-user] Re: help! IP blocking not working

[Jeremi Piotrowski]

On Tue, Sep 06, 2016 at 01:57:54PM -0700, Grant wrote:
> > Hi, my site is being ravaged by an IP but dropping the IP via
> > shorewall is seeming to have no effect.  I'm using his IP from nginx
> > logs.

What you really need is to set up net-anlyzer/fail2ban and not do this
kind of stuff manually. It automates parsing logs for attacks and setting
up persistent iptables rules to block them.

As soon as I assigned a dns domain name to my home ssh-server and made it
available externally I was getting attacked by multiple IP addresses from
china, and as soon as one IP was banned they came at me with another one.
After I set up fail2ban and set a low preauth limit along with lifetime
bans, this whole cat-and-mouse game started going more to my liking.

Highly recommend you try it, it comes with lots of predefined
rules/templates that you can choose from (I see nginx-botsearch and
nginx-http-auth are included).

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Rich Freeman]

On Tue, Sep 6, 2016 at 4:57 PM, gevisz  wrote:
>
> It seems that now I should edit /boot/grub/grub.cfg directly
> without even knowing its commands.
>

Well, if nothing else you can certainly read it and see what it is
putting in there.  If you page down you'll hit the actual menus which
are readable enough.

While the autogenerated menus are fairly complex, the reality is that
grub2 is able to handle simple configuration files the same way that
grub1 was.  The format is slightly different though.  So, that is
always a fallback.  However, I'd check /etc/defaults/grub to make sure
you don't have it set to suppress UUIDs.  That will, obviously,
suppress UUIDs.

-- 
Rich

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 22:54 GMT+03:00 Neil Bothwick :
> On Tue, 6 Sep 2016 21:38:07 +0300, gevisz wrote:
>
>> > It sounds like you are specifying the root device by device node and
>> > those have changed with the addition of a new drive. Using UUID or
>> > LABEL will avoid this problem.
>>
>> Thank you for the prompt reply!
>>
>> In my fstab, all the old drives are specified by UUID.
>> And the new one does not have UUID yet.
>>
>> But it seems that GRUB does not read fstab... :(
>
> It does not, because it has not loaded the kernel yet, so it cannot do
> anything on the system.

Oh, poor little Grand Unified Boot Loader!

It cannot do anything! Even to read fstab by its grub-mkconfig script!

P.S. I usually run grub-mkconfig when kernel is already loaded!
  And in my fstab all the disks are refered by UUID!

>> Where else should I specify them?
>
> grub.cfg in the kernel options.
>
>> Do you think that running
>> # grub-mkconfig -o /boot/grub/grub.cfg
>> with a new drive connected will be enough?
>
> grub-mkconfig should use UUIDs by default, unless you have uncommented
>
> #GRUB_DISABLE_LINUX_UUID=true

I did not. So, it is a bug in a almighty Grand Unified Boot Loader!

> in /etc/default/grub
>
>
> --
> Neil Bothwick
>
> Top Oxymorons Number 8: Tight slacks

[gentoo-user] Re: help! IP blocking not working

[Grant]

> Hi, my site is being ravaged by an IP but dropping the IP via
> shorewall is seeming to have no effect.  I'm using his IP from nginx
> logs.  IP blocking in shorewall has always worked before.  What could
> be happening?


I'm blocking like this with the firewall running on the web server:

/etc/shorewall/rules
DROPnet:1.2.3.4  $FW

Could shorewall/iptables see a different IP address than the one seen by nginx?

- Grant

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 22:48 GMT+03:00 Daniel Frey :
> On 09/06/2016 12:39 PM, gevisz wrote:
>> 2016-09-06 22:08 GMT+03:00 Rich Freeman :
>>> On Tue, Sep 6, 2016 at 3:01 PM, gevisz  wrote:

 I have already looked into this file but did not find where to set the
 UUID of the root partion.

>>>
>>> It depends.  :)
>>>
>>> Usually you end up with root=UUID=abc on your kernel command line.  It
>>> looks like grub-mkconfig is supposed to do this automatically.
>>
>> I do agree and suspect that it is a bug in grub-mkconfig.
>>
>> Why otherwise adding a new unformatted disk to the system
>> should prevent grub from finding a root (and boot :) partition
>> if it already been set in fstab?
>
> Because either the BIOS (or the kernel itself) is rearranging your
> device names when you plug the new device in.

After the GRUB menu, it should be GRUB.

But why, on earth, it does not use UUID that has been set in fstab
and was available for grub-mkconfig?

It seems that now I should edit /boot/grub/grub.cfg directly
without even knowing its commands.

>>> Your initramfs tool may also do something here (I know dracut sticks a
>>> copy of your fstab in the initramfs and uses it to help find the root
>>> partition, assuming you have root in your fstab (if not it will
>>> probably yell at you at some point)).
>>>
>>> You have to use an initramfs to use a UUID to mount your root.
>
> I ran into this myself and I don't remember having to use an initramfs
> to fix it. In my case I believe it was USB devices mucking it up and I
> was able to fix it by building sata into the kernel and USB as modules
> so it wouldn't mess up my boot order. I don't think this will work in
> your case though.
>
> I see you are still using IDE drives, so perhaps the kernel is loading
> the sata and ide order differently when adding a new drive.
>
>
> Dan
>

[gentoo-user] help! IP blocking not working

[Grant]

Hi, my site is being ravaged by an IP but dropping the IP via
shorewall is seeming to have no effect.  I'm using his IP from nginx
logs.  IP blocking in shorewall has always worked before.  What could
be happening?

- Grant

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Rich Freeman]

On Tue, Sep 6, 2016 at 4:10 PM, Alan McKinnon  wrote:
> On 06/09/2016 21:39, gevisz wrote:
>>
>> 2016-09-06 22:08 GMT+03:00 Rich Freeman :
>>>
>>> On Tue, Sep 6, 2016 at 3:01 PM, gevisz  wrote:


 I have already looked into this file but did not find where to set the
 UUID of the root partion.

>>>
>>> It depends.  :)
>>>
>>> Usually you end up with root=UUID=abc on your kernel command line.  It
>>> looks like grub-mkconfig is supposed to do this automatically.
>>
>>
>> I do agree and suspect that it is a bug in grub-mkconfig.
>>
>> Why otherwise adding a new unformatted disk to the system
>> should prevent grub from finding a root (and boot :) partition
>> if it already been set in fstab?
>
> Easy. BIOS/efi and/or udev has decided to renumber your drives and give them
> different node names.
>

Adding a new disk would not affect the UUID of existing disks, so as
long as grub-mkconfig is setting them on the command line you won't
have this issue.

Whether or not there is a bug is another matter.  If you tell
grub-mkconfig to not use UUID then it will comply.  And then
renumbering can certainly cause issues.

-- 
Rich

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Alan McKinnon]

On 06/09/2016 21:39, gevisz wrote:

2016-09-06 22:08 GMT+03:00 Rich Freeman :

On Tue, Sep 6, 2016 at 3:01 PM, gevisz  wrote:


I have already looked into this file but did not find where to set the
UUID of the root partion.



It depends.  :)

Usually you end up with root=UUID=abc on your kernel command line.  It
looks like grub-mkconfig is supposed to do this automatically.


I do agree and suspect that it is a bug in grub-mkconfig.

Why otherwise adding a new unformatted disk to the system
should prevent grub from finding a root (and boot :) partition
if it already been set in fstab?



Easy. BIOS/efi and/or udev has decided to renumber your drives and give 
them different node names.


All my Dell laptops are like that - firmware sees the ssd as the first 
drive and that's the name grub uses. The kernel and udev see them in the 
opposite order so auto tools for grub always get it wrong.


It's common, nothing to get upset about. It's one of the reasons why 
udev does the tricks it does.









Your initramfs tool may also do something here (I know dracut sticks a
copy of your fstab in the initramfs and uses it to help find the root
partition, assuming you have root in your fstab (if not it will
probably yell at you at some point)).

You have to use an initramfs to use a UUID to mount your root.


I do use initramfs (created by genkernel) as the system refuses
to boot without it.

I have already thought about it.

Do you think that I  should recreate initramfs anew after adding
a new hard disk?

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

On Tue, 6 Sep 2016 21:38:07 +0300, gevisz wrote:

> > It sounds like you are specifying the root device by device node and
> > those have changed with the addition of a new drive. Using UUID or
> > LABEL will avoid this problem.  
> 
> Thank you for the prompt reply!
> 
> In my fstab, all the old drives are specified by UUID.
> And the new one does not have UUID yet.
> 
> But it seems that GRUB does not read fstab... :(

It does not, because it has not loaded the kernel yet, so it cannot do
anything on the system.
 
> Where else should I specify them?

grub.cfg in the kernel options.

> Do you think that running
> # grub-mkconfig -o /boot/grub/grub.cfg
> with a new drive connected will be enough?

grub-mkconfig should use UUIDs by default, unless you have uncommented

#GRUB_DISABLE_LINUX_UUID=true

in /etc/default/grub


-- 
Neil Bothwick

Top Oxymorons Number 8: Tight slacks


pgpRRuQTta5y0.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Daniel Frey]

On 09/06/2016 12:39 PM, gevisz wrote:
> 2016-09-06 22:08 GMT+03:00 Rich Freeman :
>> On Tue, Sep 6, 2016 at 3:01 PM, gevisz  wrote:
>>>
>>> I have already looked into this file but did not find where to set the
>>> UUID of the root partion.
>>>
>>
>> It depends.  :)
>>
>> Usually you end up with root=UUID=abc on your kernel command line.  It
>> looks like grub-mkconfig is supposed to do this automatically.
> 
> I do agree and suspect that it is a bug in grub-mkconfig.
> 
> Why otherwise adding a new unformatted disk to the system
> should prevent grub from finding a root (and boot :) partition
> if it already been set in fstab?

Because either the BIOS (or the kernel itself) is rearranging your
device names when you plug the new device in.


> 
>> Your initramfs tool may also do something here (I know dracut sticks a
>> copy of your fstab in the initramfs and uses it to help find the root
>> partition, assuming you have root in your fstab (if not it will
>> probably yell at you at some point)).
>>
>> You have to use an initramfs to use a UUID to mount your root.

I ran into this myself and I don't remember having to use an initramfs
to fix it. In my case I believe it was USB devices mucking it up and I
was able to fix it by building sata into the kernel and USB as modules
so it wouldn't mess up my boot order. I don't think this will work in
your case though.

I see you are still using IDE drives, so perhaps the kernel is loading
the sata and ide order differently when adding a new drive.


Dan

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 22:08 GMT+03:00 Rich Freeman :
> On Tue, Sep 6, 2016 at 3:01 PM, gevisz  wrote:
>>
>> I have already looked into this file but did not find where to set the
>> UUID of the root partion.
>>
>
> It depends.  :)
>
> Usually you end up with root=UUID=abc on your kernel command line.  It
> looks like grub-mkconfig is supposed to do this automatically.

I do agree and suspect that it is a bug in grub-mkconfig.

Why otherwise adding a new unformatted disk to the system
should prevent grub from finding a root (and boot :) partition
if it already been set in fstab?

> Your initramfs tool may also do something here (I know dracut sticks a
> copy of your fstab in the initramfs and uses it to help find the root
> partition, assuming you have root in your fstab (if not it will
> probably yell at you at some point)).
>
> You have to use an initramfs to use a UUID to mount your root.

I do use initramfs (created by genkernel) as the system refuses
to boot without it.

I have already thought about it.

Do you think that I  should recreate initramfs anew after adding
a new hard disk?

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Rich Freeman]

On Tue, Sep 6, 2016 at 3:01 PM, gevisz  wrote:
>
> I have already looked into this file but did not find where to set the
> UUID of the root partion.
>

It depends.  :)

Usually you end up with root=UUID=abc on your kernel command line.  It
looks like grub-mkconfig is supposed to do this automatically.

Your initramfs tool may also do something here (I know dracut sticks a
copy of your fstab in the initramfs and uses it to help find the root
partition, assuming you have root in your fstab (if not it will
probably yell at you at some point)).

You have to use an initramfs to use a UUID to mount your root.

-- 
Rich

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 21:45 GMT+03:00 Willie M :
> On 09/06/2016 11:38 AM, gevisz wrote:
>> 2016-09-06 21:21 GMT+03:00 Neil Bothwick :
>>> On Tue, 6 Sep 2016 21:16:12 +0300, gevisz wrote:
>>>
 I had one IDE hard drive for /
 and one SATA hard drive for /home

 After adding another (yet non-formatted) SATA hard drive
 the system panics and complains that it cannot find kernel
 (if I understood it correctly :).

 As it happens after the GRUB(2) menu, I suspect GRUB(2).

 Just executed
 # grub-mkconfig -o /boot/grub/grub.cfg
 but have not tried to reboot yet.

 After disconnecting a new hard drive, the system boot normally.
>>>
>>> It sounds like you are specifying the root device by device node and
>>> those have changed with the addition of a new drive. Using UUID or LABEL
>>> will avoid this problem.
>>
>> Thank you for the prompt reply!
>>
>> In my fstab, all the old drives are specified by UUID.
>> And the new one does not have UUID yet.
>>
>> But it seems that GRUB does not read fstab... :(
>>
>> Where else should I specify them?
>>
>> Do you think that running
>> # grub-mkconfig -o /boot/grub/grub.cfg
>> with a new drive connected will be enough?
>>
>  I edit the /etc/default/grub.

I have already looked into this file but did not find where to set the
UUID of the root partion.

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Willie M]

On 09/06/2016 11:38 AM, gevisz wrote:
> 2016-09-06 21:21 GMT+03:00 Neil Bothwick :
>> On Tue, 6 Sep 2016 21:16:12 +0300, gevisz wrote:
>>
>>> I had one IDE hard drive for /
>>> and one SATA hard drive for /home
>>>
>>> After adding another (yet non-formatted) SATA hard drive
>>> the system panics and complains that it cannot find kernel
>>> (if I understood it correctly :).
>>>
>>> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>>>
>>> Just executed
>>> # grub-mkconfig -o /boot/grub/grub.cfg
>>> but have not tried to reboot yet.
>>>
>>> After disconnecting a new hard drive, the system boot normally.
>>
>> It sounds like you are specifying the root device by device node and
>> those have changed with the addition of a new drive. Using UUID or LABEL
>> will avoid this problem.
> 
> Thank you for the prompt reply!
> 
> In my fstab, all the old drives are specified by UUID.
> And the new one does not have UUID yet.
> 
> But it seems that GRUB does not read fstab... :(
> 
> Where else should I specify them?
> 
> Do you think that running
> # grub-mkconfig -o /boot/grub/grub.cfg
> with a new drive connected will be enough?
> 
 I edit the /etc/default/grub.

-- 

Willie Matthews
matthews.willi...@gmail.com



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 21:24 GMT+03:00 Willie M :
> On 09/06/2016 11:20 AM, gevisz wrote:
>> 2016-09-06 21:16 GMT+03:00 gevisz :
>>> I had one IDE hard drive for /
>>> and one SATA hard drive for /home
>>>
>>> After adding another (yet non-formatted) SATA hard drive
>>> the system panics and complains that it cannot find kernel
>>> (if I understood it correctly :).
>>>
>>> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>>>
>>> Just executed
>>> # grub-mkconfig -o /boot/grub/grub.cfg
>>> but have not tried to reboot yet.
>>>
>>> After disconnecting a new hard drive, the system boot normally.
>>>
>>> Any ideas?
>>
>> P.S. Just forgot to say that everything works fine if I connect the
>>   new SATA drive already after booting the system.
>>
>
> Your /dev/sd* devices are changing when you boot with the new drive most
> likely. Try taking the new drive out and reconfigure your system to boot
> with UUID's for the drives instead of /dev/sda1 or whatever it is in
> your case.

Thank you for the prompt reply but as I have just written to Neil,
in my fstab, all the old drives are specified by UUID.
And the new one does not have UUID yet.

Where else should I specify them?

Do you think that running
# grub-mkconfig -o /boot/grub/grub.cfg
with a new drive connected will be enough?

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 21:21 GMT+03:00 Neil Bothwick :
> On Tue, 6 Sep 2016 21:16:12 +0300, gevisz wrote:
>
>> I had one IDE hard drive for /
>> and one SATA hard drive for /home
>>
>> After adding another (yet non-formatted) SATA hard drive
>> the system panics and complains that it cannot find kernel
>> (if I understood it correctly :).
>>
>> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>>
>> Just executed
>> # grub-mkconfig -o /boot/grub/grub.cfg
>> but have not tried to reboot yet.
>>
>> After disconnecting a new hard drive, the system boot normally.
>
> It sounds like you are specifying the root device by device node and
> those have changed with the addition of a new drive. Using UUID or LABEL
> will avoid this problem.

Thank you for the prompt reply!

In my fstab, all the old drives are specified by UUID.
And the new one does not have UUID yet.

But it seems that GRUB does not read fstab... :(

Where else should I specify them?

Do you think that running
# grub-mkconfig -o /boot/grub/grub.cfg
with a new drive connected will be enough?

Re: [gentoo-user] Re: Kernel does not boot after adding a new SATA drive

[Willie M]

On 09/06/2016 11:20 AM, gevisz wrote:
> 2016-09-06 21:16 GMT+03:00 gevisz :
>> I had one IDE hard drive for /
>> and one SATA hard drive for /home
>>
>> After adding another (yet non-formatted) SATA hard drive
>> the system panics and complains that it cannot find kernel
>> (if I understood it correctly :).
>>
>> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>>
>> Just executed
>> # grub-mkconfig -o /boot/grub/grub.cfg
>> but have not tried to reboot yet.
>>
>> After disconnecting a new hard drive, the system boot normally.
>>
>> Any ideas?
> 
> P.S. Just forgot to say that everything works fine if I connect the
>   new SATA drive already after booting the system.
> 

Your /dev/sd* devices are changing when you boot with the new drive most
likely. Try taking the new drive out and reconfigure your system to boot
with UUID's for the drives instead of /dev/sda1 or whatever it is in
your case.

-- 

Willie Matthews
matthews.willi...@gmail.com
702.659.9966



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[Neil Bothwick]

On Tue, 6 Sep 2016 21:16:12 +0300, gevisz wrote:

> I had one IDE hard drive for /
> and one SATA hard drive for /home
> 
> After adding another (yet non-formatted) SATA hard drive
> the system panics and complains that it cannot find kernel
> (if I understood it correctly :).
> 
> As it happens after the GRUB(2) menu, I suspect GRUB(2).
> 
> Just executed
> # grub-mkconfig -o /boot/grub/grub.cfg
> but have not tried to reboot yet.
> 
> After disconnecting a new hard drive, the system boot normally.

It sounds like you are specifying the root device by device node and
those have changed with the addition of a new drive. Using UUID or LABEL
will avoid this problem.


-- 
Neil Bothwick

And then Adam said, "What's a headache?


pgpZoQi5Ssf2j.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-06 21:16 GMT+03:00 gevisz :
> I had one IDE hard drive for /
> and one SATA hard drive for /home
>
> After adding another (yet non-formatted) SATA hard drive
> the system panics and complains that it cannot find kernel
> (if I understood it correctly :).
>
> As it happens after the GRUB(2) menu, I suspect GRUB(2).
>
> Just executed
> # grub-mkconfig -o /boot/grub/grub.cfg
> but have not tried to reboot yet.
>
> After disconnecting a new hard drive, the system boot normally.
>
> Any ideas?

P.S. Just forgot to say that everything works fine if I connect the
  new SATA drive already after booting the system.

[gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

I had one IDE hard drive for /
and one SATA hard drive for /home

After adding another (yet non-formatted) SATA hard drive
the system panics and complains that it cannot find kernel
(if I understood it correctly :).

As it happens after the GRUB(2) menu, I suspect GRUB(2).

Just executed
# grub-mkconfig -o /boot/grub/grub.cfg
but have not tried to reboot yet.

After disconnecting a new hard drive, the system boot normally.

Any ideas?