ipcop-devel Mailing List for IPCop Firewall

Eric Shubert wrote:
> Davide wrote:
>> Hi!
>> I'm trying to install vm-tools in Ipcop 1.4.21 distribution following 
>> these instructions:
>> http://www.ipcop.org/index.php?module=pnWikka&tag=HowToCompileAdditionalCode 
>> <http://www.ipcop.org/index.php?module=pnWikka&tag=HowToCompileAdditionalCode>
>>
>> I've downloaded the sources package of ipcop and compile it with success.
>> So,
>> I've added the source package of open-vm-tools 
>> (http://open-vm-tools.sourceforge.net/) at directory "cache".
>> I've write the script for open-vm-tools in "lsf" directory, like this:
>>
>> $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects))
>>     @$(PREBUILD)
>>     @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar zxf $(DIR_DL)/$(DL_FILE)
>>     cd $(DIR_APP) && ./configure --without-x --without-procps 
>> --without-dnet --without-icu
>>     cd $(DIR_APP) && make
>>     cd $(DIR_APP) && make install
>>     @rm -rf $(DIR_APP)
>>     @$(POSTBUILD)
>>
>> But, i have this trouble with the make command:
>>
>> make[3]: Entering directory 
>> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
>> make[4]: Entering directory 
>> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
>> Dependencies for .././linux/af_vsock.c
>> Dependencies for .././linux/vsockAddr.c
>> Dependencies for .././linux/util.c
>> Dependencies for .././linux/driverLog.c
>> make[4]: Leaving directory 
>> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
>> make[4]: Entering directory 
>> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
>> Compiling .././linux/af_vsock.c
>> ../linux/af_vsock.c: In function `VSockVmciStreamConnect':
>> ../linux/af_vsock.c:3199: warning: implicit declaration of function 
>> `DEFINE_WAIT'
>> ../linux/af_vsock.c:3199: error: `wait' undeclared (first use in this 
>> function)
>> ../linux/af_vsock.c:3199: error: (Each undeclared identifier is reported 
>> only once
>> ../linux/af_vsock.c:3199: error: for each function it appears in.)
>> ../linux/af_vsock.c:3275: warning: implicit declaration of function 
>> `prepare_to_wait'
>> ../linux/af_vsock.c:3310: warning: implicit declaration of function 
>> `finish_wait'
>> ../linux/af_vsock.c: In function `VSockVmciAccept':
>> ../linux/af_vsock.c:3348: error: `wait' undeclared (first use in this 
>> function)
>> ../linux/af_vsock.c: In function `VSockVmciStreamSendmsg':
>> ../linux/af_vsock.c:4079: error: `wait' undeclared (first use in this 
>> function)
>> ../linux/af_vsock.c: In function `VSockVmciStreamRecvmsg':
>> ../linux/af_vsock.c:4428: error: `wait' undeclared (first use in this 
>> function)
>> make[4]: *** [af_vsock.o] Error 1
>> make[4]: Leaving directory 
>> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
>> make[3]: *** [driver] Error 2
>> make[3]: Leaving directory 
>> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
>> make[2]: *** [vsock] Error 2
>> make[2]: Leaving directory `/usr/src/vm-tools-2008.09.03-114782/modules'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/usr/src/vm-tools-2008.09.03-114782'
>> make: *** [/usr/src/log/vm-tools-2008.09.03-114782] Error 2
>>
>> Someone have any idea?
>> (I run compile with some parameters that exclude some (optional ?) librarys)
>>
>> Sorry for my english :-\
>>
>> Best regards.
>> Davide
>>
>>
> 
> Ok, I've figured this one out. According to some comments in 
> compat_wait.h, DEFINE_WAIT() and friends were backported to kernel 
> 2.4.28, so they weren't being included. The IPCop kernel 2.4.36 doesn't 
> have this backport (why I don't know). I modified compat_wait.h to 
> include the DEFINE_WAIT() code with the kernel versions < 2.4.48, and 
> now vsock compiles clean.
> 
> Now for trying turn on a few more features, then installing and testing 
> this thing. Stay tuned.
> 

I've been in touch with Dmitry on the open-vm-tools development list, 
and he has everything fixed up for the next monthly release. I'm going 
to continue working on getting it installed in IPCop and will report back.

In case anyone's interested in trying things out before the next monthly 
release of open-vm-tools, the following patch provided by Dmitry will 
fix the vsock compile error. It should be applied to all instances of 
compat_wait.h in the source tree.

--- compat_wait.h.orig
+++ compat_wait.h
@@ -179,10 +179,16 @@ do {									\

  /*
   * DEFINE_WAIT() and friends were added in 2.5.39 and backported to 
2.4.28.
+ *
+ * Unfortunately it is not true. While some distros may have done it the
+ * change has never made it into vanilla 2.4 kernel. Instead of testing
+ * particular kernel versions let's just test for presence of DEFINE_WAIT
+ * when figuring out whether we need to provide replacement implementation
+ * or simply alias existing one.
   */
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 28) || \
-   (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 5, 0) && \
-    LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 39))
+
+#ifndef DEFINE_WAIT
+
  # define COMPAT_DEFINE_WAIT(_wait)                              \
     DECLARE_WAITQUEUE(_wait, current)
  # define compat_init_prepare_to_wait(_sleep, _wait, _state)     \
@@ -197,7 +203,9 @@ do {									\
        __set_current_state(_state);                              \
        remove_wait_queue(_sleep, _wait);                         \
     } while (0)
+
  #else
+
  # define COMPAT_DEFINE_WAIT(_wait)                              \
     DEFINE_WAIT(_wait)
  # define compat_init_prepare_to_wait(_sleep, _wait, _state)     \
