It's very difficult to verify or get details from your complaint. And
now you seem upset because I called the difficulty into question.
No, I am dissatisfied, because of general remarks instead of concrete
questions. I think I answered all questions, please tell me if not.
There's missing critical information, such as whether your colleague
made the correct selections in the disk partitioning interface for SL
7, which is admittedly a confusing interface,
The "partition disk automatically" option was (found and) used. The process
then led to spurious hangups, which have not been documented further. It may
have to do with memory (RAM), which was only 1GB on some machines. Still, I
would suggest to have the installer indicate "out of memory" after an initial
check rather than hanging forever without further notice.
or what other changes
they may have made in "creating a dumb partition", or even what
fileysystem that "dumb partition" uses.
I do not understand this question. Boot on original OS, fdisk /dev/<newdisk>,
boot on DVD and install on /dev/<newdisk>. Where do you see place for "other
changes"?
And, you can't run "fdisk" on a new disk without setting a label on
the new disk, unless the disk already had a label pre-set. Many do:
was the label pre-set to something oddball? Was the "new disk" a brand
new disk, or a pre-formatted disk from some vendor? Does it work if
you "zero" the disk, or at least zero the first 2048 blocks, which is
one of my favorite tricks for clickly restoring a disk to a "pristine"
state?
I cannot tell, because I will have a hard time convincing anybody to erase
the disk, which was successfully (and painfully) installed finally. But can
the installer (better) implement all these advices in the pre-partitioning
process, once the user has selected "auto" or "disk can be erased" in the
dialog?
I mean the new anaconda installer for SL 7, which is relatively new.
I see. I think these are sufficiently known and understood in this case. At
least there was no difference noticed in the unsuccessfull compared to the
successful installation.
Why? What exactly do you think we need to understand? There was no
possibility (at least not visible enough) to partition the new disk during
the installation procedure. We guessed the reason and managed to partition
it on another system manually (gparted).
The reason you guessed sounds unlikely. I'm not saying it didn't
happen, but that it seems unlikely, so I wonder what else was going
on.
Trying to answer as good as I know:
Did the disk not show up *at all* in the interface until a dummy
partition was created?
Yes
How was the dummy partition created?
gparted
Was a label needed and added?
Will have to ask (Monday).
Was there already partition information, such as spurious LVM or other
partitons?
On the disk or in the system (old disk)? The new disk was received from the
"recycle and erase service" of our lab and had been used before under unknown
circumstances. The old disk very likely had the standard LVM setup, which
comes with SL6 by default.
And this is definitely not the case, I've verified it in the last 24
hours with VM based installation and entirely new disk images.
Again, I do not think VM test cases cover the case of "recycled" disks. But
you seem to suspect that as well, when you are asking about LVM above.
You've come to a conclusion inconsistent with other people's experience and
unlikely in the extreme for a freeware rebuild of a commercial grade
operating system.
No, I did not conclude. I observed. And asked. However, this kind of arguing
is waste of time.
Anyway, thanks for your help. And on the next re-installation I will invest
an extra 30 minutes to try with a "weird" recycled disk first, eventually
zero if failure and report.
Cheers
Dirk
