Matthias Drochner <M.Drochner%fz-juelich.de@localhost> writes: > gson%gson.org@localhost said: >> I replaced the /boot on my non-booting 201001150000Z system by a copy >> from a 201001140000Z system, and now it boots. So yes, the problem >> does appear to be in /boot. > > Yes I see -- the new bits are located in the installboot-installed > part, not in the filesystem visible /boot. Didn't expect that > something replaces /boot without applying installboot. This is the kind of thing that really needs to be in updating. It's never been clear to me exactly what the compat order is between installboot, boot, and kernel in terms of which is expected to deal with older versions of the others. I could easily invert the meaning of the flags, so that the default values don't change. This would mean that we'd have kind of "negative options" then which are less esthetical at least for me. It's almost like we need a version passed from installboot (bootxx_foo I mean) to /boot so that /boot can know what the flags are supposed to mean. The notion that a flag not being set means something when you don't know if the caller knew to set it is dangerous. I see what you mean about negative options, but there's also an argument that bits not being set should mean 'do the normal thing' which is sort of like 'do what would have worked last week'.
Attachment:
pgpNtuc2uEM5V.pgp
Description: PGP signature