kernel build - back in the soup.

[reader-2]

I'll say right from the start, that building a new kernel, has always
been a problem for me.  I don't remember ever not having a problem, in
10+ yrs..

Many people here seem to find it completely easy... not me.

So I'm back in the soup.
[I hope what I try to layout below is not overly confusing]

(After install of gentoo-sources-2.6.31-r4)

I started with `make oldconfig'
Moved from that to `make menuconfig'

Trying to mimic all the needed drivers in current running kernel.
But, On the first build and reboot, I got  `kernel panic'

So by now I've rebuilt the kernel 4 times, each time trying to get the
new one to have all the needed drivers that are present in the old
one, but still getting `kernel panic'.

I tried closely comparing the current working kernel with newly built
one. I mean side by side with `make menuconfig' running in both sources.
I cannot tell what it is I'm overlooking.

I copied the latest output painfully off the boot screen, and best I
can make of it, a driver required to let the kernel recognize the
filesystem that / is on, is not getting loaded.  I think its one of
PIIX items.

The thing is, I cannot find the culprit.  For example, examining the
PIIX items in the working kernel and inserting here:

zgrep PIIX /proc/config.gz

 CONFIG_BLK_DEV_PIIX=y
 CONFIG_ATA_PIIX=m
 CONFIG_PATA_MPIIX=y
 # CONFIG_PATA_OLDPIIX is not set
 CONFIG_I2C_PIIX4=m

Try the same thing on the newbuild:

grep  PIIX /usr/src/linux/.config

 CONFIG_BLK_DEV_PIIX=y
 CONFIG_ATA_PIIX=m
 CONFIG_PATA_MPIIX=y
 # CONFIG_PATA_OLDPIIX is not set
 CONFIG_I2C_PIIX4=m

So maybe it is not even related to PIIX....
But let me insert the kernel messages from a failed boot here:
(I've numbered the lines from the bad boot output so as not confuse
them with the good boot messages from kernel 2.6.30-r1
-------        ---------       ---=---       ---------      --------
From Kernel 2.6.31-r4
 
1  hda: ST3160021A, ATA DISK drive
2  hdb: WDC SE3000JB-00KFA0, ATA DISK drive
3  hda: UDMA/100 mode selected
4  hdb: UDMA/100 mode selected
5  hdc: LITE-ON CD-ROM LTN-5291s, ATAPI CD/DVD-ROM drive
6  hdd: WDC WD16000JB-00EVA0, ATA DISK drive
7  hdc: UDMA/33 mode selected
8  hdd: UDMA/100 mode selected
9  IDE0 at 0x1f0-0X1f7,0X3f6 on irg 14
10 IDE0 at 0x170-0X177,0X376 on irg 15
-------        ---------       ---=---       ---------      --------

NOTE: Comparing a similar section of dmesg from  working kernel
                                                 2.6.30-r1

Uniform Multi-Platform E-IDE driver
piix 0000:00:1f.1: IDE controller (0x8086:0x24db rev 0x02)
PIIX_IDE 0000:00:1f.1: enabling device (0005 -> 0007)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
PIIX_IDE 0000:00:1f.1: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) -> IRQ 10
piix 0000:00:1f.1: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xfc00-0xfc07
    ide1: BM-DMA at 0xfc08-0xfc0f

  ** The part above, I think is where a piix driver is loaded or
     something (these messages from working kernel 2.6.30-r1)

Probing IDE interface ide0...
Switched to high resolution mode on CPU 0
hda: ST3160021A, ATA DISK drive
hdb: WDC WD3000JB-00KFA0, ATA DISK drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/100 mode selected
hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hdb: UDMA/100 mode selected
Probing IDE interface ide1...
hdc: LITE-ON CD-ROM LTN-5291S, ATAPI CD/DVD-ROM drive
hdd: WDC WD1600JB-00EVA0, ATA DISK drive
hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hdc: UDMA/33 mode selected
hdd: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hdd: UDMA/100 mode selected

[...] snipped the rest of dmesg ouput from running kernel
                                      2.6.30.1

-------        ---------       ---=---       ---------      --------
   (continuation of messages from failed boot of kernel-2.6.31-r4

11 ide_generic: please use "probe_mask=0x3f" module parameters for probing all legacy IS IDE ports
12 ide-cd driver 5.00
13 ide cd:hdc: ATAPI 52X CD-ROM drive 96kB Cache
14 Uniform CD-ROM driver Revision: 3.10
15 Intel(R) PRO/1000 Network Driver version - 7.3.21-k3-NAPI
16 Copyright (c) 1999-2006 Intel Corporation
17 e1000e: Intel(R) Pro/1000 Network Driver, 1.0.2-k2
18: e1000e: Copyright(c) 1999-2008 Intel Corporation
19: e100: Intel (R) PRO/100 Network Driver 3.5.24-k-NAPI
20: e100: Copyright blah blah
21: sky2 driver version 1.23
22: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
23: r8169 0000:02:03:0: PCI INT A -> GSI 19 (level,low) -> IRQ 19
24: r8169 0000:02:03:0: no PCI Experss capability
25: eth0  RTL8110s at 0xf8026f00, 00:40:f4:b5:29:41, XID 04000000 IRQ 20
26: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
27: r8169 0000:02:06:0: PCI INT A -> GSI 20 (level,low) -> IRQ 20
28: r8169 0000:02:06:0: no PCI Experss capability
29: eth1  RTL8110s at 0xf802ae00, 00:11:09:ee:6c:04, XID 04000000 IRQ 20
30: PnP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 IRQ 1
31: PnP: PS/2 appears to have AUX port disabled, if this bla bla
32: serio: i8042 KBD port at 0x60,0x64 IRQ 1
33: mice: PS/2 mouse device common for all mice
34: cupidle: using governors ladder
35: cpuidle: using governor menu
36: TCP cubic registered
37: NET: Registered protocol family 17
38: RPC: Registered udp transport module
39: RPC: Registered udp transport module
40: Using IPI No-Shortcut mode
41: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
42: ROOT-NFS: No NFS server available, giving up.
43: VFS: Unable to mount root fs via NFS, trying floppy
44: VFS: Cannot open root device "hda5" or unknown-block(2.0)
45: Please append a correct "root=" boot option - here are the available partitions:
46: 1600       419302 hdc driver: ide-cdrom
47: kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2.0)
48: Pid: 1: comm: swappers Not tainted 2.6.31-gentoo-r4_rdr-2 #3
49: Call Trace:
50: [<c130cd18>] ? printk+0xf/0x17
51: [<c130cc6e>] panic+0x39/0xd4
 [There were several more lines here]

[Volker Armin Hemmann]

your drivers for the ide disks have to be built INTO THE KERNEL! NOT MODULES.

Also, you need to compile in the filesystem, not as module.

091103 Harry Putnam wrote:
> building a new kernel has always been a problem for me.
> Many people here seem to find it completely easy... not me.

I find it doable with a bit of care (smile).

> After install of gentoo-sources-2.6.31-r4
> I started with `make oldconfig'
> Moved from that to `make menuconfig'

I just installed the same kernel with no problems.
I did 'make oldconfig', looking at the '?' help for each new item
& deciding whether to say Y/N as seemed appropriate.
There wasn't anything dramatically new,
so I went straight on to 'gvimdiff .config .config-<previous_kernel>',
which allows a careful review of all the differences.
There seemed to be nothing outstanding, so I went ahead with 'make',
copied it by hand into  /boot  & updated Lilo;
there was a problem, which I reported here, re Nvidia-drivers,
but I moved up to a new version & then everything worked as expected.
I never compile kernel items as modules if it cb avoided:
it's one source of potential pain one can avoid.

--
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

[walter s]

On 11/03/2009 02:29 PM, Harry Putnam wrote:

> I'll say right from the start, that building a new kernel, has always
> been a problem for me.  I don't remember ever not having a problem, in
> 10+ yrs..
>
> Many people here seem to find it completely easy... not me.
>
> So I'm back in the soup.
> [I hope what I try to layout below is not overly confusing]
>
> (After install of gentoo-sources-2.6.31-r4)
>
> I started with `make oldconfig'
> Moved from that to `make menuconfig'...

There's no reason to use menuconfig after running oldconfig,  If your
old kernel was using all of the hardware, then the new kernel should,
too, just with oldconfig.

Volker makes an excellent point.  Support for your disk controller and
for your file system(s) must be built into the kernel unless you use
initrd to load those modules *before* the kernel tries to mount /.

That's a pain and isn't necessary for most machines because you know
in advance what hardware you have and which file systems you use.
(But your kernel doesn't know in advance unless the right drivers are
compiled in ;o)

[reader-2]

Volker Armin Hemmann <volkerarmin@...> writes:

> your drivers for the ide disks have to be built INTO THE KERNEL! NOT MODULES.

Is that really a hard rule? I've done it both ways successfully in the
past.

And in fact, I didn't record my first builds on this kernel but I'm
pretty sure my first build did have all PIIX stuff built in.

Not to be argumentative but did you notice that both old and new
kernel have exactly the same module and built-ins concerning PIIX
Yet one recognizes /dev/hda5 and runs and the other doesn't

zgrep PIIX /proc/config.gz (this is 2.6.30-r1)

 CONFIG_BLK_DEV_PIIX=y
 CONFIG_ATA_PIIX=m
 CONFIG_PATA_MPIIX=y
 # CONFIG_PATA_OLDPIIX is not set
 CONFIG_I2C_PIIX4=m

Try the same thing on the newbuild:

grep  PIIX /usr/src/linux/.config 2.6.31-r4

 CONFIG_BLK_DEV_PIIX=y
 CONFIG_ATA_PIIX=m
 CONFIG_PATA_MPIIX=y
 # CONFIG_PATA_OLDPIIX is not set
 CONFIG_I2C_PIIX4=m

> Also, you need to compile in the filesystem, not as module.

Again, I've done it both ways successfully in the past.
Why do we have module choices for these things?

-------        ---------       ---=---       ---------      --------
So is that all you see in the failed boot messages that gives any clue
to why it fails.

I'm building them in on this build... I hope it works

But am I missing some critical driver?

[reader-2]

walt <w41ter@...> writes:

> There's no reason to use menuconfig after running oldconfig,  If your
> old kernel was using all of the hardware, then the new kernel should,
> too, just with oldconfig.

I don't know about that.  I found a whole lot of stuff different when
I ran menuconfig and checked the old and new settings.

I just made a partial list by comparing the oldkernel settings in
menuconfig and the new kernel after running make oldconfig.  And this
is only SOME of them, got tired of it part way thru:

Some of these really seem like they should have ended up marked the
same after oldconfig

-------        ---------       ---=---       ---------      --------
Automatically append version string on in old off in new
BSD accounting off in old On in new
Export Task process thru netlink off in old, on in new
Auditing support off in old, on in new
Namespc support all off in old all on in new.
Network support/wireless off in old, on in new
Amatuer radio support off in old, on in new
RFswitch subsys support off in old On in new
Networking/ multicasting off in old on in new
Advanced router off in old On in new
BOOTTP off in old on in new
RARP off in old on in new
TCP advanced congestion control off in old, on in new.
ipv6 off in old, on in new

  I gave up after that... so if you think oldconfig means you get the
  same settings by and large... it doesn't.

[hamilton-4]

On Tue, 03 Nov 2009 17:02:18 -0800, walt <w41ter@...> wrote:

> On 11/03/2009 02:29 PM, Harry Putnam wrote:
>> I'll say right from the start, that building a new kernel, has always
>> been a problem for me.  I don't remember ever not having a problem, in
>> 10+ yrs..
>>
>> Many people here seem to find it completely easy... not me.
>>
>> So I'm back in the soup.
>> [I hope what I try to layout below is not overly confusing]
>>
>> (After install of gentoo-sources-2.6.31-r4)

Just checking - but you didn't mention: did you copy the .config to the
new kernel src directory?  If not, that would certainly explain the
disparity in configuration settings you're seeing.  

>>
>> I started with `make oldconfig'
>> Moved from that to `make menuconfig'...


--
Jon Hamilton
hamilton@...

[reader-2]

hamilton <hamilton@...> writes:

> On Tue, 03 Nov 2009 17:02:18 -0800, walt <w41ter@...> wrote:
>> On 11/03/2009 02:29 PM, Harry Putnam wrote:
>>> I'll say right from the start, that building a new kernel, has always
>>> been a problem for me.  I don't remember ever not having a problem, in
>>> 10+ yrs..
>>>
>>> Many people here seem to find it completely easy... not me.
>>>
>>> So I'm back in the soup.
>>> [I hope what I try to layout below is not overly confusing]
>>>
>>> (After install of gentoo-sources-2.6.31-r4)
>
> Just checking - but you didn't mention: did you copy the .config to the
> new kernel src directory?  If not, that would certainly explain the
> disparity in configuration settings you're seeing.  
>

I think you can say make `oldconfig' and the `old config' is supposed to
be incorporated so no I didn't

