Kernel reinstallation via chroot on encrypted sda5

[Bashing-om]

apt2; Welp.

Like I advised originally, with encryption there just may not be a thing that can be done.

But one last stab at this.
What returns from these commands at the grub prompt:

ls
ls (hd0,msdos5)

Appears,

great sercurity

is solidly in-place

[apt2]

"My security is so good I can't even access it WITH the password!!!"


Most recent repair-boot: http://paste.ubuntu.com/7246274/

grub>  ls
(hd0) (hd0,msdos5) (hd0,msdos1) (hd1) (hd1,msdos1)

grub>  ls (hd0,msdos5)
           Partition hd0,msdos5:  No known filesystem detected - Partition starts at 501760 - Total size is 312078336 sectors

[steeldriver]

Let's preface this by stating that I know nothing about encrypted partitions and have never used one

Reading through this from the top, it seems to me that you originally had a separate (non-encrypted) ext2 boot partition at /dev/sda1, and a LUKS container at /dev/sda5, within which was a fairly standard LVM root

You were able to unlock the container with cryptsetup, and got

1. /dev/mapper/de_luks which you tried to mount but couldn't (because it was the unlocked container)
2. /dev/mapper/mint-vg/root (aka /dev/mapper/mint--vg-root) which is the root filesystem (minus /boot, which was on /dev/sda1)

After successfully mounting the root partition, you rebooted - but of course the LUKS container wouldn't stay unencrypted across reboots so you were back to square one.

You say you then deleted /dev/sda1 - not sure how or why

Based on that, how about:

1. boot the live CD again
2. run cryptsetup just like last time, and mount /dev/mapper/mint--vg-root at /mnt/a as before
3. mount /dev/sda1 -t ext2 at /mnt/a/boot
4. do the rest of the usual bind mounts and chroot into the system at /mnt/a
5. reinstall the kernel in the chroot i.e. apt-get update && apt-get install --reinstall linux-image
6. reinstall grub in /dev/sda

Bashing, what say you?

[apt2]

mint / # sudo apt-get install --reinstall linux-image
reading package lists... done
building dependancy tree 
reading state information... done
the following new packages will be installed
    linux image
0 upgraded, 1 newly installed 0 to remove and 1 not upgraded
need to get 1694 b
after 33.8 kb will be used.
get:1 linux-image 9386 3.11.0.19.20
fetched
can not write log, openpty() failed (/dev/pts not mounted?)
selecting previously unselected package linux-image.
(reading database ...
unpacking 
can not write log, openpty() failed (/dev/pts not mounted?)
setting up linux-image (3.11.0.19.20)...
mint / # update-grub /dev/sda
Generating grub.cfg...
found linux image: /boot/vmlinuz-3.11.0-19-generic
found initrd image /boot/initrd.img-3.11.0-19-generic
done
min / #

added information: to answer your question of how/why,I deleted the /dev/sda1(mbr) partition with gpartedEDIT:CFDISK and remade it with gparted, and did boot-repair. I might be so far in my own hole no ladder or rope can save me.

What if I were to completely unencrypt/decrypt the drive, is that possibly an option?

Or looking up some more stuff, possibly boot to sda5 with a usb that has grub installed and has the key attached?

[Bashing-om]

apt2; Hey,

I see good help has arrived .

This, however, might bear further investigation:
Output from your latest boot-repair.

cryptsetup: WARNING: invalid line in /etc/crypttab for luks-fac185e3-6390-42ca-a131-95f0ab1b6fe0 -
which might lead/cause of this output "0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded.".

I see that steeldriver has a handle on that one !

Good deal

when wiser heads prevail

[steeldriver]

Well it didn't actually complain about either the kernel reinstall OR the grub reinstall (just about not being able to write the logs) - which is a pretty good sign I'd say

I'd half expect (hope?) that the system might now boot as far as a 'drive for cryptXXX not ready' type message and offer you the option to fix manually (perhaps by typing in the key, as presumably you would have had to do when you ran cryptsetup?)

[apt2]

Right now it loads the Mint logo (quite slowly)

hangs for a little bit,then:

Giving up waiitng for root device.  Commong problems: 
 - Boot args ( cat /proc/cmdline)
  - check rootdelay=
  - check root
 - missing modules ( cat /proc/modules; ls /dev)
ALERT! /dev/mapper/mint--vg-root does not exist. Dropping to a shell!

BusyBox v1.20.2
enter help for a list of builtin commands

[Bashing-om]

apt2; & steeldriver;

steeldriver:

Bashing, what say you?

response -> Encryption is a level of complexity - from my former glory days with Dec and Nec - that I do not care to get into with linux. I was really hoping for a quick solution without having to deal with the aspect of encryption. After all, it is but a bootloader and all we have to do is direct the bootloader to load a kernel. Tell the bootloader where that kernel is ... um .. is that kernel residing within the encrypted file system ? Most likely . But, how to see ?

@ apt2; all indications are that what is next required is to install that kernel and that from a change root environment. Presently does not look like you have a full chroot.
Show us how you are implementing the change root routine, and we can advise on what is missing and maybe see a way to get it installed.

can not write log, openpty() failed (/dev/pts not mounted?)

However, I say again

where there is a will there is a way -> just looks like it is not going to be easy

[apt2]

mint@mint ~ $ sudo cryptsetup luksOpen /dev/sda5 de_luks
Enter passphrase for /dev/sda5:
mint@mint ~ $ sudo fdisk -l
mint@mint ~ $ sudo mkdir /mnt/a
mint@mint ~ $ sudo mount /dev/mapper/mint--vg-root /mnt/a         #/dev/mint-vg/root  (Logical Volume) has been used as well.
mint@mint ~ $ sudo mount --bind /dev/ /mnt/a/dev
mint@mint ~ $ sudo mount --bind /sys/ /mnt/a/sys
mint@mint ~ $ sudo mount --bind /etc/ /mnt/a/etc
mint@mint ~ $ sudo mount --bind /proc/ /mnt/a/proc
mint@mint ~ $ sudo chroot /mnt/a

#note:  I haven't been mounting /dev/sda1 to /mnt/a/boot.   does it matter if i have been update-grub or grub-install directly to /dev/sda1?  
#I suppose we have to focus on getting sda1 to boot sda5.  No way to boot sda5 by itself.

I mounted /dev/sda1 to mnt/a/boot and mount --bind /etc/pts to mnt/a/etc/pts
did the apt-get install --reinstall linux-image (no errors)                       # should i be using a different linux image? it's 3.11.0.19.20

mint / # update-grub
generating grub.cfg
found linux image: /boot/vmlinuz-3.11.0-19-generic
Found initrd image: /boot/initrd.img-3.11.0-19-generic
done

^See Above^ : This is how I usually have been accessing it, I did try the logical volume route as well. Based on this link's advice: http://pissedoffadmins.com/os/mount-...m2_member.html

[Bashing-om]

apt2; Well,

I would suggest that

sudo mount --bind /dev/pts /mnt/a/dev/pts

be added, also I do not know that networking is enabled in that change root routine,
What returns from within the chroot of terminal command:

ping -c3 8.8.8.8

If there is a good return then try and install the kernel once more;
In the change root environment you are 'root' and elevated privileges are not needed:

apt-get install linux-generic linux-headers-generic linux-image-generic

Meanwhile,

back at the ranch