Quote:
Originally Posted by yancek
Because you're using one of the Ubuntu's. Many Linux distributions doing a kernel update will automatically remove older kernels so that you never have more than 2-3 kernels. I think the most recent version of Ubuntu now does this but previously did not and I have seen posts on the Ubuntu forums with users having 30+ kernels!! Simply deleting the kernels is not the proper procedure. I'm not an Ubuntu user but you should have no problem finding the proper method with a simple online search.
Grub is still on version 2 so I think you are confusing Grub version with the kernel version. The numbers above would be appropriate for a kernel. I'm not sure what you are referring to when you say you removed triplicated grub files??
|
Yeah what I meant was that the GRUB boot loader, has the lines of code in it that referenced the different kernels.
And the GRUB tripplets I was referring too, were like this:
In the /boot/grub/Grub.cfg file are these entries:
menuentry 'Ubuntu, with Linux 3.2.0-68-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-68-generic-advanced-f74c948f-bb45-4c82-8d43-7fe0b28a28bc' {
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 f74c948f-bb45-4c82-8d43-7fe0b28a28bc
else
search --no-floppy --fs-uuid --set=root f74c948f-bb45-4c82-8d43-7fe0b28a28bc
fi
echo 'Loading Linux 3.2.0-68-generic ...'
linux /boot/vmlinuz-3.2.0-68-generic root=UUID=f74c948f-bb45-4c82-8d43-7fe0b28a28bc ro quiet splash $vt_handoff
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-68-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-68-generic (upstart)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-68-generic-init-upstart-f74c948f-bb45-4c82-8d43-7fe0b28a28bc' {
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 f74c948f-bb45-4c82-8d43-7fe0b28a28bc
else
search --no-floppy --fs-uuid --set=root f74c948f-bb45-4c82-8d43-7fe0b28a28bc
fi
echo 'Loading Linux 3.2.0-68-generic ...'
linux /boot/vmlinuz-3.2.0-68-generic root=UUID=f74c948f-bb45-4c82-8d43-7fe0b28a28bc ro quiet splash $vt_handoff init=/sbin/upstart
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-68-generic
}
menuentry 'Ubuntu, with Linux 3.2.0-68-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.2.0-68-generic-recovery-f74c948f-bb45-4c82-8d43-7fe0b28a28bc' {
recordfail
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 f74c948f-bb45-4c82-8d43-7fe0b28a28bc
else
search --no-floppy --fs-uuid --set=root f74c948f-bb45-4c82-8d43-7fe0b28a28bc
fi
echo 'Loading Linux 3.2.0-68-generic ...'
linux /boot/vmlinuz-3.2.0-68-generic root=UUID=f74c948f-bb45-4c82-8d43-7fe0b28a28bc ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-68-generic
}
And in the BOOT folder, are these files:
abi-3.2.0-68-generic
config-3.2.0-68-generic
initrd.img-3.2.0-68-generic
System.map-3.2.0-68-generic
vmlinuz-3.2.0-68-generic
During an earlier /boot space making exercise, I had deleted the earliest 3.XXX series, and left in the later 3.XXX series kernels.
However, during the last bout of /boot space making, I deleted the latter 3.XXX series of kernels and just left the 4.XXX series kernels in the /boot folder.
But it was the 3.1 / 3.2 kernel set, that was referenced in GRUB, that was the boot up sequence.
And this is the exact nature of the problem.
I could use a 3.1 or 3.2 USB boot stick (with persistence) to boot up from - SO OK I can do that and then see what happens.
So rather than speculate, I ought to do it.
but to speculate, there is the issue of essentially getting the enter the code to boot into the encrypted file system with (not recovery passphrase), and the matching key in the LUKS encryption system.
I don't know about this. Maybe I should just go and find out.
If it works, then come back and report the success, if not, then come back and research the LUKS issue further.
I do believe I have the passphrase written down somewhere, and it's safely stashed away ??????
Maybe I should get off my arse and go look for that as well.
Will be back within 12 hours.