@@ -206,6 +214,7 @@ do {									\
     prepare_to_wait(_sleep, _wait, _state)
  # define compat_finish_wait(_sleep, _wait, _state)              \
     finish_wait(_sleep, _wait)
-#endif
+
+#endif /* #ifndef DEFINE_WAIT */

  #endif /* __COMPAT_WAIT_H__ */
-- 
-Eric 'shubes'

Davide wrote:
> Hi!
> I'm trying to install vm-tools in Ipcop 1.4.21 distribution following 
> these instructions:
> http://www.ipcop.org/index.php?module=pnWikka&tag=HowToCompileAdditionalCode 
> <http://www.ipcop.org/index.php?module=pnWikka&tag=HowToCompileAdditionalCode>
> 
> I've downloaded the sources package of ipcop and compile it with success.
> So,
> I've added the source package of open-vm-tools 
> (http://open-vm-tools.sourceforge.net/) at directory "cache".
> I've write the script for open-vm-tools in "lsf" directory, like this:
> 
> $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects))
>     @$(PREBUILD)
>     @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar zxf $(DIR_DL)/$(DL_FILE)
>     cd $(DIR_APP) && ./configure --without-x --without-procps 
> --without-dnet --without-icu
>     cd $(DIR_APP) && make
>     cd $(DIR_APP) && make install
>     @rm -rf $(DIR_APP)
>     @$(POSTBUILD)
> 
> But, i have this trouble with the make command:
> 
> make[3]: Entering directory 
> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
> make[4]: Entering directory 
> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
> Dependencies for .././linux/af_vsock.c
> Dependencies for .././linux/vsockAddr.c
> Dependencies for .././linux/util.c
> Dependencies for .././linux/driverLog.c
> make[4]: Leaving directory 
> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
> make[4]: Entering directory 
> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
> Compiling .././linux/af_vsock.c
> ../linux/af_vsock.c: In function `VSockVmciStreamConnect':
> ../linux/af_vsock.c:3199: warning: implicit declaration of function 
> `DEFINE_WAIT'
> ../linux/af_vsock.c:3199: error: `wait' undeclared (first use in this 
> function)
> ../linux/af_vsock.c:3199: error: (Each undeclared identifier is reported 
> only once
> ../linux/af_vsock.c:3199: error: for each function it appears in.)
> ../linux/af_vsock.c:3275: warning: implicit declaration of function 
> `prepare_to_wait'
> ../linux/af_vsock.c:3310: warning: implicit declaration of function 
> `finish_wait'
> ../linux/af_vsock.c: In function `VSockVmciAccept':
> ../linux/af_vsock.c:3348: error: `wait' undeclared (first use in this 
> function)
> ../linux/af_vsock.c: In function `VSockVmciStreamSendmsg':
> ../linux/af_vsock.c:4079: error: `wait' undeclared (first use in this 
> function)
> ../linux/af_vsock.c: In function `VSockVmciStreamRecvmsg':
> ../linux/af_vsock.c:4428: error: `wait' undeclared (first use in this 
> function)
> make[4]: *** [af_vsock.o] Error 1
> make[4]: Leaving directory 
> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
> make[3]: *** [driver] Error 2
> make[3]: Leaving directory 
> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
> make[2]: *** [vsock] Error 2
> make[2]: Leaving directory `/usr/src/vm-tools-2008.09.03-114782/modules'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/src/vm-tools-2008.09.03-114782'
> make: *** [/usr/src/log/vm-tools-2008.09.03-114782] Error 2
> 
> Someone have any idea?
> (I run compile with some parameters that exclude some (optional ?) librarys)
> 
> Sorry for my english :-\
> 
> Best regards.
> Davide
> 
> 

