boot loader blank screen

[John Kennedy]

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.

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Toomas Soome]

Post by John Kennedy
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

[John Kennedy]

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.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Warner Losh]

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,
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Kennedy]

Post by Warner Losh
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.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Warner Losh]

Post by John Kennedy

Post by Warner Losh
Yea, this is a feature that needs to be fixed since black on black text

is

Post by Warner Losh
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Toomas Soome]

Post by Toomas Soome

Post by John Kennedy
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

[Idwer Vollering]

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);

Post by Toomas Soome

Post by Toomas Soome

Post by John Kennedy
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

[John Kennedy]

Post by Toomas Soome
the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be cool if you can verify:)

No, sorry...

Post by Toomas Soome
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.

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Toomas Soome]

Post by Toomas Soome

Post by Toomas Soome

Post by John Kennedy
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

[Mark Millard]

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)

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Kennedy]

... 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.

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mark Millard]

write

Post by Toomas Soome

Post by David Wolfskill

Post by Toomas Soome
...

Post by Toomas Soome
the 58661b3ba9eb should hopefully fix the loader text mode issue, it woul

d be cool if you can verify:)

Post by David Wolfskill

Post by Toomas Soome

Post by Toomas Soome
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.

Post by David Wolfskill

Post by Toomas Soome
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
. . .

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".

Post by David Wolfskill
# hw.vga.textmode="0"

textmode=1 doesn't work either. Been using it for years and this is the
first time it's borked.

Post by Toomas Soome

Post by David Wolfskill
# 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.

Post by Toomas Soome

Post by David Wolfskill
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)

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Cy Schubert]

In message <63A29589-22B5-495B-8E0D-***@yahoo.com>, Mark Millard
write

Post by Toomas Soome

Post by David Wolfskill

Post by Toomas Soome
...

Post by Toomas Soome
the 58661b3ba9eb should hopefully fix the loader text mode issue, it woul

d be cool if you can verify:)

Post by David Wolfskill

Post by Toomas Soome

Post by Toomas Soome
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.

Post by David Wolfskill

Post by Toomas Soome
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
. . .

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".

Post by David Wolfskill
# hw.vga.textmode="0"

textmode=1 doesn't work either. Been using it for years and this is the
first time it's borked.

Post by Toomas Soome

Post by David Wolfskill
# 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.

Post by Toomas Soome

Post by David Wolfskill
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 <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: https://FreeBSD.org
NTP: <***@nwtime.org> Web: https://nwtime.org

The need of the many outweighs the greed of the few.


_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dan Mack]

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

Post by Mark Millard

write

Post by Toomas Soome

Post by David Wolfskill

Post by Toomas Soome
...

Post by Toomas Soome
the 58661b3ba9eb should hopefully fix the loader text mode issue, it woul

d be cool if you can verify:)

Post by David Wolfskill

Post by Toomas Soome

Post by Toomas Soome
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.

Post by David Wolfskill

Post by Toomas Soome
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
. . .

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".

Post by David Wolfskill
# hw.vga.textmode="0"

textmode=1 doesn't work either. Been using it for years and this is the
first time it's borked.

Post by Toomas Soome

Post by David Wolfskill
# 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.

Post by Toomas Soome

Post by David Wolfskill
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)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Kennedy]

Post by John Kennedy
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-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Santiago Martinez]

Hi, +1 on this, i still have issue on a supermicro.

Santi

Post by John Kennedy

Post by John Kennedy
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.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

[Toomas Soome]

Could you please check latest current now?:)

Thanks,
Toomas

Post by Santiago Martinez
Hi, +1 on this, i still have issue on a supermicro.
Santi

Post by John Kennedy

Post by John Kennedy
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.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

[Johan Hendriks]

Post by Toomas Soome
Could you please check latest current now?:)
Thanks,
Toomas

Post by Santiago Martinez
Hi, +1 on this, i still have issue on a supermicro.
Santi

Post by John Kennedy

Post by John Kennedy
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.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

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
    ***@srv-01.thuis.local:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64
FreeBSD clang version 11.0.1 (***@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

[s***@codenetworks.net]

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Johan Hendriks]

Post by Johan Hendriks

Post by Toomas Soome
Could you please check latest current now?:)
Thanks,
Toomas

Post by Santiago Martinez
Hi, +1 on this, i still have issue on a supermicro.
Santi

  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.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to

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
llvmorg-11.0.1-rc2-0-g43ff75f2c3f)
VT(vbefb): resolution 1280x1024
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.

[Johan Hendriks]

Post by Johan Hendriks

Post by Johan Hendriks

Post by Toomas Soome
Could you please check latest current now?:)
Thanks,
Toomas

Post by Santiago Martinez
Hi, +1 on this, i still have issue on a supermicro.
Santi

  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.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to

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
llvmorg-11.0.1-rc2-0-g43ff75f2c3f)
VT(vbefb): resolution 1280x1024
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.

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
***@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

