On Thu, Feb 05, 2009 at 12:35:15PM -0500, wrote: > I can confirm that first.b does in fact build correctly. I am not sure > what I did wrong before while trying to debug it. Certainly second.b > ends up much too large, and I have not managed to fix first.b to support > a larger second.b, although I am not sure that is because my first.b > changes are incorrect or if it is because second.b is broken due to the > ext2 changes. > > I have been trying to change the load address of second.b from 3e000 to > 3d000 to give it 128k instead of 64k. I was also changing the BAR setup > to allow more than 16MB to be used by the initrd, which I pretty sure > will work fine, if I could just manage to get a working second.b build. > > So which part of the ext2 headers is causing it to get too large? I > would love to build with the old headers to try and see if my other > changes are sane, so that I can solve one problem at a time. > > Changing the installer setting should at least permit installing, but > being unable to rebuild quik is still a serious problem, which I am sure > can be fixed, so I am working on it.
So I now have a version of quik that works with larger than 64KB second.b and hence works when built with a current version of e2fslibs. It also doesn't have any warnings from the compiler when built either. It took some major change to the design, although not much code change to do it. It now creates a /boot/second.map.x (where x is whatever block device it is dealing with at the time, it seems to have something to do with raid use) and then maps the single block of that file into the first.b's data structure. first.b now loads the second.map data into memory, and uses the up to 256 blocks worth of locations (1KB) to load second.b. So the data structure in first.b is much smaller, but the supported size of second.b is 4 times larger. The load address also had to be moved down by 192KB to fir the larger second.b image without globbering first.b's memory. Now given the large change and the change in behavior especially, I think this deserves a new version number. Unfortunately I can't figure out how to locate the author of quik, or whoever is the current maintainer, so I am not sure what to do about that. Any suggestions? I also have to go fix openbios since their way of detecting the QUIK boot loader uses a hardcoded copy of the data structures from QUIK which hence break when QUIK is changed like this. This wasted probably 3 days of my time before I noticed there was nothing wrong with my changes, it was entirely openbios doing the wrong thing and deciding I had no boot loader as soon as I moved anything in QUIK. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
