HOWTO prevent installation hangs on recent hardware
 

The problem: The standard Slackware installer hangs solid when trying to install on recent hardware, shortly after loading the initrd.img. The only way out is to power down.

The reason: Some newer generation on-board graphics systems use 64-bit addressing for the efifb. Slackware uses elilo as the default boot system. Elilo is not compliant with 64-bit efifb.

The solution: Use GRUB to boot the install media.

Here's how:

1) Create a new Slackware install drive using "./usbimg2disk.sh -f -s /path/to/slackware64-current -o /dev/sdX"

2) Mount USBSLACKINS

3) Delete or rename (if you have space) /EFI on the USBSLACKINS drive.

4) Copy recursively (USBSLACKINS)/slackware64-current/EFI to (USBSLACKINS)/

5) Edit (USBSLACKINS)/EFI/BOOT/grub.cfg (change path to kernel and initrd):

You should now have a grub bootable install USBSLACKINS. Once the kernel and initrd have loaded, you should get the initial loading screen (the one with a row of penguins at the top), and be able to carry on with a normal Slackware install.

Its taken me a while to figure this out, as you cannot read any error messages before the system locks up solid! Hopefully this will help anyone else running into the same problem!

I initially worked around the problem by installing Liveslack first, and then using slackpkg+ to switch to Slackware. Strangely, going this route enabled the resulting Slackware install to boot with elilo, although the initial "penguin" screen was missing.

However, I would recommend switching to GRUB for anyone who is having this issue.

Hopefully Pat and/or Eric will address this before 15 gets released!

--
Pete

Pete,

The Slackware installer does not use elilo. Both the Slackware installer and my liveslak use GRUB on UEFI computers.
My GRUB EFI boot image is different from the Slackware version however. Perhaps I add some GRUB module to liveslak that your computer needs and which is not present in the Slackware GRUB EFI boot image.

Compare the scripts used to generate the EFI boot images and spot the differences: https://git.slackware.nl/current/tre...T/make-grub.sh (Slackware) to https://git.slackware.nl/liveslak/tr...T/make-grub.sh (liveslak).

Hi Eric, and thanks for your input! I stand corrected!

However, there is something fundamentally wrong with the installer on the standard Slackware install media as it simply doesn't work with (at least) Intel 620 graphics and possibly others.

I thought it was only me having this issue, but I now see some other threads emerging with the same problem.

I'm not claiming to be an expert with grub or elilo - far from it - but the work-around I have outlined does work, though I accept its a bit of a kludge! ;)

Its a while since I installed via liveslak and I can't recall whether the efifb initialised properly or not - but it didn't crash, which the slackware installer did!

If you look at the procedure I've outlined above, you'll see I just copied the -current EFI folder onto the install USB, replacing the one that was already there. The original EFI folder contained an elilo.conf file - which is why I assumed it was using elilo! There were no signs of any grub files in the EFI folder until I put them there!

I'll have another dig around this afternoon and get back to you, but something is wrong somewhere, and my kludge provides a work-around for the time being.

I realise that neither you nor Pat has access to the full range of hardware out there to pick up on things like this, and I'm quite happy to help out in trying to find a solution.

Thanks for your comments. I have to go out right now and do some paperwork when I get back, but as soon as possible - hopefully later today - I'll have a look at those links and see if I can find anything more clues!

Cheers,

--
Pete

OK, Eric, I'm not sure what is going on here, but I've just created a new USBSLACKINS pendrive using your usbimg2disk.sh script.The /EFI/BOOT folder on that disk conains 3 files: BOOTX64.EFI, elilo.conf and message.txt.

The BOOTX64.EFI file is 232.9 KiB (quite compact).

When booting from this pendrive in my laptop, there is no grub menu. I get the following messagesthen the machine locks solid. (It does work on my older, desktop machine - also UEFI)

Looking in the slackware64-current/EFI/BOOT folder, I find 8 files: bootx64.efi (1.4MB, much bigger!), grub-embedded.cfg, grub.cfg,huge.s, initrd.img, make-grub.sh, os-detect.cfg and tools.cfg.

In other words, the files I would expect to find for a grub boot.

My conclusion has to be that the usbimg2disk.sh script is NOT producing grub bootable media, but something else - from the cfg file, elilo!

Copying the contents of the 2nd EFI/BOOT folder (the one under slackware64-current) into the EFI/BOOT under the / of the drive (and tweaking the paths to the kernel and initrd in the grub.cfg file) DOES produce a working grub install medium.