If I had put .confg into the new sources, then plain make menuconfig
is what I would have used.

Do you know where the man pages or docs for that stuff is .. its not in
`man make'

I'd like to check some of that.

[John H. Moe-2]

Harry Putnam wrote:

> I'll say right from the start, that building a new kernel, has always
> been a problem for me.  I don't remember ever not having a problem, in
> 10+ yrs..
>
> Many people here seem to find it completely easy... not me.
>
> So I'm back in the soup.
> [I hope what I try to layout below is not overly confusing]
>
> (After install of gentoo-sources-2.6.31-r4)
>
> I started with `make oldconfig'
> Moved from that to `make menuconfig'
>
> Trying to mimic all the needed drivers in current running kernel.
> But, On the first build and reboot, I got  `kernel panic'
>
> So by now I've rebuilt the kernel 4 times, each time trying to get the
> new one to have all the needed drivers that are present in the old
> one, but still getting `kernel panic'.
>
> I tried closely comparing the current working kernel with newly built
> one. I mean side by side with `make menuconfig' running in both sources.
> I cannot tell what it is I'm overlooking.
>
> I copied the latest output painfully off the boot screen, and best I
> can make of it, a driver required to let the kernel recognize the
> filesystem that / is on, is not getting loaded.  I think its one of
> PIIX items.
>
> The thing is, I cannot find the culprit.  For example, examining the
> PIIX items in the working kernel and inserting here:
>
> zgrep PIIX /proc/config.gz
>
>  CONFIG_BLK_DEV_PIIX=y
>  CONFIG_ATA_PIIX=m
>  CONFIG_PATA_MPIIX=y
>  # CONFIG_PATA_OLDPIIX is not set
>  CONFIG_I2C_PIIX4=m
>
> Try the same thing on the newbuild:
>
> grep  PIIX /usr/src/linux/.config
>
>  CONFIG_BLK_DEV_PIIX=y
>  CONFIG_ATA_PIIX=m
>  CONFIG_PATA_MPIIX=y
>  # CONFIG_PATA_OLDPIIX is not set
>  CONFIG_I2C_PIIX4=m
>
> So maybe it is not even related to PIIX....
> But let me insert the kernel messages from a failed boot here:
> (I've numbered the lines from the bad boot output so as not confuse
> them with the good boot messages from kernel 2.6.30-r1
> -------        ---------       ---=---       ---------      --------
> From Kernel 2.6.31-r4
>  
> 1  hda: ST3160021A, ATA DISK drive
> 2  hdb: WDC SE3000JB-00KFA0, ATA DISK drive
> 3  hda: UDMA/100 mode selected
> 4  hdb: UDMA/100 mode selected
> 5  hdc: LITE-ON CD-ROM LTN-5291s, ATAPI CD/DVD-ROM drive
> 6  hdd: WDC WD16000JB-00EVA0, ATA DISK drive
> 7  hdc: UDMA/33 mode selected
> 8  hdd: UDMA/100 mode selected
> 9  IDE0 at 0x1f0-0X1f7,0X3f6 on irg 14
> 10 IDE0 at 0x170-0X177,0X376 on irg 15
> -------        ---------       ---=---       ---------      --------
>
> NOTE: Comparing a similar section of dmesg from  working kernel
>                                                  2.6.30-r1
>
> Uniform Multi-Platform E-IDE driver
> piix 0000:00:1f.1: IDE controller (0x8086:0x24db rev 0x02)
> PIIX_IDE 0000:00:1f.1: enabling device (0005 -> 0007)
> ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
> PCI: setting IRQ 10 as level-triggered
> PIIX_IDE 0000:00:1f.1: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) -> IRQ 10
> piix 0000:00:1f.1: not 100% native mode: will probe irqs later
>     ide0: BM-DMA at 0xfc00-0xfc07
>     ide1: BM-DMA at 0xfc08-0xfc0f
>
>   ** The part above, I think is where a piix driver is loaded or
>      something (these messages from working kernel 2.6.30-r1)
>
> Probing IDE interface ide0...
> Switched to high resolution mode on CPU 0
> hda: ST3160021A, ATA DISK drive
> hdb: WDC WD3000JB-00KFA0, ATA DISK drive
> hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> hda: UDMA/100 mode selected
> hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> hdb: UDMA/100 mode selected
> Probing IDE interface ide1...
> hdc: LITE-ON CD-ROM LTN-5291S, ATAPI CD/DVD-ROM drive
> hdd: WDC WD1600JB-00EVA0, ATA DISK drive
> hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> hdc: UDMA/33 mode selected
> hdd: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> hdd: UDMA/100 mode selected
>
> [...] snipped the rest of dmesg ouput from running kernel
>                                       2.6.30.1
>
> -------        ---------       ---=---       ---------      --------
>    (continuation of messages from failed boot of kernel-2.6.31-r4
>
> 11 ide_generic: please use "probe_mask=0x3f" module parameters for probing all legacy IS IDE ports
> 12 ide-cd driver 5.00
> 13 ide cd:hdc: ATAPI 52X CD-ROM drive 96kB Cache
> 14 Uniform CD-ROM driver Revision: 3.10
> 15 Intel(R) PRO/1000 Network Driver version - 7.3.21-k3-NAPI
> 16 Copyright (c) 1999-2006 Intel Corporation
> 17 e1000e: Intel(R) Pro/1000 Network Driver, 1.0.2-k2
> 18: e1000e: Copyright(c) 1999-2008 Intel Corporation
> 19: e100: Intel (R) PRO/100 Network Driver 3.5.24-k-NAPI
> 20: e100: Copyright blah blah
> 21: sky2 driver version 1.23
> 22: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> 23: r8169 0000:02:03:0: PCI INT A -> GSI 19 (level,low) -> IRQ 19
> 24: r8169 0000:02:03:0: no PCI Experss capability
> 25: eth0  RTL8110s at 0xf8026f00, 00:40:f4:b5:29:41, XID 04000000 IRQ 20
> 26: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> 27: r8169 0000:02:06:0: PCI INT A -> GSI 20 (level,low) -> IRQ 20
> 28: r8169 0000:02:06:0: no PCI Experss capability
> 29: eth1  RTL8110s at 0xf802ae00, 00:11:09:ee:6c:04, XID 04000000 IRQ 20
> 30: PnP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 IRQ 1
> 31: PnP: PS/2 appears to have AUX port disabled, if this bla bla
> 32: serio: i8042 KBD port at 0x60,0x64 IRQ 1
> 33: mice: PS/2 mouse device common for all mice
> 34: cupidle: using governors ladder
> 35: cpuidle: using governor menu
> 36: TCP cubic registered
> 37: NET: Registered protocol family 17
> 38: RPC: Registered udp transport module
> 39: RPC: Registered udp transport module
> 40: Using IPI No-Shortcut mode
> 41: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
> 42: ROOT-NFS: No NFS server available, giving up.
> 43: VFS: Unable to mount root fs via NFS, trying floppy
> 44: VFS: Cannot open root device "hda5" or unknown-block(2.0)
> 45: Please append a correct "root=" boot option - here are the available partitions:
> 46: 1600       419302 hdc driver: ide-cdrom
> 47: kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2.0)
> 48: Pid: 1: comm: swappers Not tainted 2.6.31-gentoo-r4_rdr-2 #3
> 49: Call Trace:
> 50: [<c130cd18>] ? printk+0xf/0x17
> 51: [<c130cc6e>] panic+0x39/0xd4
>  [There were several more lines here]
>
>
>
>  

