Bug 6673 - Numerous bugs in Python script, some suggestions
Summary: Numerous bugs in Python script, some suggestions
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jay Turner
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-03 03:15 UTC by klingler
Modified: 2015-01-07 23:39 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-11-03 12:51:49 UTC
Embargoed:


Attachments (Terms of Use)

Description klingler 1999-11-03 03:15:58 UTC
I'm a RedHat 5.2 buyer and I just downloaded 6.1 on the strength of its RAID support for evaluation against FreeBSD for some experimental servers.  The installation so far has not succeeded, and it's been extremely problematic.  This is an FTP installation; I've done perhaps 20 using 5.0, 5.1, 5.2 and 6.0.

The machine in question:

- HP Vectra VL Series 5 5/133 upgraded with a Winchip 2A-233, 256k L2 cache, 48 Megs RAM, HX chipset, various IDE boot drives.  Machine confirmed to boot other OSes fine, and I've tried several different known-good IDE drives.  The idea is
to boot IDE, use SCSI RAID 5 array for storage.

- 3Com 3c905 PCI Ethernet card

- Advansys ABP915 PCI SCSI adapter

I'm attempting an anonymous FTP installation from my own server, off which
I've already done one successful FTP installation to another clone with all SCSI hardware from this server with no configuration changes.  Have other Winchip 2A machines up for several months, so I don't believe they're a factor.  These are Python scripting errors, perhaps exacerbated by some timeouts that are set too low.

The following problems, along with my reference titles for them, are the easily repeatable ones:

1.  MD not spoken, not really.
Blew away my md device prepared on another successfully-built 6.1 machine (clone, all scsi).  Rather than help me build a raidtab and keep the MD device (what I expected given the language on the RedHat website) it listed the devices separately and then actually blew away the partitioning information without telling me.  On subsequent installation attempts the disks came up without partitioning info and I confirmed it was gone by moving the MD device back to the original server.  I'm very glad I hadn't moved much data across, but it did waste a lot of my time and leave me gritting my teeth.  This could potentially make someone very, very angry.  It's the kind of thing you'd get from those damned paperclip animators up northwest.

2.  You can never go back.
Installation doesn't forget partitioning info, even if you hit the back button without saving.  Seems to automagically save partitioning info even if you don't want it to sometimes, but I haven't been able to pin down exactly when.  Happened to me once (and I didn't hit yes), and it really sucked.

3.  FTP doesn't cotton to CWD.
Behavior changed (for the worse) when, as a test, I threw an old 170 meg IDE drive on just in case the 1.2 gig IDE I was using might be corrupt somehow.  At the point where it went out to get the package list I got a Python script error that ended in the following:

	"/var/tmp/python-root/usr/lib/python1.5/ftplib.py", line 201, in
	getresp IOError: [Errorno ftp error] 500 'CWD': command not understood"

I'm not a Python guy yet, but this appears to be a bug in the installation script library.  I don't know why the script works differently for my 170 meg IDE versus my 1.2 gig IDE when going out to retrieve the package list.  I consistently got past this point when I was using the 1.2 gig drive; I consistently hung at this point when I used the 170 meg with the above error
message. "Shore 'nuff", I said. "CWD ain't a command in ftp."

4. I'll die anyway.
The error I got with the 1.2 gig was a kernel panic as soon as the installation began formatting the drive, not much additional info.  Happens consistently.
The message is "Kernel panic: Free list corrupted."  This is as far as I have gotten in more attempt than I care to admit (>20).

5.  I'll swap anything.
At one point it decided I didn't have enough remaining space to create a
swap partition, so it changed the status of a Linux native partition (the only
other partition) to invalid.  At that point no combination of deletion, addition or editing could convince the machine to make a new Linux native partition, and since it wouldn't forget what I'd already told it, hitting the back button didn't help either.  I had to reboot and start from scratch.

In addition to the above install bugs, I've got the following hopefully constructive criticisms:

1.  It was a big pain when I found out that the check box in the ftp for
"non-anonymous ftp installation" was no longer there.  I had to go back and install anonymous ftp on the other machine.  Time consuming.

2.  The loss of fdisk is keenly felt.  I much preferred it.

3.  This installation script overall doesn't seem as smart as old install.
For example, it doesn't know enough to check for a swap partition like the
old one did, so it goes on and hangs.

4.  Disk Druid doesn't know how to make a RAID partition, despite the RAID
support advertised.

5.  The "server" choice of machine configurations installs without kernel source.  Really.  Yet there are still various X-related things in there.  And the "server" choice was the one that blew away my MD device.

Thanks for your hard work and attention.

Dave Klingler
klingler

Comment 1 Jay Turner 1999-11-03 12:51:59 UTC
The Server-class installation is advertised to remove all existing
partitions and recreate based on the partitioning scheme which is
published in the manual.  Blowing away an existing MD device is the
expected behavior, so that is not a bug.

There is a "reset" button in Disk Druid which restores the partition
table to its status since the last time that you wrote the partition
table, so clicking this button should restore to original state, thus
"forgetting" the changes which you have made in Disk Druid.

The FTP problem that you are seeing is probably not related to the
drive that you are installing to, but rather to a known oddity in the
installer.  For FTP installations, the FTP server must be specified as
either a fully-qualified domain name or as the IP address.  In
addition, there must *NOT* be a trailing slash on the path to the
source files.  We have seen this CWD error when the previous two
statements are not true.  Let me know if you are getting this error
under different circumstances.

I will have to get back to you on the "free list corrupt"  This is an
error that we used to see a lot in the 5.2 days, but I have not seen
it since.  Sorry!

