> On 4. Jan 2021, at 18:22, John Kennedy wrote: > > This is a little weird. > > Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 29th), > I've lost the screen in the boot loader. This is really weird because I > didn't update the boot loader (in quite a while, actually), but I suppose it > might drag some stuff off of the disk and misbehave. > > But the system boots, presumably after the countdown that I can't see, I just > have to SSH in from a different machine to tweak things. Just no screen at > all past the GELI encrypted disk password prompt (and some usual noise as > it complains about some padding that I've seen forever). > > I used to just upgrade the boot loader around ZFS upgrades, and I haven't > done that since OpenZFS got merged. I just got overly conservative there > and may have missed the "all clear" for all combinations of ZFS and the > bootloader recognizing them. > > The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust > those dates above (I pulled it ~Jan 3rd and let it compile overnight), but > I'm going to repull all the sources and recompile, just in case. I might > have initiall pulled it during the git conversion and maybe it is confused. >
On Mon, Jan 04, 2021 at 06:30:38PM +0200, Toomas Soome wrote: > Yes, it is known defect, and I???m searching for cause; the issue is with /boot/loader and BIOS text mode (unfortunately I have the usual ???but it is working for me??? case). For workaround, you can try to either: 1 (blind) press esc to get out of boot menu, then enter: vbe on; another option is to add hw.vga.textmode=???0??? to loader.conf. > > Sorry for confusion, > toomas
On Mon, Jan 4, 2021 at 11:35 AM John Kennedy wrote: > On Mon, Jan 04, 2021 at 06:30:38PM +0200, Toomas Soome wrote: > > Yes, it is known defect, and I???m searching for cause; the issue is > with /boot/loader and BIOS text mode (unfortunately I have the usual ???but > it is working for me??? case). For workaround, you can try to either: 1 > (blind) press esc to get out of boot menu, then enter: vbe on; another > option is to add hw.vga.textmode=???0??? to loader.conf. > > > > Sorry for confusion, > > toomas > > Yeah, that is a BIOS (vs UEFI) system. Adding hw.vga.textmode=0 worked, > and I like the graphical demon for what that's worth. (: > > I've also upgraded the bootcode, although that may mean nothing if the > textmode is avoiding the problem. > > In any case, I guess I have a known-bad (?) system, so if I can help you > out in some way let me know. Bonking that box every now and then isn't a > problem for me. >
On Mon, Jan 04, 2021 at 11:39:08AM -0700, Warner Losh wrote: > Yea, this is a feature that needs to be fixed since black on black text is > a show stopper :(
On Mon, Jan 4, 2021 at 11:53 AM John Kennedy wrote: > On Mon, Jan 04, 2021 at 11:39:08AM -0700, Warner Losh wrote: > > Yea, this is a feature that needs to be fixed since black on black text > is > > a show stopper :( > > Ah, this is part of the "Terminal colours in current" thread? I saw > that, > but didn't correlate it with default black-on-black text. It looked like > more of a graphics-mode glitch (blank screen, backlit, signal) initially, > I'd > just not seen something like that bite me at the bootloader stage before. >
> On 4. Jan 2021, at 18:30, Toomas Soome wrote: > > > >> On 4. Jan 2021, at 18:22, John Kennedy wrote: >> >> This is a little weird. >> >> Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 29th), >> I've lost the screen in the boot loader. This is really weird because I >> didn't update the boot loader (in quite a while, actually), but I suppose it >> might drag some stuff off of the disk and misbehave. >> >> But the system boots, presumably after the countdown that I can't see, I just >> have to SSH in from a different machine to tweak things. Just no screen at >> all past the GELI encrypted disk password prompt (and some usual noise as >> it complains about some padding that I've seen forever). >> >> I used to just upgrade the boot loader around ZFS upgrades, and I haven't >> done that since OpenZFS got merged. I just got overly conservative there >> and may have missed the "all clear" for all combinations of ZFS and the >> bootloader recognizing them. >> >> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust >> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but >> I'm going to repull all the sources and recompile, just in case. I might >> have initiall pulled it during the git conversion and maybe it is confused. >> > > hi! > > Yes, it is known defect, and I’m searching for cause; the issue is with /boot/loader and BIOS text mode (unfortunately I have the usual ‘but it is working for me’ case). For workaround, you can try to either: 1 (blind) press esc to get out of boot menu, then enter: vbe on; another option is to add hw.vga.textmode=“0” to loader.conf. > > Sorry for confusion, > toomas >
> > > > > On 4. Jan 2021, at 18:30, Toomas Soome wrote: > > > > > > > >> On 4. Jan 2021, at 18:22, John Kennedy wrote: > >> > >> This is a little weird. > >> > >> Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 29th), > >> I've lost the screen in the boot loader. This is really weird because I > >> didn't update the boot loader (in quite a while, actually), but I suppose it > >> might drag some stuff off of the disk and misbehave. > >> > >> But the system boots, presumably after the countdown that I can't see, I just > >> have to SSH in from a different machine to tweak things. Just no screen at > >> all past the GELI encrypted disk password prompt (and some usual noise as > >> it complains about some padding that I've seen forever). > >> > >> I used to just upgrade the boot loader around ZFS upgrades, and I haven't > >> done that since OpenZFS got merged. I just got overly conservative there > >> and may have missed the "all clear" for all combinations of ZFS and the > >> bootloader recognizing them. > >> > >> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust > >> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but > >> I'm going to repull all the sources and recompile, just in case. I might > >> have initiall pulled it during the git conversion and maybe it is confused. > >> > > > > hi! > > > > Yes, it is known defect, and I’m searching for cause; the issue is with /boot/loader and BIOS text mode (unfortunately I have the usual ‘but it is working for me’ case). For workaround, you can try to either: 1 (blind) press esc to get out of boot menu, then enter: vbe on; another option is to add hw.vga.textmode=“0” to loader.conf. > > > > Sorry for confusion, > > toomas > > > > the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be cool if you can verify:) > > thanks, > toomas
> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be cool if you can verify:)
On Tue, Jan 05, 2021 at 02:58:02AM +0100, Idwer Vollering wrote: > I had more success with this patch, applied on top of 7beeacb27b27 (in > other words: call vbe_is_vga() from cons_update_mode() instead of > vidc_install_font() ): ...
> On 5. Jan 2021, at 00:59, Toomas Soome wrote: > > > >> On 4. Jan 2021, at 18:30, Toomas Soome <tsoome@me.com > wrote: >> >> >> >>> On 4. Jan 2021, at 18:22, John Kennedy <warlock@phouka.net > wrote: >>> >>> This is a little weird. >>> >>> Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 29th), >>> I've lost the screen in the boot loader. This is really weird because I >>> didn't update the boot loader (in quite a while, actually), but I suppose it >>> might drag some stuff off of the disk and misbehave. >>> >>> But the system boots, presumably after the countdown that I can't see, I just >>> have to SSH in from a different machine to tweak things. Just no screen at >>> all past the GELI encrypted disk password prompt (and some usual noise as >>> it complains about some padding that I've seen forever). >>> >>> I used to just upgrade the boot loader around ZFS upgrades, and I haven't >>> done that since OpenZFS got merged. I just got overly conservative there >>> and may have missed the "all clear" for all combinations of ZFS and the >>> bootloader recognizing them. >>> >>> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust >>> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but >>> I'm going to repull all the sources and recompile, just in case. I might >>> have initiall pulled it during the git conversion and maybe it is confused. >>> >> >> hi! >> >> Yes, it is known defect, and I’m searching for cause; the issue is with /boot/loader and BIOS text mode (unfortunately I have the usual ‘but it is working for me’ case). For workaround, you can try to either: 1 (blind) press esc to get out of boot menu, then enter: vbe on; another option is to add hw.vga.textmode=“0” to loader.conf. >> >> Sorry for confusion, >> toomas >> > > the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be cool if you can verify:) > > thanks, > toomas
On 2021-Jan-5, at 14:46, Toomas Soome <tsoome at me.com> wrote: > On 5. Jan 2021, at 00:59, Toomas Soome wrote: >> >> >> >>> On 4. Jan 2021, at 18:30, Toomas Soome wrote: >>> >>> >>> >>>> On 4. Jan 2021, at 18:22, John Kennedy wrote: >>>> >>>> This is a little weird. >>>> >>>> Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 29th), >>>> I've lost the screen in the boot loader. This is really weird because I >>>> didn't update the boot loader (in quite a while, actually), but I suppose it >>>> might drag some stuff off of the disk and misbehave. >>>> >>>> But the system boots, presumably after the countdown that I can't see, I just >>>> have to SSH in from a different machine to tweak things. Just no screen at >>>> all past the GELI encrypted disk password prompt (and some usual noise as >>>> it complains about some padding that I've seen forever). >>>> >>>> I used to just upgrade the boot loader around ZFS upgrades, and I haven't >>>> done that since OpenZFS got merged. I just got overly conservative there >>>> and may have missed the "all clear" for all combinations of ZFS and the >>>> bootloader recognizing them. >>>> >>>> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust >>>> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but >>>> I'm going to repull all the sources and recompile, just in case. I might >>>> have initiall pulled it during the git conversion and maybe it is confused. >>>> >>> >>> hi! >>> >>> Yes, it is known defect, and I’m searching for cause; the issue is with /boot/loader and BIOS text mode (unfortunately I have the usual ‘but it is working for me’ case). For workaround, you can try to either: 1 (blind) press esc to get out of boot menu, then enter: vbe on; another option is to add hw.vga.textmode=“0” to loader.conf. >>> >>> Sorry for confusion, >>> toomas >>> >> >> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be cool if you can verify:) >> >> thanks, >> toomas > > I think, I got it fixed (at least idwer did confirm for his system, thanks). If you can test this patch: http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch it would be really nice. >
On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: > ... > > the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be cool if you can verify:) > > > > thanks, > > toomas > > I think, I got it fixed (at least idwer did confirm for his system, thanks). If you can test this patch: http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch <http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch> it would be really nice. > > thanks, > toomas
On 2021-Jan-5, at 17:54, David Wolfskill <david at catwhisker.org> wrote: > On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: >> ... >>> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be cool if you can verify:) >>> >>> thanks, >>> toomas >> >> I think, I got it fixed (at least idwer did confirm for his system, thanks). If you can test this patch: http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch <http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch> it would be really nice. >> >> thanks, >> toomas > > I tested with each of the following "stanzas' in /boot/loader.conf, > using vt (vs. syscons) in each case (though that breaks video reset > on resume after suspend): > > . . .
> # hw.vga.textmode="0" > # vbe_max_resolution=1280x800 > > (That is, not specifying anything for hw.vga.textmode or > vbe_max_resolution.) > > This boots OK, but I see no kernel probe messages or single- to > multi-user mode messages. I can use (e.g.) Ctl+Alt+F2 to switch to > vty1, see a "login: " prompt, and that (also) works. (This is the > initial symptom I had reported.)
> hw.vga.textmode="1" > # vbe_max_resolution=1280x800 > > This works -- boots OK, and I see kernel probe (&c.) messages; this is a > text console (mostly blue text; some white, against a dark background. > It's a medium-light blue, so it's easy enough to read (unlike a navy > blue, for example).
> > > On 2021-Jan-5, at 17:54, David Wolfskill <david at catwhisker.org> wrote: > > > On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: > >> ... > >>> the 58661b3ba9eb should hopefully fix the loader text mode issue, it woul > d be cool if you can verify:) > >>> > >>> thanks, > >>> toomas > >> > >> I think, I got it fixed (at least idwer did confirm for his system, thanks > ). If you can test this patch: http://148-52-235-80.sta.estpak.ee/0001-loader > -rewrite-font-install.patch <http://148-52-235-80.sta.estpak.ee/0001-loader-r > ewrite-font-install.patch> it would be really nice. > >> > >> thanks, > >> toomas > > > > I tested with each of the following "stanzas' in /boot/loader.conf, > > using vt (vs. syscons) in each case (though that breaks video reset > > on resume after suspend): > > > > . . . > > I've done no experiments with an explicit vbe_max_resolution > setting. My context for hw.vga.textmode="0" shows up as > 1920x1200. (I do have the font for this set to 8x16, making > for lots of character cells across and down.) > > > For the below I do not have hw.vga.textmode="0". > > > # hw.vga.textmode="0"
> > # vbe_max_resolution=1280x800 > > > > (That is, not specifying anything for hw.vga.textmode or > > vbe_max_resolution.) > > > > This boots OK, but I see no kernel probe messages or single- to > > multi-user mode messages. I can use (e.g.) Ctl+Alt+F2 to switch to > > vty1, see a "login: " prompt, and that (also) works. (This is the > > initial symptom I had reported.) > > So I tried commenting out hw.vga.textmode="1" and I saw everything > I expected in my context. Whiteish on black background (or at least > something very dark). I did not take videos to do detailed > inspections.
> > > > hw.vga.textmode="1" > > # vbe_max_resolution=1280x800 > > > > This works -- boots OK, and I see kernel probe (&c.) messages; this is a > > text console (mostly blue text; some white, against a dark background. > > It's a medium-light blue, so it's easy enough to read (unlike a navy > > blue, for example). > > FYI: whiteish on black (or at least something very dark) > in my hw.vga.textmode="1" context. I saw everything here > as well. I did not take videos to do detailed inspections. > > I did not notice any way to tell hw.vga.textmode="1" from > having no hw.vga.textmode assignment at all. But, again, > I did not set up for an after-the-fact detailed review of > what is displayed.
On 2021-Jan-6, at 09:51, Cy Schubert <Cy.Schubert at cschubert.com> wrote: > In message <63A29589-22B5-495B-8E0D-14E13091D939@yahoo.com>, Mark Millard > write > s: >> >> >> On 2021-Jan-5, at 17:54, David Wolfskill <david at catwhisker.org> wrote: >> >>> On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: >>>> ... >>>>> the 58661b3ba9eb should hopefully fix the loader text mode issue, it woul >> d be cool if you can verify:) >>>>> >>>>> thanks, >>>>> toomas >>>> >>>> I think, I got it fixed (at least idwer did confirm for his system, thanks >> ). If you can test this patch: http://148-52-235-80.sta.estpak.ee/0001-loader >> -rewrite-font-install.patch <http://148-52-235-80.sta.estpak.ee/0001-loader-r >> ewrite-font-install.patch> it would be really nice. >>>> >>>> thanks, >>>> toomas >>> >>> I tested with each of the following "stanzas' in /boot/loader.conf, >>> using vt (vs. syscons) in each case (though that breaks video reset >>> on resume after suspend): >>> >>> . . . >> >> I've done no experiments with an explicit vbe_max_resolution >> setting. My context for hw.vga.textmode="0" shows up as >> 1920x1200. (I do have the font for this set to 8x16, making >> for lots of character cells across and down.) >> >> >> For the below I do not have hw.vga.textmode="0". >> >>> # hw.vga.textmode="0" > > textmode=1 doesn't work either. Been using it for years and this is the > first time it's borked. > >>> # vbe_max_resolution=1280x800 >>> >>> (That is, not specifying anything for hw.vga.textmode or >>> vbe_max_resolution.) >>> >>> This boots OK, but I see no kernel probe messages or single- to >>> multi-user mode messages. I can use (e.g.) Ctl+Alt+F2 to switch to >>> vty1, see a "login: " prompt, and that (also) works. (This is the >>> initial symptom I had reported.) >> >> So I tried commenting out hw.vga.textmode="1" and I saw everything >> I expected in my context. Whiteish on black background (or at least >> something very dark). I did not take videos to do detailed >> inspections. > > Didn't work for me. Then again my old eyes didn't detect much difference in > contrast. > >> >> >>> hw.vga.textmode="1" >>> # vbe_max_resolution=1280x800 >>> >>> This works -- boots OK, and I see kernel probe (&c.) messages; this is a >>> text console (mostly blue text; some white, against a dark background. >>> It's a medium-light blue, so it's easy enough to read (unlike a navy >>> blue, for example). >> >> FYI: whiteish on black (or at least something very dark) >> in my hw.vga.textmode="1" context. I saw everything here >> as well. I did not take videos to do detailed inspections. >> >> I did not notice any way to tell hw.vga.textmode="1" from >> having no hw.vga.textmode assignment at all. But, again, >> I did not set up for an after-the-fact detailed review of >> what is displayed. > > Everything becomes normal when X starts, except for the three machines > downstairs which don't use X.
On Wed, 6 Jan 2021, Mark Millard wrote: > > > On 2021-Jan-6, at 09:51, Cy Schubert <Cy.Schubert at cschubert.com> wrote: > >> In message <63A29589-22B5-495B-8E0D-14E13091D939@yahoo.com>, Mark Millard >> write >> s: >>> >>> >>> On 2021-Jan-5, at 17:54, David Wolfskill <david at catwhisker.org> wrote: >>> >>>> On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: >>>>> ... >>>>>> the 58661b3ba9eb should hopefully fix the loader text mode issue, it woul >>> d be cool if you can verify:) >>>>>> >>>>>> thanks, >>>>>> toomas >>>>> >>>>> I think, I got it fixed (at least idwer did confirm for his system, thanks >>> ). If you can test this patch: http://148-52-235-80.sta.estpak.ee/0001-loader >>> -rewrite-font-install.patch <http://148-52-235-80.sta.estpak.ee/0001-loader-r >>> ewrite-font-install.patch> it would be really nice. >>>>> >>>>> thanks, >>>>> toomas >>>> >>>> I tested with each of the following "stanzas' in /boot/loader.conf, >>>> using vt (vs. syscons) in each case (though that breaks video reset >>>> on resume after suspend): >>>> >>>> . . . >>> >>> I've done no experiments with an explicit vbe_max_resolution >>> setting. My context for hw.vga.textmode="0" shows up as >>> 1920x1200. (I do have the font for this set to 8x16, making >>> for lots of character cells across and down.) >>> >>> >>> For the below I do not have hw.vga.textmode="0". >>> >>>> # hw.vga.textmode="0" >> >> textmode=1 doesn't work either. Been using it for years and this is the >> first time it's borked. >> >>>> # vbe_max_resolution=1280x800 >>>> >>>> (That is, not specifying anything for hw.vga.textmode or >>>> vbe_max_resolution.) >>>> >>>> This boots OK, but I see no kernel probe messages or single- to >>>> multi-user mode messages. I can use (e.g.) Ctl+Alt+F2 to switch to >>>> vty1, see a "login: " prompt, and that (also) works. (This is the >>>> initial symptom I had reported.) >>> >>> So I tried commenting out hw.vga.textmode="1" and I saw everything >>> I expected in my context. Whiteish on black background (or at least >>> something very dark). I did not take videos to do detailed >>> inspections. >> >> Didn't work for me. Then again my old eyes didn't detect much difference in >> contrast. >> >>> >>> >>>> hw.vga.textmode="1" >>>> # vbe_max_resolution=1280x800 >>>> >>>> This works -- boots OK, and I see kernel probe (&c.) messages; this is a >>>> text console (mostly blue text; some white, against a dark background. >>>> It's a medium-light blue, so it's easy enough to read (unlike a navy >>>> blue, for example). >>> >>> FYI: whiteish on black (or at least something very dark) >>> in my hw.vga.textmode="1" context. I saw everything here >>> as well. I did not take videos to do detailed inspections. >>> >>> I did not notice any way to tell hw.vga.textmode="1" from >>> having no hw.vga.textmode assignment at all. But, again, >>> I did not set up for an after-the-fact detailed review of >>> what is displayed. >> >> Everything becomes normal when X starts, except for the three machines >> downstairs which don't use X. > > FYI: My testing did not span using X. I do build lumina, but > basically as part of an environment cross-check on building, > not for use. Still, I could try to start lumina if needed. > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > >
On Wed, Jan 06, 2021 at 02:40:32PM -0800, Mark Millard wrote: > ... screen.textmode="0" works, including with screen.font="8x16" . There > is a difference, in that it displays some material at the very beginning > that it was not displaying since the recent problems started (until now > or so). This initial material displays in screen.textmode="1" style before > the display switches to the screen.textmode="0" style of display for alter > output. (I'm not complaining, just noting the visible sequence.)
On 1/5/21 8:54 PM, David Wolfskill wrote: > On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: >> ... >>> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be cool if you can verify:) >>> >>> thanks, >>> toomas >> >> I think, I got it fixed (at least idwer did confirm for his system, thanks). If you can test this patch: http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch <http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch> it would be really nice. >> >> thanks, >> toomas > > I tested with each of the following "stanzas' in /boot/loader.conf, > using vt (vs. syscons) in each case (though that breaks video reset > on resume after suspend): > > # hw.vga.textmode="0" > vbe_max_resolution=1280x800 > > This works, and provides a graphical console (depth 32). > > > hw.vga.textmode="0" > # vbe_max_resolution=1280x800 > > This also works, and provides a low-resolution (and depth 16) > graphical console (800x320 or something similar, IIRC). > > > # hw.vga.textmode="0" > # vbe_max_resolution=1280x800 > > (That is, not specifying anything for hw.vga.textmode or > vbe_max_resolution.) > > This boots OK, but I see no kernel probe messages or single- to > multi-user mode messages. I can use (e.g.) Ctl+Alt+F2 to switch to > vty1, see a "login: " prompt, and that (also) works. (This is the > initial symptom I had reported.) > > > hw.vga.textmode="1" > # vbe_max_resolution=1280x800 > > This works -- boots OK, and I see kernel probe (&c.) messages; this is a > text console (mostly blue text; some white, against a dark background. > It's a medium-light blue, so it's easy enough to read (unlike a navy > blue, for example). > > > FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 main-c255601-g9fd96b416c45-dirty: Tue Jan 5 17:24:45 PST 2021 root@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 > > Peace, > david >
On 1/14/21 4:49 AM, monochrome wrote: > I should add my experience to this since its different and haven't > seen anyone else mention it. > I see the new boot loader, it's not blank, but its large text, and > it's very SLOW. > I can see each char drawn, and then when it gets to the bottom and has > to redraw all the lines to scroll up for new lines, it loads so slowly > it's like watching an 8086 on a 300 baud modem, or slower! Takes like > an extra 30 seconds to get through all the loaded modules, then back > to normal speed boot with the same large font. > > added these lines and everything is back to normal with new appearance > and small font like before, and at normal speed. > hw.vga.textmode="0" > vbe_max_resolution=1280x800 > > also removed the old lines for the amdgpu efi problem with no effect > so I assume those are no longer necessary and why I'm seeing this change? > #hw.syscons.disable=1 > #kern.vty=vt > #hw.vga.textmode=1 > > am using X and everything seems fine for now > > system: > AMD Ryzen 5 2400G, using integrated vega GPU > ASRock B450M Pro4 > 13-current > > > > On 1/5/21 8:54 PM, David Wolfskill wrote: >> On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: >>> ... >>>> the 58661b3ba9eb should hopefully fix the loader text mode issue, >>>> it would be cool if you can verify:) >>>> >>>> thanks, >>>> toomas >>> >>> I think, I got it fixed (at least idwer did confirm for his system, >>> thanks). If you can test this patch: >>> http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch >>> <http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch> >>> it would be really nice. >>> >>> thanks, >>> toomas >> >> I tested with each of the following "stanzas' in /boot/loader.conf, >> using vt (vs. syscons) in each case (though that breaks video reset >> on resume after suspend): >> >> # hw.vga.textmode="0" >> vbe_max_resolution=1280x800 >> >> This works, and provides a graphical console (depth 32). >> >> >> hw.vga.textmode="0" >> # vbe_max_resolution=1280x800 >> >> This also works, and provides a low-resolution (and depth 16) >> graphical console (800x320 or something similar, IIRC). >> >> >> # hw.vga.textmode="0" >> # vbe_max_resolution=1280x800 >> >> (That is, not specifying anything for hw.vga.textmode or >> vbe_max_resolution.) >> >> This boots OK, but I see no kernel probe messages or single- to >> multi-user mode messages. I can use (e.g.) Ctl+Alt+F2 to switch to >> vty1, see a "login: " prompt, and that (also) works. (This is the >> initial symptom I had reported.) >> >> >> hw.vga.textmode="1" >> # vbe_max_resolution=1280x800 >> >> This works -- boots OK, and I see kernel probe (&c.) messages; this is a >> text console (mostly blue text; some white, against a dark background. >> It's a medium-light blue, so it's easy enough to read (unlike a navy >> blue, for example). >> >> >> FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 >> main-c255601-g9fd96b416c45-dirty: Tue Jan 5 17:24:45 PST 2021 >> root@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY >> amd64
On Thu, Jan 14, 2021 at 12:15 AM Jakob Alvermark wrote: > > On 1/14/21 4:49 AM, monochrome wrote: > > I should add my experience to this since its different and haven't > > seen anyone else mention it. > > I see the new boot loader, it's not blank, but its large text, and > > it's very SLOW. > > I can see each char drawn, and then when it gets to the bottom and has > > to redraw all the lines to scroll up for new lines, it loads so slowly > > it's like watching an 8086 on a 300 baud modem, or slower! Takes like > > an extra 30 seconds to get through all the loaded modules, then back > > to normal speed boot with the same large font. > > > > added these lines and everything is back to normal with new appearance > > and small font like before, and at normal speed. > > hw.vga.textmode="0" > > vbe_max_resolution=1280x800 > > > > also removed the old lines for the amdgpu efi problem with no effect > > so I assume those are no longer necessary and why I'm seeing this change? > > #hw.syscons.disable=1 > > #kern.vty=vt > > #hw.vga.textmode=1 > > > > am using X and everything seems fine for now > > > > system: > > AMD Ryzen 5 2400G, using integrated vega GPU > > ASRock B450M Pro4 > > 13-current > > > > > > > > On 1/5/21 8:54 PM, David Wolfskill wrote: > >> On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: > >>> ... > >>>> the 58661b3ba9eb should hopefully fix the loader text mode issue, > >>>> it would be cool if you can verify:) > >>>> > >>>> thanks, > >>>> toomas > >>> > >>> I think, I got it fixed (at least idwer did confirm for his system, > >>> thanks). If you can test this patch: > >>> > http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch > >>> < > http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch> > > >>> it would be really nice. > >>> > >>> thanks, > >>> toomas > >> > >> I tested with each of the following "stanzas' in /boot/loader.conf, > >> using vt (vs. syscons) in each case (though that breaks video reset > >> on resume after suspend): > >> > >> # hw.vga.textmode="0" > >> vbe_max_resolution=1280x800 > >> > >> This works, and provides a graphical console (depth 32). > >> > >> > >> hw.vga.textmode="0" > >> # vbe_max_resolution=1280x800 > >> > >> This also works, and provides a low-resolution (and depth 16) > >> graphical console (800x320 or something similar, IIRC). > >> > >> > >> # hw.vga.textmode="0" > >> # vbe_max_resolution=1280x800 > >> > >> (That is, not specifying anything for hw.vga.textmode or > >> vbe_max_resolution.) > >> > >> This boots OK, but I see no kernel probe messages or single- to > >> multi-user mode messages. I can use (e.g.) Ctl+Alt+F2 to switch to > >> vty1, see a "login: " prompt, and that (also) works. (This is the > >> initial symptom I had reported.) > >> > >> > >> hw.vga.textmode="1" > >> # vbe_max_resolution=1280x800 > >> > >> This works -- boots OK, and I see kernel probe (&c.) messages; this is a > >> text console (mostly blue text; some white, against a dark background. > >> It's a medium-light blue, so it's easy enough to read (unlike a navy > >> blue, for example). > >> > >> > >> FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 > >> main-c255601-g9fd96b416c45-dirty: Tue Jan 5 17:24:45 PST 2021 > >> root@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > > >> amd64 > > > +1 on the slowness. > > I like the graphics mode, it's very pretty. > > But slow. It seems to depend a lot on the screen resolution. On my small > laptop, 1366x768, it's fairly OK. On the 1080p laptop it is very much > slower, it takes about 35 seconds longer compared to the old loader. > > Booting on a 4K monitor, well, I didn't time it... > > > Jakob > >
On 1/14/21 8:15 AM, Jakob Alvermark wrote: > > On 1/14/21 4:49 AM, monochrome wrote: >> I should add my experience to this since its different and haven't >> seen anyone else mention it. >> I see the new boot loader, it's not blank, but its large text, and >> it's very SLOW. >> I can see each char drawn, and then when it gets to the bottom and >> has to redraw all the lines to scroll up for new lines, it loads so >> slowly it's like watching an 8086 on a 300 baud modem, or slower! >> Takes like an extra 30 seconds to get through all the loaded modules, >> then back to normal speed boot with the same large font. >> >> added these lines and everything is back to normal with new >> appearance and small font like before, and at normal speed. >> hw.vga.textmode="0" >> vbe_max_resolution=1280x800 >> >> also removed the old lines for the amdgpu efi problem with no effect >> so I assume those are no longer necessary and why I'm seeing this >> change? >> #hw.syscons.disable=1 >> #kern.vty=vt >> #hw.vga.textmode=1 >> >> am using X and everything seems fine for now >> >> system: >> AMD Ryzen 5 2400G, using integrated vega GPU >> ASRock B450M Pro4 >> 13-current >> >> >> >> On 1/5/21 8:54 PM, David Wolfskill wrote: >>> On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: >>>> ... >>>>> the 58661b3ba9eb should hopefully fix the loader text mode issue, >>>>> it would be cool if you can verify:) >>>>> >>>>> thanks, >>>>> toomas >>>> >>>> I think, I got it fixed (at least idwer did confirm for his system, >>>> thanks). If you can test this patch: >>>> http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch >>>> <http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch> >>>> it would be really nice. >>>> >>>> thanks, >>>> toomas >>> >>> I tested with each of the following "stanzas' in /boot/loader.conf, >>> using vt (vs. syscons) in each case (though that breaks video reset >>> on resume after suspend): >>> >>> # hw.vga.textmode="0" >>> vbe_max_resolution=1280x800 >>> >>> This works, and provides a graphical console (depth 32). >>> >>> >>> hw.vga.textmode="0" >>> # vbe_max_resolution=1280x800 >>> >>> This also works, and provides a low-resolution (and depth 16) >>> graphical console (800x320 or something similar, IIRC). >>> >>> >>> # hw.vga.textmode="0" >>> # vbe_max_resolution=1280x800 >>> >>> (That is, not specifying anything for hw.vga.textmode or >>> vbe_max_resolution.) >>> >>> This boots OK, but I see no kernel probe messages or single- to >>> multi-user mode messages. I can use (e.g.) Ctl+Alt+F2 to switch to >>> vty1, see a "login: " prompt, and that (also) works. (This is the >>> initial symptom I had reported.) >>> >>> >>> hw.vga.textmode="1" >>> # vbe_max_resolution=1280x800 >>> >>> This works -- boots OK, and I see kernel probe (&c.) messages; this >>> is a >>> text console (mostly blue text; some white, against a dark background. >>> It's a medium-light blue, so it's easy enough to read (unlike a navy >>> blue, for example). >>> >>> >>> FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 >>> main-c255601-g9fd96b416c45-dirty: Tue Jan 5 17:24:45 PST 2021 >>> root@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY >>> amd64 > > > +1 on the slowness. > > I like the graphics mode, it's very pretty. > > But slow. It seems to depend a lot on the screen resolution. On my > small laptop, 1366x768, it's fairly OK. On the 1080p laptop it is very > much slower, it takes about 35 seconds longer compared to the old loader. > > Booting on a 4K monitor, well, I didn't time it...
> I should add my experience to this since its different and haven't seen > anyone else mention it. > I see the new boot loader, it's not blank, but its large text, and it's > very SLOW. > I can see each char drawn, and then when it gets to the bottom and has > to redraw all the lines to scroll up for new lines, it loads so slowly > it's like watching an 8086 on a 300 baud modem, or slower! Takes like an > extra 30 seconds to get through all the loaded modules, then back to > normal speed boot with the same large font. > > added these lines and everything is back to normal with new appearance > and small font like before, and at normal speed. > hw.vga.textmode="0" > vbe_max_resolution=1280x800 > > also removed the old lines for the amdgpu efi problem with no effect so > I assume those are no longer necessary and why I'm seeing this change? > #hw.syscons.disable=1 > #kern.vty=vt > #hw.vga.textmode=1 > > am using X and everything seems fine for now > > system: > AMD Ryzen 5 2400G, using integrated vega GPU > ASRock B450M Pro4 > 13-current > > > > On 1/5/21 8:54 PM, David Wolfskill wrote: > > On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: > >> ... > >>> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be cool if you can verify:) > >>> > >>> thanks, > >>> toomas > >> > >> I think, I got it fixed (at least idwer did confirm for his system, thanks). If you can test this patch: http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch <http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch> it would be really nice. > >> > >> thanks, > >> toomas > > > > I tested with each of the following "stanzas' in /boot/loader.conf, > > using vt (vs. syscons) in each case (though that breaks video reset > > on resume after suspend): > > > > # hw.vga.textmode="0" > > vbe_max_resolution=1280x800 > > > > This works, and provides a graphical console (depth 32). > > > > > > hw.vga.textmode="0" > > # vbe_max_resolution=1280x800 > > > > This also works, and provides a low-resolution (and depth 16) > > graphical console (800x320 or something similar, IIRC). > > > > > > # hw.vga.textmode="0" > > # vbe_max_resolution=1280x800 > > > > (That is, not specifying anything for hw.vga.textmode or > > vbe_max_resolution.) > > > > This boots OK, but I see no kernel probe messages or single- to > > multi-user mode messages. I can use (e.g.) Ctl+Alt+F2 to switch to > > vty1, see a "login: " prompt, and that (also) works. (This is the > > initial symptom I had reported.) > > > > > > hw.vga.textmode="1" > > # vbe_max_resolution=1280x800 > > > > This works -- boots OK, and I see kernel probe (&c.) messages; this is a > > text console (mostly blue text; some white, against a dark background. > > It's a medium-light blue, so it's easy enough to read (unlike a navy > > blue, for example). > > > > > > FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 main-c255601-g9fd96b416c45-dirty: Tue Jan 5 17:24:45 PST 2021 root@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 > > > > Peace, > > david > >
On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: > I think, I got it fixed (at least idwer did confirm for his system, thanks). If you can test this patch: http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch <http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch> it would be really nice.
On Tue, Jan 05, 2021 at 07:09:22PM -0800, John Kennedy wrote: > On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: > > I think, I got it fixed (at least idwer did confirm for his system, thanks). If you can test this patch: http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch <http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch> it would be really nice. > > I regret to say that it didn't fix my issue.
On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote: > I saw your commit of 99870c70bac7 (loader: rewrite vidc_install_font), > 31c2bcad7e44 (loader: remove left over call to unsetenv()), and belatedly > babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> screen.textmode). > > Didn't fix the blank screen, and I thought the hw.vga.textmode workaround > had broken until I read that commit fully (will try it next reboot). > > At main-c255633-g3efe9b3e77c3 right now (also past your f1829643c476.
On 1/8/21 8:11 PM, John Kennedy wrote: > On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote: >> I saw your commit of 99870c70bac7 (loader: rewrite vidc_install_font), >> 31c2bcad7e44 (loader: remove left over call to unsetenv()), and belatedly >> babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> screen.textmode). >> >> Didn't fix the blank screen, and I thought the hw.vga.textmode workaround >> had broken until I read that commit fully (will try it next reboot). >> >> At main-c255633-g3efe9b3e77c3 right now (also past your f1829643c476. > At main-c255756-g40903394bf48, still no love for my system yet. FYI, > screen.textmode=0 continued to work around the issue, as expected. >
> On 13. Jan 2021, at 20:13, Santiago Martinez wrote: > > Hi, +1 on this, i still have issue on a supermicro. > > Santi > >> On 1/8/21 8:11 PM, John Kennedy wrote: >>> On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote: >>> I saw your commit of 99870c70bac7 (loader: rewrite vidc_install_font), >>> 31c2bcad7e44 (loader: remove left over call to unsetenv()), and belatedly >>> babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> screen.textmode). >>> >>> Didn't fix the blank screen, and I thought the hw.vga.textmode workaround >>> had broken until I read that commit fully (will try it next reboot). >>> >>> At main-c255633-g3efe9b3e77c3 right now (also past your f1829643c476. >> At main-c255756-g40903394bf48, still no love for my system yet. FYI, >> screen.textmode=0 continued to work around the issue, as expected. >>
>
On 15/01/2021 14:51, Toomas Soome wrote: > Could you please check latest current now?:) > > Thanks, > Toomas > >> On 13. Jan 2021, at 20:13, Santiago Martinez wrote: >> >> Hi, +1 on this, i still have issue on a supermicro. >> >> Santi >> >>> On 1/8/21 8:11 PM, John Kennedy wrote: >>>> On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote: >>>> I saw your commit of 99870c70bac7 (loader: rewrite vidc_install_font), >>>> 31c2bcad7e44 (loader: remove left over call to unsetenv()), and belatedly >>>> babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> screen.textmode). >>>> >>>> Didn't fix the blank screen, and I thought the hw.vga.textmode workaround >>>> had broken until I read that commit fully (will try it next reboot). >>>> >>>> At main-c255633-g3efe9b3e77c3 right now (also past your f1829643c476. >>> At main-c255756-g40903394bf48, still no love for my system yet. FYI, >>> screen.textmode=0 continued to work around the issue, as expected. >>>
>> >>
On 15/01/2021 20:06, Johan Hendriks wrote: > > On 15/01/2021 14:51, Toomas Soome wrote: >> Could you please check latest current now?:) >> >> Thanks, >> Toomas >> >>> On 13. Jan 2021, at 20:13, Santiago Martinez >>> wrote: >>> >>> Hi, +1 on this, i still have issue on a supermicro. >>> >>> Santi >>> >>>> On 1/8/21 8:11 PM, John Kennedy wrote: >>>>> On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote: >>>>> I saw your commit of 99870c70bac7 (loader: rewrite >>>>> vidc_install_font), >>>>> 31c2bcad7e44 (loader: remove left over call to unsetenv()), and >>>>> belatedly >>>>> babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> >>>>> screen.textmode). >>>>> >>>>> Didn't fix the blank screen, and I thought the hw.vga.textmode >>>>> workaround >>>>> had broken until I read that commit fully (will try it next reboot). >>>>> >>>>> At main-c255633-g3efe9b3e77c3 right now (also past your >>>>> f1829643c476. >>>> At main-c255756-g40903394bf48, still no love for my system yet. >>>> FYI, >>>> screen.textmode=0 continued to work around the issue, as expected. >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>> >>> > I found out my desktop pc that i updated today also has a blank screen. > In my case setting the following helps > > screen.textmode=1 > vbe_max_resolution=800x600 > > And thank you for that lovely boot screen and awesome font, very neat! > > My release is main-c255921-gec2700e01532: Wed Jan 13 12:32:28 CET 2021 > > This is on a old intel core 2 > Copyright (c) 1992-2021 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-CURRENT #24 main-c255921-gec2700e01532: Wed Jan 13 > 12:32:28 CET 2021 > root@srv-01.thuis.local:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64 > FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git > llvmorg-11.0.1-rc2-0-g43ff75f2c3f) > VT(vbefb): resolution 1280x1024 > CPU: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz (2327.55-MHz > K8-class CPU) > Origin="GenuineIntel" Id=0x6fb Family=0x6 Model=0xf Stepping=11 > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0xe3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM> > > AMD Features=0x20100800<SYSCALL,NX,LM> > AMD Features2=0x1<LAHF> > VT-x: (disabled in BIOS) HLT,PAUSE > TSC: P-state invariant, performance statistics > >
> On 16. Jan 2021, at 14:40, Johan Hendriks wrote: >> > I just did an update to FreeBSD jhost002.thuis.local 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #26 main-c256002-gfe258f23ef36: Sat Jan 16 12:25:49 CET 2021 root@srv-01.thuis.local :/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64 > > For me all works now on my desktop pc. > > With an empty /boot/loader.conf all is fine, it boots to the text based screen. > Setting vbe_max_resolution= resolution give me that beautiful boot page, thank you very much for that. I always get laugh about by my Linux colleages about the FreeBSD boot screen, those days are over ;-). Also the font for me is very pleasant to see. > > Thank you for all your work on this. > > regards Johan >
On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote: > Could you please check latest current now?:)
On Sat, Jan 16, 2021 at 8:39 AM John Kennedy wrote: > On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote: > > Could you please check latest current now?:) > > Success! With main-c255999-g0bc776f3da70, I've been able to comment out > the > screen.textmode=0 (so, back to the default like I originally was). >
On 16/01/2021 21:15, Alan Somers wrote: > On Sat, Jan 16, 2021 at 8:39 AM John Kennedy wrote: > >> On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote: >>> Could you please check latest current now?:) >> Success! With main-c255999-g0bc776f3da70, I've been able to comment out >> the >> screen.textmode=0 (so, back to the default like I originally was). >>
On Mon, Jan 18, 2021 at 7:16 AM Johan Hendriks wrote: > > On 16/01/2021 21:15, Alan Somers wrote: > > On Sat, Jan 16, 2021 at 8:39 AM John Kennedy wrote: > > > >> On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote: > >>> Could you please check latest current now?:) > >> Success! With main-c255999-g0bc776f3da70, I've been able to comment > out > >> the > >> screen.textmode=0 (so, back to the default like I originally was). > >> > I needed to set vbe_max_resolution="800x600" to get the non text version > of the boot loader. >
> On 18. Jan 2021, at 19:27, Alan Somers wrote: > > On Mon, Jan 18, 2021 at 7:16 AM Johan Hendriks <joh.hendriks@gmail.com > > wrote: > >> >> On 16/01/2021 21:15, Alan Somers wrote: >>> On Sat, Jan 16, 2021 at 8:39 AM John Kennedy wrote: >>> >>>> On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote: >>>>> Could you please check latest current now?:) >>>> Success! With main-c255999-g0bc776f3da70, I've been able to comment >> out >>>> the >>>> screen.textmode=0 (so, back to the default like I originally was). >>>> >> I needed to set vbe_max_resolution="800x600" to get the non text version >> of the boot loader. >> > > Oh, I see. "hw.vga.textmode" got renamed to "screen.textmode". And it > works both ways now. No need to set vbe_max_resolution. > -Alan
On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote: > The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust > those dates above (I pulled it ~Jan 3rd and let it compile overnight), but > I'm going to repull all the sources and recompile, just in case. I might > have initiall pulled it during the git conversion and maybe it is confused.
> This might be perfectly natural and just new to me, but when I look at the > git logs this morning I see things like this (editing by me): > > Date: Mon Jan 4 17:30:00 2021 +0100 > Date: Mon Dec 14 18:56:56 2020 +0100 > Date: Tue Dec 15 13:50:00 2020 +0100 > Date: Mon Jan 4 16:23:10 2021 +0100 > > I've always assumed that the "Date:" there was when the commit happened,
On Mon, Jan 4, 2021 at 9:58 AM Poul-Henning Kamp wrote: > -------- > John Kennedy writes: > > > This might be perfectly natural and just new to me, but when I look at > the > > git logs this morning I see things like this (editing by me): > > > > Date: Mon Jan 4 17:30:00 2021 +0100 > > Date: Mon Dec 14 18:56:56 2020 +0100 > > Date: Tue Dec 15 13:50:00 2020 +0100 > > Date: Mon Jan 4 16:23:10 2021 +0100 > > > > I've always assumed that the "Date:" there was when the commit > happened, > > It is, but it is the time it was committed in the first git repos it was > committed to, > in this case the repos of the committer in question. > > Without taking a position on the merits of this design-choice, I > just want to point out that it means that timestamps should be > viewed very sceptically, since they depend on the *local* clock on > somebodys computer, not on the central repos machine. >
> I'll be more frank than phk: it sucks. Git's commit dates are basically > useless.
On Mon, Jan 4, 2021 at 10:51 AM Poul-Henning Kamp wrote: > -------- > Alan Somers writes: > > > I'll be more frank than phk: it sucks. Git's commit dates are basically > > useless. > > Git is not built as, or to be, version control. > > Git is built to be distrbuted collaboration tool. > > The designed-in version control aspect was always, and only, that > the ranting finish guy *by fiat* had the golden tree. > > The fact that people, like us, dress git up and call it a VCS does > not wash the stripes of the tiger. > > To me, personally, having a distributed collaboration tool has been > much more valuable than any "pure" or "real" VCS ever were. >
On Mon, Jan 4, 2021 at 10:08 AM Warner Losh wrote: ... > As for date order, we could also add a commit hook that requires the date > to be properly set, but that creates friction for developers. Is that > friction worth the benefits? I don't think so, but as you say we could also > add notes... but since there's no checkout by date feature, I'm not sure > what good it would do.
> On Mon, Jan 4, 2021 at 10:08 AM Warner Losh wrote: > ... > > As for date order, we could also add a commit hook that requires the date > > to be properly set, but that creates friction for developers. Is that > > friction worth the benefits? I don't think so, but as you say we could also > > add notes... but since there's no checkout by date feature, I'm not sure > > what good it would do. > > Not a vote one way or the other, but it would at least make > git log --since more meaningful.
On Tue, Jan 5, 2021 at 6:08 AM Jamie Landeg-Jones wrote: > Ryan Libby wrote: > > > On Mon, Jan 4, 2021 at 10:08 AM Warner Losh wrote: > > ... > > > As for date order, we could also add a commit hook that requires the > date > > > to be properly set, but that creates friction for developers. Is that > > > friction worth the benefits? I don't think so, but as you say we could > also > > > add notes... but since there's no checkout by date feature, I'm not > sure > > > what good it would do. > > > > Not a vote one way or the other, but it would at least make > > git log --since more meaningful. > > Not having timestamps on files cloned or viewed in cgit.freebsd.org is a > nightmare too. >
> > Not having timestamps on files cloned or viewed in cgit.freebsd.org is a > > nightmare too. > > > > I just clicked through and saw several time stamps quite trivially. Could > you be more specific in your complaint? > > Warner
On 06/01/2021 02:32, Jamie Landeg-Jones wrote: > Re: git non-time-sequential logs
> Warner Losh wrote: > >>> Not having timestamps on files cloned or viewed in cgit.freebsd.org is a >>> nightmare too. >>> >> I just clicked through and saw several time stamps quite trivially. Could >> you be more specific in your complaint? >> >> Warner > I wasn't really complaining - If the git transition is better for you guys, I'm all for it. > > However, this is one such URL: https://cgit.freebsd.org/src/tree/usr.bin/diff > > Those files have no dates besides them on my screen.. > > Cheers, Jamie
> Alongside 'tree', click 'log'
> Also/alternatively there's the read-only mirror on GitHub so, for example: > > <https://github.com/freebsd/freebsd-src/tree/main/usr.bin/diff>
On 06/01/2021 14:34, Jamie Landeg-Jones wrote: > Git: timestamps > Graham Perrin wrote: > >> Alongside 'tree', click 'log' > Thanks, but I wanted the file dates, not the log! > >> Also/alternatively there's the read-only mirror on GitHub so, for example: >> >> <https://github.com/freebsd/freebsd-src/tree/main/usr.bin/diff> > I know, which is why I miss it on the FreeBSD main site. > > cheers!
On 2021-01-07, Graham Perrin wrote: > cgit describes itself as "hyperfast" with ><https://git.zx2c4.com/cgit/about/#features> "basic repository browsing" > as a feature. > > Beyond those basics, I guess that it will be appropriate to ensure > awareness of complementary web-based repository browsers including > GitHub and <https://gitlab.com/FreeBSD/> GitLab;
> Strictly speaking, main site <https://www.freebsd.org/> does still > direct developers to the Subversion repository and the Git mirror on GitHub.
> cgit describes itself as "hyperfast" with > <https://git.zx2c4.com/cgit/about/#features> "basic repository browsing" > as a feature. > > Beyond those basics, I guess that it will be appropriate to ensure > awareness of complementary web-based repository browsers including > GitHub and <https://gitlab.com/FreeBSD/> GitLab; these might be > described as fuller-featured (without explicitly describing them as > relatively slow). Awareness through the Developers menu at > <https://www.freebsd.org/> and so on.
> Yes. Git has never been a true/pure VCS. However, it does offer enough > VCS-like features to create a shared distributed versioned tree that's > useful to the project. > > As for date order, we could also add a commit hook that requires the date > to be properly set, but that creates friction for developers. Is that > friction worth the benefits? I don't think so, but as you say we could also > add notes... but since there's no checkout by date feature, I'm not sure > what good it would do.
> Why is it that the project can't continue to operate the SVN server in > addition to Git, gatewaying with -current as is being done with 12-stable?
> Why is it that the project can't continue to operate the SVN server in > addition to Git, gatewaying with -current as is being done with 12-stable? > As a developer, I definitely need monotonic revision numbers and reliable > dates when I'm trying to troubleshoot a regression. I understand that you > want better 'collaboration' in FreeBSD, but why can't we have the best of > both worlds?
On Mon, Jan 4, 2021 at 9:06 PM David G Lawrence wrote: > > Yes. Git has never been a true/pure VCS. However, it does offer enough > > VCS-like features to create a shared distributed versioned tree that's > > useful to the project. > > > > As for date order, we could also add a commit hook that requires the date > > to be properly set, but that creates friction for developers. Is that > > friction worth the benefits? I don't think so, but as you say we could > also > > add notes... but since there's no checkout by date feature, I'm not sure > > what good it would do. > > Warner, > > Why is it that the project can't continue to operate the SVN server in > addition to Git, gatewaying with -current as is being done with 12-stable? > As a developer, I definitely need monotonic revision numbers and reliable > dates when I'm trying to troubleshoot a regression. I understand that you > want better 'collaboration' in FreeBSD, but why can't we have the best of > both worlds? >
> On Jan 4, 2021, at 9:05 AM, Alan Somers wrote: > > On Mon, Jan 4, 2021 at 9:58 AM Poul-Henning Kamp <phk@phk.freebsd.dk > wrote: > >> -------- >> John Kennedy writes: >> >>> This might be perfectly natural and just new to me, but when I look at >> the >>> git logs this morning I see things like this (editing by me): >>> >>> Date: Mon Jan 4 17:30:00 2021 +0100 >>> Date: Mon Dec 14 18:56:56 2020 +0100 >>> Date: Tue Dec 15 13:50:00 2020 +0100 >>> Date: Mon Jan 4 16:23:10 2021 +0100 >>> >>> I've always assumed that the "Date:" there was when the commit >> happened, >> >> It is, but it is the time it was committed in the first git repos it was >> committed to, >> in this case the repos of the committer in question. >> >> Without taking a position on the merits of this design-choice, I >> just want to point out that it means that timestamps should be >> viewed very sceptically, since they depend on the *local* clock on >> somebodys computer, not on the central repos machine. >> > > I'll be more frank than phk: it sucks. Git's commit dates are basically > useless. But there are a few ways to improve the situation: > 1) If we start using Gitlab or something similar, we can ban pushes > directly to head. Then we'll be able to trust the Dates on Gitlab's merge > commits. > 2) Perhaps we can use the Git Notes to add a field for the Date when a > commit was pushed to the master server? > 3) The internet is full of suggestions for how to change the way commits > are displayed locally to mediate this problem. But they all seem to > involve changes to the working copy's configuration, not the master's. And > I haven't gotten any way to work.
> On 4. Jan 2021, at 7:52 PM, Enji Cooper wrote: > > The point is to stop looking at git like svn: commits should be done as larger bodies of work (merge commits), as opposed to single atomic commits.
On Mon, Jan 04, 2021 at 07:59:12PM +0100, Franco Fichtner wrote: > The author date stays the same, the committer date is sequential except > that it indicates the local time of the committer doing the cherry-pick > instead of the central server as opposed to svn: > > # git log --format=fuller
On Mon, Jan 4, 2021 at 11:00 AM Franco Fichtner wrote: > > > > On 4. Jan 2021, at 7:52 PM, Enji Cooper wrote: > > > > The point is to stop looking at git like svn: commits should be done as larger bodies of work (merge commits), as opposed to single atomic commits. > > Er, uh, no. ;) > > The author date stays the same, the committer date is sequential except > that it indicates the local time of the committer doing the cherry-pick > instead of the central server as opposed to svn: > > # git log --format=fuller >
On 1/4/21 8:52 AM, John Kennedy wrote: > On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote: >> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust >> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but >> I'm going to repull all the sources and recompile, just in case. I might >> have initiall pulled it during the git conversion and maybe it is confused. > > This might be perfectly natural and just new to me, but when I look at the > git logs this morning I see things like this (editing by me): > > commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, freebsd/main, freebsd/HEAD) > Author: Emmanuel Vadot > Date: Mon Jan 4 17:30:00 2021 +0100 > > commit f61a3898bb989edef7ca308043224e495ed78f64 > Author: Emmanuel Vadot > Date: Mon Dec 14 18:56:56 2020 +0100 > > commit b6cc69322a77fa778b00db873781be04f26bd2ee > Author: Emmanuel Vadot > Date: Tue Dec 15 13:50:00 2020 +0100 > > commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf > Author: Emmanuel Vadot > Date: Mon Jan 4 16:23:10 2021 +0100 > > This is a fresh clone+pull off of anongit@git.FreeBSD.org:src.git. > > I've always assumed that the "Date:" there was when the commit happened, > so they'd be increasing (most recent on top), but I suppose that you might > have developers in branches that are committing to their branch at one > point in time and it's getting merged into current (main) later, but the > original date is preserved? > > I guess I only care because I was trying to use time to bisect the > time I thought the problem might have been introduced.
On 1/5/21 2:36 PM, John Baldwin wrote: > On 1/4/21 8:52 AM, John Kennedy wrote: >> On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote: >>> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust >>> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but >>> I'm going to repull all the sources and recompile, just in case. I might >>> have initiall pulled it during the git conversion and maybe it is confused. >> This might be perfectly natural and just new to me, but when I look at the >> git logs this morning I see things like this (editing by me): >> >> commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, freebsd/main, freebsd/HEAD) >> Author: Emmanuel Vadot >> Date: Mon Jan 4 17:30:00 2021 +0100 >> >> commit f61a3898bb989edef7ca308043224e495ed78f64 >> Author: Emmanuel Vadot >> Date: Mon Dec 14 18:56:56 2020 +0100 >> >> commit b6cc69322a77fa778b00db873781be04f26bd2ee >> Author: Emmanuel Vadot >> Date: Tue Dec 15 13:50:00 2020 +0100 >> >> commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf >> Author: Emmanuel Vadot >> Date: Mon Jan 4 16:23:10 2021 +0100 >> >> This is a fresh clone+pull off of anongit@git.FreeBSD.org:src.git. >> >> I've always assumed that the "Date:" there was when the commit happened, >> so they'd be increasing (most recent on top), but I suppose that you might >> have developers in branches that are committing to their branch at one >> point in time and it's getting merged into current (main) later, but the >> original date is preserved? >> >> I guess I only care because I was trying to use time to bisect the >> time I thought the problem might have been introduced. > For commits to gdb (which uses git), the project asks that all series be > rebased via 'git rebase --ignore-date' prior to pushing to master to give > monotonically increasing commit dates. We could do something similar in > FreeBSD either by asking folks to do that explicitly (though I know I > sometimes forget when pushing to gdb myself), or we could avoid direct > pushes to main. One option some folks mentioned on IRC was to have a > separate "staging" branch that developers push to and then have a bot that > does a rebase --ignore-date of that branch to main periodically, though > that opens the question of how to deal with cherry-picks to stable (for > which asking developers to do a rebase --ignore-date prior to pushing is > probably the simpler approach). > > If we did want monotonically increasing dates without having a staging > branch, we could perhaps use a server-side push hook to reject them and > developers would just have to do a rebase --ignore-date before pushing > again. >
> This is a little weird. > > Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 29th), > I've lost the screen in the boot loader. This is really weird because I > didn't update the boot loader (in quite a while, actually), but I suppose it > might drag some stuff off of the disk and misbehave. > > But the system boots, presumably after the countdown that I can't see, I just > have to SSH in from a different machine to tweak things. Just no screen at > all past the GELI encrypted disk password prompt (and some usual noise as > it complains about some padding that I've seen forever). > > I used to just upgrade the boot loader around ZFS upgrades, and I haven't > done that since OpenZFS got merged. I just got overly conservative there > and may have missed the "all clear" for all combinations of ZFS and the > bootloader recognizing them. >
> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust > those dates above (I pulled it ~Jan 3rd and let it compile overnight), but > I'm going to repull all the sources and recompile, just in case. I might > have initiall pulled it during the git conversion and maybe it is confused. >