I stopped using that option in my systems, as there is now a AHCI SATA
option to use instead. It appears CONFIG_ATA_SFF (which CONFIG_ATA_PIIX
requires) is deprecated. From the help on it:

------
SFF is the legacy IDE interface that has been around since the dawn of
time. Almost all PATA controllers have an SFF interface. Many SATA
controllers have an SFF interface when configured into a legacy
compatibility mode.

For users with exclusively modern controllers like AHCI, Silicon Image
3124, or Marvell 6440, you may choose to disable this unneeded SFF support.
------

So I disabled ATA_SFF and used SATA_AHCI instead. You can enable (or
disable) AHCI from most BIOS'es; sometimes it's nice and simple with
something like: ATA Mode: AHCI or IDE Emulation. Others just ask if you
want ATA Native mode, which seems to be AHCI.

HTH

John Moe

[Dale-46]

Harry Putnam wrote:

> hamilton <hamilton@...> writes:
>
>  
>> On Tue, 03 Nov 2009 17:02:18 -0800, walt <w41ter@...> wrote:
>>    
>>> On 11/03/2009 02:29 PM, Harry Putnam wrote:
>>>      
>>>> I'll say right from the start, that building a new kernel, has always
>>>> been a problem for me.  I don't remember ever not having a problem, in
>>>> 10+ yrs..
>>>>
>>>> Many people here seem to find it completely easy... not me.
>>>>
>>>> So I'm back in the soup.
>>>> [I hope what I try to layout below is not overly confusing]
>>>>
>>>> (After install of gentoo-sources-2.6.31-r4)
>>>>        
>> Just checking - but you didn't mention: did you copy the .config to the
>> new kernel src directory?  If not, that would certainly explain the
>> disparity in configuration settings you're seeing.  
>>
>>    
>
> I think you can say make `oldconfig' and the `old config' is supposed to
> be incorporated so no I didn't
>
> If I had put .confg into the new sources, then plain make menuconfig
> is what I would have used.
>
> Do you know where the man pages or docs for that stuff is .. its not in
> `man make'
>
> I'd like to check some of that.
>
>
>
>  

I always do this:  cp /path/to/old/kernel/.config
/path/to/new/kernel/.config .  Then run make oldconfig and configure all
the new stuff.  I usually answer no to everything but there is
exceptions.  After that, make all && make modules_install and either run
make install or copy it the old fashioned way.  Then edit grub if needed
and reboot.

Do all that in /usr/src/linux especially the make parts.

It has worked for me for quite a while.  I do have a hiccup every once
in a while but usually something else is wrong.

Dale

:-)  :-)

Harry Putnam <reader@...> writes:

> I think you can say make `oldconfig' and the `old config' is supposed to
> be incorporated so no I didn't
>
> If I had put .confg into the new sources, then plain make menuconfig
> is what I would have used.