With this swap thing, I am assumming that you are in Disk Druid when
this is happening.  If that is the case, then we are aware of some
strange things happening when the user starts adding and deleteing
partitions, and we are working to determine what exactly is happening
with the partition stack, but you can always click "reset" to get back
to a clean slate and start identifying and creating partitions anew.

We have received many requests to reimplement the non-anonymous FTP
feature, so get your eyes open in future releases.

Fdisk is still available, but it is only accessible in expert mode
(type "expert" at the boot prompt)

Could you please provide more details about Disk Druid not knowing how
to create a RAID partition.  We have had no trouble here in the test
lab, as well as at user sites getting RAID 0,1, and 5 setup and
functioning without fail.

Finally, we have received many reports that the Server-class
installation does not install kernel source, and this was an oversight
on our parts.  The workaround is to install the source afterwards.  We
will make sure to fix this in later releases.  As for the X stuff
which gets installed with a Server-class installation, this is a
side-effect of the way that RPM handles dependencies and we are trying
to get this more streamlined so that the Server-class installation
will not include any X components at all.

Thanks for the feedback.  I am putting your suggeestions into a
features request document here at the office.

Comment 2 Jay Turner 1999-11-03 12:52:59 UTC
*** Bug 6669 has been marked as a duplicate of this bug. ***

I'm a RedHat 5.2 buyer and I just downloaded 6.1 on the strength of its RAID support for evaluation against FreeBSD for some experimental servers.  The installation so far has not succeeded, and it's been extremely problematic.  This is an FTP installation; I've done perhaps 20 using 5.0, 5.1, 5.2 and 6.0.

The machine in question:

- HP Vectra VL Series 5 5/133 upgraded with a Winchip 2A-233, 256k L2 cache, 48 Megs RAM, HX chipset, various IDE boot drives.  Machine confirmed to boot other OSes fine, and I've tried several different known-good IDE drives.  The idea is
to boot IDE, use SCSI RAID 5 array for storage.

- 3Com 3c905 PCI Ethernet card

- Advansys ABP915 PCI SCSI adapter

I'm attempting an anonymous FTP installation from my own server, off which
I've already done one successful FTP installation to another clone with all SCSI hardware from this server with no configuration changes.  Have other Winchip 2A machines up for several months, so I don't believe they're a factor.  These are Python scripting errors, perhaps exacerbated by some timeouts that are set too low.

The following problems, along with my reference titles for them, are the easily repeatable ones:

1.  MD not spoken, not really.
Blew away my md device prepared on another successfully-built 6.1 machine (clone, all scsi).  Rather than help me build a raidtab and keep the MD device (what I expected given the language on the RedHat website) it listed the devices separately and then actually blew away the partitioning information without telling me.  On subsequent installation attempts the disks came up without partitioning info and I confirmed it was gone by moving the MD device back to the original server.  I'm very glad I hadn't moved much data across, but it did waste a lot of my time and leave me gritting my teeth.  This could potentially make someone very, very angry.  It's the kind of thing you'd get from those damned paperclip animators up northwest.

2.  You can never go back.
Installation doesn't forget partitioning info, even if you hit the back button without saving.  Seems to automagically save partitioning info even if you don't want it to sometimes, but I haven't been able to pin down exactly when.  Happened to me once (and I didn't hit yes), and it really sucked.

3.  FTP doesn't cotton to CWD.
Behavior changed (for the worse) when, as a test, I threw an old 170 meg IDE drive on just in case the 1.2 gig IDE I was using might be corrupt somehow.  At the point where it went out to get the package list I got a Python script error that ended in the following:

	"/var/tmp/python-root/usr/lib/python1.5/ftplib.py", line 201, in
	getresp IOError: [Errorno ftp error] 500 'CWD': command not understood"

I'm not a Python guy yet, but this appears to be a bug in the installation script library.  I don't know why the script works differently for my 170 meg IDE versus my 1.2 gig IDE when going out to retrieve the package list.  I consistently got past this point when I was using the 1.2 gig drive; I consistently hung at this point when I used the 170 meg with the above error
message. "Shore 'nuff", I said. "CWD ain't a command in ftp."

4. I'll die anyway.
The error I got with the 1.2 gig was a kernel panic as soon as the installation began formatting the drive, not much additional info.  Happens consistently.
The message is "Kernel panic: Free list corrupted."  This is as far as I have gotten in more attempt than I care to admit (>20).

5.  I'll swap anything.
At one point it decided I didn't have enough remaining space to create a
swap partition, so it changed the status of a Linux native partition (the only
other partition) to invalid.  At that point no combination of deletion, addition or editing could convince the machine to make a new Linux native partition, and since it wouldn't forget what I'd already told it, hitting the back button didn't help either.  I had to reboot and start from scratch.

In addition to the above install bugs, I've got the following hopefully constructive criticisms:

1.  It was a big pain when I found out that the check box in the ftp for
"non-anonymous ftp installation" was no longer there.  I had to go back and install anonymous ftp on the other machine.  Time consuming.

2.  The loss of fdisk is keenly felt.  I much preferred it.

3.  This installation script overall doesn't seem as smart as old install.
For example, it doesn't know enough to check for a swap partition like the
old one did, so it goes on and hangs.

4.  Disk Druid doesn't know how to make a RAID partition, despite the RAID
support advertised.

5.  The "server" choice of machine configurations installs without kernel source.  Really.  Yet there are still various X-related things in there.  And the "server" choice was the one that blew away my MD device.

Thanks for your hard work and attention.

Dave Klingler
klingler


Note You need to log in before you can comment on or make changes to this bug.