Is it possible to use zImage on 2.6 kernels or is bzImage required?
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Mon, 2 May 2005 21:29:51 -0400 Wakko Warner wrote:
| Is it possible to use zImage on 2.6 kernels or is bzImage required?
What processor architecture?
It's supported in arch/i386/Makefile (and some others).
For i386, you'll need to disable enough (lots of) options to make the
resulting output file small enough...
---
~Randy
Randy.Dunlap wrote:
> On Mon, 2 May 2005 21:29:51 -0400 Wakko Warner wrote:
> | Is it possible to use zImage on 2.6 kernels or is bzImage required?
>
> What processor architecture?
x86. Does zImage work on other arches? (I've only ever dealt with alpha
and sparc other than x86)
> It's supported in arch/i386/Makefile (and some others).
> For i386, you'll need to disable enough (lots of) options to make the
> resulting output file small enough...
The resultant bzImage is ~760kb. I compiled out everything I could, only
ram disk/initrd, and ext2 are compiled in.
If you'd like to see the .config, I'll send it up.
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Tue, 3 May 2005 06:45:03 -0400 Wakko Warner wrote:
| Randy.Dunlap wrote:
| > On Mon, 2 May 2005 21:29:51 -0400 Wakko Warner wrote:
| > | Is it possible to use zImage on 2.6 kernels or is bzImage required?
| >
| > What processor architecture?
|
| x86. Does zImage work on other arches? (I've only ever dealt with alpha
| and sparc other than x86)
I don't know if it works, just that it's listed in:
ppc, arm, sh, cris, arm26, m68k, ppc64, parisc, m32r, frv,
and sh64. and i386.
| > It's supported in arch/i386/Makefile (and some others).
| > For i386, you'll need to disable enough (lots of) options to make the
| > resulting output file small enough...
|
| The resultant bzImage is ~760kb. I compiled out everything I could, only
| ram disk/initrd, and ext2 are compiled in.
|
| If you'd like to see the .config, I'll send it up.
Are you saying that zImage still fails (image is too large?) ?
I built one, but I wouldn't want to boot it. :)
It looks like you would need to put almost everything into
an initrd to make it usable.
---
~Randy
On Monday 02 May 2005 09:29 pm, Wakko Warner wrote:
> Is it possible to use zImage on 2.6 kernels or is bzImage required?
Why do you need the zImage anyway? Maybe there is another way around the
problem you are having. Can you post what you are trying to do (end goal) ?
--
Richard Warner
Lead Systems Integrator
Microway, Inc
(508)732-5517
Randy.Dunlap wrote:
> On Tue, 3 May 2005 06:45:03 -0400 Wakko Warner wrote:
> | > It's supported in arch/i386/Makefile (and some others).
> | > For i386, you'll need to disable enough (lots of) options to make the
> | > resulting output file small enough...
> |
> | The resultant bzImage is ~760kb. I compiled out everything I could, only
> | ram disk/initrd, and ext2 are compiled in.
> |
> | If you'd like to see the .config, I'll send it up.
>
> Are you saying that zImage still fails (image is too large?) ?
Yes, I do recall it says "System is 724k". zImage failes. bzImage says
724k as well and succeeds.
> I built one, but I wouldn't want to boot it. :)
> It looks like you would need to put almost everything into
> an initrd to make it usable.
That was the idea in this. Once I get my stuff the way I want it, I'll
probably move on to using initramfs. My initrd is using ramdisk, my / is on
tmpfs and is populated by .tgz files on other media (The boot time is
generally short lived by design anyway)
--
Lab tests show that use of micro$oft causes cancer in lab animals
Please keep me CCd
Rick Warner wrote:
> On Monday 02 May 2005 09:29 pm, Wakko Warner wrote:
> > Is it possible to use zImage on 2.6 kernels or is bzImage required?
> Why do you need the zImage anyway? Maybe there is another way around the
> problem you are having. Can you post what you are trying to do (end goal) ?
This is a little project I'm doing to beable to load a system onto a hard
drive. The linux system is short lived by design and will run out of a
tmpfs root populated by various tgz files found either on CDs or a USB
stick.
My goal (which I realize may not be achivable nor is it important in the
long run) is to get the kernel and the initrd onto a single floppy disk
(Currently, I'm ~80kb too large for this).
I decided (remembering 2.2 days and prior when zImage was normally used) to
try zImage to see what happened. I was going to compare the size of the
resulting images. That's when I hit the problem.
I understand that upx can compress the kernel better and I also remember
hearing about utilizing bzip2 as the compressor for the kernel and initrd
images.
As far as my question, it still stands. Is bzImage required (i386/x86) for
a 2.6 kernel?
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Tue, 3 May 2005 12:33:43 -0400 Wakko Warner wrote:
| Randy.Dunlap wrote:
| > On Tue, 3 May 2005 06:45:03 -0400 Wakko Warner wrote:
| > | > It's supported in arch/i386/Makefile (and some others).
| > | > For i386, you'll need to disable enough (lots of) options to make the
| > | > resulting output file small enough...
| > |
| > | The resultant bzImage is ~760kb. I compiled out everything I could, only
| > | ram disk/initrd, and ext2 are compiled in.
| > |
| > | If you'd like to see the .config, I'll send it up.
| >
| > Are you saying that zImage still fails (image is too large?) ?
|
| Yes, I do recall it says "System is 724k". zImage failes. bzImage says
| 724k as well and succeeds.
The image size needs to be <= 0x7f000 (520192 bytes, 508 KB).
(No, I don't know why, just that this is what is being
enforced.)
Just cut more out of the kernel image...
| > I built one, but I wouldn't want to boot it. :)
| > It looks like you would need to put almost everything into
| > an initrd to make it usable.
|
| That was the idea in this. Once I get my stuff the way I want it, I'll
| probably move on to using initramfs. My initrd is using ramdisk, my / is on
| tmpfs and is populated by .tgz files on other media (The boot time is
| generally short lived by design anyway)
---
~Randy
On Tue, May 03, 2005 at 12:40:12PM -0400, Wakko Warner wrote:
> This is a little project I'm doing to beable to load a system onto a hard
> drive. The linux system is short lived by design and will run out of a
> tmpfs root populated by various tgz files found either on CDs or a USB
> stick.
>
> My goal (which I realize may not be achivable nor is it important in the
> long run) is to get the kernel and the initrd onto a single floppy disk
> (Currently, I'm ~80kb too large for this).
>
> I decided (remembering 2.2 days and prior when zImage was normally used) to
> try zImage to see what happened. I was going to compare the size of the
> resulting images. That's when I hit the problem.
>
> I understand that upx can compress the kernel better and I also remember
> hearing about utilizing bzip2 as the compressor for the kernel and initrd
> images.
>
> As far as my question, it still stands. Is bzImage required (i386/x86) for
> a 2.6 kernel?
Due to the 640k base memory limitations, you need to use bzImage for
any kernel that is over about 500k compressed. There is absolutely no
reason I can think of for not using bzImage. All the boot loaders
support it just fine, and the result is the same after loading. It
doesn't change the size of the kernel, just how large a kernel the boot
loader can load.
With the size of 2.6 kernels I consider zImage imposible to use anymore,
and it has never caused me any trouble to use bzImage. It seems that
practically bzImage is requried on x86 for 2.6 kernels. I don't know
how small you could make it if you left out everything except initrd and
cramfs support (assuming your kernel supports cramfs initrd's). Even
ext2 is rather big.
Len Sorensen
Wakko Warner <[email protected]> writes:
> x86. Does zImage work on other arches? (I've only ever dealt with alpha
> and sparc other than x86)
Sure, ARM for example. 2 MB is not a problem.
--
Krzysztof Halasa
Wakko Warner wrote:
> Please keep me CCd
>
> Rick Warner wrote:
>
>>On Monday 02 May 2005 09:29 pm, Wakko Warner wrote:
>>
>>>Is it possible to use zImage on 2.6 kernels or is bzImage required?
>>
>>Why do you need the zImage anyway? Maybe there is another way around the
>>problem you are having. Can you post what you are trying to do (end goal) ?
>
>
> This is a little project I'm doing to beable to load a system onto a hard
> drive. The linux system is short lived by design and will run out of a
> tmpfs root populated by various tgz files found either on CDs or a USB
> stick.
>
> My goal (which I realize may not be achivable nor is it important in the
> long run) is to get the kernel and the initrd onto a single floppy disk
> (Currently, I'm ~80kb too large for this).
>
> I decided (remembering 2.2 days and prior when zImage was normally used) to
> try zImage to see what happened. I was going to compare the size of the
> resulting images. That's when I hit the problem.
>
> I understand that upx can compress the kernel better and I also remember
> hearing about utilizing bzip2 as the compressor for the kernel and initrd
> images.
>
> As far as my question, it still stands. Is bzImage required (i386/x86) for
> a 2.6 kernel?
>
More or less yes. As you're finding out, it's very difficult to build a
functioning 2.6 kernel that fits the size requirements of the zImage
format. Really, the zImage format is not needed anymore. It was only
kept around because a small number of ancient BIOSes failed to load the
bzImage format with the now defunct floppy boot block. There is no size
difference in the resulting zImage or bzImage, only the load address is
different.
--
Brian Gerst
On Tuesday 03 May 2005 12:40 pm, Wakko Warner wrote:
> Please keep me CCd
>
> Rick Warner wrote:
> > On Monday 02 May 2005 09:29 pm, Wakko Warner wrote:
> > > Is it possible to use zImage on 2.6 kernels or is bzImage required?
> >
> > Why do you need the zImage anyway? Maybe there is another way around the
> > problem you are having. Can you post what you are trying to do (end
> > goal) ?
>
> This is a little project I'm doing to beable to load a system onto a hard
> drive. The linux system is short lived by design and will run out of a
> tmpfs root populated by various tgz files found either on CDs or a USB
> stick.
>
> My goal (which I realize may not be achivable nor is it important in the
> long run) is to get the kernel and the initrd onto a single floppy disk
> (Currently, I'm ~80kb too large for this).
>
> I decided (remembering 2.2 days and prior when zImage was normally used) to
> try zImage to see what happened. I was going to compare the size of the
> resulting images. That's when I hit the problem.
>
> I understand that upx can compress the kernel better and I also remember
> hearing about utilizing bzip2 as the compressor for the kernel and initrd
> images.
>
> As far as my question, it still stands. Is bzImage required (i386/x86) for
> a 2.6 kernel?
As others have mentioned, bzImage seems to be a requirement now for x86.
However, zImage will not do any better for you. I recall doing testing of
zImage vs bzImage a long time back, and the bzImage kernels were slightly
smaller than the zImage ones anyway. I think you're going to be out of luck
trying to get your kernel that small. A single floppy boot/root disk isn't
really possible with 2.6 kernels anymore. Have you looked into pxe booting
instead? I work at a cluster company and we do tons of pxe/network booting
stuff.
--
Richard Warner
Lead Systems Integrator
Microway, Inc
(508)732-5517
Randy.Dunlap wrote:
> On Tue, 3 May 2005 12:33:43 -0400 Wakko Warner wrote:
> | Yes, I do recall it says "System is 724k". zImage failes. bzImage says
> | 724k as well and succeeds.
>
> The image size needs to be <= 0x7f000 (520192 bytes, 508 KB).
>
> (No, I don't know why, just that this is what is being
> enforced.)
>
> Just cut more out of the kernel image...
Any suggestions? All that I know of that is modularizable is a module,
except for keyboard, ext2, unix sockets, ramdisk+initrd. Some of the options I need since
this is supposed to support all relevent hardware that we use where I work.
(all scsi,ide,sata,raid cards,ethernet cards that we have)
Hmm, I did find one I forgot. CONFIG_MII.
Here's my =y config:
X86=y
MMU=y
UID16=y
GENERIC_ISA_DMA=y
GENERIC_IOMAP=y
EXPERIMENTAL=y
CLEAN_COMPILE=y
BROKEN_ON_SMP=y
SYSCTL=y
HOTPLUG=y
EMBEDDED=y
TINY_SHMEM=y
MODULES=y
MODULE_UNLOAD=y
MODULE_FORCE_UNLOAD=y
OBSOLETE_MODPARM=y
KMOD=y
X86_PC=y
M586=y
X86_CMPXCHG=y
X86_XADD=y
RWSEM_XCHGADD_ALGORITHM=y
GENERIC_CALIBRATE_DELAY=y
X86_PPRO_FENCE=y
X86_F00F_BUG=y
X86_WP_WORKS_OK=y
X86_INVLPG=y
X86_BSWAP=y
X86_POPAD_OK=y
X86_ALIGNMENT_16=y
NOHIGHMEM=y
PM=y
ACPI=y
ACPI_BOOT=y
ACPI_INTERPRETER=y
ACPI_BUS=y
ACPI_EC=y
ACPI_POWER=y
ACPI_PCI=y
ACPI_SYSTEM=y
PCI=y
PCI_GOANY=y
PCI_BIOS=y
PCI_DIRECT=y
PCI_MMCONFIG=y
ISA=y
CARDBUS=y
PCMCIA_PROBE=y
BINFMT_ELF=y
STANDALONE=y
PREVENT_FIRMWARE_BUILD=y
PNP=y
ISAPNP=y
BLK_DEV_RAM=y
BLK_DEV_INITRD=y
IOSCHED_NOOP=y
IDEDISK_MULTI_MODE=y
BLK_DEV_IDEPCI=y
IDEPCI_SHARE_IRQ=y
BLK_DEV_IDEDMA_PCI=y
IDEDMA_PCI_AUTO=y
BLK_DEV_IDEDMA=y
IDEDMA_AUTO=y
SCSI_PROC_FS=y
AIC7XXX_DEBUG_ENABLE=y
AIC7XXX_REG_PRETTY_PRINT=y
AIC79XX_DEBUG_ENABLE=y
AIC79XX_REG_PRETTY_PRINT=y
MEGARAID_NEWGEN=y
SCSI_SATA=y
NET=y
INET=y
NETDEVICES=y
NET_ETHERNET=y
NET_VENDOR_3COM=y
NET_VENDOR_SMC=y
NET_TULIP=y
NET_PCI=y
8139TOO_PIO=y
NET_RADIO=y
NET_WIRELESS=y
NET_PCMCIA=y
INPUT=y
INPUT_KEYBOARD=y
KEYBOARD_ATKBD=y
SERIO=y
SERIO_I8042=y
SERIO_LIBPS2=y
SOUND_GAMEPORT=y
VT=y
VT_CONSOLE=y
HW_CONSOLE=y
VGA_CONSOLE=y
DUMMY_CONSOLE=y
USB_ARCH_HAS_HCD=y
USB_ARCH_HAS_OHCI=y
USB_DEVICEFS=y
USB_OHCI_LITTLE_ENDIAN=y
USB_STORAGE_FREECOM=y
USB_STORAGE_ISD200=y
USB_STORAGE_DPCM=y
USB_STORAGE_USBAT=y
USB_STORAGE_SDDR09=y
USB_STORAGE_SDDR55=y
USB_STORAGE_JUMPSHOT=y
USB_HIDINPUT=y
USB_ALI_M5632=y
USB_AN2720=y
USB_BELKIN=y
USB_GENESYS=y
USB_NET1080=y
USB_PL2301=y
USB_KC2190=y
USB_ARMLINUX=y
USB_EPSON2888=y
USB_ZAURUS=y
USB_CDCETHER=y
USB_AX8817X=y
EXT2_FS=y
JOLIET=y
UDF_NLS=y
NTFS_RW=y
PROC_FS=y
SYSFS=y
TMPFS=y
RAMFS=y
NFS_V3=y
LOCKD_V4=y
MSDOS_PARTITION=y
DEBUG_KERNEL=y
MAGIC_SYSRQ=y
CRYPTO=y
GENERIC_HARDIRQS=y
GENERIC_IRQ_PROBE=y
X86_BIOS_REBOOT=y
--
Lab tests show that use of micro$oft causes cancer in lab animals
Brian Gerst wrote:
> Wakko Warner wrote:
> >Please keep me CCd
> >As far as my question, it still stands. Is bzImage required (i386/x86) for
> >a 2.6 kernel?
> >
>
> More or less yes. As you're finding out, it's very difficult to build a
> functioning 2.6 kernel that fits the size requirements of the zImage
> format. Really, the zImage format is not needed anymore. It was only
> kept around because a small number of ancient BIOSes failed to load the
> bzImage format with the now defunct floppy boot block. There is no size
> difference in the resulting zImage or bzImage, only the load address is
> different.
Ok, thanks. Definately wanted to know this. The kernel will always be
loaded by some boot loader (be it grub or syslinux)
--
Lab tests show that use of micro$oft causes cancer in lab animals
Rick Warner wrote:
> On Tuesday 03 May 2005 12:40 pm, Wakko Warner wrote:
> > Please keep me CCd
> As others have mentioned, bzImage seems to be a requirement now for x86.
> However, zImage will not do any better for you. I recall doing testing of
> zImage vs bzImage a long time back, and the bzImage kernels were slightly
> smaller than the zImage ones anyway. I think you're going to be out of luck
> trying to get your kernel that small. A single floppy boot/root disk isn't
> really possible with 2.6 kernels anymore. Have you looked into pxe booting
> instead? I work at a cluster company and we do tons of pxe/network booting
> stuff.
Not all machines are PXE capable. The boot will be generally CDrom or USB
stick. I wanted to continue to support our machines that are not capable of
booting from either of these (which all of these are not PXE capable)
I might beable to pull this off, I don't know yet. If it wasn't for all the
modules I have placed in the initrd, I could. (I could remove one of the
modules and it would fit just fine but I might actually need that module)
--
Lab tests show that use of micro$oft causes cancer in lab animals
I'll be honest. zImage kernels are pointless, and are _BIGGER_ than a bzImage kernel.
You should realize that use of zImage kernels detucts 100 points off your IQ.
--- Wakko Warner <[email protected]> wrote:
> Randy.Dunlap wrote:
> > On Tue, 3 May 2005 12:33:43 -0400 Wakko Warner wrote:
> > | Yes, I do recall it says "System is 724k". zImage failes. bzImage says
> > | 724k as well and succeeds.
> >
> > The image size needs to be <= 0x7f000 (520192 bytes, 508 KB).
> >
> > (No, I don't know why, just that this is what is being
> > enforced.)
> >
> > Just cut more out of the kernel image...
>
> Any suggestions? All that I know of that is modularizable is a module,
> except for keyboard, ext2, unix sockets, ramdisk+initrd. Some of the options I need since
> this is supposed to support all relevent hardware that we use where I work.
> (all scsi,ide,sata,raid cards,ethernet cards that we have)
>
> Hmm, I did find one I forgot. CONFIG_MII.
>
> Here's my =y config:
> X86=y
> MMU=y
> UID16=y
> GENERIC_ISA_DMA=y
> GENERIC_IOMAP=y
> EXPERIMENTAL=y
> CLEAN_COMPILE=y
> BROKEN_ON_SMP=y
> SYSCTL=y
> HOTPLUG=y
> EMBEDDED=y
> TINY_SHMEM=y
> MODULES=y
> MODULE_UNLOAD=y
> MODULE_FORCE_UNLOAD=y
> OBSOLETE_MODPARM=y
> KMOD=y
> X86_PC=y
> M586=y
> X86_CMPXCHG=y
> X86_XADD=y
> RWSEM_XCHGADD_ALGORITHM=y
> GENERIC_CALIBRATE_DELAY=y
> X86_PPRO_FENCE=y
> X86_F00F_BUG=y
> X86_WP_WORKS_OK=y
> X86_INVLPG=y
> X86_BSWAP=y
> X86_POPAD_OK=y
> X86_ALIGNMENT_16=y
> NOHIGHMEM=y
> PM=y
> ACPI=y
> ACPI_BOOT=y
> ACPI_INTERPRETER=y
> ACPI_BUS=y
> ACPI_EC=y
> ACPI_POWER=y
> ACPI_PCI=y
> ACPI_SYSTEM=y
> PCI=y
> PCI_GOANY=y
> PCI_BIOS=y
> PCI_DIRECT=y
> PCI_MMCONFIG=y
> ISA=y
> CARDBUS=y
> PCMCIA_PROBE=y
> BINFMT_ELF=y
> STANDALONE=y
> PREVENT_FIRMWARE_BUILD=y
> PNP=y
> ISAPNP=y
> BLK_DEV_RAM=y
> BLK_DEV_INITRD=y
> IOSCHED_NOOP=y
> IDEDISK_MULTI_MODE=y
> BLK_DEV_IDEPCI=y
> IDEPCI_SHARE_IRQ=y
> BLK_DEV_IDEDMA_PCI=y
> IDEDMA_PCI_AUTO=y
> BLK_DEV_IDEDMA=y
> IDEDMA_AUTO=y
> SCSI_PROC_FS=y
> AIC7XXX_DEBUG_ENABLE=y
> AIC7XXX_REG_PRETTY_PRINT=y
> AIC79XX_DEBUG_ENABLE=y
> AIC79XX_REG_PRETTY_PRINT=y
> MEGARAID_NEWGEN=y
> SCSI_SATA=y
> NET=y
> INET=y
> NETDEVICES=y
> NET_ETHERNET=y
> NET_VENDOR_3COM=y
> NET_VENDOR_SMC=y
> NET_TULIP=y
> NET_PCI=y
> 8139TOO_PIO=y
> NET_RADIO=y
> NET_WIRELESS=y
> NET_PCMCIA=y
> INPUT=y
> INPUT_KEYBOARD=y
> KEYBOARD_ATKBD=y
> SERIO=y
> SERIO_I8042=y
> SERIO_LIBPS2=y
> SOUND_GAMEPORT=y
> VT=y
> VT_CONSOLE=y
> HW_CONSOLE=y
> VGA_CONSOLE=y
> DUMMY_CONSOLE=y
> USB_ARCH_HAS_HCD=y
> USB_ARCH_HAS_OHCI=y
> USB_DEVICEFS=y
> USB_OHCI_LITTLE_ENDIAN=y
> USB_STORAGE_FREECOM=y
> USB_STORAGE_ISD200=y
> USB_STORAGE_DPCM=y
> USB_STORAGE_USBAT=y
> USB_STORAGE_SDDR09=y
> USB_STORAGE_SDDR55=y
> USB_STORAGE_JUMPSHOT=y
> USB_HIDINPUT=y
> USB_ALI_M5632=y
> USB_AN2720=y
> USB_BELKIN=y
> USB_GENESYS=y
> USB_NET1080=y
> USB_PL2301=y
> USB_KC2190=y
> USB_ARMLINUX=y
> USB_EPSON2888=y
> USB_ZAURUS=y
> USB_CDCETHER=y
> USB_AX8817X=y
> EXT2_FS=y
> JOLIET=y
> UDF_NLS=y
> NTFS_RW=y
> PROC_FS=y
> SYSFS=y
> TMPFS=y
> RAMFS=y
> NFS_V3=y
> LOCKD_V4=y
> MSDOS_PARTITION=y
> DEBUG_KERNEL=y
> MAGIC_SYSRQ=y
> CRYPTO=y
> GENERIC_HARDIRQS=y
> GENERIC_IRQ_PROBE=y
> X86_BIOS_REBOOT=y
>
> --
> Lab tests show that use of micro$oft causes cancer in lab animals
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Jeez... Is it just me or is it that most people today are too fucking retarded to use a computer?
Semper fi pengunius.
Webmaster of Segin's Open Source Den.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
segin wrote:
> I'll be honest. zImage kernels are pointless, and are _BIGGER_ than a bzImage kernel.
Others have stated this.
> You should realize that use of zImage kernels detucts 100 points off your IQ.
I was trying to do comparisions between the 2. I would not have cared
as long as 1) it was smaller and 2) it worked.
Maybe they should deduct 100 off whoever is keeping zImage target still in
the make files.
> Jeez... Is it just me or is it that most people today are too fucking retarded to use a computer?
Uh, excuse me?! I ask a question and you have to do this?! Really, you are
of no help to me.
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Tue, 3 May 2005 18:19:22 -0400 Wakko Warner wrote:
| Randy.Dunlap wrote:
| > On Tue, 3 May 2005 12:33:43 -0400 Wakko Warner wrote:
| > | Yes, I do recall it says "System is 724k". zImage failes. bzImage says
| > | 724k as well and succeeds.
| >
| > The image size needs to be <= 0x7f000 (520192 bytes, 508 KB).
| >
| > (No, I don't know why, just that this is what is being
| > enforced.)
| >
| > Just cut more out of the kernel image...
|
| Any suggestions? All that I know of that is modularizable is a module,
| except for keyboard, ext2, unix sockets, ramdisk+initrd. Some of the options I need since
| this is supposed to support all relevent hardware that we use where I work.
| (all scsi,ide,sata,raid cards,ethernet cards that we have)
Are those (mostly) modular?
Is this supposed to be a kernel that is used on a regular basis,
not just a temporary quick boot thing?
You want one kernel that handles many configurations but fits
in < 510 KB? That is aggressive. :)
I think of this as being a custom kernel, but it sounds
like you want a very general-purpose (small) one.
| Hmm, I did find one I forgot. CONFIG_MII.
|
| EXPERIMENTAL=y
| CLEAN_COMPILE=y
| BROKEN_ON_SMP=y
Do you need some drivers etc. that are EXPERIMENTAL or BROKEN?
Just curious.
| ACPI=y
| ACPI_BOOT=y
| ACPI_INTERPRETER=y
| ACPI_BUS=y
| ACPI_EC=y
| ACPI_POWER=y
| ACPI_PCI=y
| ACPI_SYSTEM=y
so some systems may need ACPI ?
| ISA=y
| CARDBUS=y
| PCMCIA_PROBE=y
some systems have ISA? some are PCMCIA/CardBus?
| PNP=y
| ISAPNP=y
and ISA PNP? :(
| SCSI_PROC_FS=y
drop this one
| AIC7XXX_DEBUG_ENABLE=y
| AIC7XXX_REG_PRETTY_PRINT=y
| AIC79XX_DEBUG_ENABLE=y
| AIC79XX_REG_PRETTY_PRINT=y
drop these.
| SOUND_GAMEPORT=y
drop.
| VT=y
| VT_CONSOLE=y
| HW_CONSOLE=y
| VGA_CONSOLE=y
| DUMMY_CONSOLE=y
drop that ^^^^^
| USB_ARCH_HAS_HCD=y
| USB_ARCH_HAS_OHCI=y
| USB_DEVICEFS=y
| USB_OHCI_LITTLE_ENDIAN=y
| USB_STORAGE_FREECOM=y
| USB_STORAGE_ISD200=y
| USB_STORAGE_DPCM=y
| USB_STORAGE_USBAT=y
| USB_STORAGE_SDDR09=y
| USB_STORAGE_SDDR55=y
| USB_STORAGE_JUMPSHOT=y
| USB_HIDINPUT=y
| USB_ALI_M5632=y
| USB_AN2720=y
| USB_BELKIN=y
| USB_GENESYS=y
| USB_NET1080=y
| USB_PL2301=y
| USB_KC2190=y
| USB_ARMLINUX=y
| USB_EPSON2888=y
| USB_ZAURUS=y
| USB_CDCETHER=y
| USB_AX8817X=y
| EXT2_FS=y
| JOLIET=y
| UDF_NLS=y
| NTFS_RW=y
drop NTFS (you didn't list it as a requirement :)
| PROC_FS=y
| SYSFS=y
| TMPFS=y
| RAMFS=y
| NFS_V3=y
| LOCKD_V4=y
| MSDOS_PARTITION=y
| DEBUG_KERNEL=y
| MAGIC_SYSRQ=y
| CRYPTO=y
drop ^^^^^
so what's the problem with using a bzImage kernel?
---
~Randy
Randy.Dunlap wrote:
> On Tue, 3 May 2005 18:19:22 -0400 Wakko Warner wrote:
>
> | Randy.Dunlap wrote:
> | > On Tue, 3 May 2005 12:33:43 -0400 Wakko Warner wrote:
> | > | Yes, I do recall it says "System is 724k". zImage failes. bzImage says
> | > | 724k as well and succeeds.
> | >
> | > The image size needs to be <= 0x7f000 (520192 bytes, 508 KB).
> | >
> | > (No, I don't know why, just that this is what is being
> | > enforced.)
> | >
> | > Just cut more out of the kernel image...
> |
> | Any suggestions? All that I know of that is modularizable is a module,
> | except for keyboard, ext2, unix sockets, ramdisk+initrd. Some of the options I need since
> | this is supposed to support all relevent hardware that we use where I work.
> | (all scsi,ide,sata,raid cards,ethernet cards that we have)
>
> Are those (mostly) modular?
Yes.
> Is this supposed to be a kernel that is used on a regular basis,
> not just a temporary quick boot thing?
I'd say it would be used frequently, but short lived.
> You want one kernel that handles many configurations but fits
> in < 510 KB? That is aggressive. :)
=) hehe, if I can.
> I think of this as being a custom kernel, but it sounds
> like you want a very general-purpose (small) one.
Yes, very custom.
> | Hmm, I did find one I forgot. CONFIG_MII.
> |
> | EXPERIMENTAL=y
> | CLEAN_COMPILE=y
> | BROKEN_ON_SMP=y
>
> Do you need some drivers etc. that are EXPERIMENTAL or BROKEN?
> Just curious.
Actually, not sure, I've always enabled that.
> | ACPI=y
> | ACPI_BOOT=y
> | ACPI_INTERPRETER=y
> | ACPI_BUS=y
> | ACPI_EC=y
> | ACPI_POWER=y
> | ACPI_PCI=y
> | ACPI_SYSTEM=y
> so some systems may need ACPI ?
I wanted to beable to query battery life on laptops that I use this on. I
can remove it I think, all ACPI that can be a module is. I don't think it
works that way though. I'll have to check it on a laptop.
> | ISA=y
> | CARDBUS=y
> | PCMCIA_PROBE=y
> some systems have ISA? some are PCMCIA/CardBus?
Yes, however, pcmcia is modular.
> | PNP=y
> | ISAPNP=y
> and ISA PNP? :(
We have some old ISA cards that support PNP (3c509 comes to mind)
> | SCSI_PROC_FS=y
> drop this one
>
> | AIC7XXX_DEBUG_ENABLE=y
> | AIC7XXX_REG_PRETTY_PRINT=y
> | AIC79XX_DEBUG_ENABLE=y
> | AIC79XX_REG_PRETTY_PRINT=y
> drop these.
All SCSI is a module, these I assume are just capabilites in the modules.
> | SOUND_GAMEPORT=y
> drop.
Couldn't find a configure option to disable this. It caught my eye too. I
don't have gameport in input configured.
> | VT=y
> | VT_CONSOLE=y
> | HW_CONSOLE=y
> | VGA_CONSOLE=y
> | DUMMY_CONSOLE=y
> drop that ^^^^^
All of those or DUMMY_CONSOLE?
> | USB_ARCH_HAS_HCD=y
> | USB_ARCH_HAS_OHCI=y
> | USB_DEVICEFS=y
> | USB_OHCI_LITTLE_ENDIAN=y
> | USB_STORAGE_FREECOM=y
> | USB_STORAGE_ISD200=y
> | USB_STORAGE_DPCM=y
> | USB_STORAGE_USBAT=y
> | USB_STORAGE_SDDR09=y
> | USB_STORAGE_SDDR55=y
> | USB_STORAGE_JUMPSHOT=y
> | USB_HIDINPUT=y
> | USB_ALI_M5632=y
> | USB_AN2720=y
> | USB_BELKIN=y
> | USB_GENESYS=y
> | USB_NET1080=y
> | USB_PL2301=y
> | USB_KC2190=y
> | USB_ARMLINUX=y
> | USB_EPSON2888=y
> | USB_ZAURUS=y
> | USB_CDCETHER=y
> | USB_AX8817X=y
> | EXT2_FS=y
> | JOLIET=y
> | UDF_NLS=y
> | NTFS_RW=y
> drop NTFS (you didn't list it as a requirement :)
All USB are modules, NTFS is a module (yes I need it)
> | PROC_FS=y
> | SYSFS=y
> | TMPFS=y
> | RAMFS=y
> | NFS_V3=y
> | LOCKD_V4=y
> | MSDOS_PARTITION=y
> | DEBUG_KERNEL=y
> | MAGIC_SYSRQ=y
> | CRYPTO=y
> drop ^^^^^
Crypto is required by one of the wireless drivers (MADWIFI I believe)
> so what's the problem with using a bzImage kernel?
Nothing, I wanted to see if zImage would be smaller. As others have stated,
it's not. However, I did not know this.
I do appriate your time in helping me. I'm real close to getting this on a
single floppy (if I formatted to 1.7mb, it would be easy. I know some of
our systems that I would need this on can't use these). One goal is to use
the same kernel for all booting.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Agreed. The idiot who keeps zImage as a possible target in the makefile should be taken out and
shot, or forced to use Windows.
--- Wakko Warner <[email protected]> wrote:
> segin wrote:
> > I'll be honest. zImage kernels are pointless, and are _BIGGER_ than a bzImage kernel.
>
> Others have stated this.
>
> > You should realize that use of zImage kernels detucts 100 points off your IQ.
>
> I was trying to do comparisions between the 2. I would not have cared
> as long as 1) it was smaller and 2) it worked.
>
> Maybe they should deduct 100 off whoever is keeping zImage target still in
> the make files.
>
> > Jeez... Is it just me or is it that most people today are too fucking retarded to use a
> computer?
>
> Uh, excuse me?! I ask a question and you have to do this?! Really, you are
> of no help to me.
>
> --
> Lab tests show that use of micro$oft causes cancer in lab animals
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Jeez... Is it just me or is it that most people today are too fucking retarded to use a computer?
Semper fi pengunius.
Webmaster of Segin's Open Source Den.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
On Tue, 3 May 2005 19:05:32 -0400 Wakko Warner wrote:
| Randy.Dunlap wrote:
| > On Tue, 3 May 2005 18:19:22 -0400 Wakko Warner wrote:
| >
| > | Randy.Dunlap wrote:
| > | > On Tue, 3 May 2005 12:33:43 -0400 Wakko Warner wrote:
| > | > | Yes, I do recall it says "System is 724k". zImage failes. bzImage says
| > | > | 724k as well and succeeds.
| > | >
| > | > The image size needs to be <= 0x7f000 (520192 bytes, 508 KB).
| > | >
| > | > (No, I don't know why, just that this is what is being
| > | > enforced.)
| > | >
| > | > Just cut more out of the kernel image...
| > |
| > | Any suggestions? All that I know of that is modularizable is a module,
| > | except for keyboard, ext2, unix sockets, ramdisk+initrd. Some of the options I need since
| > | this is supposed to support all relevent hardware that we use where I work.
| > | (all scsi,ide,sata,raid cards,ethernet cards that we have)
| >
| > Are those (mostly) modular?
|
| Yes.
|
| > Is this supposed to be a kernel that is used on a regular basis,
| > not just a temporary quick boot thing?
|
| I'd say it would be used frequently, but short lived.
|
| > You want one kernel that handles many configurations but fits
| > in < 510 KB? That is aggressive. :)
|
| =) hehe, if I can.
|
| > I think of this as being a custom kernel, but it sounds
| > like you want a very general-purpose (small) one.
|
| Yes, very custom.
|
|
| > | SCSI_PROC_FS=y
| > drop this one
| >
| > | AIC7XXX_DEBUG_ENABLE=y
| > | AIC7XXX_REG_PRETTY_PRINT=y
| > | AIC79XX_DEBUG_ENABLE=y
| > | AIC79XX_REG_PRETTY_PRINT=y
| > drop these.
|
| All SCSI is a module, these I assume are just capabilites in the modules.
OK.
| > | SOUND_GAMEPORT=y
| > drop.
|
| Couldn't find a configure option to disable this. It caught my eye too. I
| don't have gameport in input configured.
OK, probably hidden.
| > | VT=y
| > | VT_CONSOLE=y
| > | HW_CONSOLE=y
| > | VGA_CONSOLE=y
| > | DUMMY_CONSOLE=y
| > drop that ^^^^^
|
| All of those or DUMMY_CONSOLE?
I meant just DUMMY_CONSOLE.
|
| > so what's the problem with using a bzImage kernel?
|
| Nothing, I wanted to see if zImage would be smaller. As others have stated,
| it's not. However, I did not know this.
|
| I do appriate your time in helping me. I'm real close to getting this on a
| single floppy (if I formatted to 1.7mb, it would be easy. I know some of
| our systems that I would need this on can't use these). One goal is to use
| the same kernel for all booting.
Good luck, have fun.
---
~Randy
On Tue, 3 May 2005, Wakko Warner wrote:
On an interesting side note, when running linux on IBM rs/6000, which is
a ppc64 machine, one must use a zImage kernel dd'ed into a small PReP
partition to boot the machine... bzImage kernels will not work.
Scott
> segin wrote:
> > I'll be honest. zImage kernels are pointless, and are _BIGGER_ than a bzImage kernel.
>
> Others have stated this.
>
> > You should realize that use of zImage kernels detucts 100 points off your IQ.
>
> I was trying to do comparisions between the 2. I would not have cared
> as long as 1) it was smaller and 2) it worked.
>
> Maybe they should deduct 100 off whoever is keeping zImage target still in
> the make files.
>
> > Jeez... Is it just me or is it that most people today are too fucking retarded to use a computer?
>
> Uh, excuse me?! I ask a question and you have to do this?! Really, you are
> of no help to me.
>
> --
> Lab tests show that use of micro$oft causes cancer in lab animals
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/
shogunx wrote:
> On Tue, 3 May 2005, Wakko Warner wrote:
>
> On an interesting side note, when running linux on IBM rs/6000, which is
> a ppc64 machine, one must use a zImage kernel dd'ed into a small PReP
> partition to boot the machine... bzImage kernels will not work.
Some time ago, I thought they decided to make zImage = bzImage. That was
going through my mind when I tried "make zImage" and was actually surprised
it didn't work.
So I guess for some arches (x86 in this case) they could either make zImage
= bzImage or just remove it. Although I'm not sure how many people actually
try it anymore =)
--
Lab tests show that use of micro$oft causes cancer in lab animals
> Is it possible to use zImage on 2.6 kernels or is bzImage required?
I appreciate everyone's help that replied to me. I have my "stage1" running
entirely off of 1 floppy with 2.6.12-rc2!
--
Lab tests show that use of micro$oft causes cancer in lab animals