Subject: fedora-list Digest, Vol 59, Issue 5

From: [email-masked]
Date: Thu, 1 Jan 2009 19:44:31 -0500 (EST)

Send fedora-list mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.redhat.com/mailman/listinfo/fedora-list
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of fedora-list digest..."
Today's Topics:

   1. Re: Network changing from eth0 to eth1 (Nat Gross)
   2. Re: Catch-22 : wide monitor -- Surprise! (Bill Davidsen)
   3. Re: Catch-22 : curiouser and curiouser -- but better
      (Bill Davidsen)
   4. Re: RAID5 gets a bad rap (Bill Davidsen)
   5. Re: RAID5 gets a bad rap (Bill Davidsen)
   6. Re: Network changing from eth0 to eth1 (Bill Davidsen)
   7. Re: Network changing from eth0 to eth1 (Bill Davidsen)
   8. Re: Network changing from eth0 to eth1 (Nat Gross)
   9. Re: Network changing from eth0 to eth1 (Mikkel L. Ellertson)
  10. Re: Unrecognized Hard Drive (jdow)
  11. Re: Network changing from eth0 to eth1 (Bill Davidsen)
  12. Re: Unrecognized Hard Drive (jdow)

Subject: Re: Network changing from eth0 to eth1
From: "Nat Gross" <[email-masked]>
To: "Community assistance, encouragement, and advice for using Fedora." <[email-masked]>
Date: Thu, 1 Jan 2009 17:02:13 -0500

On Thu, Jan 1, 2009 at 3:59 PM, Mikkel L. Ellertson
<[email-masked]> wrote:
> Nat Gross wrote:
>> On Thu, Jan 1, 2009 at 1:09 PM, Mikkel L. Ellertson
>>> If you are looking in /etc/sysconfig/network-scripts for ifcfg-eth0,
>>> and not finding it, they you are probably using NetworkManager to
>>> manage the interface. You may have to configure it again. (If you
>>> looked in the wrong place, make sure ifcfg-eth0 has "ONBOOT=yes".)
>>>
>>> Mikkel
>>> --
>> I don't have any file that begins with ifcfg in /etc/sysconfig/network-scripts.
>> I took another look at the "services" gui and am not running
>> NetworkManager and I am running 'network'. And now I notice that in
>> the "status" area it sais (when network is highlighted):
>> --------------------------
>> ls: cannot access ifcfg*. No such file or directory.
>> Configured devices:
>> lo
>> Currently active devices:
>> lo eth0
>> --------------------------
>> Any clues?
>> Thanks;
>> nat
>>
> Definitely strange - At the very least, you should have ifcfg-lo!
>
> If you are using hte network service and DHCP, ifcfg-eth0 should
> look something like this:
Once you told me that I need these two files, I grabbed them from
another fedora 8 box on the same lan, adjusted the static ip address,
and... voila! It works!
Thank you!
& Happy New Year!
nat

Subject: Re: Catch-22 : wide monitor -- Surprise!
From: Bill Davidsen <[email-masked]>
To: [email-masked]
Date: Thu, 01 Jan 2009 17:52:35 -0500

