The Dual Boot is the method of installation of two operating systems side by side, on different partitions or disks.

For example, having Windows on its own partition(s) and Slackware on its own partition(s), with ability to chose which one starts, on the bootloader screen.

i know min 10 application for make this possible. i think is thread is snow ball to Win 11 testing.
I select free software.
Also know what more lucky is dual hdd with BIOS selection or virt.
Thank you !

Slackware already comes with a USB boot image (usb-and-pxe-installers/usbboot.img). There is no reason why the slackware distribution could not provide the two boot images for secure boot installation using shim complete with images signed by a slackware key. The user's only additional step then to take is to enter the slackware key in the MOK, which is trivial. But in truth what would be even easier is to adjust usb-and-pxe-installers/usbboot.img so that it brings up PreLoader. I have indicated separately why that would not be my preferred option.

I am not arguing against the idea that slackware could also make its own EFI binaries, based on shim, which it could take to Microsoft for signature in the same way as Fedora does. But that does not seem to me to be essential: you need to have some idea about what you are doing to successfully install slackware anyway.

1 members found this post helpful.

Feel free to select the free software as much you want, BUT what you will do IF your motherboard is Secure Boot enabled only?

There are already tons of laptops which are this way. Even on my extended family are several.

Sorry, I didn't make myself clear. I know that what you said is a working way to install, and it's not terribly complicated for someone having average Slackware knowledge.

What I meant is that it would be a problem for someone who only has available the single PC where he needs to install Slackware with secureboot, and secureboot cannot be disabled on that pc.

It doesn't necessarily mean a newbie, but also an expert user who, for various reasons, doesn't have any other computer around at the moment that installation needs to be done.

1 members found this post helpful.

So, with the risk of some people bricking their computers, we should use self-generated MOK keys? What guarantee you that for some BIOSes "adding a new MOK key" does not mean also "purging the previous MOK keys" ?

And for what to do that?

For our BDFL saving of 250 dollars and the convenience of people playing with their custom kernels, we should accept the risk to have horror stories about how Slackware bricked computers?

With all respect, I believe that Slackware should use the most simple and secure way: with keys from Microsoft and signed kernels. As the other distributions do.

Those Gurus who love to compile custom kernels will find anyway an alternative way to play with MOKs too. Because they are Gurus, right?

This is nonsense. First, MOK keys can't brick a computer and secondly "BIOSes" have nothing to do with adding MOK keys: the "BIOSes" (by which you really mean the EFI firmware) know nothing about MOK. The MOK list is only used by shim and PreLoader.

So let me see if I understand this. There are built-in variables like the Microsoft key which the UEFI not only stores but understands and uses to determine what is bootable. And there are variables which can be stored in the UEFI's NVRAM by programs but which the UEFI itself does not use and does not care about. MOKs and kernel hashes are of the second kind: they allow programs like shim to make decisions about which kernels/modules can be loaded and run by a bootloader. Correct?

Simple. I will never buy a PC like that.

3 members found this post helpful.

I hope in the next 5 years we still have that choice. I wouldn't put it past MS to lock down things in their "extinguish" end of the chain.

2 members found this post helpful.

To the best of my understanding, that's pretty much it. Some EFI variables, as stored in NVRAM, are required by the UEFI standard. The most notable of these hold the Platform Key (PK), Key Exchange Keys (KEK), signature database keys (db) and forbidden signature database keys (dbx). These amongst others are stored as secure variables: they cannot be changed unless in platform setup mode except in particular circumstances. The PK and KEK cannot be changed except by an update signed with the PK. The db and dbx cannot be changed except by an update signed by the KEK. Microsoft's public keys, one for their own EFI binaries and one for third party EFI binaries, are in db in pretty much all consumer computers. The PK and KEK keys are generally set up by the OEM, but most firmwares enable the user to enter setup mode to substitute his/her own. Such user installed keys have nothing to do with MOK, shim or PreLoader. They are a way by which a machine owner can set up secure boot to his/her own liking. Secure boot is not intended to protect a computer from the activities of a physically present person.

Possibly the advent of Windows 11 may affect the willingness of UEFI firmware writers to enable secure boot to be switched off and/or setup mode to be entered by those physically present. I have no idea on that. I imagine Microsoft would be pleased if they did for anti-competitive reasons and it looks as if Windows 11 won't run if secure boot is off.

The MOK list does not feature in the UEFI standard at all (the shim and PreLoader EFI binaries of course use the EFI BIOS firmware to write to, read and control access to the MOK keys, but MOK doesn't have any special meaning to UEFI). As I understand it, it is a layer on top of it. When secure boot was introduced Microsoft were persuaded, perhaps in fear of another anti-trust suit, to offer a service to sign third party EFI binaries and in due course they signed shim and PreLoader, which establish and use the MOK list to authenticate linux kernels. There is no chance they would sign PreLoader again, and it is possible that at some point that PreLoader may be shunted into the dbx, because it allows you to drive a coach and horses through secure boot. Exclusion via the dbx will probably happen the first time (if any) PreLoader is used to assist a back door attack on windows. Shim is pretty much OK because it requires the boot manager or loader it hands off to (in effect either grub or rEFInd) to authenticate the kernel it boots via db or MOK keys. It is possible shim may be enhanced to require kernel modules to be signed. At present that is not required but is an option the linux build system offers.

At the risk of almost 0% contribution from my post - I will just say - I don't care. If I need Windows 11, I will do what I did with Windows 10 and use a VM, done and done.

-Edit

Also Windows 10 EOL is projected to be at 2025; so yea who cares. Anyone who needs to dual boot Windows (bare metal install), I would say stick with Windows 10 also; let the early adopters be the guinea pigs to the potential bugs of Windows 11, since Windows 10 is 'mature enough' for the early bugs to be dealt with.

2 members found this post helpful.

Re: UEFI with SecureBoot locked in.

It wouldn't be the first time I modded Firmware. Recently I modded a UEFI image for a 2014 Z77 mobo to get solid NVME support and, true, it wasn't as easy as it used to be (had to jump through flaming hoops to get it to flash a modded image name) but it was doable. It still runs almost every day as a streaming device.

1 members found this post helpful.

(excuse if this is n00b/dumb)

Could ALL Slackware (non-M$Win) users be *just as happy*
running in a VM (on M$locked hwd)?

Yea, M$ maybe soooooo desperate to fix (by locking) their hackable WinDoze,
that they may neglect the 2% 'collateral damage' from requiring
anything that runs their CrapWare to be 100.00% locked-down.

Any specific uses of Slackware that won't work in a VM?


IF I had a new Win11 PC, I wouldn't run anything except VirtualBox directly on it. Not even any web browser app. (except risking once, to download VB & a distro)

It may be worth read the requirements from Microsoft to the OEM wrt Secure Boot for installing Windows. Caveat: this document is dated 07/29/2019.

1 members found this post helpful.