Either I've misunderstood something about creating the install media (quite likely!) or you / Pat are creating yours differently.

If I have misunderstood, then others are likely doing the same (see the thread below this one).

Are you able to clarify? What am I doing wrong?

Does your "make-grub.sh" script have anything to do with this, and if so, is it applied before or after the "usbimg2disk.sh" script?

All the documentation I've found about grub on slackware is either very old and/or very confusing! Any help greatly appreciated!

--
Pete

Just made up a new Liveslak pendrive, using the iso2usb.sh script.

That DOES use grub to boot, I get the proper efifb output (the "penguin" screen) and everything works as it should. The standard way of making a Slackware pendrive does NOT use grub to boot, and crashes on my laptop - though it does work fine on older UEFI machines.

--
Pete

Your problem statement:
Made me think that your story was about the Slackware installer.
Now that you add more information, it actually looks like you are not talking about booting the installer, but booting the USB disk which is created during the installation.
If that is the case, disregard my comments and next time explain yourself better.

Hi Eric,

No, I AM talking about the Slackware installer. I can never get as far as creating a USB boot disk, because the actual installer never starts.

Please read post #4 above. I create an install drive from the Slackware64-current tree using "usbimg2disk.sh". If I boot from this to install Slackware on my laptop, the kernel loads, the initrd loads, as described in #4. Then everything just stops dead.

The keyboard is dead, the whole machine is locked solid. The only way out is to power down.

Again, just to be absolutely clear, this is with the Slackware install pen, NOT a bootdisk created during install. It never gets that far.

Replacing the contents of the EFI/BOOT folder on the installation pendrive with the contents of the EFI/BOOT folder from the top level of the slackware64-current folder (and tweaking the paths in the grub.cfg file) allows everything to complete as expected, and get to the setup program.

I hope this is clearer now.

Thanks for your time here, Eric.

Cheers,

--
Pete

I've updated the instructions in the top post of this "HOWTO" in the light of more experience. The original version works fine, but I've managed to simplify it a bit!

If anyone gives it a try, let me know how you get on!

--
Pete

Pete,

Thank you for your instructions! I've been a Slackware advocate for nearly 20 years and have never had major problems installing it. (Until recently...). I have a new Acer Aspire 5 A515-55T, and I had to follow your instructions in order to get past the installer hanging after loading the initrd.img file. Now my next step is to get Slack to find my SSD... (but that's probably another thread)!


Rob.

Hi Rob, and thanks for the feedback! Glad I could help out!

It took me a long time to figure out the problem and fix it! Actually, I did make one error, though it doesn't affect the fix. The installer does not use (e)lilo, but syslinux/ldlinux. However, the end result is the same.

I did find that once I overcame the initrd hang, I could install elilo and get the system to boot with it. However, the screen remained blank until kms kicked in (no penguins!). The best solution is to use grub.

I have notified both Eric and Pat about this, though the only reaction has been from Eric who seems skeptical. Probably because only a very small number of people have reported the issue. In my case, it was the on-board Intel graphics that were being upset. Do you happen to know what graphics set your Acer has?

Having said that Eric seemed skeptical, I have to say that it was he who recommended installing Liveslack first (which did install OK - and seems to use grub as the installer!), and then pointing slackpkg at the proper Slackware tree. Although this approach works - and indeed, got me out of trouble - it does seem to me to be side-stepping the issue rather than fixing it. And who knows how many would-be Slackers have given up because the installer failed, without reporting it?

Most other distros seem to have switched to grub - at least for the installer. Perhaps Slackware needs a nudge in this direction?

Time to climb down from my soap-box! ;)

--
Pete

Hi Pete,

First of all thank you for all your effort put into this - the threads you started helped me setting up slackware-current on a Clevo laptop I purchased recently. Although I didn't use your method of creating a grub based installation drive, reading about your experience with your laptop helped me choosing the right installation method. I used grub based pxe server which I already experimented with before buying the new machine.

Out of curiosity however I checked the install usb which I created recently for use on another machine. It was made using the official instructions from slackware repo:
And it does use elilo. It doesn't appear to launch the installer as you can't see any output on the screen, but if you press enter a few times, press "1" as you would to accept the default keymap and type in "reboot" blindly it will restart the computer promptly. That indicates the installer is really working.
This is consistent with elilo's behaviour on the installed system - there is no screen output until kms kicks in. I had to switch to grub to see the boot messages and the penguins.
Eric was right that the other installation media use grub already, so DVD installer will boot to grub, but that doesn't help when you don't have a dvd drive to boot from :-)

