8:10 p.m.
Anaconda is barfing when I try to upgrade my existing F10. The machine has
an IDE drive that contains a single Windows partitions, and two SCSI drives,
hanging off an Adaptec 29320 HBA, with F10 on both drives in a RAID-1
configuration.
When Anaconda gets to the "checking storage" phase, it spins for a while,
then proceeds immediately to do a new install.
The partitioning screen has only /dev/sda listed, which is the existing
Windows partition. /dev/sdb and /dev/sdc, the two SCSI drives, are not
shown. HOWEVER:
When I flip over to ALT-F2, "fdisk /dev/sdb" and "fdisk /dev/sdc" read
the
partition table of the two SCSI drives. So, what I have is:
1) The kernel sees the SCSI drives
2) On some other ALT-F screen I see all the soothing messages from the md
subsystem concerning registering various md personalities.
However,
3) mdadm isn't running
4) Anaconda sees neither the softraid partitions, nor the actual underlying
/dev/sd? devices at all.
WTF?
This is a 64 bit machine. I have another machine 32 bit machine with no
IDE drives, two SCSI drives connected to an AIC-7902B, also in a RAID-1
configuration, and I had no problems whatsoever upgrading that one to F11.
2:55 p.m.
On Tue, Jun 30, 2009 at 17:27:58 +0200,
Roberto Ragusa <mail(a)robertoragusa.it> wrote:
Ok, I know that, but I suppose that the refusal to upgrade on a degraded
array would be "do not do something dangerous when the array is not really
in good conditions" and then a (debatable) assumption that 4 mirrors out
of 5 is an emergency condition.
I think the concern is that if the other device shows back up later something
bad could happen. (Such as mirroring from the newly put back device over
the top of the fresh install.) I don't know if that is a real possibility,
but I can see why people might have concern.
That is another unreasonable limitation.
For example, mdadm is a little petulant if I try to create a 1-disk RAID-1,
but it finally does it if I force it enough.
Well I think so, but the anaconda guys don't.
Was there a motivation for "wontfix"?
I'm curious to listen what kind of logic has been applied.
They don't consider a 1 element raid 1 array as a valid array and are worried
people will think they have redundancy when they don't.
The bug below gives a pretty good look at the various viewpoints. I think
I have seem some other similar bugs, if you want to look for more:
https://bugzilla.redhat.com/show_bug.cgi?id=188314
Also there was a thread on the anaconda list:
http://www.redhat.com/archives/anaconda-devel-list/2008-November/msg00233...
10:27 a.m.
Bruno Wolff III wrote:
On Tue, Jun 30, 2009 at 15:02:04 +0200,
Roberto Ragusa <mail(a)robertoragusa.it> wrote:
> Anaconda refused to detect the "degraded" array. 4 disk in RAID-1 is not
> exactly degraded, I would say... :-)
> I had to "grow" the array from 5 disks to 4.
Degraded means that all of the array elements aren't functional, not whether
there is still redundancy.
Ok, I know that, but I suppose that the refusal to upgrade on a degraded
array would be "do not do something dangerous when the array is not really
in good conditions" and then a (debatable) assumption that 4 mirrors out
of 5 is an emergency condition.
In my opinion this limitation is completely unjustified.
RAID has as objective "the system will go on"; if an upgrade is impossible
then the system is not going on, and it's happening for no real technical
reason.
> I have no idea if this still applies.
Yes.
In your case you could have dropped the number of elements in the array,
did the install and then bumped it back up again. If you only had two drives
This is what I did.
I did grow the array from 5 to 4 (that is, reverse-grow).
you wouldn't have been able to, because anaconda also has a
minimum number
of drives for each raid type. So even a complete 1 element raid 1 array
can't be used for an install.
That is another unreasonable limitation.
For example, mdadm is a little petulant if I try to create a 1-disk RAID-1,
but it finally does it if I force it enough.
These things are really annoying, as they happen in a particularly
delicate moment, when you don't have your usual environment, you may not
have an internet connection and you are already tired because of the
slow DVD boot and other details.
In the past I have patched anaconda to allow
this. There have been RFEs both for allowing degraded arrays and allowing
complete 1 element raid 1 arrays and both (well actually more since there
are duplicates of these RFEs) have been closed won't fix.
Was there a motivation for "wontfix"?
I'm curious to listen what kind of logic has been applied.
--
Roberto Ragusa mail at robertoragusa.it
9:37 a.m.
On Tue, Jun 30, 2009 at 15:02:04 +0200,
Roberto Ragusa <mail(a)robertoragusa.it> wrote:
Anaconda refused to detect the "degraded" array. 4 disk in
RAID-1 is not
exactly degraded, I would say... :-)
I had to "grow" the array from 5 disks to 4.
Degraded means that all of the array elements aren't functional, not whether
there is still redundancy.
I have no idea if this still applies.
Yes.
In your case you could have dropped the number of elements in the array,
did the install and then bumped it back up again. If you only had two drives
you wouldn't have been able to, because anaconda also has a minimum number
of drives for each raid type. So even a complete 1 element raid 1 array
can't be used for an install. In the past I have patched anaconda to allow
this. There have been RFEs both for allowing degraded arrays and allowing
complete 1 element raid 1 arrays and both (well actually more since there
are duplicates of these RFEs) have been closed won't fix.
8:02 a.m.
Sam Varshavchik wrote:
See above. I can see the bloody drives just fine, from the shell on
ALT-F2.
Probably something different, but with an older Fedora (5?) I discovered
that anaconda refuses to run RAID-1 arrays if they are in degraded mode.
In my case I had a 5 disk RAID-1 root partition and I smartly decided
to remove one of the disks from the array so to have an unchanged disk
in case a I wanted to revert the upgrade.
Anaconda refused to detect the "degraded" array. 4 disk in RAID-1 is not
exactly degraded, I would say... :-)
I had to "grow" the array from 5 disks to 4.
I have no idea if this still applies.
--
Roberto Ragusa mail at robertoragusa.it
6:48 a.m.
On 06/30/2009 01:07 AM, Andrew Parker wrote:
On Sat, Jun 27, 2009 at 9:10 PM, Sam
Varshavchik<mrsam(a)courier-mta.com> wrote:
> Anaconda is barfing when I try to upgrade my existing F10. The machine has
> an IDE drive that contains a single Windows partitions, and two SCSI drives,
> hanging off an Adaptec 29320 HBA, with F10 on both drives in a RAID-1
> configuration.
>
> When Anaconda gets to the "checking storage" phase, it spins for a while,
> then proceeds immediately to do a new install.
>
> The partitioning screen has only /dev/sda listed, which is the existing
> Windows partition. /dev/sdb and /dev/sdc, the two SCSI drives, are not
> shown. HOWEVER:
>
> When I flip over to ALT-F2, "fdisk /dev/sdb" and "fdisk /dev/sdc"
read the
> partition table of the two SCSI drives. So, what I have is:
>
> 1) The kernel sees the SCSI drives
>
> 2) On some other ALT-F screen I see all the soothing messages from the md
> subsystem concerning registering various md personalities.
>
> However,
>
> 3) mdadm isn't running
>
> 4) Anaconda sees neither the softraid partitions, nor the actual underlying
> /dev/sd? devices at all.
>
You may want to bugzilla this. Anaconda had all sorts of storage
changes during f11 and had numerous problems. I believe it was (one
of?) the reasons that F11 slipped. A few days before the f11 release
anaconda was trying to resize one of my partitions that wasn't even
being used in the install.
I had a major problem with installing on a system with Raid partitions as well,
due to my use of a kickstart install. This is noted in the Install notes
I know.
Will a "fixed" anaconda package be release soon to fix these issues so we can
roll our own "fixed" F11 ?
7:07 p.m.
On Sat, Jun 27, 2009 at 9:10 PM, Sam Varshavchik<mrsam(a)courier-mta.com> wrote:
Anaconda is barfing when I try to upgrade my existing F10. The
machine has
an IDE drive that contains a single Windows partitions, and two SCSI drives,
hanging off an Adaptec 29320 HBA, with F10 on both drives in a RAID-1
configuration.
When Anaconda gets to the "checking storage" phase, it spins for a while,
then proceeds immediately to do a new install.
The partitioning screen has only /dev/sda listed, which is the existing
Windows partition. /dev/sdb and /dev/sdc, the two SCSI drives, are not
shown. HOWEVER:
When I flip over to ALT-F2, "fdisk /dev/sdb" and "fdisk /dev/sdc"
read the
partition table of the two SCSI drives. So, what I have is:
1) The kernel sees the SCSI drives
2) On some other ALT-F screen I see all the soothing messages from the md
subsystem concerning registering various md personalities.
However,
3) mdadm isn't running
4) Anaconda sees neither the softraid partitions, nor the actual underlying
/dev/sd? devices at all.
You may want to bugzilla this. Anaconda had all sorts of storage
changes during f11 and had numerous problems. I believe it was (one
of?) the reasons that F11 slipped. A few days before the f11 release
anaconda was trying to resize one of my partitions that wasn't even
being used in the install.
5:37 p.m.
Bill Davidsen writes:
Sam Varshavchik wrote:
> David Timms writes:
>
>> On 06/28/2009 11:10 AM, Sam Varshavchik wrote:
>>> 4) Anaconda sees neither the softraid partitions, nor the actual
>>> underlying /dev/sd? devices at all.
>> When you say softraid, you mean linux software raid, rather than bios
>> raid or hardware raid ?
>
> Yes. Linux softraid.
>
>> Maybe it is related to:
>>
https://fedoraproject.org/wiki/Common_F11_bugs#Kickstart_installations_ca...
>>
>
> No. I am not doing a kickstart install.
>
> And I succesfully updated two other machines with F10 installed on Linux
> softraid, to F11.
>
> Something in Anaconda is failing to see the second and the third drive
> on a machine with the first drive being an IDE drive, and the 2nd and
> the 3rd drive being SCSI drives. It doesn't see the drives, but I can
> flip over to the ALT-F2 shell, and run mdadm --assemble --scan. mdadm
> ends up creating /dev/md125, /dev/md126, and /dev/md127 (!), rather than
> /dev/md[012], but I can mount them manually and see my existing F10
> partitions.
>
This sounds as if either the raid or scsi modules are not being loaded. My guess
would be the scsi modules, but if you haven't solved this yet, when you get
Of course they're getting loaded. As I said: I can run mdadm to assemble the
RAID and mount them. If they weren't getting loaded, mdadm would do bupkis.
I'd be surprised if mdadm, on it's own:
* Surveyed the attached IDE and SCSI hardware
* Mapped them to the supporting kernel module(s)
* Loaded the kernel module(s)
I'd be surprised if mdadm has all that logic built-in. More than likely it
just sweeps all the existing device nodes, looking for RAID partitions it
can assemble together.
started, could you 'lsmod' and see if the scsi stuff is
loaded before running
mdadm? mdadm is smart, they might be loaded on demand.
Actually, I can run 'fdisk /dev/sdb' and 'fdisk /dev/sdc' before running
mdadm, and read the partition table. Everything is loaded, kernel-wise.
Bug 508554 -- F11 anaconda is seeing the disks, but intentionally ignoring
them, for some reason.
1:59 p.m.
Sam Varshavchik wrote:
David Timms writes:
> On 06/28/2009 11:10 AM, Sam Varshavchik wrote:
>> 4) Anaconda sees neither the softraid partitions, nor the actual
>> underlying /dev/sd? devices at all.
> When you say softraid, you mean linux software raid, rather than bios
> raid or hardware raid ?
Yes. Linux softraid.
> Maybe it is related to:
>
https://fedoraproject.org/wiki/Common_F11_bugs#Kickstart_installations_ca...
>
No. I am not doing a kickstart install.
And I succesfully updated two other machines with F10 installed on Linux
softraid, to F11.
Something in Anaconda is failing to see the second and the third drive
on a machine with the first drive being an IDE drive, and the 2nd and
the 3rd drive being SCSI drives. It doesn't see the drives, but I can
flip over to the ALT-F2 shell, and run mdadm --assemble --scan. mdadm
ends up creating /dev/md125, /dev/md126, and /dev/md127 (!), rather than
/dev/md[012], but I can mount them manually and see my existing F10
partitions.
This sounds as if either the raid or scsi modules are not being loaded. My guess
would be the scsi modules, but if you haven't solved this yet, when you get
started, could you 'lsmod' and see if the scsi stuff is loaded before running
mdadm? mdadm is smart, they might be loaded on demand.
So, Anaconda is not even assembling my existing RAID arrays. I can
assemble them manually, but Anaconda does not see them.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
9:18 p.m.
On 06/28/2009 11:10 AM, Sam Varshavchik wrote:
4) Anaconda sees neither the softraid partitions, nor the actual
underlying /dev/sd? devices at all.
When you say softraid, you mean linux software
raid, rather than bios
raid or hardware raid ?
Maybe it is related to:
https://fedoraproject.org/wiki/Common_F11_bugs#Kickstart_installations_ca...
DaveT.
10:15 p.m.
Mikkel L. Ellertson writes:
Sam Varshavchik wrote:
> David Timms writes:
>
>> On 06/28/2009 11:10 AM, Sam Varshavchik wrote:
>>> 4) Anaconda sees neither the softraid partitions, nor the actual
>>> underlying /dev/sd? devices at all.
>> When you say softraid, you mean linux software raid, rather than bios
>> raid or hardware raid ?
>
> Yes. Linux softraid.
>
>> Maybe it is related to:
>>
https://fedoraproject.org/wiki/Common_F11_bugs#Kickstart_installations_ca...
>>
>
> No. I am not doing a kickstart install.
>
> And I succesfully updated two other machines with F10 installed on Linux
> softraid, to F11.
>
> Something in Anaconda is failing to see the second and the third drive
> on a machine with the first drive being an IDE drive, and the 2nd and
> the 3rd drive being SCSI drives. It doesn't see the drives, but I can
> flip over to the ALT-F2 shell, and run mdadm --assemble --scan. mdadm
> ends up creating /dev/md125, /dev/md126, and /dev/md127 (!), rather than
> /dev/md[012], but I can mount them manually and see my existing F10
> partitions.
>
> So, Anaconda is not even assembling my existing RAID arrays. I can
> assemble them manually, but Anaconda does not see them.
>
2 dumb questions:
1 - Does your BIOS see the drives?
See above. I can see the bloody drives just fine, from the shell on ALT-F2.
2 - Have you tried doing an expert install?
I can't find documentation on the expert installation option in F11's
install documentation. Earlier Fedoras had an expert boot option, but it no
longer seems to be present.
10 p.m.
Sam Varshavchik wrote:
David Timms writes:
> On 06/28/2009 11:10 AM, Sam Varshavchik wrote:
>> 4) Anaconda sees neither the softraid partitions, nor the actual
>> underlying /dev/sd? devices at all.
> When you say softraid, you mean linux software raid, rather than bios
> raid or hardware raid ?
Yes. Linux softraid.
> Maybe it is related to:
>
https://fedoraproject.org/wiki/Common_F11_bugs#Kickstart_installations_ca...
>
No. I am not doing a kickstart install.
And I succesfully updated two other machines with F10 installed on Linux
softraid, to F11.
Something in Anaconda is failing to see the second and the third drive
on a machine with the first drive being an IDE drive, and the 2nd and
the 3rd drive being SCSI drives. It doesn't see the drives, but I can
flip over to the ALT-F2 shell, and run mdadm --assemble --scan. mdadm
ends up creating /dev/md125, /dev/md126, and /dev/md127 (!), rather than
/dev/md[012], but I can mount them manually and see my existing F10
partitions.
So, Anaconda is not even assembling my existing RAID arrays. I can
assemble them manually, but Anaconda does not see them.
2 dumb questions:
1 - Does your BIOS see the drives?
2 - Have you tried doing an expert install?
Mikkel
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
9:50 p.m.
David Timms writes:
On 06/28/2009 11:10 AM, Sam Varshavchik wrote:
> 4) Anaconda sees neither the softraid partitions, nor the actual
> underlying /dev/sd? devices at all.
When you say softraid, you mean linux software raid, rather than bios
raid or hardware raid ?
Yes. Linux softraid.
Maybe it is related to:
https://fedoraproject.org/wiki/Common_F11_bugs#Kickstart_installations_ca...
No. I am not doing a kickstart install.
And I succesfully updated two other machines with F10 installed on Linux
softraid, to F11.
Something in Anaconda is failing to see the second and the third drive on a
machine with the first drive being an IDE drive, and the 2nd and the 3rd
drive being SCSI drives. It doesn't see the drives, but I can flip over to
the ALT-F2 shell, and run mdadm --assemble --scan. mdadm ends up creating
/dev/md125, /dev/md126, and /dev/md127 (!), rather than /dev/md[012], but I
can mount them manually and see my existing F10 partitions.
So, Anaconda is not even assembling my existing RAID arrays. I can assemble
them manually, but Anaconda does not see them.
5433
days inactive
5435
days old
12 comments
8 participants
participants (8)
-
Andrew Parker -
Bill Davidsen -
Bruno Wolff III -
Development discussions related to Fedora -
Mikkel -
Roberto Ragusa -
Sam Varshavchik -
Terry Barnaby