Re: slimmer busybox (was Re: build failure on ia32)
On Sun Sep 23, 2001 at 05:17:46PM -0400, Adam Di Carlo wrote: > Erik Andersen <[EMAIL PROTECTED]> writes: > > > I'll have one tomorrow. Since I lost my job on Friday, I've > > now got a bit more time on my hands for doing useful things, > > This never happened did it? It did last night. :) -Erik -- Erik B. Andersen email: [EMAIL PROTECTED], formerly of Lineo --This message was written using 73% post-consumer electrons-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failure on ia32
On Sun Sep 09, 2001 at 07:20:56PM -0800, Ethan Benson wrote: > > as soon as a busybox enters woody that doesn't include loads of > cruft things will be fine. I'll have one tomorrow. Since I lost my job on Friday, I've now got a bit more time on my hands for doing useful things, -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- PGP signature
Re: build failure on ia32
On Sun, Sep 09, 2001 at 11:05:24PM -0400, Daniel Jacobowitz wrote: > > Oh, OK, I'm completely wrong again :) So much for that. I wonder why > we're so much tighter on space, then. we still have a bit more cruft then other arches, but not that much really. we are again fine with a debloated busybox package ive been using locally. (using the Config.h patch i posted to the list). as soon as a busybox enters woody that doesn't include loads of cruft things will be fine. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: build failure on ia32
On Sun, Sep 09, 2001 at 03:45:48PM -0800, Ethan Benson wrote: > On Sun, Sep 09, 2001 at 03:13:14PM -0400, Daniel Jacobowitz wrote: > > > Hmm. Then something must be eating up all that space -- powerpc > > > binaries are not that much bigger then x86 binaries... Is library > > > reduction not working on powerpc? > > > > No, PowerPC needs extra tools. We have hfsutils and yaboot and quik; I > > guess these exceed the size of lilo and whatever else x86-only things > > we need, that's all. hfsutils is quite big. > > no i ditched hfsutils and yaboot a lng time ago. now > ybin/mkofboot/yabootconfig on the root disk are a tiny wrapper that > sets LD_LIBRARY_PATH and runs ybin from /target/... /usr/lib/yaboot > is a symlink to /target/usr/lib/yaboot > > that was the only way especially given the discusting bloat of current > yaboot binary. Oh, OK, I'm completely wrong again :) So much for that. I wonder why we're so much tighter on space, then. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failure on ia32
On Sun, Sep 09, 2001 at 03:13:14PM -0400, Daniel Jacobowitz wrote: > > Hmm. Then something must be eating up all that space -- powerpc > > binaries are not that much bigger then x86 binaries... Is library > > reduction not working on powerpc? > > No, PowerPC needs extra tools. We have hfsutils and yaboot and quik; I > guess these exceed the size of lilo and whatever else x86-only things > we need, that's all. hfsutils is quite big. no i ditched hfsutils and yaboot a lng time ago. now ybin/mkofboot/yabootconfig on the root disk are a tiny wrapper that sets LD_LIBRARY_PATH and runs ybin from /target/... /usr/lib/yaboot is a symlink to /target/usr/lib/yaboot that was the only way especially given the discusting bloat of current yaboot binary. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: build failure on ia32
[wow, can you tell I'm cleaning up a mail backlog?] On Tue, Sep 04, 2001 at 06:48:13PM -0600, Erik Andersen wrote: > On Tue Sep 04, 2001 at 04:18:42PM -0800, Ethan Benson wrote: > > > > yup but again i still need busybox reduction since none of this reiser > > stuff is on the powerpc disks, and i still have a problem with space > > there. > > Hmm. Then something must be eating up all that space -- powerpc > binaries are not that much bigger then x86 binaries... Is library > reduction not working on powerpc? No, PowerPC needs extra tools. We have hfsutils and yaboot and quik; I guess these exceed the size of lilo and whatever else x86-only things we need, that's all. hfsutils is quite big. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: busybox reduction on ppc (was Re: build failure on ia32)
#include Adam Di Carlo wrote on Wed Sep 05, 2001 um 04:30:30AM: > Have you tried mklibs.py ? Does it work? Does it do a better job? > > If so, we should enable it, possibly for all arches. Works flawless on i386. BTW: If nobody objects, I will enable the parted stuff in the udma100-ext3 variant as soon as the new parted-bf packages are in the archive. Gruss/Regards, Eduard. -- Bei MacOS X-Air ist das aber alles anders...;-) Sobald Du da eine Detail-Frage hast, wirst Du höflich aber bestimmt darauf hingewiesen, daß Du das Programm Terminal.app starten mußt und nach Herzenslust am BSD-Unterbau Deines Systems herumfeilen kannst. Und das Zeitungsfach an der Sitzlehne vor Dir ist über und über mit man-pages bestückt...;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failure on ia32
On Tue, Sep 04, 2001 at 06:48:13PM -0600, Erik Andersen wrote: > On Tue Sep 04, 2001 at 04:18:42PM -0800, Ethan Benson wrote: > > > > yup but again i still need busybox reduction since none of this reiser > > stuff is on the powerpc disks, and i still have a problem with space > > there. > > Hmm. Then something must be eating up all that space -- powerpc > binaries are not that much bigger then x86 binaries... Is library > reduction not working on powerpc? well libc is about 700k on the root disk, and several MB in /lib so lib reduction is at least partially working. someone suggested that mklibs.py may be more effective i wasn't paying much attention when that thing materialized though. my best wild guess is that libc 2.4.4 is somehow larger then 2.2.3 was. > > why again are we not using minix for the root floppy filesystem? its > > a bit more space efficient no? > > Well, since we have to mount the target fs, we already have to pay most of the > price for ext2 anyways (the size of mkfs.ext2 and the size of the kernel ext2 > code). So switching to minixfs isn't going to save us all that much. If we > are going to bother with changing filesystems, IMHO only cramfs really makes > sense. Redhat switched their installer to using cramfs and apparently gained > quite a lot of space that way... of course we have to have mke2fs, and ext2 in memory, but memory isn't the problem, its space available on the root disk. ive read minix has less overhead then ext2. cramfs requires 2.4 and i don't think debian is prepared to use that as a stable kernel. (though if woody drags on much longer 2.4 will end up being stable enough by release time...) -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: build failure on ia32
On Tue, 4 Sep 2001 18:48:13 -0600 "Erik Andersen" <[EMAIL PROTECTED]> wrote: > Well, since we have to mount the target fs, we already have to pay most of the > price for ext2 anyways (the size of mkfs.ext2 and the size of the kernel ext2 > code). So switching to minixfs isn't going to save us all that much. If we > are going to bother with changing filesystems, IMHO only cramfs really makes > sense. Redhat switched their installer to using cramfs and apparently gained > quite a lot of space that way... > Cramfs compresses each fs block individually, if compressing a big image or tarfile due to the fact that it is bigger than a fs block it will get better compression. An alternative to cramfs is to use romfs for the initrd, compresses it with gzip -9 and uncompress to tmpfs (or ramfs), but its a tradeoff, you would save disk space due to better compression and smaller kernel, and it would be faster from memmory, but it would also use a lot more memory which could be a critical factor. Personally i think cramfs is the best solution for lowmem installs and romfs.gz/tmpfs is best for normal installs. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failure on ia32
On Tue, Sep 04, 2001 at 05:47:48PM -0600, Erik Andersen wrote: > > [andersen@slag gcc-2.95-2.95.4.ds5]$ dpkg -l reiserfsprogs | tail -n1 > ii reiserfsprogs 3.x.0j-6 User-level tools for ReiserFS filesystems > [andersen@slag gcc-2.95-2.95.4.ds5]$ du -hc /sbin/mkreiserfs /sbin/reiserfsck >/sbin/resize_reiserfs > 92k /sbin/mkreiserfs > 184k/sbin/reiserfsck > 96k /sbin/resize_reiserfs > 372ktotal i am not avers to reiserfsck going away, since it is 1) about useless and 2) usually not required. (perhaps a way to make a good rescue disk with these utilities? hmm, must think about that) resize_reiserfsck? it can probably go away also. not a great need for that at install time. (at rescue time? again, probably not) not going to help the pps busybox bloat though. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failure on ia32
On Tue Sep 04, 2001 at 04:18:42PM -0800, Ethan Benson wrote: > > yup but again i still need busybox reduction since none of this reiser > stuff is on the powerpc disks, and i still have a problem with space > there. Hmm. Then something must be eating up all that space -- powerpc binaries are not that much bigger then x86 binaries... Is library reduction not working on powerpc? > besides just read -user archives for how useful reiserfsck really is, > you may as well symlink it to mkreiserfs. LOL! > > If we really need to include these, I can see a couple options. We could > > switch to cramfs (and the 2.4.x kernels it requires). Or we could switch > > making just a boot floppy which is then used to bootstrap a larger bf system > > image. > > that could be complicated... > > why again are we not using minix for the root floppy filesystem? its > a bit more space efficient no? Well, since we have to mount the target fs, we already have to pay most of the price for ext2 anyways (the size of mkfs.ext2 and the size of the kernel ext2 code). So switching to minixfs isn't going to save us all that much. If we are going to bother with changing filesystems, IMHO only cramfs really makes sense. Redhat switched their installer to using cramfs and apparently gained quite a lot of space that way... -Erik -- Erik B. Andersen email: [EMAIL PROTECTED], [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- PGP signature
Re: build failure on ia32
On Tue, Sep 04, 2001 at 05:47:48PM -0600, Erik Andersen wrote: > On Tue Sep 04, 2001 at 02:51:05PM -0800, Ethan Benson wrote: > > same thing on powerpc, though i can't explain powerpc i can explain > > i386. > > > > from SMALL_BASE_LIST_i386: > > > > sbin/mkreiserfs > > sbin/reiserfsck > > sbin/resize_reiserfs > > > > reiserfsck is something like 180k, resize_reiserfs is 80, and > > mkreiserfs is 80. all you need is mkfs, the fsck and resize should be > > removed. > > Yipe! And there we were picking nits from busybox... While the busybox > nits are probably valid, they are nothing compared to these. and i am doing all development on powerpc, there are no reiserfsprogs on powerpc, and thus they are not responsible for my headaches with the powerpc root disk. > [andersen@slag gcc-2.95-2.95.4.ds5]$ dpkg -l reiserfsprogs | tail -n1 > ii reiserfsprogs 3.x.0j-6 User-level tools for ReiserFS filesystems > [andersen@slag gcc-2.95-2.95.4.ds5]$ du -hc /sbin/mkreiserfs /sbin/reiserfsck >/sbin/resize_reiserfs > 92k /sbin/mkreiserfs > 184k/sbin/reiserfsck > 96k /sbin/resize_reiserfs > 372ktotal yup but again i still need busybox reduction since none of this reiser stuff is on the powerpc disks, and i still have a problem with space there. > It might be nice for people to have a rescue disk that has reiserfsck and > resize_reiserfs on it, but the boot floppies cannot be all things to all > people. exactly, there are much better alternatives for floppy based rescue systems, tom's root/boot for one. besides just read -user archives for how useful reiserfsck really is, you may as well symlink it to mkreiserfs. > If we really need to include these, I can see a couple options. We could > switch to cramfs (and the 2.4.x kernels it requires). Or we could switch > making just a boot floppy which is then used to bootstrap a larger bf system > image. that could be complicated... why again are we not using minix for the root floppy filesystem? its a bit more space efficient no? -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: build failure on ia32
On Tue Sep 04, 2001 at 02:51:05PM -0800, Ethan Benson wrote: > same thing on powerpc, though i can't explain powerpc i can explain > i386. > > from SMALL_BASE_LIST_i386: > > sbin/mkreiserfs > sbin/reiserfsck > sbin/resize_reiserfs > > reiserfsck is something like 180k, resize_reiserfs is 80, and > mkreiserfs is 80. all you need is mkfs, the fsck and resize should be > removed. Yipe! And there we were picking nits from busybox... While the busybox nits are probably valid, they are nothing compared to these. [andersen@slag gcc-2.95-2.95.4.ds5]$ dpkg -l reiserfsprogs | tail -n1 ii reiserfsprogs 3.x.0j-6 User-level tools for ReiserFS filesystems [andersen@slag gcc-2.95-2.95.4.ds5]$ du -hc /sbin/mkreiserfs /sbin/reiserfsck /sbin/resize_reiserfs 92k /sbin/mkreiserfs 184k/sbin/reiserfsck 96k /sbin/resize_reiserfs 372ktotal It might be nice for people to have a rescue disk that has reiserfsck and resize_reiserfs on it, but the boot floppies cannot be all things to all people. If we really need to include these, I can see a couple options. We could switch to cramfs (and the 2.4.x kernels it requires). Or we could switch making just a boot floppy which is then used to bootstrap a larger bf system image. -Erik -- Erik B. Andersen email: [EMAIL PROTECTED], [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- PGP signature
Re: build failure on ia32
On Tue, Sep 04, 2001 at 04:31:34PM -0400, Adam Di Carlo wrote: > Adam Di Carlo <[EMAIL PROTECTED]> writes: > > > Martin Schulze <[EMAIL PROTECTED]> writes: > > > > > Is this an error we will ignore today? > > > > Oh, we should fix it. Bump up the size. I wonder what is causing the > > bloat...? > > Sorry, wrong answer. We can't bump up the size. > > Somehow the root.bin is a lot bigger than it used to be. Even > compressed root.bin doesn't fit for root1200.bin. same thing on powerpc, though i can't explain powerpc i can explain i386. from SMALL_BASE_LIST_i386: sbin/mkreiserfs sbin/reiserfsck sbin/resize_reiserfs reiserfsck is something like 180k, resize_reiserfs is 80, and mkreiserfs is 80. all you need is mkfs, the fsck and resize should be removed. > gunzip -tvv root.bin > root.bin: > gunzip: root.bin: unexpected end of file > > I guess it's been broken for a while. this won't happen anymore since i added a check to see if the regular root image is larger then the floppy sized image that gets created (regardless of what size floppy). now the build will fail and whoever is building will have to deal with it or not release. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