alekow: Thanks for your input! That's quite interesting. The machine that gave me all the problems was also a (locally re-badged) Clevo. I'm not absolutely certain that the Intel graphics are to blame. It might also be the Insyde BIOS! I remember having problems with one of those with Slamd64, back in the dawn of the 64-bit era, but it wasn't as intransigent as the Clevo!

The strange thing is I did try to boot from a DVD (I have a USB-BluRay drive), but that exhibited exactly the same problem! I also tried tapping random keys, trying to provoke a response, but to no avail. Not even a flicker from the HDD LED to indicate anything was working. To all intents and purposes, it was locked solid!

Alas, I have been working from a sample of 1, so its very useful to hear the experiences of others. I have a feeling that this is an issue that will grow with time, and is perhaps best sorted now, whilst the number of machines affected is small.

We don't want to put off potential Slackers with installs that just hang without reason. That's getting into Micro$oft territory... ;)

--
Pete

Yes, I remember reading about it in one of your posts. I was planning to buy one at that time. I think we are using the same supplier ;-)

Never tried an optical drive as I didn't need to and don't own one either.


Exactly my thoughts.

Have a great day!

Alex

Hi Pete,
I want to thank you for this thread, it was very helpful to successfully let me install Slackware on my new notebook.

VicFer: My pleasure! Glad to help!

And thank you for posting here. I think this is a "hidden issue" at present, but one that will become increasingly problematic. I have tried to raise the issue with Mr.Volkerding (and AlienBob), but to no effect so far. I suspect that they don't have any hardware that demonstrates the problem.

Maybe if enough people post their experiences here, it will get their attention! ;)

--
Pete

Thanks pchristy, you saved my day on a brand new laptop !!!
didn't make a bootable drive so I used
and followed the remaining of your tutorial.

Glad to be of help! And thanks for the tip about using dd instead of usbimg2disk.sh. It might help others out!

--
Pete

Hello,

is this problem supposed to be fixed?

I cannot boot my new Acer Aspire 3 A315-56 (BIOS version 1.19, SSD storage) with a
USB pendrive holding the "usbboot.img" in "slackware64-current" from October 10,
2021. The MS Windows installation worked fine.

This is what I did, after searching the Net:

1. at boot time, press F2 to enter the BIOS setup;

2. in BIOS's "Security" tab: set the Supervisor Password;

3. in BIOS's "Boot" tab: the only boot mode available is UEFI, but I disabled the
Secure Boot;

4. in BIOS's "Main" tab: press Ctrl+S to enable the supervisor features; change the
SATA mode from "Optane without RAID" to "AHCI";

5. in BIOS's "Exit" tab: select "Exit Saving Changes".

Now I try to boot from the USB pendrive:

1. at boot time press F12 to enter the boot menu;

2. select the "USB HDD" as boot device;

3. I see the first textual screen from Slackware's loader "Welcome to Slackware64
version 15.0 (Linux kernel 5.14.11)!"

4. I just press Enter to boot with the "huge.s" image;

5. loading starts; it loads "huge.s" until "done"; it loads "initrd.img" until
"done";

6. and it just stops doing nothing.

Sometimes I can reboot with Ctrl+Alt+Canc; other times I have to cut energy by
inserting a needle in the small reset hole under the laptop.

The same happens with "usbboot.img" in Slackware64 14.2. I can boot the laptop from
a USB pendrive holding one of the latest LinuxMint images
"linuxmint-20.2-xfce-64bit.iso".

If I leave SATA mode to "Optane without RAID": LinuxMint cannot see the internal SDD;
by setting it to "AHCI": LinuxMint can see the internal SDD with devices:

/dev/nvme0n1p1 EFI system partition

/dev/nvme0n1p2 Microsoft reserved partition

/dev/nvme0n1p3 Basic data partition (with the Windows installation in it)

/dev/nvme0n1p4 Basic data partition (with the Recovery system in it)

With SATA mode set to "AHCI", the preinstalled Windows does not boot anymore; I can
boot it again by switching SATA mode back to "Optane without RAID", boot, let it
"repair" the system and restart.

