Re: [leaf-devel] New linuxrc mods ready for testing
Charles At 16:31 18.03.2004 -0600, Charles Steinkuehler wrote: .. Any idea why the FILESYSTEMS variable is behaving oddly? Just a shot in the dark, define FILESYSTEMS on top of the loop. HTH Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Eric At 09:35 17.03.2004 +, Eric Spakman wrote: Erich, Charles, Also note that I don't believe the POSIXness scripts (lrpkg included) are available currently in the initial ramdisk, but are in root.lrp. True, but then why. It certainly is not that big. Because they were never needed in initrd. For Bering-uClibc we want to keep it that way. The reason for this is that we want to keep the config/package scripts separated so it can easely be replaced by some other config/package system like f.e. apkg. We have put the lrpkg and lrcfg scripts in a separate config.lrp package for this reason. IMHO, if you want to be able to replace it easily you should use it wherever the sme functionality is used. cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Eric At 19:18 17.03.2004, Eric Spakman wrote: Hello Erich, .. That doesn't really change the case and makes things even more inflexible. You need some code to uncompress and install the package manager. It doesn't matter if you use a compressed fs or a tar.gz (lrp) file. The problem is that you need code that loads the package from the right (mounted) filesystem and uncompress it. An other drawback of this approach is that you cannot backup the package manager with the standard tools. .. Me too, but it are only a few lines of code to create a minimal system where init can take over. I see no difference in having a few redundant lines or doing basicly the same with other code. I think it's better to not rely on a different package to reach the part where init takes over. I am just afraid that these few lines do a minimalistic approach (see the broken current code), whereas a fully blown package manager might do better. So the sequence could be: boot install whatever is needed to run init run init let the package manager load the other packages Eric Spakman I get your point. cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
At 17:53 17.03.2004, you wrote: Hello Erich, ... That's only partial possible, at least a few few packages need to be installed in the linuxrc script (etc.lrp, config.lrp, ..) to make it work. So there needs to be some code in the initrd package to install those packages. Well I believe the only thing really needed is lrpkg.lrp or whatever suffix is used. It does _not_ really have to be a .lrp file (much like initrd.lrp). From that very moment everything could be loaded by the package manager, whichever is used. so basically the sequence could be: boot load initrd load the package manager load whatever is needed to run init (using the package manager) run init (which might load other stuff using the package manager) If you want to have the flexibility to change the config/package system by having it in a seperate package, you need some code in initrd.lrp to load that config package. I just hate redundant code, even in scripts. cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Eric Spakman wrote: Hello Charles, Files like mount.boot, boot.fstype and /dev/boot are removed (which is great btw), but they are used in some of the lrcfg/lrpkg scripts AFAIK. So maybe some of these scripts needs some changes too. I don't think the Dachstein package backup scripts use these anymore (part of the upgrade to supporting multiple devices), so Bering shouldn't be either. I have verified I can properly backup packages, but I have not made an exhaustive search for anything that might reference the 'boot' files. There are some traces of boot.fstype and /dev/boot left in POSIXness.linuxrouter (both Dachstein-1.0.2 and Bering). I just looked at these, and the use of the boot= kernel command line setting, boot.fstype and /dev/boot are not real significant in POSIXNESS.linuxrouter. The boot= setting and boot.fstype are used as 'defaults' for populating the backdisk file when manually installing a package after the system has come up (note is is also possible to optionally specify a backup device when manually installing a package). The /dev/boot symlink and boot.fstype are used in the mount.boot procedure (uncalled by any other POSIXness or lrcfg script), and by the mount.back procedure (as a fallback if the newer backdisk file is not present). There are at least three ways to deal with this: 1) Remove the references to these files from POSIXNESS.linuxrouter, replacing them with references to the newer files (and likely get rid of the mount.boot procedure entirely). 2) Create the files in linuxrc, using the first PKGPATH= device (instead of the depricated boot= device). 3) Ignore the problem with manually adding packages once the system is up and running. :) Any preference? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Eric Spakman wrote: Charles, snip There are at least three ways to deal with this: 1) Remove the references to these files from POSIXNESS.linuxrouter, replacing them with references to the newer files (and likely get rid of the mount.boot procedure entirely). 2) Create the files in linuxrc, using the first PKGPATH= device (instead of the depricated boot= device). 3) Ignore the problem with manually adding packages once the system is up and running. :) Any preference? My preference would be option 1, although option 3 also appeals to me :) :) OK, then it's not a linuxrc problem. Should I go ahead and make the mods to POSIXness? If so, are the Bering versions checked in to CVS anywhere (I've got the Dachstein versions in CVS). Are there any differences between the Bering and the Bering-uClibc versions of POSIXness? P.s. Any progression with the rewrite of linuxrc, need any help? It looks like the linuxrc rewrite is pretty much done. I've made a minor tweak or two since the version I posted (removed /bin/bash from initrd.lrp to prevent conflicts when adding a real bash shell, and removed the code that leaves the CD-ROM mounted and creates the /lib/modules symlink from linuxrc). The biggest help at this point would be for others to test the new linuxrc, make sure it works for them, and think about any other features that might need to be added to linuxrc or leaf.cfg. Further work that looks like it needs to get done, but isn't really directly related to just linuxrc: - Merge Dachstein and Bering modutils code. Bang commands from Dachstein are necessary (IMHO) for running cleanly off a CD-ROM, and I like the 'find' feature of the Bering modutils (as long as it's limited to searching only the current directory and below, rather than the whole root filesystem). Of course, the Bering development team might have a different view of this, and want to keep the current modutils. - Add the /bin/bash - /bin/ash symlink to root, or (optionally) create it in /linuxrc (or sometime prior to loading add-on packages, if package loading gets moved to init). - Determine a mechanism for loading packages at init time, rather than in /linuxrc. There are a lot of options here, including adding a couple new rcS.d scripts, creating an entirely new runlevel (maybe rcL.d?) that runs before rcS.d, etc. I'm not sure there's a universal solution to this problem...since LEAF is based on a ramdisk that is populated at boot time, there's a natural conflict between wanting to mount additional devices 'normally' (ie /etc/fstab or similar), and needing to have some directories mounted prior to package installation, since we're rebuilding the entire filesystem every time we boot. I think the package installation issue needs some discussion between the developers to determine what would work well, and the first two issues are minor enough to be ignored until one of the Bering branches switches to the new linuxrc code (I can work around these issues pretty easily for now, and convert to the 'real' Bering way of doing things once there's an official release). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Charles At 06:11 16.03.2004 -0600, Charles Steinkuehler wrote: Eric Spakman wrote: Hello Charles, Files like mount.boot, boot.fstype and /dev/boot are removed (which is great btw), but they are used in some of the lrcfg/lrpkg scripts AFAIK. So maybe some of these scripts needs some changes too. I don't think the Dachstein package backup scripts use these anymore (part of the upgrade to supporting multiple devices), so Bering shouldn't be either. I have verified I can properly backup packages, but I have not made an exhaustive search for anything that might reference the 'boot' files. There are some traces of boot.fstype and /dev/boot left in POSIXness.linuxrouter (both Dachstein-1.0.2 and Bering). I just looked at these, and the use of the boot= kernel command line setting, boot.fstype and /dev/boot are not real significant in POSIXNESS.linuxrouter. The boot= setting and boot.fstype are used as 'defaults' for populating the backdisk file when manually installing a package after the system has come up (note is is also possible to optionally specify a backup device when manually installing a package). The /dev/boot symlink and boot.fstype are used in the mount.boot procedure (uncalled by any other POSIXness or lrcfg script), and by the mount.back procedure (as a fallback if the newer backdisk file is not present). There are at least three ways to deal with this: 1) Remove the references to these files from POSIXNESS.linuxrouter, replacing them with references to the newer files (and likely get rid of the mount.boot procedure entirely). 2) Create the files in linuxrc, using the first PKGPATH= device (instead of the depricated boot= device). Sounds reasonable, it certainly is better than boot= 3) Ignore the problem with manually adding packages once the system is up and running. :) or insert backuptype NONE if not specified at lrpkg -i I looked into linuxrc myself and found that it does not use lrpkg to install packages. It is not a big deal but to me this is not extremely consistent. cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Erich Titl wrote: snip 3) Ignore the problem with manually adding packages once the system is up and running. :) or insert backuptype NONE if not specified at lrpkg -i I looked into linuxrc myself and found that it does not use lrpkg to install packages. It is not a big deal but to me this is not extremely consistent. linuxrc doesn't use lrpkg -i to install packages because at boot time the PKGPATH variable is used to install packages from potentially multiple places. The intent of lrpkg -i is to allow manual installation of a specific *.lrp package file once the system is running. While I could be convinced extending lrpkg to deal with the PKGPATH setting would be worthwhile, I think this would mainly be of benifit if package loading is broken into two (or more) steps, with only a limited number of core packages being installed by linuxrc, with the rest being installed by an /etc/init.d script. Also note that I don't believe the POSIXness scripts (lrpkg included) are available currently in the initial ramdisk, but are in root.lrp. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
At 10:29 16.03.2004 -0600, Charles Steinkuehler wrote: Erich Titl wrote: snip 3) Ignore the problem with manually adding packages once the system is up and running. :) or insert backuptype NONE if not specified at lrpkg -i I looked into linuxrc myself and found that it does not use lrpkg to install packages. It is not a big deal but to me this is not extremely consistent. linuxrc doesn't use lrpkg -i to install packages because at boot time the PKGPATH variable is used to install packages from potentially multiple places. It still iterates through all potential directories, this can be done with lrpkg just the same. The intent of lrpkg -i is to allow manual installation of a specific *.lrp package file once the system is running. While I could be convinced extending lrpkg to deal with the PKGPATH setting would be worthwhile, I think this would mainly be of benifit if package loading is broken into two (or more) steps, with only a limited number of core packages being installed by linuxrc, with the rest being installed by an /etc/init.d script. I don't think lrpkg needs to be touched (well, not for that reason) ... gunzip -c $mnt/$f.lrp /dev/null if [ $? -eq 0 ]; then echo -n $dev gunzip -c $mnt/$f.lrp | qt busybox tar -x might as well be lrpkg -i $mnt/$f #Update installed packages file [ $fnd -eq 0 ] echo $f$PFX/packages backdisk=$f=-t $t $dev fnd=1 else echo -n $dev(cpt!) fnd=1 fi ... Also note that I don't believe the POSIXness scripts (lrpkg included) are available currently in the initial ramdisk, but are in root.lrp. True, but then why. It certainly is not that big. cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
On Tue, 2004-03-16 at 07:36, Charles Steinkuehler wrote: The biggest help at this point would be for others to test the new linuxrc, make sure it works for them, and think about any other features that might need to be added to linuxrc or leaf.cfg. Charles, Did you look at David's apkg? I think it has many of the features you're looking at now. http://leaf-project.org/devel/ddouthitt/packages/apkg.lrp http://leaf-project.org/devel/ddouthitt/packages/apkg.lrp.txt -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Charles Steinkuehler wrote: I finally have a working update to the /linuxrc script for bering. I was playing with the lrcfg* files at the end of February. Part of the exercise was to understand how the LEAF backup and configuration menu system works. By the time I finished I had a cross-platform package install and menu configuration system working. I still had to intercept the backup portion of the scripts to make it work completely. I had three remaining tasks. One of them was diving into linuxrc. I thought I read that bzip2 was more efficient at compressing files than gzip. So I looked at implementing that compression scheme. A new package ending of .tbz or .lef would be required so that the scripts and users could tell the two apart and act accordingly. lrpkg.sh has some notes about bzip2. Where I was hampered was in how to pull this off in linuxrc. For example, I don't know if you can have a bzip2 ramdisk. If not root.lrp, then the script could support packages that used bzip2. I thought I saw that busybox supported bzip2 but to what extent I do not know. The other issue for linuxrc was a scp backup choice. I am happy with scping my packages to my Linux PC. There I would create a new ISO with the full packages. I use CD-R/W disks for this purpose. It's a drag to sneaker net the floppy. So I modified the lrcfg menuing system. If sshd is sensed, then an entry for a scp backup target is placed in the Set Backup Destination menu. linuxrc would have to read scp in the device target and know to use the boot device or assume cdrom. Since I have most of the lrcfg files modified are these ideas implementable in the linuxrc file that you are working on? The files are in http://leaf.sourceforge.net/devel/dr_kludge/ for now. I was still debating how I wanted to put them in CVS but I thought I'd pipe up at this point to see if they were of interest in the linuxrc discussions. The 00readme.txt file is attached below. Greg Ident: 00readme.txt Greg Morgan 3/14/2004. This set of files was extracted from a DCD 1.02 CD. The modified files propose several new features. One a developer or perhaps a user could perform cross- platform configuration. Variables in lrcfg.spec control where the the backup menu is running from. Please see this file to configure the lrcfg system. Lots of comments should help. lrpkg.sh was used to install root.lrp but the rest of the sytem is not ready to try backing up root.lrp or some other package. The other is a new package extension of either .tbz or .lef. The question is can bzip2 be introduced in such a way that both existing .lrp formats and bzip2 compression formats be supported. Can a ramdisk be bzip2 or does the kernel presume gzip? Finally, a new backup target has been introduced. If sshd is detected, an scp backup target is created. This allows a user with a cd image of their ISO on a Linux file system to more easily create a new CD-R/W. The scp target allows them to leave the newly configured package in /tmp/scp. The user would then go to the full Linux PC and scp the files from the /tmp/scp directory into the ISO directory. Both mkisofs and cdrecord commands would be issued or shell scripted to created a new CD-R or CD-R/W. To use this on a Linux platform perform these steps. 1.) The scripts had to presume some hardcoded place. The choice was ~/lrcfg mkdir ~/lrcfg # Copy all the scripts into this directory. 2.) The scripts make an additional presumption that all of the other lrcfg scripts are in the current directory. You will need a supporting directory structure like this mkdir lrcfg mkdir lrcfg/tmp mkdir lrcfg/var mkdir lrcfg/var/lib mkdir lrcfg/var/lib/lrpkg mkdir lrcfg/var/lib/lrpkg/mnt mkdir lrcfg/proc mkdir lrcfg/etc mkdir lrcfg/mnt 3.) You will also need to perform these steps to have some supporting data. Replace firewallname with the real name of your firewall. You will also have to have the sshd.lrp package installed on your firewall and have generated your keys with sshkey.lrp. cd lrcfg scp [EMAIL PROTECTED]:/var/lib/lrpkg/* ./var/lib/lrpkg scp [EMAIL PROTECTED]:/etc/* ./etc scp [EMAIL PROTECTED]:/proc/* ./proc Note the scp of proc was an idea that did not work. Presently the scripts presume a DCD cmdline file. You will have to create this from the /proc filesystem on your live LEAF box. 3.) To play with the system use these commands to run the menu. cd ~/lrcfg # Edit the lrcfg.spec to your tastes. Make sure LRROOT and # LREDIT are set correctly. ./lrcfg 4.) To install a package, place the desired package in your ~/lrcfg/mnt directory. Then use lrpkg.sh to install it as you would normally. Use ./lrpkg.sh to see the options. cp root.lrp ~/lrcfg/mnt cd ~/lrcfg/mnt ../lrpkg.sh -i root.lrp File Name Description and Status --
RE: [leaf-devel] New linuxrc mods ready for testing
Charles wrote: Hmm...I like this idea, but why make a symlink from /var/log rather than simply mounting your persistent log device directly to /var/log, instead of the tmpfs ramdisk? Because I wanted to allow to use a directory on an existing partition instead of necessarily requiring a complete partition. Cheers Alex --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [leaf-devel] New linuxrc mods ready for testing
Eric wrote: Although I do like the idea of mounting a persistent device for things like logs I see a few serious drawbacks. LEAF is designed, with reason, to run from ram and don't has all the tools/scripts for checking various filesystems. I use a journaling filesystem, of course (ext3). If the filesystem gets corrupted, I'll upload an fsck, I can live with that. What I cannot live with is lost logfiles after a reset performed by a user because Internet access didn't work. Which means log.lrp doesn't help me. Although there are solutions by choosing ext2/3, jfs, vfat and the like and providing special fs-check packages, an option to select a persistant device in the base linuxrc without an user knowing the drawbacks can give strange problems. I basically read here lets not provide this feature, users are too stupid to use it correctly. I'd rather write a recommendation in the doc that journalling filesystems should be used. Note that people who have space to save their logs usually also have space for jfs.o and ext3.o There is always the option to use a loghost to store the LEAF logfiles. And this seems a better option to me. Sure, if you have a loghost available... Cheers Alex --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
re: mounting various partitions in /linuxrc I have been thinking more about this issue, and have come to the following conclusion (mantra). Repeat after me: ... linuxrc IS NOT init ... ... linuxrc IS NOT init ... ... linuxrc IS NOT init ... The sole purpose of linuxrc (IMHO) is to build enough of a filesystem so init can run and bring up the system proper. linuxrc is not the place to be mounting additional filesystems that are not required for init to run. Any non-volitle partitions can be mounted through the normal init and rcS.d methods. Note that I am unaware of a single distribution other than Bering that mounts /tmp and /var/log as seperate partitions prior to launching init (although obviously it's possible to mount most anything with the disto of your choice once init is up and running). Even Dachstein mounted /var/log via /etc/init.d scripts (ramdisk.mk and ramdisk.pkg). IMHO, while we're sort of changing everything, what should really happen is the following: - The creation and mounting of /var/log and /tmp should be removed from linuxrc and migrated to general purpose init script(s). - Installation of all but the very core packages (root.lrp, etc.lrp, ???) should be delegated to another new init script that executes once the full filesystem is mounted (avoiding the problem I had with Dachstein of trying to populate a newly mounted ramdisk with data that really belongs in a normal LRP file which was getting installed by linuxrc). - There should still be some procedural 'hooks' added to allow leaf.cfg to run code after the root ramdisk is created. While I don't have a need for this functionality at the moment, it's not hard to add and won't take a lot of space. - Support should be added for either *nix or DOS style EOLs in leaf.cfg Thoughts? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
At 16:36 14.03.2004 -0600, you wrote: re: mounting various partitions in /linuxrc I have been thinking more about this issue, and have come to the following conclusion (mantra). Repeat after me: ... linuxrc IS NOT init ... ... linuxrc IS NOT init ... ... linuxrc IS NOT init ... true, true true The sole purpose of linuxrc (IMHO) is to build enough of a filesystem so init can run and bring up the system proper. linuxrc is not the place to be mounting additional filesystems that are not required for init to run. Any non-volitle partitions can be mounted through the normal init and rcS.d methods. Note that I am unaware of a single distribution other than Bering that mounts /tmp and /var/log as seperate partitions prior to launching init (although obviously it's possible to mount most anything with the disto of your choice once init is up and running). normally something like mountall() is done during init using /etc/fstab .. - The creation and mounting of /var/log and /tmp should be removed from linuxrc and migrated to general purpose init script(s). - Installation of all but the very core packages (root.lrp, etc.lrp, ???) should be delegated to another new init script that executes once the full filesystem is mounted (avoiding the problem I had with Dachstein of trying to populate a newly mounted ramdisk with data that really belongs in a normal LRP file which was getting installed by linuxrc). I did something similar in rload.lrp, which loaded packages from the net. It required only the very basic packages and net access. rload is running at init level 2, then switches to init level 3 to reinitialise the symbolic links in the init packages and finalise the init process. cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Hello Charles , List Sorry to get involved so late ( After a change of job, much time is consumed elsewhere :( ) Thanks for cleaning up /rewriting linuxrc. Some suggestions. 1. wouldn't it be a good Idea to include a dos2unix command in source() , people do edit with other os as linux. Dos2unix could be included in busybox or realized with a sed pipe. 2. Why not get the mount against all filesystems part out. normally you know from what filesystem your packages load. this could be set as a default value in the cfg script . As far as I remember the repeated mounting of devices was one of the reasons for problems with DOC . 3. don't use fix values for log tmp and systemsize, but calculate a decent division if the values aren't defined by variables- Regards Eric Wolzak member of the bering crew On 12 Mar 2004 at 17:36, Charles Steinkuehler wrote: I finally have a working update to the /linuxrc script for bering. To avoid any nasty spacetab confusion, and to avoid sending attachments to the list, I've made a small tarball with the new script, an example leaf.cfg file, and some documentation avaialble as a tarball at the following URL: http://lrp.steinkuehler.net/files/kernels/misc-stuff/linuxrc-2004-03-12.tgz There are a few items on the 'TODO' list, mainly because I have not discussed them on-list, and I don't want to change any bering-specific functionality that's actually desired. TODO rest of messages deleted --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [leaf-devel] New linuxrc mods ready for testing
Charles, I finally have a working update to the /linuxrc script for bering. It seems to be time to try and submit my patch again It allows to use a log_mnt parameter to mount /var/log/ on a persistent partition that is not lost reboots. I use this to save the logs on a DoM. Could you take a look at the support requests 657859 and 658015? You can find the info and patch there. Direct links: http://sourceforge.net/tracker/index.php?func=detailaid=657859group_id=137 51atid=213751 http://sourceforge.net/tracker/index.php?func=detailaid=658015group_id=137 51atid=213751 Cheers Alex --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Alex Rhomberg wrote: Charles, I finally have a working update to the /linuxrc script for bering. It seems to be time to try and submit my patch again It allows to use a log_mnt parameter to mount /var/log/ on a persistent partition that is not lost reboots. I use this to save the logs on a DoM. Could you take a look at the support requests 657859 and 658015? You can find the info and patch there. Direct links: http://sourceforge.net/tracker/index.php?func=detailaid=657859group_id=137 51atid=213751 http://sourceforge.net/tracker/index.php?func=detailaid=658015group_id=137 51atid=213751 Hmm...I like this idea, but why make a symlink from /var/log rather than simply mounting your persistent log device directly to /var/log, instead of the tmpfs ramdisk? I propose making log_mnt a new leaf.cfg variable (could also come in via the kernel command line). Rather than the format you used, however, I would like to use the existing PKGPATH/LEAFCFG format (dev[:filesystem). If the log_mnt variable is set, linuxrc would mount the log_mnt device directly to /var/log, and skip making the tmpfs ramdisk. If log_mnt is unset or null, the current behavior would result. Does this seem acceptable to everyone? Also, any reason (or drawback) to handling /tmp exactly the same way? I realize /tmp doesn't need to be persistent, but someone might want to be able to mount /tmp on something other than a ramdisk, and I might be able to save some space (or at least not grow /linuxrc much) if I fold togheter the /var/log and /tmp processing. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Eric Spakman wrote: Charles, A few comments (sorry, oflist again...). You create the /dev entries before you create the tmpfs. I don't think it's a problem but now all those entries get copied (qt cp -dpR $ii /tmpfs) to the new root (pivot_root) instead of created after the new root is set (the latter case seems more save and faster). I have to populate /dev before creating the tmpfs so I can mount the LEAFCFG device. I'm open to skipping the copying of /dev and rebuilding it on the new device. The only drawback I can think of is if someone uses the new leaf.cfg functionality to add an unsupported device, we will have just lost their newly created device file... Maybe /var/lock/subsys should also be added in the list of directories that are created. Some new programs seems to expect that directory. We should look through this list anyway, maybe it isn't fully up-to-date anymore. I'm open to any changes you want to make in this regard...I'm just mucking around with /linuxrc. :) Files like mount.boot, boot.fstype and /dev/boot are removed (which is great btw), but they are used in some of the lrcfg/lrpkg scripts AFAIK. So maybe some of these scripts needs some changes too. I don't think the Dachstein package backup scripts use these anymore (part of the upgrade to supporting multiple devices), so Bering shouldn't be either. I have verified I can properly backup packages, but I have not made an exhaustive search for anything that might reference the 'boot' files. Is anyone using the multi and revrs options? I always found it very confusing. Can we do without? I know you added that part in Eigerstein ;) While I don't know of anyone heavily using this feature, I think it really does solve some potential problems with folks who are loading packages from multiple locations. I mainly see the search order being useful for upgrading packages on local systems w/o having to burn a new CD (or otherwise change a potentially read-only boot media). I mainly see the normal 'forward, load multiple copies' setting and the 'reverse, load the first copy and stop' being useful. The other two settings exist because it was easy to support once I had the two flavors I thought might be needed. I think if we had more folks running off of CD or other having multiple package repositories, you'd see this used more. Should we still support Query /proc/cmdline to see if we want to ask for a second disk, is anyone really using this? (maybe I'm going too far :) I think there are some folks still using this. I think the leaf.cfg way should be the preferred and only way to configure things. No need to muck with syslinux.cfg anymore. Agreed, in general, although syslinux.cfg is still the only place to set LEAFCFG= so it points to the proper device. I think support for parsing the other kernel command line variables (LRP=, PKGPATH=, etc) should be left in at least for a while, so we don't break everyone's existing systems. Bering-uClibc doesn't use tinylogin anymore (it's integrated in the latest busybox now), nut we can easely remove that part ofcourse. The same is almost true for POSIXness, we try to rewrite the few parts that are left to standalone scripts. Most of POSIXness is available in busybox now. About TODO: Remove the code that keeps the CD-ROM mounted and makes a symlink to /lib/modules on the CD? This doesn't look necessary, as the current modutils automounts the CD anyway, if present. and Modify modutils to look in /lib/modules or cdrom/lib/modules (as appropriate) for modules, instead of through the *ENTIRE* filesystem? The modutils used in Bering-uClibc doesn't automount CD anymore and I think the upcoming? version of Bering wont't use it anymore too. The new modutils script: # Loop over every line in /etc/modules. echo 'Loading modules: ' grep ^[a-z0-9A-Z] /etc/modules | while read module args do insmod $module $args 2/dev/null lsmod | grep -n -q ^$module || \ logger modutils module $module could not be loaded done I of course am partial to the Dachstein modutils scripts, which support 'bang' commands (lines starting with !) to mount devices, change directories, etc. I do, however, like the use of 'find' to locate the module files (used in the current bering modutils I'm referring to above), but I don't think the system should just assume if there's a cd present that you want to load modules from it, or that it can safely install the first matching module that a search of the entire filesystem with find happens to turn up. Any modutils issues, however, are completely seperate from any /linuxrc mods (with the possible exception of leaving the CD mounted). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system
Re: [leaf-devel] New linuxrc mods ready for testing
Eric Wolzak wrote: Hello Charles , List Sorry to get involved so late ( After a change of job, much time is consumed elsewhere :( ) Thanks for cleaning up /rewriting linuxrc. Some suggestions. 1. wouldn't it be a good Idea to include a dos2unix command in source() , people do edit with other os as linux. Dos2unix could be included in busybox or realized with a sed pipe. Good suggestion. I've been trying to eliminate sed as a requirement for linuxrc, but there may be a way to handle the EOL issue w/o actual file conversion (likely by adding CR to IFS prior to sourcing the file, but I need to test this). 2. Why not get the mount against all filesystems part out. normally you know from what filesystem your packages load. this could be set as a default value in the cfg script . As far as I remember the repeated mounting of devices was one of the reasons for problems with DOC . As long as the filesystem specification is optional, I think we'll need to try mounting against all existing filesystems. Note that currently no device is ever mounted more than once (without being unmounted first), so my updated linuxrc should work with folks using DOC (needs to be tested). 3. don't use fix values for log tmp and systemsize, but calculate a decent division if the values aren't defined by variables- Sounds like a decent idea...anyone got any suggestions for how to divide up memory? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
* Charles Steinkuehler [EMAIL PROTECTED] [2004:03:13:16:47:02-0600] scribed: snip / I propose making log_mnt a new leaf.cfg variable (could also come in via the kernel command line). Rather than the format you used, however, I would like to use the existing PKGPATH/LEAFCFG format (dev[:filesystem). If the log_mnt variable is set, linuxrc would mount the log_mnt device directly to /var/log, and skip making the tmpfs ramdisk. If log_mnt is unset or null, the current behavior would result. Does this seem acceptable to everyone? Also, any reason (or drawback) to handling /tmp exactly the same way? I realize /tmp doesn't need to be persistent, but someone might want to be able to mount /tmp on something other than a ramdisk, and I might be able to save some space (or at least not grow /linuxrc much) if I fold togheter the /var/log and /tmp processing. Need it be hard coded? Could it be variable-ized, such that I can specify some arbitrary directory (e.g., /home) during initial configuration? That way, other future exceptions are handled in stride. Notice that I ask this out of ignorance of what is required to accomplish this ; What do you think? -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: [leaf-devel] New linuxrc mods ready for testing
re-sent (forgot to include the list) Michael D Schleif wrote: * Charles Steinkuehler [EMAIL PROTECTED] [2004:03:13:16:47:02-0600] scribed: snip / I propose making log_mnt a new leaf.cfg variable (could also come in via the kernel command line). Rather than the format you used, however, I would like to use the existing PKGPATH/LEAFCFG format (dev[:filesystem). If the log_mnt variable is set, linuxrc would mount the log_mnt device directly to /var/log, and skip making the tmpfs ramdisk. If log_mnt is unset or null, the current behavior would result. Does this seem acceptable to everyone? Also, any reason (or drawback) to handling /tmp exactly the same way? I realize /tmp doesn't need to be persistent, but someone might want to be able to mount /tmp on something other than a ramdisk, and I might be able to save some space (or at least not grow /linuxrc much) if I fold togheter the /var/log and /tmp processing. Need it be hard coded? Could it be variable-ized, such that I can specify some arbitrary directory (e.g., /home) during initial configuration? That way, other future exceptions are handled in stride. Notice that I ask this out of ignorance of what is required to accomplish this ; Um...if it refers to where the log files reside, currently it *IS* hard-coded. We're discussing making the log partition not be hard-coded, and I'm wondering if we should go ahead and make /tmp work the same way. If I'm mis-understanding your question, please clarify. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Michael D Schleif wrote: `not be hard-coded' is _exactly_ what I am referring to. I don't know how you are doing this; but, I can see value in having some arbitrary director(y|ies) persist across reboots -- in some applications. So, unless I am misunderstanding the previous dialog on this matter, I am suggesting that, instead of limiting this to `/var/log' and `/tmp', you may consider creating this so that an admin can also do same with `/home', or some other arbitrary directory. Am I making any sense? OK, I'm understanding what you're after now. I probably wouldn't have thought about this, but it should be fairly easy to support, espeically if I fold /tmp into the processing for /var/log (although the syntax might be a bit cryptic...probably a shell variable to indicate which directories are to be mounted). Note that it's probably better to mount things like /home using the normal init scripts, rather than linuxrc. To increase the overall flexability of the new leaf.cfg file, it would probably be good to make some 'hooks' (shell functions) that get called once the root filesystem is mounted, and maybe before after extracting packages. That would allow a custom leaf.cfg file to do things like mount arbitrary filesystems wherever desired in the heirearchy (ie: /usr, /var, or even /etc, if desired). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
* Charles Steinkuehler [EMAIL PROTECTED] [2004:03:13:21:51:06-0600] scribed: Michael D Schleif wrote: `not be hard-coded' is _exactly_ what I am referring to. I don't know how you are doing this; but, I can see value in having some arbitrary director(y|ies) persist across reboots -- in some applications. So, unless I am misunderstanding the previous dialog on this matter, I am suggesting that, instead of limiting this to `/var/log' and `/tmp', you may consider creating this so that an admin can also do same with `/home', or some other arbitrary directory. Am I making any sense? OK, I'm understanding what you're after now. I probably wouldn't have thought about this, but it should be fairly easy to support, espeically if I fold /tmp into the processing for /var/log (although the syntax might be a bit cryptic...probably a shell variable to indicate which directories are to be mounted). Note that it's probably better to mount things like /home using the normal init scripts, rather than linuxrc. NOTE: I do not -- at this moment -- have a real application for this. Needing some example directory, /home is the first non-system directory that came to mind, and that also made some sense in this context. To increase the overall flexability of the new leaf.cfg file, it would probably be good to make some 'hooks' (shell functions) that get called once the root filesystem is mounted, and maybe before after extracting packages. That would allow a custom leaf.cfg file to do things like mount arbitrary filesystems wherever desired in the heirearchy (ie: /usr, /var, or even /etc, if desired). I believe that the additional work to accomplish this extends the flexibility of the overall system, which adds value. -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