fred smith wrote:
> On Mon, Dec 29, 2008 at 11:19:45AM -0500, Bill Davidsen wrote:
>> Beartooth wrote:
>>
>>> 	Btw, I don't really suppose this new change in anaconda is an act 
>>> of purposeful obscurantism -- but the result is not significantly 
>>> different. If the developers were deliberately trying to drive non-
>>> technoid users away, they could hardly do it more effectively than by 
>>> this and several other changes (such as package kit and network manager).
>>>
>> I have to agree, FC10 is absolutely the worst install available. I have it 
>> on five machines now, and in every case I had to do video tricks to get a 
>> working display. I think the people who put in that animated boot display 
>> took control, and were more concerned with having people oh and ah over the 
>> animation that have a working default video mode like 800x600, and have the 
>> graphics *fit* instead of depending on screen scrolling, which also doesn't 
>> work on several machines I tried, even if you know it's there.
>>
>> I have still been giving out FC9 DVDs to people, FC10 is just geek material 
>> as far as I'm concerned. FC10 is great software, but a hideous install.
> 
> Bill, I'm not disputing your experience. I've only installed F10 on a single
> machine, my eeepc 901, but on that machine it "just works".
> 
> As there is a LOT of variance from one machine to the next, I don't
> doubt that there are those where it is less smooth than my experience.
> 
> 
The issue is that FC9 works on all of the machines in question without problems. 
So it's very hard to say that on five servers, two laptops, and a virtual 
machine that I have just the wrong Intel, SiS, or ATI/Radeon video and the wrong 
display. I shouldn't have to set video modes every time with vga=, and if the 
install insists on picking a VGA 800x600 mode the content should fit, because 
new users don't know about screen scroll.

Bah.

-- 
Bill Davidsen <[email-masked]>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Subject: Re: Catch-22 : curiouser and curiouser -- but better
From: Bill Davidsen <[email-masked]>
To: [email-masked]
Date: Thu, 01 Jan 2009 17:55:36 -0500