That is the wrong way round! make oldconfig uses the .config in the
kernel directory, which in the case of an upgrade is the *default* (ie
without any customisations) config. make oldconfig does *not* operate on
the running kernel. You have to copy the .config from the running (old)
kernel to the new kernel directory before running make oldconfig. If you
start with the default config, then you have to run make menuconfig (or
config or xconfig) to customise it every time.

[Alan McKinnon-2]

On Wednesday 04 November 2009 03:46:54 Harry Putnam wrote:
> Volker Armin Hemmann <volkerarmin@...> writes:
> > your drivers for the ide disks have to be built INTO THE KERNEL! NOT
> > MODULES.
>
> Is that really a hard rule? I've done it both ways successfully in the
> past.
>

If you do not use an initrd|initramfs, then the drivers for the chipset and
the filesystem on /  do need to be built into the kernel. The drivers are on
the disk and the kernel needs to read the drivers from the disk to read the
disk to get the drivers :-)  chicken and egg.

If you use an initrd/initramfs or have genkernel make one for you, then the
drivers are on that ramdisk and the kernel can see and load them so all is
well.



--
alan dot mckinnon at gmail dot com

[James-323]

Graham Murray <graham <at> gmurray.org.uk> writes:

 You have to copy the .config from the running (old)
> kernel to the new kernel directory before running make oldconfig. If you
> start with the default config, then you have to run make menuconfig (or
> config or xconfig) to customise it every time.


Hmmmmm,


I thought when you install a new kernel, you just change the symbolic link.

example (old kernel linux-2.6.30-gentoo-r4)
New kernel (linux-2.6.30-gentoo-r5)


cd /usr/src
rm linux
ls -sf /usr/src/linux-2.6.30-gentoo-r5 linux
cd linux
make menuconfig


At this point the new kernel sources (linux-2.6.30-gentoo-r5)
automatically copies over the .config from the version
of the kernel you are actually running. If no changes
are required, save and build and setup new kennel. If something
changes then the .config is modified by 'make menuconfig'.

So minor kernel version revisions are trivial, but major
kernel revision updated (like 2.6.30.x to 2.6.31.x) require
your perusal of the menuconfig choices.....(caveat emptor).

Did I miss something? Dirt simple.

Here are my steps:

from /usr/src/linux:
make && make modules_install

then
cp System.map /boot/System.map-2.6.30-gentoo-r5
cp arch/x86_64/boot/bzImage /boot/kernel-2.6.30-gentoo-r5
cp .config /boot/config-2.6.30-gentoo-r5


Edit grub. Keep at least 2 copies of know working kernels
around, in case you have to revert or look at something old

Or did I miss something. That 'oldconfig' stuffage is
not required any more.

Or did I miss something?

