Re: Still no base tarball
> Ethan Benson <[EMAIL PROTECTED]> writes: > > > base tarballs are obsolete and deprecated, period. > > Well, kinda. See below. > > > the ONLY time a base tarball should be used to install the base system > > is for hard disk based installs. it should never be used for CD > > installs, or network installs, ever. > > Right. Dale seems to htink providing tarballs is more critical than > most others do, but since he's leading the testing effort, and if he > tells me that over 50% of his people can't test w/o it, I guess I have > to take his word. > > But Ethan is perfectly correct that the CD#1 provides enough of the > archive to use for debootstrap. > > The only cases where someone needs basedebs.tgz is (a) they have net > access, say, at work and not at home, and want to downlooad something > and ship it over, or (b) they are installing base via floppies. > > However, even for these cases, we should provide basedebs.tgz and > split base provided in a well-known location, hopefully as part of the > Debian archive itself. > > Maybe AJ disagrees? > > > for CD installs and network installs debootstrap simply uses the > > normal debian archive, that is the .debs found in the pool and the apt > > Packages/Release files in dists/woody/binary-* for CDs all necessary > > packages will be on CD1, for the network everything is there > > obviously. > > Right. > > > so the basedebs.tgz file should NOT be present on offcial Debian CDs, > > nor should it be used for CD based installs. > > Exactly. > What if I bought the CDs and now I want to `ship it' to my other 1 or 2 home machines, which doesn't have a CDROM drive and need installing base via floppies? IMHO base is useful in some cases and should be shipped on the CD. If it is on the archive, why not ship it on the CDs? > > dbootstrap or debootstrap will never download the basedebs.tgz file > > from the network, if you have network connectivity the real debian > > archive will be used, NOT a base tarball. > > Right. > > > Agree with all the rest that Ethan says. > > But the upshot is the same: We NEED, I think, a well-known location at > which to provide the basedebs.tgz. Then we can document this in the > install manual, for the cases where people do need this (though rare). > > I suggest dists/woody/main/disks-/base-MMDD/ > > That would contain both basedebs.tgz and images-1.44/base-*.bin > containing split images. > > -- > ...Adam Di Carlo..<[EMAIL PROTECTED]>...http://www.onshored.com/> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Shaul Karl <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies by aph
Repository: boot-floppies who:aph time: Sun Aug 19 22:53:09 PDT 2001 Log Message: no reason why alpha can't support PCMCIA, put that on the todo for alpha Files: changed:todo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies/debian by aph
Repository: boot-floppies/debian who:aph time: Sun Aug 19 22:48:54 PDT 2001 Log Message: 'make cleanarchive' cleans the download directory only Files: changed:changelog -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies by aph
Repository: boot-floppies who:aph time: Sun Aug 19 22:48:47 PDT 2001 Log Message: 'make cleanarchive' cleans the download directory only Files: changed:Makefile -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies by aph
Repository: boot-floppies who:aph time: Sun Aug 19 22:07:47 PDT 2001 Log Message: oops, left in an 'exit 1' by accident Files: changed:kernel.sh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] Some questions
Le Sat, Aug 11, 2001 at 09:15:00PM -0400, Joey Hess écrivait: > > But launching an external program would break the nice encapsulation of the > > UI. Was that already discussed ? > > Yes, this is a problem of course. Debconf may come in handy for feeding > in pre-determined partition setups, and it could be used to ask every > question needed to partition a disk, but it would be quite clunky. The > simplicity of the UI you can create with debconf is both a weakness and > a strength. Yes, we'll have to live with that. But we really need to add at least a progressbar to cdebconf ... > > autodetection of hardware, this will also have to fit in that boot image > > (at least to autodetect the medium that will be used to retrieve the rest > > of the install), no ? > > Yes, there's really no other way it can be done. Oh, it's possible to > have a two stage process, where a simple to set up retriver (like one > that grabs files from floppies) is used to download what's needed to use > a more complex retreiver. For my CDROM install there isn't that many stages for the "retrieval", however there is two stage in the installer since there's what is on the boot image and what is copied from the CD once I detected it. That's how it was planned anyway. Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer 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]
Re: [debian-installer] Full CDROM install
Le Sat, Aug 11, 2001 at 08:58:14PM -0400, Joey Hess écrivait: > > strip -R .comment -R .note, it saves about 500k on the scsi directory. > > (eventually I heard that compiling them with -Os could help too but that'd > > need more work for you Herbert) > > Wow! We need this. > > Is this done on the boot-floppies kernel modules BTW? Saving the space > is likely to be very useful over there too. In fact, i was *really* wrong. I answered myself somewhere else in this thread since I stripped far too much to have working modules. :( The strip that we can afford is strip -R. comment -R .note -x but it saves a lot less. Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer 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]
Re: [debian-installer] Full CDROM install
Le Sat, Aug 11, 2001 at 09:10:42PM -0400, Joey Hess écrivait: > I had hoped that the first working debian-installer would be able to do > network installs, and it's not too far away. I think actually that the > peices it's missing are all required for the cdrom installer > (partitioning, debootstrap interface). I'll be really happy when we get > a working cdrom installer (or any working install via d-i). We might > just get two for the price of one.. Since my first mail I completed my installer. But since I had a very short time constraint I had to simplify some things. What i actually have and that may be valuable for debian-installer is : - a cdrom detection script using a stripped down discover (I have done a discover udeb but unfortunately Branden Robinson didn't integrate it in its package even if I asked him), this is commited in tools/cdrom-detect - an automatic partitionner using libparted (works only for disks having enough free room, or 1-2 big FAT partitions, and of course msdos disk labels only) I'll commit it soon in tools/autpartkit but it will probably need to be modified since it mounts the partition and writes /etc/fstab.new in the target directory. And it writes /etc/windows_part with the name of the bootable windows partition found. I have several other things but that I don't think they should be used by debian-installer (they are too hackish) : - an udeb which does decompress .tar.gz (found in a precise directory of the CD) in the tmpfs used dor the setup (it is required to extend the installer) - an udeb which does decompress other .tar.gz in the target directory (i have a base.tar.gz that I decompress) - a reboot udeb (simple shell script calling reboot and unmounting/ejecting the CDROM) - a basic hook mechanism for launching shell script whenever some events happens (after-unpack-target, after-setup-bootloader), i'm using run-parts to launch scripts put in - a simple shell script to automatically setup grub (will add an entry for Windows if /etc/windows_part exists). I had to make some other hacks for my installer to work : - make anna use my cdrom retriever by default - remove devfs, it does totally confuse parted and grub-install - changed some things in the build system of the images (those changes are worth for d-i, so i commited them, at least the beginning) > This could be pretty easy to do, depending on if syslinux allows > specification of things like foo/bar=baz on the command line, and if the > command line can be sufficiently large. If it does that could seed values > in a debconf database. I think the buffer is not big enough to handle many parameters, and it's not syslinux the problem but the kernel itself afaik. We'll need a conversion mechanism to be able to use short names on the commande line. > Instead of using Installer-Menu-Item fields, you can programmatically do > this via the menutest script mechanism. See doc/ui.txt. Oh, I didn't understand that. I thought that it was for deciding if an item was selected by default ... that was my reading of doc/ui.txt. Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer 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 boot-floppies/utilities/dbootstrap/po by jtarrio
Repository: boot-floppies/utilities/dbootstrap/po who:jtarrio time: Sun Aug 19 14:54:04 PDT 2001 Log Message: Galician translation update Files: changed:gl.po -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to debian-installer/retriever/cdrom/debian by hertzog
[EMAIL PROTECTED] wrote: > * cdrom-retriever is much like file retriever. It just symlinks > file from cdrom to the "downloaded" file. That's exactly what file-retreiver is meant to do, and the name is just more generic because there's no reason it can't work for disks with debian mirrors on them and nfs mounts too. Is cdrom-retreiver really needed then? -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to debian-installer/build/lists by hertzog
[EMAIL PROTECTED] wrote: > * Makefile updated to build good floppies (with basic terminfo files) > and various things (status -> status.udeb) I think the terminfo stuff, if needed, should be in its own udeb. I'm not sure about the status stuff and I can't look at what you mean as I'm offline for the next week. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] Full CDROM install
Raphael Hertzog wrote: > Ok, a few generic questions though. Does it matter if some modules are > in several modules-udeb ? I hope not (and I don't see why it would cause > problem as long as they are the same in the different udeb) because I > guess it'll be difficult to avoid this if all dependent modules are > automatically included. As Herbert says, a third package can be split out. If there's just a few modules in common though, it is legal to have udebs contain overlapping files without conflicts declared. No problem. > BTW, I see that none of the modules are stripped by default. That should > be done automatically for udeb. > > strip -R .comment -R .note, it saves about 500k on the scsi directory. > (eventually I heard that compiling them with -Os could help too but that'd > need more work for you Herbert) Wow! We need this. Is this done on the boot-floppies kernel modules BTW? Saving the space is likely to be very useful over there too. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] Full CDROM install
Thierry Laronde wrote: > BTW, it would be interesting to see somebody implementing a loader in a > bootstrapper (say GRUB), just in order (for monolithic kernel :-^) to link a > kernel with all the modules needed before booting. This would solve security > and access to the root fs as well... FWIW, HPA (syslinux author) gave a talk a year or two ago in which he discussed doing this. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] Some questions
[ Again, sorry for the delay. ] Raphael Hertzog wrote: > I've got one question though. If we use cdebconf for all interactions, > we're never going to have a GUI for advanced partitionning (you know > something like PartitionMagic or the Mandrake partitionner, where > you can resize a FAT partition and see the result on a visual > representation of the disk), unless of course we launch an external > program that doesn't interact with cdebconf. > > But launching an external program would break the nice encapsulation of the > UI. Was that already discussed ? Yes, this is a problem of course. Debconf may come in handy for feeding in pre-determined partition setups, and it could be used to ask every question needed to partition a disk, but it would be quite clunky. The simplicity of the UI you can create with debconf is both a weakness and a strength. > Another point is that the very beginning of the install process is not yet > clear in my mind. I understand that the boot image would include one > or several retrievers (and their dependencies) in order to let the system > get other modules for continuing the install but since we also want > autodetection of hardware, this will also have to fit in that boot image > (at least to autodetect the medium that will be used to retrieve the rest > of the install), no ? Yes, there's really no other way it can be done. Oh, it's possible to have a two stage process, where a simple to set up retriver (like one that grabs files from floppies) is used to download what's needed to use a more complex retreiver. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] Full CDROM install
[ I'm sorry for the delay, I've been busy with some projects outside of Debian, and some release-critical stuff inside it. Of course you'll get this with an extra week of delay too, since I'm camping ATM. ] Raphael Hertzog wrote: > i have to provide a simpler install for a specialized distribution that I > work on. And I'm using Debian. I'd like to use this opportunity to > contribute to debian-installer. This is excellent! I had hoped that the first working debian-installer would be able to do network installs, and it's not too far away. I think actually that the peices it's missing are all required for the cdrom installer (partitioning, debootstrap interface). I'll be really happy when we get a working cdrom installer (or any working install via d-i). We might just get two for the price of one.. > - a debconf database is setup using parameters from syslinux This could be pretty easy to do, depending on if syslinux allows specification of things like foo/bar=baz on the command line, and if the command line can be sufficiently large. If it does that could seed values in a debconf database. > - the setup after reboot should be configurable, ie each udeb should be > able to provide a script that would be launched at the first boot. > In that way the traditionnal setup could easily be replaced by an > automatic install of packages for example (skipping tasksel). You want to drop files in /usr/share/base-config/, see base-config(8). I'm not sure I understand why udebs are supposed to be doing this though, and not proper debian packages. And I wonder what you need to add to the base-config process. > And here are some open questions, can I programmatically control the flow > of udeb modules ? I mean, actually it's controlled by > XBC-Installer-Menu-Item and the depends. But I'd like for example to > do an automatic partitioning when the disk is empty and let the user decide > of his partitionning when there's a FAT partition taking all the room. > Suppose that the automatic partionner and the manual partitionner are not > in the same udeb, can I do something like that ? My first idea is > that i'd have to have a partition-method-chooser that'd depend on > automatic-partitioner and manual-partitioner and that would launch the > corresponding program depending on its decision. Instead of using Installer-Menu-Item fields, you can programmatically do this via the menutest script mechanism. See doc/ui.txt. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
request: add keymap (sg-latin1)
hi is it possible to have "sg-latin1" keymap (that's for Swiss German Keyboards) in the installation? regards tarzeau / www.linuks.mine.nu -- Windoze not found: (C)heer, (P)arty or (D)ance? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tftp install for i386
Hi, Some time ago, someone ask if we could have tftp install for i386. The rational was lots of nic cards nowdays have bootprom/PXE integrated. And from my point of view, network install are faster that floppy/cd. The tftp boot image doesn't seem to have made it to bf-3.0.11. Any plan to support it ? Thank's. Fab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding aacraid support for i386 bf
(No need to CC, thank's)
Adam Di Carlo wrote:
>
...
> Well, there are two issues.
>
> (1) one or more of the the kernel-image-2.2.19-* packages we use must
> include these drivers. That's up to the maintainer of these
> packages, Herbert Xu.
Done in compat (cf. mail from herbert).
>
> (2) any devices in the root filesystem that we need must be there.
> Can you check that and see if there are any devices we're not
> supplying which need to be added?
Just checked the root.bin from compat in boot-floppy-3.0.11. The device
isn't
there.
That's what I got on a running PowerEdge :
$ ls -lisa /dev/afa*
174500 crw---1 root root 254, 0 Mar 17 17:17
/dev/afa0
174510 crw---1 root root 254, 1 Mar 17 20:47
/dev/afa1
And in attachement is the MAKEDEV.afa from RH/Dell.
Thank's,
Fab
#!/bin/sh
#devname="afa"
devname="aac"
device="afa"
mode="600"
major=`cat /proc/devices | awk "\\$2==\"$devname\" {print \\$1}"`
minor=`echo $1 | awk '{print substr($1,length($1))}'`
if [ $major ]
then
if [ "$1" != "" ]
then
if [ $minor -le 7 ]
then
rm -f $1
mknod $1 c $major $minor
chmod $mode $1
else
echo ""
echo "Usage:"
echo "$0 ${device}[0-7]"
echo ""
fi
else
echo ""
echo "Usage:"
echo " $0 ${device}[0-7]"
echo ""
fi
else
echo ""
echo "$0: Can not derive the major number for device $device."
echo ""
fi
Re: rescue.sh.use-flavour.diff
#include
Adam Di Carlo wrote on Sat Aug 18, 2001 um 12:40:24PM:
> This seems rather dangerous. Have you tested that this has no affects
> when using the compact or idepci flavors?
Your feeling was not wrong, the patch will break. Please revert the last
patch if applied, and take the one in attachment (tested this time).
BTW, there is also another patch, displaying the warning about minimal
partition size for ReiserFS.
Gruss/Regards,
Eduard.
--
Wenn einer träumt, bleibt es ein Traum.
Wenn viele träumen,
beginnt der Traum, Wirklichkeit zu werden.
--- boot-floppies-cvs.orig/rescue.sh
+++ boot-floppies-cvs/rescue.sh
@@ -11,9 +11,17 @@
# Write (or don't write) the install.sh script
#
write_installsh () {
+ local kverfl
+
if [ "x$noinstall" = x ]; then
+if [ -z "$subarch" ]; then
+export kverfl=$kver
+ else
+export kverfl=$kver-$subarch
+fi
+
m4 -D__ERROR_MESS__=$scripts/messages/$language/install.sh.txt \
- -D__version__=$kver -D__arch__=$arch \
+ -D__version__=$kverfl -D__arch__=$arch \
<$scripts/install.sh >$mnt/install.sh
chmod 755 $mnt/install.sh
fi
--- boot-floppies-cvs.orig/utilities/dbootstrap/partition_config.c
+++ boot-floppies-cvs/utilities/dbootstrap/partition_config.c
@@ -193,6 +210,14 @@
_("Note on Dvhtool installation"));
#endif
+ if(is_rfs && ! bootargs.isquiet)
+ wideMessageBox(_(
+"NOTE: if you plan to create an Reiser filesystem, don't forget the\n"
+"additional space that its Journal will eat up.\n\n"
+"Usually you can calculate with: (partition size) = \n"
+"(expected free space on ReiserFS) + (32MB for the Journal)\n"),
+_("Note about additional space for Journal"));
+
if ( NAME_ISEXE( "/sbin/cfdisk", &statbuf )
#if #cpu(powerpc)
&& ( strcmp(Arch2, "PowerMac") != 0 )
PGP signature
cvs commit to boot-floppies/s390-specials by gt
Repository: boot-floppies/s390-specials who:gt time: Sun Aug 19 07:17:54 PDT 2001 Log Message: Added inetd.conf, special inittab for s390 and parmfile containing kernel parameters. Files: added: inetd.conf inittab parmfile -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies/s390-specials by gt
Repository: boot-floppies/s390-specials who:gt time: Sun Aug 19 07:14:57 PDT 2001 Log Message: Directory /cvs/debian-boot/boot-floppies/s390-specials added to the repository Files: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies by gt
Repository: boot-floppies who:gt time: Sun Aug 19 07:14:43 PDT 2001 Log Message: Content of parmfile moved to s390-specials. Files: changed:release.sh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies by gt
Repository: boot-floppies who:gt time: Sun Aug 19 07:13:51 PDT 2001 Log Message: Content of inittab and inetd.conf moved to s390-specials. Files: changed:rootdisk.sh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Still no base tarball
On Sat, 18 Aug 2001, Ethan Benson wrote: > so the basedebs.tgz file should NOT be present on offcial Debian CDs, As sombody else pointed out, this might not be a good idea, as: > reasons a hard disk install might be desired are: > > * lack of CDs > * lack of CDROM > * lack of decent network connection (read the connection requires junk > like ppp or pppoe) * lack of CDROM on a specific computer, but that is connected to an computer with CDROM * computer, that has CD but this CD is not supported by Linux. I think in this situations an hard-disk install should be possible only with an CD. (And though the CD should IMHO contain this base tgz). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
