devil-linux-develop — developer discussions

Re: [Devil-linux-develop] [PATCH] boot option docu

[Heiko Z. <he...@zu...>]

Roland Pabel wrote:
> Hi,
> here is the patch for the documentation

The patch applied fine, but when I opened the document with the Morphon 
XML editor it complained and your sample "<computeroutput>" seems to be 
messed up.

Heiko

Re: [Devil-linux-develop] [PATCH] To fix mount issue with mounting bootcd.iso off disk/usb drive

[Heiko Z. <he...@zu...>]

Friedrich Lobenstock wrote:
> Tim Tait wrote on 08.05.2004 21:15 MET:
> 
>> Friedrich Lobenstock wrote:
>>
>>> Tim Tait wrote on 08.05.2004 19:13 MET:
>>>
>>>> Friedrich Lobenstock wrote:
>>>>
>>>>>
>>>>> Why don't you change the original mount and add the options 
>>>>> "ro,noatime"
>>>>> there?
>>>>>
>>>>> Just tried it with my local CD-Rom drive to make sure iso9660 
>>>>> accepts the
>>>>> "noatime" option.
>>>>>
>>>>> # mount /dev/cdrom /mnt/ -o ro,noatime # mount | grep /mnt /dev/sr0 
>>>>> on /mnt
>>>>> type iso9660 (ro,noatime)
>>>>
>>>>
>>>>
>>>>
>>>> I thought that mounting it read only from the beginning would break 
>>>> the live-update feature, no?
>>>
>>>
>>>
>>>
>>> Then your patch should also break it too, shouldn't it? 
>>
>>
>> No, because I remount it read-only after the update check is finished 
>> - ie it will have already copied bootcd.iso.new (if it exists) to 
>> bootcd.iso, and thus is ready to continue with the normal mount 
>> sequence, which only requires read access.
> 
> 
> Ok, were did I have my head.
> 
> 
>>>> Tho I suppose if is bootcd.iso.new is detected, it could be 
>>>> remounted rw at
>>>> that time.
>>>
>>>
>>> Can you please test that and add the necessary remount's there?
>>
>>
>> I can, though it will mean 2 remounts - one to make it rw for update, 
>> then another to make ro when update is done.
> 
> 
> The current situation is using the minimal amount of mount commands.
> But for sake of cleaner implementation, meaning in the normal case we 
> don't need to run two mounts, I think the other way is better. Updating 
> is a special case anyway and were you have to take special meassures 
> anyway. How about factoring out the update stuff into another file to 
> make the mount_cdrom more readable again?
> 
> BTW while looking at the update code I think we should also rename/move 
> the /mnt/DEVIL-LINUX file so we know from which version to which we are 
> updating. Heiko!?

I thought we don't need this, because when the configuration gets 
upgraded, then the Admin sees anyway from where to where.
On the other hand, you don't really "see" the upgrade, since the system 
replaces the files and continues the boot process where it then replaces 
the initrd and reboots again....

>> Should the new diff be done against the original, or the last patched 
>> version?  I don't see that change in CVS yet.
> 
> 
> The webinterface seems to be up to date, so you can always get the file 
> from there: 
> http://cvs.sourceforge.net/viewcvs.py/devil-linux/build/config/etc/initrd/mount_cdrom 

They're supposed to be only a few hours behind....

> While you are at it, your addition of "if [ "$3" != "silent" ]" should 
> rather be merged by moving the "if" before "# generate list of cdroms 
> from devfs" down.
> 
> And while your are using the "rw,noatime" mount option why not merge the 
> two for-loops into one? Like
> 
>   for disk in $CDROMS $PARTITIONS
>   do
> 
> 


Heiko

Re: [Devil-linux-develop] [PATCH] To fix mount issue with mounting bootcd.iso off disk/usb drive

[Friedrich L. <fl...@fl...>]

*Sorry if you have received 2 copies of this mail*
I had to stop the sending process to make some last minute changes.

Tim Tait wrote on 08.05.2004 21:15 MET:

