I made a mistake and added a luks partiton inside a md raid to the crypttab that seems to not be mounted when crypttab is processed.
This md raid does not contain any meaningfull data.
Yet the boot process stops with:
You are in emergency mode. After logging in, type “journalctl -xb” to view system logs “systemctl reboot” to reboot, “systemctl default” or "exit to boot into default mode.
Give root password for maintenance (or press Control-D to continue):
But no matter what I do, providing the actual root password or pressing Control-D, first it shows
Reloading systemmanager configuration
Starting default target
And after a minute and a half I end up with the exact same prompt from above again, but not in the emergency console. There is also no error saying that the password was wrong or anything else helpful.
What can I do now?
You can boot with a live USB,
manjaro-chroot into your system partition, edit the
crypttab file and comment out the entry. Then exit and reboot.
I’m a bit confused about the first part of this post. Is the md raid array where your OS is installed?
yes and no. There are two md raids on the same drive. one is with the root system on it and a new one that has no data yet next to it.
md0 / luks / btrfs = root partiition
md1 / luks / btrfs = new partition with no data.
the md0 is referenced in grub as cryptroot the other I wanted to mount via crypttab.
Before entering md1 into crypttab the root partition booted fine. Now he waits for 90 seconds for md1 to appear and aborts into the loop I mentioned.
I currently have no means to boot into a live cd/usb, but will get a stick later to do what you suggest.
I would start all over. That’s a precarious and inadvisable setup. Arrays work best (and are safest) when they have exclusive use over a physical device. Much can go wrong in the future.
Btrfs natively supports redundancy,
mkfs.btrfs -L myRaidMirror -d raid0 -m raid0 /dev/sdx /dev/sdy
Or if you’re using encryption underneath, which does require multiple containers,
mkfs.btrfs -L myRaidMirror -d raid0 -m raid0 /dev/mapper/cryptosdx /dev/mapper/cryptosdy
That’s my opinion, and you might have reasons for trying your setup. I honestly find it too complex and shaky for comfort.
However, what I said earlier can still be used to do “recovery” steps (i.e, booting into a live USB session and using
manjaro-chroot to enter the system to make modifications to important files.)
Haha, originally it was only one md array. Set up for the root filesystem.
I prefer LUKS as it does not even leak metadata of the file system
I use md raid as then I can have the luks partition on it, requireing to only encrypt once instead of twice. Not sure if this would be possible with btrfs without md. Also I am far more familar with it than with btrfs.
Setting this all up and get it running was quite the task, I rather not repeat it.
Why the second mdraid? Simple. I got a bigger set of drives. I dd’d the data over to the new drives.
First I wanted to extend the existing mdraid, but this seemed to be quite the chore. Instead I just created a new partition and wanted to set up another raid.
This worked fine. But when trying to get it mounted automatically this happend…
I’m in again. Just uncommented the additional cryptroot entry.
This emergency console requires a real emergency console to back it up, if it is that fragile
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.