Hi Máirín,
> We don't show sda/sdb/usbN/scsi (at least if you have more than one scsi
> card) because those are not reliable and can change from boot-to-boot
> because they're assigned based on scan ordering and the order in which
> the relevant modules are loaded. We're very cautious about protecting
> users from dataloss where we can, so if a storage label is not
> persistent / reliable, we decided to not use it.
The hardware never mixes up the Primary IDE Master, Primary IDE Slave,
Secondary IDE Master, Secondary IDE Slave. /usr/sbin/dmidecode tells all.
dmidecode also seems to work for SATA:
DMI type 8, 9 bytes;
Port Connector Information
Internal Reference Designator: SATA4 (note the '4')
Internal Connector Type: On Board IDE
I can open the box, look at the cables, read the silkscreen labels on the
mainboard, [apply the mobo/BIOS errata], and read the labels/serial numbers
on the drives. Surely *something* in /sys (etc.) can do the equivalent
matching, even if the kernel chooses not to do so for daily operations.
But install is not a daily operation, and more care is appropriate
during install.
If persistence and reliability is the criterion, then drive serial numbers
win; so don't hide them. And where are the facilities for dealing with
UUID of partitions?
[snip]
> Can you tell us a little bit more about your setup? I'm guessing it's a
> desktop machine, right? What kind of drives do you have in it, how do
> you use them? Are they all the same size and RAIDed, or does each have a
> different OS, or...?
This box is a common self-built mid-tower with 4 drives (2 IDE, 2 SATA)
plus an ATAPI Zip drive (usually empty). There are about three dozen hard
partitions. Mostly, each is the root of a different installed version:
Fedora and Ubuntu, i686 and x86_64, going back many years. As a consultant,
I must run what my customers run (future customers, too.)
Most customers run 1 to 3 years behind the bleeding edge,
and they don't run virtualized systems. The bugs are different,
and I cannot afford to waste any more time chasing non-reproducible cases.
>
> We're trying to design the UI to be as seamless as possibly for the
> majority of users who would use a GUI to install Fedora, which we've
> found is overwhelmingly laptop users who are necessarily limited to a
> small max bound of disks. However, we still want it to work for other
> cases.
I run into a similar situation in software development. The target market
wants and needs a fairly simple solution, but the early adopters and
gate-keepers tend to be experts who will not accept "toys".
>
>> Sometimes I have multiple drives of the same make and model,
>> so I need to see the serial numbers, too.
>
> We do display those if you hover over the drives. How do you know the
> serial number - do you open up the box and look so you are sure?
I have a paper list created during physical assembly of my own boxes,
and a text file. I also have screenshots from gparted. For customer
boxes, sometimes I open the box and look. I also run a LiveCD,
then read syslog, and run smartctl and hdparm.
[snip]
>
>> There was no message "No LVM2 structures were found" which is
>> required in order to increase my confidence and help detect errors.
>
> Can you tell us a little bit more about what you were looking to do
> here?
I want more assurance that the installer has correctly detected the
storage configuration. This part of the installer is a scout that
I send on a reconnaissance mission. A good scout reports not only
what was seen, but also what was checked for but not observed.
That category of "I looked for it, but did not see it" is just as
important as "I looked for it, and did see it."
--
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
