[gentoo-user] Rebuilding a kernel on a hardened gentoo

[gentoo-user] Rebuilding a kernel on a hardened gentoo

[Stefan G. Weichinger]

I got the job to admin a gentoo server that was configured and setup by 
a former admin.

No surprise that it is outdated ...

It runs with profile "hardened/linux/amd64" and kernel 4.1.15-gentoo-r1

That kernel does not have the necessary flags enabled to support EXT4 
ACLs ...

At first I emerged latest stable gentoo-sources, enabled these flags and 
compiled ... but the lpfc module didn't detect the SAN devices 
correctly, so I switched back to 4.1.15 (mark this as another todo here 
... sooner or later I want a more recent kernel working with lpfc ... I 
have no clue about multipath so far)

-

Right now I always get this when I run "make bzImage" (

# make bzImage
   CHK     include/config/kernel.release
   CHK     include/generated/uapi/linux/version.h
   CHK     include/generated/utsrelease.h
   CC      kernel/bounds.s
kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
  /*

make[1]: *** [Kbuild:44: kernel/bounds.s] Error 1
make: *** [Makefile:990: prepare0] Error 2

Why?
Because the gcc has flags enabled?

I googled but klibc-related stuff doesn't seem to apply here.

I am not insisting on hardened profile but want to avoid bigger issues 
when switching profiles without thinking ...

-

Basically I only need:

CONFIG_EXT4_FS_SECURITY=y
CONFIG_EXT4_FS_POSIX_ACL=y

in my kernel ;-)

But this leads into these new areas of learning ...

greets, Stefan

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Stefan G. Weichinger]

Am 11.09.18 um 11:48 schrieb Stefan G. Weichinger:

> Right now I always get this when I run "make bzImage" (
> 
> # make bzImage
>    CHK     include/config/kernel.release
>    CHK     include/generated/uapi/linux/version.h
>    CHK     include/generated/utsrelease.h
>    CC      kernel/bounds.s
> kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>   /*
> 
> make[1]: *** [Kbuild:44: kernel/bounds.s] Error 1
> make: *** [Makefile:990: prepare0] Error 2
> 
> Why?
> Because the gcc has flags enabled?
> 
> I googled but klibc-related stuff doesn't seem to apply here.
> 
> I am not insisting on hardened profile but want to avoid bigger issues 
> when switching profiles without thinking ...


I managed to compile a 4.9.95 after "make localmodconfig". Maybe that 
would help with the other kernels as well.

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Mick]

[-- Attachment #1: Type: text/plain, Size: 3395 bytes --]

On Tuesday, 11 September 2018 10:48:59 BST Stefan G. Weichinger wrote:
> I got the job to admin a gentoo server that was configured and setup by
> a former admin.
> 
> No surprise that it is outdated ...
> 
> It runs with profile "hardened/linux/amd64" and kernel 4.1.15-gentoo-r1

This is a rather old kernel.


> That kernel does not have the necessary flags enabled to support EXT4
> ACLs ...

Among many other changes that have taken place since that kernel version.


> At first I emerged latest stable gentoo-sources, enabled these flags and
> compiled ... but the lpfc module didn't detect the SAN devices
> correctly, so I switched back to 4.1.15 (mark this as another todo here
> ... sooner or later I want a more recent kernel working with lpfc ... I
> have no clue about multipath so far)
> 
> -
> 
> Right now I always get this when I run "make bzImage" (
> 
> # make bzImage
>    CHK     include/config/kernel.release
>    CHK     include/generated/uapi/linux/version.h
>    CHK     include/generated/utsrelease.h
>    CC      kernel/bounds.s
> kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>   /*
> 
> make[1]: *** [Kbuild:44: kernel/bounds.s] Error 1
> make: *** [Makefile:990: prepare0] Error 2
> 
> Why?
> Because the gcc has flags enabled?

Probably because you need a later version of gcc to compile the newer kernel 
with.


> I am not insisting on hardened profile but want to avoid bigger issues
> when switching profiles without thinking ...
> 
> -
> 
> Basically I only need:
> 
> CONFIG_EXT4_FS_SECURITY=y
> CONFIG_EXT4_FS_POSIX_ACL=y
> 
> in my kernel ;-)

Have you tried to enable these in the current kernel version and while running 
with the same gcc configuration?


> But this leads into these new areas of learning ...
> 
> greets, Stefan

This is how I would approach this task, but it's not a 5 minute effort.

LONG WINDED APPROACH
====================

1. Update your system:

 emerge -uaNDv system

Assuming there are no major blockers which you will need to resolve one at a 
time, update your profile, switch your gcc to a newer version and continue 
with building a newer kernel.

2. Copy the current kernel's .config file to the latest stable.  Change the /
usr/src/linux/ symlink to point to the latest linux kernel source.  Run 'make 
oldconfig' and go through all the changes as required.  Then 'make clean, && 
make && make modules_install' and copy over the bzImage, .config and System 
files of the new kernel to /boot.  Leave the old files in /boot intact.  
Update grub config and reboot.

3. Assuming all went fine, update your @world.

WARNING:  I would NOT try anything like this on a production system, but use a 
cloned fs to do all this work offline.  Once I get something booting 
successfully I would then copy over binary packages and update the production 
system with them.


SHORTER AND RECOMMENDED WAY
===========================

There have been many changes with gcc and gentoo profiles since kernel-4.1.15-
gentoo-r1.  This is why I would recommend you reinstall using a stage 3 for an 
easier life.  Keep your /etc, kernel .config and /var/lib/portage/world files 
from the existing installation, so you have minimal configuration changes to 
perform, following reinstallation.  Also keep the old kernel image in /boot in 
case you struggle getting a newer kernel to boot immediately.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[J. Roeleveld]

On Tuesday, September 11, 2018 11:48:59 AM CEST Stefan G. Weichinger wrote:
> At first I emerged latest stable gentoo-sources, enabled these flags and
> compiled ... but the lpfc module didn't detect the SAN devices
> correctly, so I switched back to 4.1.15 (mark this as another todo here
> ... sooner or later I want a more recent kernel working with lpfc ... I
> have no clue about multipath so far)

I found multipath quite "simple" to implement when following the documentation 
for this.

--
Joost

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Stefan G. Weichinger]

Am 12.09.18 um 08:42 schrieb J. Roeleveld:
> On Tuesday, September 11, 2018 11:48:59 AM CEST Stefan G. Weichinger wrote:
>> At first I emerged latest stable gentoo-sources, enabled these flags and
>> compiled ... but the lpfc module didn't detect the SAN devices
>> correctly, so I switched back to 4.1.15 (mark this as another todo here
>> ... sooner or later I want a more recent kernel working with lpfc ... I
>> have no clue about multipath so far)
> 
> I found multipath quite "simple" to implement when following the documentation
> for this.

*which* documentation, please?

with the newer kernel I got:

[  864.521464] lpfc 0000:02:00.1: 1:1303 Link Up Event x7b received
Data: x7b x0 x20 x0 x0 x0 0
[  868.693743] lpfc 0000:02:00.0: 0:1305 Link Down Event x7c received
Data: x7c x20 x80011 x0 x0
[  869.523664] lpfc 0000:02:00.0: 0:1303 Link Up Event x7d received
Data: x7d x0 x20 x0 x0 x0 0
[  873.691535] lpfc 0000:02:00.1: 1:1305 Link Down Event x7c received
Data: x7c x20 x80011 x0 x0
[  874.521185] lpfc 0000:02:00.1: 1:1303 Link Up Event x7d received
Data: x7d x0 x20 x0 x0 x0 0
[  878.694259] lpfc 0000:02:00.0: 0:1305 Link Down Event x7e received
Data: x7e x20 x80011 x0 x0


and no /dev/sdX created for the relevant LUN (is that the term?)

I see a multipath.conf on the system, will try to understand that.

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Stefan G. Weichinger]

Am 11.09.18 um 12:54 schrieb Mick:

> Probably because you need a later version of gcc to compile the newer kernel
> with.

I already installed gcc-6.4.0 and 7.3.0 some times ago. These should be 
modern enough?

>> CONFIG_EXT4_FS_SECURITY=y
>> CONFIG_EXT4_FS_POSIX_ACL=y
>>
>> in my kernel ;-)
> 
> Have you tried to enable these in the current kernel version and while running
> with the same gcc configuration?

Yes, yesterday that failed as well.
But I was able to compile 4.9.95 with the ext4 flags after a "make 
localmodconfig". Maybe this intermediary step does not "break" lpfc 
behavior.

A reboot test will happen on friday or so.

> LONG WINDED APPROACH
> ====================
> 
> 1. Update your system:
> 
>   emerge -uaNDv system
> 
> Assuming there are no major blockers which you will need to resolve one at a
> time, update your profile, switch your gcc to a newer version and continue
> with building a newer kernel.
> 
> 2. Copy the current kernel's .config file to the latest stable.  Change the /
> usr/src/linux/ symlink to point to the latest linux kernel source.  Run 'make
> oldconfig' and go through all the changes as required.  Then 'make clean, &&
> make && make modules_install' and copy over the bzImage, .config and System
> files of the new kernel to /boot.  Leave the old files in /boot intact.
> Update grub config and reboot.
> 
> 3. Assuming all went fine, update your @world.
> 
> WARNING:  I would NOT try anything like this on a production system, but use a
> cloned fs to do all this work offline.  Once I get something booting
> successfully I would then copy over binary packages and update the production
> system with them.
> 
> 
> SHORTER AND RECOMMENDED WAY
> ===========================
> 
> There have been many changes with gcc and gentoo profiles since kernel-4.1.15-
> gentoo-r1.  This is why I would recommend you reinstall using a stage 3 for an
> easier life.  Keep your /etc, kernel .config and /var/lib/portage/world files
> from the existing installation, so you have minimal configuration changes to
> perform, following reinstallation.  Also keep the old kernel image in /boot in
> case you struggle getting a newer kernel to boot immediately.

Thanks for your suggestions, I will consider preparing a new 
stage3-based VM somewhere.

I went through @world-updates some months ago when I started maintaining 
that server.

Most of the system is updated already but you are right, there are 
always hidden issues ... and I should keep downtime and effort/costs low 
--- as always

As soon as I can update that IPMI module it gets easier to test things ;-)

thanks, Stefan

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Stefan G. Weichinger]

Am 12.09.18 um 09:43 schrieb Stefan G. Weichinger:

> I see a multipath.conf on the system, will try to understand that.

Another thing I just noticed:

seems I have been cautious so far to keep sys-fs/multipath-tools at 
version 0.5.0-r1 from 2016 ....

portage would update to stable 0.6.4-r1

and maybe that would help creating /dev/sdX with a newer kernel as well 
(instead of that flapping as mentioned in my other mail before)

Does anyone have an opinion here?
Seems I can only test by actually trying it ...

(doing a quickpkg now at first)

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Stefan G. Weichinger]

Am 12.09.18 um 10:09 schrieb Stefan G. Weichinger:

> seems I have been cautious so far to keep sys-fs/multipath-tools at 
> version 0.5.0-r1 from 2016 ....
> 
> portage would update to stable 0.6.4-r1
> 
> and maybe that would help creating /dev/sdX with a newer kernel as well 
> (instead of that flapping as mentioned in my other mail before)

and sys-fs/udev-238 might help as well (currently at 225 on that box ...)

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

On Wed, Sep 12, 2018 at 5:59 PM Stefan G. Weichinger <lists@xunil.at> wrote:

> Am 11.09.18 um 12:54 schrieb Mick:
>
> > Probably because you need a later version of gcc to compile the newer
> kernel
> > with.
>
> I already installed gcc-6.4.0 and 7.3.0 some times ago. These should be
> modern enough?
>

Yep "Officially the Linux kernel listed GCC 3.2 as the minimum version of
the GNU compiler needed. However, with Linux 4.19 that is being raised to
GCC 4.6"

https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-Ups-GCC-Build-Req

[-- Attachment #2: Type: text/html, Size: 1028 bytes --]

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[J. Roeleveld]

On September 12, 2018 7:43:12 AM UTC, "Stefan G. Weichinger" <lists@xunil.at> wrote:
>Am 12.09.18 um 08:42 schrieb J. Roeleveld:
>> On Tuesday, September 11, 2018 11:48:59 AM CEST Stefan G. Weichinger
>wrote:
>>> At first I emerged latest stable gentoo-sources, enabled these flags
>and
>>> compiled ... but the lpfc module didn't detect the SAN devices
>>> correctly, so I switched back to 4.1.15 (mark this as another todo
>here
>>> ... sooner or later I want a more recent kernel working with lpfc
>... I
>>> have no clue about multipath so far)
>> 
>> I found multipath quite "simple" to implement when following the
>documentation
>> for this.
>
>*which* documentation, please?
>
>with the newer kernel I got:
>
>[  864.521464] lpfc 0000:02:00.1: 1:1303 Link Up Event x7b received
>Data: x7b x0 x20 x0 x0 x0 0
>[  868.693743] lpfc 0000:02:00.0: 0:1305 Link Down Event x7c received
>Data: x7c x20 x80011 x0 x0
>[  869.523664] lpfc 0000:02:00.0: 0:1303 Link Up Event x7d received
>Data: x7d x0 x20 x0 x0 x0 0
>[  873.691535] lpfc 0000:02:00.1: 1:1305 Link Down Event x7c received
>Data: x7c x20 x80011 x0 x0
>[  874.521185] lpfc 0000:02:00.1: 1:1303 Link Up Event x7d received
>Data: x7d x0 x20 x0 x0 x0 0
>[  878.694259] lpfc 0000:02:00.0: 0:1305 Link Down Event x7e received
>Data: x7e x20 x80011 x0 x0
>
>
>and no /dev/sdX created for the relevant LUN (is that the term?)
>
>I see a multipath.conf on the system, will try to understand that.

Multipath devices end up under /dev/mapper/...

I think it was Redhat who had most decent docs. Will check my bookmarks tonight and give you the full list.

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

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[J. Roeleveld]

On Wednesday, September 12, 2018 2:14:05 PM CEST J. Roeleveld wrote:
> On September 12, 2018 7:43:12 AM UTC, "Stefan G. Weichinger" 
<lists@xunil.at> wrote:
> >Am 12.09.18 um 08:42 schrieb J. Roeleveld:
> >> On Tuesday, September 11, 2018 11:48:59 AM CEST Stefan G. Weichinger
> >
> >wrote:
> >>> At first I emerged latest stable gentoo-sources, enabled these flags
> >
> >and
> >
> >>> compiled ... but the lpfc module didn't detect the SAN devices
> >>> correctly, so I switched back to 4.1.15 (mark this as another todo
> >
> >here
> >
> >>> ... sooner or later I want a more recent kernel working with lpfc
> >
> >... I
> >
> >>> have no clue about multipath so far)
> >> 
> >> I found multipath quite "simple" to implement when following the
> >
> >documentation
> >
> >> for this.
> >
> >*which* documentation, please?
> >
> >with the newer kernel I got:
> >
> >[  864.521464] lpfc 0000:02:00.1: 1:1303 Link Up Event x7b received
> >Data: x7b x0 x20 x0 x0 x0 0
> >[  868.693743] lpfc 0000:02:00.0: 0:1305 Link Down Event x7c received
> >Data: x7c x20 x80011 x0 x0
> >[  869.523664] lpfc 0000:02:00.0: 0:1303 Link Up Event x7d received
> >Data: x7d x0 x20 x0 x0 x0 0
> >[  873.691535] lpfc 0000:02:00.1: 1:1305 Link Down Event x7c received
> >Data: x7c x20 x80011 x0 x0
> >[  874.521185] lpfc 0000:02:00.1: 1:1303 Link Up Event x7d received
> >Data: x7d x0 x20 x0 x0 x0 0
> >[  878.694259] lpfc 0000:02:00.0: 0:1305 Link Down Event x7e received
> >Data: x7e x20 x80011 x0 x0
> >
> >
> >and no /dev/sdX created for the relevant LUN (is that the term?)
> >
> >I see a multipath.conf on the system, will try to understand that.
> 
> Multipath devices end up under /dev/mapper/...
> 
> I think it was Redhat who had most decent docs. Will check my bookmarks
> tonight and give you the full list.

Bit sooner:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/
dm_multipath/mpio_overview

https://www.thegeekdiary.com/beginners-guide-to-device-mapper-dm-multipathing/


I use multipath from a SAS-controller to a dual-backplane and SAS-disks.
From the controller, I have 2 paths to each disk, which means I have twice the 
amount of "sd?" entries.

==
# multipath -l
35000cca25d8ec910 dm-4 HGST,HUS726040ALS210
size=3.6T features='1 retain_attached_hw_handler' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=0 status=active
| `- 0:0:7:0  sdh 8:112  active undef running
`-+- policy='service-time 0' prio=0 status=enabled
  `- 0:0:20:0 sdt 65:48  active undef running
==
(This is only the first device)

It shows that device "35000cca25d8ec910" is mapped to "sdh" and "sdt".
To use the disk correctly, I need to access "/dev/mapper/35000cca25d8ec910", 
which is:
# ls -lsa /dev/mapper/35000cca25d8ec910
0 lrwxrwxrwx 1 root root 7 Sep  4 11:43 /dev/mapper/35000cca25d8ec910 -> ../
dm-4

I have "multipathd" in the "boot" runlevel.

Version info:
# eix -I multipath
[I] sys-fs/multipath-tools
     Available versions:  0.5.0-r1 0.6.4-r1{tbz2} ~0.7.6^t ~0.7.7^t {rbd 
systemd KERNEL="linux"}
     Installed versions:  0.6.4-r1{tbz2}(10:51:01 AM 01/23/2018)(-rbd -
systemd)
     Homepage:            http://christophe.varoqui.free.fr/
     Description:         Device mapper target autoconfig

# uname -a
Linux san1 4.9.76-gentoo-r1-generic #1 SMP Tue Jan 23 12:05:11 CET 2018 x86_64 
Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz GenuineIntel GNU/Linux

As for the terms, a LUN is a Logical disk provided by a SAN to a different 
system. I have multipath inside my SAN and have a single path to iSCSI 
clients. (Single switch with bonded NICs)

--
Joost

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Stefan G. Weichinger]

Am 12.09.18 um 15:07 schrieb J. Roeleveld:

> Bit sooner:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/
> dm_multipath/mpio_overview
> 
> https://www.thegeekdiary.com/beginners-guide-to-device-mapper-dm-multipathing/
> 
> 
> I use multipath from a SAS-controller to a dual-backplane and SAS-disks.
>  From the controller, I have 2 paths to each disk, which means I have twice the
> amount of "sd?" entries.
> 
> ==
> # multipath -l
> 35000cca25d8ec910 dm-4 HGST,HUS726040ALS210
> size=3.6T features='1 retain_attached_hw_handler' hwhandler='0' wp=rw
> |-+- policy='service-time 0' prio=0 status=active
> | `- 0:0:7:0  sdh 8:112  active undef running
> `-+- policy='service-time 0' prio=0 status=enabled
>    `- 0:0:20:0 sdt 65:48  active undef running
> ==
> (This is only the first device)
> 
> It shows that device "35000cca25d8ec910" is mapped to "sdh" and "sdt".
> To use the disk correctly, I need to access "/dev/mapper/35000cca25d8ec910",
> which is:
> # ls -lsa /dev/mapper/35000cca25d8ec910
> 0 lrwxrwxrwx 1 root root 7 Sep  4 11:43 /dev/mapper/35000cca25d8ec910 -> ../
> dm-4
> 
> I have "multipathd" in the "boot" runlevel.
> 
> Version info:
> # eix -I multipath
> [I] sys-fs/multipath-tools
>       Available versions:  0.5.0-r1 0.6.4-r1{tbz2} ~0.7.6^t ~0.7.7^t {rbd
> systemd KERNEL="linux"}
>       Installed versions:  0.6.4-r1{tbz2}(10:51:01 AM 01/23/2018)(-rbd -
> systemd)
>       Homepage:            http://christophe.varoqui.free.fr/
>       Description:         Device mapper target autoconfig
> 
> # uname -a
> Linux san1 4.9.76-gentoo-r1-generic #1 SMP Tue Jan 23 12:05:11 CET 2018 x86_64
> Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz GenuineIntel GNU/Linux
> 
> As for the terms, a LUN is a Logical disk provided by a SAN to a different
> system. I have multipath inside my SAN and have a single path to iSCSI
> clients. (Single switch with bonded NICs)

thanks for the links etc

To me it seems that the former administrator somehow tried to set that 
up but failed.

This corresponds to something he wrote when leaving the company.

There is no multipathd-daemon enabled or running.

# multipath
Sep 14 08:31:10 | MSA2040_SAMBA_storage: ignoring map
Sep 14 08:31:10 | MSA2040_SAMBA_storage: ignoring map

# multipath -l
#

# ls /dev/mapper/
control


so nothing gets mapped here ;-)

-

# /etc/multipath.conf

defaults {
#  udev_dir                /dev
   polling_interval        15
#  selector                "round-robin 0"
   path_grouping_policy    group_by_prio
   failback                5
   path_checker            tur
#  prio_callout            "/sbin/mpath_prio_tpc /dev/%n"
   rr_min_io               100
   rr_weight               uniform
   no_path_retry           queue
   user_friendly_names     yes
}
blacklist {
   devnode cciss
   devnode fd
   devnode hd
   devnode md
   devnode sr
   devnode scd
   devnode st
   devnode ram
   devnode raw
   devnode loop
   devnode sda
   devnode sdb
}

multipaths {
   multipath {
     wwid  3600c0ff0001e91b2c1bae25601000000
     ## To find your wwid, please use /usr/bin/sg_vpd --page=di /dev/DEVICE.
     ## The address will be a 0x6. Remove the 0x and replace it with 3.
     alias MSA2040_SAMBA_storage
   }
}


--- I will check docs etc asap
That is a productive server a few 100 kms away from me, so I have to be 
careful.

Users can work, so no hurry here, just interest.

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[J. Roeleveld]

On September 14, 2018 6:34:20 AM UTC, "Stefan G. Weichinger" <lists@xunil.at> wrote:
>Am 12.09.18 um 15:07 schrieb J. Roeleveld:
>
>> Bit sooner:
>>
>https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/
>> dm_multipath/mpio_overview
>> 
>>
>https://www.thegeekdiary.com/beginners-guide-to-device-mapper-dm-multipathing/
>> 
>> 
>> I use multipath from a SAS-controller to a dual-backplane and
>SAS-disks.
>>  From the controller, I have 2 paths to each disk, which means I have
>twice the
>> amount of "sd?" entries.
>> 
>> ==
>> # multipath -l
>> 35000cca25d8ec910 dm-4 HGST,HUS726040ALS210
>> size=3.6T features='1 retain_attached_hw_handler' hwhandler='0' wp=rw
>> |-+- policy='service-time 0' prio=0 status=active
>> | `- 0:0:7:0  sdh 8:112  active undef running
>> `-+- policy='service-time 0' prio=0 status=enabled
>>    `- 0:0:20:0 sdt 65:48  active undef running
>> ==
>> (This is only the first device)
>> 
>> It shows that device "35000cca25d8ec910" is mapped to "sdh" and
>"sdt".
>> To use the disk correctly, I need to access
>"/dev/mapper/35000cca25d8ec910",
>> which is:
>> # ls -lsa /dev/mapper/35000cca25d8ec910
>> 0 lrwxrwxrwx 1 root root 7 Sep  4 11:43 /dev/mapper/35000cca25d8ec910
>-> ../
>> dm-4
>> 
>> I have "multipathd" in the "boot" runlevel.
>> 
>> Version info:
>> # eix -I multipath
>> [I] sys-fs/multipath-tools
>>       Available versions:  0.5.0-r1 0.6.4-r1{tbz2} ~0.7.6^t ~0.7.7^t
>{rbd
>> systemd KERNEL="linux"}
>>       Installed versions:  0.6.4-r1{tbz2}(10:51:01 AM
>01/23/2018)(-rbd -
>> systemd)
>>       Homepage:            http://christophe.varoqui.free.fr/
>>       Description:         Device mapper target autoconfig
>> 
>> # uname -a
>> Linux san1 4.9.76-gentoo-r1-generic #1 SMP Tue Jan 23 12:05:11 CET
>2018 x86_64
>> Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz GenuineIntel GNU/Linux
>> 
>> As for the terms, a LUN is a Logical disk provided by a SAN to a
>different
>> system. I have multipath inside my SAN and have a single path to
>iSCSI
>> clients. (Single switch with bonded NICs)
>
>thanks for the links etc
>
>To me it seems that the former administrator somehow tried to set that 
>up but failed.
>
>This corresponds to something he wrote when leaving the company.
>
>There is no multipathd-daemon enabled or running.
>
># multipath
>Sep 14 08:31:10 | MSA2040_SAMBA_storage: ignoring map
>Sep 14 08:31:10 | MSA2040_SAMBA_storage: ignoring map
>
># multipath -l
>#
>
># ls /dev/mapper/
>control
>
>
>so nothing gets mapped here ;-)
>
>-
>
># /etc/multipath.conf
>
>defaults {
>#  udev_dir                /dev
>   polling_interval        15
>#  selector                "round-robin 0"
>   path_grouping_policy    group_by_prio
>   failback                5
>   path_checker            tur
>#  prio_callout            "/sbin/mpath_prio_tpc /dev/%n"
>   rr_min_io               100
>   rr_weight               uniform
>   no_path_retry           queue
>   user_friendly_names     yes
>}
>blacklist {
>   devnode cciss
>   devnode fd
>   devnode hd
>   devnode md
>   devnode sr
>   devnode scd
>   devnode st
>   devnode ram
>   devnode raw
>   devnode loop
>   devnode sda
>   devnode sdb
>}
>
>multipaths {
>   multipath {
>     wwid  3600c0ff0001e91b2c1bae25601000000
>## To find your wwid, please use /usr/bin/sg_vpd --page=di /dev/DEVICE.
>     ## The address will be a 0x6. Remove the 0x and replace it with 3.
>     alias MSA2040_SAMBA_storage
>   }
>}
>
>
>--- I will check docs etc asap
>That is a productive server a few 100 kms away from me, so I have to be
>
>careful.
>
>Users can work, so no hurry here, just interest.

You really want to be at the server or at least have some kind of access to the keyboard and screen to coordinate booting to a different environment before enabling multipath.

You need to change all the devices from whatever they are now to the multipath versions, which is best done when booted into a live-environment instead of the actual production one.

The idea is:
Disk(/dev/sd?) - (multipathd) - virtual (/dev/mapper/???) - (filesystem)

If the current system is pointing at /dev/sd?, you are bypassing multipathing.

Also, important and should be obvious, the kernel must have multipath support enabled in de device-mapper section.

I was able to get it all working before doing the rest of the system.
On my system, I didn't have to change the default configuration of multipath as it autodetects which sd?'s are pointing to the same disc due to serial numbers and ZFS is happy to sit on top of that.

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

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Stefan G. Weichinger]

Am 12.09.18 um 10:15 schrieb Stefan G. Weichinger:
> Am 12.09.18 um 10:09 schrieb Stefan G. Weichinger:
> 
>> seems I have been cautious so far to keep sys-fs/multipath-tools at
>> version 0.5.0-r1 from 2016 ....
>>
>> portage would update to stable 0.6.4-r1
>>
>> and maybe that would help creating /dev/sdX with a newer kernel as
>> well (instead of that flapping as mentioned in my other mail before)
> 
> and sys-fs/udev-238 might help as well (currently at 225 on that box ...)

Planning and preparing for a new test tomorrow.

Swapping a kernel isn't that hard as one can keep and chose the old one
again. Updating udev is another thing ;-)

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Stefan G. Weichinger]

Am 07.11.18 um 10:42 schrieb Stefan G. Weichinger:
> Am 12.09.18 um 10:15 schrieb Stefan G. Weichinger:
>> Am 12.09.18 um 10:09 schrieb Stefan G. Weichinger:
>>
>>> seems I have been cautious so far to keep sys-fs/multipath-tools at
>>> version 0.5.0-r1 from 2016 ....
>>>
>>> portage would update to stable 0.6.4-r1
>>>
>>> and maybe that would help creating /dev/sdX with a newer kernel as
>>> well (instead of that flapping as mentioned in my other mail before)
>>
>> and sys-fs/udev-238 might help as well (currently at 225 on that box ...)
> 
> Planning and preparing for a new test tomorrow.
> 
> Swapping a kernel isn't that hard as one can keep and chose the old one
> again. Updating udev is another thing ;-)


https://wiki.gentoo.org/wiki/Udev/Upgrade_Guide

looks as if 225 -> 238 might be no problem at all?

Anyone using lpfc module with some recommendations around?

Re: [gentoo-user] Rebuilding a kernel on a hardened gentoo

[Stefan G. Weichinger]

Am 07.11.18 um 10:45 schrieb Stefan G. Weichinger:
> Am 07.11.18 um 10:42 schrieb Stefan G. Weichinger:
>> Am 12.09.18 um 10:15 schrieb Stefan G. Weichinger:
>>> Am 12.09.18 um 10:09 schrieb Stefan G. Weichinger:
>>>
>>>> seems I have been cautious so far to keep sys-fs/multipath-tools at
>>>> version 0.5.0-r1 from 2016 ....
>>>>
>>>> portage would update to stable 0.6.4-r1
>>>>
>>>> and maybe that would help creating /dev/sdX with a newer kernel as
>>>> well (instead of that flapping as mentioned in my other mail before)
>>>
>>> and sys-fs/udev-238 might help as well (currently at 225 on that box ...)
>>
>> Planning and preparing for a new test tomorrow.
>>
>> Swapping a kernel isn't that hard as one can keep and chose the old one
>> again. Updating udev is another thing ;-)
> 
> 
> https://wiki.gentoo.org/wiki/Udev/Upgrade_Guide
> 
> looks as if 225 -> 238 might be no problem at all?
> 
> Anyone using lpfc module with some recommendations around?

udev upgrade was no problem, new kernel booted as well, but again I saw
the FC flapping up and down and no filesystems coming up there.

So I patched the older kernel and went back ... for now our one issue is
solved (enabling ACLs for the filesystems) but 4.1.15 as kernel isn't
quite up to date.

I wonder if that FC adapter would need a firmware update or so. Too
risky anyway, the server is a few 100 kms away etc etc