So I tried an equivalent of pchristy's method to create a bootable instllation USB
pendrive: it worked, I can boot the installation procedure (not finished yet, I will
in the upcoming days).

Glad it worked for you!

As far as I am aware, neither PV (Slackware creator / maintainer) nor Alien_Bob (creator of the script to make installation pendrives) have followed up on this. It only appears to affect a small number of machines. Whilst I am not absolutely certain of the cause, I *do* know that using grub to boot the install media (as described above) works.

Anyway, glad you got it sorted!

--
Pete

I only read the first four comments between pchristy and Alien Bob on the first page of this thread, so I don't know the rest of the conversation. I came to say that I've had the same problems, or similar anyway, as pchristy when trying to use the liveslak at times. I've posted about this in the past, but didn't have the technical knowledge to try to diagnose as pchristy did or to see Alien Bob's explanation as the background of issue. Hopefully though, there is some update to the installer or boot process so that it will be easier to use those media for testing, troubleshooting, or installation. Thanks, pchristy, for the thread.

Thanks, Thanks, Thanks pchristy !

I am just now exploring my new Sager NP9672M-G1 which is a rebranded Clevo CLEVO X170KM-G

Lots of shiney-new Hardware here but the Insyder BIOS Application seems dumbed-down to the point of being primitive ( :) ??? where are all the knobs and buttons for all those new goodies ??? :) )

Anyhow, Alien Bob's Slackware Live Edition Booted fine yesterday after I was able to find a Bootable 32GB Thumb Drive.

Everything seems to work ( Rare for me on new Hardware ) and Plasma is beautiful.

Bookmarked your post.

I am going to try the 'old way' of installing Slackware Current but if I have grub issues, I know where to look.

-- kjh

Good day.

Created install thumb drive for 15.0RC2 using supplied usbimg2disk.sh.
On system with MSI MS-7B51 mainboard (MSI MPG Z390 Gaming Plus), system hung after loading kernel and initrd.
Per your post, deleted contents of EFI folder and copied over from slackware64-current/EFI folder and edited grub config as shown.
On next boot from install media, was greeted by grub prompt. Was able to start boot by issuing commands

linux (hd0,msdos1)/efi/boot/huge.s
initrd (hd0,msdos1)/efi/boot/initrd.img
boot

Not sure why it didn't pick up the thumb drive partition automatically, but install worked properly afterwards.

Thanks much.

Hi - just want to chime in here. This issue is affecting new Intel Jasper Lake machines also.

I suspect most, if not all, integrated Intel graphics systems 10th generation and onward are going to be affected by this issue.

Just wanted to note that the machine does not lockup, just that graphics output doesn't happen after ELILO loads initrd.gz.
I have managed to do installations remotely using network via ssh through dropbear on the install media.

Andrew.

Thanks for your input, Andrew. Whatever the issue is, it looks as if it is becoming more commonplace, as I feared. I still haven't seen any response from our beloved leader, and hesitate to keep prompting him about this.

Perhaps it needs a few others to file bug reports to prompt a proper investigation? In the meantime, switching to grub seems to be a viable work-around.

--
Pete

Just to note - after the installation, when I booted, then I still had no graphics output in the standard vga framebuffer. It wasn't until the switch to the intel framebuffer around 6 seconds into boot that the display output returned. Thankfully that required no special setup or kernel parameters and worked as normal after that.

Andrew.

Did you switch your installation to grub? Once I'd managed to get mine installed, initially it did exactly what you have described. I didn't get the frame buffer (penguins) back until I installed grub. Using grub on the install media just enables you to boot the install media. It doesn't automatically install grub on the final installation.

Grub appears to correctly use the efi buffer. From what I can make out, elilo (& syslinux?) tries to use a non-existent vga buffer!

--
Pete

No, I used the original ELILO based install but "blind". I just started dhcp and dropbear to allow remote installation and did it from another machine on the network.

Once installed, also using ELILO. It's quite possible that the framebuffer switch issue comes from ELILO, but I haven't looked into it further.

Andrew.

OK, if you want the "penguins" (frame-buffer) back, just install grub instead of elilo.

Yes, I had to take a deep breath before I did it the first time, but its actually quite painless! A side benefit is that if you configure /etc/default/grub to your liking, not only do future kernel upgrades become very simple, but for dual boot systems, you can make it reboot to the last booted system by default. This makes upgrading systems that need multiple reboots to upgrade a doddle! ;)