Last, if you are talking about hardware that is fixed
(mobo, Hard drive (file systems), video cards(video drivers)
etc etc, I always hard compile that into the kernel. I'd add to
that mouse and keyboard, cause headaches can occur if
those are loadable (others will disagree). But if you swap out
usb keyboards quite often, either compile all choices into the
kernel or use loadable modules.


Stuff like external HD, usb or things that routinely get
plugged and unplugged to/from the system, should definitely
be loadable modules. imho.


hth,
James

[reader-2]

"John H. Moe" <johnmoe@...> writes:

> I stopped using that option in my systems, as there is now a AHCI SATA
> option to use instead. It appears CONFIG_ATA_SFF (which CONFIG_ATA_PIIX
> requires) is deprecated. From the help on it:

Do you notice some kind of difference from switching?

[Kutulu]

On 11/3/2009 11:10 PM, Harry Putnam wrote:
> hamilton<hamilton@...>  writes:

>> Just checking - but you didn't mention: did you copy the .config to the
>> new kernel src directory?  If not, that would certainly explain the
>> disparity in configuration settings you're seeing.
>>
>
> I think you can say make `oldconfig' and the `old config' is supposed to
> be incorporated so no I didn't
>
> If I had put .confg into the new sources, then plain make menuconfig
> is what I would have used.
>
> Do you know where the man pages or docs for that stuff is .. its not in
> `man make'

The 'make' man page wouldn't know anything about the kernel's makefile.
  You want the README file that's included in the top of the kernel
source folder.  That file says, among other things:

"make oldconfig"   Default all questions based on the contents of
                    your existing ./.config file and asking about
                    new config symbols.

You need to already have a .config file in the source tree in order for
'make oldconfig' to work; otherwise you are going to get the default
answers to just about every question.  The benefit of this is that you
don't have to search through the entire menu tree in the UI to find
what's new.

When you're ready to build a new kernel version, you should copy the
.config file from your current kernel into the new source tree.  For
example, if you use 'make install' it will copy .config to
/boot/config-<kernel version>; from there you can copy it back to
/usr/src/linux/.config for the next version.

When you run 'oldconfig' you should rarely get more than a few dozen
questions, and it should all be on truly new items that didn't exist in
your previous kernel.  The hardware drivers you selected should all
carry over as-is.

--Mike

[walter s]

On 11/04/2009 06:16 AM, james wrote:

> Graham Murray <graham <at> gmurray.org.uk> writes:
>
>  You have to copy the .config from the running (old)
>> kernel to the new kernel directory before running make oldconfig. If you
>> start with the default config, then you have to run make menuconfig (or
>> config or xconfig) to customise it every time.
>
>
> Hmmmmm,
>
>
> I thought when you install a new kernel, you just change the symbolic link.
>
> example (old kernel linux-2.6.30-gentoo-r4)
> New kernel (linux-2.6.30-gentoo-r5)
>
>
> cd /usr/src
> rm linux
> ls -sf /usr/src/linux-2.6.30-gentoo-r5 linux
> cd linux
> make menuconfig

Well, if you really want to use menuconfig first, you need to repeat the
entire configuration process from the beginning.  Make oldconfig is there
exactly so you *don't* need to repeat everything manually.

> At this point the new kernel sources (linux-2.6.30-gentoo-r5)
> automatically copies over the .config from the version
> of the kernel you are actually running...

That sentence doesn't make sense.  You said the sources automatically copy
the .config -- but the sources don't do anything.  Only a program could do
something automatically, not source code files. It may be that genkernel
does something like that, but I've never used it so I don't know.

If you are building your kernel manually (as you seem to be doing) then *you*
need to copy the .config from the old sources over to your new kernel source
directory and *then* do make oldconfig. That's when the magic happens, not
before.

You'll see lots of interesting stuff if you run 'make help' in the kernel
source directory.

[reader-2]

Mike Edenfield <kutulu@...> writes:

> The 'make' man page wouldn't know anything about the kernel's
> makefile. You want the README file that's included in the top of the
> kernel source folder.  That file says, among other things:
>
> "make oldconfig"   Default all questions based on the contents of
>                    your existing ./.config file and asking about
>                    new config symbols.
>
> You need to already have a .config file in the source tree in order
> for 'make oldconfig' to work; otherwise you are going to get the
> default answers to just about every question.  The benefit of this is
> that you don't have to search through the entire menu tree in the UI
> to find what's new.

Thanks for clearing that stuff up, and the pointer to documentation.

[Grant Edwards-6]

On 2009-11-04, Harry Putnam <reader@...> wrote:

>> Just checking - but you didn't mention: did you copy the
>> .config to the new kernel src directory?  If not, that would
>> certainly explain the disparity in configuration settings
>> you're seeing.  
>
> I think you can say make `oldconfig' and the `old config' is
> supposed to be incorporated

No, it isn't.

> so no I didn't

That's the problem.

> If I had put .config into the new sources, then plain make
> menuconfig is what I would have used.

No, that's when you use make oldconfig: when you've placed a
.config file from an old kernel into the build directory.
Doing a "make oldconfig" will used the existing .config file as
much as possible and ask you questions about new choices.

> Do you know where the man pages or docs for that stuff is ..
> its not in `man make'

Have you tried looking in the 'Documentation' directory in the
linux source tree?

> I'd like to check some of that.

Good idea.

--
Grant Edwards                   grante             Yow! ... I'm IMAGINING a
                                  at               sensuous GIRAFFE, CAVORTING
                               visi.com            in the BACK ROOM of a
                                                   KOSHER DELI --

[Dirk Heinrichs-2]

Am Dienstag 03 November 2009 23:29:59 schrieb Harry Putnam:

> The thing is, I cannot find the culprit.  For example, examining the
> PIIX items in the working kernel and inserting here:

Still the (IMHO) best way is to boot a LiveCD, run "lspci -vv" (two times "v")
and write down which hardware is detected and which driver is used for it.
From that you can directly determine what you need to compile into your
kernel. Everything else is guesswork.

Hint: menuconfig has a search function ("/"). You can directly search for the
driver name you got from lspci and enable the corresponding option.

If you're unsure as to what should be compiled into the kernel and what can be
a module, always say "Y". You can try "M" in later iterations. As a rule of
thumb: everything you need to access your root fs should get a "Y". That is
Chipset->(S)ATA harddisk->Filesystem.

If it still won't work, you can also post your kernel config and the output of
lspci -vv here and somebody will find out what's wrong/missing.

HTH...

        Dirk

[Dirk Heinrichs-2]

Am Mittwoch 04 November 2009 02:46:54 schrieb Harry Putnam:

> But am I missing some critical driver?

Harddisk (CONFIG_BLK_DEV_SD=y), maybe? That's one reason for "unknown block
device".

Bye...

        Dirk