Bug 113910

With rawhide-20040121 the behavior has changed.  The system no longer
shuts down.  Instead it simply stops (text screen changes background
color to red and then nothing happens).

Attempting to switch between VCs leads to screen corruption.

Has the way framebuffers as modules work changed?  Loading vga16fb
doesn't seem to automatically change the console as happened with 2.4

Hmm, yeah, I see this too with rawhide-20040122.  The install is just
stuck with the initial blue background screen scrolled up a few lines.
 I see no text though, as though loader error messages were written in
an invisible font.

> Has the way framebuffers as modules work changed?

oh boy, where to begin..
looks like yet another regression in this area.

Should this be re-assigned to the kernel?

No, fbdev has changed behavior in 2.6, I talked with the upstream
maintainer.  Now I get to change bogl to match.  

Should be fixed with newer bogl + anaconda rebuild afterwards.

*** Bug 116254 has been marked as a duplicate of this bug. ***

Thanks.  Confirmed fixed in latest tree.

Errm, the initial segfault is gone, but now it segfaults
before "starting X" even with "linux text selinux=0"
I'm afraid.

Laptop w/pcmcia?

Nope, Dell Dimension 2400c, and Dell Precision 450.

Mine is Dell Dimension 450, desktop, video card is:
VGA compatible controller: nVidia Corporation NV18GL [Quadro4 NVS AGP
8x] (r
ev 162).

Nevermind, now it is crashing as soon as one selects
a ja install from boot.iso again.

should be fixed in rawhide now (sys_shmat was broken briefly)

Still happening with kernel-2.6.3-1.109.

still segfaulting with kernel-2.6.3-1.116.

Still happens with FC2 test2 .

I just noticed that bterm segfaults too.  Is that the same issue?

Comment 19: it sure looks like bterm and 2.6's way of doing the
framebuffer is the culprit.

Yes, definitely the same issue -- Adrian, debian has a newer bogl now.
 It might possibly work better (it's at least worth trying).

Thanks, let me re-assign it to bogl, then. :)

And fyi, I've disabled the use of bterm in anaconda until this works
... having the installer segfault is less than useful and I'd rather
have it in English than just not work at all.

So, for nfs and other installation modes which start up with TUI,
could you let user to set favorite installation language once again
after anaconda GUI starts up?

Because
- Japanese users do mistakes with English message only
  and installation mistakes is sometimes critical
  (like partition blow away)
- Such failure voids translators works
- Bterm issue should not affect GUI installation language

We would meet again and again with this bterm fault with future
version of kernel, new cheap but popular video cards, or
unknown CPU architecture. And users want to use installer with
their favorite language at that time.

Umm, comment 24 is for comment 23.
This report is filed as bogl now...

Yes, this is how things currently work (we stay in English only until
we get to graphical mode where Japanese display is fine).  Basically,
you select Japanese in an NFS install and it tells you it's not
available until you get to the graphical portion of the install.

Debian had fixed it recently (0.1.18-1) for this problem. Can we have
a look and test it?

I've build bogl-0.1.18-1 on my test box, and it works fine on
2.6.7-1.457smp at least. Jeremy, could you update our bogl package to
0.1.18-1 ?

Created attachment 101630 [details]
modified spec file.diff

Created attachment 101631 [details]
a patch to replace bogl-0.1.9-rh.patch

this problem should be fixed in 0.1.18-1. please confirm it. thanks

Do we need to reenable bogl to test this fix?

A new bogl needs to make it into the build roots so that when I build
anaconda, the loader can link against it.  I've removed my "disable
bogl" patch for now.

Kernel seems to oops now when doing a Japanese TUI nfs install.

Please file the oops as a (seperate preferably) kernel bug (and feel
free to cc me on it)

it works on rawhide-20040801. however when the vt is switched, the
rendering was screwed up, and it happens on anaconda only - switching
vt on bterm works fine.

What kernel are you not seeing rendering problems with?  I just tried
on my test box with 2.6.7-1.499 and see the rendering break running
just bterm when I switch vts (which makes me think it's not just anaconda)

I tried 2.6.7-1.499 too. but it works as I said. kernel was booted
with vga=0x31[12] and run bterm as root. was my test case different
with yours?

Yes, you want to be using vga16fb, not the vesafb stuff.

Boot and then modprobe vga16fb and then running bterm will initialize
the framebuffer, etc (exactly as anaconda does things).  

Thanks Jeremy. indeed, the rendering breaks when I switch vts and when
I exit from bterm - it works again when I'm back from the broken vts,
though. it looks like to me it's only difference between anaconda and
running bterm as usual.

The vga16fb and vesafb rendering are somewhat different drawing paths
form what I remember...

Problem still persist in rawhide-20040828.

just tried jfbterm with vga16fb. and I saw similar problem on that.
perhaps this bug should be reassigned to the kernel?

tried on 2.6.8-1.607. switching vt looks fine except exit bterm. when
I was back from bterm and vt scroll up, it's broken a bit. but it does
render correctly after switching back vt.
Jeremy, how can I do test if it works on anaconda? current kernel
looks much better than before. it's probably worth testing on anaconda
again.

I'll turn it on again for the next anaconda build.

Tested with anaconda-10.0.3.18-1.i386.rpm and
bogl-bterm-0.1.18-2.i386.rpm and the machine shut down automatically
after entering the NFS dir.

The text rendering in traditional chinese is good though.

Observation
- clicked ok, after entering the NFS installation path
- the screen background turn from blue to red
- output the graphical card
- crash

*** Bug 131081 has been marked as a duplicate of this bug. ***

So we're defitely better off now, although still not completely good.

bterm linked against glibc seems fine, bterm linked against diet
doesn't.  Running bterm-diet and switching vts shows the same sig11 as
with it in anaconda (where we use diet to build the loader)

And I have a feeling that this is related to bug 134546...

With the frame buffer fixups plus the dietlibc fix for bug 134546, I
think we should be good once I build anaconda again (version will be
>= 10.0.3.20)

rawhide-20041019 should contains those fixes, right? signal 11 was
still occurred when I switched vt, though.

Tried with anaconda-10.0.3.21-1, signal 11 still occurred for me when
I switched vt.

You need a tree with anaconda >= 10.1.0 due to a series of silliness...

I've tested rawhide-20041021, and bogl works fine on both 1st stage of
TUI and GUI even if I switched vts. also, on 2nd stage, TUI installer
works on bogl, and GUI installer was realized properly.

Thanks Jeremy!