HOWTO prevent installation hangs on recent hardware

ldarby · 03-23-2023, 05:21 AM

Quote:

Originally Posted by Aeterna

maybe use
Quote:
file
e.g.
Quote:
file /usr/src/linux-6.2.7/drivers/video/fbdev/efifb.o
/usr/src/linux-6.2.7/drivers/video/fbdev/efifb.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

My kernel is 64 bit, of course.

Quote:

Originally Posted by Aeterna

Quote:
[ 6.837318] efifb: is not 64 bit
does not mean that efifb is not 64-bit, it means that something requested by efifb is not 64-bit. Maybe BIOS is buggy.

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.

ldarby · 03-26-2023, 12:23 PM

Hi Pete,

I've spent the weekend confirming that your original assertion that

Quote:

Elilo is not compliant with 64-bit efifb.

is actually correct, and that's the reason for this boot failure.

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

Quote:

efifb: is 64 bit

and also this:

Quote:

efifb: framebuffer at 0xfce0000000, using 3072k, total 3072k

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

Quote:

efifb: framebuffer at 0xe0000000, using 3072k, total 3072k

)

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

Quote:

10:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 164e (rev c4) (prog-if 00 [VGA controller])
...
Region 0: Memory at fce0000000 (64-bit, prefetchable) [size=256M]

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

Code:

#if defined (GRUB_MACHINE_EFI) && defined (__x86_64__)
  params->ext_lfb_base = (grub_size_t) (((grub_uint64_t)(grub_size_t) framebuffer) >> 32);
  params->capabilities |= VIDEO_CAPABILITY_64BIT_BASE;
#endif

(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.

pchristy · 03-26-2023, 01:12 PM

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

ldarby · 03-26-2023, 03:03 PM

Ok, but where you said this:

Quote:

And yes, once installed, elilo does boot the system, but the screen remains blank (no penguins) until KMS kicks in.

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.

ldarby · 03-26-2023, 04:37 PM

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.

pchristy · 03-27-2023, 02:33 AM

Yes, that's exactly what I mean. Post install, and without grub, the system starts but the initial low resolution screen (the one with the penguins) is blank. After a few seconds - when the resolution changes (which I assume is kms starting) - and the text console becomes visible.

I boot into sddm (run level 4 in inittab), and sddm starts normally. Once logged in at sddm, then X (or Wayland, if you make that choice) starts and you are into your graphic environment.

With grub, everything is visible right from the start, and you get the "penguin" screen.

The problem that Eric and Patrick will face is that the installer needs to be generic - ie: work on any system. I've no doubt it is possible to put the amd module in the initrd, but would that also work for NVidia, Intel or any other graphics card. Very unlikely, I would have thought, and putting every possible combination in becomes messy!

Once you have managed to install the system, it is quite simple to rebuild the initrd to your requirements. The problem I was facing was that the installer either wouldn't run at all, or was running "invisibly" - in either event, not very helpful!

Even grub on the installer is not truly universal because, as I understand it, you need to choose between UEFI or non-UEFI when creating the boot media. I may be wrong here, as I haven't tried a non-UEFI install media on a UEFI machine, but I think it would create a non-UEFI installation. It may be possible to work around this (if I'm right), but that's a bit above my pay grade!

Another advantage of using grub on the install media is that it makes a truly excellent recovery disk! If the problem is simply mbr corruption (ie: windows had over-written it, as it is prone to do!), then booting from a grub install disk, created as I describe, will find all the installed systems and allow you to boot straight into any of them! Then its just a matter of re-installing whichever boot system you choose. Simples!

I believe elilo is no longer supported by the original maintainer, but that doesn't mean that someone else cannot take it over - or create a fork! If you manage to patch it, submit it to Patrick! I'm sure he would be interested. However, that doesn't help with the install media, which uses syslinux rather than elilo, as I understand it.

--
Pete

colinh2 · 04-17-2023, 07:30 AM

Thanks Pete!

