Hello Todd; I had not thought of a possible solution. I am not one of the devs. However I would imagine a symlink in /boot/ from vmlinuz to the relevant kernel, which is changed either by wrapper script surrounding /sbin/lilo and/or by the relevant kernel PGKBUILD (or install of said same binary) might work.
Or some sort of kernel install script might be in order. I *DO* realize that such things are not well handled by linux, and of course we all are use to such manual intervention. Perhaps this is best solved by appropriate notation in the various echos to console from the various install files ? Very best regards; Bob Finch P.S.... I did not mean this as a bug per se. I meant it as a gotcha that appeared with changes to udev, although I am not certain just why this kind of thing chose to show up just now. Perhaps it was because the kernel was a sort of "forced" upgrade ? Again I am not sure, and I am merely pointing out what happened. Perhaps more documentation by way of commenting in the lilo.conf file itself might help somewhat ? > Hi Bob, > > I guess my big question is - What is your proposed solution? > > (Ignoring the many tasting looking pieces of bait...and trying to stick > with the key issue) > > lilo.conf as provided is a template to be customized and the user is > given the chance to customize during the install. Not having the > correct values will cause problems like any other config file, but the > user is expected to be able to manage his config files. The correct > value for image > = /boot/________ will vary depending on which kernel the user opts for > (kernel24, kernel26, kernel26mm etc...) . To expect pacman to *guess* > what the user wants is unreasonable and not very *Arch-like*, as there > are a multitude of possible customizations that are possible - > including the one you mention below. > > I understand that you see a problem with the installed kernel having a > different name than that which is identified in the lilo.conf... There > are many possible valid reasons for this. > > Can you suggest a solution that: > > A.) Works for all the different possible configurations out there. B.) > Follows the Arch philosophy of package/configuration management. > > > Smile and have a great day, > > Todd Maynard > > > On Tuesday 11 October 2005 07:31 am, [EMAIL PROTECTED] wrote: >> OOPS: >> >> Small correction below. >> >> (And sorry about that !!) >> >> Very best regards; >> >> Bob Finch >> >> > Hey gang; >> > >> > Yes I already know this might belong on the bug tracker. Then again >> it should also be promulgated more widely. A recent experience with >> the bugtracker also dissuades me from posting there. So I will post >> it here. If this info is on the forums; well I do not post there as >> a rule, and certainly have not checked there (yet). >> > >> > Two things came up during my recent upgrade on my desktop machine at >> work. I started the upgrade last Thursday and completed it yesterday >> morning. >> > >> > 1 - From lilo.conf (which most likely will be named >> > /etc/lilo.conf.pacnew): >> > >> > image=/boot/vmlinuz >> > label=arch >> > root=/dev/hda3 >> > read-only >> > >> > 2 - From PKGBUILD for kernel26: >> > >> > cp arch/i386/boot/bzImage $startdir/pkg/boot/vmlinuz26 >> > >> > >> > i.e. lilo (...$ /sbin/lilo) will not successfully run with the two >> different names for the image file, or worse yet; it will >> successfully run with some other image that might happen to reside >> at >> > /boot/vmlinuz26. >> >> this should read /boot/vmlinuz >> >> > Yes, I am aware that on a previous install that is now upgraded to >> the new kernel and therefore the new udev system will require the >> user to edit his fstab, and lilo conf. at the very least. And he >> will know to do so, if he carefully reads the console output >> generated during the upgrade from kernel26.install. Nonetheless, a >> new install (for instance from an ftp style install) will >> potentially have problems with this. >> > >> > While on the subject of new installs and to whomever is in charge of >> said install machinations; I filed a bug report in the last month or >> two at the bugtracker. I have not received any notification that it >> has been attended to *and* repaired. It was a relatively bad bug in >> that file(s) were NOT being installed on an ftp install. Someone who >> cares might want to go look this one up. >> > >> > >> > Anyways, thanks everyone for the attention and your time. >> > >> > >> > Very best regards; >> > >> > >> > Bob Finch >> > >> > >> > >> > _______________________________________________ >> > arch mailing list >> > [email protected] >> > http://www.archlinux.org/mailman/listinfo/arch >> >> _______________________________________________ >> arch mailing list >> [email protected] >> http://www.archlinux.org/mailman/listinfo/arch > > _______________________________________________ > arch mailing list > [email protected] > http://www.archlinux.org/mailman/listinfo/arch _______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
