Re: di: seperate preperation and installation phases
On Tue, May 08, 2001 at 03:00:37PM +1000, Glenn McGrath wrote: > If we have a seperate preperation and installation phase then it would > make the installer more versatile. > > The actual installation phase could be much like what debootsrap does, > and the preperation stage would involve preparing an environment for > deboostrap to run. FWIW, I'm working on something like that too (and hope I can show the alpha for the Debian Conference). The strategy is : Phase I : bootstrap a minimal OS making the detection of the hardware and the software installed on the machine. Send a descriptive file to a kind of "master" Phase II : the master takes the decisions (interactively or not) and gives "orders" to a build daemon which builds kernel (there is no relationship between the initial OS and the kernel built), servers/modules, rootfs Phase III : master gives instruction for the installation of the machine, whether as a TX, TA or standalone; in this case : partitionning, downloading a package with the OS built. Phase IV : machine reboots and is up for customization When one has no "master", I can imagine that the descriptive file could be sent via http to a cgi script building the orders. One takes back its customized "package" (a fake one, with rules and no data but orders for retrieving packages), gives it to the minimal OS which installs according to that with resources on a CD, or from the net, etc... BTW, I have designed a new packaging system, with a new package format, that could be a proposal for a common basis for other packaging system. The initial OS is : busybox, uClibc, _ash_ as a shell, Linux at the moment but I'm not quite sure I will not go the FreeBSD way sooner or later. It could seem that I'm reinventing the wheel, but I have found that even when facing a huge task, it takes me less time to do it by myself than trying to convince others that it is worth working on it /*sigh*/. -- Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France http://www.cri74.org PingOO, serveur de com sur distribution GNU/Linux: http://www.pingoo.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
building the cvs snapshot: pointerize troubles
hi all i've been trying to make the cvs-snapshot. make check succeeds, but make fails with: make[3]: Entering directory `/home/fin/cvs/boot-floppies/utilities/dbootstrap' pointerize -m po/C.mo < floppy_merge.c >> build/floppy_merge.t.c String "Some important data was not read from the floppy disks. You floppy disk from the drive. " not found. make[3]: *** [build/floppy_merge.t.c] Error 255 any ideas? could it be because i got my packages out of unstable instead of testing? cheers, fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: di: seperate preperation and installation phases
Thierry Laronde wrote: > > BTW, I have designed a new packaging system, with a new package format, that > could be a proposal for a common basis for other packaging system. > Id be interested in hearing what you have in mind, do you have any details handy ? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: di: seperate preperation and installation phases
Thierry Laronde wrote: > > It could seem that I'm reinventing the wheel, but I have found that even > when facing a huge task, it takes me less time to do it by myself than > trying to convince others that it is worth working on it /*sigh*/. Yea, i know how you feel, it seems that there are a few of us that are going in our own direction. It would be good if we could organise ourselves a bit better, maybe some of us that have been going our own way should try and document (what we have done/what we intend to do) as a first step to possibly pooling our efforts. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to base-config/debian by joeyh
Repository: base-config/debian who:joeyh time: Wed May 9 08:24:55 PDT 2001 Log Message: * Galacian translations update. * Portuguese translation udate (yes, feel free to just commit next time) Closes: #96814 Files: changed:changelog templates.gl templates.pt_BR -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to base-config by joeyh
Repository: base-config who:joeyh time: Wed May 9 08:24:54 PDT 2001 Log Message: * Galacian translations update. * Portuguese translation udate (yes, feel free to just commit next time) Closes: #96814 Files: changed:apt-setup.templates.gl apt-setup.templates.pt_BR -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: di: seperate preperation and installation phases
On Thu, May 10, 2001 at 01:08:39AM +1000, Glenn McGrath wrote: > Thierry Laronde wrote: > > > > BTW, I have designed a new packaging system, with a new package format, that > > could be a proposal for a common basis for other packaging system. > > > > Id be interested in hearing what you have in mind, do you have any > details handy ? I'm, of course, still working on it, but here are some sketches of the directions I take. General idea : you obtain "products" by applying `rules' to `data'. So the package will always have a `rules' with, optionnally, data. But a package can consist only of rules. There is no data without rules. This format allows "task" almost naturally, but also to administrate by sending a package which consists only of rules (i.e. commands). In fact, a package is a tgz of a strictly compliant Bourne Shell script named `rules' (probably also "or a Makefile") "explaining" how to handle data placed in a subdirectory called... `data'. The format is defined to be able to be handled by a minimal system. data has the following constitution : ./data | |_RSC | |_BIN | |_CONFIG | |_DOC | |_INFO | |_MAN | |_SBIN | |_SRC | |_VAR The subdirectories MUST be considered as variable or symbolic names. There are two main files defining the system policy, that is `System.data' (defining what are the actual value of DOC for example --- this can be /usr/doc or /usr/share/doc ;) --- etc, defining the VERSION of the system, etc...), and System.rules defining system dependant subfunctions for the installation tool (at the moment, I work with the lightest and simplest possible, and this is all ash compliant script, invoking BB commands). The System.data allows to change the directories [these values are changed by the way packages are installed ; untrusted packages will go in directories prefixed by a "sand-box" directory ; a normal user can install a package ; but no non-root can deal with the core system etc...]. The System.rules allows to customize the administration of the packages. For example, if one decides to have a sysVinit style, this will be different from a BSD style. A function to insert and run a daemon is different too. So the packaging system defines a kind of API (a way to invoke a prototype, say install_daemon) but the internal details of the function IS NOT defined in the packaging tool but in the System.rules. One of the more "interesting" directory is the RSC one : this is the resource directory, which contains data used at installation time but not installed as files on the system. For example, to customize a package, one puts in CONFIG (which ordinarily will be /etc/$pkgname) files with, say, ##VARIABLE## strings. The file containing these installation time defined values are suffixed .template. The default values of these are put in files in the RSC directory, where the package tool can look in order to parse the templates. If none are defined -> interactive If one wants to customize a package and distribute it, he just adds a correct RSC directory to the tar.gz archive. The format of the package file must match as close as possible an organization of data in a tarball (the main package format is source ; in the system I'm building, the system calls build daemons to customize the packages, and put them in package servers, whose role is just to cache them). The name of "binary" package are built with the version of the system they match, and the architecture. If your version 1 is kernel_foo with libc_bar, a system whose System.data is saying that VERSION is 2.0 will search for binaries for that version and for the architecture. If there is none, the system asks the build daemon to build the correct version. This is an "ever upgrading" system [and this is theory; I have just started with the bootstrapping OS]. A system invokes an authoritative server telling him what are the pkgserver it is allowed to contact (the server sends back something closed to a sources.list with the name/IP of the server, the directories allowed, the protocole to use). The authoritative server serves also the signature of the packages and, if a package doesn't match a signature given by the authoritative server, even if it comes from an authorized server, the package is not installed. Updating the sources for the package is made by the package tool. At the moment, I simply use tftp, and http (and local source), since these ones are implemented in BusyBox. I have more to say but will work in order to have "lot" to show, I think during Debian Conference. Cheers, -- Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France http://www.cri74.org PingOO, serveur de com sur distribution GNU/Linux: http://www.pingoo.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: di: seperate preperation and installation phases
On Thu, May 10, 2001 at 01:13:35AM +1000, Glenn McGrath wrote: > Thierry Laronde wrote: > > > > It could seem that I'm reinventing the wheel, but I have found that even > > when facing a huge task, it takes me less time to do it by myself than > > trying to convince others that it is worth working on it /*sigh*/. > > Yea, i know how you feel, it seems that there are a few of us that are > going in our own direction. > > It would be good if we could organise ourselves a bit better, maybe some > of us that have been going our own way should try and document (what we > have done/what we intend to do) as a first step to possibly pooling our > efforts. I absolutely OK for that. Cheers, -- Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France http://www.cri74.org PingOO, serveur de com sur distribution GNU/Linux: http://www.pingoo.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to image_stuff by dwhedon
Repository: image_stuff who:dwhedon time: Wed May 9 12:48:29 PDT 2001 Log Message: This is the project. Status: Vendor Tag: e223 Release Tags: start N image_stuff/f.c N image_stuff/g.c N image_stuff/h.c No conflicts created by this import Files: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to image_stuff by dwhedon
Repository: image_stuff who:dwhedon time: Wed May 9 12:53:47 PDT 2001 Log Message: ick, I had the wrong cvs root, this is junk. Files: removed:f.c g.c h.c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to image_stuff by dwhedon
ugg, wrong CVSROOT. I removed the files from cvs. Could someone with the appropriate permissions remove the directory: dwhedon@klecker:/org/cvs.debian.org/cvs/debian-boot/ drwxrwxr-x2 aph Debian 4096 May 9 12:59 image_stuff Thanks, David Wed, May 09, 2001 at 12:48:29PM -0700 wrote: > Repository: image_stuff > who:dwhedon > time: Wed May 9 12:48:29 PDT 2001 > > > Log Message: > > This is the project. > > Status: > > Vendor Tag: e223 > Release Tags: start > > N image_stuff/f.c > N image_stuff/g.c > N image_stuff/h.c > > No conflicts created by this import > > > Files: > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies/documentation/en by kraai
Repository: boot-floppies/documentation/en who:kraai time: Wed May 9 13:17:43 PDT 2001 Log Message: Document that etherconf can be used after installation to configure the network. Files: changed:dbootstrap.sgml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: bug fixed
Processing commands for [EMAIL PROTECTED]: > tags 90204 fixed Bug#90204: [doc] document how to configure network after install Tags added: fixed > End of message, 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]
tasks: counterproposal (and implimentation)
Attached to this message is a tarball which contains a rather simple program that uses debconf to present the user with a list of tasks (sorted into groups). To try it, upgrade to debconf 0.9.53 (Incoming) [1], unpack, and run "newtasksel/tasksel -t newtasksel/tasklist" (or see [2] at the very end of this message). With that flag it will output a list of the packages you selected, suitable for feeding into dselect. You will probably then want to examine newtasksel/tasklist, which contains the definitions of tasks. The contents of this file are up for debate, and would be maintained subject to consensus on -devel or -boot. I just looked at all the existing task packages and took the ones that made sense to show a new user, filled in a few obvious holes, etc. Ok, that's the implementation, on the the proposal. I propose that we do away with all task-* packages, removing them from debian before woody is released. Maintainers who are attached to their task packages may want to reimplement them as meta packages (w/o the task- prefix). Task packages will not be used to define tasks, so we need something else. A centrally maintained file of task information (in fledgling form as the tasklist file I mention above) will be placed in debian cvs, and maintained cooperatively by the project. The file will be packaged up, presumably with a task selector tool such as my sample implementation, and included in the base system, and base-config will run this tool as it runs tasksel today. After running the task selection tool, which will mark packages for install with dpkg --set-selections, base-config will allow the user to run dselect, capt/deity, or some other apt frontend. This will let them override any packages a task pulled in which they do not need, select additional packages, be informed of recommands and suggests relationships, etc. Or, they can chose to not do this, and just let apt take care of things for them. (This step is provided in leu of a task selector tool that lets a user pick a task and "drill down" then and there to select packages. That would be nice, and an implementation is welcomed, but I didn't feel up to it today..) The tasklist file I have provided includes some guidelines about how it may be modified, and what type of things should go into it. I will not restate them here, but they are also part of my proposal. One final note -- if you look at the gnome, kde, and X tasks at the end of the file, you will see that they only pull in a metapackage or two. I did this in these three cases where we have large bodies of software, split amoung many packages, most of which should be pulled in by a task. It makes sense in those situations, I think, to put the control over the tasks' contents in the hands of whoever maintains that software. Metapackages are a perfect way to accomplish this. On the other hand, something like the games or web server task is better controlled by the project as a whole. I don't belive that policy need be modified at all for this to work, and I am looking for a rough consensus, not seconds. -- see shy jo [1] Or don't use debconf's dialog frontend -- but the dialog frontend is how people will see it, so I recommend you do use that frontend. [2] Here is a sample run with debconf's text frontend[1]. joey@silk:~/tmp/newtasksel>./tasksel -t tasklist Selecting software to install - A Debian system can be used for many tasks, a few of which we present here. Each item on the list represents a set of software that is useful for a particular purpose. You may select as many, or as few of them as you wish. d. Desktop: s. Server: a. - Gnome desktop environmentj. - dns server b. - KDE desktop environment k. - file server c. - X window system l. - mail server m. Misc: n. - news server e. - Debian Jr. (for kids)o. - print server f. - dialup systemp. - relational database server g. - gamesq. - shell server h. - laptop r. - web server i. - programming and development (Type in the letters of the items you want to select, separated by spaces.) What do you want to use this computer for? c m r x-window-system install apache install analog install junior-toys install junior-math install junior-typing install junior-arcade install junior-writing install junior-soundinstall junior-doc install anacron install diald install dialdcost install fetchmail install junkbuster install lynxinstall ppp install pppconfig install wgetinstall wvdial install wwwoffleinstall leafnodeinstall lftpinstall isdnutils install xtris install bsdgamesinstall nethack install xgalaga install xscavenger install koules install gnome-gnomine install gnome-card-gamesinstall lincity-x install apmdinst
cvs commit to boot-floppies/documentation by stephen.r.marenka
Repository: boot-floppies/documentation who:stephen.r.marenka time: Wed May 9 14:48:25 PDT 2001 Log Message: debiandoc.decl reanmed and moved in package debiandoc-sgml, fixes bug#96793 Files: changed:Makefile -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies/make by stephen.r.marenka
Repository: boot-floppies/make who:stephen.r.marenka time: Wed May 9 14:51:14 PDT 2001 Log Message: Let powerpc build using ROOTCMD. Files: changed:powerpc.rules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#96906: Base-install over net doesnt load lilo
Package: Boot-Floppies Version: 1.9 When installing the base system over the network, it doesnt install lilo. I noticed this when, at the last step, I couldnt make a boot floppy or a bootloader. I opened a console and tried to do it manually, and it sayed that I had to run the version installed in the target install. I did a find '/target -name lilo' and there were no matches. I reinstalled and I watched the network-install log, and it didnt appear to install lilo. I think that's an error. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
base-config cruft cleanup
I want to check and see if some of the uglier cruft in base-config can
be removed for the woody boot-floppies. Can anyone verify:
- If LANG is set, will it be properly set to a ll_LL form? Base-config
had some code to deal with the ll form, which broke perl. (I've
already removed that code.)
- Have any new settings been added to /root/dbootstrap_settings that I
should deal with?
- This code probably better belongs in console-tools or something. Do I
still need to keep it?
# Keyboard configuration.
# TODO: this doesn't belong here.
if [ ! -e /etc/console-tools/default.kmap.gz ]; then
if [ "$KEYBD" ]; then
# do automatic configuration
loadkeys /usr/share/keymaps/${KEYBD}.kmap.gz
dumpkeys > /etc/console-tools/default.kmap
gzip -9fv /etc/console-tools/default.kmap
elif [ "$SERIALCONSOLE" ]; then
# we are on serial console -- no kbd config at all
dpkg --purge console-data console-tools console-tools-libs \
/dev/tty || true
elif [ ! -f /etc/console-tools/default.kmap.gz -a -f /bin/loadkeys ];
then
# no file -- ask user
kbdconfig /dev/tty || true
if ! loadkeys /etc/console-tools/default.kmap.gz; then
db_input critical base-config/keymap-failed
db_go
fi
fi
fi
- Is pcmcia handled more sanely now that we use debootstrap? It used to not
be in a package, just dumped onto the filesystem, so I have this code:
echo pcmcia-cs purge | dpkg --set-selections
echo pcmcia-modules-`uname -r` purge | dpkg --set-selections
# In a sane world, I would not need to do this. Welcome to my world.
rm -rf /etc/pcmcia /lib/modules/`uname -r`/pcmcia
depmod -a >/dev/null || true
# Delete lines above if/when those files are registed with dpkg.
- From my TODO:
* Aph can add dboostrap_settings info that says where they got base.tgz
from. This might be able to be used to tell where the archive they used is.
Updating that thought to the present, if debootstrap downloads packages from
the net, we know whatever server it used works for this system, and if that
server could be written to dboostrap_settings, it would make a good default
for apt-setup.
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Web Hosting for $9.95
Web Hosting at it's best. Free Domain Name Transfers. New Domain Name Registration. Free Site Transfer. 100 Mb Disk Space. Plus alot more for a low monthly fee of $9.95. Don't miss out on this limited time offer. Don't have a web site? No problem. We can build one for you. Need more disk space? No problem. We have additional plans to choose from to suit your needs. Call 1-813-431-8032 for details. If you received this email in error, or you wish to be removed from our mailing list, send an email to [EMAIL PROTECTED] with remove as the subject. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: di: seperate preperation and installation phases
There are two things that I would like to see in a new installer that I don't see in debian-installer at the moment: 1. The ability to redo some of the installation after the system is all the way set up. I would like to see the same utility, same user interface, that people can use to modify an existing installation. For example adding new hardware or reconfiguring the network, setting the timezone. FreeBSD does this, it is very cool. 2. An install system that isn't inherently Debian or Linux specific. I would love to see an system that was designed from the ground up to support a wide variety of platforms. This is a real tough one. Maybe it doesn't make sense, but I'd rather see us developing something that can be used by non-Debian systems (like apt). I want to be careful about changing the design of debian-installer though because we have made it a long way and if we don't get the new installer finished soon we'll be stuck with boot-floppies again for woody+1. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to boot-floppies/utilities/dbootstrap by dwhedon
Repository: boot-floppies/utilities/dbootstrap who:dwhedon time: Wed May 9 23:57:09 PDT 2001 Log Message: If we install over the network write the known good hostname to dbootstrap_settings as the variable DEBIAN_MIRROR Files: changed:extract_base.c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-config cruft cleanup
> - From my TODO: > > * Aph can add dboostrap_settings info that says where they got base.tgz > from. This might be able to be used to tell where the archive they used is. > > Updating that thought to the present, if debootstrap downloads packages from > the net, we know whatever server it used works for this system, and if that > server could be written to dboostrap_settings, it would make a good default > for apt-setup. I just did this, it is called DEBIAN_MIRROR in dbootstrap_settings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
