Martin Wilck [Mon, 9 Oct 2017 12:39:12 +0000 (14:39 +0200)]
emergency.service: use Type=idle
Type=oneshot, as currently set in dracut's emergency service file,
causes an awkward situation if emergency mode is entered e.g. because
of a root device timeout, and the root device appears later because it
just has taken longer than the timeout. In that situation, my
expectation (backed by past positive experience) is that the user should
be able to simply exit the emergency shell and resume normal boot.
:/# systemctl list-jobs
JOB UNIT TYPE STATE
56 emergency.target start waiting
57 emergency.service start running
2 jobs listed.
:/# exit
logout
Failed to start default.target: Transaction is destructive.
(system keeps idling from this point on, user has no chance to
do anything).
This results from the combination of two effects:
1) initrd-root-fs.target sets "OnFailureJobMode=replace-irreversibly",
2) emergency.service's Type=oneshot causes the start jobs for both
emergency.service and emergency.target to persist while the user is in
the emergency shell.
When the shell is exited, systemd tries to isolate "initrd.target"
again, but this fails with "the transaction is destructive" error
because of the still pending jobs.
This patch fixes this by changing the Type of "emergency.service" from
"oneshot" to "idle".
Michal Sekletar [Wed, 27 Sep 2017 11:27:42 +0000 (13:27 +0200)]
systemd: fix setting of timeouts for device units
JobRunningTimeoutSec now affects how long can start jobs for device
units stay in the "running" state. Disabling default job timeout via
JobTimeoutSec=0 doesn't disable running state timeout. We need to set
running state timeout as well.
Note that doing this the other way around has effect on generic timeout,
i.e. disabling running state timeout disables generic timeout. But doing
it this way we would create implicit dependency on fairly new
systemd-234. However, by setting both options we don't create dependency
on specific systemd version.
privb0x23 [Tue, 3 Oct 2017 22:37:55 +0000 (23:37 +0100)]
Add basic LUKS detached header support
A LUKS root volume with a detached header on a device without partitioning will not have a UUID and will not have an attribute ENV{ID_FS_TYPE}=="crypto_LUKS".
Therefore, several areas need to be addressed: identification of the LUKS device, inclusion of entries within crypttab, and provision of the detached header file.
- Added support for an option (4th column: "force") in /etc/crypttab to force the inclusion of the entry in the initramfs version (avoiding the fs type test).
- Added support for an option (4th column: "header=/path/to/file") in /etc/crypttab to provide a path to a detached header file embedded within the initramfs.
- Added ID and PARTUUID support to the device (2nd column) in /etc/crypttab (complementing the existing UUID functionality).
- Added cmdline support to indicate LUKS device ("rd.luks.serial=") that refers to the attribute ENV{ID_SERIAL_SHORT}.
Tested successfully on Void Linux (x86_64 musl) (no systemd) with a LUKS root volume accessed with a keyfile and using a detached header.
Not tested on systemd, or on a LUKS root volume with a passphrase rather than a keyfile.
Xunlei Pang [Mon, 25 Sep 2017 03:18:06 +0000 (11:18 +0800)]
fcoe: handle CNAs with DCB firmware support
Some Combined Network Adapters(CNAs) implement DCB protocol
in firmware, it is recommended that do not run software-based
DCB or LLDP on CNAs that implement DCB, but we have to start
the lldpad service anyway(there might be other software DCB).
If the network interface provides hardware DCB/DCBX capabilities,
the field DCB_REQUIRED in "/etc/fcoe/cfg-xxx" is expected to
be set to "no".
We met an issue on "QLogic BCM57810" with DCB firmware support,
and found dracut still generated "fcoe=<mac>:dcb" which caused
kdump boot failure when using that fcoe dump target.
This patch parses /etc/fcoe/cfg-xxx to detect DCB_REQUIRED="no",
and force "nodcb" if it is the case.
Robert LeBlanc [Thu, 21 Sep 2017 20:33:59 +0000 (14:33 -0600)]
Fix MTU on bond interface.
The MTU is only being set on the slave devices and the MTU of the
bonding master is not being updated. This updates the bonding master and
also changes the MTU on the slaves as expected.
Signed-Off-By: Robert LeBlanc <robert@leblancnet.us>
Prior to this commit, the MTU setting was applied to a bond slave
interface. In older versions of the Linux kernel, this setting
propagated to the bond master and the other bond slaves associated with
the master. In recent versions of the kernel (observed in Linux 4.12),
increasing the MTU of a slave does not automatically increase the MTU of
the master. This allows for more flexibility but requires the MTU of
the master to be changed manually.
Ideally, the MTU setting should be applied to the bond master and the
setting will propagate to the bond slaves, since the slaves are required
to have a MTU that is greater than or equal to the bond master.
Daniel Molkentin [Tue, 29 Aug 2017 06:46:07 +0000 (08:46 +0200)]
Enable core dumps with systemd from initrd
systemd sets /proc/sys/kernel/core_pattern to use systemd-coredump.
However, systemd-coredump is missing from initrd, making dumping
the core in initrd impossible by default.
Ziyue Yang [Wed, 23 Aug 2017 03:23:34 +0000 (11:23 +0800)]
dracut.sh: disable lsinitrd logging when quiet
Currently in Fedora/RedHat dracut installs its fedora.conf.example
as the default config file, in which sysloglvl is set 5. This leads
to maxloglvl=5 in dracut calls, making unnecessary lsinitrd calls
during initramfs builds by kdump.
This patch disables lsinitrd logging when --quiet option is given,
which is controlled by maxloglvl only before. This will speed up
dracut image building as the following if --quiet is used in kdump:
1) Before this patch
$ kdumpctl stop; touch /etc/kdump.conf; time kdumpctl start
kexec: unloaded kdump kernel
Stopping kdump: [OK]
Detected change(s) in the following file(s):
/etc/kdump.conf
Rebuilding /boot/initramfs-4.13.0-0.rc1.git4.1.fc27.x86_64kdump.img
kexec: loaded kdump kernel
Starting kdump: [OK]
real 0m26.824s
user 0m9.958s
sys 0m15.106s
2) After this patch
$ kdumpctl stop; touch /etc/kdump.conf; time kdumpctl start
kexec: unloaded kdump kernel
Stopping kdump: [OK]
Detected change(s) in the following file(s):
/etc/kdump.conf
Rebuilding /boot/initramfs-4.13.0-0.rc1.git4.1.fc27.x86_64kdump.img
kexec: loaded kdump kernel
Starting kdump: [OK]
real 0m20.420s
user 0m8.385s
sys 0m10.468s
Kdump doesn't need default host devices like root, swap, fstab, etc,
we only care about the dump target which can be added via "--mount"
or "--add-device". We met several issues that kdump kernel failed
due to one of those host devices added by dracut, additionally, the
needless devices(e.g. LVM) consume some appreciable amount of memory
which is more likely to cause OOM under memory-limited kdump.
So this patch introduced "--no-hostonly-default-device" to avoid
adding those default devices as host_devs.
Harald Hoyer [Fri, 11 Aug 2017 12:11:32 +0000 (14:11 +0200)]
dracut.spec: add support for builds without dist-tag
In the module-build-service, we have pieces of dracut provided by different
modules ("base-runtime" provides most functionality, but we need
dracut-network in "installer". Since these two modules build with separate
dist-tags, we need to reduce this strict requirement to ignore the dist-tag.
The dracut network module is only supposed to be used for wired interfaces
but if driver modules for wireless devices are wrongly copied, these will
be loaded and the available interfaces brought up.
If the rd.neednet=1 command line parameter is used, dhclient will attempt
to request an IP address for the interfaces and these requests will fail.
But other dracut modules that depend on the network to be settled, will
have to wait for the DHCP requests to timeout. Which can be a lot of time
since the dhclient default timeout value is 60 seconds.
Instead of trying to blacklist all possible kernel modules for wireless
devices, only bring up network interfaces if these are for wired devices.
Suggested-by: Harald Hoyer <harald@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Ankit Kumar [Mon, 7 Aug 2017 06:43:53 +0000 (12:13 +0530)]
Sync initramfs after creation
If we trigger crash just after creating initramfs, sometimes it is
observed that initramfs is not written to disk causing the subsequent
boot to fail. A sync should resolve this.
40network/dhclient.conf: rename classless-routes to classless-static-routes
We tell dhclient to name 121 option "classless-routes",
but in dhclient-script we parse classless_static_routes.
So either have to change the configuration or the script.
And since dhclient uses by default classless_static_routes,
let's change the configuration
Harald Hoyer [Mon, 10 Jul 2017 11:28:40 +0000 (13:28 +0200)]
add 90multipath-hostonly module
hardcoding the wwid of the drives in the initramfs causes problems
when the drives are cloned to a system with the same hardware, but
different disk wwid's
Robert Scheck [Thu, 29 Jun 2017 22:15:57 +0000 (00:15 +0200)]
Add NTFS support to 90dmsquash-live module (#191)
Support booting from USB media with NTFS filesystem (optionally),
which removes the FAT32 related 4 GB file size limit for LiveOS/
squashfs.img (and any other file on the same USB media).
Julian Wolf [Tue, 19 Aug 2014 14:23:59 +0000 (16:23 +0200)]
90crypt: Fixed crypttab_contains() to also work with device path in /etc/crypttab
blkid is not available when this function is called, so block_uuid.map is put into
the initrd, mapping block devices from /etc/crypttab to UUIDs.
This fixes a bug where udev rules were created by mistake as crypttab_contains()
returned false for devices specified by path in /etc/crypttab which resulted in
error messages during boot.