make menuconfig broken

make menuconfig broken

[Michal Zachar]

I dont know if it was not reported yet or not fixed yet.

It apeared about in version 2.6.20.xx or there about so it is broken already 
awhile.

Problem:

changing settings manualy seem to work. Where problem apears is that loading 
alternate config file changes settings but on exit '.config' file is not 
writen and one is advised to run make which bombs.

Also window:	Do you wish to save your new kernel configuration ?
				<ESC><ESC> to continue
					<YES>	<NO>

does not apear.

Solution for me is before exit to change content of window (Save an Alternate 
Configuration File) to .config. And only then file .config is writen.

It seems that contents of bouth Load and save Alt Conf File are set to same 
using Load. It may actualy write to alternate file instead to .config 

One which I'm compiling at present is 2.6.23.14 version

Regards Michael

Re: make menuconfig broken

[Sam Ravnborg]

Hi Michal.

Thanks for your report.

On Sat, Feb 02, 2008 at 06:29:59PM +0100, Michal Zachar wrote:
> I dont know if it was not reported yet or not fixed yet.
> 
> It apeared about in version 2.6.20.xx or there about so it is broken already 
> awhile.
> 
> Problem:
> 
> changing settings manualy seem to work. Where problem apears is that loading 
> alternate config file changes settings but on exit '.config' file is not 
> writen and one is advised to run make which bombs.
> 
> Also window:	Do you wish to save your new kernel configuration ?
> 				<ESC><ESC> to continue
> 					<YES>	<NO>
> 
> does not apear.
This is a bug - we should notice the config changed.

> 
> Solution for me is before exit to change content of window (Save an Alternate 
> Configuration File) to .config. And only then file .config is writen.
> 
> It seems that contents of bouth Load and save Alt Conf File are set to same 
> using Load. It may actualy write to alternate file instead to .config

And this is a feature not a bug.
I am well aware that this is a change in behaviour but
if you looks at top left corner you can see the current filename
and is thus told what menuconfig use as default filename.

	Sam

I fixed the bug like this:

>From 7c280820a7a66abbb6b3b3f82c3753c7564600f2 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam@ravnborg.org>
Date: Sat, 2 Feb 2008 20:44:09 +0100
Subject: [PATCH] kconfig: mark config as changed when loading an alternate config

Michal Zachar <mgzachar@mail.t-com.sk> reported that
menuconfig did not save the new config when loading
an alternate config unless he altered it manually.

Mark config as changed upon load of alternate config fixed this.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
 scripts/kconfig/mconf.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 50e61c4..734cf4f 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -821,6 +821,7 @@ static void conf_load(void)
 				return;
 			if (!conf_read(dialog_input_result)) {
 				set_config_filename(dialog_input_result);
+				sym_set_change_count(1);
 				return;
 			}
 			show_textbox(NULL, _("File does not exist!"), 5, 38);
-- 
1.5.4.rc3.14.g44397

2.6.0-test1 won't go further than "uncompressing" on a p1/32MB pc

[michaelm]

.config: http://www0.org/config

That is on a p1 150MMX 32MB PC, specifically an IBM ThinkPad 560E. It
will keep showing "booting the kernel, uncompressing" without going
any further. There will be some disk activity for at least 5-7 minutes
after that on a 5-10 seconds interval period, without change on the
screen. I tried removing framebuffer support or keep it but set
CONFIG_VIDEO_SELECT to 'n', but there is still the same output.

The bzimage is around 919Kb, I tried to make it as modular and small
as it gets to be "usefull" since I suspect this is too old to run 2.5,
but the bzimage still can't be less than 800-810 kilobytes.

-michael

Re: 2.6.0-test1 won't go further than "uncompressing" on a p1/32MB pc

[Charles Lepple]

michaelm said:
> That is on a p1 150MMX 32MB PC, specifically an IBM ThinkPad 560E. It

I just did a diff between your configuration, and that of my ThinkPad 770
(233 MHz Pentium MMX).

Note to defconfig maintainers: can these options be enabled by default on
i386 (like they were in 2.4)?

Things that you might want to enable:

CONFIG_ISA=y

CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_INPUT_AT_KEYBOARD=y

CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y

