Re: Alpha boot-foppies successes and failures cvs-2001-08-03
Adam Di Carlo <adam@onshore.com> writes:
> Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
>
> > I build a set of bootfloppies yesterday from cvs (cvs-2001-08-03) on
> > Alpha/sid.
> >
> > I run across the already mentioned problems so I won't elaborate on them:
> >
> > - sysvinit (workaround by Falk Hueffner)
>
> Porting the latest sysvinit package should solve this, no?
On the TO-TEST list.
> > - library reduction (root.bin is a bit to big)
>
> Did you try building using the mklibs.sh I committed on 2001-08-03
> 21:09 ? Does that help?
The mklibs.py script is done except for cosmetics. The root.bin has
about 40K to spare. I tested it on alpha and i386, should be in the
cvs as soon as Falk hueffner tried the boot-floppies it produced and
approves.
Comparing the sice I find that mklibs.py saves 300K (I think) on the
library size on i386. I will run a test on alpha after this mail to
compare size and see if the mklibs.sh works again.
> > - Configuring modules segfaults
>
> This is bug 107377 right? I suspect a lib reduction problem. Might
> also be fixed by the mklibs.sh change (though it would actually be
> rather odd if it was).
How does the modconf work anyway? Its not used to reduce the
libraries, so anything special it uses would be unresolved. Is it
linked static or are we just lucky?
Unresolved symbols should be detected by the linker and schould not
segfault. So I don't think its the library reduction. It fails too
with the mklibs.py script.
> > - installing base segfaults and gives return value 139
>
> Is there a bug for this? Has this been identified? Is it
> debootstrap's fault?
Actually during base install there are several segfaults but they
scroll away. Also some packages fail to install. Is there a easy way
to keep a logfile of the output in a file on the ramdisk or on
/target?
> > Now, what did work and what didn't thats new:
> >
> > 1) The tfpboot.img is not build but is later copied
>
> Are you able to commit your patches to the archive itself?
Falk Hueffner can do it. The excrepts where just to show what I had
done, just some workaround mostly. The tftpboot.img should have a
propper traget so other archs can use it as well.
But I will keep it in mind to commit changes. Now that the make
release actually runs through I can cleanup the patches.
> [ snip some alpha bugs I really can't help with, sorry]
>
> > 4) When installing files via NFS it doesn't work to list possible
> > dirs, one has to specify the correct dir manually.
>
> This might be a general problem, not an alpha problem. We should
> track this down or file it or something.
I just tried installing from harddisk. Once it worked and found the
stuff, the next reboot it didn't. Most curious.
> > Also the /instmnt is still there and still confusing.
>
> I don't think it would be best to remove this. Rather there should be
> verbage on there explaining that the mount point for the server
> already mounted is /instmnt.
You select "server:/path/to/the/dir" and that gets omited as
well. Theres realy no reason for the gui to tell where the nfs is
mounted temporary.
> > 5) Installing base does not cope with /proc being mounted already
>
> debootstrap bug? Why does this only affect Alpha?
It only happens when you mount it manually or if you repeat a crashed
"install base". I think the error canbe savely ignored without any
warning.
> > 6) How do I format the DOS partition needed for milo?
>
> Hmm. At install time, right? I see that sbin/mkdosfs is on the Alpha
> root filesystem. Does the filesystem have a special signature? If
> so, offer to run mkdosfs on that partition (ask first!). If not, then
> I guess you could just pop up a message warning folks that they have
> to do it manually in tty2 ...
I think the "initialise filesystem" entry should list the fat
partitions too and format them acordingly. Same for "mount initialised
partition" (which already does that on i386 I think).
> > 7) I created a new DOS partition and I have one with my current milo
> > on it, but still the install told me that I have no DOS partiton so I
> > can't make the system bootable.
>
> This is dbootstrap here complaining at you?
>
> You'd have to track this down in the source and try to fix it.
I guessed that alreay. It complains when you want to make linux bootable.
> > I have a Ruffian system and I'm one of those hit with network
> > problems. Does anyone know if the docs say how to cope with it? What
> > to try to make it work, what boot paramter to use to use de4x5 instead
> > of tulip? If not we should add that. I can write something up if
> > someone corrects the grammar and spelling.
>
> I don't think much work has been done on the Install Manual for Alpha.
>
> You might be able to track it down on the Alpha lists (kernel or
> debian lists or even SUSE support databases, which are pretty good).
I thought I saw some options to let the tulip scan only certain io
adresses, but I can't find it anywhere. Not in the source, nor docs
not faqs on the web. Must have imagined that. In the worst case this
needs a small driver patch.
MfG
Goswin
PS: Any options about 2.4 and devfs?
Reply to: