>>>>> "Valdis" == Valdis Kletnieks <[email protected]> writes:
Valdis> The whole 'init=/bin/bash' style of recovery has been
Valdis> widely documented and often used (for instance, it's
Valdis> covered in the RHCE class and used in one of the hands-on
Valdis> labs to recover a non-booting system). That's a lot of
Valdis> people to retrain, and a lot of systems that need
Valdis> changing...
Valdis> (Trust me - if it's 3AM, and you type 'init=/bin/sh' and
Valdis> it outputs the '#' but won't take input, you WONT think of
Valdis> that kernel and initscripts change from 3 months ago...)
Explain to me how a kernel compiled with
CONFIG_SERIO=m
CONFIG_KEYBOARD_ATKBD=m
would be able to boot with "init=/bin/sh" and still have the keyboard
working.
I've just verified that "make allmodconfig", which is what many people
are tempted to do once they've learnt about it, will produce such a
.config.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On Wed, 09 Jun 2004 10:17:04 +0200, Sau Dan Lee said:
> Explain to me how a kernel compiled with
> CONFIG_SERIO=m
> CONFIG_KEYBOARD_ATKBD=m
> would be able to boot with "init=/bin/sh" and still have the keyboard
> working.
Explain to me why you think that example is a good reason why
a kernel compiled with
CONFIG_SERIO=y
CONFIG_KEYBOARD_ATKBD=y
should *NOT* be able to boot with 'init=/bin/sh'.
>>>>> "Valdis" == Valdis Kletnieks <[email protected]> writes:
Valdis> On Wed, 09 Jun 2004 10:17:04 +0200, Sau Dan Lee said:
>> Explain to me how a kernel compiled with CONFIG_SERIO=m
>> CONFIG_KEYBOARD_ATKBD=m would be able to boot with
>> "init=/bin/sh" and still have the keyboard working.
Valdis> Explain to me why you think that example is a good reason
Valdis> why a kernel compiled with
Valdis> CONFIG_SERIO=y
Valdis> CONFIG_KEYBOARD_ATKBD=y
Valdis> should *NOT* be able to boot with 'init=/bin/sh'.
"make help" shows:
...
Configuration targets:
oldconfig - Update current config utilising a line-oriented program
menuconfig - Update current config utilising a menu based program
xconfig - Update current config utilising a QT based front-end
gconfig - Update current config utilising a GTK based front-end
defconfig - New config with default answer to all options
allmodconfig - New config selecting modules when possible
allyesconfig - New config where all options are accepted with yes
allnoconfig - New minimal config
A person trying to upgrade from 2.4 would suppose that the 2.4 .config
won't work and would likely start with "make allmodconfig", and then
"make {menu/x}config". With 100s (or 1000s) of configuration items,
it is not easy for a 2.4-er to discover that one now has to explicitly
enable i8042 and atkbd. So, it is likely for him to have:
CONFIG_SERIO=m
CONFIG_KEYBOARD_ATKBD=m
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On Wed, 09 Jun 2004 19:12:09 +0200, Sau Dan Lee said:
> A person trying to upgrade from 2.4 would suppose that the 2.4 .config
> won't work and would likely start with "make allmodconfig", and then
> "make {menu/x}config". With 100s (or 1000s) of configuration items,
> it is not easy for a 2.4-er to discover that one now has to explicitly
> enable i8042 and atkbd. So, it is likely for him to have:
>
> CONFIG_SERIO=m
> CONFIG_KEYBOARD_ATKBD=m
*plonk* <add to killfile>
OK. You proved that it's possible to create a kernel configuration that won't
boot on your hardware (hey, people who boot off IDE or SCSI and build those
drivers as modules have to play initrd games too).
Let me know when you actually answer the question - which was "Why does that
mean it's OK to break users who *do* answer with 'y' for those options?" (An
alternate way of looking at it is that you will mandate a situation where the
only *useful* values are equivalent to 'm' and 'n' - either you don't have it
at all (n) or you need userspace assistance before you have it (m).