> Friedrich Lobenstock wrote:
> 
>> Tim Tait wrote on 08.05.2004 19:13 MET:
>>
>>> Friedrich Lobenstock wrote:
>>>
>>>>
>>>> Why don't you change the original mount and add the options 
>>>> "ro,noatime"
>>>> there?
>>>>
>>>> Just tried it with my local CD-Rom drive to make sure iso9660 
>>>> accepts the
>>>> "noatime" option.
>>>>
>>>> # mount /dev/cdrom /mnt/ -o ro,noatime # mount | grep /mnt /dev/sr0 
>>>> on /mnt
>>>> type iso9660 (ro,noatime)
>>>
>>>
>>>
>>> I thought that mounting it read only from the beginning would break 
>>> the live-update feature, no?
>>
>>
>>
>> Then your patch should also break it too, shouldn't it? 
> 
> No, because I remount it read-only after the update check is finished - 
> ie it will have already copied bootcd.iso.new (if it exists) to 
> bootcd.iso, and thus is ready to continue with the normal mount 
> sequence, which only requires read access.

Ok, were did I have my head.


>>> Tho I suppose if is bootcd.iso.new is detected, it could be remounted 
>>> rw at
>>> that time.
>>
>> Can you please test that and add the necessary remount's there?
> 
> I can, though it will mean 2 remounts - one to make it rw for update, 
> then another to make ro when update is done.

The current situation is using the minimal amount of mount commands.
But for sake of cleaner implementation, meaning in the normal case we don't need 
to run two mounts, I think the other way is better. Updating is a special case 
anyway and were you have to take special meassures anyway. How about factoring 
out the update stuff into another file to make the mount_cdrom more readable again?

BTW while looking at the update code I think we should also rename/move the 
/mnt/DEVIL-LINUX file so we know from which version to which we are updating. 
Heiko!?

> 
> Should the new diff be done against the original, or the last patched 
> version?  I don't see that change in CVS yet.

The webinterface seems to be up to date, so you can always get the file from 
there: 
http://cvs.sourceforge.net/viewcvs.py/devil-linux/build/config/etc/initrd/mount_cdrom


While you are at it, the "if" from before "# generate list of cdroms from devfs" 
down should be moved down and merged with your addition of "if [ "$3" != 
"silent" ]". Is shorter and makes the file more readable.


And while your are using the "ro,noatime" mount option why not merge the two 
for-loops into one? Like:

   for disk in $CDROMS $PARTITIONS
   do


-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] [PATCH] To fix mount issue with mounting bootcd.iso off disk/usb drive

[Friedrich L. <fl...@fl...>]

Tim Tait wrote on 08.05.2004 21:15 MET:

> Friedrich Lobenstock wrote:
> 
>> Tim Tait wrote on 08.05.2004 19:13 MET:
>>
>>> Friedrich Lobenstock wrote:
>>>
>>>>
>>>> Why don't you change the original mount and add the options 
>>>> "ro,noatime"
>>>> there?
>>>>
>>>> Just tried it with my local CD-Rom drive to make sure iso9660 
>>>> accepts the
>>>> "noatime" option.
>>>>
>>>> # mount /dev/cdrom /mnt/ -o ro,noatime # mount | grep /mnt /dev/sr0 
>>>> on /mnt
>>>> type iso9660 (ro,noatime)
>>>
>>>
>>>
>>> I thought that mounting it read only from the beginning would break 
>>> the live-update feature, no?
>>
>>
>>
>> Then your patch should also break it too, shouldn't it? 
> 
> No, because I remount it read-only after the update check is finished - 
> ie it will have already copied bootcd.iso.new (if it exists) to 
> bootcd.iso, and thus is ready to continue with the normal mount 
> sequence, which only requires read access.

Ok, were did I have my head.


>>> Tho I suppose if is bootcd.iso.new is detected, it could be remounted 
>>> rw at
>>> that time.
>>
>> Can you please test that and add the necessary remount's there?
> 
> I can, though it will mean 2 remounts - one to make it rw for update, 
> then another to make ro when update is done.

The current situation is using the minimal amount of mount commands.
But for sake of cleaner implementation, meaning in the normal case we don't need 
to run two mounts, I think the other way is better. Updating is a special case 
anyway and were you have to take special meassures anyway. How about factoring 
out the update stuff into another file to make the mount_cdrom more readable again?