Beartooth wrote:
> On Mon, 29 Dec 2008 11:25:26 -0500, Bill Davidsen wrote:
> 
>> One answer, the PAE kernel is used for 32 bit operation with 4GB or more
>> of ram. Lets you see the whole memory.
> 
> 	Well, I looked at both the system-monitor and lshw-gui -- and got 
> very different answers. One tells me I have 2.8 GB of (unspecified) 
> "memory," while the other tells me 4 GB of "system memory," with two 
> entries for RAM, neither of which says (in a form I can read, at least) 
> how much. One just says 32; the other gives "widths" of 64 for the cpu, 
> and 32 for each of its RAMs.
> 
> 	My guess is that I might as well remove the PAE -- if I could, 
> without initiating yet another catastrophe; I did big damage a few years 
> by removing kernels wrong somehow. Probably better to let well enough 
> alone -- especially if never using either eventually gets them 
> expired ....
> 
>>    "We have more to fear from the bungling of the incompetent than from
>> the machinations of the wicked."  - from Slashdot
> 
> 	If only more people would realize that! 
> 
> 	(I also like the version that says something like "Never 
> attribute to malevolence what can be explained by mere stupidity" -- and 
> Schiller's "Mit der Dummheit kaempfen Goetter selbst vergebens." (In 
> Asimov's translation, "Against stupidity the Gods themselves contend in 
> vain."))
> 
If you want to know what the system can use, just type "free" and look at the 
total memory.

And not "stupidity," but rather "incompetence." They are not the same.

-- 
Bill Davidsen <[email-masked]>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Subject: Re: RAID5 gets a bad rap
From: Bill Davidsen <[email-masked]>
To: [email-masked]
Date: Thu, 01 Jan 2009 18:04:54 -0500

Gordon Messmer wrote:
> Philip A. Prindeville wrote:
>>
>> If you're *not* a database weenie, and you're doing usual manly things 
>> with your filesystem (like lots of compiles, for instance), you're 
>> typically not going to be modifying files in place at all.
> 
> That's not quite it.  RAID 5 performance suffers because every write 
> requires that the entire block that's being written be read from every 
> drive in the array, parity calculated, and then the data and parity 
> written out.  For each block written, the array has to do N reads plus 
> two writes.
> 
No. Even in the worst case it would read N-2 blocks (you are writing a new data 
block and calculating new parity), and two writes. But normally, writing 
sequential data, you can wait until you have enough data for an entire stripe at 
once, read nothing, and write once to each drive. You should be able to do this 
in parallel, but unlike RAID0 I've never measured it happening. Tuning the 
"stripe_cache_size" and creating a filesystem using the "stride=" option will help.

> It doesn't matter whether you're writing new files or modifying existing 
> files, because all of this happens at the block level.  It's especially 
> bad on journalled filesystems, where writing to a file will update the 
> files blocks, plus the filesystem's journal's blocks, and finally the 
> filesystem's blocks.
> 
No again. You read the parity block and the old data block, XOR first the old 
then the new data with the parity block, and write the new data and parity.

>> So is it just the database-heads that are maligning RAID5, or are 
>> there other performance issues I don't know about?
> 
> Most of your comments don't reflect the way RAID 5 actually functions in 
> any way.
> 
>> Because my empirical experience has always been that when writing 
>> large files, RAID5 performs on par with RAID0.
> 
> The system on which you were testing was probably limited by other 
> factors, if that was the case.  A RAID 0 disk array will be much faster 
> than a RAID 5 array.
> 
> RAID 5 tends to be most appropriate when you're trying to get as much 
> disk space as you can with the lowest cost, you won't be running 
> multiple simultaneous jobs on the same disk array, and when you'll be 
> collecting data at a rate that's relatively low.  Usually, that's 
> backups.  Your network is probably slower than your disk array (unless 
> the array is very large -- array speed decreases with array size), so 
> streaming data in over the network to your disk array won't bog it down. 
>  Virtually any interactive workload will benefit from a better disk 
> configuration.
> 

-- 
Bill Davidsen <[email-masked]>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Subject: Re: RAID5 gets a bad rap
From: Bill Davidsen <[email-masked]>
To: [email-masked]
Date: Thu, 01 Jan 2009 18:07:08 -0500

Gordon Messmer wrote:
> Chris Tyler wrote:
>> On Tue, 2008-12-30 at 01:02 -0800, Gordon Messmer wrote:
>>> That's not quite it.  RAID 5 performance suffers because every write 
>>> requires that the entire block that's being written be read from 
>>> every drive in the array, parity calculated, and then the data and 
>>> parity written out.  For each block written, the array has to do N 
>>> reads plus two writes.
>>
>> You don't have to read all of the drives -- just the block you're
>> updating and the parity block. XOR the old data you're about to
>> overwrite with the parity block and the new data and you'll have the new
>> parity block. Total activity: two reads plus two writes.
> 
> I've understood that to be the case, but while watching the drive 
> activity lights on RAID5 arrays, it seems like I always see the entire 
> set flash at the same time.  I guess I'll have to investigate that 
> further to find out why.  Thanks.
> 
>>> RAID 5 tends to be most appropriate when you're trying to get as much 
>>> disk space as you can with the lowest cost, you won't be running 
>>> multiple simultaneous jobs on the same disk array, and when you'll be 
>>> collecting data at a rate that's relatively low.
>>
>> I'd say the other way around -- RAID 5 is poor at small writes (hence
>> the OP's comments about database updates), but very nearly approaches
>> RAID-0 speeds when reading or writing large quantities of sequential
>> data.
> 
> Your assertion ignores the fact that filesystems themselves are, in 
> fact, databases.  Real-world experience with many production systems and 
> many workloads has convinced me to use RAID 5 as rarely as possible. 
> Even when I'm forced to use it, I generally choose a RAID 5+0 
> configuration as I get much better performance.
> 
Or you might want to read the man pages for md and mdadm. RAID10 is faster 
(assuming you use the "far 2" config). No, RAID10 is not another name for RAID1+0...

-- 
Bill Davidsen <[email-masked]>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Subject: Re: Network changing from eth0 to eth1
From: Bill Davidsen <[email-masked]>
To: [email-masked]
Date: Thu, 01 Jan 2009 18:19:55 -0500

Nat Gross wrote:
> On Mon, Nov 3, 2008 at 3:09 PM, Phil Meyer <[email-masked]> wrote:
>> Jim wrote:
>>> FC8, KDE
>>> What is changing the Network settings from eth0 to eth1 ?
>>>
>>> Even if you go into /etc/sysconfig/network-scripts/ifcfg-eth0 and setup as
>>> eth0, and reboot box,it will change settings to eth1.
>>>
>>> And it is causing a unstable network.
>>>
>>> This box only has one ethernet card in  it.
>>>
>>
>> Now days, when Fedora detects a different NIC from one it knew (right or
>> wrong), it creates a new entry in: /etc/udev/rules.d/70-persistent-net.rules
>>
>> This is why you get messages in dmesg and at bootup that eth0 is being
>> 'moved' to eth1.
>>
>> It is reasonably safe to remove this file, plus
>> /etc/sysconfig/network-scripts/ifcfg-eth? and reboot.
>>
>> If you are just doing DHCP, then udev will recreate the file, put the
>> correct NIC into it, and set up a generic ifcfg-eth0 script.
>>
>> Good luck!
>>
> Thanks for this post, it helped me a bit, but I still have nameserver problem.
> Yesterday my [only]nic in a 32 bit fc8 box blew. When I replaced it,
> it insisted to be eth1 and gave me eth0 errors when booting. I did an
> ifconfig 192.168.... and had eth1 up and running.

You did change the MAC address in the config, to reflect the change right? 
Otherwise eth0 will go to the old MAC address even if not present, and the next 
NIC found will be eth1, eth2, etc.

-- 
Bill Davidsen <[email-masked]>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Subject: Re: Network changing from eth0 to eth1
From: Bill Davidsen <[email-masked]>
To: [email-masked]
Date: Thu, 01 Jan 2009 18:23:07 -0500

Mikkel L. Ellertson wrote:
> Nat Gross wrote:
>> On Thu, Jan 1, 2009 at 1:09 PM, Mikkel L. Ellertson
>>> If you are looking in /etc/sysconfig/network-scripts for ifcfg-eth0,
>>> and not finding it, they you are probably using NetworkManager to
>>> manage the interface. You may have to configure it again. (If you
>>> looked in the wrong place, make sure ifcfg-eth0 has "ONBOOT=yes".)
>>>
>>> Mikkel
>>> --
>> I don't have any file that begins with ifcfg in /etc/sysconfig/network-scripts.
>> I took another look at the "services" gui and am not running
>> NetworkManager and I am running 'network'. And now I notice that in
>> the "status" area it sais (when network is highlighted):
>> --------------------------
>> ls: cannot access ifcfg*. No such file or directory.
>> Configured devices:
>> lo
>> Currently active devices:
>> lo eth0
>> --------------------------
>> Any clues?
>> Thanks;
>> nat
>>
> Definitely strange - At the very least, you should have ifcfg-lo!
> 
> If you are using hte network service and DHCP, ifcfg-eth0 should
> look something like this:
> 
> DEVICE=eth0
> BOOTPROTO=dhcp
> ONBOOT=yes
> HWADDR=<MAC address>
> DHCP_HOSTNAME=<something>
> TYPE=Ethernet
> IPV6INIT=no
> NM_CONTROLLED=no
> USERCTL=no
> 
> You don't need all of this - you could get by with:
> 
> DEVICE=eth0
> BOOTPROTO=dhcp
> ONBOOT=yes
> NM_CONTROLLED=no
> 
I really suggest using the MAC field, it prevents learning about Plauger's Law 
(law of least astonishment) the hard way... Of course the O.P. was using the MAC 
field (I suspect) and didn't know it.

> You should also be able to create it using system-config-network.
> 
Indeed. And I believe that should be part of the default install again.

> Mikkel

-- 
Bill Davidsen <[email-masked]>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Subject: Re: Network changing from eth0 to eth1
From: "Nat Gross" <[email-masked]>
To: "Community assistance, encouragement, and advice for using Fedora." <[email-masked]>
Date: Thu, 1 Jan 2009 18:37:15 -0500

On Thu, Jan 1, 2009 at 6:19 PM, Bill Davidsen <[email-masked]> wrote:
> Nat Gross wrote:
>>
>> On Mon, Nov 3, 2008 at 3:09 PM, Phil Meyer <[email-masked]>
>> wrote:
>>>
>>> Jim wrote:
>>>>
>>>> FC8, KDE
>>>> What is changing the Network settings from eth0 to eth1 ?
>>>>
>>>> Even if you go into /etc/sysconfig/network-scripts/ifcfg-eth0 and setup
>>>> as
>>>> eth0, and reboot box,it will change settings to eth1.
>>>>
>>>> And it is causing a unstable network.
>>>>
>>>> This box only has one ethernet card in  it.
>>>>
>>>
>>> Now days, when Fedora detects a different NIC from one it knew (right or
>>> wrong), it creates a new entry in:
>>> /etc/udev/rules.d/70-persistent-net.rules
>>>
>>> This is why you get messages in dmesg and at bootup that eth0 is being
>>> 'moved' to eth1.
>>>
>>> It is reasonably safe to remove this file, plus
>>> /etc/sysconfig/network-scripts/ifcfg-eth? and reboot.
>>>
>>> If you are just doing DHCP, then udev will recreate the file, put the
>>> correct NIC into it, and set up a generic ifcfg-eth0 script.
>>>
>>> Good luck!
>>>
>> Thanks for this post, it helped me a bit, but I still have nameserver
>> problem.
>> Yesterday my [only]nic in a 32 bit fc8 box blew. When I replaced it,
>> it insisted to be eth1 and gave me eth0 errors when booting. I did an
>> ifconfig 192.168.... and had eth1 up and running.
>
> You did change the MAC address in the config, to reflect the change right?
> Otherwise eth0 will go to the old MAC address even if not present, and the
> next NIC found will be eth1, eth2, etc.
In the network gui, there is a "probe" button. I used that and saw it
magically change the MAC.
nat

Subject: Re: Network changing from eth0 to eth1
From: "Mikkel L. Ellertson" <[email-masked]>
To: "Community assistance, encouragement, and advice for using Fedora." <[email-masked]>
Date: Thu, 01 Jan 2009 18:19:50 -0600

Bill Davidsen wrote:
> Mikkel L. Ellertson wrote:
>>
>> If you are using the network service and DHCP, ifcfg-eth0 should
>> look something like this:
>>
>> DEVICE=eth0
>> BOOTPROTO=dhcp
>> ONBOOT=yes
>> HWADDR=<MAC address>
>> DHCP_HOSTNAME=<something>
>> TYPE=Ethernet
>> IPV6INIT=no
>> NM_CONTROLLED=no
>> USERCTL=no
>>
>> You don't need all of this - you could get by with:
>>
>> DEVICE=eth0
>> BOOTPROTO=dhcp
>> ONBOOT=yes
>> NM_CONTROLLED=no
>>
> I really suggest using the MAC field, it prevents learning about
> Plauger's Law (law of least astonishment) the hard way... Of course the
> O.P. was using the MAC field (I suspect) and didn't know it.
> 
>> You should also be able to create it using system-config-network.
>>
> Indeed. And I believe that should be part of the default install again.
> 
>> Mikkel
>>
With /etc/udev/rules.d/70-persistent-net.rules, you are probably not
going to run into it if you do not use HWADDR in ifcfg-eth? On the
other hand, I do tend to use something like the first example I gave
- you don't need to, but it can prevent surprises.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

Subject: Re: Unrecognized Hard Drive
From: "jdow" <[email-masked]>
To: "Community assistance, encouragement, and advice for using Fedora." <[email-masked]>
Date: Thu, 1 Jan 2009 16:29:54 -0800

From: "Eli Pelcastre" <[email-masked]>
Sent: Thursday, 2009, January 01 11:19

> Maybe this can guide you:
> http://www-personal.umich.edu/~hnarayan/maxtor-harddrive-linux.html
> 
> Gustavo Eli Pelcastre H.

Aside from its egregious error using /dev/sda1 it's "sort of useful."
The first part of it will get him to the point of recognizing the drive.

{^_^}

Subject: Re: Network changing from eth0 to eth1
From: Bill Davidsen <[email-masked]>
To: [email-masked]
Date: Thu, 01 Jan 2009 19:43:14 -0500

Mikkel L. Ellertson wrote:
> Bill Davidsen wrote:
>> Mikkel L. Ellertson wrote:
>>> If you are using the network service and DHCP, ifcfg-eth0 should
>>> look something like this:
>>>
>>> DEVICE=eth0
>>> BOOTPROTO=dhcp
>>> ONBOOT=yes
>>> HWADDR=<MAC address>
>>> DHCP_HOSTNAME=<something>
>>> TYPE=Ethernet
>>> IPV6INIT=no
>>> NM_CONTROLLED=no
>>> USERCTL=no
>>>
>>> You don't need all of this - you could get by with:
>>>
>>> DEVICE=eth0
>>> BOOTPROTO=dhcp
>>> ONBOOT=yes
>>> NM_CONTROLLED=no
>>>
>> I really suggest using the MAC field, it prevents learning about
>> Plauger's Law (law of least astonishment) the hard way... Of course the
>> O.P. was using the MAC field (I suspect) and didn't know it.
>>
>>> You should also be able to create it using system-config-network.
>>>
>> Indeed. And I believe that should be part of the default install again.
>>
>>> Mikkel
>>>
> With /etc/udev/rules.d/70-persistent-net.rules, you are probably not
> going to run into it if you do not use HWADDR in ifcfg-eth? On the
> other hand, I do tend to use something like the first example I gave
> - you don't need to, but it can prevent surprises.
> 
There are valid arguments both ways, as long as you have only one NIC. After 
that you really want to have them called by the same names.  ;-)

