On Fri, Sep 18, 2015 at 2:18 PM, Dirk Hoffmann <[log in to unmask]> wrote:
>
>> 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.

You also received general question, most of which you've answered
directly or indirectly The key piece of information, is that these are
not "new disks" as you originally stated. They're apparently
repurposed disks. Those are notably more difficult to QA, and to
ensure that they are in a "pristine" or consistent state. There is a
particular old problem I encountered with virtual machines where the
old disk images had LVM based logical volumes, especially including
"physical volumes" in a set that included disks or partitions that are
no longer availab.e

Hilarity ensued. I had to explain to several engineers, for both VM's
and for repurposing hardware, that you should really clear the first
blocks of a disk before handing it off to an installer, precisely to
clear this and other kinds of confusion.

>> 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.

1 GB should be enough to at least do the basic SL7 installation.

>> 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"?

In the previously unstated details of "Boot on original OS". That's
the critical part. Since there was an "original OS", it's not a "new
disk".

>> 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?

It normally does, yes

>> 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.

I assume you mean "not  other differenice than the disk partitioning
was noticed".

>>> 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

And above, you said "fdisk", which is vary much not the same as 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.

On the old disk. My strong working theory is that you've encountered a
variant of the LVM problems I mentioned.

>> 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.

Good! You may not encounter the problem with yet another disk, if it's
related to the LVM issue I mentioned. I used to have to script
clearing those, and the inconsistencies and overlaps of output from
lvscan, vgscan, and pvscan drove me buggy trying to automate the whole
"clean this disk of partitions, I am *not kidding*" that I used to
have to put in my kickstart files.

> Cheers
>                                                                         Dirk