2

I spent 6 hours on this and I've given up. I am not finding a method to recovering a /boot partition that was overwritten by an identical /boot partition. This isn't your regular average grub installation problem. This is from hell.

I have 2 systems, A and B. These 2 systems are identical in every way except for UUID's and several files that are particular to the respective systems (e.g., fstab, crypttab, etc). B was a backup of A and both systems were able to boot successfully at one point.

Now B having its /boot overwritten %100 by A, B refuses to boot up and I've tried everything I could possibly come up with that should work (nothing works).

I've --bind mounted /dev/ /dev/pts/ /sys/ /proc/ to a chrooted environment and chrooted into it and updated-grub, purged grub, reinstalled grub, removed kernels, updated kernels, ran update-initramfs -k all -c with other options and other stuff in all sorts of orders, even from scratch. I've ran grub-update from the host using the --directory option and I've even resorted to boot-repair and I've literally done this perhaps a hundred times for 6 hours.

Nothing will get the system back up.

I know this has to be simpler and I'm just having the most terrible luck at figuring it out. What am I doing wrong? Both systems are encrypted using the whole disk encryption from installation.

update it appears at the point during boot where I should be prompted for a password to unlock / the system hangs and then drops to an initramfs prompt. I have no idea and there is no help on how to unlock a cryptsetup disk. I don't have cryptsetup in initramfs :/

closed as unclear what you're asking by Panther, user117103, Eric Carvalho, LiveWireBT, Elder Geek Dec 21 '14 at 4:10

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • You cannot share a /boot with two different installs. And if encrypted then I think you have to have a separate /boot. May be best to see details, but if encrypted, un-encrypt so report shows all the details. help.ubuntu.com/community/Boot-Repair – oldfred Nov 28 '14 at 19:11
  • @oldfred I backed up system A over B but this time overwrote B /boot with A /boot. 99% of the systems are identical but B, no matter what I do refuses to boot. Something about /boot on B I just can't manage to get right. – vbgunz Nov 28 '14 at 19:17
  • @bodhi.zazen don't read, don't answer. – vbgunz Nov 28 '14 at 19:18
-1

I hope this helps anyone that may have come across the same situation. It turns out, after 8+ hours of trying to figure this out, I get some rest and come back and solve it in under 30 minutes. It turns out I was hot on the tail of the answer every time.

From the host system, when I mount the encrypted disk for a backup, I do the following

sudo cryptsetup luksOpen /dev/sdd5 kub # a sneaky kind of wrong

It turns out, the name "kub" screws up everything. What name should it be? Why did I always use kub? The name should be what the encrypted disk name is in /etc/crypttab. I always used "kub" because it always worked for what I needed but it turns out, not when using update-initramfs on a chrooted system and trying to update-grub on it. The correct name in my /etc/crypttab turned out to be sdc5_crypt so

sudo cryptsetup luksOpen /dev/sdd5 sdc5_crypt # wow, the answer

Then after unlocking the disk correctly and making the relevant mounts (/dev/ /sys/ /run/ /dev/pts/ /proc/) I ran the following

sudo update-initramfs -k all -c
sudo update-grub

And the system became bootable. Wow "kub" is like calling someone named Jack, Bobby and Jack never bothers to correct you so you think you're right but it turns out Jack hates you for it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.