This solved my installer boot problem on a Dell XPS13 (9343) from 2015.

In my case nothing even started to boot: I just got asked to "press F1 to retry booting" etc.

With your suggestions the installer booted and ran fine. Only when actually installing the packages did the screen flicker occasionally.

Have to say I found AlienBob's reaction a bit ... odd.

pchristy · 04-17-2023, 07:41 AM

Glad it worked for you, Colin.

I was bit puzzled by AlienBob's reaction too, but I put it down to me perhaps not explaining as clearly as I might have done (too close to the problem!) and English not being his first language - though he does seem pretty fluent.

Either way, the grub fix works, and at the end of the day that is what matters!

Cheers,

--
Pete

ldarby · 04-17-2023, 08:04 AM

After my last comment above I emailed Pat asking if there's any possibility of him including a patch for elilo, but he didn't respond, so I'm not going to gamble spending my time on creating this patch in the hope he starts responding once the patch is created.

pchristy · 04-17-2023, 10:00 AM

Yes, I pointed him to this thread shortly after I started it, but it failed to produce a response. I didn't pursue it, heeding the warning "Do not meddle in the affairs of wizards, for they are subtle and quick to anger."

--
Pete

ldarby · 04-27-2023, 06:16 PM

Aha! I was just in the BIOS and spotted this option:

Advanced > PCI > Above 4G Decoding
which has help text:

Quote:

Enables or Disables 64bit capable Devices to be Decoded in Above 4G Address Space (Only if System Supports 64 bit PCI Decoding)

I disabled that, which changed the PCI address to a 32 bit one:

Code:

10:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raphael (rev c4) (prog-if 00 [VGA controller])
        Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]

and now elilo (and the USB installer) works.

(Edit: fixed typo & formatting)

pchristy · 04-28-2023, 03:07 AM

Good spot! However, I've just had a look at my BIOS, and it doesn't offer that setting. In fact, it doesn't offer much at all! It is an Insyde BIOS, and they seem to offer the absolute minimum they an get away with! My first 64-bit computer also had an Insyde BIOS, which was also a pain to deal with...

Your info might help others though, so well done! It also confirms one of my original conjectures!

Cheers,

--
Pete

Kowalczyk · 09-27-2023, 04:58 AM

Hi.

I created a bootable usb using dd and it worked.

The installation went perfectly but when I try to boot it is stuck on loading initrd.gz

This is Slackware 15.0.

It works on slackware current but I want to use the stable version.

So any tips for what can be wrong?

rizitis · 09-27-2023, 02:33 PM

first make a deep format to your usb stick

its better to use this tool

Code:

http://www.slackware.com/~alien/liveslak/iso2usb.sh

command should be like this

Code:

# ./iso2usb.sh -i slackware.iso -o /dev/sdX -P

if you prefer dd then leave it without write speed

Code:

dd if=slackware.iso of=/dev/sdX status=progress

pchristy · 09-28-2023, 06:52 AM

Quote:

Originally Posted by Kowalczyk

Hi.

I created a bootable usb using dd and it worked.

The installation went perfectly but when I try to boot it is stuck on loading initrd.gz

This is Slackware 15.0.

It works on slackware current but I want to use the stable version.

So any tips for what can be wrong?

Have you tried switching it to grub as the bootloader? What did you select as the bootloader during installation?

It may be the same issue that stopped the installer running as outlined at the start of this thread, but without more information its difficult to say. My preferred method of creating boot media is to use AlienBob's excellent usbimg2disk.sh. It comes with instructions included (open it with a text reader) but does require access to a local copy of the slackware "tree". I have a small NAS (RaspberryPi + OpenMediaVault) where I keep an clone of the Slackware tree, which makes it very easy to make install media.

You should be able to find usbimg2disk.sh in the usb-andpxe-installers folder of Slackware15. If you have the slackware iso file, you should be able to loop mount this and use it as the source for usbimg2disk, but I haven't tried that!

Otherwise, re-install, but try selecting grub as the boot loader!

--
Pete