-- 
Bill Davidsen <[email-masked]>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Subject: Re: Unrecognized Hard Drive
From: "jdow" <[email-masked]>
To: "Community assistance, encouragement, and advice for using Fedora." <[email-masked]>
Date: Thu, 1 Jan 2009 16:44:04 -0800

From: "Jorge Luis" <[email-masked]>
Sent: Thursday, 2009, January 01 13:06

> jdow:
>> OK, let's break the problem down into smaller pieces. Do you have a known
>> good drive you can test on that adapter? Does it work?
>
> I have four drives that I'm using with the converter, including another 
> 200
> GiB Maxtor; all of them are EIDE.  Only one of the drives exhibits this
> behavior; the others are fine.  All drives are ext3.

At this point one might suggest the drive is toast. Plugging the interface
onto the drive upside down can do that.

>> When you say you've tried with an EIDE cable how do you know the drive 
>> was
>> not found? Did you look at dmesg after booting?
>
> Here is the dmesg output when the faulty drive is unplugged from a USB 2.0
> input and then plugged into the running box again.
>
> [81041.572000] usb 4-6: USB disconnect, address 16
> [81056.170272] usb 4-6: new high speed USB device using ehci_hcd and 
> address 17
> [81056.303917] usb 4-6: configuration #1 chosen from 1 choice
> [81056.348793] scsi11 : SCSI emulation for USB Mass Storage devices
> [81056.358481] usb-storage: device found at 17
> [81056.358490] usb-storage: waiting for device to settle before scanning
>
> The output from the operation stops there; no other messages are emitted.