Ok, I've figured this one out. According to some comments in 
compat_wait.h, DEFINE_WAIT() and friends were backported to kernel 
2.4.28, so they weren't being included. The IPCop kernel 2.4.36 doesn't 
have this backport (why I don't know). I modified compat_wait.h to 
include the DEFINE_WAIT() code with the kernel versions < 2.4.48, and 
now vsock compiles clean.

Now for trying turn on a few more features, then installing and testing 
this thing. Stay tuned.

-- 
-Eric 'shubes'

Eric Shubert wrote:
> Eric Shubert wrote:
>> Gilles Espinasse wrote:
>>> ----- Original Message ----- 
>>> From: Davide
>>> To: ipc...@li...
>>> Sent: Monday, October 27, 2008 7:53 PM
>>> Subject: [IPCop-devel] Adding vm-tools package to IPCOP 1.4.21
>>>
>>>
>>>> make[3]: Entering directory
>>> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
>>>
>>> I am stopped before that stage.
>>> I add the call in make.sh after openvpn
>>> On the lfs file, I had to add --with-kernel-release=$(KVER) or configure
>>> stop very early
>>>
>>> Tested with 2008.09.03-114782 or 2008.10.10-123053 , it fail similary with
>>> make[3]: Entering directory
>>> `/usr/src/open-vm-tools-2008.09.03-114782/modules/linux/vmxnet'
>>> In file included from /lib/modules/2.4.36/build/include/asm/dma.h:14,
>>>                  from vmxnet.c:34:
>>> /lib/modules/2.4.36/build/include/linux/delay.h:62: error: parse error
>>> before "const"
>>> make[3]: *** [vmxnet.o] Error 1
>>>
>>> Gilles
>>>
>>> PS I have attached the lfs file I used
>>>
>> I too tried this with open-vm-tools-2009.02.18-148847. After installing 
>> pkg-config and glib2 for new dependencies, I get the same parse error as 
>> Gilles.
>>
>> Has anyone made any progress with this? I'm wondering if perhaps we need 
>> a compile flag of some sort.
>>
> 
> I've made some progress, and here's an update.
> 
> The recent open-vm-tools-2009.02.18-148847 added a dependency for glib2, 
> and pkg-config. I created Makefiles for them (attached) and added 
> lfsmake2 commands for them to the make.sh script at the end of the 
> buildbase function. They appear to have built without a problem.
> 
> Then I proceeded to try debugging the error that Gilles and I were 
> getting with vmxnet. I'm not sure what the problem with linux/delay.h 
> exactly was, but it doesn't appear to be necessary. I tried removing
> #include <asm/dma.h>
> from vmxnet.c, and the only complaint was the lack of the udelay 
> function, which is defined in <asm/delay.h>. It appears that asm/dma.h 
> was including linux/delay.h, which in turn included asm/delay.h. I 
> replaced <asm/dma.h> with <asm/delay.h>, and vmxnet.c compiled clean.
> 
> The next error was with vmhgfs. Makefile.normal had specified 
> hgfsEscapeLinux.o, while the program was really hgfsEscape.o (the 
> "Linux" part had apparently been dropped along the line). I modified 
> Makefile.normal, specifying hgfsEscape.o, and it compiled clean.
> 
> Now I'm up to (or back to?) Davide's original problem. I'm getting 
> exactly the same error as his original post. I don't see a quick fix for 
> that right now. I expect that I'll just omit this as it's not necessary 
> for IPCop.
> 
> Tomorrow I hope to move on to installing the pertinent pieces in a test 
> IPCop.
> 

Here are the attachments. (I hate it when I do that!)

-- 
-Eric 'shubes'

Eric Shubert wrote:
> Gilles Espinasse wrote:
>> ----- Original Message ----- 
>> From: Davide
>> To: ipc...@li...
>> Sent: Monday, October 27, 2008 7:53 PM
>> Subject: [IPCop-devel] Adding vm-tools package to IPCOP 1.4.21
>>
>>
>>> make[3]: Entering directory
>> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
>>
>> I am stopped before that stage.
>> I add the call in make.sh after openvpn
>> On the lfs file, I had to add --with-kernel-release=$(KVER) or configure
>> stop very early
>>
>> Tested with 2008.09.03-114782 or 2008.10.10-123053 , it fail similary with
>> make[3]: Entering directory
>> `/usr/src/open-vm-tools-2008.09.03-114782/modules/linux/vmxnet'
>> In file included from /lib/modules/2.4.36/build/include/asm/dma.h:14,
>>                  from vmxnet.c:34:
>> /lib/modules/2.4.36/build/include/linux/delay.h:62: error: parse error
>> before "const"
>> make[3]: *** [vmxnet.o] Error 1
>>
>> Gilles
>>
>> PS I have attached the lfs file I used
>>
> 
> I too tried this with open-vm-tools-2009.02.18-148847. After installing 
> pkg-config and glib2 for new dependencies, I get the same parse error as 
> Gilles.
> 
> Has anyone made any progress with this? I'm wondering if perhaps we need 
> a compile flag of some sort.
> 

I've made some progress, and here's an update.

The recent open-vm-tools-2009.02.18-148847 added a dependency for glib2, 
and pkg-config. I created Makefiles for them (attached) and added 
lfsmake2 commands for them to the make.sh script at the end of the 
buildbase function. They appear to have built without a problem.

Then I proceeded to try debugging the error that Gilles and I were 
getting with vmxnet. I'm not sure what the problem with linux/delay.h 
exactly was, but it doesn't appear to be necessary. I tried removing
#include <asm/dma.h>
from vmxnet.c, and the only complaint was the lack of the udelay 
function, which is defined in <asm/delay.h>. It appears that asm/dma.h 
was including linux/delay.h, which in turn included asm/delay.h. I 
replaced <asm/dma.h> with <asm/delay.h>, and vmxnet.c compiled clean.

The next error was with vmhgfs. Makefile.normal had specified 
hgfsEscapeLinux.o, while the program was really hgfsEscape.o (the 
"Linux" part had apparently been dropped along the line). I modified 
Makefile.normal, specifying hgfsEscape.o, and it compiled clean.

Now I'm up to (or back to?) Davide's original problem. I'm getting 
exactly the same error as his original post. I don't see a quick fix for 
that right now. I expect that I'll just omit this as it's not necessary 
for IPCop.

Tomorrow I hope to move on to installing the pertinent pieces in a test 
IPCop.

-- 
-Eric 'shubes'

Gilles Espinasse wrote:

> Probably many IDE and scsi chipset drivers are not necessary on the ppc
> arch.
> Having everything enabled is only convenient when checking config arch
> difference from 486. But I don't know exactly wich driver would be needed.

We could disable some, but I would not know which and the differences 
between architectures makes things complicated.


Maybe it is easier to create a ipcop-1.9.4-drivers-<arch>.tar.gz, 
similar to what we now do on 1.4 ?
We could for example put the PCMCIA and SCSI drivers in that, and the 
installer can ask "Do you want to use the additional drivers for 
installation?"

Or, if we use this only for ppc and netboot, the installer can detect 
that and either ask the question or automatically try to load the 
drivers.tar.gz



Olaf

Gilles Espinasse wrote:
> ----- Original Message ----- 
> From: Davide
> To: ipc...@li...
> Sent: Monday, October 27, 2008 7:53 PM
> Subject: [IPCop-devel] Adding vm-tools package to IPCOP 1.4.21
> 
> 
>> make[3]: Entering directory
> `/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
> 
> I am stopped before that stage.
> I add the call in make.sh after openvpn
> On the lfs file, I had to add --with-kernel-release=$(KVER) or configure
> stop very early
> 
> Tested with 2008.09.03-114782 or 2008.10.10-123053 , it fail similary with
> make[3]: Entering directory
> `/usr/src/open-vm-tools-2008.09.03-114782/modules/linux/vmxnet'
> In file included from /lib/modules/2.4.36/build/include/asm/dma.h:14,
>                  from vmxnet.c:34:
> /lib/modules/2.4.36/build/include/linux/delay.h:62: error: parse error
> before "const"
> make[3]: *** [vmxnet.o] Error 1
> 
> Gilles
> 
> PS I have attached the lfs file I used
> 

I too tried this with open-vm-tools-2009.02.18-148847. After installing 
pkg-config and glib2 for new dependencies, I get the same parse error as 
Gilles.

Has anyone made any progress with this? I'm wondering if perhaps we need 
a compile flag of some sort.

-- 
-Eric 'shubes'

----- Original Message ----- 
From: "Olaf" <mai...@ba...>
To: <ipc...@li...>
Cc: "Gilles Espinasse" <g....@fr...>
Sent: Sunday, February 22, 2009 2:35 PM
Subject: [2.0] PPC initramfs


> ges...@us... wrote:
> > Revision: 2522
> >           http://ipcop.svn.sourceforge.net/ipcop/?rev=2522&view=rev
> > Author:   gespinasse
> > Date:     2009-02-22 13:04:49 +0000 (Sun, 22 Feb 2009)
> >
> > Log Message:
> > -----------
> > Upgrade yaboot to 1.3.14
> > cd boot work
> > network boot fail unless initramfs size is reduced under 6 MB
> By how much would we need to shrink the initramfs ?
> The i486 initramfs is ~ 6.1 MB
>
>
> Olaf
>
On ppc, code is much bigger

Without changes on initramfs, cdinitramfs size is 7396 kB
I think that yaboot netboot work with an initramfs smaller than 6MB.

I have tested some changes on initramfs

+       # Save 4k when compressed
+       sed -i -e '/last-updated/d'
$(INITRAMFS_DIR)/usr/share/discover/pci-device.xml

Removing x and sound drivers from pci-device.xml should gain more space but
that need to be done manually. We will not spare more than 100 kB compressed
there as full file compresssed is less than 200 kB.

Removing /lib/firmware and a few unneeded modules bsd_comp.ko,tun.ko allow
to reduce the size to 6972 kB. So that's still far from ~6000 kB

Probably many IDE and scsi chipset drivers are not necessary on the ppc
arch.
Having everything enabled is only convenient when checking config arch
difference from 486. But I don't know exactly wich driver would be needed.

And we have IDE drivers for ide/pci and ata/pata
To my understanding, both are drivers for the same hardware. That's legacy
and new flavor drivers.
Looking at yellowdog linux kernel config, they have CONFIG_ATA is not set
and many IDE chipset disabled.
That's probably the way to go to reduce initramfs size.

Gilles

On Sunday 22 February 2009 06:41:16 am you wrote:
> David W Studeman wrote:
> > The rom kernel has ide drivers embedded, ext2, and ext3, as well as the
> > network modules you are using to connect to nfs. There is another boot
> > option bfx where you can specify that it boot another kernel over the
> > net. I've seen people use bfx n n and when I do that, it looks for a
> > tftpboot folder too. I need more info on the other bfx parameters.
>
> I don't know if there are more parameters, if I use bfx n n, I can see
> that a kernel is loaded from a NFS /tftpboot folder.
>
> If said kernel is missing, this happens and boot is again tried from
> /nfsroot-x86:
> BOOTLOADER: Mapping in physical locations
> BOOTLOADER: load_addr=0xc2004000 ret_data=0xc2205cc4
> BOOTLOADER: opening "/boot/vmlinux.bz2"
> BOOTLOADER: opening "/vmlinux.bz2"
> BOOTLOADER: opening "/boot/vmlinux.gz"
> BOOTLOADER: opening "/vmlinux.gz"
> BOOTLOADER: calling reboot notifiers
> md: stopping all md devices.
> flushing ide devices:
> BOOTLOADER: mapping 22M-32M for ride home
> BOOTLOADER: disabling interrupts
> BOOTLOADER: flushing cache
> BOOTLOADER: Leap of faith!
> Back in ramcode: done
> Second stage load failed.  Booting ROM kernel...
>
>
> When a kernel is found (bzipped from current SVN), I get:
> BOOTLOADER: Mapping in physical locations
> BOOTLOADER: load_addr=0xc2004000 ret_data=0xc2205cc4
> BOOTLOADER: opening "/boot/vmlinux.bz2"
> BOOTLOADER: opening "/vmlinux.bz2"
> BOOTLOADER: reading "/vmlinux.bz2"
> BOOTLOADER: read 1306109bytes
> BOOTLOADER: unmounting /
> BOOTLOADER: calling reboot notifiers
> md: stopping all md devices.
> flushing ide devices:
> BOOTLOADER: mapping 22M-32M for ride home
> BOOTLOADER: disabling interrupts
> BOOTLOADER: flushing cache
> BOOTLOADER: Leap of faith!
> Back in ramcode: done
> Second stage kernel: Decompressing - done
>
> And then silence ...  Must be because we do not have NFS.
> Anyways, this just might look like a way to get 2.0 on a RaQ4.
>
>
> Olaf

The only problem with using BFX  n n is that it relies on dhcp to tell 
it where to go so everyone would have to add parameters to a dhcp server 
to point to a public ip in order to install. I also made a 2.4.37 kernel 
recently using the same config file as the rom kernel used to compile 
it, all that stuff is available and put the monolithic kernel in 
tftpboot, it also started to boot after the leap of faith message but 
crashed. Was yours a patched kernel? You need the patch to see serial 
console output after 2.6.24. Jeff worked long hours to track that one 
down and modify the cobalt patch accordingly.

If you set the btoip in the cmos, one could easily install over the 
internet but only using bfn. Basically if the installer uses the rom 
kernel which is 2.4.25 and has every driver you need for the hardware on 
the unit except usb, you're golden. It's also not difficult to make a 
rom with a different kernel if the kernel is all you are changing but it 
seems like you would be upgrading roms a lot to match the installer.
Likely you know this  stuff from your own findings or mine previously. 
Using bfn, the rom simply looks for /sbin/init, it does not look for a 
kernel. After uncompressing and loop mounting installroot and in turn 
copying those contents to /nfsroot-x86, /sbin/init of course links to 
busybox which starts, runs and I can get as far as network or cd rom and 
trying anything at this point fails because the installer does not know 
that it really already has network and ide drivers loaded via the 
monolithic rom kernel, and gives you a press to reboot button that does 
in fact reboot the machine.


Dave

David W Studeman wrote:

> The rom kernel has ide drivers embedded, ext2, and ext3, as well as the 
> network modules you are using to connect to nfs. There is another boot option 
> bfx where you can specify that it boot another kernel over the net. I've seen 
> people use bfx n n and when I do that, it looks for a tftpboot folder too. I 
> need more info on the other bfx parameters. 

I don't know if there are more parameters, if I use bfx n n, I can see 
that a kernel is loaded from a NFS /tftpboot folder.

If said kernel is missing, this happens and boot is again tried from 
/nfsroot-x86:
BOOTLOADER: Mapping in physical locations
BOOTLOADER: load_addr=0xc2004000 ret_data=0xc2205cc4
BOOTLOADER: opening "/boot/vmlinux.bz2"
BOOTLOADER: opening "/vmlinux.bz2"
BOOTLOADER: opening "/boot/vmlinux.gz"
BOOTLOADER: opening "/vmlinux.gz"
BOOTLOADER: calling reboot notifiers
md: stopping all md devices.
flushing ide devices:
BOOTLOADER: mapping 22M-32M for ride home
BOOTLOADER: disabling interrupts
BOOTLOADER: flushing cache
BOOTLOADER: Leap of faith!
Back in ramcode: done
Second stage load failed.  Booting ROM kernel...


When a kernel is found (bzipped from current SVN), I get:
BOOTLOADER: Mapping in physical locations
BOOTLOADER: load_addr=0xc2004000 ret_data=0xc2205cc4
BOOTLOADER: opening "/boot/vmlinux.bz2"
BOOTLOADER: opening "/vmlinux.bz2"
BOOTLOADER: reading "/vmlinux.bz2"
BOOTLOADER: read 1306109bytes
BOOTLOADER: unmounting /
BOOTLOADER: calling reboot notifiers
md: stopping all md devices.
flushing ide devices:
BOOTLOADER: mapping 22M-32M for ride home
BOOTLOADER: disabling interrupts
BOOTLOADER: flushing cache
BOOTLOADER: Leap of faith!
Back in ramcode: done
Second stage kernel: Decompressing - done

And then silence ...  Must be because we do not have NFS.
Anyways, this just might look like a way to get 2.0 on a RaQ4.


Olaf

-- 

A weizen a day helps keep the doctor away.

ges...@us... wrote:
> Revision: 2522
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=2522&view=rev
> Author:   gespinasse
> Date:     2009-02-22 13:04:49 +0000 (Sun, 22 Feb 2009)
>
> Log Message:
> -----------
> Upgrade yaboot to 1.3.14
> cd boot work
> network boot fail unless initramfs size is reduced under 6 MB
By how much would we need to shrink the initramfs ?
The i486 initramfs is ~ 6.1 MB


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Sunday, February 15, 2009 4:42 PM
Subject: Re: [IPCop-devel] rrdtools-1.3.6 difference when checking if msync
with MS_ASYNC updates the files mtime


> Gilles Espinasse wrote:
>
> > Could I have your feedback when checking our resulting rrdtool files?
>
> 723fe9be58c95cf7112b6eb4a13706ff  /usr/lib/librrd.so
> 723fe9be58c95cf7112b6eb4a13706ff  /usr/lib/librrd.so.4
> 723fe9be58c95cf7112b6eb4a13706ff  /usr/lib/librrd.so.4.0.5
> 812e83dd3d7d7f3f7b70f067bdb51744  /usr/lib/librrd_th.so
> 812e83dd3d7d7f3f7b70f067bdb51744  /usr/lib/librrd_th.so.4
> 812e83dd3d7d7f3f7b70f067bdb51744  /usr/lib/librrd_th.so.4.0.5
>
>
> > Machines are both with AMD XP cpu
> > The machine that fail on the test is the debian etch machine with 2.6.18
> > kernel running when the other is with 2.6.27 kernel (but to my
> > understanding, that really should not matter).
>
> I have a (probably fairly similar) Debian Etch 2.6.18 machine.
>
>
> Olaf
>
tested by upgrading to 2.6.26 lenny and md5 remain the same as with etch
2.6.18.
Upgrading the kernel to 2.6.27 and md5 change to what I had with the other
machine and 2.6.27 kernel.

So it appear that 'checking if msync with MS_ASYNC updates the files mtime'
is a running kernel feature that leak during our compilation.
I find a related rrd message
http://oss.oetiker.ch/rrdtool/forum.en.html#nabble-td1618319

Test was made on purpose but work only against the running kernel.
I have preset the test result to ok so now it no more depend on the running
kernel.

Gilles

>> Is this correct for alpha, ppc and sparc ?
>>
> Should be ok :
> alpha is mostly like sparc except you need to let a few block free at disk
> start for aboot.

I am not sure we have that now.


>>   *  Partition scheme is:
>>   *  i386      partition1 /
>>   *            partition2 /var/log
>>   *
>>   *  alpha     partition1 /    need to let space at disk start for aboot
>> installation
>>   *            partition2 /var/log
>>   *            partition3 -- reserved, absolutely can't be used
>>   *
>>   *  powerpc   partition1 -- reserved, absolutely can't be used
>>   *            partition2 -- reserved, absolutely can't be used
>>   *            partition3 /
>>   *            partition4 /var/log
>>   *
>>   *  sparc     partition1 /
>>   *            partition2 /var/log
>>   *            partition3 -- reserved, absolutely can't be used
>>   *


This is now in SVN. I think I got it right for PPC and Sparc, please 
report any problems.


> That's a long time I did not power my alpha machine.
> It's slow and has a bug with the net card that I think could be fixed by a
> recent patch.
> I could have too have put another nic.

For alpha we are still missing the code to make bootable.
Probably not much, but it is still empty. If there are suggestions for 
that I will code it.


Olaf

On 21.02.2009, at 13:31, Olaf <mai...@ba...> wrote:

>
>
>>> Thinking more, that should not be a problem to combine /boot and  
>>> root.
>>> If (/boot and root) size is limited to 512 MB, we should not reach  
>>> the 1024
>>> limit.
>> OK, I will start working on that. Hopefully I do not break the  
>> partitioning for ppc/sparc too much ;-)
>
>
> Is this correct for alpha, ppc and sparc ?
>
>
> *  Partition scheme is:
> *  i386      partition1 /
> *            partition2 /var/log
> *
> *  alpha     partition1 /    need to let space at disk start for  
> aboot installation
> *            partition2 /var/log
> *            partition3 -- reserved, absolutely can't be used
> *
> *  powerpc   partition1 -- reserved, absolutely can't be used
> *            partition2 -- reserved, absolutely can't be used
> *            partition3 /
> *            partition4 /var/log
> *
> *  sparc     partition1 /
> *            partition2 /var/log
> *            partition3 -- reserved, absolutely can't be used
> *
>
>
> Olaf