You also might want to turn off Trident FB support, and turn on generic
VESA support. I have had good luck with the VESA driver, but odd,
irreproducible errors with the Trident code (several versions back;
haven't retested).

-- 
Charles Lepple <ghz.cc!clepple>
http://www.ghz.cc/charles/

Re: 2.6.0-test1 won't go further than "uncompressing" on a p1/32MB pc

[Samuel Flory]

Charles Lepple wrote:

>michaelm said:
>  
>
>>That is on a p1 150MMX 32MB PC, specifically an IBM ThinkPad 560E. It
>>    
>>
>
>I just did a diff between your configuration, and that of my ThinkPad 770
>(233 MHz Pentium MMX).
>
>Note to defconfig maintainers: can these options be enabled by default on
>i386 (like they were in 2.4)?
>
>Things that you might want to enable:
>
>CONFIG_ISA=y
>
>CONFIG_SERIO=y
>CONFIG_SERIO_I8042=y
>CONFIG_INPUT_AT_KEYBOARD=y
>
>CONFIG_VT=y
>CONFIG_VT_CONSOLE=y
>CONFIG_HW_CONSOLE=y
>
Actual the i386 defconfig does this:
[root@grendel linux-2.6.0-test1]# grep -e VT -e HW_CONSOLE  -e SERIO -e 
INPUT_AT_KEYBOARD arch/i386/defconfig
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
[root@grendel linux-2.6.0-test1]#


  However a "make oldconfig" on a 2.4 .config doesn't pick this up.  In 
fact it appears to be impossible to select  CONFIG_VT  CONFIG_VT_CONSOLE 
in make menuconfig.

-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>

Make menuconfig broken

[Samuel Flory]

Samuel Flory wrote:

> Charles Lepple wrote:
>
>>
>> Note to defconfig maintainers: can these options be enabled by 
>> default on
>> i386 (like they were in 2.4)?
>>
>> Things that you might want to enable:
>>
>> CONFIG_ISA=y
>>
>> CONFIG_SERIO=y
>> CONFIG_SERIO_I8042=y
>> CONFIG_INPUT_AT_KEYBOARD=y
>>
>> CONFIG_VT=y
>> CONFIG_VT_CONSOLE=y
>> CONFIG_HW_CONSOLE=y
>>
> Actual the i386 defconfig does this:
> [root@grendel linux-2.6.0-test1]# grep -e VT -e HW_CONSOLE  -e SERIO 
> -e INPUT_AT_KEYBOARD arch/i386/defconfig
> CONFIG_SERIO=y
> CONFIG_SERIO_I8042=y
> # CONFIG_SERIO_SERPORT is not set
> # CONFIG_SERIO_CT82C710 is not set
> # CONFIG_SERIO_PARKBD is not set
> CONFIG_VT=y
> CONFIG_VT_CONSOLE=y
> CONFIG_HW_CONSOLE=y
> [root@grendel linux-2.6.0-test1]#
>
>
>  However a "make oldconfig" on a 2.4 .config doesn't pick this up.  In 
> fact it appears to be impossible to select  CONFIG_VT  
> CONFIG_VT_CONSOLE in make menuconfig.
>

  Try this in 2.6.0-test1:
rm .config
make mrproper
make menuconfig

  There is no option for CONFIG_VT, and CONFIG_VT_CONSOLE under 
character devices in "make menuconfig.

  This works:
rm .config
make mrproper
cp arch/i386/defconfig .config
make menuconfig


-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>

Re: Make menuconfig broken

[Sam Ravnborg]

On Mon, Jul 21, 2003 at 05:42:51PM -0700, Samuel Flory wrote:
> 
>  There is no option for CONFIG_VT, and CONFIG_VT_CONSOLE under 
> character devices in "make menuconfig.
> 
>  This works:
> rm .config
> make mrproper
> cp arch/i386/defconfig .config
> make menuconfig

The preferred way to achieve the default configuration is to use:
make defconfig

See also "make help" for a list of more options.

	Sam

Re: Make menuconfig broken

[Roman Zippel]

Hi,

On Mon, 21 Jul 2003, Samuel Flory wrote:

>   Try this in 2.6.0-test1:
> rm .config
> make mrproper
> make menuconfig
> 
>   There is no option for CONFIG_VT, and CONFIG_VT_CONSOLE under 
> character devices in "make menuconfig.

Try enabling CONFIG_INPUT.

Vojtech, how about the patch below? This way CONFIG_VT isn't hidden behind 
CONFIG_INPUT, but CONFIG_INPUT is selected if needed.

Index: drivers/char/Kconfig
===================================================================
RCS file: /home/other/cvs/linux/linux-2.6/drivers/char/Kconfig,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Kconfig
--- drivers/char/Kconfig	14 Jul 2003 09:22:00 -0000	1.1.1.1
+++ drivers/char/Kconfig	22 Jul 2003 08:08:26 -0000
@@ -6,7 +6,7 @@ menu "Character devices"
 
 config VT
 	bool "Virtual terminal"
-	requires INPUT=y
+	select INPUT
 	---help---
 	  If you say Y here, you will get support for terminal devices with
 	  display and keyboard devices. These are called "virtual" because you

Re: Make menuconfig broken

[Vojtech Pavlik]

On Tue, Jul 22, 2003 at 11:50:47AM +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 21 Jul 2003, Samuel Flory wrote:
> 
> >   Try this in 2.6.0-test1:
> > rm .config
> > make mrproper
> > make menuconfig
> > 
> >   There is no option for CONFIG_VT, and CONFIG_VT_CONSOLE under 
> > character devices in "make menuconfig.
> 
> Try enabling CONFIG_INPUT.
> 
> Vojtech, how about the patch below? This way CONFIG_VT isn't hidden behind 
> CONFIG_INPUT, but CONFIG_INPUT is selected if needed.

Fine with me.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Make menuconfig broken

[James Simmons]

> >   Try this in 2.6.0-test1:
> > rm .config
> > make mrproper
> > make menuconfig
> > 
> >   There is no option for CONFIG_VT, and CONFIG_VT_CONSOLE under 
> > character devices in "make menuconfig.
> 
> Try enabling CONFIG_INPUT.
> 
> Vojtech, how about the patch below? This way CONFIG_VT isn't hidden behind 
> CONFIG_INPUT, but CONFIG_INPUT is selected if needed.
> 
> Index: drivers/char/Kconfig
> ===================================================================
> RCS file: /home/other/cvs/linux/linux-2.6/drivers/char/Kconfig,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Kconfig
> --- drivers/char/Kconfig	14 Jul 2003 09:22:00 -0000	1.1.1.1
> +++ drivers/char/Kconfig	22 Jul 2003 08:08:26 -0000
> @@ -6,7 +6,7 @@ menu "Character devices"
>  
>  config VT
>  	bool "Virtual terminal"
> -	requires INPUT=y
> +	select INPUT
>  	---help---
>  	  If you say Y here, you will get support for terminal devices with
>  	  display and keyboard devices. These are called "virtual" because you

What about the keyboard being built in. People will still not set that. 

The proper solution would be to alter the build system on a default build 
to scan the .config file for CONFIG_PC_KEYB, CONFIG_MOUSE, CONFIG_BUSMOUSE,
CONFIG_PSMOUSE etc. Then convert them to what is needed for 2.6.X. The same 
for framebuffer console stuff. We can scan for CONFIG_FB and if 
CONFIG_FRAMEBUFFER_CONSOLE is not present set it. We only would need to do 
this for a default build. 

Re: Make menuconfig broken

[Christoph Hellwig]

On Tue, Jul 22, 2003 at 05:47:04PM +0100, James Simmons wrote:
> What about the keyboard being built in. People will still not set that. 

Why not?  With this change they will get asked for keyboard support now.
Now that they actually are asked we can expect them to give the proper
answer.

> The proper solution would be to alter the build system on a default build 
> to scan the .config file for CONFIG_PC_KEYB, CONFIG_MOUSE, CONFIG_BUSMOUSE,
> CONFIG_PSMOUSE etc. Then convert them to what is needed for 2.6.X. The same 
> for framebuffer console stuff. We can scan for CONFIG_FB and if 
> CONFIG_FRAMEBUFFER_CONSOLE is not present set it. We only would need to do 
> this for a default build. 

If you really want that do it a a separate make updateconfig script instead
of bloating make oldconfig.

Re: Make menuconfig broken

[Sam Ravnborg]

On Tue, Jul 22, 2003 at 07:17:46PM +0100, Christoph Hellwig wrote:
> 
> If you really want that do it a a separate make updateconfig script instead
> of bloating make oldconfig.

updateconfig is definetely more acceptable than bloating oldconfig.
But would we end up with lots of hacks - and where do we stop.
Do we want to go the whole way back to a 2.0 .config and do an
acceptable .config using:
make updateconfig

Or is this limited to 2.4 -> 2.6?

	Sam

Re: Make menuconfig broken

[Samuel Flory]

Sam Ravnborg wrote:

>On Tue, Jul 22, 2003 at 07:17:46PM +0100, Christoph Hellwig wrote:
>  
>
>>If you really want that do it a a separate make updateconfig script instead
>>of bloating make oldconfig.
>>    
>>
>
>updateconfig is definetely more acceptable than bloating oldconfig.
>But would we end up with lots of hacks - and where do we stop.
>Do we want to go the whole way back to a 2.0 .config and do an
>acceptable .config using:
>make updateconfig
>
>Or is this limited to 2.4 -> 2.6?
>
>	Sam
>  
>

  Well there are 2 issues here:

1) How to handle "make oldconfig" on 2.4 config files.  Which may not be 
fixable in a manner that doesn't involve really ugly code.

2) That make menuconfig|xconfig on a clean 2.6 tree results in a kernel 
that doesn't have console support.   This will be something that will 
come up over and over again in the future, and does not require ugly 
hacks to fix.

-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>

Re: Make menuconfig broken

[Charles Lepple]

please drop my email from the cc line-- I'll catch up on this thread later.

thanks,

-- 
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/

Re: Make menuconfig broken

[James Simmons]

>   Well there are 2 issues here:
> 
> 1) How to handle "make oldconfig" on 2.4 config files.  Which may not be 
> fixable in a manner that doesn't involve really ugly code.
> 
> 2) That make menuconfig|xconfig on a clean 2.6 tree results in a kernel 
> that doesn't have console support.   This will be something that will 
> come up over and over again in the future, and does not require ugly 
> hacks to fix.

Instead of hacking up a oldconfig why not have the system detect old 
config files and refuse to build it and tell the user to start from 
scratch. I think this is acceptable.

Re: Make menuconfig broken

[bill davidsen]

In article <Pine.LNX.4.44.0307222129070.17797-100000@phoenix.infradead.org>,
James Simmons  <jsimmons@infradead.org> wrote:
| 
| >   Well there are 2 issues here:
| > 
| > 1) How to handle "make oldconfig" on 2.4 config files.  Which may not be 
| > fixable in a manner that doesn't involve really ugly code.
| > 
| > 2) That make menuconfig|xconfig on a clean 2.6 tree results in a kernel 
| > that doesn't have console support.   This will be something that will 
| > come up over and over again in the future, and does not require ugly 
| > hacks to fix.
| 
| Instead of hacking up a oldconfig why not have the system detect old 
| config files and refuse to build it and tell the user to start from 
| scratch. I think this is acceptable.

I would say defconfig first, then menuconfig, but whatever. If you can't
do it right, don't do it at all. The problems introduced by almost-right
conversions are often harder to find than starting from default.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Make menuconfig broken

[bill davidsen]

In article <20030722191746.A13975@infradead.org>,
Christoph Hellwig  <hch@infradead.org> wrote:
| On Tue, Jul 22, 2003 at 05:47:04PM +0100, James Simmons wrote:
| > What about the keyboard being built in. People will still not set that. 
| 
| Why not?  With this change they will get asked for keyboard support now.
| Now that they actually are asked we can expect them to give the proper
| answer.

If the user selects an Intel CPU why isn't the typical PC setup set by
default? Time to stop pretending that there are enough non-PC setups to
justify having these choices done manually each time, and make the PC
the default Intel config.

Anyone running other is going to have to do a bunch of configs anyway.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Make menuconfig broken

[Samuel Flory]

Roman Zippel wrote:

>Hi,
>
>On Mon, 21 Jul 2003, Samuel Flory wrote:
>
>  
>
>>  Try this in 2.6.0-test1:
>>rm .config
>>make mrproper
>>make menuconfig
>>
>>  There is no option for CONFIG_VT, and CONFIG_VT_CONSOLE under 
>>character devices in "make menuconfig.
>>    
>>
>
>Try enabling CONFIG_INPUT.
>
>Vojtech, how about the patch below? This way CONFIG_VT isn't hidden behind 
>CONFIG_INPUT, but CONFIG_INPUT is selected if needed.
>

  Now that's very confusing.   So in order to enable something under the 
Character devices menu you need to 1st enable something under "Input 
device support".   Which for some reason is configured as a module?  It 
says something that I resorted to editing .config by hand.


   Is it too much to ask to make the defaults give us a working 
console?  Otherwise we will be answering the question of "why does 
screen go blank after uncompressing" for the entire 2.6 cycle!!  The 
number of people who don't want to enable config_vt is fairly small, and 
they will be wanting to remove a number of our defaults any way.


-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>

Re: Make menuconfig broken

[michaelm]

On Tue, Jul 22, 2003 at 11:00:31AM -0700, Samuel Flory wrote:
>   Is it too much to ask to make the defaults give us a working 
> console?  Otherwise we will be answering the question of "why does 
> screen go blank after uncompressing" for the entire 2.6 cycle!!

I'm the 'beginner' that started the thread and I was wondering what *I*
wanted to have in place. Well, I don't think the way the scripts work
now should change, that would make an ugly newbiefication on something
that works. On the other hand as already mentioned, 'if you need
keyboard support at boot, then you just need to include keyboard support
into the kernel' which I guess is a good way into pushing the use of
some common sense. Also the problem is probably here partly because
people are used to older kernel configs which brings two thoughts.
Firstly, people who are compiling 2.5 are *supposed* to have some
experience and secondly, people using 2.6 will eventually learn how to
use the new features.

Some '*** WARNING:'s would the job without making the scripts
too newbiefied IMO. Most linux end-users don't compile kernels
in these days and the ones that do, prefer rawness.

- end of message