Can't boot after latest update

Hello

I have the same issue, I have tried to roll back with no change, now I have upgraded the packages again from the terminal
(sudo eopkg up).

I'm running with luks

Best regards
Karsten

JoshStrobl thank you, I will try it

RunningAroundIC Well the getsol.us certificate certainly is valid You could try downloading them to somewhere like your Downloads folder using a browser and installing them using sudo eopkg install <file>.eopkg instead.

tom73287428764

5.14.12-201 has a * next to it so i'm guessing that's the one that's selected

That is correct.

is there anything else i should be doing or should i wait until the packages are updated again a week from now and updata via software centre then

You'll be on the latest kernel that will get pushed from unstable to stable today. No additional changes needed on your part, just keep on rollin. You will see a modaliases package update related to nvidia-glx-driver once these land in stable, this is just for hardware detection and not something you have to worry about immediately updating and rebooting for.

Apologies for the disruption. This worked on my laptop, which is a LUKS based installation. Obviously wouldn't have pushed .12 to begin with if it hadn't.

RunningAroundIC I would double check that you are using the -201 version. If you are unsure and haven't seen a prompt / list when booting, spam the spacebar while booting up and you should see a menu.

JoshStrobl

The -201 is not listed

But in my eopkg history I see it installed, do I need to configure more?

When sudo usysconf run -f

I see that it is not updating the clr-boot-manager

RunningAroundIC Sounds like clr-boot-manager did not successfully run, possibly a full boot partition.

If you still have access to 5.14.10 and it's available in the boot menu, I would boot into that. You have two options after this, frankly I would suggest the first option.

The Easy Thing

1. Revert the eopkg transaction(s) responsible for the installation of -201 by following https://getsol.us/articles/package-management/history-and-rollback/en/ -- For example if it was transaction number 1000, you would do sudo eopkg history -t 999 to basically uninstall it.
2. Wait until 201 is pushed to the stable repo.

The Hard(er) Thing

sudo clr-boot-manager update
sudo clr-boot-manager list-kernels

Return the result from the last command. If 5.14.12-201 isn't listed there, it may be indicative of a full EFI System Partition (ESP). Do the following:

1. Run lsblk to determine the partition device names. You may see sda or it might be even be nvme0n1 if it is an NVMe drive.
2. Run sudo fdisk -o Device,Size,Type -l /dev/###, replacing ### with either sda, nvme0n1, etc. You should see something like the following...

[~] sudo fdisk -o Device,Size,Type -l /dev/nvme0n1                                                                                                                                                                                 
Disk /dev/nvme0n1: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 970 EVO Plus 1TB            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1CDC09CE-51FC-456F-8E52-A5B5EDE6E12C

Device           Size Type
/dev/nvme0n1p1   100M EFI System
/dev/nvme0n1p2    16M Microsoft reserved
/dev/nvme0n1p3 214.2G Microsoft basic data
/dev/nvme0n1p4   505M Windows recovery environment
/dev/nvme0n1p5   500M EFI System
/dev/nvme0n1p6 700.6G Linux filesystem
/dev/nvme0n1p7  15.6G Linux swap

Look for the EFI System. If you are dual-booting with Windows and had correctly followed our UEFI instructions, you should have a 500M EFI System partition. If you didn't, you are probably sharing it with Windows (big no no) and it's full with both Solus and Windows stuff.

In my example, my EFI System Partition is /dev/nvme0n1p5 and so I will run:

3. sudo mount /dev/nvme0n1p5 /boot

After this, I run sudo tree /boot, which returns

├── EFI
│   ├── Boot
│   │   └── BOOTX64.EFI
│   ├── com.solus-project
│   │   ├── initrd-com.solus-project.current.5.14.10-199
│   │   ├── initrd-com.solus-project.current.5.14.12-200
│   │   ├── initrd-com.solus-project.next.5.10.0-17
│   │   ├── kernel-com.solus-project.current.5.14.10-199
│   │   ├── kernel-com.solus-project.current.5.14.12-200
│   │   └── kernel-com.solus-project.next.5.10.0-17
│   └── systemd
│       └── systemd-bootx64.efi
└── loader
    ├── entries
    │   ├── Solus-current-5.14.10-199.conf
    │   ├── Solus-current-5.14.12-200.conf
    │   └── Solus-next-5.10.0-17.conf
    └── loader.conf

6 directories, 12 files

This is my desktop, not my laptop, and thus I have some extra stuff and not actually 201 (my laptop is what I tested 201 on).

In this scenario (as in, in your case, as you should be on .10), I would do the following:

1. Remove 5.14.12* by doing: sudo rm /boot/EFI/com.solus-project/*.solus-project.current.5.14.12-*
2. Remove the 5.14.12* config by doing: sudo rm /boot/loader/entries/Solus-current-5.14.12-*.conf

This would clean up space, and thus I would re-install the -201 kernels (following either the command from the task, or whatever means you did it). This is the easiest way to ensure clr-boot-manager is triggered and has the necessary files.

After this, re-run sudo clr-boot-manager list-kernels and sudo tree /boot (assuming it is still mounted) and double check that 201 is now listed. If it failed and /boot is still mounted, try doing sudo umount /bootthen try the clr-boot-manager update again.