Thanks for info! Adam Di Carlo wrote: > > (a) root.bin is too large to fit in 1.44FD. (about 1.6Mbytes) > > possily because of very large size of libc and binaries. > > In particular, we might have to reduce the libc. > > This is after compression? 'rootdisk.sh' is currently built at 3200k > -- this was enough to build the sparc version, for instance... Yes, after compression. I changed that 'rootdisks.sh' is built at 5400k for alpha, and ungzipped root.bin is used at 4400k. compressed root.bin is 1.5-6Mbytes. (1509405 bytes for today's cvs tree). > > (b) aboot does not work well. > > In aboot prompt, I typed 'linux' but aboot said > > 'linux: file not found'. > > Hmmm... well, you know that we're splitting root and boot disks now, > right? Yes, I know that. aboot problem occurs just before loading linux kernel. (aboot is second boot loader, like lilo in i386.) > On the boot disk, is the kernel getting copied into place > properly? Yes. when I mount rescue1440.bin, I could see 'linux' which is 770k. > the one building the rescue disks for you -- you shouldn't have to do > it manually. Ok. I just tried to show the problem clearly. It is separate problem, actually. (I might confuse you, sorry) > Are you asking for boot-floppies write access? Yes I am. > I don't have any > control over new-maintainer but I can add people who are *not* debian > developers to have write access to boot-floppies. I would prefer if > you first send a patch to this list for review before you commit stuff > if you're new to all this though, at least for the first round... Ok, I appended patch for CVS tree. This patch makes it possible that you finish 'make release' for alpha, but only for sub-architecture of 'generic'. I do not understand well how old boot-floppies made various sub-architecutre's images. Anyway, I think my patch does not break things. It is simple. > We have this but I think it only works on i386. See > scripts/rootdisk/mklibs.sh. Perhaps someone could get it working for > the other architectures? Thanks! I am looking into that. -- Tadayoshi Ohkuma / tad@omoikane.co.jp Omoikane Inc. / http://www.omoikane.co.jp
Attachment:
diff
Description: Binary data