LVM Raid1 extend with another Raid 1

General support questions
cameleon
Posts: 6
Joined: 2015/04/05 02:37:58

Re: LVM Raid1 extend with another Raid 1

Post by cameleon » 2015/04/10 02:09:42

Here is what my /etc/default/grub file looks like when I tried it yesturday by adding the 8695... uuid in it.
As you mentioned, I did this in rescue mode by booting with Centos 7 DVD and did a chroot.

Code: Select all

GRUB_TIMEOUT=5
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rd.md.uuid=0aed56dc:e9ec7961:87ec4f7b:1cccf5e7 rd.lvm.lv=vg_cyclone/root rd.md.uuid=8695b6de:f55545e1:c1fefe00:ef4a041f rd.md.uuid=45577c97:0ffee56f:f471ab59:4f9a17ae rd.md.uuid=eb391042:54aa4c5b:37105da4:c7ea36ab rhgb"
GRUB_DISABLE_RECOVERY="true"
I rerun the grub2-mkconfig command.

Code: Select all

grub2-mkconfig -o /boot/grub2/grub.cfg
When I did it yesturday, I did not work.
I retried it today and it works !! :D

Thanks for helping this is really appreciated.

cmurf
Posts: 64
Joined: 2015/02/12 01:31:31

Re: LVM Raid1 extend with another Raid 1

Post by cmurf » 2015/04/10 02:35:40

OK so next thing is to look at /etc/mdadm.conf and follow that format to add in an entry for the new array. You might get a hint with

Code: Select all

grep mdadm /var/log/anaconda/program.log
### This is on Fedora, I'm not exactly sure off hand where the anaconda log is on CentOS.
So if anaconda has use mdadm <some switches> >> /etc/mdadm.conf then you can do the same thing, and then just edit the mdadm.conf to clean it up of any superfluous entry.

Thing is, this mdadm.conf is not available until root mounts. To make it available in the initramfs you have to rebuild it with dracut, and once again that means rescue boot and chroot before issuing dracut.

Really, systemd + mdadm in the initramfs should discover all of these things and assemble them before LVM, even absent mdadm.conf, because the necessary metadata is obviously on the drives already. So I'm not exactly sure why it's not being assembled without all this extra work.

If you want, before doing the above work, but certainly if you do the above work and it still isn't working, you can boot with these added to the (grub.cfg) boot parameter:

Code: Select all

rd.shell rd.debug systemd.log_level=debug
This is extremely verbose, it will slow down the boot process. The first one should get you a prompt instead of an indefinite hang, although I'm not sure how long it waits, maybe up to 5 minutes? And the second is debug logging for dracut's initramfs. And the third is debug logging for systemd.

Once at the prompt, use mount to see if you have something mounted you can write to. If not you can cheat and mount the volume used for /boot, the usual FHS doesn't exist in early boot so you can just mount it on /sysroot, and then:

Code: Select all

journalctl -b -l -o short-monotonic > /sysroot/journal.txt
umount /sysroot
reboot -f
So that gets you a big journal.txt to attach to the thread. And make sure to cleanly unmount before forcing the reboot. I tend to use reboot -f (force) in such cases just to make it faster when everything is already umounted. Buried in this will likely be some details about what it's waiting on and why, the monotonic time is most useful for this as it'll show those big time gaps. An that is a lower case L after the -b.

Post Reply