I have done some preliminary work on getting the debian-installer to work as an "application". So far, I've only done this with the 'net' live image, and the 'netboot' installer. I had some trouble getting the installer images to begin with, since I've been using a reprepro generated mirror to get the packages from. The reprepro program doesn't hold anything but deb's and sources, and generates lists for those. I had to make a small one-liner script to help with this. Here it is, in case anybody else is interested. wget -m -nH --cut-dirs=1 -L ftp://debian.mirrors.tds.net/debian/dists/lenny/main/installer-i386/current/images Replace the host with the debian mirror of your choice. Replace the i386 if you need to. Make sure that it's an ftp url, as http will not work correctly here (trying to save y'all a headache here). This command needs to be run in the base directory of your local mirror. It would probably be good for live-helper to make a new variable, such as LH_MIRROR_CHROOT_DI_IMAGES, to distinguish this mirror from the LH_MIRROR_CHROOT. This would help when the chroot mirror doesn't carry the d-i images. Once I got the images mirrored, I was able to start working on the installer. The initrd.gz can't be loop mounted anymore. I had forgotten about this. I remember that they used to be cramfs images, but they are now cpio archives (at least since sarge, I think). What I did was to extract them into a directory that I would later chroot into. As far as the 'net' live image, and the netboot installer are concerned, I had to use atftp to retrieve the image, so this package should be automatically installed in the live image when LH_DEBIAN_INSTALLER is enabled, and the live image is of the 'net' type. I will probably only be able to test the iso type additionally, since I'm doing all the work on virtualbox VM's. I'm using a VM to run live-helper and build the images, so in order to boot a testing VM, I need to get the iso from the guest to the host before running another VM to test that iso. That's not that big of a deal, but it's a tad inconvenient. I may not be able to do much with the usb images, but I can possibly use a .vdi file in place of that. That's all in the future, as there is enough to do to just get the installer working properly as it is. The VM that I'm using is set to 128MB of ram, and half is allocated to the tmpfs filesystem. Extracting the initrd (for the netboot without gtk) takes about 15MB of space in ram. The VM is just a simple console system. I am attaching some scripts. They are particular to the 'net' image, netboot configuration that I'm using, but the basic idea should work with any of the images (at least the console images). These scripts are rather hacky, and are only a means to see what must be done to just get the menu up and running. The mount-initrd-netboot script does nothing but grab the inirtd.gz from the tftpserver, extract it, and run the chroot-debian-installer script. This script uses the nfsroot ip as the tftp server, and needs to be more accurate about getting the address of the tftp server. This script also bind mounts /lib/modules , as it's likely that the kernel that the installer expects won't be the run that's running on the live system. The /dev directory is also bind mounted, although I'm curious as to whether this is proper or not. The chroot-debian-installer script is the script that does most of the work and is responsible for bringing up the installer menu. This one took quite a while to get into the state of just starting the menu. I felt like I was weaving through a maze of scripts, trying to determine which ones were necessary and which ones should be skipped. I tried to make note of the scripts that I used. Many scripts are there to enable the framebuffer and setup the terminal, which I skipped. Others are using /proc/cmdline to determine other options (and some of this needs to be replaced with command line options to the script (application) that will eventually be running). Still, other scripts are there to determine if the memory is adequate to run the installer, or how to run the installer based on the available memory. I skipped those scripts too. I tried to run the scripts that seemed necessary (or really just pasted them into this script). Some scripts that were responsible for setting up environment variables were skipped, and the variables hardcoded. I tried to mention this in the scripts, but I likely left things out of it. The menu does start, and it runs with a few errors. It hangs as soon as it gets to the partitioner, and the whole system seems to go "offline" and the nfs filesystem stops responding. Starting the menu, and immediately selecting "Abort the Installation" will freeze the menu also. There are some things that the live system should preseed based on the information in it's debconf database, such as the keyboard, console, etc. The maintainence of doing things this way will be a nightmare, and I'm only hacking now to get things started. I think that the scripts in /lib/debian-installer*.d/ should have comments in them that would help determine whether or not they should be run by this method. This way, the init (run-parts) script that's responsible for running these scripts can be modified with a grep command (that's executed on the existence of an environment variable) to determine whether to run that particular script or not. This can be done with the help of the d-i maintainers, and not affect the normal usage of the installer. I think that it is a flaw in the way that the debian-installer has been designed/developed to make it run exclusively in a constrained busybox environment. I think that much of what the debian-installer does has an important use in areas that aren't so constrained. The partman-* packages, the automation, and the debconf configuration are particularly valuable and can serve a purpose on a system where more is possible. The d-i team has done a very good job of making partitioning a breeze, and making it automated if required. I think that it's a shame that there is a barrier for getting this to work on a live system. Keeping these good tools locked in this particular environment is something that has been aggravating me since sarge. I'm hoping that the work I'm doing will help the d-i team see that there is another use for the installer that they haven't seen yet, and hopefully inspire them to keep this use in mind as they develop. I don't think that the work in this area will be extensive in the long run, although it may take quite a bit initially. I think that in the long run, work in this area will actually make the debian-installer the universal installer it was meant to be. I think that before I do too much poking around blindly, I'll read the debian-installer internals part on the wiki. The wiki is down at the moment, but I think that reading it will prove to be better than just messing around, since I still don't have a good enough understanding of exactly what the installer does through all it's phases. I'm hoping that this here is enough to give y'all some insight on the difficulties in running the installer from the live system. If y'all are serious about running the debian-installer as an 'application' you should be prepared to work with the d-i team to help make this possible, otherwise maintenance of the work that will be required will probably be burdensome. -- Thanks: Joseph Rawson
Attachment:
mount-initrd-netboot
Description: application/shellscript
Attachment:
chroot-debian-installer
Description: application/shellscript
Attachment:
cleanup-initrd-netboot
Description: application/shellscript
Attachment:
signature.asc
Description: This is a digitally signed message part.