Harddrives renaming themselves?

[Eadwine Rose]

Is there anyone interested in what my /etc/fstab looks like? I mean.. I haven't looked back when it was the new installation still. Lemme post it, and see what it becomes if it does the naming trick again.


Honestly all this UUthingies is going over my head. This is the whole reason why I say: I will always be a noob. This pata and sata and stuff have been explained to me many times over, and I understood PERFECTLY at the time what it meant, but if the info is not used on a daily basis it oozes out of my brain and onto the pavement, annoying but a factual thing I have to deal with daily.

Thank god it isn't as bad as that guy in that movie that got up every morning and had to relearn everything!


Rich: the monkey's butt isn't a Dutch saying, but just something I rolled out of my sleeve right there. I do that all the time. Trust me.. that my elderly clients haven't died laughing yet amazes me greatly



Oh yeah.. fstab thingie:

Code: Select all

# Pluggable devices are handled by uDev, they are not in fstab
UUID=db1aed9a-aa14-4458-a611-ddf5d06a7aa6 / auto defaults,noatime 1 1
UUID=399beb91-0a62-43e1-bd92-496305879ac6 swap swap sw,pri=1 0 0
proc /proc proc defaults 0 0
devpts /dev/pts devpts mode=0622 0 0
UUID=375a7b9d-8ef3-4d99-b0a8-7b8b28fd3d74 /home auto defaults,noatime 1 2

This is in the normally named system.

[anticapitalista]

Eadwine - great, could you also post the output of (as root)

blkid

[Eadwine Rose]

Still on the normally named system:

Code: Select all

root@eadwinemx14beta2:/home/eadwine# blkid
/dev/sdb1: LABEL="Backups" UUID="2EAD013249FC871A" TYPE="ntfs" 
/dev/sdb2: LABEL="Clonezilla" UUID="25D6697F1D688C58" TYPE="ntfs" 
/dev/sdb3: LABEL="Downloads" UUID="2F5789B27BF514F2" TYPE="ntfs" 
/dev/sdc1: LABEL="CANON_DC" UUID="5824-2D93" TYPE="vfat" 
/dev/sda1: UUID="db1aed9a-aa14-4458-a611-ddf5d06a7aa6" TYPE="ext4" 
/dev/sda2: UUID="375a7b9d-8ef3-4d99-b0a8-7b8b28fd3d74" TYPE="ext4" 
/dev/sda3: UUID="399beb91-0a62-43e1-bd92-496305879ac6" TYPE="swap" 
/dev/sda4: LABEL="data" UUID="7b9b35d6-a939-4b49-ac62-fade7b83e0b7" SEC_TYPE="ext2" TYPE="ext3" 
root@eadwinemx14beta2:/home/eadwine# 

I read that wrong and was wondering what you needed that blind kid for...


Oh.. I got a canon sd card in there, just took a pic (that drive is now sdc).

[anticapitalista]

When you get the 'not-proper boot' post the fstab and blkid outputs so we can see what has changed.

[anticapitalista]

What is /dev/sdc1: LABEL="CANON_DC" UUID="5824-2D93" TYPE="vfat" ? A camera for skype?

[Eadwine Rose]

That is my canon's sd card. Goes in my digital camera Nothing to do with the system, just gets inserted when I want to get the pictures off the card to post online.

[BitJam]

Is there any correlation between having the card inserted at boot-time and the way the block devices get named?

Anything that affects the timing of how quickly buses come on-line can affect the name order. It is now first come, first served. OTOH, I don't know how this would account for a device switching between sda and sr0.

Edit:
According to the log file you have 2 dvd drives: PLEXTOR DVDR PX-820A and SONY DVD-ROM DDU1612. Normally they should show up as sr0 and sr1 (not necessarily in that order). The log file says that when you get the incorrect naming then one of the dvd drives is attached to sr0. The other gets attached to sda. Then there are several errors that are probably due to it not acting like a hard drive. Then your internal Western Digital hard drive gets attached to sdb. Finally your usb Hitachi hard drive gets attached to sdc. If you only have one dvd drive then the problem could be related to the kernel thinking you have two.