It sounds like the drive is not spinning up or has not spun up. Holding
it in your hand when you apply power to it can inform you somewhat about
what is happening. If it gives a solid "clunk" then sits idle the head
could not load and went back to idle. A damaged track might happen from
pulling power while writing to the drive.

>> I guess an obvious question is, "How did you abort the gpartd operation?"
>> Pulling power while a drive is writing is "not a good thing."
>
> If I wrote that an aborted gparted was a likely suspect, I misspoke.  I 
> meant
> to say that I bailed out of a GRUB configuration.  It was some time ago 
> that
> this possibly unrelated event occured.  It is true that neither gparted,
> nor parted, nor fdisk can find the drive now while scanning devices.

Yes, you did say GRUB. My antiquated chunk of gray goo I call a brain
twisted that up into gparted.

Did you exit the configuration or did you bail out by pulling power?

>> And a sense of your urgency to recover the drive might help. Is it a new
>> one you'd hate to lose but all you'd lose is the drive or did it have a
>> lot of precious data on it that you have to figure out how to recover, 
>> now.
>> (If it is the latter you are going to have to do some serious learning 
>> and
>> have the patience of Job.)
>
> We swap out three backup drives.  One drive is always off the premises. 
> An
> attempt to introduce the wonky drive back into the rotation gave me the 
> first
> intimation of trouble.  The drive contains no sensitive or irrecoverable
> information in its current state; I'd actually like to wipe it.  I'm not 
> about
> to go at it with Knoppix STD or some other forensic suite.

