[OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install
Chris
oidev at sunos.info
Sat Feb 6 21:36:59 UTC 2021
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.
>
> rgds,
> toomas
--Chris
>
>
>>>> thanks,
>>>> toomas
>>> --Chris
>>
--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX
More information about the openindiana-discuss
mailing list