Re: [gentoo-user] SR-IOV on a LSI Broadcom HBA/RAID SAS2008/SAS3008 card
On 10/17/2018 10:37 AM, J. Roeleveld wrote: > The SAS2008 is quite old. Are you sure it actually supports this? It does yes, lspci reports SR-IOV support and the marketing literature touts it along with the SAS 2308 and 3008 etc.
Re: [gentoo-user] systemd/dracut: Correctly boot using flash drive with LUKS key?
On Fri, Nov 16, 2018 at 12:15 PM Andrew Udvare wrote: > > I am not sure if there is a way to move the systemd-cryptsetup@home.service > up the dependency tree once it's working, which would then remove the > mnt-chuan.mount dependency. > Ok, I did a bit more reading. You're using the cryptsetup generator most likely. It sets up units to be oneshot+remainafterexit, which means they're "active" whenever the LUKS device is mounted (without any processes - but they show as active so that you can stop them and unmount the device). It sets the RequiresMountsFor parameter for the device the key file is contained on, which makes that mount service a Required dependency. That means that it can't be unmounted while the cryptsetup device is in use, and in theory attempting to unmount the key file should make systemd attempt to unmount the cryptsetup device (though busy filesystems could interfere with that). I'm not sure if there is a cleaner solution for this without adding some kind of new dependency type to systemd. You really do want that mountpoint to be considered "Required" when the service starts as that file is essential, but you don't need it to stick around after the unit starts. Of course, you don't want it to automatically stop right away either (that would create a race condition between unmounting the key and reading it). This is built-in systemd behavior. I wouldn't be surprised if the folks on the #systemd IRC channel would be interested in talking about this use case and ways to improve it. The fact that they anticipate the key being on a removable mount makes me think it is something they want to support, but it would clearly be more secure to not leave that file mounted all the time. I'd encourage you to ask about it on IRC. If that isn't something you want to do I might inquire about it myself, but I don't want to steal your thunder. -- Rich
Re: [gentoo-user] systemd/dracut: Correctly boot using flash drive with LUKS key?
> On 2018-11-16, at 08:16, Rich Freeman wrote: > > On Fri, Nov 16, 2018 at 12:11 AM Andrew Udvare wrote: >> >> - use key to decrypt root partition (systemd job in the first systemd >> launched within initramfs) >> ... >> Nov 16 00:01:52 limelight systemd[1]: Dependency failed for /mnt/chuan. >> Nov 16 00:01:52 limelight systemd[1]: mnt-chuan.mount: Job >> mnt-chuan.mount/start failed with result 'dependency'. > > So, I haven't messed around that much with systemd and removable > media, but a few things I'd start by looking at: > > systemctl show mnt-chuan.mount > systemctl list-dependencies --reverse --all mnt-chuan.mount So this output seems to make sense, and running systemctl stop on the mount gave me similar messages about dependencies. I"m not sure there is a way around this, as the dependency tree always relies on that mount before systemd-cryptsetup@root can work. If unmounted it will be flagged as in invalid state. I am not sure if there is a way to move the systemd-cryptsetup@home.service up the dependency tree once it's working, which would then remove the mnt-chuan.mount dependency. Tree from the device: dev-disk-by\x2...device ● └─mnt-chuan.mount │ └─... ● ├─systemd-cryptsetup@home.service ● │ ├─dev-disk-by\x2duuid-device │ │ └─... ● │ ├─dev-mapper-home.device ● │ └─cryptsetup.target ● │ └─sysinit.target systemd-cryptsetup@home.service is red. -- Andrew Udvare
Re: [gentoo-user] systemd/dracut: Correctly boot using flash drive with LUKS key?
On Fri, Nov 16, 2018 at 12:11 AM Andrew Udvare wrote: > > - use key to decrypt root partition (systemd job in the first systemd > launched within initramfs) > ... > Nov 16 00:01:52 limelight systemd[1]: Dependency failed for /mnt/chuan. > Nov 16 00:01:52 limelight systemd[1]: mnt-chuan.mount: Job > mnt-chuan.mount/start failed with result 'dependency'. So, I haven't messed around that much with systemd and removable media, but a few things I'd start by looking at: systemctl show mnt-chuan.mount systemctl list-dependencies --reverse --all mnt-chuan.mount I'd have to read up the manpages on how automounting works and what the appropriate flags are in fstab to trigger that. Obviously that is someplace else to check. Clearly you have things set up so that the usb drive is mounted before your script goes and reads the key off of it. If you're doing that in a service and have a dependency on the usb drive (or system somehow figured out that there should be a dependency on it), and that service is left in a running state after the decryption is done, that could be causing issues as systemd thinks that drive is still needed and is desperately trying to get it back. With systemd mountpoints are units, and can be started/stopped like any service and can be dependencies of services. This is usually a good thing, but services tend to be persistent and removable drives tend not to be, so you probably need to use some care when mixing the two. Note that due to generators system will create mount units automatically from fstab and other sources. Usually traditional commands like mount/umount and so on just do the right thing, but if you've inadvertently enabled some kind of automounting logic or systemd believes there is a dependency with another unit then you might be fighting the system. Here is another route you could take. When you want to remove that usb drive, instead of just pulling it out or manually unmounting it, try running: systemctl stop mnt-chuan.mount That is asking systemd to nicely unmount it. If systemd doesn't want to unmount it then it will nicely tell you take a hike, but perhaps the error output will give you some clues as to why. -- Rich
[gentoo-user] Re: Woes with Kernel and Iptables
I wound up solving this myself by painstakingly looking at a kernel of a working machine and getting all of the network-related options to match. Here is the gist of the changes I had to make to the kernel to get this to work: https://gist.github.com/afalko/034966bf72f5da8070d5829c8aac40e4 I followed it up by rebuilding the kernel like so: MAKEOPTS="-j4" make && make modules && make modules_install && make install && make mo dules_prepare && emerge @module-rebuild Hopefully this might help another poor soul who might get stuck on this. -Andrey On Fri, Nov 16, 2018 at 1:34 AM Andrey F. wrote: > > Hi everyone, > > I have a newly provisioned machine and for the life of me, I can't get > iptables working. Here is the error: > > # iptables -L > iptables v1.6.1: can't initialize iptables table `filter': Table does > not exist (do you need to i > nsmod?) > Perhaps iptables or your kernel needs to be upgraded. > > # lsmod > Module Size Used by > ip_tables 24576 0 > > I see the same error after manually modprobing iptable_filter: > > # modprobe iptable_filter > # lsmod > Module Size Used by > iptable_filter 16384 0 > ip_tables 24576 1 iptable_filter > > I've also tried building it into the kernel, with no luck. On the > userspace-side I've went as far is doing a full "emerge -e iptables". > I tried upgrading to iptables-1.8 too. I also tried upgrading kernel > headers to match the version of the kernel I'm currnetly running. > Nothing I do can get it to work. > > # uname -r > 4.18.18 > > Thanks in advance for any suggestions! > -Andrey > > P.S. Below are my related kernel settings. I tried to make them all > built-in, but that didn't work. > > # zcat /proc/config.gz | grep NETF | grep -v XT > CONFIG_NETFILTER=y > CONFIG_NETFILTER_ADVANCED=y > CONFIG_BRIDGE_NETFILTER=y > CONFIG_NETFILTER_INGRESS=y > CONFIG_NETFILTER_NETLINK=y > CONFIG_NETFILTER_FAMILY_BRIDGE=y > CONFIG_NETFILTER_FAMILY_ARP=y > CONFIG_NETFILTER_NETLINK_ACCT=y > CONFIG_NETFILTER_NETLINK_QUEUE=y > CONFIG_NETFILTER_NETLINK_LOG=y > CONFIG_NETFILTER_CONNCOUNT=y > CONFIG_NETFILTER_NETLINK_GLUE_CT=y > CONFIG_NETFILTER_SYNPROXY=y > > # zcat /proc/config.gz | grep IPTA > CONFIG_IP_NF_IPTABLES=m > CONFIG_IP6_NF_IPTABLES=y > > # zcat /proc/config.gz | grep IP_NF > CONFIG_IP_NF_IPTABLES=m > CONFIG_IP_NF_MATCH_AH=m > CONFIG_IP_NF_MATCH_ECN=m > CONFIG_IP_NF_MATCH_RPFILTER=m > CONFIG_IP_NF_MATCH_TTL=m > CONFIG_IP_NF_FILTER=m > CONFIG_IP_NF_TARGET_REJECT=m > CONFIG_IP_NF_TARGET_SYNPROXY=m > CONFIG_IP_NF_NAT=m > CONFIG_IP_NF_TARGET_MASQUERADE=m > CONFIG_IP_NF_TARGET_NETMAP=m > CONFIG_IP_NF_TARGET_REDIRECT=m > CONFIG_IP_NF_MANGLE=m > CONFIG_IP_NF_TARGET_CLUSTERIP=m > CONFIG_IP_NF_TARGET_ECN=m > CONFIG_IP_NF_TARGET_TTL=m > # CONFIG_IP_NF_RAW is not set > CONFIG_IP_NF_SECURITY=m > CONFIG_IP_NF_ARPTABLES=y > CONFIG_IP_NF_ARPFILTER=y > CONFIG_IP_NF_ARP_MANGLE=y
[gentoo-user] Woes with Kernel and Iptables
Hi everyone, I have a newly provisioned machine and for the life of me, I can't get iptables working. Here is the error: # iptables -L iptables v1.6.1: can't initialize iptables table `filter': Table does not exist (do you need to i nsmod?) Perhaps iptables or your kernel needs to be upgraded. # lsmod Module Size Used by ip_tables 24576 0 I see the same error after manually modprobing iptable_filter: # modprobe iptable_filter # lsmod Module Size Used by iptable_filter 16384 0 ip_tables 24576 1 iptable_filter I've also tried building it into the kernel, with no luck. On the userspace-side I've went as far is doing a full "emerge -e iptables". I tried upgrading to iptables-1.8 too. I also tried upgrading kernel headers to match the version of the kernel I'm currnetly running. Nothing I do can get it to work. # uname -r 4.18.18 Thanks in advance for any suggestions! -Andrey P.S. Below are my related kernel settings. I tried to make them all built-in, but that didn't work. # zcat /proc/config.gz | grep NETF | grep -v XT CONFIG_NETFILTER=y CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y CONFIG_NETFILTER_INGRESS=y CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_FAMILY_BRIDGE=y CONFIG_NETFILTER_FAMILY_ARP=y CONFIG_NETFILTER_NETLINK_ACCT=y CONFIG_NETFILTER_NETLINK_QUEUE=y CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_NETFILTER_CONNCOUNT=y CONFIG_NETFILTER_NETLINK_GLUE_CT=y CONFIG_NETFILTER_SYNPROXY=y # zcat /proc/config.gz | grep IPTA CONFIG_IP_NF_IPTABLES=m CONFIG_IP6_NF_IPTABLES=y # zcat /proc/config.gz | grep IP_NF CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_RPFILTER=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_SYNPROXY=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m # CONFIG_IP_NF_RAW is not set CONFIG_IP_NF_SECURITY=m CONFIG_IP_NF_ARPTABLES=y CONFIG_IP_NF_ARPFILTER=y CONFIG_IP_NF_ARP_MANGLE=y
