Sven LUTHER <[EMAIL PROTECTED]> writes: > pb3 : When i call partition the harddisk, cfdisk is called, and not > amiga-fdisk, like it should be. cfdisk don't know anything about > amiga partitioned harddisks.
Have you fixed this in dbootstrap yet? It should be fairly trivial to fix. I don't wanna mess with ports I don't understand. > There is a minor problem also on > scripts/rootdisk/fdisk-powerpc which becomes /sbin/fdisk, but even > fixing this don't seem to influence the "partition the harddisk" > menu option. Strange since a manual call to fdisk finds the correct > amiga-fdisk (or don't find it). Is this still the case? libfdisk uses /proc to determine viable install candidates etc. > There is something i don't understand here, what is libfdisk for in the > busybox, i can read the partition correctly (with the menu option view the > partition table) but not set it. If the busybox has a working fdisk, why is > fdisk included in the boot floppies ? libfdisk != fdisk libsfdisk IIRC was intended one day to be a general fdisk library for use in cfdisk, fdisk, etc, but I think that's stalled. Less code in boot-floppies the bettter. Less for us to maintain and debug. > pb4 : When first configuring the network, and choosing the no option > (for ppp) there is an error message : "Error writing to /root/ppp" Fixed in CVS I think. > pb5 : When installing the kernel, it searches for disks-1.44/rescue.bin, which > should be resc1440apus.bin. Is apus a subarch? The file must be moved to apus/disks-1.44/rescue.bin . Hack on 'make release' for your arch to fix this. old file names like resc1440apus.bin are not supported. > Anyway, would be better to search for the > linuxapus binary and the drivers.tgz file, or even only the driver.tgz, since > we don't have lilo, and a kernel on the ext2 partition is only a waste of > space. Interesting. Well, it would be apus/linux btw... Not a bad idea, if anyone manages to get it coded up. > Is it possible to change that menu option to "install the kernel > modules" or something such, and go searching for drivers.tgz only, for > architectures not supporting lilo or similar ? Um, you still need a kernel to boot from don't you? > pb6 : there are a lot of menu choices that don't make sense on my > arch/subarch. This include the precedent Install OS kernel & > modules, but also "make linux bootable directly from harddisk", > "make boot floppy", "eject floppy disks" and "configure pcmcia > support". Sure... just hack on utilities/dbootstrap/main_menu.c. > Would be nice to add a "configure the bootstrap system" or > something such, who would mount a bootable affs partition (for apus > or m68k/amiga), and do the appropriate stuff to make it work. Not sure what you're talking about. > How > can i modify this stuff ? it is in utilities/dbootstrap, right ? Right. You have CVS don't you? do you have access? Write access? if you have an account on VA, you should. > pb7 : There is arch specific stuff in scripts/rootdisks. But, at least for > powerpc, we have one rootdisk per subarch, which makes sense, since on apus, > mac-fdisk, pcmcia_cs and eject are not needed, while amiga-fdisk seems to be. > Would it not be better if we could differenciate between subarches, or is the > plan to have a common rootdisk per arch. It should be possible, now that we > removed the kernel from the rootdisk. I dunno -- however you guys wanna handle it. One rootdisk per subarch sounds good to me but we might need to worry a bit about how the files would lay out and/or how dbootstrap searches for files. > pb8 : MAX_DISKNAME_LEN is still not defined, but i guess it is in cvs. Will > have to get the cvs version. How do i do that (i had a mail with it, but lost > my mail archive yesterday ...:()) See below. -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/> You can access the boot-floppies using CVS; this is particularly useful if you are actively working on the package. CVS comes with excellent documentation; in particular, see the 'cvs' info pages. There are various ways to access the CVS repository for the boot-floppies, depending on your circumstances. However, once you've set up your CVSROOT variable properly, all the access methods behave identically. The following are bash commands you can run to get the CVS area; other shell users should be able to translate to their shell language easily. Commands with a '#' are comments; you don't have to type those. # if you are logged into to va.debian.org, aka cvs.debian.org: export CVSROOT=/cvs/debian-boot # if you are using 'ssh' to access the area, and you have an account # on va.debian.org -- this is the recommended method: export CVS_RSH=ssh export CVSROOT=:ext:<MY-USERNAME>@cvs.debian.org:/cvs/debian-boot # if you are using anonymous (readonly) access: export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/debian-boot cvs login # you will be prompted for a password -- just hit 'enter' # if you are using a pserver account (i.e., you need write access but # do not have an account on va, and you have been given a pserver # username and password): export CVSROOT=:pserver:<USERNAME>@cvs.debian.org:/cvs/debian-boot cvs login # enter the password you have been given After that, all techniques are the same. Simply check out the sources. For the lastest (possibly unstable) version, do: cvs co boot-floppies For the slink CVS branch, which is probably what you are using if you are working on translating slink documentation: cvs co -r adam-boot-floppies_2-1_branch boot-floppies >From there, you just use 'cvs update' and 'cvs commit' -- see the info pages.
