Thanks to @JoshStrobl for deploying updated documentation to https://solus-project.com/articles/packaging/submitting-a-package/en/

Happy to report that builds are now able to flow once more

Can confirm it for my Win7 Enterprise machine at work as well - had the option after upgrade. So both, Win7 and Win10 worked (showing a vista for both for some reason - but that's not an issue as long as it recognizes it and boots correctly).

Certainly glad to be closing this one, hopefully for the last time. Thanks for testing, folks.

Worked for me - Windows boot option available after the update.

Hi - please open a separate bug for the power stuff.

I also don't see a notification now when I unplug my laptop charger. Screenshot of my power management settings and missing battery icon:

Using Solus Mate, I just noticed that I no longer have the battery icon in my notification area.
And even though I have it set to Ask me when the power button is pressed, in Power Management, my laptop shut down now instead of showing me the options and the countdown timer.
This was my last update:

This is fixed for me, thanks! I updated to kernel 4.9.25, and without running sudo update-grub and restarting, I saw the Windows option available. It still shows as Windows Vista, but it has booted fine before, just the wrong name. Nice way to troll us, thinking Windows 7 became Vista haha.

These updates are now in - please try.

So I'm hopeful that this one will actually fix it: https://git.solus-project.com/packages/kernel-glue/commit/?h=kernel-glue-4-191

@Shadow53 certainly not the case.

• I have a clean win10 install here at home, detected as Vista (running clr-boot-manager update manually, not recognized at all after kernel updates)
• I have a clean win7 enterprise install at work, detected as Vista (running clr-boot-manager update manually, not recognized at all after kernel updates).

@iachopolo It's probably part of how it detects the Windows bootloader. I installed Solus in a dual boot on a computer that was running Windows 10 but came with Vista and it detected the bootloader as Windows Vista. I personally doubt it's related to this issue, but others will know better than me.

BTW, when I run sudo update-grub it finds Windows Vista (I have 10). If I reinstall GRUB, it finds Windows 10. But if I run sudo update-grub it finds Vista again. Not sure if it's somehow related.
I have Solus and Windows 10 in same Hard Drive, different partitions.

Another confirmation. Never stopped happening. Confirmed while updating to 4.9.20, 4.9.21, 4.9.22. I don't really mind running 'update-grub' once in a while, but this is clearly a bug that needs resolving.

I can also confirm that the issue exists.
After todays kernel update windows is gone from grub.
I also have Solus and Windows 10 on separate drives (not sure this is important).
Rebooting Solus after update did not fix the grub.
"sudo update-grub" still fixes the issue.

In T524#59733, @STiAT wrote:

Maybe due to the reason that I've windows on a seperate disk (not the same solus is installed on), but it does not work as I'd expect it.

am having the same issue with this same configuration

Reopening. Last update I did run clr-boot-manager update and it found the partition.
Todays kernel update - windows was gone again from the boot entries.

This has already been resolved in unstable: https://git.solus-project.com/packages/linux-lts/commit/?id=1c6e6410665cec6f639e794d56440b192c3e0de4

Nope, still no windows option after this update. Had to re-run update-grub again. Unless I need to configure something special for CBM to work, it's still broken.

I'm still having this problem... 2nd update since moving to CBM

p11-kit yes, but not p11-kit trust (which is in p11-kit/trust directory and needs to be built seperately, it isn't built by default with p11-kit by default as I know).

Also this one is a big invasive change, so we need to ensure that we design a test for this to handle updating. Remember we're updating over SSL, so pulling the carpet out with SSL certs needs to be considered.

From our perspective, p11-kit is already included in Solus by default. So what we should try to do at the same time is ensure that ca-certs becomes stateless, and we have a proper transition policy in place to the p11 method

Ideally, yes. I've looked that up, and Fedora / RHEL seem to have switched to the p11-kit trust module as well with F19 when they introduced shared system certs.

So ideally we need to move out setup to work more like Fedora certs..

@palto42 didn't have this one on the radar, sorry.

The first update moving to clr-boot-manager, this problem will persist. However, for all updates after this, (CBM managed) the problem is resolved

Very happy to finally resolve this :)

Minor underps:

• https://git.solus-project.com/packages/kernel-glue/commit/?h=kernel-glue-2-187
• https://git.solus-project.com/packages/kernel-glue/commit/?h=kernel-glue-3-188

open-vm-tools ported https://git.solus-project.com/packages/open-vm-tools/commit/?h=open-vm-tools-10.1.0-37

razer-drivers ported https://git.solus-project.com/packages/razer-drivers/commit/?h=razer-drivers-1.1.8-9

bbswitch ported https://git.solus-project.com/packages/bbswitch/commit/?h=bbswitch-0.8-35

broadcom-sta ported https://git.solus-project.com/packages/broadcom-sta/commit/?h=broadcom-sta-6.30.223.271-100

nvidia-glx-driver ported https://git.solus-project.com/packages/nvidia-glx-driver/commit/?h=nvidia-glx-driver-375.39-128

nvidia-340-glx-driver ported https://git.solus-project.com/packages/nvidia-340-glx-driver/commit/?h=nvidia-340-glx-driver-340.102-88

nvidia-304-glx-driver ported https://git.solus-project.com/packages/nvidia-304-glx-driver/commit/?h=nvidia-304-glx-driver-304.135-124

Old janky kernel packages deprecated: https://github.com/solus-project/solus-sc/commit/e18aab1cec009d3eb572fcf1d87776d85189b3af

First build of linux-lts now going in: https://git.solus-project.com/packages/linux-lts/commit/?h=linux-lts-4.9.18-10

dracut now ypkg only and dejankified https://git.solus-project.com/packages/dracut/commit/?h=dracut-33-34

Added a janky kernel-glue package to handle the triggers: https://git.solus-project.com/packages/kernel-glue/commit/?h=kernel-glue-1-186

Can't wait to see how it goes :D

OK CBM is in Solus repos now, time to actually make things "work"

Okay, I reply myself :)

