I have (had) Lubuntu 16.04 installed on an SSD. I tried Lubuntu 18.04 from a pendrive, and then decided to install it alongside 16.04, on an internal HDD, to allow further testing.
I selected 'other' as installation type.
I created a new partition table for /dev/sda (the HDD) as follows:
- swap 40gb
- / ext4 30 gb
- /home ext4 rest of HDD (~3.5 tb)
I asked for efi on sda (the HDD), believing this would ensure the OS installed on sda. I was a bit worried about this because there is also efi on the SSD and I was not sure if I should use that instead.
The system warned that it would nuke drives, but it only listed partitions on sda. The system now boots directly into 18.04 on the HDD. My old filesystem on the SSD is still there - I can see the drive in the 'places' view of PCManFM and the files and directories are still intact. I also see an option to boot into 16.04 on the boot menu, and this starts to boot something, but it remains in a loop printing 'Lubuntu wait dots'.
Is there any way I can restore booting into the SSD ?
Edits requested by Tudor
I tried ESC whilst booting '16.04 (on /dev/mapper/lubuntu--vg-root)', offered by Grub menu. At first this did not work, but I later discovered pressing ESC earlier put the machine in 'emergency mode'. After a while it produced some output:
device [8086:6f07] error status/mask=00000080/00002000
Bad DLLP
PCIe Bus Error: severity=corrected, type=Data Link Layer, id=0013(Receiver ID)
This was repeated.
I looked at the code behind the options on the GRUB menu. It is pretty lengthy, but I got the impression that they are all trying to boot something off sda.
I went into the BIOS to see what is offered. I was surprised to see that all the boot options are actually on the SSD:
- ubuntu (Samsung SSD 960 Pro)
- ubuntu (Samsung SSD 960 Pro)
- UEFI OS (Samsung SSD 960 Pro)
I booted 18.04 and used the disks tool to see which partitions exist:
- 512 Gb disk Samsung SSD 960 Pro 512GB
- 4.0 TB Hard Disk Toshiba HDWE140
- 477 GB Block Device /dev/lubuntu-vg/root
- 34 GB Block Device /dev/lubuntu-vg/swap_1
I looked at the partitions on the SSD and HDD in more detail:
SSD
Filesystem Partition 1 537 MB FAT /dev/nvme0n1p1 Partition Type: EFI System mounted: /boot/efi Filesystem Partition 2 512 MB Ext2 /dev/nvme0n1p2 Partition Type: Linux Filesystem not mounted Partition 3 511 GB LVM2 PV /dev/nvme0n1p3
Toshiba HDWE140
Swap Partition 1 40 GB Filesystem Partition2 30 GB Ext 4 Partition Type: Linux Filesystem mounted: Filesystem Root Filesystem Partition3 3.9 TB Ext4 Partition Type: Linux Filesystem mounted: /home
So it seems like the efi partition, that I requested on sda was never made or is not being used. The efi on the SSD is being used, but it seems to have forgotten how to boot the OS on the SSD, although this seems to be otherwise intact.
I forgot to mention before that when I installed 18.04, from the USB installer, it said no OS was detected on the system. This was worrying and I think is probably the cause of the whole problem - the installer never detected 16.04 on the SSD.
TL;DR
Press the ESC key when the Lubuntu dots screen appears to see why it has stopped loading.
With the added information it appears that there is a PCI Bus error occuring. The recommended course of action (from other websites) is to make sure that your BIOS is up to date. Please update your BIOS (or verify that it is the current version) and, if the error still occurs, update your question.
Full story (which will be updated as the question is revised)
This is unlikely to be an EFI problem. EFI can be on any or all of the disks. Your BIOS will search for all EFI partitions and offer them to you in the BIOS menu(s). From there, you can select the OS to boot by default, or to boot as a one-off with menus you select during boot up. Usually these can be enacted by pressing F12
When you do upgrades, the kernel is also upgraded. Kernels are built based upon information provided by the manufacturer. As such, the kernel will operate based on the assumption that the firmware of the hardware is also up to date. (Unless it is able to update it itself, which never happens with BIOS firmware).