--
Pete

Thanks - I'm familiar with GRUB, but really don't want to go down that path now.

Might look into it in future though. Good to know that it works.

It sounds like Slackware may have to migrate to GRUB at some point if there are growing pains of ELILO (which is abandoned afaik) when it comes to newer graphics devices.

Andrew.

Thank you for this workaround which made me able to install Slackware 15.0 on my laptop.

My pleasure! Glad to be of assistance!

:)

--
Pete

I have just had the same experience trying to boot a slackware 15.0 installation USB on a Dell inspiron 7415. I was able to boot using your fix but haven't got round to going ahead with the installation yet.

Glad it worked for you!

One of my "test" machines is an oldish Dell Latitude. It was given to me by a friend as it has a graphics fault somewhere that makes the screen erratic - works fine on an external monitor, though.

I had quite a struggle getting a UEFI boot on it, as there were a few things I had to mess about with in the BIOS. I can't remember off-hand what it was, but if you get stuck, send me a PM and I'll have a root around and refresh my memory!

Cheers,

--
Pete

I was bitten by this issue with a MSI Creator 17 B11UE. It has an Nvidia RTX3060.
My solution was to "steal" the GRUB bootloader from Linux Mint (20.3) to install Slackware 15.

One thing I noticed is that the machine does not freeze, it is only the video that does not work. If you hit [Enter] a couple times after the installer "loads", and type "poweroff" the machine will power off as expected, just as it does in the regular installer.

I was able to install Slackware 3h ago, and about 1.5ago found this page with you solution... yeah.
My GRUB entry is almost like yours.

linux /huge.s load_ramdisk=1 prompt_ramdisk=0 ro printk.time=0 SLACK_KERNEL=huge.s
initrd /initrd.img

Also once installed, regular elilo does not have problems booting and having video working.
In my case I need to install proprietary nvidia sadly, cause nouveau barely supports RTX3060 :(


Cheers,
Ivan

Hi Ivan,

Glad you got it sorted!

Yes, since I wrote the original piece, more information has come to light. Not all machines freeze completely, but they still remain pretty useless with no screen. And yes, once installed, elilo does boot the system, but the screen remains blank (no penguins) until KMS kicks in.

The only 100% reliable boot-loader seems to be grub. Like many others, I was reluctant to adopt it initially, but now I've used it for a while, I would not go back. I've written a simple "helper" script to take care of updating after a kernel upgrade, and copied all my important setups to the config script (and made a backup of it!). I now use this on three machines (Desktop, workshop and laptop) and it has worked on everything I've tried it on.

Regards,

--
Pete

my system:
installed
used USB for installation of Slackware-cuurent (Alien Bob installation disk) at the time. Since this problem preceded my install (and still persists) one can at least exclude some of the hardware.
I prepared disk first making partitions including EFI
Booted laptop from USB and installed with EFI/elilo. This means that the statement
is incorrect as I did not encounter any problems at all.

Hi, and thanks for your comments.

The original post was written some time ago now, and further information has come to light since then. You are correct in saying that I was wrong when I said elilo was not compliant with a 64-bit efi frame buffer, however on many systems it still has some issues until kms kicks in. Also, I believe it has been orphaned, and is no longer being updated - perhaps another reason for switching to grub for the longer term.

Either way, my fix works for most people having issues - I haven't heard from anyone who has not succeeded with it.

Glad your system is running OK!

--
Pete

I have a new PC with an AMD Ryzen 7900 (with integrated GPU) and have hit this issue, and switching to grub works.

I noticed with grub that it takes approx 5s for boot up messages to appear after grub finished loading the initrd (and the video mode changed at the same time), and looking at those with dmesg after boot, those messages around the 5 second mark are about it using the efifb console.

I might try later to see if there's anything on the serial port console when it hangs with elilo (if the kernel runs at all after it "hangs"), and try to figure out exactly what the difference is between elilo and grub that allows grub to work, but that's driven purely by my irrational desire to avoid using grub. The CDROM's EFI boot binary already uses grub so this is a pointless exercise anyway. Is there a reason the usbboot.img can't be changed to just use grub by default as well?

I, too, hung back from using grub for a long time, and only adopted it when I hit this issue. I find the Slackware implementation much easier to setup and use than some other distros I've tried. Indeed, once I got my head around it and realised the benefits, I switched ALL my other machines over to grub, and haven't looked back. Perhaps Slackware's documentation is better! ;)

As a side benefit, a grub install USB makes a brilliant rescue disk! I recently had an issue with my main PC, which suddenly refused to recognise my SDD and came up with the dreaded "no system disk found" error. I plugged my old (and well out of date) install disk in, and the grub menu immediately found the broken Slackware installation, and asked me which of the two installed kernels I wanted to boot (I always keep a spare when updating the kernel!)! I selected the most recent kernel, which booted without issue straight back into Slackware. All I had to do was re-install grub and then update it, and my system was restored. Very quick and easy, though I still don't know what caused the problem in the first place. Its been fine since!

One last question: Whose BIOS does your system use? The machine that caused me all the grief initially uses an Insyde BIOS, and I've had issues with those in the past. It feels almost as if they are designed to work only with Windows, and can cause problems with anything else. I have no hard evidence for this, just that the two machines I have owned with Insyde BIOS have both caused issues with Linux, until I figured a work-around...

Anyway, glad your system is up and running!

--
Pete

Thanks, it's an AMI BIOS, version 1222, and in case it matters the mobo is ASUS TUF GAMING X670E.

Also re-reading this thread, it's not clear that your theory about 64-bit efifb has been ruled out, I don't see anywhere in Aeterna's post if their efifb is 32 or 64 bit.

This thread https://lkml.kernel.org/lkml/2015083...@redhat.com/T/ says "basically all GOP devices in the wild use a 32-bit frame buffer address." (in 2015), so I think it could still be true that 64 bit fbs are the issue (not saying it is true, just that it could be). Is there a way to check if it's 32 or 64 bit? If not then probably can add a printk to the kernel, in the same code that patch touched.

Heh! Heh! :)