Ah - well, you might learn more if you can actually mount it to a
computer's IDE drive controller and see what happens. But the drive sounds
like toast. If it's "too new for that to happen" remember that new drives
have infantile failures. It's after the first few months of operation that
drives are usually quite stable until well into old age.

>> In terms of dmesg, set the drive to cable select. Plug it in to the drive
>> cable as master (the end connector.) Plug the cable in to either of the
>> IDE connectors, such as is free. Boot the machine. Interrupt the boot in
>> the BIOS. Usually the first page contains a list of drives. Play with it
>> to look for the drive. (Usually it's set to auto for all four possible
>> IDE/PATA drives.) If you plugged into the secondary IDE connector check
>> down, hold the drive in your hand, power up. You should FEEL the drive
>> spin up.)
>
> No matter how the drive is jumpered--cable-select, primary, or slave (in 
> the
> last instance, with the drive taking the secondary place on the primary 
> EIDE
> ribbon)--the introduction of the drive locks up the computer. The machine
> halts just after the memory POST; from there, there's no way to get to the
> BIOS screens.  It detects a legacy setting for USB storage and recognizes 
> my
> precious IBM Model M as a legacy device and then stops cold.  It's 
> impossible
> to tell whether the BIOS recognizes the drive.  There's no way into the 
> BIOS
> screens, which are normally available after the POST by <F2>.  The boot 
> chain
> (at <F12>) is similarly unavailable.

