Harddrives renaming themselves?

[lucky9]

I bought a Standby UPS that used USB to communicate with the PC. When I installed it I plugged in the USB plug and my PC turned itself off.
Long story short is that I had no working BIOS.
The PC was an old Gateway bought new in 1996-97.
I had to get the original BIOS to get the machine up as no later BIOS would boot.
After the first (original) BIOS was installed I could install the next BIOS update that had been released.
I installed 4 different BIOS to get to the latest one. I'm not absolutely sure that all of those were needed, but the first one (the original factory default), was definitely needed before anything else was going to happen.
Burning a new motherboard Firmware (BIOS) takes longer than most people would think. (It'll tell you when it's finished.)

I used to keep my Optical Drives firmware up to date as there are new burning protocols needed for newer media. Drives are so inexpensive that's not as important as it used to be.

[Paul..]

@ER, I've read through the whole trail of posts and it reminded me of a problem I had when I put in a new motherboard. I'm using and MSI motherboard, but I too had this problem of HDDs being renamed.

I finally concluded (after chasing down a bunch of posts on the MSI forum) that there was a conflict between two different chipsets - one was controlling both the IDE and a single SATA socket 7 (JMB363 supposedly to handle legacy devices) and another chipset (AMD SB850) controlling SATA sockets 1-6.

At first, I ditched my IDE DVD burner and bought a SATA DVD burner...and plugged the SATA DVD burner into SATA 7...but the problem still persisted and could only conclude that the two chipsets might be randomly fighting it out for control of assignment. I then upgraded the BIOS to see if they have fixed this potential conflict in firmware, but no dice.

Finally, I ended up plugging all devices (1 DVD burner, 4 HDDs) into SATA sockets 1-6 and the problem went away. Now, I have no devices being controlled by the JMB363 chip...and all drives controlled via the AMD SB850. An update to the MSI motherboard documentation indicated later that any SATA CD/DVD drives should be plugged into SATA 5 and set to IDE in the BIOS, but I had already found that out via trial and error on my own.

Moving to all SATA drives may be a radical approach that you're not willing to take, but it solved my problem.

[Eadwine Rose]

I will let that friend read all that, he will know what it all is heh.

Edit: got it, he explained.

Leaving things as is with the different boot order and F8. If that sorts it I am not going to spend money I can use better on a new burner when this old one is still working

[Paul..]

Absolutely! If the F8 boot order thingy works, stick with it.

[Gaer Boy]

Eadwine - In my simple mind, I see the problem of the two controllers as being one of timing. None of the motherboards I have used with two controllers have had a setting in the BIOS to define the sequence in which they are seen. The BIOS has only had a setting to determine which is looked at first to find a boot record. With parallel processing in modern machines, I think device identification can be influenced by which process completes first - SATA or IDE. Your solution of having a DVD in the drive and my suggestion of changing the boot order may slow the IDE recognition process so that the SATA device always wins. I'm quite likely wrong, or only partially right, and the problem may not go away.

What I do know is that with one controller the result is predictable - SATA devices are recognised in the order of port number and IDE devices are recognised by Primary/Secondary Master/Slave. I dropped PATA 6 years ago to get rid of similar problems, but I've used f8 or its equivalent to simplify other booting problems for many years.

BTW, my SATA DVD writer was about £12 - that's less than a couple of litres of beer in Amsterdam!

[Eadwine Rose]

Letting my friend reading the big bit hahaha.


But mind.. what most people seem to forget when they say "oh it is only...": if you are on a low income like I am 12 pounds is a lot. Especially to replace something that is working!

[qtech]

If this issue is only occurring with MX, then it is not a hardware issue. A flaw in the BIOS firmware at worst, maybe. Is AHCI enabled in the BIOS?

[BitJam]

If this issue is only occurring with MX, then it is not a hardware issue. A flaw in the BIOS firmware at worst, maybe.

I think the new kernel in MX is being very aggressive about scanning for block devices as fast as possible. It seems possible to me that this is triggering a problem with a misconfiguration of the jumpers that had not been seen before. The differences in the kernel configurations seem to be very minor and not at all related to this issue. Other people have had problems with the new kernel that I believe are related to ER's problem. For example the device naming order in /dev/ is now less consistent and usb devices can appear before non-usb devices. I believe this too is due to more aggressive scanning in the latest kernel. Specifically, I think the kernel is no longer waiting for devices in order to dole out names in a specific order. If you want to name all the internal devices before you name the usb devices then you have to wait until you have seen all the internal devices before you start handing out names for the usb devices.

At first (after seeing the dmesg output) I thought this had to be a bug in the kernel because the cdrom drive was being classified as a hard drive by the kernel, which is something I've never seen before. But if the scanning is more aggressive and the jumpers are misconfigured then it seems possible (perhaps likely) that both the hard drive and the cdrom are responding when the kernel thinks it is talking to just one device. ISTM this would explain all the symptoms without the need for there to be some horrible bug in the kernel.

AFAIK, AHCI only applies to SATA, but this problem is on the PATA (IDE) bus so I don't think it is related. I'm not trying to shoot you down. I thought your comment was insightful and I wanted to bring you up to speed on what I thought was going on and why I think it is probably a hardware problem even though it is only happening with the most recent version(s) of MX. A lot of this is conjecture but new information has come in (other people with device naming issues with the latest MX) that seems to corroborate this theory.

[qtech]

...
AFAIK, AHCI only applies to SATA, but this problem is on the PATA (IDE) bus so I don't think it is related. I'm not trying to shoot you down. I thought your comment was insightful and I wanted to bring you up to speed on what I thought was going on and why I think it is probably a hardware problem even though it is only happening with the most recent version(s) of MX. A lot of this is conjecture but new information has come in (other people with device naming issues with the latest MX) that seems to corroborate this theory.

I appreciate the info but I have been casually following the thread for awhile. I asked about AHCI because if it is disabled then the SATA controllers will operate in "IDE emulation" mode which might play a roll in drive detection / ordering. However, I now note from her lsmod that she is running in AHCI mode. I am doubtful that this is a master/slave jumper issue here as she almost certainly would have encountered problems before now.

Would it be possible that there is some sort of leftover mount point (like for a loopback with an .iso) created by MX while running live that ended up on the hd installation? The fact that she can leave a disk in the drive and boot normally seems to me to be a clue (and bizarre).

I am also wondering if Eadwine's hotplug drive has any bearing on this situation.

Finally, having never seen nor heard of a DVD-RAM reporting as an HD, I asked Dr. Google. I am only able to find one mention of such but do not believe it is pertinent to this situation (though admittedly, I may have asked the question incorrectly). It has been my experience (10 years of fixing Win boxes professionally) with hardware issues, however, that if one person has a problem there will certainly be others. The lack of such evidence here suggests to me that we may be looking at a symptom rather than the culprit.

I think we should ask Warren.

[Eadwine Rose]

With the fast speed and the /dev/ naming issues, I would say this is a problem with mounting partitions of a drive on boot. I always automounted the Lacie Downloads partition and the Backups partition, but I don't know what will happen if things start renaming themselves.