Le Fri, Oct 19, 2001 at 04:58:53PM -0400, Joey Hess écrivait: > Looks interesting, but I'll let it sit for a while since we're not > aiming at cdrom installs quite yet.
Hopefully it won't be too far away ... once you have a working network installer, it'll be a matter of hours to have a working cdrom installer. And I'll gladly do it. > Nice peice of work. I do think a lot of what it does probably needs to > be split out, and I am trying to think of a reasonable way to split up > the process into reasonable chunks without too many interdependancies. Yes, we need to find out how to split the process so that parts of it can be easily replaced (or choices provided). > But I really like the idea of what this is and what it does. Would be > great to see this, manual partitioning, and [c]fdisk all on a menu to > chose from at install time. Yes, I agree. > > And it writes /etc/windows_part with the name of the > > bootable windows partition found. > > Was that some special requirement of your project? We can just comment > it out.. Oh, grub setup, I see. Clearly it is useful for the bootloader > setup to have hints about what is the root partition, and what other > partitions need to be bootable too. Exactly, I used it to add an entry in the bootloader menu. Its place is not logically here but it was very convenient since libparted provided all the required information to identify the windows bootable partition. > > - 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 > > Hmm, what did you use that for? Several things : - creating a initrd file in the target system - copying the fstab file But well, all of this should be integrated in an udeb or another but I used that because it was convenient (no need for an udeb and easy modification) for many little tweaks. > Ugh. Ugh. I hope this doesn't keep us from using autopartkit. autopartkit was fine (although display is totally clobbered with such stupid long device names). I had troubles with grub-install however, I can't remember them however. > revision 1.81 > date: 2001/08/06 17:18:06; author: hertzog; state: Exp; lines: +38 -9 > * Makefile updated to build good floppies (with basic terminfo files) > and various things (status -> status.udeb) > > I confess I don't see the point of that symlink. Well, things are not consistent within debian-installer so I took the simple solution instead of the nice one... here's the problem : ./tools/cdebconf/src/dpkg-reconfigure.c:#define STATUSFILE "/var/lib/dpkg/status" ./tools/udpkg/udpkg.h:#define STATUSFILE ADMINDIR ## "/status.udeb" ./main-menu/main-menu.h:#define STATUSFILE DPKGDIR "status" > revision 1.82 > date: 2001/09/03 15:48:13; author: hertzog; state: Exp; lines: +12 -8 > * Better way of creating the required /dev files. > > I think that the rootskel udeb is just supposed to provide them. Why is > making them by hand in the Makefile better? The tree target is already > too big. I'm moving this to rootskel.. I had troubles with device files. IIRC although they were well created, when unpacked they were created as simple files (even when beeing root). 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]
