Re: cvs commit to debian-cd/tools/boot/potato by eb
Le Fri, Jun 15, 2001 at 02:48:49PM -0800, Ethan Benson écrivait: > this sounds perfect. i presume it will only output information about > the yaboot in the distribution for which the CD is being created for? > > that is if one is building potato CDs only information on the pototo > version of yaboot will be output? Yes, of course. > i will use the above for both potato and woody. Good. Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguez sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to debian-cd/tools/boot/potato by eb
Repository: debian-cd/tools/boot/potato who:eb time: Sat Jun 16 05:24:58 PDT 2001 Log Message: make yaboot extraction pool compatible Files: changed:boot-powerpc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to debian-cd/tools/boot/woody by eb
Repository: debian-cd/tools/boot/woody who:eb time: Sat Jun 16 05:24:59 PDT 2001 Log Message: make yaboot extraction pool compatible Files: changed:boot-powerpc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creating Custom Menu
On Fri, Jun 15, 2001 at 09:00:12PM -0400, Joey Hess wrote: > With a task package (in stable; in unstable the mechanism has utterly > changed). Hi Joey, I am using what happens to be in the CVS tree.. The new 'mechanism' wouldn't happen to be documented anywhere would it? Justin. -- Justin F. Knotzke [EMAIL PROTECTED] pgp public key http://www.shampoo.ca/pubkey.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creating Custom Menu
Justin F. Knotzke wrote: > I am using what happens to be in the CVS tree.. The new 'mechanism' > wouldn't happen to be documented anywhere would it? Yes, tasksel/tasks/README -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base*.tgz is gone, and why it's gone
Ben Collins <[EMAIL PROTECTED]> writes: > On Fri, Jun 15, 2001 at 05:09:33PM -0600, Jason Gunthorpe wrote: > > The base tarball is *very* useful for NFS root booting other > > architectures which I do alot, particularly when the NFS serving box is > > not a debian box. It is very nice to be able to say 'fetch this tar, > > unpack it, setup NFS and boot this kernel'. > > > > I'm not sure how you can automate that process without haxoring the .debs > > since they can't really have their post insts run. It would be nice if > > there is possible solution, particularly if said solution could run on > > non-Debian unix's.. > > Maybe debootstrap could be hacked to support this? I'm not sure how you > would create a fully installed system in a chroot on a different arch > though. Honestly, the best approach here is to hack debootstrap, say, with a special arg, so that instead of building base, it constructs enough of a local mirror so that you could install base. Of course, the packages in base are going to vary from arch to arch, and most of the packages are arch-dependant Anyhow, assuming you had a subset of a debian archive, enough to get base, and you can get that via http, nfs, or ftp, if you had that, why is that less convenient to install from the actual packages rather than from a big fat tarball? -- .Adam Di [EMAIL PROTECTED]http://www.onshored.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base*.tgz is gone, and why it's gone
On Sat, Jun 16, 2001 at 04:19:51PM -0400, Adam Di Carlo wrote: > > Honestly, the best approach here is to hack debootstrap, say, with a > special arg, so that instead of building base, it constructs enough of > a local mirror so that you could install base. Of course, the > packages in base are going to vary from arch to arch, and most of the > packages are arch-dependant this is my thought, have debootstrap download all the packages it needs into a flat directory, then you just tar up that directory. put it on a hard disk and unpack it in /target/var/cache/apt/archives. telling debootstrap there that it should skip the download part and just start installing as if it had just finished the download. > Anyhow, assuming you had a subset of a debian archive, enough to get > base, and you can get that via http, nfs, or ftp, if you had that, why > is that less convenient to install from the actual packages rather > than from a big fat tarball? because you can get the tarball to the machine via a hard disk rather easily, and if the only filesystem the target machine has at the moment is a crippled one tarball is the only way. we are getting a mail or two on debian-powerpc from people who configure a dual boot system, but have dsl with that horrible pppoe garbage. since the boot-floppies don't support that they can't install base. under potato they would download the base.tgz ahead of time and keep it on CrippledFileSystem. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: base*.tgz is gone, and why it's gone
On Sun, Jun 17, 2001 at 12:06:21AM -0600, Jason Gunthorpe wrote: > > This is trivially solvable by having .html files with links to all the > files that are required (or maybe if there are too many, a link to a tar > of the .debs). I expect this is easially producable in an automated way > from debbootstrap, and I agree it is an important requirement. thats a gross and unmaintainable kludge IMO. having a debootstrap option to simply download the debs and then stuff them in a tarball isn't so bad. that still creates a maintenence problem since the tarball has to be managed manually. but thats not nearly as bad as renaming 50 or so debs to crippled 8.3 filenames and building an html file to map them. > I have frequently had to do installs on machines with ethernet cards that > are not supported by the boot disks, invariably this is either solved > using a 'boot from linuxcare cd' or 'boot from windows' and using a > temporary filesystem. which is what a tarball of debs would solve. something like: debootstrap --download-only woody /var/tmp/debootstrap http://http.us.debian.org then you get /var/tmp/debootstrap filled with about 50 .debs, run (cd /var/tmp/debootstrap ; tar -zcf ../base.tgz .) debootstrap could then also support something like: debootstrap --boot-floppies woody /target tar:/instmnt/base.tgz where it would (cd /target/var/cache/apt/archives; tar -zxf /instmnt/base.tgz) and begin unpacking as if it just finished a download. > debbootstrap sounds great, but it is essiantial that all files needed > for install are fetchable with out excessive trouble using standard > netscape/IE. i tend to agree, but the only way that is possible is if we support a tarball aquisition method, such as i have proposed above. with my proposal it would be trivial for the base.tgz to be updated on a regular basis, it could even be triggered by/after the dinstall runs. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