I'd give up at this point. The drive is toast, sadly. How it got that way
is a matter for conjecture. Hanging the BIOS POST is a little far out,
though. You have an interesting case of failure there.

>> If the BIOS finds the drive then exit the BIOS setup and proceed to the
>> next step. Boot the machine. Then investigate /var/log/dmesg. Look 
>> through
>> it for references to drives being found. (If need be save a dmesg from
>> booting without the drive and one from booting with the drive and compare
>> them. The drive should stick out in a diff like a sore thumb.) Note the
>> drive's device name, say it is sdc. THAT is what you use with partd
>> or fdisk. (fdisk -l /dev/sdc)
>
> The closest I can come to having the drive recognized by the system is 
> through
> the USB cage.  When I introduce the drive using the Coolmax converter, 
> dmesg
> records the messages that I quoted above, in which the drive is recognized 
> as
> a USB storage device.  However, no userspace program that I've tried sees 
> the
> drive, not gparted, not parted.

It sounds like the drive cannot get its head mounted and simply hangs
somehow. It's not useful for backups. If I had data on it there are some
"hacks" I might try, sharply twisting the drive on the axis of rotation
as power is applied, for example. Sometimes that will get the disk to
spin up if that's the problem. I've managed to rescue data that way a
couple times.

>> If you get that far post the results of the fdisk -l and folks here will
>> probably try to help you.
>
> fdisk is similarly uninformative:

I would expect it to be uninformative. The dmesg output indicates no drive
letters could be applied to it.

{^_^} 

--
fedora-list mailing list
[email-masked]
https://www.redhat.com/mailman/listinfo/fedora-list