Mozilla for OS/2 has a really annoying bug
<http://bugzilla.mozilla.org/show_bug.cgi?id=129696>. I wanted to see if
Mozilla for Linux had a similar limitation. So, I backup, shutdown OS/2
and restart into Linux. 10:30.
[some background]
Most of my Linux experience is on boxen other than my 24/7 machine (VIA
MVP3 & K6/2) on which I used to have only DOS and OS/2 installed. My
last HD upgrade was performed by installing HD in a spare machine and
transferring to the main machine to minimize downtime on 24/7. I took
that opportunity to install 8.1 on it, using the spare box.
I had installed 8.1 several times previously, both on SCSI and IDE. This
install was from SCSI CD (/dev/scd0) on LSI HBA1 (8751), to SCSI HD
(/dev/sda) on LVD LSI HBA0 (8953). Mainboard was TX chipset w/ K6/2 CPU.
Grub on separate /boot. Modem worked. KDE worked. Tty's worked. Don't
remember trying much beyond that.
Moved HD and 8953 HBA to 24/7 machine. For the CD, HBA was on an 8150
HBA instead of 8751, which also has my data backup SCSI HD. Booted DOS
OK. Tried reboot. LSI BIOS message never displays, and boot never
progresses further. Turn off machine. Turn machine back on. Still no LSI
BIOS message, and boot hung again.
Removed HBA and HD and put back into TX machine. Perfect function.
Shutdown. Repeat. Shutdown. Repeat. No problem.
Moved HBA and HD back to 24/7. Boot into DOS OK. Tried reboot. LSI BIOS
message never displays, and boot never progresses further. Turn off
machine. Turn machine back on. Still no LSI BIOS message, and boot hung
again.
Removed HBA and HD and put back into TX machine. Perfect function.
Shutdown. Repeat. Shutdown. Repeat. No problem.
Moved HBA and HD back to 24/7. Boot into DOS OK. Tried reboot. LSI BIOS
message never displays, and boot never progresses further. Turn off
machine. Turn machine back on. Still no LSI BIOS message, and boot hung
again.
Removed 8953 and put the HD on an extra 8751. DOS boot worked. OS/2
worked. Over and over everything OK.
Pulled 8751 and moved HD back to 8953. Boot into DOS OK. Tried reboot.
LSI BIOS message never displays, and boot never progresses further. Turn
off machine. Turn machine back on. Still no LSI BIOS message, and boot
hung again.
Removed 8953 and put the HD on a second 8751. DOS boot worked. OS/2
worked. Over and over everything OK.
So, I emailed LSI in detail. Got virtually instant response. They would
try to recreate. Two days later, email announced they don't have same
motherboard to try and cannot recreate with what they have.
Then Booted Linux for first time using new HD in 24/7, but didn't
actually do anything with it then, and never booted it again between
installation in January, and yesterday.
[back to story]
Before OS/2 shutdown, I downloaded six rpms from cooker to HPFS,
Mozilla, Mozilla-Mail, Mozilla-IRC, two lib deps that worked the last
time I tried a Mozilla upgrade, and one lib dep that did not work the
last time (png). First thing to do on Linux boot was test to see if
Mozilla 0.9.4 from 8.1 had the bug.
wvdial: not found. Oh great, have to start by installing missing stuff.
Find 8.1 CD's. mount: /dev/scd0: no such device. Now what? I see
/dev/scd0 exists. Why doesn't this work? I also see stuff like
/dev/scsi/busx/idx/lun0, so the devs are there. Why doesn't this work? I
have no idea where to start looking for the solution to this, so I
decide to reinstall to make sure all devs appropriate to the hardware is
installed.
I started install from SCSI CD, using F1 for vgalo and expert. First
thing I noticed is the install stops if I make the logical choice of
SCSI support. Both NCR53c8xx and SYM53c8xx are listed. Since all my
HBA's were actually made long after NCR was no longer the company making
the chips, and labeled either Symbios or LSI, the natural choice to make
is SYM, not NCR. But, by choosing SYM, the installer cannot locate any
CD to complete the install from.
About the time I was finishing package selection, after an uneventful
assign partitions process, I realized my CDRW was not connected. I keep
my CDRW in a two bay external case, along with an 8 Gb HD to provide
some iso workspace and storage, so I can have CDRW access to any of my
machines. Except for the temporary setup to install my newest HD in my
24/7, none of the other machines have any SCSI other than a single 8751.
So, I exited install to restart with the CDRW connected, to ensure that
configuration would be correct automatically. When I use my CDRW, I
remove my backup SCSI HD cartridge, which is kept at the same SCSI ID
(2) as the HD in the external case. This allows me to have DOS, windoze,
and OS/2 all maintain the same drive letters when the CDRW and its
companion HD are connected. It should allow Linux to assign the
companion to a device later than the boot device.
I restarted install, and when I reached assign partitions, the companion
HD was /dev/sda, and the boot device was now /dev/sdb. This had me
baffled. I realized the sure fix was to simply disable the HD, so I
removed the cartridge, remembering that not only had I forgotten to
unplug it to start with, but also that it had the same ID as the CDRW
companion HD that I totally forgot was even there. Both are the same
brand and model. When I restarted install yet again, I was further
baffled that the "same" HD was still there at all, besides, on HBA1,
being /dev/sda ahead of the boot HD on HBA0.
On a few more restarts, I was seeing HBA1 being found in the boot
messages as the first HBA, followed the HBA0, being found as the second.
I restarted into SCSI setup, and found that even though I had made the
8953 the priority device, it had the higher device ID and base address.
Thinking this was confusing Linux, I took off the cover and swapped
adapters. Now in SCSI setup I not only had the 8953 as the priority
device, but also it had the lower device ID and base address.
No go. Even after forcing the BIOS to reverse the IRQ assignments, Linux
still insisted the second HBA come first and vice versa. I was forced to
pull the cover from the external case and pull the power plug from the
companion HD. Now I could finally see Linux assign the boot HD to
/dev/sda, like it should have all along.
To back up a little farther, the 8150, 8751, and 8953 all have flash
eproms and nvram. To ensure an absence of conflicts. I flashed the 8150
with the LSI null BIOS. The 8150 is older and its eprom is only 32K,
which means the latest LSI BIOS versions won't fit. All my other SYM/LSI
cards I keep flashed to the most recent BIOS, currently 4.19.
So, now I've gotten Linux installed, but can't use the 8 bit SCSI HD's,
because I can't put them on the LVD HBA, and on the CD's HBA, they get
found before the boot device.
OK, I say. For now, who cares. On to the original task, trying Mozilla.
So, I boot Linux the first time, and find the first install screwup
right away. I answered wrong when the siamesed NIC and modem network
connections were configured. It should be clearer when the installer
asks if I want to start on boot. I only wanted eth0 up, not ppp. Linux
is starting both eth0 and ppp on boot. For now I leave it be. I went to
restore /root/.bashrc and /etc/fstab at least. Mandrake installer isn't
bright enough to tell HPFS from NTFS and make a usable /etc/fstab. Then
did umount -a and mount -a. I neglected to put HPFS to ro before knowing
the install was good.
ppp was up, so I went to KDE and opened Mozilla to make the original
test I had been after when this all started. No bug. Mozilla 0.9.4 had
no problem writing an 8.3 file to an MSDOS mounted filesystem.
Jumping back to console, I copied the earlier downloaded rpms to /tmp,
and tried urpmi on Mozilla without remembering to close Mozilla first.
ppp was still up. I got a long list of failed deps. Not having actually
read man on urpmi, going only on the little I'd read on the mailing
list, I just went ahead and had it ignore the deps, then did
Mozilla-Mail and Mozilla-IRC, followed by the two libs that had
previously worked. These all completed without incident. As before, the
png rpm gave me an incredibly long list of failed deps, so I skipped it
and went on to KDE.
Oops. Mozilla 0.9.4 not yet closed. Hit the close X. Waited for quiet.
Opened up Mozilla 0.9.8. Whew! It works. No png's on Linux-Mandrake, but
Mozilla is running. Found a page to save to FAT. It works. Bug is OS/2
only.
Went to Bugzilla and updated my bug, then checked email using Mozilla.
Decided I needed to get back to OS/2 for now. After KDE logout, I
shutdown from console with telinit 6, totally forgetting about init and
ppp. This I remembered about halfway through shutdown, so I chose to
bring Linux back up again. Bad choice. Init hung on trying to get ppp
up. I thought I could fail it and make it proceed by turning the modem
power off. That didn't help, even after waiting probably close to two
minutes. Then I powered the modem back up. After more waiting, init is
still hung on ppp.
I pushed the reset button. On restart I edited the grub line to start in
runlevel 2. fsck. On root login, and not knowing how to turn off ppp in
init directly, I tried to run drakconf -> not found. I can't believe
this. Why not? I set mc to search for *rak*, and drakconf is there. su.
Now drakconf works. I turn off ppp on boot. I run fsck on other ext2
partitions. Don't know why this is not automatic like on the /
partition.
Enough Linux for now. Telinit 6. I've got to see what happened to HPFS.
Yup. Dirty. Auto CHKDSK on G:. 30 minutes later, all goes quiet, and
CHKDSK had made no indication it was done. Wait a while longer. Still no
change. CAD. On restart, OS/2 again finds G: dirty and starts CHKDSK.
Again, it never finishes. After a futile wait, I CAD again, and this
time boot C: instead of F:. Still G: is found dirty. Again, a really
long wait after all went quiet and still CHKDSK doesn't finish.
This time I reboot to DOS, and try Partition Magic to check G:. It
claims OK. I tried booting back into OS/2, and G: was still dirty. After
reboot into DOS once again, I tried the DFSee DOS version. No good.
Would not run either the dirty or the check command. Next I reboot using
OS/2 floppies so that CHKDSK isn't automatic. I start DFSee OS/2
version. and stupidly choose to try check before trying dirty. Over two
hours later, check is still running, and shows progress at 5%. I give up
on DFSee.
I boot into DOS, format G: with Partition Magic, then boot into OS/2 and
perform restore on G:. Takes a while, but by 22:00 OS/2 works again.
Before midnight, I've caught up on mail, news and bugzilla.
[epilogue]
I certainly haven't remembered every detail from yesterday. But above is
the gist of it. I can't wait to forget about it, but the SCSI HBA order
is just too troubling. Regardless of how set physically or in the BIOS,
Linux, and only Linux, insists on putting the wrong HBA in priority.
Oh, and Mandrake, no matter how much better than it used to be, still
has a lot of ground to cover before reaching a state of
user-friendliness.
--
"And we know that all things work together for good to them that
love God, to them who are the called according to His purpose."
Romans 8:28 KJV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://mrmazda.members.atlantic.net/
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