I am a little surprised that the dvd drive that is attached to sda is working because according to the log file the kernel seems to be treating it like a hard drive.

Here are a few more diagnostics that can be run when the incorrect names appear. Some of it may be redundant. The lsblk command will probably be the most useful:

Code: Select all

lsblk -do NAME,KNAME,TYPE,MODEL,RM,RO,GROUP
cat /proc/partitions
cat /proc/sys/dev/cdrom/info  
ls -l /dev/{cdrom*,dvd*,sd?,sg?,sr?} 2>/dev/null
sudo  lshw -C disk

You can run them all at once with a copy and paste into a terminal window. These will help us see if the /dev/sda device is set up as a cdrom/dvd drive. For example, here it the output of the blkid command above for one my cdrom devices:

Code: Select all

NAME  KNAME TYPE MODEL            RM RO GROUP
sr0   sr0   rom  BR-04B2T          1  0 cdrom

The name and the kname (kernel name) match. The type is "rom", it is removable (RM=1), and the device node is in the cdrom group.

A couple of more ideas. Look for rules files in /etc/udev/rules.d/, there could be something fishy with 70-persistent-cd.rules if it exists. Maybe some other rules file is triggering the problem. Also, if we are unable to track down and fix the source of this problem we may be able to write a udev rule to work around it. For example, we should be able to make rules that always attach your Sony dvd drive to sr0 and your Plextor to sr1. However, if the kernel and udev think the Plextor is a hard drive then just changing the device name might not fix it.

[JBoman]

At one point long ago there were issues with booting if the ide drives were jumpered as a master instead of cable select and I'm not sure if that was around the time that UUID came into being or not. I seem to remember then that if you had sata and ide drives mixed they needed to be jumpered cable select or problems similar to what you are having could occur. Might be worth checking.

[Eadwine Rose]

I doubt there is a relationship with the sd card being attached. Only this one last time was that card in there, and I have had multiple reboots today due to that mouse theme issue and had it happen a few times.

I know I am not going to be windowsy and reboot 15 times in a row with the sd card in there just for kicks



It seems really strange that this problem with the hardware that I have set up like this does NOT occur with mepis12, making me believe that the master/slave/cable select issue cannot be the cause or it would have come out a long time ago. Or is mepis12 set up differently from mx14 that this whole dealie won't happen there?


As far as I know sr0 has always been my Plextor drive, and when the card gets inserted it's been sdc. Just inserted it again for kicks and yep, sdc.

Also when this occurs I WILL put in a dvdrw in the Plextor drive and see what it says, to determine for certain that it is indeed working still, considering that I never paid this close attention to the issue (I didn't KNOW there was an issue after all).

What I CAN do is attach a .txt file with all those commands, as a baseline, as I have a proper boot right now. All drives get seen, all looks normal, so this would be a good opportunity to give all the commands in the terminal and store them for posterity. I will insert that canon camera card as well.

sda = the actual harddrive (internal) with the mx14 system on it
sdb = the usb harddrive (lacie, the one with partitions backups, downloads, etc, is turned on before the computer gets turned on)
sdc = canon sd card in a usb multicard reader (when attached)
sr0 = plextor dvdwriter
sr1 = sony dvdreader
I definitely do not have a floppy drive in this system *giggles*

baseline.txt

70-persistent-cd.rules.txt

I hope this will help.


We can thank conky because without that I wouldn't likely even have noticed something was up. I saw it because the hddtemp output was set to N/A.

[BitJam]

It all looks good. I look forward to seeing the outputs when the names go wrong. One small thing. For some reason udev is linking /dev/cdrom and dev/dvd to your /dev/sr1 and linking /dev/cdrom1 and /dev/dvd1 to your /dev/sr0. This seems backwards to me. It is counter-intuitive but it does not cause breakage.

I wasn't suggesting you reboot a bunch of times with the sdcard in, I was just asking if you could recall a correlation. If you stumble on something that always triggers the name problem then that could go a long way to helping us figure out what is going wrong.