I make no claims to being a programmer! I am a hobbyist tinkerer, though I've had to work with computers most of my life! I was taught some programming at college (Fortran IV on an IBM Mainframe and Focal on a PDP-8), but everything else I've picked up as I go along. I probably peaked with 6052 machine code (gives you some idea of my age!). I can follow reasonably straightforward C, but would hesitate to write anything in it!

Most of what I've written here has come from experimentation - ie: staggering around blindly in the dark! At first I was convinced the issue was the efi frame-buffer, but some - who seem to know more about it than me - have queried this. In short, I don't know, but I do know that my work-around works, and has some side benefits!

I would be interested to see any conclusions you come to, and its interesting that yours is a recent AMI bios. Perhaps I've been unkind to Insyde, but the very first 64bit machine I got also had an Insyde bios which caused me no end of grief initially.

I am running one Intel desktop, two Intel laptops (one is a junker used for test purposes!) and one (quite old) AMD desktop. All 64-bit, all running grub now.

Cheers,

--
Pete

Ok, I've done this now:
and managed to captured that by typing the following in blind (i.e. didn't need to find a serial cable):
and finally that showed:
(and all the other messages same as with grub, nothing helpful there). So, I think this rules out the 64 bit theory.

I'll go ahead with the installer now, also will see if elilo works as an installed boot loader, although I already tried copying the usbboot.img's elilo BOOTX64.EFI to the NVMe and tried booting that, but that hit the same issue.

> also will see if elilo works as an installed boot loader,

It doesn't, same problem, and this was with the installer creating an EFI menu entry, so that seems to be different from what you and others have reported. Copying grub's BOOTX64.efi to the EFI partition and booting that still worked.

Also this is much less about avoiding grub and more about getting the installer to just work out of the box, currently it doesn't, and no one even knows the pattern about exactly when it doesn't work...

Since it's still possible to login and type commands blindly, and capture dmesg, if anyone has ideas for things to try please let me know, thanks.

maybe use e.g.
also
does not mean that efifb is not 64-bit, it means that something requested by efifb is not 64-bit. Maybe BIOS is buggy.

On the laptop that gave me all the trouble (and kicked off this thread!), elilo worked once the installation was complete, but there was no initial screen (the one with the penguins) when booting. This implied to me that it was the initial framebuffer that was the culprit. However, it has also been pointed out (above somewhere) that the stock installer uses syslinux (?) and not lilo/elilo, so the problem could be different.

What put me onto grub was the fact that other distros that I tried worked perfectly - even SystemRescueCD - and they all used grub as the boot system. Once I configured the Slackware install medium to use grub, everything worked perfectly.

I have since tried the grub install media on a variety of systems, ancient and modern, and its the only one I've found that works on everything I've tried it on. As I said above, it also makes an excellent rescue system if the mbr gets damaged or overwritten.

I know that it works, but I leave the how's and why's to those better qualified than me!

;)

