On Sat, Dec 16, 2000 at 03:19:13PM -0600, Phil Howard wrote:
> David Cantrell wrote:
> >
> > Couple of questions:
> >
> > - What kind of disklabel is on this disk?
> > - What kind of disk is it?
> >
> > I've run into problems similar to this on the SPARC and I've gotten around
> > them by writing a new Sun disklabel to the disk.
> >
> > If this is something else, I'm definitely interested in fixing it.
>
> Before running fdisk I did:
> dd if=/dev/zero of=/dev/sdb bs=4096
> Then when I did run fdisk, it prompted me for the type of disk. I entered
> the value "0" for custom, then pressed empty returns to all questions for
> device parameters to accept the defaults, which appeared to all be correct.
> So the disk label involved was what fdisk put there.
>
> Even the Intel version of fdisk has had calculation and overlap bugs since
> I recall ever using it. In some cases those bugs won't put partitions right
> next to each other. In other cases I have seen overlaps. One of the things
> I am seeing in the sparc fdisk is that it lets me allocate cylinder numbers
> 0 through 1008 for a 1008 cylinder disk, whereas the Intel version numbers
> the first cylinder as 1. I think there are a combination of "one off" bugs
> and calculations not respecting sector mode in there.
I must say that that's a very odd way of going about partitioning. What I
do is just drop the disk in the machine (no dd step involved), then fire
up fdisk on that device and type "s" to create a new empty Sun disklabel.
Then I create partitions from there.
> > This is pretty odd. I've burned a couple test images using the ISOs on
> > topsecret and they appear to work fine for me. Do you have another CD-ROM
> > drive you can use?
>
> I don't think it's the media, since I can read the CDROM just fine when I'm
> not doing it with a filesystem, e.g. when reading the device directly. And
> after I copy the ISO image to a HD partition, I can mount and read it there
> just fine, so that also rules out mkisofs and the ISO support in VFS in the
> kernel as the problem sources.
>
> A couple months ago I did chase down a bug I encountered with device buffering
> in the 2.2.17 kernel with Andrea Arcangeli's help. The problem related to the
> sizes of buffered and cached I/O requests. The cause seemed to be the version
> of the gcc compiler used. With 2.91.66 there was a problem. Backing down the
> version of gcc to 2.7.2.3 fixed the problem. My assumption is something in
> the buffering code (bit field accesses I suspected) was being compiled wrong.
> Maybe that is happening here with the different device blocksize of Sun CDs.
> Just a guess. But if you are compiling the kernel with 2.9X.X versions of gcc
> you might try backing down to 2.7.2.X and see if that makes a difference.
OK, that could be it. I am using gcc 2.95.2 to compile the kernels. I'm
going to upgrade to 2.2.18 and use gcc 2.95.2. I'd like you to give that
new kernel a try and see if it does the same thing. If it does, I'll
recompile using another compiler and we'll see if it goes away then.
> > Yes, some of those packages expect md5sum. The error isn't properly
> > trapped and I know about this.
>
> Are they running it from the install CD initrd system, or from the target
> filesystem? It would seem just including md5sum somewhere would be easy.
Yeah, I could just drop the md5sum binary on the root disk. It's not
actually in the path until the textutils package gets installed.
> > > And I'm guessing the installed inittab was one for video. I'm thinking
> > > maybe Slackware needs a configuration setup prompt to ask for whether or not
> > > virtual console logins should be enabled, and likewise for serial ports. It
> > > could be a list with [X] choices much like the prompt for which series to
> > > install, one per tty device to start getty on.
> > >
> >
> > Yes, *DEFINITELY* a good idea! I'll work on that for the configuration
> > stage of the set up program.
>
> Such a configuration stage would be good even in Intel version, for headless
> server boxes like the Intel ISP1100. Other platforms might use it, too.
Perhaps. I'll definitely be showing Patrick what I've added to the
installer on the SPARC and he may decide to adopt some of that on the
Intel side.
> > True. I think there are boot parameters for the kernel for the SysRQ
> > handling on the SPARC, but I could be wrong. Perhaps there's an option we
> > could pass on the serial booting method that would properly enable this?
>
> I'll look around in the kernel again. All my kernel work is with 2.4.0-testX
> right now, but perhaps Slackware 7.2 could end up with a 2.4 kernel if it
> becomes finalized soon enough? Or would that be held off for 8.0?
I don't think you will see 2.4 for a while. 2.2.18 was just released and
has the USB backport included now. 2.2.19 is having the new 2.4 memory
management thing backported.
> > > BTW, this is how I'm booting up right now:
> > > ok boot cdrom serial console=ttya root=/dev/sda1 ro
> > >
> > > It would be nice if the fsck didn't so that progress bar on serial port. It
> > > produces a LOT of output which slows it down on a 9600 baud serial port.
> > > I'll hack around on that later.
> > >
> >
> > Hmmm....ok, I can go with that. I'll try to think of any easy way to fix
> > that up.
>
> This should catch most cases (bash assumed):
>
> # if not serial console use progress bar
> [ -z "`egrep 'console=tty[a-z]' /proc/cmdline`" ] && fsckopt="${fsckopt} -C"
Cool. I'll toss that in and we'll see how well it works for serial
console users.
--
David Cantrell | david@slackware.com *
KG6CII | Slackware Linux Project
This archive was generated by hypermail 2b30 : Thu Sep 19 2002 - 11:00:02 PDT