Olaf,

yes, ppc and sparc are good with this partition scheme.

IvanK.

>> Thinking more, that should not be a problem to combine /boot and root.
>> If (/boot and root) size is limited to 512 MB, we should not reach the 1024
>> limit.
> 
> OK, I will start working on that. Hopefully I do not break the 
> partitioning for ppc/sparc too much ;-)


Is this correct for alpha, ppc and sparc ?


  *  Partition scheme is:
  *  i386      partition1 /
  *            partition2 /var/log
  *
  *  alpha     partition1 /    need to let space at disk start for aboot 
installation
  *            partition2 /var/log
  *            partition3 -- reserved, absolutely can't be used
  *
  *  powerpc   partition1 -- reserved, absolutely can't be used
  *            partition2 -- reserved, absolutely can't be used
  *            partition3 /
  *            partition4 /var/log
  *
  *  sparc     partition1 /
  *            partition2 /var/log
  *            partition3 -- reserved, absolutely can't be used
  *


Olaf

----- Original Message ----- 
From: "Olaf" <mai...@ba...>
To: "IPCop devel" <ipc...@li...>
Cc: "Ivan Kabaivanov" <ch...@ya...>; "Gilles Espinasse"
<g....@fr...>
Sent: Saturday, February 21, 2009 12:31 PM
Subject: Re: [IPCop-devel] [2.0] to grub or not to grub