[Toomas Soome]

Post by Johan Hendriks
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

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Kennedy]

Post by Toomas Soome
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).
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alan Somers]

Post by John Kennedy

Post by Toomas Soome
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Johan Hendriks]

Post by John Kennedy

Post by Toomas Soome
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.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alan Somers]

Post by Johan Hendriks

Post by John Kennedy

Post by Toomas Soome
Could you please check latest current now?:)

Success! With main-c255999-g0bc776f3da70, I've been able to comment

out

Post by John Kennedy
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Toomas Soome]

Post by Alan Somers

Post by Johan Hendriks

Post by John Kennedy

Post by Toomas Soome
Could you please check latest current now?:)

Success! With main-c255999-g0bc776f3da70, I've been able to comment

out

Post by John Kennedy
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

[Jakob Alvermark]

Post by monochrome
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
AMD Ryzen 5 2400G, using integrated vega GPU
ASRock B450M Pro4
13-current

Post by David Wolfskill

Post by Toomas Soome
...

Post by Toomas Soome
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,
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
# 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
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

[Alan Somers]

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

Post by Toomas Soome

Post by monochrome
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
AMD Ryzen 5 2400G, using integrated vega GPU
ASRock B450M Pro4
13-current

Post by David Wolfskill

Post by Toomas Soome
...

Post by Toomas Soome
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,

http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch

Post by monochrome

Post by David Wolfskill

Post by Toomas Soome
<

http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch>

Post by monochrome

Post by David Wolfskill

Post by Toomas Soome
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
# 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
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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Tomoaki AOKI]

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

Post by monochrome
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
AMD Ryzen 5 2400G, using integrated vega GPU
ASRock B450M Pro4
13-current

Post by David Wolfskill

Post by Toomas Soome
...

Post by Toomas Soome
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
# 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).
Peace,
david

_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

--
Tomoaki AOKI <***@dec.sakura.ne.jp>
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jakob Alvermark]

Post by Jakob Alvermark

Post by monochrome
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
AMD Ryzen 5 2400G, using integrated vega GPU
ASRock B450M Pro4
13-current

Post by David Wolfskill

Post by Toomas Soome
...

Post by Toomas Soome
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,
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
# 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
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

[Mark Millard]

Post by Toomas Soome

Post by Toomas Soome

Post by John Kennedy
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)

[David Wolfskill]

Post by Toomas Soome
...

Post by Toomas Soome
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 ***@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64

Peace,
david

[John Kennedy]

Post by Toomas Soome
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.

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mark Millard]

Post by David Wolfskill

Post by Toomas Soome
...

Post by Toomas Soome
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
. . .

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".

Post by David Wolfskill
# 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.

Post by David Wolfskill
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)

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Kennedy]

Post by John Kennedy

Post by Toomas Soome
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.

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[monochrome]

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

Post by David Wolfskill

Post by Toomas Soome
...

Post by Toomas Soome
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
# 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).
Peace,
david

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Kennedy]

Post by John Kennedy
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 <***@FreeBSD.org>
Date: Mon Jan 4 17:30:00 2021 +0100

commit f61a3898bb989edef7ca308043224e495ed78f64
Author: Emmanuel Vadot <***@freebsd.org>
Date: Mon Dec 14 18:56:56 2020 +0100

commit b6cc69322a77fa778b00db873781be04f26bd2ee
Author: Emmanuel Vadot <***@freebsd.org>
Date: Tue Dec 15 13:50:00 2020 +0100

commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
Author: Emmanuel Vadot <***@FreeBSD.org>
Date: Mon Jan 4 16:23:10 2021 +0100

This is a fresh clone+pull off of ***@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.

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Poul-Henning Kamp]

--------

Post by John Kennedy
This might be perfectly natural and just new to me, but when I look at the
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
***@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.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alan Somers]

Post by Poul-Henning Kamp
--------

Post by John Kennedy
This might be perfectly natural and just new to me, but when I look at

the

Post by John Kennedy
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Poul-Henning Kamp]

--------

Post by Alan Somers
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
***@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.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Warner Losh]

Post by Poul-Henning Kamp
--------

Post by Alan Somers
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ryan Libby]

On Mon, Jan 4, 2021 at 10:08 AM Warner Losh <***@bsdimp.com> wrote:
...

Post by Warner Losh
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.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David G Lawrence]

Post by Warner Losh
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.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Poul-Henning Kamp]

--------

Post by David G Lawrence
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
***@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.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[grarpamp]

Post by David G Lawrence
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.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jamie Landeg-Jones]

Post by Ryan Libby
...

Post by Warner Losh
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.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Warner Losh]

Post by David G Lawrence

Post by Warner Losh
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

Post by Warner Losh
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Warner Losh]

Post by Jamie Landeg-Jones

Post by Ryan Libby
...

