From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Description of problem: System boots directly into "segmentation faults" after clean install. INIT: Id "x" respawning too fast: disabled for 5 minutes. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install FC2 T2 2. Boot normally. Actual Results: Init loads and X kicks out errors and segfaults. Expected Results: Should load RHGb or fallback on text mode. Additional info: Something about unicode_start $SYSFONT $SYSFONTMATCH on line 80. /etc/X11/prefdm
I am seeing the same exact fault on FCT2 installed on an MS Virtual PC. The hardware driver is an S3 Trio 64. I have reinstalled three times with the same error. I can reproduce the error at will <G>...
Resolved on FC2 T3 (with Virtual PC). Thanks.
X.org X11 hasn't changed at all. This must have been caused by the kernel's buggy vm86() code which was fixed recently. That caused a SEGV to occur in vm86() on any video driver which used the video BIOS.
Bug alias of the vm86 issue is "vm86-segv" for reference.
Crap, this is not fixed (my bad). I was thinking of something else (anaconda). In my haste I closed the bug. It's still a problem when RHGB tries to load on FC2 T3. Same error with unicode_start $SYSFONT $SYSFONTMATCH on line 80. Repoened.
unicode_start has nothing to do with X. It sounds to me like you're having 2 problems: 1) Your X server isn't starting 2) You're getting an unrelated error about unicode_start from rc.sysinit or some other initscript We don't support Virtual PC installations, however if you attach your X server log and config file, and /var/log/messages, I will review the issue anyway in case it is something obvious. Thanks in advance.
When I switch to the VCs, every command returns a segfault error. What is the best way to export the logs on a system that will not boot?
FYI - I tried a "linux rescue" and /mnt/sysimage/var/log/messages is 0 bytes.
If every command is segfaulting, then that very definitely is not an X specific error or bug. Most likely this is a problem caused by using VirtualPC instead of a real machine. Please try using real x86 hardware and if the problem persists, feel free to reopen the report. Closing as NOTABUG
Another engineer just mentioned to me also, that the 2.6.x kernel contains polymorphic code, and Virtual PC doesn't support that. That could be the problem you're experiencing perhaps. Just thought I'd mention that in case it saves you time trying to find an alternate solution. Hope this helps.
Hell of an answer guys. Maybe you should be passing this on to Linus then. It's comments like this that make it easy for corporations to stay in the Windows camp. I would suggest you find a way to make it work...
It's not Red Hat's fault that VPC will not support "polymorphic code". Yes, it sucks, but that's just the way it is. I believe VMWare has committed to 2.6 kernel support and other features like 64 bit extensions. At the same time, Microsoft has removed official Linux support from Virtual PC. Perhaps people like you and I should reevaluate our virtualization systems and choose a more Linux friendly vendor.
Hi Marlin, I'm sorry you seem to be upset with Red Hat however I think there is a bit of a misunderstanding and I would like to try and resolve that and help you to find a workable solution if possible. First I'll try to resolve the misunderstanding through a bit of explanation and clarification, and then I'll make some recommendations that may help you to find a reasonable solution that meets your real needs. Background: The Virtual PC problem seems to be that it does not support polymorphic code. I am not a kernel engineer myself, however I've briefly discussed this issue with a few kernel engineers. To the best of my current understanding, the Linux kernel uses polymorphic code for patching in code optimized for the running processor at boot time, which is a very important feature of the current Linux kernel, as it allows for a single binary kernel to support many CPUs, while also containing optimizations for all common CPUs, rather than being optimized for a single CPU. This feature also benefits Red Hat and our customers, by allowing us to support more processors with fewer kernels, which in turn has a major engineering cost savings that allows us to develop more features for our next generation products, and to do so in much less time. The problems experienced by the reporter, yourself and perhaps others, are allegedly due to a design flaw in Virtual PC itself, and there may be various other problems as well. If Red Hat did support Virtual PC officially, since this is a design flaw in Virtual PC, and not a bug in the OS that is causing the problem, the only way that these issues could really be resolved, is for the Virtual PC vendor to modify their proprietary software to support the 2.6.x Linux kernel properly, and to address any other flaws in the software which prevent it from being able to use modern Linux systems. It seems that VirtualPC may be intentionally not supporting Linux, and unfortunately there isn't much that Red Hat can do about that, however we may be able to provide some other type of solution that meets your needs, and I'll discuss that further below. Assuming we were to contact Linus about this, we have no influence over Linus's decisions, and both Red Hat and our customers support and benefit from this feature greatly. Except for VirtualPC users perhaps. ;o) Bugzilla bug reports come to engineering, and while we do not make the decisions of what platforms Red Hat supports, we do have to honour this. Even though Virtual PC is unsupported, I did try to acquire further information in case I was able to do something on my own anyway, however once I was able to conclude that the problem was caused by a design flaw in Virtual PC, since that is beyond Red Hat's support policies and beyond Red Hat's reach of being able to fix, I closed this as NOTABUG, although NOTOURBUG would probably be a useful bugzilla resolution addition, as it is a bug, just not a Red Hat bug. Possible solution: That said, what is much more important, is that you and other customers have a workable solution of some kind. As an engineer, I'm not the best suited to determine that, however Red Hat customers and potential customers are encouraged to contact the Red Hat sales department or Red Hat support for inquiries regarding which processor architectures or virtualized platforms are supported by Red Hat and which are not, and what technical and customer support options are available. Our sales/support teams are much better equipped to provide a direct solution for a given customer's needs. This is also the best route for customers to provide feedback to Red Hat of what types of solutions and support they require, and inform Red Hat of feature and/or other requests for the future. Such feedback is important to determine future product and support level planning. Please contact Red Hat sales at sales, or by dialing 1-888-RED-HAT1, and one of our associates can work with you to find a solution that best meets your needs. I'd like to offer my apology for any confusion I may have caused in earlier comments, and hope that Red Hat sales/support is able to offer a solution or make a recommendation which can meet your needs. Thanks, TTYL
Sorry I did not respond to this sooner, I had to play "colonel" this past weekend <G>. Actually I understand exactly where you are coming from on this issue. I am an IT professional and make my living tying different operating systems, etc. together for customers. My point is one that I hear echoed from my customers and frankly is a valid one. I have had similar issues with Novell in the past when they thought they could not get torched by anyone and Microsoft made mincemeat out of them. I, along with a lot of other resellers, got out of the Novell camp when they began to blame their resellers for their own marketing mistakes. And this is a marketing mistake that Red Hat can't afford to make. Linux is getting into smaller businesses primarily due to cost issues, but telling a small business owner that you won't make something work just because it's Microsoft isn't going to keep you on the premises. I have enough experience with marketing folks (I have an MBA, too) that they do not listen to facts when those facts disrupt their thinking and the greatness in their own minds. That's why I feel sorry for the engineers on matters like this. We who are small and face customers everyday knows what is said and done. When you get too big, you lose contact with the customers and you will lose business in the long run. Maybe big business helps the stock price, but it's small business that pays the bills and offers the best engineering experiences. So I guess what I am saying here is that I won't waste my time with your marketing folks and let things lie as they are. My customers will most likely remain in the Microsoft camp because that is where things work and reasonably well. I continue to play with Linux here on the side... Thanks for listening.
It would have been nice to see the FC2 release notes reflect that it's a known issue that MS VPC will not support FC2. I think it's a valid point and would saved many users a lot of time.
Reassigning to "distribution" component for consideration of the reporter's request in comment #15.
Assigning to the release notes component. However, it doesn't seem right to claim <foo> doesn't work if we haven't actually verified it inhouse (and, with virtual PC, we haven't, AFAIK.)
Closing as notabug due to the lack of in-house resources to verify/validate this issue for documentation purposes.
I'm pretty sure it's valid. I have tested other distos with 2.6 and it barfs. Anyway, thanks for the update.
Here's an idea, FWIW (but I don't think I have time to test this myself): If you try a 2.6 kernel with CONFIG_X86_GENERIC disabled, does that work around this problem?
Created attachment 102719 [details] Screenshot Screenshot of 2.6 running in VPC.
FYI - 2.6 works in VPC under Gentoo 2004. Added a screen shot.
Would you mind attaching your .config from the Gentoo 2004 2.6 kernel to this bug?
Created attachment 102742 [details] config-2.6.7-gentoo Requested .config file for 2.6.7