>
>
> >> Thinking more, that should not be a problem to combine /boot and root.
> >> If (/boot and root) size is limited to 512 MB, we should not reach the
1024
> >> limit.
> >
> > OK, I will start working on that. Hopefully I do not break the
> > partitioning for ppc/sparc too much ;-)
>
>
> Is this correct for alpha, ppc and sparc ?
>
Should be ok :
alpha is mostly like sparc except you need to let a few block free at disk
start for aboot.

>
>   *  Partition scheme is:
>   *  i386      partition1 /
>   *            partition2 /var/log
>   *
>   *  alpha     partition1 /    need to let space at disk start for aboot
> installation
>   *            partition2 /var/log
>   *            partition3 -- reserved, absolutely can't be used
>   *
>   *  powerpc   partition1 -- reserved, absolutely can't be used
>   *            partition2 -- reserved, absolutely can't be used
>   *            partition3 /
>   *            partition4 /var/log
>   *
>   *  sparc     partition1 /
>   *            partition2 /var/log
>   *            partition3 -- reserved, absolutely can't be used
>   *
>
That's a long time I did not power my alpha machine.
It's slow and has a bug with the net card that I think could be fixed by a
recent patch.
I could have too have put another nic.

Gilles

----- Original Message ----- 
From: "Olaf" <mai...@ba...>
Cc: "Gilles Espinasse" <g....@fr...>; "IPCop devel"
<ipc...@li...>
Sent: Saturday, February 21, 2009 9:24 AM
Subject: Re: [IPCop-devel] [2.0] to grub or not to grub


