Re: Build problem for Alpha bootdisks
On Mon, Jul 30, 2001 at 03:45:37AM +0200, Falk Hueffner wrote: Do I have to add sysvinit to the package list, or what's the problem? The problem was already being discussed starting at http://lists.debian.org/debian-boot-0107/msg00603.html. The solution is too simle: you just have to download some packages manually, i.e. e2fsprogs, which isn't needed for the bootdisk (and won't be unpacked). You'll need to do this until apt-get gets a switch for telling it: Hey, just download the packages without checking deps! I want it! I know what I'm doing! :-) I also wonder if we shouldn't use the milos from http://www.suse.de/~stepan/, which are actively being maintained by the SuSe folks. If nobody objects, I could try it. That sounds great, because all MILOs I tried so far suck (can't read my ext2 with sparse superblocks, even with a MILO said to be made out of a 2.4.x-kernel...) CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
New bootdisks / first install report / help needed
Hi, I've just uploaded a new set of Alpha-bootdisks to http://people.debian.org/~thimo/ They are still with a manually made to get around the libm-library-reduction problem (any binutils knowing folks around?). However I succeeded in booting them, installing kernel and drivers. Unfortunately, when I tried to configure the modules I just saw a segfault flashing by being overwritten by dbootstrap again :( Strangely, nothing about this got written to the logs... Anyway, manually inserting the modules worked, configuring the network with DHCP and downloading the packages, too! But even here several segfaults flashed by. At the end I got a window telling me that dbootstrap exited with a return code of 139. Daring as I am I rebooted and had a totally unusable system as /etc/fstab wasn't written... Basically, there is still much to do, but as I have to have my diploma thesis finished in three weeks and still have no useful results, I won't be dealing very much with the disks... Now, all Alpha owners with a bit of C-knowledge should try to debug the stuff because Debian 3.0 wouldn't be that great without Alpha... ;-) CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
Progress with Alpha bootdisks!
Hi, Today I got a Alpha-root-disk of proper size by doing the following: I created a very dummy libm (8k in size, just one arbitrary symbol in it!) and included it on the root-filesystem. By doing this, the size went from 1.7M to 1416337 bytes! Hooray! To my biggest surprise all newt-programs on the bootdisk (dbootstrap and nano-tiny) work without the dynamic linker choking on missing symbols, so libm is really pretty useless on the root-disk. Basically this shows that we have to modify mklibs.sh in a way that it first checks all programs for missing symbols, creates libs with those and then in a second pass (and maybe third pass in bad cases) adds all symbols which are yet undefined in the libs. I haven't got time for this because I have to work for my diploma thesis :( When testing the install, I encountered a somewhat funny error: Jul 28 15:56:40 (none) user.err dbootstrap[38]: This is disk 1 of 2 in the drv14generic series of 24-Jul-2001 13:09 CEST. Wrong disk. This is from series drv14generic. You need disk 1 of series the driver series. What is going wrong? The stuff before installing the driver-disks went all fine! CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
Re: libm on root-filesystem?
On Wed, Jul 25, 2001 at 09:42:28PM -0400, Adam Di Carlo wrote: Thimo Neubauer [EMAIL PROTECTED] writes: Ouch. So its that libslang itself should be reduced, and based on that, the usage in libnewt should be reduced? Almost :) First libnewt needs to be reduced, then libslang and after that libm, so that only the really needed math-symbols get in :( How many bytes are needed for alpha, exactly? Right now the size of root.bin is 1717580 bytes :( I put all my hope in getting libm to shrink because its size is 577440 bytes (uncompressed)[1] and 303227 bytes in compressed form (gzip --best on the file). Now if we just substract that from the above we would have a compressed root of 1414353 bytes :) Ok, this is a very coarse estimation but it could work out... I'd very much like to proove this by manually getting a very-much-reduced libm on the disks but haven't figured out the right commandline to build a reduced lib (spying in mklibs.sh isn't very enlighting ...). Could anyone tell me how to do this? Maybe this could at least help to get out manually-prepared-Alpha-bootdisks to get some testing on them going. CU Thimo [1] the unreduced libm is 665710 bytes big which made me wonder in the first place :) -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
Re: Problems with building the Alpha-bootdisks
On Tue, Jul 24, 2001 at 02:33:58PM +0200, H.Heinold wrote: the biggest problems with the alpha bootfloppies is the size of some files. I think libary-reduction on alpha ist really a mess. What does that mean? Is there a possibility to reduce the size further? I'd be very interested, because I'd like to check if the bootfloppies work on Alpha. What are the favorite ways of reducing the disksize anyway? As I'm still totally new to boot-disks, can someone tell me where I have to go? The lists of what packages have to go on the bootdisk seems to be irreducible... CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
Re: Problems with building the Alpha-bootdisks
On Wed, Jul 25, 2001 at 04:49:57AM -0800, Ethan Benson wrote: busybox has alot of cruft turned on that doesn't need to be, going through that and finding potential applets to kill would be useful. its probably a good idea to ask on the list first so the other archtectures can comment on whether something can go or not. The busybox applets seem to be fine but I wonder about the following: depmod and insmod are taken from the modutils (rmmod and modprobe being links to insmod) whereas lsmod from busybox is used. Is there a reason for this? I already checked the BTS for bugs in busybox but there weren't any concerning the module-stuff. As the modutils-bins eat about 200k on Alpha (uncompressed) and busybox will grow a bit when compiling in the mod-stuff this won't save the Alpha-bootdisks but it might be a way. Comments? CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
Re: Problems with building the Alpha-bootdisks
On Wed, Jul 25, 2001 at 09:26:47AM -0600, Erik Andersen wrote: If you find stuff that is enabled that shouldn't be, please do let me/us know by posting to the list. I'm about to make a new busybox package in the next hour or two, so now would be a good time to mention any needed changes. Of course, there are many new releases where this one came from if you find things later on... Well, I hope that this might save some precious space on the disk: could you enable all the module-stuff (insmod, modprobe, ...)? On Alpha the real binaries eat about 130k and the busybox-binary 282k. If there are no problems, route may also be activated, even if it is only 87k in size, but remember that we need ~200k extra-space (compressed!) on the rootdisk to get everything squeezed on a 1.4M-floppy. How is the shell-part of busybox? Is it useable and compatible enough to run all the shellscripts needed for the boot-process? I just ask because ash has annother 150k :) Well, I don't know if putting all of this in busybox will actually save that much space but IMHO it is worth looking into it (if it works). CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
libm on root-filesystem?
Hi, in my effort to save about any byte disposable to get the alpha-root-fs on a floppy, I'd like to ask the following: what does libm do on the root-disk? First of all: these are the binaries using libm (if i did not miss one): /bin/nano-tiny (aka edit) /sbin/cfdisk /sbin/dbootstrap The interesting thing about these is that they all use slang/newt. I also checked which dynamic symbols there are in libm, as those should be (after the library reduction) the ones actually used by the programs or libraries (or did I get something wrong?). I found functions like asinh, lgamma and erf which are pretty advanced stuff for a rootdisk :) Doesn't the reduction work? Or are there spots in libslang referring to all those math-function? Or did I get it all wrong? CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
Re: libm on root-filesystem?
I hate do do a self-reply but I tracked down the problem further: libslang needs all mathmatical functions on earth, because it provides wrappers for all of them. libnewt instead just needs a few of slangs functions, not including a math-function at all. Unfortunately the library reduction seems to only to see that there are unresolved symbols in libslang and includes all the math-stuff which is wrong because thos routines needing the math will be kicked out anyway (I checked this with objdump on the reduced libslang). Anyone able to teach the library reduction about this case? I do not dare after I read parts of the script... CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
Re: Problems with building the Alpha-bootdisks
On Tue, Jul 24, 2001 at 10:38:30AM +0200, Martin Schulze wrote: From a first glance it looks like a dependency problem: sysvinit: Depends e2fsprogs (= 1.15-1) e2fsprogs: version 1.22-1 is available, but: e2fsprogs-bf version 1.22-1 will be installed, so the dependency is not fulfilled. I guess that sysvinit should have a dependency like e2fsprogs (= 1.15-1) | e2fsprogs-bf (= 1.15-1) Well, I thought about that as well, but if sysvinit had these dependencies a user and/or apt could get the idea that installing e2fsprogs-bf seems like a good idea which it is not (out of the description of e2fsprogs-bf): | Don't attempt to install this package, it has no support for a | couple of features you surely want. Anyway it should refuse to | install. This could give raise to a bunch of bad bug reports... Anyway, it seems that the downloading of the packages needed for the boot-floppies seems to be broken if there is no way of getting apt to download package-files without checking. CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
Re: Problems with building the Alpha-bootdisks
On Tue, Jul 24, 2001 at 03:55:04AM -0800, Ethan Benson wrote: i never had any trouble with this, i used a woody chroot which is quite normal it has sysvinit and regular e2fsprogs (not -bf) installed. apt seems to have no trouble with this inside of boot-floppies build. are you sure your not trying to build on potato? or a very outdated testing/unstable? Yes, I'm running an up-to-date testing. The version of the system building the boot-floppies has no influence on the problem, because the apt-process showing the error uses his own boot-floppies/sources.list. Additionally, the problem only happens if you start with an empty download-directory, because rootdisk.sh only tells apt to download the packages not yet downloaded. This also means that I could fix the problem by downloading the packages manually, but where is the point having the download-stuff if it does not work without manual interaction? CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
Problems with building the Alpha-bootdisks
Hi, I'm trying to build the Alpha-bootdisks, because up to now I haven't heard of anyone doing this and I want the release to happen ;-) Anyway, I'm getting an error when rootdisk.sh tries to download the needed packages. After setting the debug-variable I found an apt-error: (I wrapped the apt-commandline) -- snip -- ... ++ apt-get -q --yes -oDir::Etc::SourceList=/data/debian/boot-floppies/sources.list -o Debug::NoLocking=true -o Dir::Cache=/data/debian/download/cache -o Dir::State::status=/data/debian/download/status -oDir::State::Lists=/data/debian/download/lists -o Dir::Etc::preferences=/data/debian/boot-floppies/preferences.apt --download-only install base-passwd busybox dhcp-client debootstrap e2fsprogs-bf libnewt0 libpopt0 makedev modutils nano-tiny netbase net-tools slang1 whiptail sysvinit util-linux aboot dosfstools Reading Package Lists... Building Dependency Tree... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: Sorry, but the following packages have unmet dependencies: sysvinit: Depends: e2fsprogs (= 1.15-1) but it is not going to be installed E: Sorry, broken packages ... -- snip -- Note that I already added sysvinit to the list of needed packages, because before I got the error that modutils needs sysvinit... Maybe this is the error? But if it is, the problem somehow stays the same... I could of course download the packages manually but do not know if this will make things even worse... Remember that this is the first time I try to build the boot-disks :) I just subscribed to debian-boot but haven't got the replay from the list-server yet, so please CC me on replies. CU Thimo -- Thimo Neubauer [EMAIL PROTECTED] Debian GNU/Linux 3.0 semi-frozen! See http://www.debian.org/ for details PGP signature
