TalkEnd

Boot loader blank screen

FreeBSD 1 month ago
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.
62 replies
Re: boot loader blank screen
> 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
Re: boot loader blank screen
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.
Re: boot loader blank screen
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. >
Yea, this is a feature that needs to be fixed since black on black text is a show stopper :( Warner
Re: boot loader blank screen
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.
Re: boot loader blank screen
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. >
To be fair, I'm unsure if this is a failure to draw the characters, or a color attribute failure introduced. I've not looked deeply and am jumping a bit to conclusions. Warner
Re: boot loader blank screen
> 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
Re: boot loader blank screen
Toomas, 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() ): diff --git a/stand/i386/libi386/vbe.c b/stand/i386/libi386/vbe.c index 7681eb633b8..1fee4f040f4 100644 --- a/stand/i386/libi386/vbe.c +++ b/stand/i386/libi386/vbe.c @@ -1105,6 +1105,15 @@ vbe_default_mode(void) return (modenum); } +bool +vbe_is_vga(void) +{ + if (vbe == NULL) + return (false); + + return ((vbe->Capabilities & VBE_CAP_NONVGA) == 0); +} + COMMAND_SET(vbe, "vbe", "vesa framebuffer mode management", command_vesa); int diff --git a/stand/i386/libi386/vbe.h b/stand/i386/libi386/vbe.h index ff28b960df9..7d07d9ee518 100644 --- a/stand/i386/libi386/vbe.h +++ b/stand/i386/libi386/vbe.h @@ -161,3 +161,4 @@ int vbe_set_mode(int); int vbe_get_mode(void); int vbe_set_palette(const struct paletteentry *, size_t); void vbe_modelist(int); +bool vbe_is_vga(void); diff --git a/stand/i386/libi386/vidconsole.c b/stand/i386/libi386/vidconsole.c index b4829db1ea4..22708032a49 100644 --- a/stand/i386/libi386/vidconsole.c +++ b/stand/i386/libi386/vidconsole.c @@ -907,7 +907,8 @@ cons_update_mode(bool use_gfx_mode) unsetenv("screen.width"); unsetenv("screen.depth"); unsetenv("kern.vt.fb.default_mode"); - vidc_install_font(); + if (!vbe_is_vga()) + vidc_install_font(); } free(screen_buffer); Op ma 4 jan. 2021 om 23:59 schreef Toomas Soome <tsoome@me.com>:
> > > > > 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
Re: boot loader blank screen
Op ma 4 jan. 2021 om 23:59 schreef Toomas Soome <tsoome@me.com>:
> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be cool if you can verify:)
No, sorry...
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() ): ...
... and that patch didn't work for me either. Although, in my case, it is on top of main-c255599-g58661b3ba9eb.
Re: boot loader blank screen
> 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
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
Re: boot loader blank screen
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. >
[I got to this sooner than I originally expected.] With the patch applied, hw.vga.textmode="1" finally displayed correctly for the ThreadRipper 1950X context that I had originally reported. (The only amd64 FreeBSD context that I've access to.) Thanks, Mark === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: boot loader blank screen
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 -- David H. Wolfskill david@catwhisker.org Defense against criminal charges for Trump's call to "find 11,780 votes": he's delusional. That must be why he should be making life-or-death decisions. See https://www.catwhisker.org/~david/publickey.gpg for my public key.
Re: boot loader blank screen
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): > > . . .
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. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: boot loader blank screen
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. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few.
Re: boot loader blank screen
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)
Re: boot loader blank screen
1 month ago
I've tried multiple rebuilds to no avail - what finally fixed it for me was to add this to /boot/loader.conf and rebooted: screen.textmode=1 I don't use X11 on this box but only had console access so needed the console to work :-) Works for me, your mileage may vary. Dan
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) > >
Re: boot loader blank screen
This issue(s) seem to need a variety of reporting contexts for coverage. My coverage at this point is more of a check if something reverted for my type of context but when it started my context was a failure case. I'm no longer testing a context based on the earlier patch (before its commital) but now caught up to recently enough on the ThreadRipper to have screen.textmode be the intended means of control: # ~/fbsd-based-on-what-freebsd-main.sh mm-src b1ea63e2e3c92d1346af067f5cf609e3e062f8b9 CommitDate: 2021-01-06 13:18:37 -0800 fa0b97dbe6e1 b1ea63e2e3c9 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. FreeBSD FBSDFHUGE 13.0-CURRENT FreeBSD 13.0-CURRENT mm-src-c255637-gfa0b97dbe6e1 GENERIC-NODBG amd64 amd64 1300133 1300133 For this vintage of my context . . . screen.textmode="1" works. (With the huge, blocky font on the 1920x1200 display. But nothing significant about that is recently changed.) 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.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: boot loader blank screen
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.)
For my system, that change seems to be with the nvidia video driver gets loaded. Basically it looks like a screen clear and potential font change depending on your setup. Seems logical since something is probably getting (re)initialized at that point.
Re: boot loader blank screen
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 >
Re: boot loader blank screen
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
Re: boot loader blank screen
Is there a bugzilla issue for this yet? It's affecting a lot of people, and it will be easier for us to monitor progress with Bugzilla than with the mailing list. -Alan
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 > >
Re: boot loader blank screen
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...
Observations with the current version: 1. The font is now a lot smaller. 2. It feels quicker. However, still a bit slow. Something that seems very slow is clearing the screen. It's like pulling down a curtain slowly. 3. Booting on the 4k monitor does not work now. Loader looks alright, but when it hands over to the kernel, the screen just goes blank, and the machine hangs. This worked before. Jakob
Re: boot loader blank screen
Hi. It seems that font-to-display-80x24(25?)-chars-on-full-screen is selected automatically for display resolution. How's going on if you set, e.g., screen.font=8x16 On /boot/loader.conf? This helps me by reduced scrolling. If it's too small for you, see /boot/fonts for other sizes. Each font files has .fnt.gz extension, and base file name eliminating .tar.gz extension is what to set to screen.font variable. And the latest loader looks a bit faster than first graphics mode port. But it would be better if it catches up with in-kernel vt(efifb). HTH, maybe not sufficient, though. On Wed, 13 Jan 2021 22:49:26 -0500 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 > > > > Peace, > > david > >
-- Tomoaki AOKI
Re: boot loader blank screen
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.
Re: boot loader blank screen
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.
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.
Re: boot loader blank screen
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.
Re: boot loader blank screen
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. >
Re: boot loader blank screen
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. >>
>
Re: boot loader blank screen
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. >>>
>> >>
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
Re: boot loader blank screen
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 > >
I found out that i have this line in my /boot/loader.conf file. loader_logo="orb" if i leave that in, than only this setting works and only the text based boot screen works. screen.textmode=1 I then can not use the vbe_max_resolution="800x600" setting as i get no screen (in the top it looks like i have some small consoles of about 20 pixels high in all collors.) If i remover the loader_logo="orb" line, then i can use vbe_max_resolution="800x600" and i see the console but only in 16 colors i think. I will rebuild to the current of this moment and see if the latest works.
Re: boot loader blank screen
Re: boot loader blank screen
> 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 >
Thank you for testing and patience. rgds, toomas
Re: boot loader blank screen
1 month ago
Re: boot loader blank screen
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).
Re: boot loader blank screen
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). >
Sort of! Now textmode works again. But the hw.vga.textmode setting is ignored. Instead, I'm always in text mode; I can't boot into graphics mode. This is at main-c256008-gde57c3d88258 on an Ivy Bridge system. -Alan
Re: boot loader blank screen
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.
Re: boot loader blank screen
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. >
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
Re: boot loader blank screen
> 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
That is good. and btw, hw.vga.textmode is still there, it is doing what it has been done before — controlling VGA gfx or text mode when you are starting kernel with text mode. rgds, toomas
Git non-time-sequential logs
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.
Re: git non-time-sequential logs
-------- 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: git non-time-sequential logs
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. 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. -Alan
Re: git non-time-sequential logs
-------- 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: git non-time-sequential logs
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. >
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
Re: git non-time-sequential logs
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.
Re: git non-time-sequential logs
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.
Re: git non-time-sequential logs
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. >
I just clicked through and saw several time stamps quite trivially. Could you be more specific in your complaint? Warner
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
Git: timestamps
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> – although time stamps there are relative, not absolute.
Re: 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!
Git and complementary web interfaces (some fast but basic, others fuller-featured)
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!
Strictly speaking, main site <https://www.freebsd.org/> does still direct developers to the Subversion repository and the Git mirror on GitHub. Re: <https://wiki.freebsd.org/git>, things such as <https://github.com/bsdimp/freebsd-git-docs/blob/main/doc-cvt.md#old-vs-new-url-translation-table> "should be viewed as rough drafts for material for the handbook". 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. HTH
Re: Git and complementary web interfaces (some fast but basic, others fuller-featured)
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;
Use of Git implies cloning the repository, so you have a local copy of the repository and can run _local_ browsing tools to your heart's desire. E.g., you could set up your very own cgit web interface. Personally, I'm fond of Got's curses-based repository browser tog(1). I think that one is vaguely modeled on another tool called tig(1). Undoubtedly, there are plenty of others. The main value of Git web interfaces is easy browsing of foreign repositories that you have not cloned. -- Christian "naddy" Weisgerber naddy@mips.inka.de
Re: Git and complementary web interfaces (some fast but basic, others fuller-featured)
Graham Perrin wrote:
> Strictly speaking, main site <https://www.freebsd.org/> does still > direct developers to the Subversion repository and the Git mirror on GitHub.
Fair enough, but that will change, and timestamps don't appear to be an option. I'm sure it wouldn't be too painful to add, I'll probably look at it myself when I switch to FreeBSD-13.
> 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.
I liked svnweb. I like cgit. github is too heavy for browsing (I can't be the only one who fires up w3m from the command line to do a quick check on something) A typical "file/directory" type ui that git has is all I want... but with absolute timestamps! :-) Cheers, Jamie
Re: git non-time-sequential logs
> 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? -DG * David Greenman-Lawrence * * Pave the road of life with opportunities.
Re: git non-time-sequential logs
-------- David G Lawrence writes:
> 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?
David, With all due respect: That question has been asked and answered so many times now, that it's time to stop asking it and move on. And mind you: Nothing prevents you, or any other person who cannot live without SVN, from providing that service yourself. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: git non-time-sequential logs
1 month ago
> 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?
Unlimited best worlds are already free to exist. In addition to the internet's good suggestions how to use the forms of "revision numbers" already in git, and the internet's many good tutorials on how to learn, use, adopt, adapt and live breathe git, FreeBSD has chosen git for this time. It appears unsensible to expect any opensource project or OS to continue operation and maintenance of N x different repos and different repo camps in perpetuity because minor minority seeks some small feature. A feature in shipped code for users ok, but not in raw project overhead. Look at the entirety of Linux and Github's thousands of big projects... who there is leaving git these days to get number feature? The way forward is to explore how those git projects use git to "troubleshoot regressions" as obviously they are performing that function well everyday, without regard to such numbers or dates. If people find they need numbers or anything else, they can also get together and offsite host great import "gateway" services (or on their own locally), publish wrapper script ports, metainfo db's, etc... those best worlds are really unlimited and infinitely customizable as needed, so much can be done there :) Though since FreeBSD (and almost all world of public code repos) has chosen git and abandoned SVN etc, it's unsensible to expect a project efficiently on one repo (FreeBSD on git) to really interact using such N x repos within itself... it's overhead. The good people running those N x repos will need to speak git upstream, or at least send up patch format. That is the normal history of [mass effect] migrations. For more "best worlds"... Now can call to deploy RCS too, "because" pretty version numbers, wastes zero time on security concerns, etc. And call to pass around tarballs on tape too, "because" tape is reliable and can hold every revision and iso and pkg of every OS on one 580TiB raw cart, 2+PiB compressed ;) And as far as which of N x services to examine offsite, rather than boring numbers, perhaps it would be more academically interesting to learn a bit about the crypto primitives, distribution network, and database behind some things like https://monotone.ca/ Or anything about any other repos far more novel or new than any of those above. Since one day people might have to leave some formerly thought "needed" feature of git behind in order to be carried by and follow the world into one of those repos in the future as well. They might even be the ones abandoning their thoughts first in order to carry and lead others there.
Re: git non-time-sequential logs
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? >
Hi David, We purposely decided not to mirror main -> head. This is a conversion and git is the source of truth. Mirroring to head would have created additional demand for the continued generation of git notes to coordinate the subversion rXXXX numbers than just having it be for stable/12. The script that's been written, but delayed due to illness just publishes changes to subversion: nothing more. Even this simple design took more time and effort than anticipated. Mirroring to stable/12 only gives an effective end date for subversion. Git does provide you the tools you want to do bisection, they are just a bit different. Just as subversion provided new tools that CVS didn't, git does the same. Subversion was also unfamiliar at first and took some time to understand its paradigms and how they differed from CVS. They also sounded scary and crazy at the time, but turned out to be more fear of the unknown rather than actual problems in practice. Git provides a revision count on a branch (or since inception) that can be used to soften the blow of rXXXX numbers going away that's almost the same (it won't coordinate between branches, but then we rarely needed that property of rXXXX numbers). Git doesn't provide checkout by date, but we've not needed that since CVS days when it was the only way to bisect a change (though I will admit it was handy to be able to do it, one can still do it, but with a little more effort and fuzziness). So to do the mirroring back to subversion was hard, created logistical issues, and was one more thing that needed care and feeding. As such, we limited its scope to limit the extra work for the project and to time-bound how long that obligation lasts. Warner
Re: git non-time-sequential logs
> 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.
I actually find the non-sequential dates a feature: if someone reorders commits in a stack, e.g., `git rebase -I` I find it curious wondering why things were committed in the order they were. 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. Cheers, -Enji
Re: git non-time-sequential logs
> 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 Cheers, Franco
Re: git non-time-sequential logs
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
That format gets me the CommitDate:, which is what I would have been looking for. Seems like the data is there, just not necessarily used (displayed) by default. Not sure what the original SVN timestamps were, but assuming GMT: (export TZ=GMT && git log --format=fuller --date=local) Maybe there are some ways to make those default options.
Re: git non-time-sequential logs
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 >
It's normally sequential, but with the caveat that it's ultimately arbitrary and can't be relied on unless we enforce that. GIT_COMMITTER_DATE="1970-01-01T00:00:00Z" git commit
Re: git non-time-sequential logs
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. -- John Baldwin
Re: git non-time-sequential logs
1 month ago
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. >
In the example above, the commit dates *are* monotonically increasing.  The author dates aren't however, and that's what the log shows. Commit dates for direct changes to HEAD (seen in 'git log --first-parent --pretty=fuller' among other methods) seem like a direct replacement for SVN revisions and their timestamps.  Maybe I'm not understanding the problem? To be extra sure commit dates remain monotonic, it would make sense to enforce by rule: - The commit date must not be earlier than the date of the commit's parent. - The commit date must not be in the future. Is there any nonnegligible reason not to impose that as a protection against accidental system time misconfigurations?  In any other circumstance, it would not come into effect anyway?
Re: boot loader blank screen
On Mon, 4 Jan 2021 08:22:56 -0800 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. >
I had this problem also after I updated my sources this morning in Germany and decided to make a new kernel and world. I then booted the new kernel and did installworld, after which I rebooted with the new kernel and saw that the console disappeared after the BTX Loader output appeared. So I logged in using ssh and looked under /boot. There were 52 files which had been newly installed, all of them related to booting. Luckily, I had a backup of /boot which I'd made on January 1. Restoring the backup got me back my console. I have no idea which of the newly installed files caused the console to disappear. Note that my loader.conf was not modified. And also that I still use 4th rather than lua. I tried using both sc and vt, but the console still failed to appear.
> 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. >
-- Gary Jennejohn
Related Threads