> Olaf wrote:
> > Gilles Espinasse wrote:
> >
> >> Thinking more, that should not be a problem to combine /boot and root.
> >> If (/boot and root) size is limited to 512 MB, we should not reach the
1024
> >> limit.
> >
> > OK, I will start working on that. Hopefully I do not break the
> > partitioning for ppc/sparc too much ;-)
>
> When doing that, I would also like to change from 3 tar.gz files into 1
> file (as we do for 1.4).
> So bundle config.tar.gz, varlog.tar.gz into ipcop-<version>.tar.gz
>
> Any objections?
>
>
> Olaf
>
I am ok

Gilles

Olaf wrote:
> Gilles Espinasse wrote:
> 
>> Thinking more, that should not be a problem to combine /boot and root.
>> If (/boot and root) size is limited to 512 MB, we should not reach the 1024
>> limit.
> 
> OK, I will start working on that. Hopefully I do not break the 
> partitioning for ppc/sparc too much ;-)

When doing that, I would also like to change from 3 tar.gz files into 1 
file (as we do for 1.4).
So bundle config.tar.gz, varlog.tar.gz into ipcop-<version>.tar.gz

Any objections?


Olaf

Gilles Espinasse wrote:

> Thinking more, that should not be a problem to combine /boot and root.
> If (/boot and root) size is limited to 512 MB, we should not reach the 1024
> limit.

OK, I will start working on that. Hopefully I do not break the 
partitioning for ppc/sparc too much ;-)


>>> Another point, I would rethink to compress modules outside of initramfs.
>>> This sort of patch already exist againts kernel sources or simplier, we
>>> could replace with a find like in 1.4.
>>> That should help to shrink minimal root size.
>> OK, but how do we rebuild initramfs after kernel upgrade?
>> Would that require following procedure:
>>   - unpack current initramfs to /tmp/newinitramfs
>>   - find modules we want from /tmp/newinitramfs/lib/modules/<oldkernel>
>>   - uncompress modules we need into
>> /tmp/newinitramfs/lib/modules/<newkernel>
>>   - remove /tmp/newinitramfs/lib/modules/<oldkernel>
>>   - pack new initramfs from /tmp/newinitramfs
>>
> yes
> 
> Another possibility would be to have modules compressed inside initramfs.
> This should help to miminize memory requirement on install.
> BUT, currently busybox does not support compressed modules actually.
> Compressed (gzip) modules inside initramfs may produce a slightly bigger
> initramfs when initramfs is compressed with gzip. I am unsure that's still true
> if initramfs is compressed with lzma.

