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

Sun Feb 7 09:48:42 UTC 2021

> On 7. Feb 2021, at 09:04, Chris <oidev at sunos.info> wrote:
> 
> On 2021-02-06 13:36, Chris wrote:
>> On 2021-02-06 00:56, Toomas Soome wrote:
>>>> On 6. Feb 2021, at 01:41, Chris <oidev at sunos.info> wrote:
>>>> On 2021-02-05 14:16, Chris wrote:
>>>>> On 2021-02-05 13:46, Toomas Soome wrote:
>>>>>>> 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
>>>>> Thank you. I think you may have already told me that too. Sorry.
>>>>> But TBH, the differences are negligible. So I think my time is probably
>>>>> better spent tracking down the cause. :-)
>>>>>>> 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.
>>>>>> That's just two samples, you need more to draw conclusions:)
>>>>> I only _post_ 2 samples. I must have towards 50. But they were
>>>>> close enough to simply pick the first in these 2 installs. :-)
>>>>>>> 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.
>>>>> Thanks! Good idea. I could probably choose the previous env from the loader,
>>>>> and mark it default.
>>>>>> 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
>>>>> Will do.
>>>>> Thanks for taking the time to reply, Toomas! :-)
>>>> OK we have a winner! Thanks to some advice from Toomas:
>>>> adding: console=text to /boot/conf.d/console
>>>> which I later moved to /boot/loader.conf.local (console="text")
>>>> followed by commenting the console= line from /boot/default/loader.conf
>>>> I now have speed to boot menu that is close to the
>>>> OI-hipster-text-20191106.usb install I mentioned earlier in this thread.
>>>> While the screen still isn't as fast as the other some half dozen OSs
>>>> I use. It's not so slow I can't work with it. :-)
>>>> So a HUGE thanks go out to everyone here on the list, that chimed in
>>>> to help out -- THANK YOU! :-)
>>>> @moderator
>>>> Please mark this solved. ;-)
>>> The issue is still up, we do need better way to pick up serial config (ACPI SPCR);
>>> but workaround is good to have.
>>> Note, you do not need to have console=text in config if you have commented out the
>>> /boot/defaults/loader.conf line; however, defaults will be replaced by next
>>> update.
>> Well commenting the line in /boot/default/loader.conf seemed to prevent it from
>> polling for other possibilities. Of course I could be wrong. I'll check to confirm.
> CONFIRMED
> adding console="text" to /boot/loader.conf.local does NOT negate the
> ttya,ttyb,ttyc or ttyd entires in /boot/default/loader.conf if left UNcommented.
> 
> What's the magic incantation? :-)

When the interpreter is starting, we read in and process the following config files and in listed order:

/boot/solaris/bootenv.rc    # managed by eeprom command
/boot/defaults/loader.conf # defaults from pkg
/boot/loader.conf               # if present, distribution defaults from pkg
/boot/loader.conf.local      # user settings, if present
/boot/conf.d/*                    # user settings by snippets
/boot/transient.conf          # one time settings created by reboot command, automatically removed on boot.

This means that anything you set in later file (like in /boot/conf.d/somefile), can override previous setting. However, for console, as there may be some output while processing each file, “bad” setting in /boot/defaults/loader.conf can cause issues till replaced in later file.

rgds,
toomas