applet: read disk partition only
Ive been thinking about partitioning, there are lots of compromises with existing tools. I think it would be more flexible to have a cleaner sepeartion between existing tools, so the task can be done in more descrete steps. 1) detect devices 2) detect partitions 3) detect filesystems 4) create/modify partitions 5) create/modify filesystems Advatage of breaking it up is that only the needed tools have to be provided. parted does a very good all round job, but it has to be pretty big to support all those features. I hacked up libfdisk and made a small busybox appplet (rdisk, i.e. read disk) that provides a similar output to fdisk -lu e.g. home:/home/bug1/dev/busybox# ./busybox rdisk /dev/hda Disk /dev/hda: 20.5 GB = 40160988 sectors Units = sectors of 1 * 512 bytes Device BootStart EndBlocks Id System /dev/hda16336499936+ 82 Linux swap /dev/hda2 *36 1976688488376 83 Linux native /dev/hda3 1976688 4905936 1464624 83 Linux native /dev/hda4 4905936 40160736 176274005 DOS Extended /dev/hda5 4905999 10765440 2929720+ 83 Linux native /dev/hda6 10765503 40160736 14697616+ 83 Linux native fdisk could be used directly, but you have to take the partition creation/modifciate capability with it... and you dont know wether that is needed, or which tool(s) are best used (parted / cfdisk / raidtools / lvm stuff) untill after you see the current state Similar information could be gathered by parsing /proc/partitions, but you dont get the partition type which can be quite usefull for identifying partitions, also it is kernel dependent. What ive done is only experimental, it only detects standard msdos partitions, if its going to be usefull i will have to put a bit of stuff back in. As it is it only adds 4kB to the busybox udeb, a patch is at http://people.debian.org/~bug1/busybox/rdisk.diff It would be pretty trivial to change the format so that it could be more easily parsed or whatever and trivial -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to debian-installer/tools/kdetect by bug1
Repository: debian-installer/tools/kdetect who:bug1 time: Wed Feb 21 07:22:34 PST 2001 Log Message: Application to use the library for testing purposes Files: added: test.c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to debian-installer/tools/kdetect by bug1
Repository: debian-installer/tools/kdetect who:bug1 time: Wed Feb 21 07:23:09 PST 2001 Log Message: make test Files: changed:Makefile -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to debian-installer/tools/lmod-detect-pci by bug1
Repository: debian-installer/tools/lmod-detect-pci who:bug1 time: Sat Aug 4 21:44:10 PDT 2001 Log Message: Directory /cvs/debian-boot/debian-installer/tools/lmod-detect-pci added to the repository Files: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to debian-installer/tools/lmod-detect-pci/debian by bug1
Repository: debian-installer/tools/lmod-detect-pci/debian who:bug1 time: Sat Aug 4 21:44:44 PDT 2001 Log Message: Directory /cvs/debian-boot/debian-installer/tools/lmod-detect-pci/debian added to the repository Files: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to debian-installer/tools/lmod-detect-pci/debian by bug1
Repository: debian-installer/tools/lmod-detect-pci/debian who:bug1 time: Sat Aug 4 21:47:48 PDT 2001 Log Message: Updated pci database based on Thierry Laronde's pci-id table, it now knows about 120 pci modules Files: added: changelog control copyright rules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to debian-installer/tools/pcidetect/debian by bug1
Repository: debian-installer/tools/pcidetect/debian who:bug1 time: Sat Aug 4 21:47:48 PDT 2001 Log Message: Updated pci database based on Thierry Laronde's pci-id table, it now knows about 120 pci modules Files: removed:README.Debian changelog control copyright dirs pcidetect.1 postinst postrm preinst prerm rules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to debian-installer/tools/lmod-detect-pci by bug1
Repository: debian-installer/tools/lmod-detect-pci who:bug1 time: Sat Aug 4 21:47:48 PDT 2001 Log Message: Updated pci database based on Thierry Laronde's pci-id table, it now knows about 120 pci modules Files: added: Makefile lmod-detect-pci.1 lmod-detect-pci.c pci_ids.h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs commit to debian-installer/tools/pcidetect by bug1
Repository: debian-installer/tools/pcidetect who:bug1 time: Sat Aug 4 21:53:39 PDT 2001 Log Message: Renamed to lmod-detect-pci Files: removed:Makefile lst_net.h lst_net_1000.h lst_net_10_100.h lst_net_arcnet.h lst_net_other.h lst_net_tokenring.h lst_net_wan.h lst_net_wlan.h pcidetect.c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Booting X
Adam Lininger wrote: > > I installed version 2.1 and configured X. Now it automatically boots into a collored >screen that asks for the login name and password but after I type them in it gives me >a blue screen with an icon in the lower left corner. The mouse doesn't work and each >key results in a beep and nothing else. What wen't wrong and how do I stop it from >boooting into X. > --- > Adam Lininger > mailto:[EMAIL PROTECTED] > Sounds like you have installed xdm (or gdm), you could remove it with apt or dselect. You should still be able to get to the console by pressing ctrl-alt-f1 If your mouse and/or keyboard arent working try setting it up again with XF86Setup Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to set up an install server ?
"Karl M. Hegbloom" wrote: > Joey Hess has started a design document for the Woody > installation system. Look in the archives for it. > In CVS? could you please give a few more pointers as to where it is. I looked but i didnt really know where to look or what to look for. Thanks Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[woody] What are the plans so far.
Joey, i have some ideas of how woody boot floppies could work and would like to see how close they are to yours, or what are the curent plans for woody? Some things ive been thinking are base.tgz could be created on the fly if someone has access to the debian archive. An intermediate install could be installed to either ramfs (or ramdisk) or a loopback filsystem depending on the local systems available resources. Busybox can unpack debs (one ar.c patch pending that fixes extracting newer debs) so if the install disk had enough to contact the debian archive (net, hd, cd whatever) then busybox could unpack dpkg*deb or apt*deb and its dependencies with busybox ar, gunzip and tar. Then apt of dpkg could install the rest of base to either loop or ramfs before doing a chroot or pivot. This interim install should have enough to repartition, maybe resize ext2, fat partitions, if on a loopfs then it may be possible to have a raid1 or lvm mirror of two loopfs's, each on a seperate drive or partition if available, that way the whole drive could be repartitioned without destroying the loopfs. The interim installer would be independent of what is actually being installed, ie there could be a linux interim install which actually installs debian/linux, debian/hurd or even debian/bsd or debian/plan9, who knows what will be available for woody. Glenn IkthcmwgTS4gSGVnYmxvb20iIHdyb3RlOgo+ICBKb2V5IEhlc3MgaGFzIHN0YXJ0ZWQgYSBk ZXNpZ24gZG9jdW1lbnQgZm9yIHRoZSBXb29keQo+ICBpbnN0YWxsYXRpb24gc3lzdGVtLiAg TG9vayBpbiB0aGUgYXJjaGl2ZXMgZm9yIGl0Lgo+IAoKSW4gQ1ZTPyBjb3VsZCB5b3UgcGxl YXNlIGdpdmUgYSBmZXcgbW9yZSBwb2ludGVycyBhcyB0byB3aGVyZSBpdCBpcy4KSSBsb29r ZWQgYnV0IGkgZGlkbnQgcmVhbGx5IGtub3cgd2hlcmUgdG8gbG9vayBvciB3aGF0IHRvIGxv b2sgZm9yLgoKVGhhbmtzCgpHbGVubgoKCi0tIApUbyBVTlNVQlNDUklCRSwgZW1haWwgdG8g ZGViaWFuLWJvb3QtcmVxdWVzdEBsaXN0cy5kZWJpYW4ub3JnCndpdGggYSBzdWJqZWN0IG9m ICJ1bnN1YnNjcmliZSIuIFRyb3VibGU/IENvbnRhY3QgbGlzdG1hc3RlckBsaXN0cy5kZWJp YW4ub3JnCgo=
Re: Linux-2.4.0-test1-ac18 + Reiserfs 3.6.9 (patched) kernel rescue disk!
[EMAIL PROTECTED] wrote: > > Hi new to the list. Trying to get the Linux-2.4.0-test1-ac18 + Reiserfs 3.6.9 >(patched) ???????? > kernel rescue disk to work, but get a "Unable to find swap-space signature" and >"Sorry, ???????? > your computer does not have enough memory." after the root disk is loaded. Anyone >orry, ???????? > know a fix? > does not have enough memory." after the root disk is loaded. Anyone orry, >???????? > > ??? fix? > does not have enough memory." after the root disk is loaded. Anyone orry, >???????? > -Rolf > fix? > does not have enough memory." after the root disk is loaded. Anyone orry, >???????? > > ??? > fix? > does not have enough memory." after the root disk is loaded. Anyone orry, >???????? > IDE RAID(0) + Reiserfs == :( > ough memory." after the root disk is loaded. Anyone orry, ???????? > "not enough memory" is a problem with busybox init and the 2.4 kernel, it is fixed in the busybox cvs (i pretty sure), but hasnt been integrated into debian boot floppies yet. If your after new raid0, you could patch 2.2.x kernel with the raid 0.9 patch, as for reiserfs im not sure why you want it on the floppy ? After you install base you can use any kernel you want. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody,debinst] (Was: Re: [dbootstrap] `newt' and `boxes.c', `bogl' and `bowl'[, `???' and `boxeX.c'?])
"Karl M. Hegbloom" wrote: > > > Karl> I discovered today that the `boot-floppies' "root.bin" has the entire > Karl> libnewt.so on it, rather than a subset as I had assumed previously. > Karl> I somehow never noted that there's a libslang.pic, but not a > Karl> libnewt.pic. > Talking about newt, did you know there exists gnewt, its a gnome wrapper around newt, not directly usefull to us, but who knows, could come in handy. http://oksid.ch/gnewt/ > Bruce> I hadn't got as far as looking at what is available yet, it's a variable > Bruce> anyways ;). Has anyone created a map of the structure yet (how the > Bruce> installation will be modularized, etc.)? > > Yes. Joey Hess has started a `debinst' repository on kitenet.net. > > http://kitenet.net/cgi-bin/cvsweb/joey-cvs/public/packages/debinst> > > (Joey? Please let me know if that's not meant for public > consumption. If that's the case, can you please move it to c.d.o?) > I checked it out, hasnt been updated for a few months, is it still "the" plan ? > The Woody `debconf' uses Perl and a really neat toolkit written by > Joey Hess called `libterm-stool-perl', which in turn uses > `libterm-slang-perl'. Perl is way to large for the boot floppy, at > least for the first stage. > I cant hold on any longer, here is what ive been thinking. All the boot floppy has to do is be able to locate the debian binaries, then busybox ar , tar and gunzip can unpack the binaries to temperary filesystem, either ramdisk (or ramfs) or loopfs This would be a pretty doddgy way to install a deb, but ok for an emergency. Once the installer can access the debian binaries it can unpack dpkg-deb and its dependencies which are libc, libstdc++, ldso and libncurses (only for dselect). Once dpkg-deb is available it can easily install apt and debconf to the temperary filesystem. Once these (apt, debconf) are running on a temperary filesystem we are home free, we could just have a virtual package called install.deb and/or install-stage-.deb, this virtual package could contain the next stage of the installer which will fetch any other packages required (apt --fix-missing) and fill out the temperagy filesysytem. I think having a static install.deb is important as it allows us (install team) to divorce ourselves from the current status of base, we dont have to do anything if base packages change, the isntaller will automatically fetch the latest versions of each package. The temperary filesystem should eventullay have partitioning tools, hardware detection (libdetect?), other GUI's etc. Partitioning could be done via debconf. I think it should be possible (but tricky) to repartition under a loopfs (using LVM mirroring) providing that there is more than one disk/partition on the target source. Other option would be to install to ramdisk and resize the one partition (if ext2 or fat) or else the only option would be to do destructive install An intermediate installer like this i think would make life really simple for installing GNU/Hurd, or GNU/FreeBSD, or GNU/Plan9 whatever is about at the time. The intermediate installer would always be linux, but that doesnt matter non linux stuff is just files, fine tuning can be done after a reboot in the native OS. The kernel should not be a general purpose kernel, it should specifically be for floppies. All the boot floppies and boot kernel *needs* to do is be able to contact to debian binary archive (or a subset of it), after that space shouldnt be a problem. So my thoughts are that we should be able to do a read-only non-destructive installer to handle foreign (non-linux) OS's and it should be able to fit on 1 floppy. > We really need `dpkg' to have the ability to filter what it installs, > and to mark the installation as having been partial. It should be If we use an interim install partition then we can do a "trashy" install for the interim installer as long as it doesnt effect the final install. (maybe this is taking you out of context though) > possible to install everything but documentation, or conffiles only, > etc. This way, you can install most things only on a NFS file > server, but still have configurations installed on each host, with > automatic updating via `dpkg' available. You should be able to > change your mind, and say something like `apt-get --docs-only install > PKG', or something like that. I'm not the one who can design that. > > Hmmm... `dpkg-reconfigure dpkg'? dunno. This is Joey and the > `dpkg'/`apt' developer's department. > > Karl> The main menu could be nicer also... anyway, if you've any good > Karl> ideas, let me know. I'll be on IRC all evening. > > Bruce> I don't see why any of the installation ought to be serial. > > Right. I've grabbed Red Hat's `anaconda' package, which is their > installation system. It's worth haveing a look at. Most of it is > written in Python, with both a `newt' and `gtk' interface. I'v
Re: [woody,debinst] (Was: Re: [dbootstrap] `newt' and `boxes.c', `bogl' and `bowl'[, `???' and `boxeX.c'?])
Ben Collins wrote: > > Also, I'm looking into a program on freshmeat called genext2fs that can > create ext2 images from a directory (and using an optional device list for > devices) as non-root. Would be very nice for woody boot-floppies, IMO. > It's a single .c, so could go into utilities if it doesn't get packaged. > Im a bit slow sometimes, how would it be used by boot-floppies? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody,debinst] (Was: Re: [dbootstrap] `newt' and `boxes.c', `bogl' and `bowl'[, `???' and `boxeX.c'?])
"Karl M. Hegbloom" wrote: > Karl> newtGrid's and whatnot. I'm going to start learning Newt, and see > Karl> what I can come up with. Karl, if you havent found this newt tutorial already, its at http://oksid.ch/gnewt/tutorial.html Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody,debinst] (Was: Re: [dbootstrap] `newt' and `boxes.c', `bogl' and `bowl'[, `???' and `boxeX.c'?])
Erik Andersen wrote: > > On Sat Jun 17, 2000 at 12:02:51AM -0400, Ben Collins wrote: > > On Fri, Jun 16, 2000 at 09:44:31PM -0600, Erik Andersen wrote: > > > On Sat Jun 17, 2000 at 01:29:43PM +1000, bug1 wrote: > > > > > Red Hat's `libfdisk' contains a partition editor with a `newt' > > > > > interface. It might be possible to port it to our system and hook > > > > > that into our Woody `debinst' `dbootstrap'. > > > > > > > > > What about parted, it doesnt have much a of a GUI, but it wouldnt be > > > > hard to do i dont think. > > > > I think the ability to resize existing partitions (non destructivve > > > > install) is one most users would really like. > > > > > > Agreed re parted. I think a cool project would be hacking a GUI similar to > > > cfdisk into parted... > > > > Better get parted to support more than just msdos partitions before we > > even thing of using it in boot-floppies :) > > ??? > Parted supports ext2. > http://freshmeat.net/appindex/1999/09/19/937790960.html > > -Erik I think Ben meant msdos partition *tables*, ie parted doesnt support partitioning schemes that arent native to i386 architecture. This got me wondering , exactly what other types of partition tables would need to be supported by parted ? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[woody,debinst] keeping track of plans
Karl mentioned something on this in another post, there are lots of ideas floating around, maybe we do need something other than emails and cvs to keep track of everything. What about a web page or something? I guess the issue is, would the benefits of maintaining a web page for the development of the debian installer be worth the effort. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody,debinst] Interim filesystem
Joey Hess wrote: > I think this would require a minimum of 16 mb of disk space, and > probably a bit more. Since with ramfs, disk space == memory, this > would limit installations to systems with around 20-32 mb of memory. > I don't think that's very acceptable. > > I don't see how you could use loopfs without having first > identified, partitioned, formated, and mounted a disk. If you're going > to do that, then you might as well use my original proposal about > this[1], which uses modular code to get the partitioning and so on done, > downloads and extracts a base tarball, then chroots into it for the > rest. > How and Interim filesystem might work (as i see it) There are a four possible alternate install paths at this stage. 1) Interim filesystem in memory. 2) Interim file on a local disk in its own partition. 3) Interim filesystem via network 4) Interim filesystem on an existing local filesystem via loopback device Case 1 : RAMDISK, RAMFS : This is likely to be the simplest and fastest option, but would not work on lots of systems due to large memory requirements. Case 2 : TRADITIONAL : This is the traditional method used, it requires partitioning prior to setting up any nonram filesystems, if this method is taken there aren't really any advantages to an interim filesystem. This method placer large limitations on space for the initial boot media which in turn limit the functionality of the install. Case 3 : NETWORK : The interim filesystem could be mounted from a remote host e.g. NFS, (SMB?), it would probably require a small amount of temporary write access somewhere. This remote interim filesystem could be used for multiple different installs from different hosts, it would require the same complexity as if the binary deb archive were sourced from the network. This method would be slow (depending on network speed) but would place minimum requirements on local hardware (except network card) more space on boot-media for net-tools, and there earlier configuration would add extra complexity compared to a local install. Case 4 : LOOP : By placing an extra filesystem layer between the interim filesystem gains some independence over its local storage. The active loop filesystem is contained on multiple mirrored loop filesystems on local writeable partitions. Mirroring can be done with raid mode 1, this way if one of the loop files is destroyed it can be rebuilt in another place. This method would allow us possible to totally repartition the local storage, the only restriction is that it cant be done in one big hit, which would mean that path *might* not be available to machines with one drive, one partition, or if there is there is no room on mountable partition for the loop files. I have actually tried implementing something like this till today, ive had some success, but also two OOPS's which i will try to track down later. This is what i was doing, to do this you need a kernel with raid mode1 support, # Create two loop filesystems in some directory, # practically disk1 and disk2 should be different drives, at least different partition. # for the test will use the same dir dd if=/dev/zero of=./loopfs1 bs=1k count=2 dd if=/dev/zero of=./loopfs2 bs=1k count=2 # mount the two files on loop devices losetup /dev/loop1 ./loopfs1 losetup /dev/loop2 ./loopfs2 # Create an etc/raidtab file containing raiddev /dev/md0 raid-level 1 persistent-superblock 1 # or 0, shouldn't matter chunk-size 16 nr-raid-disks 2 nr-spare-disks 0 device /dev/loop1 raid-disk 0 device /dev/loop2 raid-disk 1 # make the loop files into raid devices mkraid /dev/md0 # now treat it like a normal block device mkfs.ext2 /dev/md0 mount -t ext2 /dev/md0 /mnt # Say the filesystem/partition containing the loop1 file had to be destroyed # to enable repartitioning of that area of storage, # i got an error filesystem is busy (or something like that) around here, # i had to recompile raidtools. raidsetfaulty /dev/md0 /dev/loop1 raidhotremove /dev/md0 /dev/loop1 losetup -d /dev/loop1 # the loopfs is now running in deraded mode from only loop2 # we can now move ./loopfs1 to another location mv ./loopfs1 //newdir/ # now reintegrate loopfs1 from its new location losetup /dev/loop1 /newdir/loopfs1 raidhotadd /dev/md0 /dev/loop1 It did work for me once, but i got two oopses in other attempts, so it still has problems. It would require the installer scanning /proc/partitions and finding filesystems it can write to, but repartitioning can the
Re: [woody,debinst] keeping track of plans
Steve Przepiora wrote: > As long as your thinking of re-doing boot-floppies, why not take suggestions > from users about what's important for them? Maybe set up some kind voting > page or something. > Its a good idea to keep in touch with regular users, but i think timing is important. I think it would be good if we come up a plan first and then announce it, asking for for comments/suggestions etc. > > I guess the issue is, would the benefits of maintaining a web page for > > the development of the debian installer be worth the effort. > > I volunteer, do I need to be a registered debian developer? I could always > do the pages and mail them to someone. I also wouldn't mind documenting the > new debian-install process. > Cool, a volunteer... im not a registered debian developer yet either. Anyone else think a developer web page is good idea? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody,debinst] Interim filesystem
Bruce Sass wrote: > > On Sun, 18 Jun 2000, bug1 wrote: > > How and Interim filesystem might work (as i see it) > > Why have an interim fs? > > - Bruce 1) To get around any space limitations presented by the boot medium, or ramdisk. It is delaying the partitioning process till later on after we have lots on space available to us. There are lots of different things we can consider doing if space isnt the primary limitation. 2) It adds a seperation layer between what we are installing from and what we are installing to. To enable non linux installs, e.g. Debian/Hurd (or Debian/bsd, or Debian/plan9 if they eventuate) For all those cases the interrim filesystem would always be Linux, and the linux interim filessytem would provide what is needed to install and configure the local hardware (partitioning etc), the final os kernel and then can just be copied across and activated on reboot. It adds a seperation layer between what we are installing from and what we are installing to. Was i convicing ? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[woody] libraries for a modular installer
If we breaking the installer into seperate modules, with binaries in seperate modules how are we going to support them with libraries? Currently we have mklibs.sh to cut down the libraries to only support the binaries we need. Its going to be harder to do that if we have heaps of different modules, some of which we will need all the time, others less often used. We could include the full libraries, but they take a fair chunk of space, libc nearly 900kB, and we would need that right at the start. We could compile each modules binaries to be static, but that would add extra overheads as well. I dont understand how mklibs.sh works, so this might be a silly idea, but would it be possible to make a library for the modules that only contains parts of the library that the modules binaries require and that arent in the base module ? eg. libc has chunks a, b, c and d. The base module requires a and b. FancyGUI module requires a b and c Could we put libc chunks a and b in the base modules, and only libc chunk c in the FancyGUI module, then when FancyGUI module is installed it combines its chunk c with existing chunks a and b so then libc chunks a, b and c are available, a diff of a library. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody,debinst] Interim filesystem
Bruce Sass wrote: > > On Mon, 19 Jun 2000, bug1 wrote: > > Bruce Sass wrote: > > > On Sun, 18 Jun 2000, bug1 wrote: > > > > How and Interim filesystem might work (as i see it) > > > > > > Why have an interim fs? > > > > 1) To get around any space limitations presented by the boot medium, or > > ramdisk. > > It is delaying the partitioning process till later on after we have > > lots on space available to us. > > There are lots of different things we can consider doing if space isnt > > the primary limitation. > > What is the advantage to delaying partitioning, get it out of the way > fast and you have the whole harddrive to play with. > If you get it out the way first, then you limit how powerfull it can be. If we delay partitioning till after the installer has accessed the debinian binary archive then partitioning tools can be taken from the archive rather than being included with the installer. We can access the debian binary archive prior to partitioning with a traditional installer, but then we have the problem of not necessarily having enough disk/memory space to be able to unpack them, hence an interim filesystem If we can have anything from the debian archive prior to partitioning we can get binaries to do filesystem resizing, LVM, raid, without includeing them in the installer. We could also delay partitioning till after a hardware detection stage which gives time for kernel modules to be inserted incase any hardware that should be repartitioned wasnt detected by the boot kernel. In a modular installer we would be much less dependent on extracting debs from the debian archive as all the required binaries could be in the modules rather than extracted from the debian archive. Having the binaries in the modules would make the modules much larger them if they were just differnt configuration files/scripts, and then we also have to sort out libraries. If we have lots of space we can use full libraries Having LVM, RAID and Resizing tools available when doing the partitioning would mean there are no limits to how you choose to partition your system, and you could most likely install without having to first backup the contents of a partition prior to the install which destroys it. Where im coming from is that i consider partitioning to be (probably) the most important part of the installation, its much harder to repartition after the install than it do any other configuration. Thats my experience anyway. > I was thinking of a monolithic installer core, modularized like the > kernel is for `maybe needed' functions... very small footprint, maybe > even totally in memory. > If we can have LVM, RAID and Filesystem resizing tools available for partitioning using this methods i would be just as happy. > > 2) It adds a seperation layer between what we are installing from and > > what we are installing to. > > > > To enable non linux installs, e.g. Debian/Hurd (or Debian/bsd, or > > Debian/plan9 if they eventuate) > > Hopefully the installer will not be Linux specific. i.e., one could use > it to install Hurd, etc., just by having the proper modules available. > Yea, true. > > For all those cases the interrim filesystem would always be Linux, and > > the linux interim filessytem would provide what is needed to install and > > configure the local hardware (partitioning etc), the final os kernel and > > then can just be copied across and activated on reboot. > > > > It adds a seperation layer between what we are installing from and what > > we are installing to. > > I'm not sure why that is a good thing. > > > Was i convicing ? > > No, but don't sweat it, I may just have strange ideas about... :) > Fair enough, constructive criticism is always a good thing. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody,debinst] Interim filesystem
Hartmut Koptein wrote: > > > > > How and Interim filesystem might work (as i see it) > > > > > > Why have an interim fs? > > And what about raiserfs or better jfs ? > I havent tried reiserfs yet, from what i know it save us a bit of space with small files wouldnt it, does it have nay other advantages ? Whats jfs? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody,debinst] Interim filesystem
Bruce Sass wrote: > I think you are forgetting about something... > how is partitioning going to be accomplished without user interaction. > > I'm not aware of any tools that can take a description of a filesystem > then partition and setup a harddrive(s) accordingly, that seems to be a > task necessary for unattended (auto-pilot mode) installations. If you > have such a program then it doesn't make much sense to use the manual > tools in the archive, give the user a more flexible and natural UI > instead. May as well aim for the target instead of below it, if you > fall short and need to resort to the manual tools then so be it, they > can always be an option loaded off of a floppy, the HD, a CD, or a > network. You already have at least a read-only filesystem available, > that is all you really need for providing extra tools required before > the target system has storage space available. > What if the partitioner was just a GUI, didnt have any tools itself, it just interfaced to external command line tools. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody,debinst] Interim filesystem
Joey Hess wrote: > > bug1 wrote: > > > What is the advantage to delaying partitioning, get it out of the way > > > fast and you have the whole harddrive to play with. > > > > > If you get it out the way first, then you limit how powerfull it can be. > > > > If we delay partitioning till after the installer has accessed the > > debinian binary archive then partitioning tools can be taken from the > > archive rather than being included with the installer. > > This is quite true, however, the design I came up with also allows you > to download the partitioner from somewhere, without the expense of > installing a scratch install of debian too. > > > If we can have anything from the debian archive prior to partitioning we > > can get binaries to do filesystem resizing, LVM, raid, without > > includeing them in the installer. > > > > We could also delay partitioning till after a hardware detection stage > > which gives time for kernel modules to be inserted incase any hardware > > that should be repartitioned wasnt detected by the boot kernel. > > Also supported by my design. > In your design these programs would be unpacked to ramdisk i assume, ram is more scarce than hdd space. If we didnt *depend* on the use of a ramdisk we would be able to install to 4MB (maybe less), ramdisk is usefull though and should be used whenever possible. I think it is a worthy goal for debian to try and get smaller as well as bigger, personally id like to see the installer work on machines with 4MB RAM, 20MB HDD. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[woody] SMB support
If the installer understood smb we could mount remote directorys using via windos (or others) shared folders. SMB mounts would be usefull for computers on a lan, ftp, http gets are more versatile. It would be easier for some people to just share a folder on there windows machine than get them to setup a ftp/http server. The installer could (optionally) automatically scan for SMB shares rather than having to specify the location of the machine. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
non-installable binaries in main (was Re: busybox_0.45-1_i386.changes REJECTED)
A recent thread on debian-boot concerns wether busybox should be allowed into woody as a seperate package. Busybox is a vital component of the installer but would NOT be useable or installable post install. The reason for rejection On Sat Jul 01, 2000 at 11:27:31AM -0400, Antti-Juhani Kaijanaho wrote: > This package violates policy in several ways: > - first of all, the busybox binary package does not include > a copyright file, a changelog file or - indeed - a > /usr/[share/]doc/ directory! > > - second of all, > E: busybox: symlink-should-be-relative bin/head /bin/busybox > [...] > > - third of all, I am not sure if it is a good idea to > include a package in the distribution that cannot be > installed into a system without breaking that system > (this package conflicts with many essential packages) > You should definitely bring this issue up on -devel or > -policy before reuploading (btw, I cannot find an ITP > for this package...) > > If you don't understand why your files were rejected, or if the > override file requires editing, reply to this email. > > Your rejected files are in incoming/REJECT/. (Some may also be in > incoming/ if your .changes file was unparsable.) If only some of the > files need to repaired, you may move any good files back to incoming/. > Please remove any bad files from incoming/REJECT/. and the latest post. Antti-Juhani Kaijanaho wrote: > > > If it can't be installed, and it is documented as such in the > > package description, then I see nothing of how it affects the distribution > > as a whole. > > I see introducing uninstallable packages deliberately as affecting the > distribution as a whole, and I maintain that it needs to be discussed > as such a matter. > > > The only other alternative is to provide a source .deb instead > > of a binary package. > > Why does it *have* to be a .deb? > > (And yes, a source deb would probably be less intrusive.) > Firstly i understand why concerns were raised, but my opinion is that if you look at the big picture there is nothing to be concered about. >From the installers point of view and the distribution as a whole it is better is the installer is integrated with the distribution as much as possible. deb is a perfect choice for components of the installer just as it is for other binary packages. Why shouldnt the advanteges of packages be available to the installer ? Creating the installer by drawing from a pool of existing conveniently lcoated packages is better than downloading/creating a big tarball every now and again. Im sure you can see why the installer team would want installer components in main. The only drawback of having installer components located in main is that some components such as busybox are not intended to be useable post installation. It is indisputable that the installer as a whole is very valuable and has to go somewhere Possible places for installer components 1) Amoungst source packages. I think it would be wrong to treat a binary package as a source deb as suggested previously, a binary package is a binary package, if it cant be treated as such then there is something wrong. 2) In there own seperate area. (e.g. disks-i386) Currently the installer has its own area, the vast majority of the installer (e.g. base.tgz) is extracted from packages in main, the disks-i386 directory is now 100MB which covers all the different flavours of installs for this architecture only. Having a seperate area means it doesnt have to be mirrored, but 99% of the isntaller is extracted from main anyway, so if your mirroring main segregating the installer isnt going to save any bandwidth or space. 3) In main This IMHO is the only logical choice, even though a component isnt directly useable its a vital component of a useable program, the installer has to be created somewhere, an analogy could be made between non-installable binaries and libraries. Distributing installer components seperatly could mean packages could be released independently, rather than generating 100MB of files every time a change is required. The package in question (busybox) is probably around 500KBytes or so, there could be more non-installable binary packages required for the woody installer (its a bit early to say) but they would also most likely be small. If package pools gets implemented for woody then this is less of an issue. Does anyone have any objections to installer components that are NOT usable post install being placed in main? Thanks Glenn McGrath -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-installable binaries in main (was Re: busybox_0.45-1_i386.changes REJECTED)
Alvaro wrote: > > This assumption is false. The new installer is going to be modular, and > it will be able to start from a very small base (1 floppy, we hope) and > retrieve other modules as needed from various sources (like cd's, > floppies, and the network). > > Where can I take a look at the new installer being developed, or is it just > an idea yet? > > Thanks, regards, Alvaro Its just an idea at this stage, http://cvs.debian.org/debian-installer/doc/ has a guide to what may be. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mini-libfdisk
At the following address there is a mini-libfdisk, its pretty tiny (it uses mini-elk), im going to check it out further, maybe it could handy for partitioning for woody. ftp://ftp.stormix.com/ogl/inst/src/om-inst/ The original site loops to be in japan, i couldnt get into it though. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: need major help- RESCUE and ROOT disks
Exodous wrote: > > Hey, > > How is everyone doing. I really need some help. I need to make custom > rescue and root disks for my systems with my specific kernel > (2.4.0-test2-ac2). I have tried so many ways and I have not reached any > success. I read the bootdisk howto , yard etc . I have no luck. If > someone can help with steps on how to make it. (I even tried to put my new > kernel in debian rescue disks and nothing happened). I would really > appreciate if someone can tell the perfect way to do it . I have been > trying for more than 2 weeks. So any help is appreciated. > > thank you > > exo > > (i need something which makes the root partition to go on ramdisk etc > something along those lines ...what debian rescue and root disks do ..like > that thanks) > Where did you have problems, getting the kernel on the disk, or getting the 2.4-test kernel to work with the installer? Did the kernel boot ? The rescue disk just uses the syslinux boot loader, you should just be able to rename your new kernel to the same name as the one on the rescue disk and copy it to the floppy. Busybox has some problems with 2.4, does your situation definitaly need 2.4, is there a way you can avoid it till afterwards isntalling. If your doing other things other that installing you may want to look at the /Documentation in the kernel, there is a ramdisk.txt initrd.txt, apart from those there is other groovy stuff in 2.4 you may want to consider like ramfs. There is a way to specify a different kernel in the boot-floppies source configuration files somewhere, i havent done it that way myself, but it would be the way its supposed to be done. If your experimenting a lot you may want to give vmware a go, saves rebooting all the time. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kernel dev patches
Hi, ive been playing around with kernel modules, and i intend to make /proc/filesystems, /proc/partitions available as devices in the same way as busybox's devmtab, devps and devmodules. My reasons for this are that when debian installer starts one of its first priorities may be to find space that it can use, it is preferable for it to be a filesystem in memory, but it could also be a loop filesystem. Having /proc/partitions and /proc/filesystems make it fairly easy to check for possible locations for a loop file. The reason for not just using the normal /proc is that it enlarges the kernel by about 67KB in 2.[34].x which is about 5% of our space on the initial boot floppy. By using a few dev modules we could (if we choose) avoid having to use a kernel with /proc support compiled in. Ive got a module that works already, but it only displays output when the module is inserted, it shouldnt be too hard to fix up from here, ill just follow how dev/mtab etc work. I can also get it to display extra partition information such as the partitions start and end points which could could possibly be usefull for a partitioning program. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel dev patches
Daniel Jacobowitz wrote: > > On Wed, Jul 19, 2000 at 12:02:30AM -0400, Ben Collins wrote: > > > The reason for not just using the normal /proc is that it enlarges the > > > kernel by about 67KB in 2.[34].x which is about 5% of our space on the > > > initial boot floppy. By using a few dev modules we could (if we choose) > > > avoid having to use a kernel with /proc support compiled in. > > > > I Don't think we will ever be able to reasonably support using a kernel > > without /proc on boot-floppies, or any other system. There are quite a few > > things that are needed in /proc besides partitions and filesystems (among > > them are cpuinfo). Replacing all of them with some sort of device or ioctl > > type thing, isn't feasible I think. > > Not to mention that it makes it nearly impossible to use the installer > to rescue a system - I always begin by chrooting and mounting proc > inside the chroot! > > Dan Fair enough, still its unfortunate that proc wasts a lot of space, i guess its just unavoidable then. I might continue with it anyway just for personal interest and to help me in understanding how the kernel works. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
devfs support code(was Re: kernel dev patches)
Ben Collins wrote: > > If you are really interesed in writing some code, I'de like to see a > smallish library that interprets things in /dev of a devfs mounted > filesystem. query things like drives, partitions, devices, etc.. Devfs is > definitely going to be the way to go in woody. > > Ben > Yea, ill have a go at this, it shouldnt be too hard, devfs lays things out pretty well by the looks of it. I think there are a couple of basic goals of early hardware detection which could use /dev and /proc or other code. 1) Memmory detection - busybox can check available memory, or from /proc/meminfo. 2) Identifying local block devices - Identifying local drives/partitions, including removable drives, md drives, ramdisks, ramfs etc. 3) Gather drive/partition info. - Get info from /proc/filesystems to enable us test and identify the filesystems needed to access the block devices identified in 2) - Find available space on each device - Determine if a drive/partition is read-only or read-write 4) Classify posible use of each drive/parition (e.g. cdrom would be a source not a target) - possible source of deb archive - possible target to install to. 5) Network connections - This would commonly require user input at some stage, so i guess its best done seperatly or at a later stage, could try bootp/dhcp here though. We could consider using libdetect or kudzu, but i think these two might be overkill at this early stage. We can initially only concern ourselves with where we get the rest of the installer from and where we are going to put it. This should make things more flexible. Glenn (i assume we want something simple for early on) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [woody,debinst]
Wookey wrote: > > Some of you may be aware that emdebian.org has been created to generate a > debian-allied embedded linux distibution. My area of interest is ARM > devices, and a lot of the potential platforms are handheld/embdedded > devices (4Mb flash, 32Mb RAM, 100Mhz Strongarm, LCD+touchscreen, no hard > disk, no keyboard, or even 'smaller'), as opposed to desktops (10Gb+ HD, > 32Mb+ ram, kdb, mouse, fast CPU, lots of devices etc). The variability > amongst devices is much greater than desktop machines which makes > designing installers 'interesting' as you really don't know what devices > they will have. Some have nothing but a serial or USB port and some RAM. > > > I think that's enough for now. Please try to bear in mind these sorts of > things when considering the design. Talk to the emdebian people if you > need more info (cc:ed to the emdebian list). I can try to provide > relevant info as the project progresses, but if the prime movers really > don't want to cover non-desktop machines then say so, and I'll shut up > about it. > > Wookey > -- Personally i thinks its a worthy challenge to reduce the installer size as much as possible, i think we could get the install itself to be small enough, its more a question of deciding what is going to be installed. So, on your strongarm you only have 4MB of permenant storage ? What sort of applications do you use on it? Maybe the way to go for really tight situations like that is to generate an image on another machine. That way you can have regualar tools around to creat the image, you could remove docs and other non-exential things beforehand. Then installing could be just moving moving the image onto your permanent storage, however you do that... You would have to have access to a desktop machine though, how do you presently do it? I assume you use compression on your perm. storage. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
future role of debconf
If debconf is going to play a central role for the woody installer it may be beneficial to rewrite it in c. Perl has its uses, but its a pretty big overhead for the installer if its only used for debconf. How stable do you consider the functionality provided by debconf, do you think it will change much ? Im thinking jobs such as these would be good to get started early on in the woody cycle. I dont understand debconf too well, and my perl is pretty rusty, but i could work it out... Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT Question: c libraries
There is a script in the boot-floppies src, /scripts/mklibs.sh, it strips the library down to only the objects required to run specified binaries. Jarkko Kovala wrote: > > Hi. > > This is kind of off topic, sorry. > > How did you get the c libraries on the boot floppies so small? > > -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debinst: debconf based installer
Ive been working on writting a debconf in c, im calling it debconf-native at the moment. If we can make the user interface for debconf a bit more flexible, it would be ideal to base the entire woody isntaller around. Debconf would be great for users becasue it would be same tool they could use post-install to reconfigure. A native debconf can be small, the installer can just be busybox debconfig and a few scripts. Microwindows could be an attractive default debconf frontend, we would still need slang for terminals and text for worst case senario. Debconf-native is set up as a multi-call binary (like busybox) to provide the various debconf commands (db_init, db_title, db_input etc), i havent got the functionality yet, just getting things in place. Ive been having heaps of fun with dynamic modules, ive got it so that it searches for libraries that match a certain pattern (_.so.) to initially identify them as debconf-native modules, then checks the modules internally to identify via version checks. Got a bit of a file parser happening, it gets default values for prefered user interface module and prefered database module, i dont think much else needs to be put into the config file. No modules actually provide functionality yet (except version check), very much a work in progress, but if anyone whats to see what i have i can email it. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
fancy loadlin interface: winux
"Winux is a graphical configuration interface for the LOADLIN bootloader. It also has multi-language support including English, French, German, Italian and Spanish." http://www.linux-france.org/prj/winux/English/index.html This could be a nice thing for people that intend to switch beteen linux and windows. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Partition file proposal
Chris Rutter wrote:
>
> I have a fairly wacky proposal which concerns, mainly, boot-floppies on
> Linux/ARM. I've attached the proposal here; it should actually of generic
> relevance, but I'm only working on ARM for the time being. If anyone had
> any comments I'd be hugely hugely greatful. If not, skip the message.
> Thanks.
>
> --
>
>A proposal for a partitioning file scheme
>
> v0.00 / 5th August 2000
>
>Chris Rutter <[EMAIL PROTECTED]>
>
> -- Rationale
>
> Many users of Linux/ARM, especially on Acorn hardware, find repartitioning a
> significant hurdle: the RISC OS tools are primitive (and don't include support
> for resizing), and unfriendly to the non-computer-literate.
>
> Furthermore, more experienced hackers may desire from time to time to have
> scratch partitions; perhaps to test a new distribution, or installation
> mechanism, or somesuch.
>
> There is a technique in Linux whereby the root of the filesystem can be
> re-mounted from one of its constituent files, viewed as a loopback device;
> for example (schematically):
>
> % mount /dev/hda1 -t adfs /
> % losetup /dev/loop0 /Linux/root
> % mount -o remount /dev/loop0 -t ext2 /
>
> There is no codified procedure for how the technique should be deployed in
> the kernel and user-land tools, however. This document proposes one.
>
Im not sure i really get what you mean, are your trying to figure out a
way to add loopback files to the kernel partition list
(/proc/partitions). It could be done entirely in userland though i
guess.
Sounds like a good idea, implementation might be difficult though.
> -- Requirements
>
> It's useful to be able to enumerate the partition files stored on any device
> without having to mount that device; for instance, in the Debian boot-floppies
> package, the segment of code which returns the list of partitions to the
> installer would have to fiddle about mounting every partition on every device
> in turn, searching through a list of probable locations for an `fstab' file,
> etc. This would be especially difficult in a call-iterative way.
>
> It would be better, I believe, to store a partition table adjoined to the
> one already on the disk: this way, there is a collected table that can be
> easily located, read and parsed. My suggestion, as the `Linux table' area
> of a FileCore disk reserves two sectors but occupies only one, would be to
> use the second sector of this table area.
>
> -- Table format
>
> I would propose the table be structured along these lines:
>
> typedef struct {
> uint32 magic;
> struct {
> uint32 size_in_sectors;
> unsigned char ms_dos_compatible_partition_type;
> unsigned char source_minor;
> char path_to_file[...];
> } partitions[...];
> }
>
> Where:
>
> * `source_minor' is the minor number of the partition within that device
> that contains the file referenced in `path_to_file';
>
> * `path_to_file' is zero-terminated, and represented as a string that can be
> concatanted to the mount path of `source_minor' -- e.g. `Linux/root';
>
> * each partition entry is aligned to 32 bits;
>
> * the table is terminated by a partition whose partition type is 0.
>
> Assuming an average length of `path_to_file' of 34 characters, this would
> give us room for eleven real partitions and a terminator in the 512-byte
> sector.
>
I dont understand the filetablespace very well, would this layout
interfere with other partitioning programs ?
> -- General syntax extension
>
> It would be helpful if there were a consistent way of referring to a partition
> file on a given device; I propose the use of a syntax thus:
>
> /dev/DEVICE:NUMBER
>
> where `DEVICE' would typically be an un-suffixed block device, and `NUMBER'
> the index into the partition file table of the wanted partition. For example
> `/dev/hda:4' to select the fifth partition file on the IDE primary master.
>
So if DEVICE = /dev/hda1:1 it would point to the first loop file on
hda1, this scheme should work with devfs as well.
> -- Kernel booting
>
> The kernel should check the `root' parameter it's passed for a `:'; if one is
> present it should decompose the string, and perform a mount-loop-remount
> operation.
>
> -- User-land utilities
>
> Utilities such as `mount' should be patched to recognise the syntax, so that
> people can create `/etc/fstab' entirely as normal, just specifying extended
> syntax device paths.
>
> (There is a question as to whether to leave `mount' to do all the parsing of
> the disk itself, or whether this should be performed in the kernel and exposed
> through a syscall interface.)
>
> When `mount' needs to access a native partition in order to losetup the
> partition file, it should:
>
> * check to see whether the native partition is already mounted, and if so
> simply use that path;
>
> * if not, mount it on `/.
debinst, debconf & postinst.
The woody installer is planning on being based around a debconf like program. I read in a recent posts (cant find it right now) about postinst stuff being unwelcome, to make everything preconfigurable. I think the debian installer could make a lot of use of a post install type setup. e.g. to do something complex like partitioning which is probably the hardest thing the install has to do. I think that there are two clearly different functions that need to be catered for. debconf: Package installation, configuring the package to work on the system. debian installer: Using the functionality provided by the package. e.g. adduser wouldnt need to use debconf to install, but for the debian installer could have a script that uses debconf like functionality to add a user at install time. So im thinking that rather than trying to reimplement the current functionality of debconf in c for the installer, it would be better to try and create a "cousin" of debconf focusing more on implementing the functionality provided by packages in a standard way. Debconf and its cousin could complement each other, they could use the same user interface to tie them together for the isntaller. Maybe im not looking at the big picture though, do all the bits fit? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
udma disks /modules/2.2.17/ should be modules/2.2.17-ide/
the udma disks spew up heaps of modprobe errors, cant open dependencies file /lib/modules/2.2.17-ide/modules.dep the directory created is /lib/modules/2.2.17/ This is pretty serious, stops modules being configured Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udma disks /modules/2.2.17/ should be modules/2.2.17-ide/
Randolph Chung wrote: > > In reference to a message from bug1, dated Aug 17: > > the udma disks spew up heaps of modprobe errors, cant open dependencies > > file /lib/modules/2.2.17-ide/modules.dep > > > > the directory created is /lib/modules/2.2.17/ > > > > This is pretty serious, stops modules being configured > > are you using rescue/root from the same disk set (same directory)? > I thought i was, maybe i did something wrong, ill double check what i did. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
