Re: [woody] modules for debian-installer (Re: the next step)
Taketoshi Sano wrote: > > * base tarball installer > > Is "base tarball" required for woody debian-installer ? > > I think if we can use network to retrieve packages, then > we can use the fresh archive itself, rather than old base > part of the archive which was frozen into tar-ball. Yes, we can certianly try to do this eventually. However, take a look at all the disgusting stuff basedisks.sh has to do in the boot-floppies to create a debian base system. A lot of packages need to be cleaned up before we can just dpkg -i `cat base-debs` and have it work. I'd prefer to go with something that already works here to save time on the first cut. > > * lilo setup > > I've also heard that the grub is better. Do you think (as the leader > of woody installer team) the lilo will be still the default kernel > loader for woody ? Maybe I shouldn't have written lilo there. I have no preference. Whoever writes this module for the first cut can decide. If you'd like it to be grub... -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the next step
Erik Andersen wrote: > Where do we upload things to? Can we get an archive area? I've had busybox > .debs ready for months now... And I've had bug #66604 open for months too. I need to track down some of the ftp maintainers and get this set up. I'll try to do that this weekend. > I've got a tiny little wget in busybox now -- I'd be happy to make > any changes wanted to handle the "http retriever" task. Maybe we can use it as the actual engine of the retreiver. The retreivers though have to all use a standard interface, and I think it makes sense to make a special module for the glue code. Does your wget support resumes? How about download progress reporting in an easily machine-parsable format? > For that "base tarball > installer" task, any reason not to use busybox tar, or is there somehow > more to it? It's clearly going to use busybox tar. But rather as with the http retreiver, there will probably be a certian amount of glue code that is best broken out into a module. Especially if it has to deal with configuring something or other in the unpacked base tarball. > Do you know what tools we do and do not want included? Not yet. Exactly what we'll need will be one of the later things to be worked out in the second month, when we're integrating everything. It seems likely that we will want to be able to build subsets of busybox as seperate modules. For example, if we're going to use the busybox wget as the engine of the http retreiver, then it needs to be on the boot floppy(ies), and we can't afford to put most of the rest of busybox on there. But we'd probably like to have busybox tar and gzip and probably a lot of other stuff available later on in the install process, so the retreiver will likely download a more complete busybox module with more stuff in it and overwrite the first one with it. Is this going to work for you? I understand it might add a bit of pain to the debian busybox build process. Oh, I should mention, I'm figuring just the following stuff will be on the boot floppy: - kernel (with ramdisk driver, tcp/ip support and nothing much else built in) - init & glue code - udpkg - udebconf - main menu support - network drivers - network configurator - http retreiver - whatever busybox programs the above needs Everything else gets downloaded. Whether this will really fit on 1 floppy is going to be interesting to find out.. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.2.17 now building for upload to potato
On Sat, Sep 30, 2000 at 12:05:46AM -0400, Adam Di Carlo wrote: > peter karlsson <[EMAIL PROTECTED]> writes: > > > Adam Di Carlo: > > > > > I'm now building for release boot-floppies 2.2.17. > > > > Does this include the translated boot floppies? > > No, no one has integrated that into the build process -- I guess it > was up to me (sigh) but I haven't had time. > > Any volunteers? What does it exactly involve ? Are the files in cvs repository ? > > -- > .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- [EMAIL PROTECTED] http://www.eric.ath.cx Please don't send proprietary format documents, I can't (and don't want to) open them. Appreciated are open-source formats like .txt or .rtf. Dvi, ps or tex files are welcome. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the next step
Joey Hess wrote: > > > * mini dpkg (mostly done) > * base tarball creator (don't have to write, we can just use > boot-floppies to make base tarballs for the first cut) > * mini debconf (with 1 frontend and a basic database) > * main menu generation code > * http retriever > * kernel build (with modules) > * NIC autodetection (limited) > * network configuration (manual method) > * disk partitioning and formatting > * base tarball installer > * lilo setup > * library reduction > * bootable image build system (take all necessary pieces and make a > bootable floppy image) > > > If we're agreed that this is a decent plan and that the target > installation system and method for the first cut are reasonable, we can > get started. I'm ready to write some code and I'd like to work on the > main menu generation module (I can do it on my own in a week, I think), > provide assistance with the mini debconf (but not write most of it; once > was enough), and help with the network configuration, and the lilo setup. > Let me know what you can work on so I can tell if this 2 month timeline is > wildly optimistic. > Im interested in looking at the partitioning and formating module. Im pretty comfortable working with busybox, so i could integrate mini-dpkg into it, but i guess this isnt a high priority as long as it works. Im a bit concerned about mini-debconf, its going to be a critical module, and is deceptively complex... Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: &mdash in boot-floppies/documentation
On Sat, Sep 30, 2000 at 02:44:12AM +0200, Van Buggenhaut wrote: > > According to Section 24 of HTML 4.01 specification, mdash is a valid entity. :) > I'm using Netscpae 4.75 with Potato and &mdash isn't resolved when i read HTML pages As I already said, Netscape is known to not support all those entities. That's very bad. :-( -- Misha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs access
I wasn't able to commit a file : yocto:~/boot-floppies/documentation/fr$ cvs -d $CVSROOT ci -m "added Sébastien Kalt" administrivia.sgml Cannot open /tmp/#cvs.lastdir.200, stopped at /usr/lib/cvs/contrib/commit_prep line 76, chunk 1. cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! What should I do ? -- [EMAIL PROTECTED] http://www.eric.ath.cx Please don't send proprietary format documents, I can't (and don't want to) open them. Appreciated are open-source formats like .txt or .rtf. Dvi, ps or tex files are welcome. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: &mdash in boot-floppies/documentation
On Sat, Sep 30, 2000 at 05:07:48PM +0400, Michael Sobolev wrote: > On Sat, Sep 30, 2000 at 02:44:12AM +0200, Van Buggenhaut wrote: > > > According to Section 24 of HTML 4.01 specification, mdash is a valid entity. :) > > I'm using Netscpae 4.75 with Potato and &mdash isn't resolved when i read HTML >pages > As I already said, Netscape is known to not support all those entities. That's very > bad. :-( Yes. This brings us back to what I mention at the beggining of this thread. Shoudn't the concerned file be adapted then ? > > -- > Misha > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- [EMAIL PROTECTED] http://www.eric.ath.cx Please don't send proprietary format documents, I can't (and don't want to) open them. Appreciated are open-source formats like .txt or .rtf. Dvi, ps or tex files are welcome. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the next step
On Sat Sep 30, 2000 at 12:51:22AM -0700, Joey Hess wrote: > Erik Andersen wrote: > > Where do we upload things to? Can we get an archive area? I've had busybox > > .debs ready for months now... > > And I've had bug #66604 open for months too. I need to track down some > of the ftp maintainers and get this set up. I'll try to do that this > weekend. k. I guess somebody just needs a kick. > > I've got a tiny little wget in busybox now -- I'd be happy to make > > any changes wanted to handle the "http retriever" task. > > Maybe we can use it as the actual engine of the retreiver. The > retreivers though have to all use a standard interface, and I think it > makes sense to make a special module for the glue code. I see. So more then just a retriever, you want something like the current boot floppies http-fetch -- complete with curses/slang status bar, and such. Got it. I can do this. I think we want an engine that works, and a pluggable front end gui, so for example, someone could later write a microwindows installer. I will just the curses/slang front end, and the underlying engine. > Does your wget support resumes? How about download progress reporting in > an easily machine-parsable format? rfc2616 doesn't mention resume -- I presume you mean HTTP 1.1 Range support. Yup it supports that. If the user specifies "-c" to continue, or if the server responds with a "206" Partial Content, it uses HTTP 1.1 Range support to grab the rest of the file. The only thing it doesn't do is it does not at all support "chunked" transfer-encoding, which technically violates rfc2616, 3.6.1 (though for my purposes it was just bloat -- reading slashdot was not the goal). > > For that "base tarball > > installer" task, any reason not to use busybox tar, or is there somehow > > more to it? > > It's clearly going to use busybox tar. But rather as with the http > retreiver, there will probably be a certian amount of glue code that is > best broken out into a module. Especially if it has to deal with configuring > something or other in the unpacked base tarball. k. Same deal as the http retriever -- the gui. I can do this too I suppose. I'm wondering though -- with the configuration stuff -- we can just rely on debconf for this, right? > > Do you know what tools we do and do not want included? > > Not yet. Exactly what we'll need will be one of the later things to be > worked out in the second month, when we're integrating everything. > > It seems likely that we will want to be able to build subsets of busybox > as seperate modules. For example, if we're going to use the busybox wget > as the engine of the http retreiver, then it needs to be on the boot > floppy(ies), and we can't afford to put most of the rest of busybox on > there. But we'd probably like to have busybox tar and gzip and probably a > lot of other stuff available later on in the install process, so the > retreiver will likely download a more complete busybox module with more > stuff in it and overwrite the first one with it. > > Is this going to work for you? I understand it might add a bit of pain > to the debian busybox build process. Not that big a deal really. I already compile busybox twice for the .deb. Adding a few more recompiles wouldn't be a problem. > Oh, I should mention, I'm figuring just the following stuff will be on > the boot floppy: > > - kernel (with ramdisk driver, tcp/ip support and nothing much else built in) > - init & glue code > - udpkg > - udebconf > - main menu support > - network drivers > - network configurator > - http retreiver > - whatever busybox programs the above needs > > Everything else gets downloaded. Whether this will really fit on 1 > floppy is going to be interesting to find out.. It will fit. Oh, yes. It will. ;-) I'm sure it can be done. Though we may need to switch to libc5 or uclibc or something more exotic (like the thin syscall wrapper libc thing on the RedHat installer). -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unable to make Russian PDFs still
Even using woody TeX (which has some serious problems, btw), I still get tons and tons of errors making install.ru.pdf ! LaTeX Error: Command \cyrt unavailable in encoding T2A. I don't understand how other people are producing this PDF properly. It's going to have to be disabled until someone can explain to me what to setup to get this file building. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Mark Blunier ] Re: Creation of 2.88MB Boot Images, Auto-Install Comments
> > 2. How does one create (under Linux) a 2.88MB boot image suitable > >for use with an El Torito format bootable CD? The last time > >I did this I used a Windows utility. I figure this might be > >answered if I found the answer to number 1... > This is what I've used. # Make a 2.88 Meg image echo "Making the 2.88 Meg image" dd if=/dev/zero of=$TMP/livecd/floppyimage bs=1024 count=2880 mformat -t 80 -h 2 -s 36 x: syslinux -s $TMP/livecd/floppyimage mount -o loop -t msdos $TMP/livecd/floppyimage $TMP/livecd/floppymount cp $SCRIPTS/linux $TMP/livecd/floppymount cp $TMP/livecd/syslinux.cfg $TMP/livecd/floppymount cp $SCRIPTS/syslinux.dpy $TMP/livecd/floppymount cp $SCRIPTS/syslinux.f1 $TMP/livecd/floppymount cp $SCRIPTS/syslinux.f2 $TMP/livecd/floppymount cp $TMP/livecd/rootfs.gz $TMP/livecd/floppymount umount $TMP/livecd/floppyimage cp $TMP/livecd/floppyimage $SRC/boot.image Mark -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/>
Re: 2.2.17 now building for upload to potato
Van Buggenhaut <[EMAIL PROTECTED]> writes: > On Sat, Sep 30, 2000 at 12:05:46AM -0400, Adam Di Carlo wrote: > > No, no one has integrated that into the build process -- I guess it > > was up to me (sigh) but I haven't had time. > > > > Any volunteers? > What does it exactly involve ? Read in the mail list archive, talk about i18n and LANG_CHOOSER. hack in the code. > Are the files in cvs repository ? Mostly. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody] modules for debian-installer (Re: the next step)
Joey Hess <[EMAIL PROTECTED]> writes: > Yes, we can certianly try to do this eventually. However, take a look at > all the disgusting stuff basedisks.sh has to do in the boot-floppies to > create a debian base system. A lot of packages need to be cleaned up > before we can just dpkg -i `cat base-debs` and have it work. I'd prefer > to go with something that already works here to save time on the first > cut. Yes. More care should be given to the base set. We need to file bugs now, and agressively, against them. A lot of people blame bf for delaying release but in fact we spent much of our time waiting for fixes in base or kernels. Anyhow, all that aside, I think the debian-installer effort should just grab this script. If all packages in base used debconf then it's going to be a lot easier to deal with -- and the basedisk.sh script can be stripped down a bit. Although it is an interesting idea if udpkg could handle this. > > I've also heard that the grub is better. Do you think (as the leader > > of woody installer team) the lilo will be still the default kernel > > loader for woody ? > > Maybe I shouldn't have written lilo there. I have no preference. Whoever > writes this module for the first cut can decide. If you'd like it to be > grub... I think grub would be better since it's xplatform. I have heard rumors that its not ready for prime time yet, though. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cvs access
Van Buggenhaut <[EMAIL PROTECTED]> writes: > I wasn't able to commit a file : > > yocto:~/boot-floppies/documentation/fr$ cvs -d $CVSROOT ci -m "added Sébastien Kalt" >administrivia.sgml > Cannot open /tmp/#cvs.lastdir.200, stopped at > /usr/lib/cvs/contrib/commit_prep line 76, chunk 1. Hmm, that dir was owned by me. I removed it. > cvs server: Pre-commit check failed > cvs [server aborted]: correct above errors first! > > What should I do ? Try again. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: &mdash in boot-floppies/documentation
Van Buggenhaut <[EMAIL PROTECTED]> writes: > On Sat, Sep 30, 2000 at 05:07:48PM +0400, Michael Sobolev wrote: > > On Sat, Sep 30, 2000 at 02:44:12AM +0200, Van Buggenhaut wrote: > > > > According to Section 24 of HTML 4.01 specification, mdash is a valid entity. :) > > > I'm using Netscpae 4.75 with Potato and &mdash isn't resolved when i read HTML >pages > > As I already said, Netscape is known to not support all those entities. That's >very > > bad. :-( > > Yes. This brings us back to what I mention at the beggining of this > thread. Shoudn't the concerned file be adapted then ? I guess so. Since we aren't likely (I don't think!) to get an updated debiandoc-sgml, can someone check to see whether we could perhaps define the mdash entity, when making HTML, to '-' or '--', perhaps in defaults.ent? If someone can get this fixed (I don't have time) and just commit it in CVS that would pretty much fix the problem. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.2.17 now building for upload to potato
Adam Di Carlo: > > > I'm now building for release boot-floppies 2.2.17. > > Does this include the translated boot floppies? > No, no one has integrated that into the build process -- I guess it > was up to me (sigh) but I haven't had time. So, basically, currently it is pointless to translate the boot-floppies? -- \\// peter - http://www.softwolves.pp.se/ Statement concerning unsolicited e-mail according to Swedish law: http://www.softwolves.pp.se/peter/reklampost.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#72246: boot-floppies: Using 2.2.16 (2.2r0) sets hostname to the short hostname, rather than fqdn
Jeff Sheinberg <[EMAIL PROTECTED]> writes: > I recently did a clean install using boot floppies 2.2.16, ie, > same as 2.2r0. When the network was being configured, I entered > the hostname as `eden-hda7', and the domain as `my.local'. > > After I re-booted, and completed the install, I noticed that the > hostname was incorrect. What is strange is that the hosts, > mailname and resolv.conf files were setup correctly, while the > hostname file was not. But it looks ok to me. On my box, /etc/hostname is 'arroz', not my FQDN. Why do you think it should be the full FQDN? -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#72845: should add default, *enabled* security.debian.org entries to /etc/apt/sources.list
reassign 72845 base-config severity 72845 important thanks Henrique M Holschuh <[EMAIL PROTECTED]> writes: > The boot-floppies should add _active_, suitable deb lines to the default > /etc/apt/source.list file, so as to allow even clueless users to access the > emergency security updates BY DEFAULT. > > It would be a good idea to get this fixed for the next point release, as it > adds quite a deal of security to the distribution "out-of-the-box", for a > ridiculously low price. I agree. This is a security issue. Most users don't know about the security URLs, I've found. What good is it if poeple don't know about it. I've bumped this to important and reassigned to base-config. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#72845: should add default, *enabled* security.debian.org entries to /etc/apt/sources.list
Processing commands for [EMAIL PROTECTED]: > reassign 72845 base-config Bug#72845: should add default, *enabled* security.debian.org entries to /etc/apt/sources.list Bug reassigned from package `boot-floppies' to `base-config'. > severity 72845 important Bug#72845: should add default, *enabled* security.debian.org entries to /etc/apt/sources.list Severity set to `important'. > thanks Stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#72246: boot-floppies: Using 2.2.16 (2.2r0) sets hostname to the short hostname, rather than fqdn
On Sat, Sep 30, 2000 at 01:41:26PM -0400, Adam Di Carlo wrote: > > I recently did a clean install using boot floppies 2.2.16, ie, > > same as 2.2r0. When the network was being configured, I entered > > the hostname as `eden-hda7', and the domain as `my.local'. > > > > After I re-booted, and completed the install, I noticed that the > > hostname was incorrect. What is strange is that the hosts, > > mailname and resolv.conf files were setup correctly, while the > > hostname file was not. > > But it looks ok to me. On my box, /etc/hostname is 'arroz', not my > FQDN. > > Why do you think it should be the full FQDN? BTW on related note: After a fresh potato installation the other day, the name I gave to the installation system was linked to 127.0.0.1, i.e. localhost: 127.0.0.1 nevkos localhost However, I wanted to give it a real address, like in slink installation, but there was no such dialog box. Anyway, after I set up /etc/network/interfaces and /etc/hosts manually, resolving the domain name wouldn't work, because my /etc/hosts had this: 127.0.0.1 nevkos localhost 161.53.211.9nevkos.gkvk.hr nevkos The resolver didn't notice the second entry at all, just the first one. The fix is rather obvious, just s/nevkos// in the first line -- but the installation system could be a bit smarter when it comes to this, i.e. it should ask the user if he's connected to network etc... -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unable to make Russian PDFs still
On Sat, Sep 30, 2000 at 12:57:12PM -0400, Adam Di Carlo wrote: > > Even using woody TeX (which has some serious problems, btw), I still > get tons and tons of errors making install.ru.pdf > > ! LaTeX Error: Command \cyrt unavailable in encoding T2A. > > I don't understand how other people are producing this PDF properly. > It's going to have to be disabled until someone can explain to me what > to setup to get this file building. Just a guess. I am using Russian environment, that means that I have LANG=ru_RU.KOI8-R I am going to check if it's a correct guess. -- Misha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody] modules for debian-installer (Re: the next step)
On Sat Sep 30, 2000 at 01:26:49PM -0400, Adam Di Carlo wrote: > > I think grub would be better since it's xplatform. I have heard > rumors that its not ready for prime time yet, though. I've been using it with great results on my laptop, home box, and work box. I give it two thumbs up (though the Debian package really needs a makeover -- it doesn't even attempt to install things in a usable fashion... -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --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: &mdash in boot-floppies/documentation
On Sat, Sep 30, 2000 at 01:38:34PM -0400, Adam Di Carlo wrote: > > Yes. This brings us back to what I mention at the beggining of this > > thread. Shoudn't the concerned file be adapted then ? > > I guess so. Since we aren't likely (I don't think!) to get an updated > debiandoc-sgml, can someone check to see whether we could perhaps > define the mdash entity, when making HTML, to '-' or '--', perhaps in > defaults.ent? Well, my knowledge of SGML is not very solid, so I could be wrong, but AFAIK just defining mdash somewhere in the document does not help, as those ISO entities are processed earlier, and, as we all know, in SGML world the first wins. :) > If someone can get this fixed (I don't have time) and just commit it > in CVS that would pretty much fix the problem. Maybe we could wait a bit before Ardo pays some attention to #72550? -- Misha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: &mdash in boot-floppies/documentation
On Sat, Sep 30, 2000 at 03:36:06PM +0200, Van Buggenhaut wrote: > > As I already said, Netscape is known to not support all those entities. That's >very > > bad. :-( > > Yes. This brings us back to what I mention at the beggining of this thread. > Shoudn't the concerned file be adapted then ? Well, I submitted bug #72550. This is a wishlist, though. Or do you think that nonreadable mdashes are more than just inconvenience? If so, you could submit a bug against boot-floppies... -- Misha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the next step
On Sat, Sep 30, 2000 at 09:54:53AM -0600, Erik Andersen wrote: > It will fit. Oh, yes. It will. ;-) > > I'm sure it can be done. Though we may need to switch to libc5 or uclibc or > something more exotic (like the thin syscall wrapper libc thing on the RedHat > installer). Oooh, uclibc. That's a good idea. In fact, that's a VITAL idea. Joey, please remember that some architectures (I'm thinking powerpc here, and at least two more) do not support library reduction. libc on a floppy is not an option. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#72870: Broken links in HTML version of Debian installation docs
Package: boot-floppies Version: 2.2.16 I hope I get the version number correct, it is the one printed at the bottom of the HTML pages: Installing Debian GNU/Linux 2.2 For Intel x86 version 2.2.16, 05 July, 2000 There are three broken links to the "dselect Tutorial" from these pages. [Until Debian is installed, I am viewing the pages with IE3 on MS Windows 95 and "Debian GNU/Linux 2.2 rev 0 Binary CD 1 Non-US" is mounted in the H: drive.] The page H:\install\doc\ch-init-config.en.html has 2 broken links to: file:H:\install\doc\dselect-beginner.html The page H:\install\doc\ch-preparing.en.html has 1 broken link to: file:H:\install\doc\dselect-beginner$langext.html The page H:\install\doc\index.en.html has 1 working link to: file:H:\install\doc\dselect-beginner.en.html FWIW, the working link appears as the "dselect Beginner's Guide" whereas the 2 broken links appear as the "dselect Tutorial". The page H:\install\doc\index.en.html also has broken links to: file:H:\install\doc\dselect-beginner.pdf file:H:\install\doc\dselect-beginner.txt file:H:\install\doc\release-notes.en.html Here is a listing of \install\doc; (Note too, that index.html is 0 bytes.) total 770 -r--r--r-- 1 dosuser root18486 Jul 20 02:15 cfdisk.txt -r--r--r-- 1 dosuser root 4916 Jul 5 18:56 ch-administrivia.en.html -r--r--r-- 1 dosuser root 4864 Jul 5 18:56 ch-appendix.en.html -r--r--r-- 1 dosuser root 4041 Jul 5 18:56 ch-boot-floppy-techinfo.en.html -r--r--r-- 1 dosuser root 2036 Aug 3 16:23 ch-dselect-conclusion.en.html -r--r--r-- 1 dosuser root 1773 Aug 3 16:23 ch-dselect-glossary.en.html -r--r--r-- 1 dosuser root 2407 Jul 5 18:56 ch-dselect-intro.en.html -r--r--r-- 1 dosuser root21119 Jul 5 18:56 ch-dselect-main.en.html -r--r--r-- 1 dosuser root18462 Jul 5 18:55 ch-hardware-req.en.html -r--r--r-- 1 dosuser root37130 Jul 5 18:56 ch-init-config.en.html -r--r--r-- 1 dosuser root32284 Jul 5 18:55 ch-install-methods.en.html -r--r--r-- 1 dosuser root24502 Jul 5 18:55 ch-partitioning.en.html -r--r--r-- 1 dosuser root12283 Jul 5 18:56 ch-post-install.en.html -r--r--r-- 1 dosuser root14384 Jul 5 18:55 ch-preparing.en.html -r--r--r-- 1 dosuser root16303 Jul 5 18:55 ch-rescue-boot.en.html -r--r--r-- 1 dosuser root16576 Jul 5 18:55 ch-welcome.en.html drwxr-xr-x 2 dosuser root 2048 Aug 14 07:31 cs/ drwxr-xr-x 2 dosuser root 2048 Aug 14 07:31 de/ -r--r--r-- 1 dosuser root 952 Aug 3 16:23 dselect-beginner.en.html -r--r--r-- 1 dosuser root24193 Jul 5 18:56 dselect-beginner.en.txt drwxr-xr-x 2 dosuser root 4096 Aug 14 07:31 es/ -r--r--r-- 1 dosuser root10193 Aug 3 16:23 fdisk.txt drwxr-xr-x 2 dosuser root 2048 Aug 14 07:31 fi/ -r--r--r-- 1 dosuser root 1771 Jul 5 18:56 footnotes.en.html drwxr-xr-x 2 dosuser root 2048 Aug 14 07:31 fr/ drwxr-xr-x 2 dosuser root 4096 Aug 14 07:31 hr/ -r--r--r-- 1 dosuser root 3729 Jul 5 18:55 index.en.html -r--r--r-- 1 dosuser root0 Jul 5 18:55 index.html -r--r--r-- 1 dosuser root10627 Jul 5 18:55 install.en.html -r--r--r-- 1 dosuser root 287398 Jul 5 18:57 install.en.pdf -r--r--r-- 1 dosuser root 174826 Jul 5 18:55 install.en.txt drwxr-xr-x 2 dosuser root 2048 Aug 14 07:31 ja/ -r--r--r-- 1 dosuser root 4466 Mar 6 2000 officiallogo-nd-50.jpg -r--r--r-- 1 dosuser root 3986 Mar 6 2000 openlogo-nd-50.jpg drwxr-xr-x 2 dosuser root 2048 Aug 14 07:31 pt/ drwxr-xr-x 2 dosuser root 2048 Aug 14 07:31 ru/ drwxr-xr-x 2 dosuser root 2048 Aug 14 07:31 sk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
index.html.m4
Hi, I'm writing this because I'd like someone to explain this change: === RCS file: /cvs/debian-boot/boot-floppies/documentation/index.en.html.m4,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- boot-floppies/documentation/index.en.html.m42000/07/29 20:03:54 +++ boot-floppies/documentation/index.en.html.m42000/09/22 19:47:00 @@ -1,6 +1,6 @@ changequote([,]) -dnl Please don't translate this file, for now. m4 may not be used in the future +dnl $Id: index.en.html.m4,v 1.10 2000/09/22 19:47:00 polish Exp $ The CVS log entry for this commit is rather useless: "added : $". I seem to remember this file being deprecated, mostly due to m4, i.e. not being able to generate it using SGML etc... -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.2.17 now building for upload to potato
peter karlsson <[EMAIL PROTECTED]> writes: > So, basically, currently it is pointless to translate the > boot-floppies? No, I'm just saying we don't ship, by default, LANG_CHOOSER enabled dbootstrap on root disks. I'm going to fix this shortly, if I get a chance. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: index.html.m4
Josip Rodin <[EMAIL PROTECTED]> writes: > I seem to remember this file being deprecated, mostly due to m4, i.e. not > being able to generate it using SGML etc... Yes, we un-deprecated this file. There's no way to do it in SGML unless we use DocBook (which I may well switch to for woody bf but I don't wanna drag that in now). Translators, take note. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: &mdash in boot-floppies/documentation
Michael Sobolev <[EMAIL PROTECTED]> writes: > On Sat, Sep 30, 2000 at 01:38:34PM -0400, Adam Di Carlo wrote: > > I guess so. Since we aren't likely (I don't think!) to get an updated > > debiandoc-sgml, can someone check to see whether we could perhaps > > define the mdash entity, when making HTML, to '-' or '--', perhaps in > > defaults.ent? > Well, my knowledge of SGML is not very solid, so I could be wrong, but AFAIK > just defining mdash somewhere in the document does not help, as those ISO > entities are processed earlier, and, as we all know, in SGML world the first > wins. :) It's true that the first wins, but defining it in the document preamble, for instance, would definately be the first and win. > > If someone can get this fixed (I don't have time) and just commit it > > in CVS that would pretty much fix the problem. > Maybe we could wait a bit before Ardo pays some attention to #72550? Yes, but is he planning on putting that into Potato? -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
stormix installer modules
I was just looking at stormix's cvs (cvs.stormix.com) looks like there installer is modular, maybe we can learn from what they have done. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the next step
Erik Andersen wrote: > > Maybe we can use it as the actual engine of the retreiver. The > > retreivers though have to all use a standard interface, and I think it > > makes sense to make a special module for the glue code. > > I see. So more then just a retriever, you want something like the current boot > floppies http-fetch -- complete with curses/slang status bar, and such. Got > it. I can do this. I think we want an engine that works, and a pluggable > front end gui, so for example, someone could later write a microwindows > installer. I will just the curses/slang front end, and the underlying engine. No, don't worry about the frontend. Debconf will (should) be able to handle displaying progress. Just make sure that busybox wget can output in some format that is easily machine reabable so it can be fed into the frontend. In other words, debconf is the pluggable front end gui you're talking about. > Not that big a deal really. I already compile busybox twice for the .deb. > Adding a few more recompiles wouldn't be a problem. Good! > It will fit. Oh, yes. It will. ;-) If we keep repeating that maybe it will happen. :-) > I'm sure it can be done. Though we may need to switch to libc5 or uclibc or > something more exotic (like the thin syscall wrapper libc thing on the RedHat > installer). -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the next step
Daniel Jacobowitz wrote: > Oooh, uclibc. That's a good idea. > > In fact, that's a VITAL idea. > > Joey, please remember that some architectures (I'm thinking powerpc > here, and at least two more) do not support library reduction. libc on > a floppy is not an option. I've never been given a good reason for why reduction doesn't work on some architectures besides "it just doesn't seem to work". Sigh. Keep in mind the (single?) floppy install I'm talking about it just a demo system, and it's not the only way the new installation system will work, just the first one we'll get working. So it may be we won't get a single floppy install for some architectures. Probably no worse than it is now though. I agree uclibc sounds like a good idea. It needs more investigation though: does it work on all architectures? Does it support anything we'll need to do? Is it painful to use? Is it small enough? (It seems to build a 415k libc.a here, which seems a little large.) -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the next step
On Sat Sep 30, 2000 at 06:08:39PM -0700, Joey Hess wrote: > Daniel Jacobowitz wrote: > > Oooh, uclibc. That's a good idea. > > > > In fact, that's a VITAL idea. > > > > Joey, please remember that some architectures (I'm thinking powerpc > > here, and at least two more) do not support library reduction. libc on > > a floppy is not an option. > > I've never been given a good reason for why reduction doesn't work on > some architectures besides "it just doesn't seem to work". Sigh. At Lineo (where I work) we have a tool called "Lipo" (written in perl) that does the library reduction thing, and we have it working quite nicely on a number of platforms. In some cases we had to add in special platform specific lists of symbols to always include, but once you get past the fact that static analysis sometimes misses sneaky platform specific symbols and just always add those back in to the keep list, all is well. > Keep in mind the (single?) floppy install I'm talking about it just a > demo system, and it's not the only way the new installation system will > work, just the first one we'll get working. > > So it may be we won't get a single floppy install for some > architectures. Probably no worse than it is now though. > > I agree uclibc sounds like a good idea. It needs more investigation > though: does it work on all architectures? Does it support anything > we'll need to do? Is it painful to use? Is it small enough? (It seems to > build a 415k libc.a here, which seems a little large.) I've done a lot of work on uclibc (like the x86 port-in-progress for example). It currently only supports static linking. Till now, all supported architectures have been source tree forks. We (Lineo/uclinux.org) are currently in the process of reintegrating all the forks into the one true tree (using my ever-so-cleaned-up source tree as a base, if I may brag a bit :-) Currently, I know of at least support for MCORE, ColdFire, DagonBall, 68EN360, ARM7, SPARC, MIPS, SH2, and x86. Though I don't quite have x86 ready for heavy duty production usage (about 30 functions missing still), for many things it works quite well already. I don't think uclibc is quite ready for use by the boot floppies -- but I think it will be ready before the woody release. One thing that may need some attention is arch support (such as Alpha or UltraSparc). -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --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: the next step
On Sat, Sep 30, 2000 at 06:08:39PM -0700, Joey Hess wrote: > Daniel Jacobowitz wrote: > > Oooh, uclibc. That's a good idea. > > > > In fact, that's a VITAL idea. > > > > Joey, please remember that some architectures (I'm thinking powerpc > > here, and at least two more) do not support library reduction. libc on > > a floppy is not an option. > > I've never been given a good reason for why reduction doesn't work on > some architectures besides "it just doesn't seem to work". Sigh. To be honest, I've never been given a really good explanation as to why libc reduction works in our current setup, period. I spent a while trying to make it work on powerpc and gave up in bewilderment. > I agree uclibc sounds like a good idea. It needs more investigation > though: does it work on all architectures? Does it support anything > we'll need to do? Is it painful to use? Is it small enough? (It seems to > build a 415k libc.a here, which seems a little large.) I do wish there was some way we could get everything that needs to be (executable) in the very minimum install into a single binary and static link it. Then we could use glibc, or uclibc, or even newlib... barring that, a small shared libc it may have to be. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#72845: should add default, *enabled* security.debian.org entries to /etc/apt/sources.list
Package: boot-floppies Version: N/A; Severity: normal The boot-floppies should add _active_, suitable deb lines to the default /etc/apt/source.list file, so as to allow even clueless users to access the emergency security updates BY DEFAULT. It would be a good idea to get this fixed for the next point release, as it adds quite a deal of security to the distribution "out-of-the-box", for a ridiculously low price. -- System Information Debian Release: woody Architecture: i386 Kernel: Linux godzillah.rivendell.sol 2.2.17 #1 Wed Sep 6 17:08:58 BRT 2000 i586 -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wasted disk space
On Sat, Sep 30, 2000 at 05:35:48PM +0200, Massimo Dal Zotto wrote:
> I found that of my 2GB root filesystem more than 10% is wasted because it has
> been formatted by the potato installer with a 4K block size instead of 1K.
What exactly is on your /-mountpoint? home? var? usr? opt? Everything?
Can we have that awk script please and thanks for your work. I guess the
reason is, that nobody has bothered to change the default of mke2fs. The
default is actually calcilated from the File System size (and if it is news
or not). So perhaps we should talk to Ted about that?
Greetings
Bernd
--
(OO) -- [EMAIL PROTECTED] --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wasted disk space
On Sat, Sep 30, 2000 at 05:35:48PM +0200, Massimo Dal Zotto wrote:
> I found that of my 2GB root filesystem more than 10% is wasted because it has
> been formatted by the potato installer with a 4K block size instead of 1K.
Actually on my system all partitions are 1k:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 101075 86295 9561 90% /
/dev/sda5 987251747829188416 80% /usr
/dev/sda6 987251922089 14156 98% /var
/dev/sda7 1771824 1657510 22744 99% /home
calista:/home/ecki# for i in /dev/sda1 /dev/sda5 /dev/sda6 /dev/sda7; do
echo "$i une2fs -l $i | grep Block\ size" ; done
/dev/sda1 Block size: 1024
/dev/sda5 Block size: 1024
/dev/sda6 Block size: 1024
/dev/sda7 Block size: 1024
This is because I dont have so big partitions as u have and mke2fs is
guessing that smaller blocks are better.
Greetings
Bernd
--
(OO) -- [EMAIL PROTECTED] --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wasted disk space
On Sat, Sep 30, 2000 at 06:54:34PM +0200, Bernd Eckenfels wrote: > > I found that of my 2GB root filesystem more than 10% is wasted because it has > > been formatted by the potato installer with a 4K block size instead of 1K. > > Actually on my system all partitions are 1k: > > /dev/sda1 Block size: 1024 > /dev/sda5 Block size: 1024 > /dev/sda6 Block size: 1024 > /dev/sda7 Block size: 1024 > > This is because I dont have so big partitions as u have and mke2fs is > guessing that smaller blocks are better. # tune2fs -l /dev/hda6 | grep Block tune2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 Block count: 2417751 Block size: 1024 Blocks per group: 8192 That's larger than Massimo's partition AFAICT, yet it has 1K block size... -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
wasted disk space
Hi,
I found that of my 2GB root filesystem more than 10% is wasted because it has
been formatted by the potato installer with a 4K block size instead of 1K.
In other words if the same files are stored on a filesystem with 1K-blocks I
have other 200MB available.
This is the test I have done:
# mke2fs -i 8192 -b 1024 /dev/sdc2 `fdisk -s /dev/sdc1`
# mount /dev/sdc2 /mnt
# (cd /var/mnt/root && tar -cf -) | (cd /mnt && tar -xvf -)
# dumpe2fs /dev/sdc1 | grep size
dumpe2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Block size: 4096
Fragment size:4096
Inode size: 128
# dumpe2fs /dev/sdc2 | grep size
dumpe2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Block size: 1024
Fragment size:1024
Inode size: 128
# df /dev/sdc1
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sdc1 2063708 1811272147604 92% /var/mnt/root
# df /dev/sdc2
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sdc2 2063265 1583476374957 81% /mnt
As you can see the wasted space is 374957-147604 = 227353 = 222MB.
The difference can be easily explained if we do some calculation on the
actual size in blocks of each file:
# find . -type f -exec ls -la {} \; | ~/test.awk
SIZE 4K-SIZE 1K-SIZEDIFF FILENAME
24536 24576 24576 0 lib/modules/2.2.17/modules.dep
13196 16384 133123072 lib/modules/2.2.17/block/ide-floppy.o
70060 73728 706563072 lib/modules/2.2.17/block/DAC960.o
27372 28672 276481024 lib/modules/2.2.17/block/ide-tape.o
23716 24576 24576 0 lib/modules/2.2.17/block/cpqarray.o
21696 24576 225282048 lib/modules/2.2.17/block/xd.o
2636409630721024 lib/modules/2.2.17/block/linear.o
364040964096 0 lib/modules/2.2.17/block/raid0.o
10200 12288 102402048 lib/modules/2.2.17/block/raid1.o
19600 20480 20480 0 lib/modules/2.2.17/block/raid5.o
...
13299 16384 133123072 var/yp/dz-net/rpc.bynumber
28672 28672 28672 0 var/yp/dz-net/services.byname
18392 20480 184322048 var/yp/dz-net/netid.byname
12935 16384 133123072 var/yp/dz-net/protocols.bynumber
12396 16384 133123072 var/yp/dz-net/netgroup
12403 16384 133123072 var/yp/dz-net/netgroup.byhost
12403 16384 133123072 var/yp/dz-net/netgroup.byuser
12434 16384 133123072 var/yp/dz-net/networks.byaddr
12431 16384 133123072 var/yp/dz-net/networks.byname
12737 16384 133123072 var/yp/dz-net/printcap
1538356570 1811968000 1597841408 214126592 104735 files, avg.diff 2044
As you can see the average difference is about 2K that multiplied by 104000
files gives the 200MB of wasted space. Other space is probably wasted by the
bigger indirect blocks of a 4K-blocks ext2fs.
I wonder why the root filesystem has been formatted with this inefficient
block size, given the fact that it contains a lot of small files.
In my opinion the 4K block size should be used only for large filestems or
filesystems that are used for database or ftp servers.
Any comment?
--
Massimo Dal Zotto
+--+
| Massimo Dal Zotto email: [EMAIL PROTECTED] |
| Via Marconi, 141phone: ++39-0461534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: see my www home page |
+--+
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wasted disk space
On Sat, Sep 30, 2000 at 06:54:34PM +0200, Bernd Eckenfels wrote:
> On Sat, Sep 30, 2000 at 05:35:48PM +0200, Massimo Dal Zotto wrote:
> > I found that of my 2GB root filesystem more than 10% is wasted because it has
> > been formatted by the potato installer with a 4K block size instead of 1K.
>
> Actually on my system all partitions are 1k:
>
> Filesystem 1k-blocks Used Available Use% Mounted on
> /dev/sda1 101075 86295 9561 90% /
> /dev/sda5 987251747829188416 80% /usr
> /dev/sda6 987251922089 14156 98% /var
> /dev/sda7 1771824 1657510 22744 99% /home
>
> calista:/home/ecki# for i in /dev/sda1 /dev/sda5 /dev/sda6 /dev/sda7; do
bash lets you do great stuff : for i in /dev/sda{1,5,6,7} is faster
> echo "$i une2fs -l $i | grep Block\ size" ; done
> /dev/sda1 Block size: 1024
> /dev/sda5 Block size: 1024
> /dev/sda6 Block size: 1024
> /dev/sda7 Block size: 1024
>
> This is because I dont have so big partitions as u have and mke2fs is
> guessing that smaller blocks are better.
>
> Greetings
> Bernd
> --
> (OO) -- [EMAIL PROTECTED] --
> ( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
> o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
> (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
--
[EMAIL PROTECTED]
http://www.eric.ath.cx
Please don't send proprietary format documents, I can't (and don't want to) open them.
Appreciated are open-source formats like .txt or .rtf. Dvi, ps or tex files are
welcome.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
2.2.17 i386 boot-floppies uploading
Sorry for the serious cross-post but no one seems to be reading debian-release right now, and I want this to propogate widely. Boot-floppies 2.2.17, a major bugfix point release for Potato, is being uploaded to samosa now. I shall put it up on auric.debian.org/~aph/ this evening. I don't read debian-devel or debian-testing, so please either CC debian-boot or file bugs against boot-floppies. Changelog is below -- aside from the numerous bug fixes, significant in this release is update packages from potato-proposed-updates, much better i18n documentation, and means to make i18n'd rescue disks. This release does *not* include the new 2.2.17 kernels because a full set (that is, idepci and compact) were not yet available. Sorry, but nothing I can do. We fixed the af_packet error so 'pump' works again. I've run thru complete installation on i386 laptop with pcmcia and it works fine. Many thanks to all the hackers (esp Martin Schulze, closing 21 BTS entries and numerous unfiled bugs), translators, and interested users who file bug reports. On my todo next is i18n integration of the root disk with dbootstrap messages (at least on i386) and of course, documentation updates. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> boot-floppies (2.2.17) stable; urgency=low * Adam Di Carlo: - release-notes: fix typo (closes: Bug#68630) - fix bugs preventing some l10n'd documentation from building - temporarily disable Russian documentation, unless you have woody debiandoc-sgml - config: re-organize a bit - fix .cvsignore file (closes: Bug#68911) - fix URLs in documentation based on link checking - documentation improvements (closes: Bug#67900); change the wording of the "in progress" warning in Chapter 1 (closes: Bug#69620); correct workaround for volume manager, patch from Jim Crumley (closes: Bug#69141); fix documentation on how mkofboot is invoked; rework the 'dbootstrap' chapter, removing plenty of slink'isms; fix some make-kpkg bugs (closes: Bug#71080) - dbootstrap: fix a condition where /target/lib/modules was being made a link to itself (closes: Bug#68021); run 'depmod -a' after manipulating the /lib/modules symlink after extracting the kernel and modules which fixes a problem with PCMCIA - fix a minor libfdisk Makefile / depends problem * Guillaume Morin: - more dbootstrap i18n - dbootstrap floppy module pre-load support * Vincent Renardias: French updates (thank to Eric VanBuggenhaut) * Jiøí Ma¹ík <[EMAIL PROTECTED]>: Czech updates * Gleydson Mazioli da Silva: Portuguese updates * novdv: Russian translations * Yoshizumi Endo <[EMAIL PROTECTED]>: Japanese updates * Risko Gergely <[EMAIL PROTECTED]>: Hungarian updates * Marcin Owsiany <[EMAIL PROTECTED]>: Polish updates * Peter Karlsson: Swedish updates * Vilem Vychodil: Czech update * Tapio Lehtonen: Finnish translation thanks to Markku Verkkoniemi * Enrique Zanardi: Spanish updates * Michael Bramer: German updates * C.M. Connelly: English documentation corrections and improvements * Josip Rodin: - release notes updates: APT::Force-LoopBreak, kernel 2.2.x upgrade issues; remove sis6326 note; add info about i810; fixed X upgrade pointer; notes about CD sets; notes about ssh - some documentation and doc build fixes; move documenation build rules to documentation/ dir - fix index.LANG.html broken links (closes: Bug#67898) * Daniel Jacobowitz: - some powerpc-specific boot stuff fixed - update PowerPC kernel version * Martin Schulze: - Added little documentation to some routines - dbootstrap.h: Added prototype of get_kver() - getFloppies() and affected routines return DLG_CANCEL (aka 10) when Cancel is pressed, no need to spit an error message (closes: Bug#68900) - boxes.h: DLG_CANCEL is now 10 instead of 1, in order to avoid problems with 'return 1' stuff - Added calls to get_kver() to every _test target. Thanks tausq for the quick investigation - basedisk.sh: Added workarounds for missing device files and added others to MAKEDEV call - rootdisk.sh: Added optcd sjcd to list of i386 devices, still missing: gscd, cm206cd and proper support for mcdx (partially fixes: Bug#68665) - rootdisk.sh: Added ida.1 creation (closes: Bug#68517) - rootdisk.sh: Added -O none to mke2fs call to gain 2.0 compatibility (closes: Bug#68659) - basedisk.sh: Added /dev/sg* to list of created devices in the base system (closes: Bug#67378) - Corrected error messages when rescue.bin wasn't found (but is there..), added " + drivers.tgz" (closes: Bug#66326, Bug#64349) - Added padding code to pad the last drivers disk with zeroes (closes: Bug#66030) - Corrected behavior when user has to type in the path relative to /instmnt, he won't be able to leave that dir anymore and don't has
Re: wasted disk space
On Sat, Sep 30, 2000 at 06:34:07PM +0200, Bernd Eckenfels wrote: > On Sat, Sep 30, 2000 at 05:35:48PM +0200, Massimo Dal Zotto wrote: > > I found that of my 2GB root filesystem more than 10% is wasted because it has > > been formatted by the potato installer with a 4K block size instead of 1K. > > What exactly is on your /-mountpoint? home? var? usr? opt? Everything? > > Can we have that awk script please and thanks for your work. I guess the > reason is, that nobody has bothered to change the default of mke2fs. The > default is actually calcilated from the File System size (and if it is news > or not). So perhaps we should talk to Ted about that? > What you have here is a case of usage v speed. Your files are broken up by the file system in to blocks and scattered over the disk surface. To store a file which contains just a single character will take up one block. Not very efficient in terms of disk usage. However a large file which requires many blocks also requires the disk heads to seek many time toaccess them. If the block size is small then more head seeking is required and performance goes down. (There's a lot more to block positiong than this.) As a sysadmin it is your job to configure the partion in the best way for the job it has to handle. If the disk is storing emails or news then file size is, on the whole, small and performance not such a big issue. If the file system is holding a database then performance (and a bigger block size) is better. Don't worry about the wasted 10%. The missing space is taken up with the end of files that don't fit into a block. File systems often fragment the little bits of the files left over and place them into one block. The problem with these fragments is that to get them requires more CPU then full blocks. At the end of the day its the old choice of cost against performance. Your system; you decide. Steve -- Steve Dobson [EMAIL PROTECTED] If bankers can count, how come they have eight windows and only four tellers? PGP signature
Re: SoundBlaster cdrom problems
On 29 Sep 2000, Adam Di Carlo wrote: > Neil Shadrach <[EMAIL PROTECTED]> writes: > > > is ok - from floppies, but I'm having trouble with the cd. > > I can mount it, wander the directories and even copy many of the files > > to the hard disk. > > However attempts to copy some files fail with i/o errors ( detail below > > ). > > The same is true under Windows 95. > > Really? Wait, you only get the errors when copying files from the > debian-cd, either under linux or windows, but in windows (or whatever) > you can copy other cds files around ok? This would indicate a cd > problem. I've cc'd debian-cd. > > > I've not had any problems with other cds on the same box. > > On the other hand I've used the same cds to install debian on a > > different machine. > > Could it be some subtle change/new faeture in the cd format or is my > > machine just inconsistent? > > > I think that the problems tend to occur with larger files but I haven't > > tested this exhaustively. > > That would be my guess. Subtle hardware problem which is triggered by > large files. Do you have any settings you can twiddle? > > > --- > > sbp_data: CDi_status loop expired > > sbp_data: CDi_status timeout ( timed_out_data ) (FB) > > sbp_data: RESULT_READY where DATA_READY awaited (FB) > > DATA_READY timeout (FF) > > read aborted by drive == > > !st_diskok detected - retrying > > !st_diskok detected - retrying > > !st_diskok detected - retrying > > sbp_status: failed after 3 tries in line 4897 > > END_REQUEST: I/O ERROR, dev 19:00 ( matsushita cd-rom controller #1 ), > > sector 101782 This is a problem with your drive (not the software), it just can't read the CD. The CD may be dirty, so cleaning it is advisable. Sector 101782 is about 200MB, so your "problem" is located at 1/3rd of the width of the CD counting from the center. It also may be that the CD's track is swaying a bit and your old drive can't cope with that, in that case ticking on the tray while accessing the CD might help. Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