GRUB2 support is now in git - we just need to get this integrated and tested in Solus now

Amazing job!

@ikey that's actually what I hoped to find since I had a suspicion like that. But I actually could not find evidence for it.

@STiAT there's nothing to work out, read T2145. Manjaro/Arch also update their kernels like us, by removing the existing kernel from disk. Thus, ntfs (and other modules) cannot be loaded, so the disk cannot be mounted, and os-prober cannot .. probe. It's why we need CBM

As a note, this is not just Solus specific, Manjaro / Arch have / had this issue until switching to pacman hooks as well, and I've had it on several more distros.

Yeeppiiee ! :)

This is now resolved in unstable. After doing a full upgrade, users can install the driver and Optimus will be automatically configured for "always on" behaviour.
We'll add "on demand" in future.

OK so if you're on unstable, do a FULL upgrade first, and then install nvidia-glx-driver, and reboot. Ideally you'll come back to a full login + desktop *and* have Optimus enabled now

Can't wait testing it ! :)

Le more progress.

Le progress

@STiAT : Thanks for the workaround instructions!
Do you know if the manually added certificates are removed if the system updates the certificates via the package manager?

Found an upstream commit that fixes this issue.
It however will break ABI compatibility.
https://reviews.llvm.org/D24736

@kyrios123 I also found it kinda confusing and thought about reporting it.
@ikey IMO if the installation is finished, the progress bar should disappear, and it could be replaced by a tick mark (✓).

But it has one o_O

Detection code now fully works. Not waiting for CBM integration, getting it done sooner. Switched to using libpci - solves our problems.

What I'd like to know additionally is the way planned forward on this @ikey .

Actually got it working by now. My fault - I missed a damn certificate in the chain which was why it didn't work :-)

Might be missing the c_rehash ?

I've dabbled a bit, my issue is: Where are the certificates stored / how to tell OpenSSL to regenerate the certificate store?

Threw another tiny PR in to get coverage up another 2.8% before I start GRUB, so we can at least swallow any 1/2% coverage drop from its introduction

PR46 now merged https://github.com/ikeydoherty/clr-boot-manager/pull/46
This allows us to now add GRUB given we can actually test it.

Alright we're unblocked on that again
https://github.com/ikeydoherty/clr-boot-manager/pull/42

Closing this as it won't be necessary when we bring in clr-boot-manager (T2145)