I think that is making too many patches and probably not worth the trouble.
Currently it would be sufficient to have compressed modules only outside 
the initramfs, no?
Surely building a new initramfs is a bit more work, but nothing that 
cannot be handled and also it is not something we need to do every week.


Olaf


PS: I am currently fighting ide=nodma, that does not work anymore (cause 
have ide-core as module and not built-in, along with some changes in 
kernel parameters).
And yes it it sometimes needed, I have at least one CF-IDE adapter that 
does not support dma and also seems to break the auto-detection mechanisms.

Selon Olaf <mai...@ba...>:

> Gilles Espinasse wrote:
>
> >> We could for example choose (just a thought):
> >>   - root (boot & root combined), minimum size ~ 192 MB, maximum size 512 MB
> >>   - log (/var/log), minimum size 64 MB, maximum size 1024 MB
> >>   - cache (/var/cache), no minimum size, no maximum size
> >>
> > I agree that a fixed partitionning scheme would be easier.
> >
> > /boot partition was first and small to fix buggy bioses with 1024 cylinder
> > limit.
> > http://tldp.org/HOWTO/Large-Disk-HOWTO-5.html say most bios after 1998
> > should be ok.
> > I don't know if we should move to combined /boot & root.
> > For sure, that would be easier on kernel update.
>
> If I read this correctly
> http://www.geocities.com/epark/linux/redhat72-install-HOWTO.html
>    it is still possible to address several GB, even with 1024 limitation.
> So if we put a max. limit on bootroot we would still be OK.
>
> And yes, it makes kernel upgrades so much easier.
>
Thinking more, that should not be a problem to combine /boot and root.
If (/boot and root) size is limited to 512 MB, we should not reach the 1024
limit.


...
>
> > Another point, I would rethink to compress modules outside of initramfs.
> > This sort of patch already exist againts kernel sources or simplier, we
> > could replace with a find like in 1.4.
> > That should help to shrink minimal root size.
>
> OK, but how do we rebuild initramfs after kernel upgrade?
> Would that require following procedure:
>   - unpack current initramfs to /tmp/newinitramfs
>   - find modules we want from /tmp/newinitramfs/lib/modules/<oldkernel>
>   - uncompress modules we need into
> /tmp/newinitramfs/lib/modules/<newkernel>
>   - remove /tmp/newinitramfs/lib/modules/<oldkernel>
>   - pack new initramfs from /tmp/newinitramfs
>
yes

Another possibility would be to have modules compressed inside initramfs.
This should help to miminize memory requirement on install.
BUT, currently busybox does not support compressed modules actually.
Compressed (gzip) modules inside initramfs may produce a slightly bigger
initramfs when initramfs is compressed with gzip. I am unsure that's still true
if initramfs is compressed with lzma.


Gilles

Gilles Espinasse wrote:

>> We could for example choose (just a thought):
>>   - root (boot & root combined), minimum size ~ 192 MB, maximum size 512 MB
>>   - log (/var/log), minimum size 64 MB, maximum size 1024 MB
>>   - cache (/var/cache), no minimum size, no maximum size
>>
> I agree that a fixed partitionning scheme would be easier.
> 
> /boot partition was first and small to fix buggy bioses with 1024 cylinder
> limit.
> http://tldp.org/HOWTO/Large-Disk-HOWTO-5.html say most bios after 1998 should be
> ok.
> I don't know if we should move to combined /boot & root.
> For sure, that would be easier on kernel update.

If I read this correctly 
http://www.geocities.com/epark/linux/redhat72-install-HOWTO.html
   it is still possible to address several GB, even with 1024 limitation.
So if we put a max. limit on bootroot we would still be OK.

And yes, it makes kernel upgrades so much easier.


> Having a screen that display calculated sizes with minimal and maximal limits
> may be enought for simple customization. That would limit risk errors and allow
> minimal configuration.

OK.


> Another point, I would rethink to compress modules outside of initramfs.
> This sort of patch already exist againts kernel sources or simplier, we could
> replace with a find like in 1.4.
> That should help to shrink minimal root size.

OK, but how do we rebuild initramfs after kernel upgrade?
Would that require following procedure:
  - unpack current initramfs to /tmp/newinitramfs
  - find modules we want from /tmp/newinitramfs/lib/modules/<oldkernel>
  - uncompress modules we need into 
/tmp/newinitramfs/lib/modules/<newkernel>
  - remove /tmp/newinitramfs/lib/modules/<oldkernel>
  - pack new initramfs from /tmp/newinitramfs



Olaf

Gilles Espinasse wrote:

>>> Concerning boot, I would prefer an option with kernel quiet mode and a
>>> verbose option (simply without quiet mode).
>> You mean something like this?
>>
>>
>> LABEL ipcop
>>    MENU default
>>    MENU LABEL IPCop
>>    KERNEL vmlinuz
>>    APPEND mode=normal initrd=ipcoprd.img root=/dev/hda2 ro panic=10 quiet
>>
>> LABEL verbose
>>    MENU LABEL IPCop (verbose boot)
>>    KERNEL vmlinuz
>>    APPEND mode=normal initrd=ipcoprd.img root=/dev/hda2 ro panic=10
>>
>>
>> Olaf
>>
> I was more thinking at installation stage.
> After installation, I don't know if we need both.
> quiet mode is fine when everything is ok and you don't need to capture boot log
> for diagnoses.

Ah. Okay.
We now have install, rescue, dma, parted and memtest.

parted is actually not needed, syslinux is quite happy to accept 
combination like install parted.

So we could change to: install, verbose, dma, rescue and memtest
Where install would boot the kernel with quiet.


Olaf

Selon Olaf <mai...@ba...>:

