[OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

Toomas Soome tsoome at me.com
Fri Feb 5 21:46:39 UTC 2021



> On 5. Feb 2021, at 19:54, Chris <oidev at sunos.info> wrote:
> 
> On 2021-01-30 02:28, Toomas Soome wrote:
>>> On 30. Jan 2021, at 10:39, Chris <oidev at sunos.info> wrote:
>>> On 2021-01-30 00:03, Toomas Soome wrote:
>>>>> On 30. Jan 2021, at 09:40, Chris <oidev at sunos.info> wrote:
>>>>> On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:
>>>>>>> On 30. Jan 2021, at 03:43, Chris <oidev at sunos.info> wrote:
>>>>>>> On 2021-01-29 17:18, Andy Fiddaman wrote:
>>>>>>>> On Fri, 29 Jan 2021, Chris wrote:
>>>>>>>> ; OK just dragged a Dell Optiplex 790 off the shelf
>>>>>>>> ; with a 4 core 8 thread i5 CPU in it, and as much RAM
>>>>>>>> ; as I could jam in it.
>>>>>>>> ; BIOS:
>>>>>>>> ; boot UEFI
>>>>>>>> ; SATA ahci
>>>>>>>> ; I've tried 2 different Nvidia cards, as well as the
>>>>>>>> ; intermal video. The results are the same;
>>>>>>>> ; 2.5 minutes to get to the OI banner/boot options.
>>>>>>>> ; An additiona 3.5 to draw the OI banner/options screen.
>>>>>>>> ; It takes ~0.5 seconds to draw each cell. To be clear;
>>>>>>>> ; I'm not complaining here. Rather, I'm trying to
>>>>>>>> ; pinpoint WTF is going wrong in hopes of overcoming
>>>>>>>> ; the problem. I've attempted to put OI on 3 different
>>>>>>>> ; computers now, and the results have all been
>>>>>>>> ; underwhelming in the console dept.
>>>>>>>> ;
>>>>>>>> ; Any thoughts?
>>>>>>>> If you can press <escape> really early in the boot process, you get the
>>>>>>>> first loader prompt (I forget exactly how it looks). At that point,
>>>>>>>> enter "-t" without the quotes and press return. That will keep in
>>>>>>>> VGA mode, which might well be faster/usable.
>>>>>>> Huge thanks for the reply, Andy!
>>>>>>> Yes, it made a difference. Drawing each cell only takes 0.25
>>>>>>> seconds. :-P
>>>>>>> So somewhat faster, anyway. It's funny. It starts out quite
>>>>>>> fast. The speed I normally experience with other stuff. It
>>>>>>> writes
>>>>>>> Available consoles:
>>>>>>> text VGA ...
>>>>>>> ttya port 0x3f8
>>>>>>> ttyb ... not present
>>>>>>> ttyc ... not present
>>>>>>> ttyd ... not present
>>>>>>> null software device
>>>>>>> spin software device
>>>>>>> Right at this point is where it drops to about 1/2 or slower speed.
>>>>>>> Then, cell by cell, it prints
>>>>>>> console ttyb failed to initialize
>>>>>>> console ttyc failed to initialize
>>>>>>> console ttyd failed to initialize
>>>>>> This is the point where you have got hint about why this happens. The same defect
>>>>>> is with virtualbox, when you have configured host pipe for serial device.
>>>>>> The three lines above tell us that ttya was successfully initialized, so it must
>>>>>> have to do about ttya.
>>>>> OK I neglected to note that this was including the advice by Andy to drop to
>>>>> text mode, by interrupting loader, and entering -t at the prompt followed by
>>>>> enter. It's clear that it was attempting serial mode -- note the port 0x3f8
>>>>> Without interrupting loader, text and ttya return:
>>>>> text VESA (800x600 - 1600x1200 depending on what I'm hooked up to)
>>>>> ttya ... not present
>>>>> I'm attempting it again via Legacy where
>>>>> text VESA 1600x1200
>>>>> ttya ... not present
>>>>> Choosing 5 (options), followed by 5 (verbose) has already taken 20
>>>>> minutes (it's still in progress). I think I'm just going to try to
>>>>> install it and work on it further from the internal disk. In hopes
>>>>> of getting at least a small speed increase from 0 to actual boot.
>>>>> I greatly appreciate your insight on this, Toomas.
>>>> Ok, so this guess was not good one afterall. If you are doing CD (ISO) boot, you
>>>> will get loader started as first stage - that is, there is no way to enter
>>>> options; however, once you get out of menu and on O prompt, you can enter:
>>>> framebuffer off
>>>> on BIOS boot, this will switch to VGA text mode, on UEFI, it will switch terminal
>>>> draw from GOP Blt() to SimpleTextOutput protocol (gfx can not be switched off as
>>>> there is no VGA text mode in UEFI, there may not be even VGA).
>>>> If you are booting from USB stick, press space on very first spinner to get boot:
>>>> prompt, from there you can enter: -t as Andy was suggesting, it will start loader
>>>> in text mode, without switching to VBE framebuffer. Once the OS is installed, you
>>>> can create /boot/config with -t in it, this will achieve the same effect.
>>>> That much about workaround.
>>>> “normally”, if drawing in FB mode is slow, it will help to use lower resolution
>>>> and/or depth, but as you wrote, 800x600 was just as bad as 1920x1200, it means
>>>> something else is going on there.
>>>> You can set mode as: framebuffer set XxY[xD], where D is for depth, defaults to
>>>> 32, if not present. framebuffer list [depth] will list available modes. With BIOS
>>>> mode, you can also try something like 640x400 or 640x480, below that the terminal
>>>> will get too weird even with 6x12 font...
>>>> If depth 8 or 15/16 does not make it faster, it still means there is something
>>>> weird going on, and at this point, I’d suggest to check if there is firmware
>>>> update from vendor. (tbh, firmware update would be good as first check, the hw
>>>> vendors are known to produce a lot of bad things, especially if it comes to have
>>>> bios emulation with uefi csm.).
>>> Sure. Good point. But already updated it. You've given me some things to poke at.
>>> I'll give them a try, and see if anything interesting develops.
>>> Thank you very much for taking the time, Toomas. Greatly appreciated!
>> Well, I wrote that stuff;)
> You seemed like a nice person. It's a pity I have to hate you now for
> doing that. ;-)
> 
> Seriously tho. After some 5 days now poking at this, and only getting marginal
> improvements via different framebuffer settings (BTW how does one make a
> framebuffer setting stick from boot to boot?).

add framebuffer set … to /boot/loader.rc.local

> It occurred to me that I didn't recall having any of these problems on earlier
> SunOS/Solaris, or Illumos/OI installs. So I decided to walk back in history,
> and see if I could discover where the problem left/started. So, always choosing
> text install images, I went from OI-hipster-text-20201031.usb, to
> OI-hipster-text-20200504.usb, to OI-hipster-text-20191106.usb, and BINGO!
> Everything worked perfectly. The time to the boot options menu/banner was
> *instantaneous*. So I figured I'd simply walk the commits going forward to
> discover what introduced the slow screen writes.


hm, that is interesting finding.

> 
> On OI-hipster-text-20201031.usb:
> % time ls --color=force -Cla /usr/include/
> took 22.4s
> 
> On OI-hipster-text-20191106.usb:
> % time ls --color=force -Cla /usr/include/
> 0.000u  8.270s  0:08.28  99.8%
> That's 3 times faster!
> 
> Finding that many of the tools I need weren't available because I needed
> to bootstrap a newer version of pkg. I did the unthinkable, and issued
> pkg update -v
> Which of course required a reboot into the new environment. The results
> of the new environment was unrewarding. Getting to the boot options
> menu/banner screen took nearly 9 minutes. Now I'm back to square 0. :-(
> Altho illumos-3c2328bf3b:
> % time ls --color=force -Cla /usr/include/
> 0.008u  8.999s  0:09.11  98.6%
> Which is *technically* slower. The difference is negligible for sure.


Thats just two samples, you need more to draw conclusions:) 


> But the fonts don't seem as smooth. In all cases the EDID was read
> correctly (1920x1200 @32bpp). OH and if it matters, it's on an Intel
> chipset (Intel video).
> 
> Time to (re)install OI-hipster-text-20191106.usb and start over.
> 
> Any thoughts? Best places to look? I'd love to shorten the timeline
> to a (correctly) working install of OI. 7 days and counting.

Is it BIOS or UEFI setup? if bios, then all you need is to copy /boot/loader from older BE (beadm mount OLD /mnt; cp, then beadm umount). Just in case, make copy of existing one.

But, there are few things to keep in mind.

loader and kernel console draw are different things, the ls itself got some fixes recently.

So, is the performance degradation actually hitting only loader? 

Can you please mail me output from: tr '\0' '\n' < /system/boot/environment 

thanks,
toomas



More information about the openindiana-discuss mailing list