On Saturday 11 November 2006 19:42, Craig White wrote: [huge snippage] >> >> >I have never had blank lines nor the extra lines like '# 1' in my >> >> >grub.conf but I have no idea what impact that they might have. >> >> >> >> Neither blank lines nor the # comments have ever effected it >> >> before. >> >> >> >> >I would guess that the reason #1 doesn't fully boot is not a grub >> >> > issue but rather an issue with your initrd that accompanies the >> >> > kernel or that LVM isn't compiled into the kernel but rather is a >> >> > module that can't load from a LVN partition. >> >> > >> >> >Again, I would suggest that you install the regular (non-xen) >> >> > kernel from fc6 and boot from that to see what happens - >> >> > especially with regard to the serial ports. >> >> > >> >> >Craig >> >> >> >> And that worked, I now have the usual serial discovery stanza's in >> >> my dmesg, and heyu is happy. >> >> >> >> So its the xen, whatever that is, thats screwing it up. I tried to >> >> bugzilla the missing ttyS's, but bugzilla didn't like my password. >> >> So I sent an email to the link provided and now have a reject >> >> message from bugzilla. Post by non-member. >> > >> >---- >> >there is an option for people who forget their passwords to have them >> >e-mailed to them. >> >> I did that, it didn't. >> >> >There also is already a bugzilla entry regarding the fc5/6 xen kernel >> >and serial ports which appears to be exactly your issue and a >> > suggestion by Bill Nottingham for motherboards that aren't entirely >> > cooperative with (not providing a pnp BIOS). >> > >> >Evidently your difficulties with bugzilla include searching... >> > >> >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204825 >> >> Correct, I didn't find that one, having gotten distracted by my >> inability to login. However theres another related bug nameing xen as >> the culprit in an x64 xen situation, it did take my login on that one >> and I appended a comment to that bugzilla entry that it also killed >> the serial ports in the ix86 versions too. >> >> But, I'll repeat myself AGAIN, I don't think udev has anything to do >> with THIS problem. One clue from this bug report may be that xen is >> hogging the serial ports somehow, and from the looks of the grub.conf, >> it has first dibs and locks everybody else out since with xen running >> (AIUI) the kernel itself is a client and xen prevents the discovery of >> something xen (the serial ports in this case) is useing. In any >> event, its appears that getting rid of xen solves the problem. So >> will you please quit harping on whether or not this udev nuwbie has a >> clue? Its not a udev problem according to what my detective work has >> found. > >---- >you're detective work notwithstanding, Bill Nottingham's suggestion to >put an entry into 'udev' rules was the suggested recommendation for the >problem but since you didn't try that with the xen kernel, didn't post >your results on this bugzilla entry after trying the recommended entry, >I guess none of us will ever be certain. And what sort of an entry might that be? It does create 4 devices now, as its written to do, but the devices are worthless when the onboard hardware hasn't been detected. >I guess I am glad that the non-xen kernel gives you what you wanted >after all (the serial port interfaces for your X11). I just assumed that >you chose the xen kernel with the intent to run xen virtualization, but >I am guessing that your motherboard doesn't support xen which is >probably the cause of the problem in the first place. Either way (I didn't choose it, anaconda did), and I have NDI if this biostar mobo supports xen or not, there has been precious little discussions about it on the 50+ mailing lists I lurk on. > >Now I agree with you that getting rid of the xen kernel solves this >problem. I don't agree with you a bit that it wasn't a udev problem >because if you again read Comment #5 on the above referenced bugzilla >entry, it is obvious that Bill Nottingham believes it is a udev related >problem. I still don't see what, if anything, udev could do about it when the hardware has not been detected. Does it have some sort of a magic twanger for that case that we common mortals don't know about? I'm now looking at that #5 comment, but have no clue because theres no preamble describing where to put those commands, which I assume would go in /.etc/udev/rules.d/50-udev.rules, but it contains no similar rules. Those in the know will I assume know where in that file, but to me thats not a usable fix without the whole story. But with some use of a figurative shovel to dig a little deeper it seems to indicate it should be added into /etc/udev/rules.d/05-udev-early-rules. It would be more at home there by far. Is this correct? There is a second reason I didn't pursue that angle, any attempt to modprobe anything 8250 related failed due to undefined labels in the module(s). Which brings me back to square one, what can udev do about it when the kernel can't find the hardware in the first place? Heck, right now, with them running, an lspci -vv doesn't show them. Whether they should show I don't recall. I just checked on my firewall box, and they don't appear there either, so perhaps I'm using the wrong tool. Sorry I'm so dense in your opinion. If it will make you feel better, I'll plead oldtimers since I had a birthday last month, having made it to 72. >Craig -- Cheers, Gene