> Gilles Espinasse wrote:
>
> >> I am not so sure about making custom partition an easy to access option.
> >> We rely on a specific partition scheme, if someone decides that he/she
> >> wants to do things differently then that is OK of course. But I see no
> >> special reason to make such things (which can easily be done wrong)
> >> easily accessible. Nor am I keen on documenting how someone can do
> >> custom partitioning.
> >>
> > obscurity is evil ;-)
>
> Maybe ;-)  Anyways there is no problem describing such options in one of
> those F1, F2, F3, F4.txt files
>
>
> > Another point is to have an optional partition where to put application
> data.
> > This would avoid to have /var/log full when squid cache grow.
> > But this has one drawback to be less flexible so on small disk, 'like in
> > 1.4' scheme may be prefered.
>
> We can still rethink our partitioning strategy. The point about squid
> cache is valid.
> However I would very much like to keep a fixed partitioning scheme,
> makes it so much easier for support, upgrades etc.
>
> We could for example choose (just a thought):
>   - root (boot & root combined), minimum size ~ 192 MB, maximum size 512 MB
>   - log (/var/log), minimum size 64 MB, maximum size 1024 MB
>   - cache (/var/cache), no minimum size, no maximum size
>
I agree that a fixed partitionning scheme would be easier.

/boot partition was first and small to fix buggy bioses with 1024 cylinder
limit.
http://tldp.org/HOWTO/Large-Disk-HOWTO-5.html say most bios after 1998 should be
ok.
I don't know if we should move to combined /boot & root.
For sure, that would be easier on kernel update.

Having a screen that display calculated sizes with minimal and maximal limits
may be enought for simple customization. That would limit risk errors and allow
minimal configuration.

Another point, I would rethink to compress modules outside of initramfs.
This sort of patch already exist againts kernel sources or simplier, we could
replace with a find like in 1.4.
That should help to shrink minimal root size.

Mandriva is using compressed modules and we already pay the price to have zlib
statically linked in module-init-tools.

There is no gain compressing modules inside initramfs and busybox does not
support compressed modules (but we actually do not use busbox depmod).

>
> > Concerning boot, I would prefer an option with kernel quiet mode and a
> > verbose option (simply without quiet mode).
>
> You mean something like this?
>
>
> LABEL ipcop
>    MENU default
>    MENU LABEL IPCop
>    KERNEL vmlinuz
>    APPEND mode=normal initrd=ipcoprd.img root=/dev/hda2 ro panic=10 quiet
>
> LABEL verbose
>    MENU LABEL IPCop (verbose boot)
>    KERNEL vmlinuz
>    APPEND mode=normal initrd=ipcoprd.img root=/dev/hda2 ro panic=10
>
>
> Olaf
>
I was more thinking at installation stage.
After installation, I don't know if we need both.
quiet mode is fine when everything is ok and you don't need to capture boot log
for diagnoses.

Gilles

Gilles Espinasse wrote:

>> I am not so sure about making custom partition an easy to access option.
>> We rely on a specific partition scheme, if someone decides that he/she
>> wants to do things differently then that is OK of course. But I see no
>> special reason to make such things (which can easily be done wrong)
>> easily accessible. Nor am I keen on documenting how someone can do
>> custom partitioning.
>>
> obscurity is evil ;-)

Maybe ;-)  Anyways there is no problem describing such options in one of 
those F1, F2, F3, F4.txt files


> Another point is to have an optional partition where to put application data.
> This would avoid to have /var/log full when squid cache grow.
> But this has one drawback to be less flexible so on small disk, 'like in 1.4'
> scheme may be prefered.

We can still rethink our partitioning strategy. The point about squid 
cache is valid.
However I would very much like to keep a fixed partitioning scheme, 
makes it so much easier for support, upgrades etc.

We could for example choose (just a thought):
  - root (boot & root combined), minimum size ~ 192 MB, maximum size 512 MB
  - log (/var/log), minimum size 64 MB, maximum size 1024 MB
  - cache (/var/cache), no minimum size, no maximum size


> Concerning boot, I would prefer an option with kernel quiet mode and a verbose
> option (simply without quiet mode).

You mean something like this?


LABEL ipcop
   MENU default
   MENU LABEL IPCop
   KERNEL vmlinuz
   APPEND mode=normal initrd=ipcoprd.img root=/dev/hda2 ro panic=10 quiet

LABEL verbose
   MENU LABEL IPCop (verbose boot)
   KERNEL vmlinuz
   APPEND mode=normal initrd=ipcoprd.img root=/dev/hda2 ro panic=10


Olaf

Selon Olaf <mai...@ba...>:

> Gilles Espinasse wrote:
>
> > I think we should reduce install boot option.
> > Concerning custom partionning, that should be an option selected in the
> > installer, not selected at boot.
>
> I am not so sure about making custom partition an easy to access option.
> We rely on a specific partition scheme, if someone decides that he/she
> wants to do things differently then that is OK of course. But I see no
> special reason to make such things (which can easily be done wrong)
> easily accessible. Nor am I keen on documenting how someone can do
> custom partitioning.
>
obscurity is evil ;-)

There is too much combination to test on boot start.
So shifting to an installer option reduce combination numbers.

I fully agree to a very big warning there.
Documentation is in the partition source so, that should not be so hard to
document. But that vary from one arch to another.

Another point is to have an optional partition where to put application data.
This would avoid to have /var/log full when squid cache grow.
But this has one drawback to be less flexible so on small disk, 'like in 1.4'
scheme may be prefered.

Concerning boot, I would prefer an option with kernel quiet mode and a verbose
option (simply without quiet mode).


Gilles

On Thu, Feb 19, 2009 at 04:29:09PM +0100, Olaf wrote:
>> I don't know why the kernel has move to disabling CONFIG_ACPI_BLACKLIST_YEAR by
>> default. On 2.4, acpi was disabled on bios date before 2000.
>> We may set again CONFIG_ACPI_BLACKLIST_YEAR=2000 to retrieve the same behavior.
>> I have seen one distro using that (I didn't remember wich one).
>> I should look on more distro for that.
> 
> On quick glance I think that would be Ubuntu.

I can confirm that Ubuntu sets that to 2000 for their kernels
since before 6.06 to 8.10.

Debian 4.0 and 5.0 kernels set it to 0 (eg disable it).