Hello Charles,
> >> > -The VERBOSE setting isn't as verbose as it should be, a lot of
> >> > messages are not shown (everything before the tmpfs system creation?)
> >>
> >> Are you setting VERBOSE in leaf.cfg, or in linuxrc?
> >>
> > VERBOSE=1 in leaf.cfg
>
> Well, if you can tell me how to pr
Charles,
> >
> > We did some testing with the new linuxrc and the increased # of
> > inodes in the Bering-uClibc initial minix ramdisk.
> >
> > A few things we noticed so far:
> > -loading packages from a CD isn't possible (probably because of the
> > FILESYSTEMS variable problem)
>
> Yes, I d
Eric Spakman wrote:
Hello Charles,
We did some testing with the new linuxrc and the increased # of
inodes in the Bering-uClibc initial minix ramdisk.
A few things we noticed so far:
-loading packages from a CD isn't possible (probably because of the
FILESYSTEMS variable problem)
Yes, I don't t
Eric Spakman wrote:
> -The VERBOSE setting isn't as verbose as it should be, a lot of
> messages are not shown (everything before the tmpfs system creation?)
Are you setting VERBOSE in leaf.cfg, or in linuxrc?
VERBOSE=1 in leaf.cfg
Well, if you can tell me how to predictivly determine that VERB
Hello Charles,
We did some testing with the new linuxrc and the increased # of
inodes in the Bering-uClibc initial minix ramdisk.
A few things we noticed so far:
-loading packages from a CD isn't possible (probably because of the
FILESYSTEMS variable problem)
-The VERBOSE setting isn't as verbo
[EMAIL PROTECTED] wrote:
The problems I've seen so far:
1) The creation of the FILESYSTEMS variable doesn't seem to be
'sticking'. The variable is getting properly created, but it doesn't
seem to be visible outside the routine that creates it:
# set -x
# cat /proc/filesystems |
> while read
Hello Charles,
> I have verified a new backup of initrd with 'normal' bering
produces the
> working version of initrd (1376 inodes).
>
> Could someone running Bering-uClibc test this using the following procedure:
>
> - Backup initrd.lrp on a 'live' Bering-uClibc system
> - Copy initrd.lrp to
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 395
Charles Steinkuehler wrote:
...however, I strongly suspect the ramdisk has run out of inodes.
Why this is happening with Bering-uClibc and not with 'regular' Bering,
is unclear, unless the initial ramdisk images were formatted differently
(it's possible to specify the number of inodes when runn
Eric Spakman wrote:
Charles,
Very odd. Is this with Bering or Bering-uClibc? How big is your
initial ramdisk?
With Bering-uClibc, initial ramdisk 1.5 Mbyte.
It looks like the initial ramdisk might be filling up
prior to getting the new tmpfs root created and running pivot_root
(possibly bec
Hi Charles,
> You might also try setting VERBOSE=1 in leaf.cfg and see if you get any
> more useful information.
>
Tried that, it doesn't add much more info, only messages about
pivoting, generating default dirs and generating tmp and var dirs.
This is rather strange, because I don't see mess
Charles,
>
> Very odd. Is this with Bering or Bering-uClibc? How big is your
> initial ramdisk?
With Bering-uClibc, initial ramdisk 1.5 Mbyte.
> It looks like the initial ramdisk might be filling up
> prior to getting the new tmpfs root created and running pivot_root
> (possibly because I'
Eric Spakman wrote:
Hello Charles,
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.
I tried the new linuxrc, but it doesn't work for me
Errors:
..
Hello Charles,
> 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.
>
I tried the new linuxrc, but it doesn't work for me
Errors:
...
LINUXRC
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
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 yo
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.
>
>>
>
>Becau
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
At 10:29 16.03.2004 -0600, Charles Steinkuehler wrote:
>Erich Titl wrote:
>
>
>>>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 lr
Erich Titl wrote:
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
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 som
Eric Spakman wrote:
Charles,
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 t
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 an
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, t
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
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
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 co
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-platfor
* 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 -
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,
* Charles Steinkuehler <[EMAIL PROTECTED]> [2004:03:13:19:12:31-0600] scribed:
> re-sent (forgot to include the list)
>
> Michael D Schleif wrote:
> >* Charles Steinkuehler <[EMAIL PROTECTED]>
> >[2004:03:13:16:47:02-0600] scribed:
> >
> >
> >>I propose making log_mnt a new leaf.cfg variable (cou
re-sent (forgot to include the list)
Michael D Schleif wrote:
* Charles Steinkuehler <[EMAIL PROTECTED]> [2004:03:13:16:47:02-0600] scribed:
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
* Charles Steinkuehler <[EMAIL PROTECTED]> [2004:03:13:16:47:02-0600] scribed:
> 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[:filesy
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 oth
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 (
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.
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 l
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.
D
38 matches
Mail list logo
