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 administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
