Re: Problem with the serial port in Fedora Core 6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2006-11-11 at 19:19 -0500, Gene Heskett wrote:
> On Saturday 11 November 2006 17:26, Craig White wrote:
> >On Sat, 2006-11-11 at 17:13 -0500, Gene Heskett wrote:
> >> On Saturday 11 November 2006 12:30, Craig White wrote:
> >> >On Sat, 2006-11-11 at 10:45 -0500, Gene Heskett wrote:
> >> >> >> Anyway, here is the grub.conf as it exists now, whats wrong with
> >> >> >> it? ----------------
> >> >> >> # grub.conf generated by anaconda
> >> >> >> #
> >> >> >> # Note that you do not have to rerun grub after making changes
> >> >> >> to this file
> >> >> >> # NOTICE:  You have a /boot partition.  This means that
> >> >> >> #          all kernel and initrd paths are relative to /boot/,
> >> >> >> eg. #          root (hd0,0)
> >> >> >> #          kernel /vmlinuz-version ro
> >> >> >> root=/dev/VolGroup00/LogVol00 #          initrd
> >> >> >> /initrd-version.img
> >> >> >> #boot=/dev/hda
> >> >> >> default=0
> >> >> >> timeout=7
> >> >> >> splashimage=(hd0,0)/grub/splash.xpm.gz
> >> >> >> # hiddenmenu
> >> >> >> # 0
> >> >> >> title Fedora Core (2.6.18-1.2798.fc6xen)
> >> >> >> 	root (hd0,0)
> >> >> >> 	kernel /xen.gz-2.6.18-1.2798.fc6
> >> >> >> 	module /vmlinuz-2.6.18-1.2798.fc6xen ro
> >> >> >> root=/dev/VolGroup00/LogVol00 module
> >> >> >> /initrd-2.6.18-1.2798.fc6xen.img
> >> >> >>
> >> >> >> # 1
> >> >> >> title Fedora Core 6 (2.6.19-rc5)
> >> >> >> 	root(hd0,0)
> >> >> >> 	kernel /vmlinuz-2.6.19-rc5 ro root=/dev/VolGroup00/LogVol00
> >> >> >> rhgb quiet module /initrd-2.6.19-rc5.img
> >> >> >>
> >> >> >> # 2
> >> >> >> title Fedora Core 2 Menu
> >> >> >> 	rootnoverify (hd1,0)
> >> >> >> 	chainloader +1
> >> >> >> # 3
> >> >> >> title DOS
> >> >> >>         rootnoverify (hd0,1)
> >> >> >>         chainloader +1
> >> >> >>
> >> >> >> --------------
> >> >> >> # 1 will unpack, and boot to a missing console message, locked
> >> >> >> up, so somethings still missing even after I added the LVM
> >> >> >> stuffs.  It works fine for FC2, but without the LVM stuff that I
> >> >> >> built into this version after getting a very early crash because
> >> >> >> it wasn't there.  And believe it or not, the last 'DOS' entry
> >> >> >> does display in the boot menu.
> >> >> >
> >> >> >----
> >> >> >I can't tell that anything is wrong with your grub.conf other than
> >> >> > I've never seen the labels that you have added in grub and wonder
> >> >> > about them. I also wonder if the grub conf that you think is
> >> >> > loading is the one that is actually loading since when you add a
> >> >> > second disk to the equation, BIOS doesn't always see disk (hd0)
> >> >> > or (hd1) as you think it will.
> >> >>
> >> >> The bios see's them just fine, all 4 of them.  The FC6 install is
> >> >> on a 160GB as hd0, the FC2 install is on a 120GB as hd1.  A new
> >> >> lightscribe dual layer burner is hd2, and hd3 is a 200GB that
> >> >> amanda yses 180GB of for vtapes, FC2's /var is on hd3, and FC2's
> >> >> swap is on hd3. And if you are referring to the # 0 etc labels,
> >> >> I've been using them since grub was new, what 5 years ago?  There
> >> >> are in fact, 26 such entries in my FC2 grub.conf, and they all
> >> >> display correctly.  Mmm, it just occured to me that maybe its
> >> >> expecting a pair of () around the word 'menu', or maybe a kernel
> >> >> version?  But heck, its (the title line) supposedly just a label to
> >> >> display to the user AFAIK.
> >> >
> >> >----
> >> >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.

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.

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.

Craig


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux