Summary: | lilo error using udev | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Roger <rogerx.oss> |
Component: | [OLD] Core system | Assignee: | Tony Vroon (RETIRED) <chainsaw> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | blocker | CC: | gregkh |
Priority: | High | ||
Version: | 2004.1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Roger
2004-06-05 22:08:20 UTC
OK. It would seem that I have confirmed this bug to be originating from lilo. I took the time to emerge/compile grub and grub works flawlessly. I'm guessing this bug with lilo has to deal with how udev implements the device (ie. /dev/hda). (btw. I kinda like grub, nice white on black menu ;-) How are you telling lilo which disk to write to? Care to attach your /etc/lilo.conf file? I'm pretty sure at this point that this is a lilo bug when using udev. Grub has no problems writing to the /dev/hda (non symlink) device when using udev. But lilo has an issue all of a sudden when using udev. My bet is everyone is now using Grub. lol. If needed, writing to /dev/hda and not /dev/hda1, etc. menu-scheme=Wb boot = /dev/hda prompt #default=vanilla default=vanilla-2.6.6u map = /boot/System.map compact # faster, but won't work on all systems. lba32 timeout=20 vga = normal Ah, so /dev/hda is a symlink for you? Sounds like a lilo bug then :) > Ah, so /dev/hda is a symlink for you? no. > Sounds like a lilo bug then :) More then likely. ;-) I have yet to search any lilo mailling lists, etc., but I would imagine that something like this may have already been reported if udev broke lilo (during the beginning of the linux-2.6.x kernel series releases.) I have lilo working fine for me on a udev system. The problem is though, that lilo insists on having /proc/partition naming identical to real device names. Using the default udev configuration in Gentoo, this works. The moment I try giving the IDE disk in my laptop a nicer name, lilo will fail. But it can work, definately. Ok, this looks like a lilo issue, not a udev issue, passing it on... Roger, can you try using the configuration file that udev comes with by default? The one that generates devfs-style names as well as /dev/hdaX. That's what I'm currently using on my laptop, without any errors. Also, please try how 22.5.9-r1 works for you, better, worse? Ok, sys-boot/lilo-22.5.9-r1 seems to work. But when I first tried lilo-22.5.9-r1, maybe becuase the emerge wasn't finished yet, it did give me the same "part_nowrite check:: No such file or directory" error. So I moved on and re-ran "grub-install /dev/hda" and then said, "Eh, maybe lilo didn't finish installing/emerging fully" and I decided to give lilo another try. This time it worked without errors. So basically I just mentioned my process here incase I find on reboot that lilo then still fails, but will only work after grub-install does it's thang. Give me a few days, or a week and I'll try reporting back when I get this verified for *sure*. I'm in the midst of travelling, so finding internet access is going to be a hassle. Just for kicks, I'm using the Gentoo's udev default rules & permissions: /etc/udev/rules.d/50-udev.rules /etc/udev/permissions.d/50-udev.permissions roger, could you tell me what your verification rounds came up with? nope. still getting the error: # lilo Warning: COMPACT may conflict with LBA32 on some systems part_nowrite check:: No such file or directory I'm now using grub and I'm noticing now they do now have password protection emplimented. The only thing I did not try was reverting to the original udev configurations (disabling the gento udev configurations). I'm currently spending 110% of my time getting GPRS networking functioning here and am mobile right now. So messing with more then I need to probably isn't a wise thing. ;-) I have not been able to reproduce your error despite various tries on my udev-only system without a device tarball. Some time has passed, and new versions have been released. If this is still an issue to you with the current version of LILO, please reopen this bug. |