[OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install
Chris
oidev at sunos.info
Sun Feb 7 18:20:46 UTC 2021
On 2021-02-07 01:48, Toomas Soome wrote:
>> 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.
That's what I thought. Much the same as on FreeBSD. I was hoping I might
learn
that there was a no_console= or console_ttya="NO" line that might be
available.
I guess commenting the line /boot/default/loader.conf is the current
solution.
Remembering to re-comment it following updates.
Thanks for the reply, Toomas.
>
> rgds,
> toomas
--Chris
--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX
More information about the openindiana-discuss
mailing list