BTW while looking at the update code I think we should also rename/move the 
/mnt/DEVIL-LINUX file so we know from which version to which we are updating. 
Heiko!?

> 
> Should the new diff be done against the original, or the last patched 
> version?  I don't see that change in CVS yet.

The webinterface seems to be up to date, so you can always get the file from 
there: 
http://cvs.sourceforge.net/viewcvs.py/devil-linux/build/config/etc/initrd/mount_cdrom


While you are at it, your addition of "if [ "$3" != "silent" ]" should rather be 
merged by moving the "if" before "# generate list of cdroms from devfs" down.

And while your are using the "rw,noatime" mount option why not merge the two 
for-loops into one? Like

   for disk in $CDROMS $PARTITIONS
   do


-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] [PATCH] To fix mount issue with mounting bootcd.iso off disk/usb drive

[Tim T. <t....@co...>]

Friedrich Lobenstock wrote:

> Tim Tait wrote on 08.05.2004 19:13 MET:
>
>> Friedrich Lobenstock wrote:
>>
>>>
>>> Why don't you change the original mount and add the options 
>>> "ro,noatime"
>>> there?
>>>
>>> Just tried it with my local CD-Rom drive to make sure iso9660 
>>> accepts the
>>> "noatime" option.
>>>
>>> # mount /dev/cdrom /mnt/ -o ro,noatime # mount | grep /mnt /dev/sr0 
>>> on /mnt
>>> type iso9660 (ro,noatime)
>>
>>
>> I thought that mounting it read only from the beginning would break 
>> the live-update feature, no?
>
>
> Then your patch should also break it too, shouldn't it? 

No, because I remount it read-only after the update check is finished - 
ie it will have already copied bootcd.iso.new (if it exists) to 
bootcd.iso, and thus is ready to continue with the normal mount 
sequence, which only requires read access.

>
>
>> Tho I suppose if is bootcd.iso.new is detected, it could be remounted 
>> rw at
>> that time.
>
>
> Can you please test that and add the necessary remount's there?

I can, though it will mean 2 remounts - one to make it rw for update, 
then another to make ro when update is done.

Should the new diff be done against the original, or the last patched 
version?  I don't see that change in CVS yet.

Tim

Re: [Devil-linux-develop] [PATCH] To fix mount issue with mounting bootcd.iso off disk/usb drive

[Friedrich L. <fl...@fl...>]

Tim Tait wrote on 08.05.2004 19:13 MET:

> Friedrich Lobenstock wrote:
> 
>> 
>> Why don't you change the original mount and add the options "ro,noatime"
>> there?
>> 
>> Just tried it with my local CD-Rom drive to make sure iso9660 accepts the
>> "noatime" option.
>> 
>> # mount /dev/cdrom /mnt/ -o ro,noatime # mount | grep /mnt /dev/sr0 on /mnt
>> type iso9660 (ro,noatime)
> 
> I thought that mounting it read only from the beginning would break the 
> live-update feature, no?

Then your patch should also break it too, shouldn't it?

> Tho I suppose if is bootcd.iso.new is detected, it could be remounted rw at
> that time.

Can you please test that and add the necessary remount's there?


-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] [PATCH] To fix mount issue with mounting bootcd.iso off disk/usb drive

[Tim T. <t....@co...>]

Friedrich Lobenstock wrote:

> Tim Tait wrote on 07.05.2004 04:48 MET:
>
>>
>> The current scripts have an issue when mounting the bootcd.iso file 
>> off of a disk device. The disk is initially mounted under the initrd 
>> /mnt point with rw access. When the /mnt/bootcd.iso is mounted 
>> followed by the chroot, it then makes it it impossible to unmount the 
>> disk device (now on /initrd/mnt) in pre_init, leaving it mounted 
>> read/write. I couldn't find a perfect solution to this, but I think 
>> these changes help-
>>
>> mount_cdrom:
>> Remount the disk device ro before mounting the iso. Sure to reduce 
>> filesystem corruption during reboots, less security issues. I also 
>> added a output line to say what version of the bootcd.iso it found - 
>> useful if there was more than one to find - hate to upgrade/downgrade 
>> unintentionally..
>> [...]
>> ------------------------------------------------------------------------
>>
>> --- ./config/etc/initrd/mount_cdrom.old    2004-05-02 
>> 13:33:41.000000000 +0200
>> +++ ./config/etc/initrd/mount_cdrom    2004-05-02 22:36:28.000000000 
>> +0200
>> @@ -26,6 +26,12 @@
>>  CDROM_SCSI=`find /dev/scsi/ -name "cd*" 2> /dev/null`
>>  CDROMS="$CDROM_IDE $CDROM_SCSI"
>>  
>> +if [ "$3" != "silent" ]; then
>> +    $GREEN
>> +    echo "Search list: $CDROMS"
>> +    $NORMAL
>> +fi
>> +
>>  for disk in $CDROMS
>>  do
>>      echo checking $disk
>> @@ -78,13 +84,20 @@
>>                  $NORMAL
>>              fi
>>              if [ -e /mnt/bootcd.iso ] ; then
>> +                # since this could be flash disk, lets make read-only.
>> +                # Should not write to this mount anymore anyway. It
>> +                # is attempted to umount it in pre_init but will fail
>> +                # because bootcd.iso is still mounted inside it.
>> +                # RO will make it less painfull.
>> +                mount -o remount,ro,noatime $disk 2> /dev/null
>
>
> Why don't you change the original mount and add the options 
> "ro,noatime" there?
>
> Just tried it with my local CD-Rom drive to make sure iso9660 accepts 
> the "noatime" option.
>
> # mount /dev/cdrom /mnt/ -o ro,noatime
> # mount | grep /mnt
> /dev/sr0 on /mnt type iso9660 (ro,noatime)

I thought that mounting it read only from the beginning would break the 
live-update feature, no?  Tho I suppose if is bootcd.iso.new is 
detected, it could be remounted rw at that time.

Tim

Re: [Devil-linux-develop] [PATCH] To fix mount issue with mounting bootcd.iso off disk/usb drive

[Friedrich L. <fl...@fl...>]

Tim Tait wrote on 07.05.2004 04:48 MET:

> 
> The current scripts have an issue when mounting the bootcd.iso file off 
> of a disk device. The disk is initially mounted under the initrd /mnt 
> point with rw access. When the /mnt/bootcd.iso is mounted followed by 
> the chroot, it then makes it it impossible to unmount the disk device 
> (now on /initrd/mnt) in pre_init, leaving it mounted read/write. I 
> couldn't find a perfect solution to this, but I think these changes help-
> 
> mount_cdrom:
> Remount the disk device ro before mounting the iso. Sure to reduce 
> filesystem corruption during reboots, less security issues. I also added 
> a output line to say what version of the bootcd.iso it found - useful if 
> there was more than one to find - hate to upgrade/downgrade 
> unintentionally..
> [...]
> ------------------------------------------------------------------------
> 
> --- ./config/etc/initrd/mount_cdrom.old	2004-05-02 13:33:41.000000000 +0200
> +++ ./config/etc/initrd/mount_cdrom	2004-05-02 22:36:28.000000000 +0200
> @@ -26,6 +26,12 @@
>  CDROM_SCSI=`find /dev/scsi/ -name "cd*" 2> /dev/null`
>  CDROMS="$CDROM_IDE $CDROM_SCSI"
>  
> +if [ "$3" != "silent" ]; then
> +	$GREEN
> +	echo "Search list: $CDROMS"
> +	$NORMAL
> +fi
> +
>  for disk in $CDROMS
>  do
>  	echo checking $disk
> @@ -78,13 +84,20 @@
>  				$NORMAL
>  			fi
>  			if [ -e /mnt/bootcd.iso ] ; then
> +				# since this could be flash disk, lets make read-only.
> +				# Should not write to this mount anymore anyway. It
> +				# is attempted to umount it in pre_init but will fail
> +				# because bootcd.iso is still mounted inside it.
> +				# RO will make it less painfull.
> +				mount -o remount,ro,noatime $disk 2> /dev/null

Why don't you change the original mount and add the options "ro,noatime" there?

Just tried it with my local CD-Rom drive to make sure iso9660 accepts the "noatime" option.

# mount /dev/cdrom /mnt/ -o ro,noatime
# mount | grep /mnt
/dev/sr0 on /mnt type iso9660 (ro,noatime)


-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

[Devil-linux-develop] [PATCH] boot option docu

[Roland P. <pa...@ta...>]

Hi,
here is the patch for the documentation
cu
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

Re: [Devil-linux-develop] [PATCH] To fix mount issue with mounting bootcd.iso off disk/usb drive

[Heiko Z. <he...@zu...>]

Tim Tait wrote:
> 
> The current scripts have an issue when mounting the bootcd.iso file off 
> of a disk device. The disk is initially mounted under the initrd /mnt 
> point with rw access. When the /mnt/bootcd.iso is mounted followed by 
> the chroot, it then makes it it impossible to unmount the disk device 
> (now on /initrd/mnt) in pre_init, leaving it mounted read/write. I 
> couldn't find a perfect solution to this, but I think these changes help-
> 
> mount_cdrom:
> Remount the disk device ro before mounting the iso. Sure to reduce 
> filesystem corruption during reboots, less security issues. I also added 
> a output line to say what version of the bootcd.iso it found - useful if 
> there was more than one to find - hate to upgrade/downgrade 
> unintentionally..
> 
> pre_init:
> perform "umount -l" (as in lazy)  rather than plain umount. If an actual 
> umount can't be done, this will prevent further access to that mount, 
> making it appear unmounted. When/if it is not busy, it will be 
> unmounted. Probably as good as it can get with current boot method?

DONE

Heiko

[Devil-linux-develop] [ devil-linux-Feature Requests-950241 ] disable most zoneinfo via menuconfig

[SourceForge.net <no...@so...>]

Feature Requests item #950241, was opened at 2004-05-07 20:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410646&aid=950241&group_id=34096

Category: Build System
Group: None
Status: Open
Priority: 5
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Nobody/Anonymous (nobody)
Summary: disable most zoneinfo via menuconfig

Initial Comment:
add option to menuconfig to disable most
files/directories in /usr/share/zoneinfo , to reduce
size of media

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410646&aid=950241&group_id=34096

[Devil-linux-develop] [ devil-linux-Feature Requests-950240 ] disable most terminfos via menuconfig

[SourceForge.net <no...@so...>]

Feature Requests item #950240, was opened at 2004-05-07 20:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410646&aid=950240&group_id=34096

Category: Build System
Group: None
Status: Open
Priority: 5
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Nobody/Anonymous (nobody)
Summary: disable most terminfos via menuconfig

Initial Comment:
enable option to menuconfig to only include minimum
amount of the terminfo files/directories, to reduce the
size of the system

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410646&aid=950240&group_id=34096

Re: [Devil-linux-develop] DVDRip - distributed load

[<hzu...@ra...>]

On 05/07/2004 03:35:13 PM Peter Frischknecht wrote:
>I have been using DVDrip (http://www.exit1.org/dvdrip/index.cipp) to
>backup my DVDs for about 8 months now.  It is a great application.
>One of its great features is the ability to distribute the processing
>load to different machines (like distcc).  They call it "cluster mode".
>The only requirement for the DL box is to have transcode installed
>(http://www.theorie.physik.uni-goettingen.de/~ostreich/transcode/)
>
>I am a serious user of DL, deploying it on business networks, but a lot
>of us use it at home as well.  At home, our DL boxes are laughing at the
>pathetic workload they have routing traffic for a few peope.  Why not
>use those extra idle cycles for something useful!?!  Heiko first
>mentioned the DVD ripping idea, and I must admit that, at first, I
>thought it was silly.  Now I think that we should have the tools in DL
>for DVDripping (condoning legal backups ONLY).
>
>I have some expertise in configuring the apps to make it work, but 2
>problems come to my mind:
>1 - Interest: anybody else out there likes this idea?
>2 - Licensing: what is the legal status of DECSS?
>
>As always, comments, feedback is welcome.

I definitely have interest and have to admit, "vobcopy" is already part of
DL. ;-)

Heiko

[Devil-linux-develop] DVDRip - distributed load

[Peter F. <pe...@em...>]

I have been using DVDrip (http://www.exit1.org/dvdrip/index.cipp) to
backup my DVDs for about 8 months now.  It is a great application.
One of its great features is the ability to distribute the processing
load to different machines (like distcc).  They call it "cluster mode". 
The only requirement for the DL box is to have transcode installed
(http://www.theorie.physik.uni-goettingen.de/~ostreich/transcode/)

I am a serious user of DL, deploying it on business networks, but a lot
of us use it at home as well.  At home, our DL boxes are laughing at the
pathetic workload they have routing traffic for a few peope.  Why not
use those extra idle cycles for something useful!?!  Heiko first
mentioned the DVD ripping idea, and I must admit that, at first, I
thought it was silly.  Now I think that we should have the tools in DL
for DVDripping (condoning legal backups ONLY).

I have some expertise in configuring the apps to make it work, but 2 
problems come to my mind:
1 - Interest: anybody else out there likes this idea?
2 - Licensing: what is the legal status of DECSS?

As always, comments, feedback is welcome.

-- 
Peter Frischknecht <pe...@em...>
Empowering Solutions, Inc.

Re: [Devil-linux-develop] Xbox Gateway

[Bruce S. <bw...@ar...>]

> There is a neat piece of software that allows "System-link" gameplay
> over the Internet. 
> Multi-link is what happens when several XBoxes are on the same network
> to play a multi-player game.  This has NOTHING to do with the "MS Live"
> service.  It is just an easy way for friends to play multi-player games.
> 
> The software can be found here:
> http://www.xboxgw.com/
> 
> I have made myself a DL image with the XBoxgw software in it, and it
> works like a charm.
> 
> HUGE DOWNside: NOT available as source, only as a pre-compiled i386
> binary.
> 
> This is a perfect example of a "neat" add-on that could go as an
> "unsupported" app.
> 
> What d'ya say?

What's the license?

If has to be freely distributable for us to even consider including it.

 - BS

[Devil-linux-develop] Xbox Gateway

[Peter F. <pe...@em...>]

Yes...I like playing games on occasion.

There is a neat piece of software that allows "System-link" gameplay
over the Internet. 
Multi-link is what happens when several XBoxes are on the same network
to play a multi-player game.  This has NOTHING to do with the "MS Live"
service.  It is just an easy way for friends to play multi-player games.

The software can be found here:
http://www.xboxgw.com/

I have made myself a DL image with the XBoxgw software in it, and it
works like a charm.

HUGE DOWNside: NOT available as source, only as a pre-compiled i386
binary.

This is a perfect example of a "neat" add-on that could go as an
"unsupported" app.

What d'ya say?

-- 
Peter Frischknecht <pe...@em...>
Empowering Solutions, Inc.

Re: [Devil-linux-develop] Shorewall update to V2

[Martin G. <sou...@gl...>]

On May 3, 2004 12:13, Bruce Smith wrote:
> > Attached is a minor patch to update Shorewall firewall to V2.0.1
> >
> > Please also download shorewall 2.0.1 from one of the listed sites in
> > http://www.shorewall.net/download.htm
>
> All done.
>
> > and yes, I have tested it with the latest CVS.
>
> Good, because I haven't (yet).  :-)
>
>  - BS

Thank you kind sir...

Martin

[Devil-linux-develop] [PATCH] To fix mount issue with mounting bootcd.iso off disk/usb drive

[Tim T. <t....@co...>]

The current scripts have an issue when mounting the bootcd.iso file off 
of a disk device. The disk is initially mounted under the initrd /mnt 
point with rw access. When the /mnt/bootcd.iso is mounted followed by 
the chroot, it then makes it it impossible to unmount the disk device 
(now on /initrd/mnt) in pre_init, leaving it mounted read/write. I 
couldn't find a perfect solution to this, but I think these changes help-

mount_cdrom:
Remount the disk device ro before mounting the iso. Sure to reduce 
filesystem corruption during reboots, less security issues. I also added 
a output line to say what version of the bootcd.iso it found - useful if 
there was more than one to find - hate to upgrade/downgrade 
unintentionally..

pre_init:
perform "umount -l" (as in lazy)  rather than plain umount. If an actual 
umount can't be done, this will prevent further access to that mount, 
making it appear unmounted. When/if it is not busy, it will be 
unmounted. Probably as good as it can get with current boot method?

Tim

Re: [Devil-linux-develop] Build pause for new grsecurity parameter?

[Heiko Z. <he...@zu...>]

hzu...@ra... wrote:
> On 05/04/2004 12:16:47 PM Tim Tait wrote:
> 
>>hzu...@ra... wrote:
>>
>>On 05/02/2004 07:43:36 PM Tim Tait wrote:
>>
>>
>>grsecurity stops to ask if I want the kernel stack base randomized -  of
>>course, since I have the logs on, I don't see this, it just looks like
>>the build is hung. Am I misconfigured or is everyone getting this?
>>
>>
>>That is not supposed to happen.
>>
>>Is the parameter missing in the file / build / scripts / config /
>>config_grsecurity  ?
>>Are you using Kernel 2.6 ?
>>
>>Heiko
>>
>>
>>
>>
>>Still happens in a fresh build (got CVS updates from last night, with
>>new sources). A cvs diff now shows no changes in cvs.
>>
> 
>>From the grsecurity log:
> 
>>     Randomize kernel stack base (CONFIG_GRKERNSEC_PAX_RANDKSTACK)
>>[N/y/?] (NEW)
>>
>>There is no matching line in the config file. But I confess that stuff
>>gets me really confused - in seems in some cases the config file
>>doesn't need to have an answer, and in some it does???
>>
>>Anyway, adding it in before the CONFIG_GRKERNSEC_PAX_RANDUSTACK line
>>fixed it.
> 
> 
> I'm starting a new compile from scratch, to see if I can reproduce the
> problem.

I was able to reproduce the problem, it's strange that it didn't come up 
on my existing sytem.

The fix is in CVS.

Heiko

Re: [Devil-linux-develop] Errors in cyrus-impad build

[<hzu...@ra...>]

On 05/04/2004 01:03:03 PM Tim Tait wrote:
>Looks like it expects to have 'ed' in the toolbox... but it doesn't
>seems to break the build... should I worry?
>
>Tiim
>
>---------- from cyrus-impad log ------------
>
>make[4]: Leaving directory
>`/data/build/tmp/cyrus-imapd-2.2.3/perl/sieve/lib'
>echo '/^# DO NOT DELETE THIS LINE/+2,$d' >eddep
>echo 'w' >>eddep
>cp Makefile Makefile.bak
>ed -s Makefile < eddep
>/bin/sh: ed: command not found
>make[3]: *** [depend] Error 127
>make[3]: Leaving directory
>`/data/build/tmp/cyrus-imapd-2.2.3/perl/sieve'
>make[2]: *** [depend] Error 1
>make[2]: Leaving directory `/data/build/tmp/cyrus-imapd-2.2.3/perl'
>make[1]: *** [depend] Error 1
>make[1]: Leaving directory `/data/build/tmp/cyrus-imapd-2.2.3'
>make[1]: Entering directory `/data/build/tmp/cyrus-imapd-2.2.3'
>### Making all in /data/build/tmp/cyrus-imapd-2.2.3/man

Nobody complained about cyrus-imapd not working, doest it work anyway?

Otherwise I would suggest that we add ed to fix it.

Heiko

Re: [Devil-linux-develop] Build pause for new grsecurity parameter?

[<hzu...@ra...>]

On 05/04/2004 12:16:47 PM Tim Tait wrote:
>hzu...@ra... wrote:
>
>On 05/02/2004 07:43:36 PM Tim Tait wrote:
>
>
>grsecurity stops to ask if I want the kernel stack base randomized -  =
of
>course, since I have the logs on, I don't see this, it just looks like=

>the build is hung. Am I misconfigured or is everyone getting this?
>
>
>That is not supposed to happen.
>
>Is the parameter missing in the file / build / scripts / config /
>config_grsecurity  ?
>Are you using Kernel 2.6 ?
>
>Heiko
>
>
>
>
>Still happens in a fresh build (got CVS updates from last night, with
>new sources). A cvs diff now shows no changes in cvs.
>
>From the grsecurity log:
>=A0=A0=A0=A0 Randomize kernel stack base (CONFIG_GRKERNSEC_PAX_RANDKST=
ACK)
>[N/y/?] (NEW)
>
>There is no matching line in the config file. But I confess that stuff=

>gets me really confused - in seems in some cases the config file
>doesn't need to have an answer, and in some it does???
>
>Anyway, adding it in before the CONFIG_GRKERNSEC_PAX_RANDUSTACK line
>fixed it.

I'm starting a new compile from scratch, to see if I can reproduce the
problem.

Heiko
=

[Devil-linux-develop] Errors in cyrus-impad build

[Tim T. <t....@co...>]

Looks like it expects to have 'ed' in the toolbox... but it doesn't 
seems to break the build... should I worry?

Tiim

---------- from cyrus-impad log ------------

make[4]: Leaving directory 
`/data/build/tmp/cyrus-imapd-2.2.3/perl/sieve/lib'
echo '/^# DO NOT DELETE THIS LINE/+2,$d' >eddep
echo 'w' >>eddep
cp Makefile Makefile.bak
ed -s Makefile < eddep
/bin/sh: ed: command not found
make[3]: *** [depend] Error 127
make[3]: Leaving directory `/data/build/tmp/cyrus-imapd-2.2.3/perl/sieve'
make[2]: *** [depend] Error 1
make[2]: Leaving directory `/data/build/tmp/cyrus-imapd-2.2.3/perl'
make[1]: *** [depend] Error 1
make[1]: Leaving directory `/data/build/tmp/cyrus-imapd-2.2.3'
make[1]: Entering directory `/data/build/tmp/cyrus-imapd-2.2.3'
### Making all in /data/build/tmp/cyrus-imapd-2.2.3/man

Re: [Devil-linux-develop] Build pause for new grsecurity parameter?

[Tim T. <t....@co...>]

hzu...@ra... wrote:

>On 05/02/2004 07:43:36 PM Tim Tait wrote:
>  
>
>>grsecurity stops to ask if I want the kernel stack base randomized -  of
>>course, since I have the logs on, I don't see this, it just looks like
>>the build is hung. Am I misconfigured or is everyone getting this?
>>    
>>
>
>That is not supposed to happen.
>
>Is the parameter missing in the file / build / scripts / config /
>config_grsecurity  ?
>Are you using Kernel 2.6 ?
>
>Heiko
>
>  
>

Still happens in a fresh build (got CVS updates from last night, with 
new sources). A cvs diff now shows no changes in cvs.

 From the grsecurity log:
     Randomize kernel stack base (CONFIG_GRKERNSEC_PAX_RANDKSTACK) 
[N/y/?] (NEW)

There is no matching line in the config file. But I confess that stuff 
gets me really confused - in seems in some cases the config file doesn't 
need to have an answer, and in some it does???

Anyway, adding it in before the CONFIG_GRKERNSEC_PAX_RANDUSTACK line 
fixed it.

Tim

Tim

Re: [Devil-linux-develop] Adding mount points to /var?

[Bruce S. <bw...@ar...>]

> > > So I can put 'tmp' on a different vg than 'imap' and both will be
> > > auto-mounted with the current DL setup?
> > >     
> > Only the stuff in the devil-linux VG will be automounted.
> >   
> (Light dawns) So for any lv in the devil-linux vg, a mount point of
> the same name as the lv will be created in /var, and then mounted?

Almost.  That's true, except for those LV's specially listed as
exceptions in the file /etc/sysconfig/lvmtab .

The default exceptions in /etc/sysconfig/lvmtab are "swap", "/opt" 
and "/home".  You can modify lvmtab to fit your needs.  (same basic
format as /etc/fstab).

 - BS

Re: [Devil-linux-develop] Adding mount points to /var?

[Diego T. <dt...@co...>]

On Tue, May 04, 2004 at 10:40:24AM -0400, Heiko Zuerker wrote:
> > about this, where are the directories created for the mounting points?
> > only on the make iso stage?
> 
> They are created dynamically on runtime, when "/etc/init.d/mountfs start"
> is executed, which happens in /etc/init.d./boot.d

so mountfs gets them from /etc/fstab, and creates all the mount points that doesn't exist? amazing :)

-- 
-- gnupg keyfingerprint -- 48AF 5BF9 8F54 2966 64CC  2327 7CD0 DD91 B09D 5799
-- Use of a keyboard or mouse may be linked to serious injuries or disorders.
Diego Torres - dtorres at anthalia dot org - Madrid / España