Date: Tue, 07 Nov 1995 12:34:17 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: uhclem%nemesis@fw.ast.com (Frank Durda IV) Cc: bugs@freebsd.org, phk@freebsd.org Subject: Re: Bugs in/near installation 1104 SNAP Message-ID: <656.815776457@time.cdrom.com> In-Reply-To: Your message of "Tue, 07 Nov 1995 08:44:00 %2B0700." <m0tCpGU-000JD4C@nemesis.lonestar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> **** DEBUG: Makedev: Called with - on path /mnt/dev > **** DEBUG: Makedev: - is an unknown device type! I've seen this too, and it appears to be benign. It was always happening but my extra debugging messages brought it to light. :-) I probably won't dive on this one unless Poul-Henning feels a sudden urge to revisit libdisk and figure out why MakeDevChunk() does this. > **** Warning: calculated sectors per cylinder (4000) disagrees with > **** disk label (1008) > **** /dev/rwd0a 200000 sectors in 50 cylinders of 1 tracks, 4000 sectors > **** 97,7MB in 4 cyl groups (16 c/g, 31.25MB/g, 3776 i/g) > > Isn't this a totally horrible and inefficient way to manage a disk? Talk to Poul-Henning.. :-) We've been over this one before. Again, I probably won't try to address this one. > cpio: /mnt/dev/wd0s2a not created: newer or same age version exists > **** 0 blocks This is fine. It's basically just saying that I created it already (as I have to for certain devices) and it's not going to bother overlaying it. Some parts of the install are brute-force and attempt to redo work that's already done. Since it'd be substantially harder to make it cleverer about it, and to no real gain, I'm not going to bother. > 3. During kernel -c, if you use "visual" and specify an interrupt > value of "2", it is not re-mapped to "9" as it is in the non-visual > configuration utility. Hmmm! If I can get a quick and relatively non-intrusive fix in for this, I'll address it. Otherwise, probably not. > 4. If you elect to configure X during install, someone needs to do > a "stty erase ^H" before running the X configure script. I can do this. > 5. /bin/797 is still broken. Probeonly can't find the "X" you > supposedly just installed and fails. 797? You've lost me. What's a /bin/797? > 6. Probably not a bug, but without enabling any extra debug messages, > the F2 screen randomly displays dozens of "DEBUG: FTP Close Called" > messages throughout the extraction. I can shut this up. > After waiting for remote site to come back up, I asked the install > to download lynx again. It failed and network board lights show > it didn't even hit the network before saying it failed. But, > if you ask for it once again, it hits the network, finds the > files and downloads OK. Hmmm. I will attempt to reproduce. > 8. After rebooting, /etc/hosts has some trailing trash on > the local system entry: (in my case) > > 165.164.6.19 skaro.lonestar.org skaro 165 > *** Already fixed in updated boot images (see floppies/README). > 9. Again, probably not a bug, but installing the compats > leaves you with a "telnet" that won't run. > > telnet 165.164.6.15 > ld.so failed: Undefined symbol "_dst_realm_sz" in telnet:telnet > The "bad" telnet is about 10K larger than the "good" one. Yes, this has been reported. I'm still waiting for some input on rebuilding the compat distributions (these are done totally by hand and we're still using the 2.0.5 ones). I could use some help with these, folks! > I don't recall reading in the installation that loading these > modules would replace working modules with non-working ones, > or it wasn't clear. Well, it's not *supposed to* - it's supposed to just load older shared libs (e.g. the actual telnet binary isn't touched at all). However, this still seems to cause telnet to have a hissy fit. Not sure why yet. I'll go back and look through both compat dists to see if something is in there that shouldn't be (I'd also like to encourage other folks to look too - last time I build compat20 by myself I ended up leaving some DES code in there by mistake!). Thanks for all the feedback! Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?656.815776457>