I have a new ASUS laptop and I am trying to get it to dual boot with Windows 10 and Slackware 14.2. I have a 14.2 install DVD and I used it to install 14.2 with the 4.4.14 kernel. I have no internet on the machine when I am in the linux partition. I also have not figured out how to get a LILO boot menu to let me select between Windows or Slackware when I start the machine, I have to hold ESC and select which partition/os I want to boot.

Currently, the BIOS settings are:
Secure boot control - disabled
CSM support - enabled
Boot option #1 - Windows
Boot option #2 - UEFI: SANDISK Partition 1 (this is the thumbdrive that lets me boot linux, made with the help of the Slackware install DVD)
Boot option #3 - P0 (linux partition)
Boot option #4 - DVD

returns

If I change the boot options and I select P0 as the first boot option, I get the "Slackware/OS Selection" screen, so it looks like Linux starts. The problem is, based on another question I'm also dealing with regarding wireless problems, I am also trying to update(upgrade? what's the difference?) the kernel and I don't think I've done that correctly, because now when I select "Linux" and tap Enter, there is a brief error message and then the boot restarts and goes back to the "Slackware/OS Selection" screen. (another upcoming question for me).

I don't know how to tell for certain if I am using LILO or GRUB for booting. When I installed from the DVD, I selected to use LILO and to put it on the MBR, but when I finished the install and rebooted, it just went to Windows. There is no /etc/lilo.conf. I tried installing multiple times and never was prompted for using ELILO, so I have no reason to believe ELILO is installed or active. I am not even sure that I am on EFI, because CSM is enable and I thought I read somewhere that EFI doesn't work with CSM enable. I've read so much stuff about EFI and LILO and related topics and all I've done is confuse the hell out of myself.

My questions are:
How do I get dual boot set up on this computer with Windows 10?
Do I need to enable LILO? How? (I thought it would work when the install disk prompted me.) Do I need to copy one (or a few) files to /boot? I'm lost at this point.

We need to see your /etc/lilo.conf. Transcribe it if necessary, and tell us what partitions things are on.

I don't have a /etc/lilo.conf. If I type "less /etc/lilo.conf" the output is

Is that your problem? I don't know elilo, but I thought it used lilo.conf. Find out what it does use to configure the boot loader.

I don’t know if the boot loader is using ELILO. When I ran the install, I never once saw a prompt for ELILO. I have no idea at all what the boot program is or how to tell. That’s a big part of my problem. If I “ls /boot” there are ELILO directories and EFI directories and a bunch more directories and I can’t tell which is the relevant directory. The only thing I can say for sure is that I never ran GRUB. Beyond that, I don’t know what’s running the boot.

@deretsigernu

It looks like you're booting on UEFI and your Windows is installed under UEFI:
If you'd ask me, and if you have no use for UEFI, I'd suggest to disable the UEFI in the BIOS, clean the drive and reinstall Windows & Slackware in legacy mode, that way you'll be happy with both Windows and Slackware and your setup will be a lot more easier (lilo). That's me, I'm no expert in UEFI and I disable it all the time, not finding any personal use of it other than over-complicating the boot process.
As you don't have a /etc/lilo.conf, maybe you have an elilo.conf - check it out.

If you cannot reinstall the OS-es and would like to stick with UEFI, these are some sources of inspiration/lecture (look after Didier Spaier's hints - he is/looks versed with the subject):
https://www.linuxquestions.org/quest...on-4175637250/
https://www.linuxquestions.org/quest...os-4175633661/
https://www.linuxquestions.org/quest...ng-4175583765/
http://docs.slackware.com/howtos:sla...uefi_and_elilo
& rEFInd - this looks to be a better solution:
https://docs.slackware.com/howtos:sl...d_on_slackware
https://www.linuxquestions.org/quest...5/#post5907133

P.S. You might not be required to reinstall win10 - maybe only disabling UEFI Secure boot will suffice:
https://docs.microsoft.com/en-us/win...ng-secure-boot

As an aside, I think that we should drop lilo and elilo altogether and use grub instead during installation in future versions. I am beginning to work at it.

Rationale:
1) lilo is hard to properly set up in a multi-boot and multi-mass storage devices environment, possibly including removable devices, which is becoming more and more common. And it is a dead project.

2) elilo can hardly cope with a multi-mass storage devices and multi-boot environments, possibly including removable devices. And it is a dead project.

3) grub can handle pretty much every context, in Legacy as well as UEFI booting. Its only limitation is that it can't handle "exotic" file systems, lacking the corresponding drivers. But then it's at least possible to use it to load an EFI boot loader for any OS that handle EFI booting, regardless of the file system it uses. And it is very actively maintained as shows the traffic on the grub-devel mailing list.

There is also rEFInd, that has the advantage of being able to refresh its menu when there is a change in an EFI boot loader as it scans them at startup, but of course it can't Legacy boot.

I know, off-topic ramblings...

PS:before someone asks: there is also syslinux, but it is also in a comatose state.

1 members found this post helpful.

@Didier Spaier
Not really off topic, as the OP is looking for a boot manager solution, however, your points, which are valid, should maybe make the subject of a standalone thread/poll. But that's for Slack - current & future versions, the OP is on Slackware 14.2 ATM.
Personally, I have some reservations with grub, while the features & documentation are OK, I guess due to its (intensive) active development there are also frequent bugs, choosing & supporting a stable version as a default boot manager might be tricky.

@deretsigernu
If you'd like to choose grub, here's a doc you might want to look at:
https://docs.slackware.com/howtos:sl...based_hardware

If I'm reading this correctly, your booting the slackware on your harddrive from the usb.
did you install 32 bit slackware-14.2 or 64 bit slackware64-14.2? I don't believe 32 bit will work on an efi system except for in legacy mode resulting in having to boot using the usb. If your system bios will detect it you may be able to boot without the usb by creating a 1-2 mb empty bios-boot(bios-grub ef02) partition and the run grub-install /dev/sda

If it was 64 bit then the rest of this might be useful
The quickest way to check if in efi mode or legacy is to check if there is a /sys/firmware/efi/ once the system is booted.

do you have line in your /etc/fstab that mounts /dev/sda1 at /boot/efi?. Do you have a /boot/efi/EFI/Slackware directory, if so what is in it? If you don't have a /boot/efi directory mount /dev/sda1 and see if there is some sort of EFI/slackware directory.
when booting the system from the usb is there a /sys/firmware/efi directory? If not then the usb is booting the system in legacy mode.

If no slackware directory on the efi partition then boot loader was probably not installed.
As already been mentioned by Didier Spaier and IMHO grub is easier to use once configured on efi mutliboot system.

to get grub installed as efi if the answers to above are no.
create a /boot/efi directory if it doesn't exist
mount /dev/sda1 to /boot/efi/
then run If the slackware was booted in legacy mode you will get an error about efi variables or something like that when grub-install is run.
Slackware doesn't use update-grub to create /boot/grub/grub.cfg file. To create a grub.cfg run edit your fstab to add an entry to mount /dev/sda1 to /boot/efi at startup.
reboot and see if you have an option to boot slackware.
once booted, if you have /sys/firmware/efi the rerun grub-install or use efibootmgr to add slackware to the efi-firmware boot options

1 members found this post helpful.

In #6 I said I found no personal use of UEFI and I was wrong, deeply, apologize for that. Dual boot of Windows (vulnerable) & Linux (Slackware) can be affected by this interesting "new use" of UEFI enabled BIOSes:
https://www.zdnet.com/article/fancy-...t-in-the-wild/
Research paper:
https://www.welivesecurity.com/2018/...-sednit-group/
Enabling SecureBoot can protect, but Slackware is not able to use that function ATM. Even if it'll sign the officially released kernels, the custom ones, built by the users, will not have a signature and will not be able to make use of SecureBoot.
https://www.linuxquestions.org/quest...ve-4175624446/

@abga: there's nothing specific to UEFI there, IMO. An attack can come from a nasty firmware (be it a BIOS or an UEFI one), by the application it starts (in case of UEFI it takes the form of a file in PE/COFF format, but that's still an executable binary file, usually converted from an ELF binary in case like e.g. elilo.efi), by the OS (in case the UEFI application is actually an OS loader), in some case using a feature of the CPU itself even if the computer is shut down as we have seen recently.

I am not convinced either that using Secure Boot is enough to protect @ 100%, as all depends on the trust you give to the signature and the signatories...

But I am not surprised that the UEFI firmware or an UEFI application be increasingly used attack vectors, as pretty much all new computers ship with an UEFI firmware nowadays.

@Didier Spaier
It's exploiting the UEFI ability to accept&use "modules":
https://www.welivesecurity.com/2018/...-sednit-group/
"Our investigation has determined that this malicious actor was successful at least once in writing a malicious UEFI module into a system’s SPI flash memory. This module is able to drop and execute malware on disk during the boot process. "

@abga: the current UEFI specification says:By module of code what is meant is just a set of definitions and instructions that correspond to a source file linked by ldd or such if I understand well. As far as I know this is a pretty ubiquitous behavior, and that this occurs in the context of UEFI makes no difference.

The issue mentioned seems to be that the module could be written in the flash memory (should I understand the code of the firmware itself was modified, not the variables in NVRAM?).

Per se this has nothing to do with the specification, which doen't say that a module should be allowed to modify the firmware's code. The specification is purely external as it states in the introduction: By "external" I mean that it says nothing about the firmware or the OS but their ability to communicate together using the interface it describes.

So if a firmware is vulnerable it's only its developer or provider responsibility. At least, that's my opinion.

@Didier Spaier
I also looked over the UEFI specification searching for "Extra/Miscellaneous Functions" and found none (documented). It looks like the former Computrace anti-theft protection mechanism/module (legacy BIOS):
https://www.blackhat.com/docs/us-14/...visited-WP.pdf
has made its way into the UEFI Environment - page 33:
https://www.blackhat.com/docs/asia-1...nd-Reality.pdf
And it's by exploiting this legitimate "module" (substituting/adding a new one) that the malicious code can hack itself into the HW and update the SPI flash with a payload - Page 3:
https://www.welivesecurity.com/wp-co...ESET-LoJax.pdf
"Along with the LoJax agents, tools with the ability to read systems’ UEFI firmware were found
and in one case, this tool was able to dump, patch and overwrite part of the system’s SPI flash
memory . This tool’s ultimate goal was to install a malicious UEFI module on a system whose
SPI flash memory protections were vulnerable or misconfigured ."

Loading malicious code through firmware updates, as you mentioned, might be also possible, but there are cryptographic anti-tampering mechanisms that are protecting from such attempts (not perfect either):
https://www.linuxquestions.org/quest...ml#post5804888

I raised this issue here, because I advised deretsigernu to disable the Secure Boot in Win10, he already did it in the BIOS, and considered this thread - dual-boot-Win10-Slack appropriate for mentioning this new vulnerability. It's not a topic for Slackware itself, unless someone will come up with a method to run this exploit through the Linux kernel and therefore I'll stop developing on the subject - it's way off-topic already.