fstab-sys now also handles device passed by dracut argument "--mount"
The "--mount" mount point is possible not exist in $NEWROOT. Thus mount it
in initramfs if mount point is not exist in real rootfs
It is useful to know that loop device that the live image's / is mounted
from. Make a /run/initramfs/live-baseloop symlink that points to it.
Edited-By: harald@redhat.com: changed /dev/live-baseloop
to /run/initramfs/live-baseloop
Like -H, we need to poll every module to check if it is needed
to mount a specific device in '--mount'.
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
When the initqueue cannot be processed, it might be about an invalid
root device (in which case a separate message produced via
wait_for_dev() should be displayed anyway), but it could also
be for any other reason (e.g. /dev/resume not existing).
Therefore, it is best to use a more generic error message.
Also a minor tab->space conversion in the near vacinity of
the real change.
This commit allows the waiting for a device to be cancelled.
When the resume partition does not exist, it becomes quite hard
to work out what to do (you have to either create the
/dev/resume symlink manually, or remove the 'finished' job
that is waiting for it). Additionally dracut incorrectly
displays a message about not being able to find the root
device, which is bogus and misleading.
This commit should just bail on the whole resume thing
if the device cannot be found and proceed with a normal boot.
This should fix initial initrd generation during install.
If the modules are not desired to be used, the nokmsboot kernel
command line should disable them.
--add-fstab [FILE] Add file to the initramfs fstab
--mount "[DEV] [MP] [FSTYPE] [FSOPTS]"
Mount device [DEV] on mountpoint [MP] with filesystem
[FSTYPE] and options [FSOPTS] in the initramfs
inst_mount_hook <mountpoint> <prio> <name> <script>
Install a mount hook with priority <prio>,
which executes <script> as soon as <mountpoint> is mounted.
add_mount_point <dev> <mountpoint> <filesystem> <fsopts>
Mount <dev> on <mountpoint> with <filesystem> and <fsopts>
and call any mount hooks, as soon, as it is mounted
Unlike "ifconfig", the "ip" command does not set a broadcast address
unless explicitly requested.
add "brd +" to make "ip" calculate the broadcast address on the fly
To start bnx2fc, we need to run fipvlan only and not dcbtool. DCBX is run
automatically in the hardware, but VLAN discovery needs to be started by
fipvlan.
https://bugzilla.redhat.com/show_bug.cgi?id=736094
The dm module, which lvm and dmraid depend on, installed dmraid
shared libs. The lvm module installed udev rules, which were
already installed by the dm module.
Cleaned up those issues.
The kernel's primary console device is determined by the last "console="
argument on the kernel command line. This setting should be respected by
dracut-generated initial RAM disks.
Steps to Reproduce:
(Easiest using a KVM VM, virt-manager and "virsh console")
1. Boot with a kernel command line ending in
console=tty0 console=ttyS0,115200
2. Observe both tty0 and ttyS0.
The output of init scripts is sent to ttyS0, as the final "console="
argument determines the primary console device as per
Documentation/serial-console.txt in the kernel sources.
https://bugzilla.redhat.com/show_bug.cgi?id=752073
The Xen module is unnecessary and it has been for a while.
Most Xen systems will not be using the module, even now, because
xen-detect is not installed by default on most Xen systems, and
dracut uses xen-detect to decide whether to include the module.
It also has some problems:
1) it does not try loading xen_platform_pci;
2) it loads modules unnecessarily; modules.alias is where all Xen support
should reside. Assuming xenbus_probe_frontend and xen_platform_pci
are loaded so that Xen devices are probed, other modules are picked up
automatically thanks to aliases such as
alias xen:vbd xen_blkfront
3) Even not-so-recent kernels (say 2.6.32) require the xen_platform_pci
and xenbus_probe_frontend modules even for non-paravirtualized guests.
60xen/module-setup.sh picks the module only for PV guests.
So, just require xenbus_probe_frontend to be builtin, and also
xen_platform_pci for fully-virtualized guests, and remove the module.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- in 10i18n - do stty -iutf8 on non-utf8 consoles, for consistency with
iutf8 on utf8 ones
- vim modeline in xml file
Signed-off-by: Michal Soltys <soltys@ziu.info>
This is from the following thread:
http://thread.gmane.org/gmane.linux.raid/35753/focus=35795
Additional tests + more specific info.
Signed-off-by: Michal Soltys <soltys@ziu.info>
[harald@redhat.com: usable_root(): relaxed check for root]
The "read" shell builtin consumes backslashes, which is a problem if
your root device is something like "LABEL=Fedora\x2016".
Using "read -r" tells the shell to leave backslashes alone.
This patch replaces:
- {var}>... redirections with functionally identical eval construct +
explicit FDs
- ^^ and ,, case modifiers with temporary shopt
This allows us to lower minimum required bash version
to at least 3.1 (with current code).
Signed-off-by: Michal Soltys <soltys@ziu.info>
in dracut.conf:
fscks="<tools>"
nofscks="yes"
and similary on command line:
--fscks [LIST] (in addition to conf's, if defined there)
--nofscks
Signed-off-by: Michal Soltys <soltys@ziu.info>
Filtering modules requires enough work that instmods() in the
next pipeline stage was rarely busy. Parallelize the two
filters which do the most work. Also fix a filename-vs-contents
mistake in net_module_filter.
--
John Reiser, jreiser@BitWagon.com
>From f4533a2ceca52c443ddebec01eeaa35d51c39c1b Mon Sep 17 00:00:00 2001
From: John Reiser <jreiser@BitWagon.com>
Date: Tue, 13 Sep 2011 17:41:43 -0700
Subject: [PATCH 1/3] Parallelize block_module_filter
ID_FS_TYPE can be much more than just ddf/imsm/linux raid member, so
do the proper checks.
This reverts certain changes from:
cf5891424e
Signed-off-by: Michal Soltys <soltys@ziu.info>
Whitespace removal in:
out="${out}${chop# }$r"
will damage certain strings, for example the following call:
str_replace ' aax aaxaa' x y
would return 'aayaayaa' instead of ' aay aayaa'.
Signed-off-by: Michal Soltys <soltys@ziu.info>
Reworked the flow of the rules file a bit, removed redundant tests, also
should be easier to follow. It's much shorter now as well, a bit more
similar to 90lvm script - both revolve around same concepts after all.
There's no reason to treat conf-assembled arrays differently from
incremental ones. Once we hit timeout in init's udev loop, we can use
common script (mdraid_start.sh) to try force inactive arrays
into degraded mode.
md-finished.sh was kind-of out of place - it didn't really wait for any
particular device(s) to show up, just watched if onetime mdadm scripts
are still in place. Furthermore, after moving mdraid_start to --timeout
initqueue, it didn't really have too much to watch at all, besides
mdadm_auto (and that served no purpose, as we do wait for concrete
devices).
Either way, with stock 64-md fixes, current version of 65-md*.rules does
the following:
- limits assembly to certain uuids, if specified
- watch for no ddf/imsm
- if mdadm.conf => setup onetime -As script, without forced --run option
- if !mdadm.conf => incrementally assemble
- for both cases, setup timeout script, run-forcing arrays as a last resort
Signed-off-by: Michal Soltys <soltys@ziu.info>
1) mdadm -As --auto=yes --run 2>&1 | vinfo (removed)
Currently such auto assembly will not complete or force-run partially
assembled arrays. It might assemble "concurrent" separate array and
force-run it, if possible (though the chances of suddenly showing
missing components in this scenario - a script run after udev timeout -
are pretty thin). See [1] for details. Also see #3 below.
2) mdadm -Is --run 2>&1 (removed)
This will only force-run native arrays - arrays in containers will not
be affected. See [1] for details. Also see #3 below.
3) mdadm -R run loop (implicitly handles #1 & #2)
This loop does everywthing that #1 & #2 are expected to do. Thus, the
above invocations are simply redundant and this is the most safe and
flexible option.
Also, it shouldn't be necessary to go under md/ directory, as those are
just symlinks to /dev/md[0-9]*.
Certain checks were changed to strict ones (array state, degraded state)
instead of relying on env tricks.
'cat' was added explicitly to installed programs (it has been used
implicitly in shutdown script either way)
4) mdmon bug
See [1] for details as well. In short - force-run arrays in containers
will not have mdmon started, so we do that manually.
5) stop/run queue magic
Also removed. mdadm -R will only cause change events to the array
itself, and they should not be an issue.
[1] http://article.gmane.org/gmane.linux.raid/35133
Signed-off-by: Michal Soltys <soltys@ziu.info>
Stop both arrays (first pass) and containers (second pass).
Loop only over /dev/md[0-9]*
Call cleanup script only once, make sure it's after crypt cleanup.
Signed-off-by: Michal Soltys <soltys@ziu.info>
Remove whole "start a container logic".
Containers once assembled, always remain in 'inactive' state.
Any attempt to run a container with mdadm -IR is a no-op, and any
attempt with just mdadm -R ends with an error.
Signed-off-by: Michal Soltys <soltys@ziu.info>
Currently shipped mdadm rules incrementally assemble all imsm and native
raids, and do so unconditionally. This causes few issues:
- fine-grained controls in 65-md* are shadowed - for example,
mdadm.conf's presence tests or uuid checks
- 90dmraid might also conflict with 90mdraid, if user prefers the former
to handle containers
- possibly other subtle issues
This patch adjusts the behaviour.
Signed-off-by: Michal Soltys <soltys@ziu.info>
Use bash "[[ string =~ pattern ]]" instead of "egrep -q".
Replace control-dominated serial fondling
for var in $(proc1); do proc2 var; done
with data-dominated parallel pipeline
proc1 | while read var; do proc2 var; done
Together this is a large savings.
[harald@redhat.com: fixed network kernel module filter]
Harald Hoyer