Post by Warner Losh
As for date order, we could also add a commit hook that requires the

date

Post by Ryan Libby

Post by Warner Losh
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

Post by Ryan Libby

Post by Warner Losh
add notes... but since there's no checkout by date feature, I'm not

sure

Post by Ryan Libby

Post by Warner Losh
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jamie Landeg-Jones]

Post by Warner Losh

Post by Jamie Landeg-Jones
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Graham Perrin]

Re: git non-time-sequential logs

Post by Warner Losh

Post by Jamie Landeg-Jones
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.

[Graham Perrin]

Git: timestamps

Post by Graham Perrin
Alongside 'tree', click 'log'

Thanks, but I wanted the file dates, not the log!

Post by Graham Perrin
<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


_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christian Weisgerber]

Post by Graham Perrin
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 ***@mips.inka.de
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jamie Landeg-Jones]

Post by Graham Perrin
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.

Post by Graham Perrin
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jamie Landeg-Jones]

Post by Graham Perrin
Alongside 'tree', click 'log'

Thanks, but I wanted the file dates, not the log!

Post by Graham Perrin
<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!
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Enji Cooper]

Post by Alan Somers

Post by Poul-Henning Kamp
--------

Post by John Kennedy
This might be perfectly natural and just new to me, but when I look at

the

Post by John Kennedy
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
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Franco Fichtner]

Post by Enji Cooper
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

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Kennedy]

Post by Franco Fichtner
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
# 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.

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ryan Libby]

Post by Franco Fichtner

Post by Enji Cooper
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
# 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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Baldwin]

Post by John Kennedy

Post by John Kennedy
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
commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, freebsd/main, freebsd/HEAD)
Date: Mon Jan 4 17:30:00 2021 +0100
commit f61a3898bb989edef7ca308043224e495ed78f64
Date: Mon Dec 14 18:56:56 2020 +0100
commit b6cc69322a77fa778b00db873781be04f26bd2ee
Date: Tue Dec 15 13:50:00 2020 +0100
commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
Date: Mon Jan 4 16:23:10 2021 +0100
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Theron]

Post by John Baldwin

Post by John Kennedy

Post by John Kennedy
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
commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, freebsd/main, freebsd/HEAD)
Date: Mon Jan 4 17:30:00 2021 +0100
commit f61a3898bb989edef7ca308043224e495ed78f64
Date: Mon Dec 14 18:56:56 2020 +0100
commit b6cc69322a77fa778b00db873781be04f26bd2ee
Date: Tue Dec 15 13:50:00 2020 +0100
commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
Date: Mon Jan 4 16:23:10 2021 +0100
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?

[Gary Jennejohn]

On Mon, 4 Jan 2021 08:22:56 -0800

Post by John Kennedy
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.

Post by John Kennedy
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
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mark Millard]

Alan Somers asomers at freebsd.org wrote on

Post by Alan Somers

Post by John Kennedy

Post by Toomas Soome
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.

Looks like you did not notice the change to screen.textmode :

QUOTE
commit babda0952f8355a89b3241d5e8943c7da0fa4f6b
Author: Toomas Soome <tsoome at FreeBSD.org>
AuthorDate: 2021-01-06 11:46:34 +0000
Commit: Toomas Soome <tsoome at FreeBSD.org>
CommitDate: 2021-01-06 12:38:55 +0000

loader: instead of hw.vga.textmode, use screen.textmode

hw.vga.textmode is directing VT VGA backend to use text mode.

The default screen mode for BIOS loader is text, and default
screen mode for VT VGA backend is graphics (unless we are running on
hypervisor or hw.vga.textmode is set to 1). Using hw.vga.textmode
for loader does remove possibility to have graphical mode VT VGA with
text mode loader.

screen.textmode can have possible values "0" to disable text mode,
and "1" to set text mode.
END QUOTE

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mark Millard]

[Just resent with corrected email address.]

Alan Somers asomers at freebsd.org wrote on

Post by Alan Somers

Post by John Kennedy

Post by Toomas Soome
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.

Looks like you did not notice the change to screen.textmode :

QUOTE
commit babda0952f8355a89b3241d5e8943c7da0fa4f6b
Author: Toomas Soome <tsoome at FreeBSD.org>
AuthorDate: 2021-01-06 11:46:34 +0000
Commit: Toomas Soome <tsoome at FreeBSD.org>
CommitDate: 2021-01-06 12:38:55 +0000

loader: instead of hw.vga.textmode, use screen.textmode

hw.vga.textmode is directing VT VGA backend to use text mode.

The default screen mode for BIOS loader is text, and default
screen mode for VT VGA backend is graphics (unless we are running on
hypervisor or hw.vga.textmode is set to 1). Using hw.vga.textmode
for loader does remove possibility to have graphical mode VT VGA with
text mode loader.

screen.textmode can have possible values "0" to disable text mode,
and "1" to set text mode.
END QUOTE

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de