David Cantrell wrote:
>
> On Sat, Dec 16, 2000 at 06:23:03AM -0600, Phil Howard wrote:
> > David Cantrell <david@slackware.com> wrote:
> > >
> > > Please, for the love of god, someone tell me if they've successfully
> > > installed the latest snapshot or not! :)
> >
> > The fdisk program is definitely bugged:
> >
> > Command (m for help): n
> > Partition number (1-8): 4
> > First sector (2841334-4187232): 2841336
> > Sector 684 is already allocated
> > First sector (2841334-4187232):
> > Value out of range.
> > First sector (2841334-4187232):
> > Value out of range.
> > First sector (2841334-4187232):
> > Value out of range.
> > First sector (2841334-4187232):
> > Value out of range.
> > First sector (2841334-4187232): 2841334
> > Sector 684 is already allocated
> > First sector (2841334-4187232): 3000000
> > Sector 723 is already allocated
> > First sector (2841334-4187232): 4187200
> > Sector 1008 is already allocated
> > First sector (2841334-4187232):
> >
> > Due to bugs I've also found in the Intel version, I've pretty much
> > decided I need to write another one. Others like cfdisk and sfdisk
> > don't do what I want for some other projects. Now I just need to
> > find the time to develop it.
>
> 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'm still having troubles getting the CDROM read on the Sparc side.
> > And I don't have a place to run NFS (yet) on the Intel side. So
> > what I tried to do was set up a partition on /dev/sdb to copy all
> > the files from the CD and just install from there. When I got to
> > the point of running tar to tar, there were I/O errors reading from
> > the CD. This may be what is causing setup to not find the CDROM.
> >
> > My workaround was to dd the CD image to /dev/sdb1, mount that,
> > mkfs /dev/sdb4, mount that, then tar copy from sdb1 to sdb4.
> > I didn't know if the mount in setup would handle sdb4 being in
> > ISO9660 format, so I did it this way.
> >
> > The interesting thing is, there are CDROM I/O errors when reading
> > a mounted CD, but not when reading the device image directly.
>
> 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.
> > I got a couple error messages during install of "etc" saying md5sum not
> > found. Maybe some package scripts expect md5sum. I know I would find it
> > useful sometimes. The "sun4u" package just had the same errors.
> >
>
> 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.
> > Series A now seems to be installed. SILO didn't seem to set the PROM boot
> > device, and I forget the syntax at the moment to describe the disk. I went
> > ahead and boot the CDROM kernel and specified root=/dev/sda1. Below is a
> > sampling of some error messages starting near the end of the ones regarding
> > the root not being mounted read-only:
>
> No, SILO setup is still totally manual. I'll let everyone know when I
> have a working siloconfig program.
Oh, OK. I recall now you have already mentioned that.
> > 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.
> > BTW, the SysRQ feature isn't working on Sparc serial port. BREAK just drops
> > to PROM.. My thought for the kernel is to change it so BREAK doesn't do
> > that, but make a SysRQ letter to drop to the PROM if SysRQ is enabled.
> > Another suggestion for the kernel people instead of us.
> >
>
> 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?
> > 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"
> > | Welcome to Linux 2.2.17 (ttyS0)
> > |
> > | darkstar login: root
> > | Password:
> > | Linux 2.2.17.
> > | You have mail.
> > | root@darkstar:~# df
> > | Filesystem 1k-blocks Used Available Use% Mounted on
> > | /dev/sda1 1962624 52684 1808632 3% /
> > | root@darkstar:~#
> >
>
> YAHOO!! Someone got it installed! :)
Yes!
-- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam@ipal.net | Texas, USA | http://phil.ipal.org/ | -----------------------------------------------------------------
This archive was generated by hypermail 2b30 : Thu Sep 19 2002 - 11:00:02 PDT