Peter Robinson [Thu, 23 Mar 2017 14:59:15 +0000 (14:59 +0000)]
Add check for aarch64 to the arm kernel module list
This adds the same list of drivers we use for arm platforms for
aarch64 too, also add the DMA drivers there too as they can add
sigficant performance for some storage/usb and often need to be
present when the storage drivers load.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Frederick Grose [Thu, 9 Mar 2017 18:02:58 +0000 (13:02 -0500)]
dmsquash-live-root: Provide enhanced feedback on missing overlay.
Provide a more prominent alert to the user if an overlay is
missing or the overlay module is not available and a temporary
overlay will be provided. This, to avoid losing data intended to
persist.
Frederick Grose [Wed, 1 Feb 2017 05:07:15 +0000 (00:07 -0500)]
Enable the use of the OverlayFS for the LiveOS root filesystem.
Integrate the option to use an OverlayFS as the root filesystem
into the 90dmsquash-live module for testing purposes.
The rd.live.overlay.overlayfs option allows one to request an
OverlayFS overlay. If a persistent overlay is detected at the
standard LiveOS path, the overlay & type detected will be used.
Tested primarily with transient, in-RAM overlay boots on vfat-
formatted Live USB devices, with persistent overlay directories
on ext4-formatted Live USB devices, and with embedded, persistent
overlay directories on vfat-formatted devices. (Persistent overlay
directories on a vfat-formatted device must be in an embedded
filesystem that supports the creation of trusted.* extended
attributes, and must provide valid d_type in readdir responses.)
The rd.live.overlay.readonly option, which allows a persistent
overlayfs to be mounted read only through a higher level transient
overlay directory, has been implemented through the multiple lower
layers feature of OverlayFS.
The default transient DM overlay size has been adjusted up to 32 GiB.
This change supports comparison of transient Device-mapper vs.
transient OverlayFS overlay performance. A transient DM overlay
is a sparse file in memory, so this setting does not consume more
RAM for legacy applications. It does permit a user to use all of
the available root filesystem storage, and fails gently when it is
consumed, as the available free root filesystem storage on a typical
LiveOS build is only a few GiB. Thus, when booted on other-
than-small RAM systems, the transient DM overlay should not overflow.
OverlayFS offers the potential to use all of the available free RAM
or all of the available free disc storage (on non-vfat-devices)
in its overlay, even beyond the root filesystem available space,
because the OverlayFS root filesystem is a union of directories on
two different partitions.
This patch also cleans up some message spew at shutdown, shortens
the execution path in a couple of places, and uses persistent
DM targets where required.
Lukas Nykryn [Tue, 7 Feb 2017 16:09:41 +0000 (17:09 +0100)]
network/ifup: write override file before dhcp_do
Commit cf376023e6d0d4abd9816fa954bb917fc2557713 moved writing .resolv.conf and .override
after dhcp_do, because dhcp_do was overwriting .resolv.conf. But .override does not have
such problem and on the contrary dhcp_do reads .override file if it is present. So let\'s
move it back.
Harald Hoyer [Thu, 8 Dec 2016 16:53:40 +0000 (17:53 +0100)]
dracut.sh: add default path for --uefi
The default output filename for --uefi is
<EFI>/EFI/Linux/linux-$kernel$-<MACHINE_ID>-<BUILD_ID>.efi.
<EFI> might be /efi, /boot or /boot/efi depending on where the ESP partition
is mounted. The <BUILD_ID> is taken from BUILD_ID in /usr/lib/os-release or
if it exists /etc/os-release and is left out, if BUILD_ID is non-existant or
empty.
Also a new option --no-machineid was added, which affects the default output
filename of --uefi and will discard the <MACHINE_ID> part.
Some docs claimed that values in certain config files would be
overwritten, when they would actually be overridden.
Override: a file is not modified but its contents are superseded by
something else. (configurations set in
/etc/dracut.conf.d/*.conf override configurations set in
/etc/dracut.conf)
Overwrite: a file is modified or its contents replaced by an action
(use dracut --force to overwrite the existing initramfs)
Lidong Zhong [Fri, 2 Dec 2016 06:32:09 +0000 (14:32 +0800)]
man: make the -k option clear using mkinitrd
For example under x86, someone maybe missunderstand that the vmlinuz
is the link /boot/vmlinuz points to a specific kernel image and use
the following command directly.
Tong Li [Wed, 30 Nov 2016 09:05:57 +0000 (17:05 +0800)]
95ssh-client: attempt to copy UserKnownHostsFile to kdump's initramfs
Bug related to this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1360131
Now dracut only attempts to copy GlobalKnownHostsFile while generating kdump's
initramfs. This method will cause kdump's failure if users set customized
UserKnownHostsFile in /etc/ssh/ssh_config. This patch simply attempts to copy
those files too while going through /etc/ssh/ssh_config. Note that we need to
make sure ~/foo will be copied as /root/foo in kdump's initramfs.
Xunlei Pang [Thu, 3 Nov 2016 11:30:41 +0000 (19:30 +0800)]
99base: add memtrace-ko.sh to debug kernel module large memory consumption
The current method for memory debug is to use "rd.memdebug=[0-3]",
it is not enough for debugging kernel modules. For example, when we
want to find out which kernel module consumes a large amount of memory,
"rd.memdebug=[0-3]" won't help too much.
A better way is needed to achieve this requirement, this is useful for
kdump OOM debugging.
The principle of this patch is to use kernel trace to track slab and
buddy allocation calls during kernel module loading(module_init), thus
we can analyze all the trace data and get the total memory consumption.
As for large slab allocation, it will probably fall into buddy allocation,
thus tracing "mm_page_alloc" alone should be enough for the purpose(this
saves quite some trace buffer memory, also large free is quite unlikey
during module loading, we neglect those memory free events).
The trace events include memory calls under "tracing/events/":
kmem/mm_page_alloc
We also inpect the following events to detect the module loading:
module/module_load
module/module_put
Since we use filters to trace events, the final trace data size won't
be too big. Users can adjust the trace buffer size via "trace_buf_size"
kernel boot command line as needed.
We can get the module name and task pid from "module_load" event which
also mark the beginning of the loading, and module_put called by the
same task pid implies the end of the loading. So the memory events
recorded in between by the same task pid are consumed by this module
during loading(i.e. modprobe or module_init()).
With these information, we can record the rough total memory(the larger,
the more precise the result will be) consumption involved by each kernel
module loading.
Thus we introduce this shell script to find out which kernel module
consumes a large amount of memory during loading. Use "rd.memdebug=4"
as the tigger.
After applying this patch and specifying "rd.memdebug=4", during booting
it will print out something extra like below:
0 pages consumed by "pata_acpi"
0 pages consumed by "ata_generic"
1 pages consumed by "drm"
0 pages consumed by "ttm"
0 pages consumed by "drm_kms_helper"
835 pages consumed by "qxl"
0 pages consumed by "mii"
6 pages consumed by "8139cp"
0 pages consumed by "virtio"
0 pages consumed by "virtio_ring"
9 pages consumed by "virtio_pci"
1 pages consumed by "8139too"
0 pages consumed by "serio_raw"
0 pages consumed by "crc32c_intel"
199 pages consumed by "virtio_console"
0 pages consumed by "libcrc32c"
9 pages consumed by "xfs"
From the print, we see clearly that "qxl" consumed the most memory.
This file will be installed as a separate executable named "tracekomem"
in the following patch.
Daniel Molkentin [Thu, 17 Nov 2016 10:22:48 +0000 (11:22 +0100)]
Add md4 and arc4 modules for ntlm
Some crashkernel targets still use legacy NTLM auth, which
require those (bsc#869496). This patch enumerates all dependent
hash algorithems, because even though most of them are probably
compiled in, older ones (e.g. md4 and arc4) usually aren't.
Daniel Molkentin [Tue, 15 Nov 2016 10:51:01 +0000 (11:51 +0100)]
Always try to add pinctrl-cherryview
Contrary to previous intel pinctrl drivers, the cherryview driver can be
and usually is built as a module. However, it sets up the SDIO pinout
so sdhci can make use of the SD card reader, which may subsequently
hold a root file system on a card (bsc#998440).
projects / thirdparty / dracut.git / log
