| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
1) This didn't do anything useful prior to rsyslog, as sysklogd would reset it.
2) This overrides the kernel commandline, for people who want to temporarily reset it there
3) This actually turns messages back on out from underneath plymouth, which isn't nice.
To frob the console loglevel, pass it on the kernel command line.
|
| |
|
|
|
|
|
|
| |
It cannot work reliably as done in this way. (It's possible to do
surgery to do it in plymouth itself, but not here.)
Interactive startup via the 'confirm' commandline option is still
available.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It's not just init that could be mislabeled and cause problems;
there's udev, random other command from rc.sysinit, etc. Furthermore,
this avoids a problem with ending up in permissive mode.
|
| | |
|
| | |
|
| |
|
|
| |
Conflict with older mdadm to make sure we're in sync.
|
| | |
|
| |
|
|
|
|
| |
In future dmraid versions, all the errors ('no raid disks', etc.)
will return proper error codes, so we can dispense with the string
checks as well.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
<mschmidt@redhat.com>)
|
| |
|
|
| |
<hdegoede@redhat.com>)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
1) pam_console is doing it wrong. Use udev's acl support.
2) exactly what are we resetting for dynamically created udev devices?
|
| |
|
|
| |
<wtogami@redhat.com>)
|
| |
|
|
| |
Adapted from <victor.lowther@gmail.com>.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We need to wait for scans to finish for mdadm & LVM to work (and heck,
even fsck). Note that this won't necessarily fix USB, as it has an
asyncrhonous delay even before it starts scanning.
|
| |
|
|
|
| |
This reverts commit 67e59d33e57d4c8feba356320bead2451cbb921b.
This reverts commit fcc54b6f014c63b64e37b0d63d871f344385da84.
|
| |
|
|
|
| |
If you have multiple addresses that resolve to different things, it will
still be unpredictable. In which case... set your hostname yourself.
|
| |
|
|
| |
<vladis.kletnieks@vt.edu>)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been doing a lot of work on mkinitrd's dmraid support lately some of the
lessons learned there also apply to the activation of (not used for /) dmraid
arrays in rc.sysinit, this will esp. help the livecd proerly activating and
using dmraid sets.
The patch fixes the following issues:
1) rc.sysinit (and mkinitrd used to) calls dm_resolve_name() on the output of
dmraid, this is not necessary as dm_resolve_name is only needed when the name
is /dev/dm-#, it is actually harmful as dm_resolve_name sometimes fails when
used like this, causing us to fail to activate dmraid sets
2) rc.sysinit does not remove the partitions from the raw disks used in a
raidset the initrd used to use special nash functionality to tell the kernels
to forget about the partitions of the raw disks it had scanned at boot. The
issue here is, say we have a mirror of sda and sdb, and that mirror has 2
partitions. Then the kernel when scanning the raw disks will find
sda1,sda2,sdb1,sdb2. But we do not want anything using those, they should use
the devicemapper versions as those are mirrored! I've even seen mounting by
LABEL / UUID do the wrong thing by using the raw partitions instead of the
raidset partitions.
I've recently done a patch to dmraid adding a --rm_partitions cmdline option
which makes dmraid do the ioctl which makes the kernel forget about the
partitions of the rawdisk (which in turn makes udev remove the device nodes).
This way we no longer need the nash magic.
Part of my rc.sysinit patch is adding --rm_partitions to the dmraid invocation
3) rc.sysinit uses dmraid -p, which tells dmraid to not setup device maps for
the partitions of the raidset and then kalls kpartx to setup the device maps
for the partitions. This can be simplified by removing the -p argument to
dmraid
4) with all these changes in place there is no longer a reason to loop, a
single dmraid invocation is enough.
p.s.
AFAIK with this patch the last user of dm_resolve_name is gone, so that
function can be removed. Better check twice though.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Notably, it prioritizes RAID/DM/LVM, etc. over the underlying block
devices. Given that initial RAID0 members share a UUID with the RAID
device itself, we need that.
|
| |
|
|
|
|
|
| |
<wwoods@redhat.com>)
Also, do some manipulation of the device name to (hopefully) handle things
like /dev/cciss/c0d0p1, and other devices with nested /dev hierarchies.
|
| |
|
|
| |
Checking whether or not it's a block device already covers that.
|
| |
|
|
| |
It's possible the initrd set the device up under a different LUKS name.
|
| | |
|
| |
|
|
| |
This reverts commit 2c55e1c2d7f4ee82aa0af9bfebfee889236c56bf.
|
| |\ |
|
| | |
| |
| |
| | |
cryptsetup should do this, by all rights. But it does not.
|
| |/
|
|
|
|
|
| |
We do need to explicitly load dm-mod for older kernels, because the
various tools won't necessarily do it. *sigh*
Reverts a chunk of 2285e2f27e1f9dce216a8b8791bd4f4237bdff80.
|
| |
|
|
|
| |
1) Loading dm-mirror, or dm-crypt, or whatever, will load it anyway.
2) We have udev. It creates device nodes. Why are we doing it by hand?
|