--
Pete

My kernel is 64 bit, of course.

It means it's not 64 bit in whatever respect the thread at https://lkml.kernel.org/lkml/2015083...@redhat.com/T/ is talking about this. That possibility to have *something* that's 32 or 64 bit is the question here, if that makes a difference to the problem in this thread. That thread says "basically all GOP devices in the wild use a 32-bit frame buffer address" and "possible to build firmware that uses a full 64-bit GOP frame buffer address". I do not see how you can conclude there is possibility of a buggy BIOS from this.

Hi Pete,

I've spent the weekend confirming that your original assertion that
is actually correct, and that's the reason for this boot failure.

I booted my patched kernel with grub, and that said:
and also this:

(I could have spotted the difference with elilo earlier, which said this:

)

0xfce0000000 is a 64bit address, and lspci -vv shows this as well which confirms it's 64bit:

Then, I found it's grub that's responsible for setting the 64 bit part (0xfc) of the address, it does this:

(here: https://git.savannah.gnu.org/cgit/gr...6/linux.c#n263). params is a struct that the bootloader has to fill in and pass to the kernel. Grub's is up to date, elilo has the equivalent params but its params just doesn't have ext_lfb_base and capabilities, hence sends the wrong 32bit address to the kernel, resulting in it failing to init the framebuffer.

Wow! Thanks for that! My initial diagnosis was that it was a framebuffer issue, but I got dissuaded by some comments from people that I assumed knew more about it than I did! As I say, I have no pretensions about being a programmer!

I still have a feeling that there might be more at play here than just the framebuffer. It is very difficult to tell if the computer is actually doing anything when the screen is blank. I'm not even sure if its possible to SSH into it at that stage in the process to find out. It *may* be that the setup program is actually running, but in the absence of any output to the monitor, it isn't easy to find out. Also, as I pointed out earlier, I think the Slackware install media doesn't use elilo, but syslinux - but it could still be the same problem.

The only universal solution I've found is to use grub on the install media. That doesn't mean you have to use grub once the install is complete, just that using anything other than grub on the install media may stop you from getting where you want to be.

One of the (many!) things I've always loved about Slackware is the simplicity of the installer. I really wouldn't want to see that change! However, with elilo seemingly being abandonware, and syslinux equally flawed on some hardware, I think out Beloved Leader may have to reconsider his choice of bootloader for the install media in the near future.

I can only see this issue becoming more prevalent in the future.

Again, many thanks for your hard and detailed work on this!

Cheers,

--
Pete

Ok, but where you said this:

did you mean it's blank until Xorg starts? I haven't got X working to test this yet (going to try slackware-current next in case that helps, since the GPU is very recent). It's confusing because I can say the same thing about Grub when it's working - the screen is blank until efifb loads and switches the video mode (at approx 5 seconds after boot), which is literally the kernel doing the video mode setting, KMS.

If yours is blank until X starts, then I'd assume this is still same problem I've got, but that still isn't really acceptable anyway - the installer would have to install grub instead of elilo to properly solve this, and I can't see that ever happening...

Also I thought the CDROM does use grub, see http://slackware.osuosl.org/slackwar...rrent/EFI/BOOT. It might also use syslinux, but I suspect an EFI BIOS is going to find that grub on the CD and boot that, instead of syslinux.

Just upgraded to slackware-current, and that fixed Xorg, and also did something else (for the same reason that Xorg now works), the boot events are as follows, with elilo:

1) elilo starts
2) kernel starts
3) efifb loads, still fails to make console visible, same as before
4) initrd starts
5) initrd asks for luks password (have to type this in blind as still can't see anything at this point)
6) initrd exits
7) amdgpu module loads (not included in initrd), this makes the text console visible, before X starts. You may have been referring to this post-efifb, pre-Xorg thing as KMS kicking in?

So the solution (for me) would be to put amdgpu in the initrd, but I would still like to know if elilo can be replaced with grub in the usbboot.img?

Or should I try and patch elilo to support 64 bit efifbs? It doesn't look that difficult now since I can see which bit of grub to copy/paste... Alien Bob or Patrick if you're reading this, please let me know, thanks.