On Fri, 2004-11-19 at 11:47 -0800, Chris Barker wrote:
> Being the user who "inattentively clobbered something vital", and then
> started this thread, I can say:
> 1) I'm a newbie at gentoo and udev (as is everyone), but not a Linux
> newbie. I've been hand editing my fstab on various distributions for
> over ten years.
> 2) If I made this mistake, probably someone else has or will too.
> So, perhaps it's useful to know why I made the mistake (by the way, I
> did keep my old fstab around, so it was easy to put back, and the reason
> I got confused was that the system worked fine with the borked fstab,
> except for errors trying to run fschk on boot. It's still a mystery to
> me how the system ran with that fstab!)
The system would still boot to your root partition thanks to the root=
line when booting your kernel. It would just start freaking out after
that. You probably also did not have any swap when you booted.
> Anyway, the reason I got confused was that the fstab that came with the
> udev package had "BOOT", "ROOT", and "SWAP" in it with NO explanation
> that those were placeholders. They looked to me like they might be magic
> names that udev figured out for you. The fact that my system worked
> reinforced this idea. So:
fstab is provided by baselayout. It is actually just coincidence that
you were changing to udev at the same time.
> if there were a single, simple comment it that file, I would not have
> made the mistake. Something like:
> # This is a template of an example fstab file. Replace "BOOT", "ROOT",
> # and "SWAP" with the appropriate drive devices for you system, for
> # example: "/dev/hda3" for the third partition of the first IDE drive.
This is commented almost verbatim in the handbook when you created your
fstab way back when you first installed Gentoo. Now, I am sure you
don't remember this one detail from your install, and I don't expect you
to remember it. Personally, I think we should *never* provide system
files such as fstab in an ebuild, especially one as ominous as
> Another thought: Is there a way for portage to tell the difference
> between an install and an upgrade? and if an upgrade, what version is
> being upgraded from? In an upgrade, there is no need install a new
This functionality is being worked on, however. There is also
functionality being worked on to know if a file has been edited since
merge, and to auto-merge the new file if it has not been changed (md5
and mtime match) since merge.
> config file unless the features or syntax of that config file has
> changed. In this case, I can think of no reason that I would ever have
> needed a new fstab after upgrading udev, and a BIG reason to keep the
> old one. It would be nice of portage could figure this out for me and
> not make me figure it out myself. Indeed, if there has been a change in
> features or syntax, I'd love to know what those changes are, in some
> easy to access place.
I mean, portage did not overwrite your fstab, you did. You would have
had to have run etc-update and told it to overwrite. Now, what would
make this so much easier is when portage is able to automatically update
files that you have *not* changed. This will mean that *everything* in
etc-update will be something that you have modified, and therefore,
something you will want to look at and determine if you want to update,
discard, or merge. The current situation definitely is not the most
optimal and action is being taken to rectify it, but changes to portage
itself are becoming increasingly slow-moving due to there being many
more features to test and retest before deploying them on the masses.
Release Engineering - Operational/QA Manager
Games - Developer