Menu
▾
▴
devil-linux-develop
|
From: Heiko Z. <hz...@pr...> - 2003-10-08 12:00:50
|
On 10/07/2003 10:03:19 PM "Dean Nedelman" wrote: >>>2) For some reason, I can no longer scroll backwards through the >console >>>messages on VC/1. I noticed this when I wanted to scroll back and >get a >>>GRSec error and couldn't. I am using the "default" (non-framebuffer)= >option >>>on boot >>> >>SHIFT + PGUP doesn't work? >>I just checked it on VMWare, it worked fine. >>Unfortunately I don't have any computers which don't support the VESA= >mode. > >It is whatever option 0 (the non-framebuffer option) is. I'm sure the= >machine supports VESA - I just don't like the framebuffer modes. That was the version I tried. Are you sure that you didn't switch to another console and then back? Can you try it again? >>>3) I am still getting the grsec resource errors. I believe they are= >comming >>>from /etc/sysconfig/network/scripts/dhcpcd.exe - and yes, even if I >use >the >>>distrubted one: >>> >>>Starting DHCP client daemon on interface eth0 >>>grsec: attempted resource overstep by requesting 37695488 for >RLIMIT_STACK >>>against limit 8388608 by (pidof:381) UID(0) EUID(0), parent >(S05network:370) >>>UID(0) EUID(0) >>>grsec: attempted resource overstep by requesting 77271040 for >RLIMIT_STACK >>>against limit 8388608 by (pidof:381) UID(0) EUID(0), parent >(S05network:370) >>>UID(0) EUID(0) >>> >>I don't use DHCP and I couldn't reproduce the problem with my test >config. >>Can you send me your /etc/dhcpd.conf ? > >I'm not running the dhcp server (which is what /etc/dhcpd.conf is >for.) For >the dhcp CLIENT, the only changes I made to the distributed config fil= e >(/etc/sysconfig/network/dhcp) is the following: >o set DHCLIENT_DEBUG to "no" >o set DHCLIENT_MODIFY_RESOLV_CONF to "no" >o set DHCLIENT_HOSTNAME_OPTION to "" > >The error messages refer to the program "pidof" - and I believe the >complaint is about the one in /etc/sysconfig/network/scripts/dhcpcd.ex= e. I'll check on the client part tonight. But this should be a commonly used option..... >>>5) Starting SAGATOR fails with: >>> >>>creating chroot jail for SAGATOR.....cp: writting >>>`/var/spool/vscan/lib/libc-2.3.2.so': No space left on device >>>And similar cp: errors for another 9 files >>>... >>>.sed: Couldn't flush stdout: No space left on device >>>Warning: no source refers to internal message, they'll go to /dev/nu= ll >>> >>You need more RAM. ;-) > >I have 64MB! We're waisting it, arent we? ;-) >>[...] >>Since the shmfs was eating up more space then it should have, we (I) >>switched to the default which is RAM / 2 >>You really should upgrade to at least 128 MB, this helps a lot. ;-) > >Right now, such an expenditure is not an option (been unemployed for t= he >last 18 months!) That really sucks ! Then you're probably willing to do some research on this: Can you check if it is possible to resize the shmfs ? The problem is that we can't umount it, because when you do that, it's automatically emptied. :-(( >>>6) PowerOFF WORKED! >>> >>> >>Finally! >>This time I would have mailed you a bomb or something... ;-) > >After 18 months of employment - a bomb would have made for welcome >change Would be more like a mail-bomb or so. ;-) cya Heiko = |
|
From: Heiko Z. <hz...@pr...> - 2003-10-08 12:42:37
|
On 10/08/2003 08:31:02 AM Bruce Smith wrote: >> 1) Memtest works! Though I couldn't use 'M' (as the option >indicated), but >> rather 'm'. > >I recommend changing the install script for memtest. If it's not >selected in menuconfig, the option should not be offered on boot. That's the way it is, isn't it? It's done in the build-iso script. Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-10-08 12:58:14
|
> >> 1) Memtest works! Though I couldn't use 'M' (as the option > >indicated), but > >> rather 'm'. > > > >I recommend changing the install script for memtest. If it's not > >selected in menuconfig, the option should not be offered on boot. > > That's the way it is, isn't it? > It's done in the build-iso script. Ah, OK. I was looking in scripts/memtest86 and didn't see it there. I'll take it out of my "firewall only" .config and make sure it works. - BS |
|
From: Heiko Z. <hz...@pr...> - 2003-10-08 13:48:19
|
On 10/08/2003 08:58:10 AM Bruce Smith wrote: >> >> 1) Memtest works! Though I couldn't use 'M' (as the option >> >indicated), but >> >> rather 'm'. >> > >> >I recommend changing the install script for memtest. If it's not >> >selected in menuconfig, the option should not be offered on boot. >> >> That's the way it is, isn't it? >> It's done in the build-iso script. > >Ah, OK. I was looking in scripts/memtest86 and didn't see it there. It had to be in there, because we create the isolinux.cfg dynamically. Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-10-08 13:53:18
|
> >> >> 1) Memtest works! Though I couldn't use 'M' (as the option > >> >indicated), but > >> >> rather 'm'. > >> > > >> >I recommend changing the install script for memtest. If it's not > >> >selected in menuconfig, the option should not be offered on boot. > >> > >> That's the way it is, isn't it? > >> It's done in the build-iso script. > > > >Ah, OK. I was looking in scripts/memtest86 and didn't see it there. > > It had to be in there, because we create the isolinux.cfg dynamically. On my latest ISO w/o memtest86, it shows on the menu but doesn't work. Looks like it's because you do this line UNCONDITIONALLY: echo -n -e " M - MEMTEST86\r\n\r\n" >> $CDDIR/boot/message You only check for memtest when creating isolinux.cfg. - BS |
|
From: Heiko Z. <hz...@pr...> - 2003-10-08 14:42:39
|
On 10/08/2003 09:53:15 AM Bruce Smith wrote: >> >> >> 1) Memtest works! Though I couldn't use 'M' (as the option >> >> >indicated), but >> >> >> rather 'm'. >> >> > >> >> >I recommend changing the install script for memtest. If it's no= t >> >> >selected in menuconfig, the option should not be offered on boot= . >> >> >> >> That's the way it is, isn't it? >> >> It's done in the build-iso script. >> > >> >Ah, OK. I was looking in scripts/memtest86 and didn't see it there= . >> >> It had to be in there, because we create the isolinux.cfg dynamicall= y. > >On my latest ISO w/o memtest86, it shows on the menu but doesn't work.= > >Looks like it's because you do this line UNCONDITIONALLY: > >echo -n -e " M - MEMTEST86\r\n\r\n" >> $CDDIR/boot/message > >You only check for memtest when creating isolinux.cfg. OOPS Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-10-08 15:18:16
|
> >On my latest ISO w/o memtest86, it shows on the menu but doesn't work. > > > >Looks like it's because you do this line UNCONDITIONALLY: > > > >echo -n -e " M - MEMTEST86\r\n\r\n" >> $CDDIR/boot/message > > > >You only check for memtest when creating isolinux.cfg. > > OOPS I'll let you fix it, since I'm not sure where my changes go if I commit something now ... :-) - BS |
|
From: Heiko Z. <hz...@pr...> - 2003-10-08 16:00:43
|
On 10/08/2003 11:18:13 AM Bruce Smith wrote: >> >On my latest ISO w/o memtest86, it shows on the menu but doesn't >work. >> > >> >Looks like it's because you do this line UNCONDITIONALLY: >> > >> >echo -n -e " M - MEMTEST86\r\n\r\n" >> $CDDIR/boot/message >> > >> >You only check for memtest when creating isolinux.cfg. >> >> OOPS > >I'll let you fix it, since I'm not sure where my changes go >if I commit something now ... :-) It will go into 1.1 You have to checkout rel-1-0-patches for the 1.0 branch Heiko = |
|
From: Dean N. <di...@ti...> - 2003-10-08 16:27:45
|
>>>>2) For some reason, I can no longer scroll backwards through the >>console >>>>messages on VC/1. I noticed this when I wanted to scroll back and >>get a >>>>GRSec error and couldn't. I am using the "default" (non-framebuffer) >>option >>>>on boot >>>> >>>SHIFT + PGUP doesn't work? >>>I just checked it on VMWare, it worked fine. >>>Unfortunately I don't have any computers which don't support the VESA >>mode. >> >>It is whatever option 0 (the non-framebuffer option) is. I'm sure the >>machine supports VESA - I just don't like the framebuffer modes. > >That was the version I tried. >Are you sure that you didn't switch to another console and then back? >Can you try it again? You are right - when I tried it again, I had no errors. So, it must have been something I did that prevented me from going back (though I haven't a clue as to what.) >[...] >Then you're probably willing to do some research on this: >Can you check if it is possible to resize the shmfs ? >The problem is that we can't umount it, because when you do that, it's >automatically emptied. :-(( I'll see what I can find out... Dean |
|
From: Bruce S. <bw...@ar...> - 2003-10-08 17:02:28
|
> >Then you're probably willing to do some research on this: > >Can you check if it is possible to resize the shmfs ? > >The problem is that we can't umount it, because when you do that, it's > >automatically emptied. :-(( > > I'll see what I can find out... See if the mount -oremount option works without emptying it. </guess> - BS |
|
From: Dean N. <di...@ti...> - 2003-10-08 22:38:39
|
>> >Then you're probably willing to do some research on this: >> >Can you check if it is possible to resize the shmfs ? >> >The problem is that we can't umount it, because when you do that, it's >> >automatically emptied. :-(( >> >> I'll see what I can find out... > >See if the mount -oremount option works without emptying it. ></guess> Well, according to the research I've done so far - tmpfs (which is listed as the shmfs replacement?) does allow the remount option to change the size on the fly. However, it also states that space used by the tmpfs is NOT eligible for reclamation by the Out-Of-Memory recovery procedures. And yes, mount -o remount, size= does work. On a side issue, I took a look at what was using the space (remember - this is -with- Postfix, and -without- SAGATOR and ClamAV at this point). Here is the -brief- results: Total Space: 30MB Total Space Used: 20MB Amount used by Postfix: 16MB Amount used by Postfix's lib directory (/var/spool/postfix/lib): 14MB So to me, this brings up an obvious question: How come most of these "jails" can't be prebuilt and reside on the CDROM? It seems to me that there are there "types" of files, and that some of these could be built and reside on the CDROM: o Files copied from /etc. These can't be on the CDROM, because they didn't come from the CDROM :-) o Files from /lib, /usr, /dev, /bin, etc. These could certainly be prebuilt and reside on the CDROM. o Files that are created dynamically. Normally these are created by the application. Just my thoughts. Dean Nedelman TimeLord Consulting |
|
From: Heiko Z. <he...@zu...> - 2003-10-09 00:21:21
|
Dean Nedelman wrote: >>>>Then you're probably willing to do some research on this: >>>>Can you check if it is possible to resize the shmfs ? >>>>The problem is that we can't umount it, because when you do that, it's >>>>automatically emptied. :-(( >>>> >>>> >>>I'll see what I can find out... >>> >>> >>See if the mount -oremount option works without emptying it. >></guess> >> >> OK I added a new parameter (CHANGE_SHMFS_SIZE) to the boot script. If defined the system will change the size of the ramdisk. It will be included in 1.0. cya Heiko |
|
From: Heiko Z. <he...@zu...> - 2003-10-09 00:46:19
|
Dean Nedelman wrote: >On a side issue, I took a look at what was using the space (remember - this >is -with- Postfix, and -without- SAGATOR and ClamAV at this point). Here is >the -brief- results: >Total Space: 30MB >Total Space Used: 20MB >Amount used by Postfix: 16MB >Amount used by Postfix's lib directory (/var/spool/postfix/lib): 14MB > >So to me, this brings up an obvious question: >How come most of these "jails" can't be prebuilt and reside on the CDROM? >It seems to me that there are there "types" of files, and that some of these >could be built and reside on the CDROM: >o Files copied from /etc. These can't be on the CDROM, because they didn't >come from the CDROM :-) >o Files from /lib, /usr, /dev, /bin, etc. These could certainly be prebuilt >and reside on the CDROM. >o Files that are created dynamically. Normally these are created by the >application. > > I like that idea ! I added it to our feature requests. cya Heiko |
|
From: Dean N. <di...@ti...> - 2003-10-09 00:58:49
|
>>On a side issue, I took a look at what was using the space (remember - this >>is -with- Postfix, and -without- SAGATOR and ClamAV at this point). Here is >>the -brief- results: >>Total Space: 30MB >>Total Space Used: 20MB >>Amount used by Postfix: 16MB >>Amount used by Postfix's lib directory (/var/spool/postfix/lib): 14MB >> >>So to me, this brings up an obvious question: >>How come most of these "jails" can't be prebuilt and reside on the CDROM? >>[...] > >I like that idea ! >I added it to our feature requests. Well, it gets a little more "interesting". Of that 16MB, 11.5MB is used for one file - libc-2.3.2.so. And since that file would be required for just about any jail, that means that every jail needs at least 11.5MB. So, if we can set this all up on CD, .... Dean |
