MX Linux Forum

Posted: **Tue Feb 11, 2014 5:29 am**

Well.. this is weird.

I was fiddling with conky a bit where the temp for the harddrive had gone to 0, and then saw in the systray that the temp for my harddrive (installed this to /dev/sda) was also set to 0C

So.. I enter in the terminal: hddtemp /dev/sda
How big my amazement when I read this: /dev/sda: PLEXTOR DVDR PX-820A : S.M.A.R.T. not available

What??

So.. open up gparted and sure enough.. sda is now sdb, and what used to be sdb is now sdc.

How on earth could this happen?

I upgraded all things upgradable on the 10th of Feb (including the wheezy base files and such), couldn't upgrade vlc so asked and told to do dist-upgrade which fixed that.

Outside of those two things I haven't done anything to the system that I know of. I figured I'd report this issue cause it doesn't look like something it should do.

I can reinstall this system, no biggie at all.. I just wonder, what the heck happened to cause it and how to prevent this sort of thing in the future?

Posted: **Tue Feb 11, 2014 10:14 am**

To add: I just rebooted and the namings are back to what they should be.

Posted: **Tue Feb 11, 2014 3:30 pm**

No external drives? Even a USB FlashDrive?

Posted: **Tue Feb 11, 2014 3:46 pm**

Nope. Nothing of the sort.

It is settled again, the reboot sorted it. I just wonder what the cause was. I doubt we will be able to find out though.

Posted: **Tue Feb 11, 2014 3:55 pm**

You're famous for having crooked volts.

Posted: **Tue Feb 11, 2014 3:58 pm**

True! Hahaha.

Just had another one, see community fun lol

Posted: **Mon Feb 17, 2014 12:41 pm**

Happened again, just now and earlier. After a reboot the harddrives have renamed themselves again and sda is now gone. sdb is now the internal harddrive, sdc is again the external usb harddrive.

How can we go about diagnosing this one.. or .. if it is just me I don't mind cause I know what to do (reboot again haha).

I am currently in the "faulty harddrive" boot.. syslog says this:

syslog.txt

Posted: **Mon Feb 17, 2014 2:21 pm**

@ER, it would be much easier for everyone if you uploaded the log file instead of putting it into the body of your posts. I *think* you just need to a ".txt" to the end of the filename to make it uploadable.

Posted: **Mon Feb 17, 2014 2:25 pm**

Ah yeah.. didn't think of that. Brain is a bit fried today haha.

Will do that and edit the post above. Thanks

Posted: **Mon Feb 17, 2014 2:27 pm**

Eadwine Rose, How many drives both internal and external do you have installed and how many usb devices and are any of them hard drives?. Might help to post your partitioning tables too and which drives have OS's installed to them. I cannot help but looks like that info will be helpful for troubleshooting.

Posted: **Mon Feb 17, 2014 2:36 pm**

I have a swappable harddrive slot in my computer in which the internal harddrive resides (sda 1-4). That one holds the sytem. The drive is a regular internal harddrive, the only special thing is that I can remove it when the system is turned off and put another drive (like a Windows drive) in it.

sda4 is a partition that does nada, it is just there because I needed both this drive and the to be cloned to drive to be the exact same sizes.

There is one harddrive externally (sdb 1-3, usb Lacie drive) which is only used for backupping and such between both the linux drive when that is in the slot, or the windows drive when that is in. There is no boot system on that, just partitions for various backup types.

I have had this system like this for 3 or 4 years now, never been a prob on Mepis.

Note this is on a proper boot:

Code: Select all

root@eadwinemx14beta2:/home/eadwine# fdisk -l

Disk /dev/sda: 500 GB, 500105249280 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System 
/dev/sda1               1        6375    51207156   83  Linux
/dev/sda2            6376       57368   409593240   83  Linux
/dev/sda3           57369       57623     2040255   82  Linux swap
/dev/sda4           57624       60801    25519252   83  Linux

Disk /dev/sdb: 500 GB, 500105249280 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System 
/dev/sdb1               1       19123   153605466    7  HPFS/NTFS
/dev/sdb2           19124       31872   102398310    7  HPFS/NTFS
/dev/sdb3           31873       60801   232364160    7  HPFS/NTFS

Posted: **Mon Feb 17, 2014 2:42 pm**

Well that all looks kosher... dunno... have you looked at your fstab for any clues?. Looks like you might need Tim,Kent,or Stevo on this one.

Posted: **Mon Feb 17, 2014 2:58 pm**

I have rebooted after I made the call that it got sda lost again

This is what it SHOULD be and in its normal state now (added that with it, I AM a fried brain today, geez..) .

I will of course repost both the above and fstab content when the weird thing happens again.

The log file earlier on in the thread is a "bad" boot.

Posted: **Mon Feb 17, 2014 3:04 pm**

As for the actual problem. I think you may have described it incorrectly. It is expected that devices names like /dev/sda and /dev/sdb will NOT always be consistent between reboots. When you said the devices were *renaming* themselves, I thought you meant that the device names were changing while the machine was running which sounded very strange indeed, with the most probable cause being flaky hardware.

If you don't believe me, please Google(consistent block device names). You will find many pages like this one from Archlinux:

Persistent block device naming

This article describes how to use persistent names for your block devices. This has been made possible by the introduction of udev and has some advantages over bus-based naming. If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary. This may result in device names like /dev/sda and /dev/sdb switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.

As long as your "root= boot" parameter is of the form "root=UUID=xxx" (which the log file shows that it is) and your /etc/fstab uses "UUID=" and/or "LABEL=" to identify devices then everything is fine and working as expected.

Although one that thing does look a little suspicious to me is your dvd drive is sometimes showing up as /dev/sda:

dev/sda: PLEXTOR DVDR PX-820A

For a while now, I have always had such devices show up as /dev/sr*. Maybe this change is due to the new kernel or a newer udev or something. I'm not sure if it is indicative of a problem or just my lack of knowledge.

PS: Please don't shoot the messenger. I didn't design this new way of doing things, I'm just reporting what it is.

Posted: **Mon Feb 17, 2014 3:14 pm**

Sorry about the terminology, little do I know about what is considered renaming and what is not. I call it as the noob that I am with this

That sr0 thing is indeed my plextor drive, which becomese sda when the issue happens.

Never once before in all the years that I have been using mepis have I seen this (started on 2005 pro beta 3 IIRC). And this system as it stands today hardware wise has been running since 2010 or so. The only thing changed since then was the video card that was added months ago.

Ok.. lemme see if I remember THIS correctly, maybe it gives a clue:
there is one old type (is that called IDE?) slot on my motherboard, the rest are more modern (SATA?). The dvd drive (the plextor) is on that particular old type slot because its connector is of the "old" kind and I didn't want to ditch a perfectly fine burner back when the hardware was changed around.

I built this system myself with the help of a good friend who is more in the know about these particular hardware namings

But yeah.. nothing new whatsoever was done, the only thing that changed was mepis12b2 --> mx14b2

Posted: **Mon Feb 17, 2014 3:59 pm**

Yes. It used to be different. Things have changed in the more recent kernels (and udev) and the /dev/sda device names are no longer consistent. In order to not cause widespread breakage they had to delay this change until everyone was using UUIDs in the root= boot-parameter and in fstab. You don't have to like it but you do have to live with it**. As long as your dvd drive still works when it is named /dev/sda then there is nothing to be fixed. IOW, inconsistent /dev/sda names is not a but but giving a dvd drive the name /dev/sda might be. Another example of a similar change is that IDE (PATA) hard drives used to show up as /dev/hd*. Now they show up as /dev/sd*.

If you are unhappy with this change, just wait until you see what they are doing to eth0.

** Some people have rebelled against udev and have been using alternatives such as mdev from busybox. I don't know if using mdev will bring back the consistency you want or not (because I don't know if the inconsistency is coming from udev or from the kernel). Our LiveCD/USB uses mdev initially so you can test this yourself by booting the MX Live media on your machine with the boot parameter "bp=2". The boot will stop early at "breakpoint 2". Wait a few seconds for all the devices to be found and then look in /dev and see if you can figure out which devices go with which block device names. You can repeat this and see if the names stay consistent or not. Use the command "safe-reboot" to reboot and try again. Unfortunately, more and more packages are depending on udev so you may not have the option to easily run a Debian system without udev. Slashbeast provides what is needed to run a Gentoo system with mdev instead of udev.

Posted: **Mon Feb 17, 2014 4:42 pm**

Ah yeah, I remember that hda stage still, back on the old mobo.
Personally, I don't care if they call it a monkey's butt, as long as it works

And it all does for as far as I can tell.

It just worries me when the dvddrive is called sda. I start thinking: can that harm the system in any way considering the install was done TO sda and the grub and all as well and it is now suddenly called sdb? I mean mostly when.. say.. upgrading, installing new stuff.. will it make a difference, or will it automagically sort itself out? That is basically what I want to know.

The rest is.. well.. monkey's butt to me hehehe

Posted: **Mon Feb 17, 2014 4:59 pm**

Monkey's butt.

Is that a Dutch saying.

Posted: **Mon Feb 17, 2014 5:08 pm**

Eadwine Rose wrote:It just worries me when the dvddrive is called sda. I start thinking: can that harm the system in any way considering the install was done TO sda and the grub and all as well and it is now suddenly called sdb? I mean mostly when.. say.. upgrading, installing new stuff.. will it make a difference, or will it automagically sort itself out? That is basically what I want to know.

What I've been saying is that as long as the UUID is used in the root= boot parameter and in your fstab then it all sorts itself out. That is why we had to switch from simple device names to the cumbersome UUIDs. The only thing I am not sure about is your dvd drive showing up as /dev/sda. I don't know if that is a bug are just another step into this brave new world.

Posted: **Mon Feb 17, 2014 5:11 pm**

Just to throw a(nother) spanner in the works - Eadwine. Beta 3 testing should only have swap as an entry when running live and only the root /, swap and /home (if separate from root) on installation.

Posted: **Mon Feb 17, 2014 5:18 pm**

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.

Posted: **Mon Feb 17, 2014 5:23 pm**

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

blkid

Posted: **Mon Feb 17, 2014 5:29 pm**

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).

Posted: **Mon Feb 17, 2014 5:33 pm**

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

Posted: **Mon Feb 17, 2014 5:36 pm**

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

Posted: **Mon Feb 17, 2014 5:55 pm**

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.

Posted: **Mon Feb 17, 2014 7:05 pm**

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.

Posted: **Mon Feb 17, 2014 8:57 pm**

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.

Posted: **Mon Feb 17, 2014 11:15 pm**

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.

Posted: **Tue Feb 18, 2014 2:07 am**

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.

Posted: **Tue Feb 18, 2014 4:26 am**

Guess what.. hehe, here we are:

/etc/fstab

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

wrongboot.txt

wrong70-persistent-cd.rules.txt

Now going to insert a dvd with data in the plextor... aha nope it doesn't get seen:

Code: Select all

root@eadwinemx14beta2:/home/eadwine# cat /proc/sys/dev/cdrom/info
CD-ROM information, Id: cdrom.c 3.20 2003/12/17

drive name:		sr0
drive speed:		40
drive # of slots:	1
Can close tray:		1
Can open tray:		1
Can lock tray:		1
Can change speed:	1
Can select disk:	0
Can read multisession:	1
Can read MCN:		1
Reports media changed:	1
Can play audio:		1
Can write CD-R:		0
Can write CD-RW:	0
Can read DVD:		1
Can write DVD-R:	0
Can write DVD-RAM:	0
Can read MRW:		1
Can write MRW:		1
Can write RAM:		1

Sees only the reader, the Sony, I cannot access the dvd in the drive. Open and close and that is it for the plextor.

Inserting the sd card and as expected that becomes sdd now

wrongbootwithsd.txt

Hope this all helps!

Posted: **Tue Feb 18, 2014 6:08 am**

I have an idea.. no clue if it works of course.

I am going to leave the dvd with data on it in the Plextor drive. I did that earlier when I rebooted from this wrong one back into a correct boot, who knows maybe upon booting the system will see the dvd and notice it is something not resembling a harddrive *shrug*

Worth a test in any case, and it won't interfere with other things that I am doing

Posted: **Tue Feb 18, 2014 6:54 am**

I hope this will help.

It helps in the sense that it confirms it is quite broken and won't be fixable by writing a udev rule. I'm glad I asked for the redundant information because sda does not even show up in the lsblk output.

One thing I noticed is that the scsi adapter numbers move around between the working and the broken boots:

Code: Select all

Device    Good        Bad
------    ----        ---
Plextor   4:0.0.0     0:0.0.0
Sony      4:0.1.0     0:0.1.0
WD        0:0.0.0     2:0.0.0
LaCie     6:0.0.0     6:0.0.0

The first number is the adapter number which the kernel assigns to adapter card. Then it is channel number, id number, and lun number. The udev rules file seems to assume that these number do not change between boots. In fact your 70-persistent-cd.rules file seems to have been configured in what I list as the bad configuration above. So that file may not be doing anything useful because the symlinks are being created even when the rules don't match.

I don't know if the change in adapter number is related to the problem or not. If you want to find out if they are related then you can run "sudo lshw -C disk" after good boots and bad. The four numbers are listed in the "bus info" field. The LaCie enclosure with the Hitachi drive inside does not have a "product" field but you can deduce which one it is from the logical name and the size. But even if you were to gather this information, I don't know what to do with it.

I am almost out of ideas. I like your idea if leaving a dvd in the drive. My final idea would be to compare the output of "lsmod" when the names are correct and when they are not. Maybe a different module is getting loaded or used and that is causing the problem. I don't think this is very likely but if it is associated with the problem then the solution could be simple by either forcing a module to load or by blacklisting it.

Posted: **Tue Feb 18, 2014 7:19 am**

The sda4 did show up in Thunar I believe, just couldn't do anything with it. I will cross check next time as I am now in a correct boot again.

Here are two correct boot files of sudo lshw -C disk and lsmod

lsmod.txt

lshw.txt

sdc is present as the canon card is inserted because I took some pics again.

I will do the same commands and list what I get upon a wrong boot.

Mind just for those wondering what the heck I do with all the inserting of that camera card

I modify puzzles for a hobby amongst other things and share the pictures of the progress with fellow puzzlers

Here is a picture of something currently in progress

megaball2.jpg

Anyways, that is that. I'll get back to you when I obtain more info on a wrong boot

Any other commands that I can do in this proper boot and the wrong boot for you guys to compare?

Posted: **Tue Feb 18, 2014 8:07 am**

The unrecognized sr0 makes me wonder if the problem I just had recently is related... see here..> http://www.forum.mepiscommunity.org/vie ... 85&t=35587

Posted: **Tue Feb 18, 2014 9:01 am**

BitJam wrote:...If you are unhappy with this change, just wait until you see what they are doing to eth0. ...

Offtopic: What are they doing to eth0?

Posted: **Tue Feb 18, 2014 12:37 pm**

I admit that I'm hanging also.

Posted: **Tue Feb 18, 2014 2:17 pm**

It's called Consistent Network Device Naming. There are a number fiery of threads about this over on the Gentoo forums. I think what rankled many people was the fact that this is enabled by default even though the vast majority of people have just one network card and therefore have no need for eth0 to be renamed. Other people were upset because the so-called consistent names would change after reboot or even while running. Changes like this in udev have caused a lot of system breakage over the past few years. This one could hose a system you trying to administer remotely. There was a breakout of people thinking other people are stupid which can be highly contagious. One result is that enthusiasm for systemd has been greatly dampened in some quarters. If you want to talk more about this, we should start a new thread.

Posted: **Thu Feb 20, 2014 12:20 pm**

BitJam wrote:It's called Consistent Network Device Naming. There are a number fiery of threads about this over on the Gentoo forums. I think what rankled many people was the fact that this is enabled by default even though the vast majority of people have just one network card and therefore have no need for eth0 to be renamed. Other people were upset because the so-called consistent names would change after reboot or even while running. Changes like this in udev have caused a lot of system breakage over the past few years. This one could hose a system you trying to administer remotely. There was a breakout of people thinking other people are stupid which can be highly contagious. One result is that enthusiasm for systemd has been greatly dampened in some quarters. If you want to talk more about this, we should start a new thread.

Thought that was Fedora specific... is it not?

Posted: **Fri Feb 21, 2014 6:42 pm**

Just letting you guys know I am still keeping an eye on this. Leaving the dvd disk in the drive still.

I haven't done that many reboots lately, but there has been no occurrence either. You'll see now that I have posted this that tomorrow morning when I boot the system the wrong boot happens

Posted: **Fri Feb 21, 2014 6:47 pm**

Good plan. No sneaking up on it. Just dare it to mess up. (Usually works for me also.)

Posted: **Thu Feb 27, 2014 11:44 am**

I guess it has worked keeping the dvd in the drive, I haven't seen it happen since I started doing that. Something to do I wager with the system seeing that the Plextor burner is not a harddrive. How to get that to happen without a disk in the drive, not a clue though *shrug* At least this works.

(I STILL keep eyeing the thing though haha)

Posted: **Thu Feb 27, 2014 4:04 pm**

We should probably report this upstream either to Debian or directly to the Linux Kernel Mailing List:

I think I found a bug, how do I report it?
http://www.tux.org/lkml/#s4-4

BTW: BBCode seems to be turned off even though the box on the bottom left of the page says "BBCode is on". Both "url" and "b" tags failed to work.

Posted: **Thu Feb 27, 2014 4:06 pm**

You must have been a bad boy, b/c both work for me

Posted: **Thu Feb 27, 2014 4:16 pm**

But how did it know?

Maybe it was pilot error and I confused the textarea box with the preview.

Posted: **Thu Feb 27, 2014 4:21 pm**

As I have NO idea how to go about it, please feel free to use the info given to report

I really hope this is indeed the solution, but it's been almost a week now with a number of reboots, I think 10-15 in total at least since I said I would try the disk in Plextor idea.

Posted: **Thu Feb 27, 2014 4:42 pm**

Eadwine Rose wrote:As I have NO idea how to go about it, please feel free to use the info given to report

That is why I provided a link to the instructions. I'm very busy ATM with programming stuff for MX and antiX. I'm down to about 4 hours of sleep per night. It would be great if you could at least take a stab at reporting this.

Posted: **Thu Feb 27, 2014 5:10 pm**

I have no idea how to describe this or where to start, sorry my brain freaks out at the whole lot of text presented there.

Also that is a kernel thing? Is it? I have no clue how to even get my kernel info right off the bat (I simply cannot remember such things), let alone what it does.

I feel like a total noobdouche when I should post there, people will get irritated with me because I -am- one (been there done that), and it will turn out that you guys will have to answer questions that I get asked and have to relay here because I have no clue what it all means.

I am not shoving this away or anything, I just feel and know I am blown out of the water there

Posted: **Thu Feb 27, 2014 5:29 pm**

Eadwine - let's look at this tomorrow. It can wait and then I can help.

Posted: **Thu Feb 27, 2014 8:39 pm**

maybe consider checking this> http://www.tomshardware.com/forum/28517 ... cdrom-sata ... and this> http://www.wdc.com/wdproducts/library/o ... 001037.pdf

Posted: **Fri Feb 28, 2014 3:05 am**

Upon boot I think it says master slave somewhere. I have no idea what things are set as right now

I will have a looksee on the next one.

Here is a screenshot:

There was one old connector on the motherboard that the Plextor (IIRC) was plugged into. and it was set as master for a reason, but that reason I'd have to ask that friend of mine, I cannot remember. What I do know is that M11 M12 and all the other Mepis releases since 2010 or so handled it fine.

screenshot.jpg

Phone with him.. It COULD be that it is set to cable select still. No idea yet.
He said there was no specific reason to set it to master, it may be set to slave, doesn't matter.

So what is the dealie with those links as I just have no idea what this all means? Set plextor to slave and that should sort this out?

Posted: **Fri Feb 28, 2014 12:16 pm**

Eadwine Rose wrote:I feel like a total noobdouche...

LOL!

I'm usin' that one.

Posted: **Fri Feb 28, 2014 12:18 pm**

[Have not forgotten about reporting this...just busy ATM]

Posted: **Fri Feb 28, 2014 1:24 pm**

It's ok Jerry

I might want to try that jumper thingie first. Tomorrow I will see if I can enslave my Plextor and maybe that will sort it already, who knows.

*cracks whip*

Posted: **Fri Feb 28, 2014 3:06 pm**

The Master/Slave setting is, or at least can be, extremely important. Depends on the Hardware and Software (Firmware on the optical drive) and the kernel that's being used (and the way it's built).

Cable Select (CS) is probably (mostly) the safest setting. However, even CS can cause problems. CS at one time was worse. You had to have the Master and Slave settings correct given what the BIOS was set at (given the particular setup and kernel).

Dive in there girl. We're all here to help.

Posted: **Fri Feb 28, 2014 3:14 pm**

Thanks for the support!!

I'll dive in tomorrow.. it is dark here now and I need to see something without having to add a light.

I will set that plextor to slave, which to me (without reading all the links) sounds like the most logical step to take; the harddrive is likely set as master, and there cannot be two captains on a ship so to speak

Posted: **Fri Feb 28, 2014 3:31 pm**

Starting with the 80-wire cable defined for use in ATAPI5/UDMA4, the master device goes at the end of the 18-inch (460 mm) cable—the black connector—and the slave device goes on the middle connector—the gray one—and the blue connector goes onto the motherboard. So, if there is only one (master) device on the cable, there is no cable stub to cause reflections. Also, cable select is now implemented in the slave device connector, usually simply by omitting the contact from the connector body.

This is under Cable Select here: http://en.wikipedia.org/wiki/Parallel_ATA
Those positions on the PATA Cable should be reflected in the drive jumper settings.

Make a note on how things are setup now so you can return to a working setup if needed.

Posted: **Fri Feb 28, 2014 3:56 pm**

I am only changing a jumper, not cables. If I start having to change cables I am calling in that friend of mine, because I am not comfortable around the hardware on my own. If someone is there who I can show and who knows what to do it's different

I DID build this system myself, but largely with his help

Posted: **Fri Feb 28, 2014 5:24 pm**

All that's needed is that the Jumpers ahould match the position on the Cable of Master and Slave. Shouldn't have to move anything except the Jumper/s. May not need to move either one. May have to move only one. It's possible that both will need to be moved, but unlikely. I'm betting that they are probably where they need to be already and you won't have to move anything. Sleep well.

Posted: **Fri Feb 28, 2014 5:51 pm**

If the simple move of that sole jumper ain't workin', I's callin' mah friend.

Posted: **Fri Feb 28, 2014 7:37 pm**

A brief how-to > http://www.youtube.com/watch?v=qdY2Jwd2rbQ
A more complex one... long and 2 parts > http://www.youtube.com/watch?v=wtC8RhYHAAI

Posted: **Fri Feb 28, 2014 10:51 pm**

lucky9 is right

"Post # 331955
Post Re: Harddrives renaming themselves?
The Master/Slave setting is, or at least can be, extremely important. Depends on the Hardware and Software (Firmware on the optical drive) and the kernel that's being used (and the way it's built).
Cable Select (CS) is probably (mostly) the safest setting. However, even CS can cause problems. CS at one time was worse. You had to have the Master and Slave settings correct given what the BIOS was set at (given the particular setup and kernel).
Dive in there girl. We're all here to help,"

I often heard that for the boot drive, usually sda1 you want that as a master , then the CDROM/DVDROM is slave. The slow device should not be a the master.
Therefore it is better if the motherboard has two pata connectors to have the sda1 as master in ide1 and the CDROM as master on ide2. Linux can be particular about correct drives, where Windows will usually work even wrongly wired and set. So the old wisdom was for linux, better to correctly use the master and slave. But, In all my experience cable select works correctly .

If you are going to move jumpers, you need to get the correct setting diagram. It is often on the drive, but when installed it may be hard to see. If you know the model of your drives you can find it with Google. To move them usually a light and tweezers or needle nose pliers are needed. Obviously move the jumpers when the system is powered off.

So much easier with SATA these days !

Posted: **Sat Mar 01, 2014 2:40 am**

This is all confusing me way too much with all the namings, sorry guys. Too much info coming at me at once.

I am back from diving in the system! Man did that case get heavier over the years?

One thing: "Obviously move the jumpers when the system is powered off."
I do know I am NOT so stupid to move jumpers with the power on. I have dealt with hardware before multiple times, not just my system but also that friends' as he has a sight problem. I know what to do and what not to do when I dive into a case. Sorry, but that remark did come across a little insulting; I may not remember things, that is an issue in itself, but I am not stupid.

In any case, I opened the case, and then another issue that I did not have back in Sept 2010 crept up on me again.. bleh: I cannot get the power and flat cable out of the drive anymore to remove it to get to the jumper, and I cannot get to the jumper nor the schematic without taking cables out, unfortunately. I'd rather take the drive out of the bay to check its jumper settings schematic as I have no idea what the exact type is anymore, and I am not doing the guessing game with these things.

So.. I have to wait for my friend to help me out with both the info posted before and he can draw his conclusions on it, and also because my hands are not cooperating anymore to be able to do this.

So.. in the mean time I have to leave the disk in the drive.

Ah well.. at least this way I can test THAT solution longer hehe.

Edit: Wednesday afternoon we are going to tackle this one

will try both slave and CS, slave first though. I will read him the posts above, so he knows what the issue is that you guys are talking about with the kernel and its preference and such and he can act accordingly with the cables and stuff. Wait and see

Posted: **Sat Mar 01, 2014 12:36 pm**

I have a large size case so, if necessary, I could pull out the drive while it was still connected to the motherboard and power connector. I forget how it is for smaller cases.
Tweezers make it much easier, especially if the Connectors are still in place. Small needle-nose pliers are easier to use. More leverage.
I print out the Jumper Settings from the manufacturer's website. (I have at least one HDD that doesn't have Jumper Settings printed on the case. I can't remember having an Optical Drive that had no Jumper Settings. (But I used to buy one every year, or every big increase in speed/functionality.)

Posted: **Sat Mar 01, 2014 12:44 pm**

Yeah.. not so with my case.. those cables are TOUGH to get through. And I don't print out the schematic because simply I don't NEED to change jumpers, never had the need to do so before this now

Anyway. I cannot get to it like this and unless someone has some new hands.. ah well.

Wednesday is the day that I can test stuff.

Posted: **Sat Mar 01, 2014 1:38 pm**

Eadwine - I have the same motherboard but my dvd drive is connected via SATA (in IDE mode). I have not had a problem with drive renaming, but I have had a few problems on booting and these seem always to be related to drive/dvd identification. I have tried various adjustments in the BIOS to no effect.

When it's next convenient, could you look in your BIOS setup and let me know the Asus BIOS version (mine is 1601). Also in Main>SATA Configuration for the settings (I have Ports 1-4 AHCI & Ports 5-6 IDE). Finally, your Boot Device Priority ( mine is CDROM, IDE: Corsair SSD, Removable Device).

I don't use the PATA port - by the time I built this machine I had heard of enough problems mixing PATA & SATA that I bought a new SATA DVDE writer.

Phil

Posted: **Sat Mar 01, 2014 1:53 pm**

This I can do

Gaer Boy wrote:When it's next convenient, could you look in your BIOS setup and let me know the Asus BIOS version (mine is 1601).

I find two version numbers, one in the bottom of the screen, says v02.61, and one in main-system info: version 2005

Also in Main>SATA Configuration for the settings (I have Ports 1-4 AHCI & Ports 5-6 IDE).

All IDE

Finally, your Boot Device Priority ( mine is CDROM, IDE: Corsair SSD, Removable Device).

1: cdrom: pm-plextor d
2: sata: 3M-WDC WD5000
3: Removable Dev.

I don't use the PATA port - by the time I built this machine I had heard of enough problems mixing PATA & SATA that I bought a new SATA DVDE writer.

The old burner cost me plenty, I wasn't going to buy a new one just yet.

Again I will say: this was never an issue, until now.

Posted: **Sat Mar 01, 2014 3:05 pm**

I think the 2.62 version is the base AMI BIOS version that Asus used. They tweak it for the motherboard and add their version number - top right of the BIOS screen. As far as I can see, they started with v1015 in 2010 and it was rapidly updated in 2010 to v1601 and then a few updates in 2011 & 2012. Typically, Asus are no more forthcoming that Microsoft when it comes to updates - except for a major one to correct RAID setups, most of the others say "Improve system stability".

Anyway, I wouldn't suggest a BIOS update - as far as I'm concerned, it's a last resort when something won't work. Your other settings seem OK. If you still get problems, you might try moving the cdrom down the Boot Priority list - if you need to boot from CD/DVD you can hit F8 early in the boot.

My occasional boot hangs sometimes produce split messages re disks on screen. The next time I get one, I'll transcribe the sequence - that could be weeks or months from now.

Posted: **Sat Mar 01, 2014 3:15 pm**

Anyway, I wouldn't suggest a BIOS update - as far as I'm concerned, it's a last resort when something won't work.

Indeed, it is not something I am even willing to do

It may open a whole other can of worms that cannot be closed, so not going there anyway hehe

Your other settings seem OK. If you still get problems, you might try moving the cdrom down the Boot Priority list - if you need to boot from CD/DVD you can hit F8 early in the boot.

F8? Oh? I didn't know about that one, thanks.

Could it help to move it down the list, set the WD as the first one, that way it won't even look at the plextor upon boot, might sort it too? *shrug* Just throwing something up

if I need to boot a livecd I can always change it back after all.

Posted: **Sat Mar 01, 2014 5:43 pm**

That's my thought. I don't know that it would have effect, but it can't hurt to try.

Posted: **Sun Mar 02, 2014 9:56 am**

To Eadwine Rose,

No insult intended. I am sorry to come off that way.

I wrote "Obviously...." to power off, so I think I realize that you and probably most on this list know this.

But as an engineer, I know sometimes a reminder for those obvious things prevents accidents.

Sorry, and best of luck to solve your boot issues. The old PATA days were certainly more complex.

-Jay

Posted: **Sun Mar 02, 2014 10:00 am**

You can boot a LiveCD/DVD from that F8 boot menu, no matter what boot order is in the BIOS.

As for updating the BIOS....those 'system stability' issues are usually extremely helpful. And I wouldn't use system stability to describe them. Manufacturer's do so because they don't want to admit to mistakes (in most cases anyway).

Posted: **Sun Mar 02, 2014 10:17 am**

Yeah I have set it like this now (hdd first) and will use the F8 option.

As far as bios: ten foot pole thing

Posted: **Sun Mar 02, 2014 10:26 am**

No problem. After some of the horror stories I've read I can understand some of the worry.

If you ever do have to update a BIOS do so when there's little possibility of the electricity going off. Or use a UPS. Print out instructions if using Linux/Unix. If you use Windows they usually have you covered with specialized software. The big thing is having the electricity stay on. (Plus letting things run until they are finished.)

But if it's not broke......

Posted: **Sun Mar 02, 2014 10:31 am**

I Have updated bios several times with success, but once, back in the old days, my floppy failed in the middle. The result was a motherboard that had to be replaced. So I understand the reluctance.

Posted: **Sun Mar 02, 2014 10:52 am**

F8 works like a peach, nice thing!

I had seen it before in the boot messages, but it wasn't clear to me what it did.

Power going off? Uhm.. last time that happened.. never in this house, lived here for 8 years now

But if it's not broke...... don't fix it indeed!

Hopefully that boot issue will be sorted now, I'd much rather solve it this way than having to open everything up and changing jumpers. Not that I mind doing that, but it involves having to bother people to help me (or rather, my hands) out.

Posted: **Sun Mar 02, 2014 11:23 am**

Eadwine Rose wrote:F8 works like a peach, nice thing!

I had seen it before in the boot messages, but it wasn't clear to me what it did.

There's a key for this on all BIOSs - F8 is what Asus use, my netbook is F10. It's the easiest way to boot from any kind of removable media.

Posted: **Sun Mar 02, 2014 12:21 pm**

Yeah.. ALL options were there.. both dvd drives, the hard drive, the external usb, even the card reader hahaha

I was just too scared to tap that F8 in the past. As I didn't know what it did, I didn't want to inadvertently break things, so.. steered clear.

Posted: **Sun Mar 02, 2014 12:38 pm**

richb wrote:I Have updated bios several times with success, but once, back in the old days, my floppy failed in the middle. The result was a motherboard that had to be replaced. So I understand the reluctance.

Many modern motherboards have a second backup BIOS chip that will become the default if the original can't be read.

Chris

Posted: **Sun Mar 02, 2014 1:37 pm**

chrispop99 wrote:
richb wrote:I Have updated bios several times with success, but once, back in the old days, my floppy failed in the middle. The result was a motherboard that had to be replaced. So I understand the reluctance.
Many modern motherboards have a second backup BIOS chip that will become the default if the original can't be read.

Chris

I would be careful relying on that, as low cost machines probably do not have a backup. I doubt my laptop does. Having said that I only had that problem once many moons ago, (about 15 to 20 years) .

Posted: **Sun Mar 02, 2014 2:08 pm**

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.

Posted: **Sun Mar 02, 2014 2:20 pm**

@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.

Posted: **Sun Mar 02, 2014 2:39 pm**

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

Posted: **Sun Mar 02, 2014 3:40 pm**

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

Posted: **Sun Mar 02, 2014 3:44 pm**

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!

Posted: **Sun Mar 02, 2014 3:55 pm**

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!

Posted: **Sun Mar 02, 2014 7:34 pm**

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?

Posted: **Sun Mar 02, 2014 9:07 pm**

qtech wrote: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.

Posted: **Sun Mar 02, 2014 11:35 pm**

BitJam wrote:...
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.

Posted: **Mon Mar 03, 2014 12:32 am**

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.

Posted: **Mon Mar 03, 2014 3:57 am**

qtech wrote: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?

I agree about a possible flaw in the BIOS firmware, combined with BitJam's suggestion below. I have the identical motherboard and have had problems with drive recognition in Mepis 12 & MX-14. I had no problems with Mepis 11.

BitJam wrote: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.

Expressed more technically, this is what I was trying to say in my simple way. I've not had the problem of device allocation varying, but I don't use the PATA port. I've had a persistent problem with hanging boots, always at about the point where /dev is populated.

qtech wrote: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.

I don't think you're right on this. I can't interpret the lsmod information, but I asked Eadwine about her SATA BIOS settings, and she said "All IDE". For the 6 SATA ports on this motherboard there are 3 possibilities - all AHCI, all IDE, 1-4 SATA + 5-6 IDE. The default is all IDE and I have option 3 (needed to let the system recognise a SATA optical drive when installing OS).

One other point. Eadwine posted a photo of her screen during the BIOS stage which showed:

Code: Select all

Auto Detecting Pri Master ATAPI CD-ROM
Auto Detecting Pri Slave ATAPI CD ROM
Auto Detecting SATA1 IDE Hard Disk
Pri Master Plextor
Pri Slave Sony

So it looks like the BIOS is detecting the PATA optical drives before the SATA hard disk. I can't get a shot of my screen - it's gone too quickly - but the only Auto Detect is the SATA optical drive.

Posted: **Mon Mar 03, 2014 9:32 am**

If you have a film function on the camera, you can use that and then grab the screen you need

Posted: **Mon Mar 03, 2014 11:04 am**

Eadwine Rose wrote:If you have a film function on the camera, you can use that and then grab the screen you need :smile:

I can try - watch this space!

Posted: **Mon Mar 03, 2014 11:23 am**

Gaer Boy wrote:...So it looks like the BIOS is detecting the PATA optical drives before the SATA hard disk. I can't get a shot of my screen - it's gone too quickly - but the only Auto Detect is the SATA optical drive.

Have you tried pressing the Scroll Lock or Pause/Break key ?

Posted: **Mon Mar 03, 2014 11:32 am**

I'll try that as well, but there's only about 1/10 second between the message appearing and the screen blanking. I'm too old for game response times!

Posted: **Mon Mar 03, 2014 12:35 pm**

That was fun - I couldn't catch the screen by pausing to boot, but I did manage to film it. The view I needed was on 2 frames.

boot2.png

I've never been able to see the final two lines - and that is "00 USB..."

Posted: **Mon Mar 03, 2014 1:38 pm**

TWO only?? Geez... no I got the chance to actually take a picture (the 2nd one happened to be a lucky hit

).

Posted: **Tue Mar 04, 2014 2:12 am**

Definitely running AHCI here:

Code: Select all

Feb 17 18:27:53 eadwinemx14beta2 kernel: [    0.360692] pci 0000:00:11.0: set SATA to AHCI mode

Code: Select all

Feb 17 18:27:53 eadwinemx14beta2 kernel: [    2.548969] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Posted: **Tue Mar 04, 2014 8:22 am**

Just rechecked, IDE on both *shrug*

Meanwhile changed the jumpers to CS, and changed the boot order back to Plextor first.

Posted: **Tue Mar 04, 2014 2:10 pm**

Like Tux, we await the news with baited breath.

Posted: **Tue Mar 04, 2014 2:13 pm**

Only if I get this working for a week without issues will I call this a success

but so far so good. Booted a few times to this config due to fried printers, and no strangeness yet.

Posted: **Wed Mar 05, 2014 6:18 am**

qtech wrote:Definitely running AHCI here:

Code: Select all

Feb 17 18:27:53 eadwinemx14beta2 kernel: [    0.360692] pci 0000:00:11.0: set SATA to AHCI mode

Code: Select all

Feb 17 18:27:53 eadwinemx14beta2 kernel: [    2.548969] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Eadwine Rose wrote:Just rechecked, IDE on both *shrug*

So the kernel is overwriting the BIOS settings - I didn't notice that. There's nothing wrong with that in principle, although it may cause user confusion (not you, Eadwine). My SATA settings are different, and those lines don't appear in my syslog. In the interests of research, I will change my BIOS settings and see if I can reproduce the problem.

Posted: **Wed Mar 05, 2014 7:30 am**

OK.. remember the change I made to cable select? Nothing else was changed, just changed both Plextor and Sony jumpers to CS.

Didn't do the trick unfortunately.

Going to set the boot order back to HDD first, but here is the output of various commands again, attached.

Posted: **Wed Mar 05, 2014 8:53 am**

Changing the SATA mode to IDE in the BIOS gave me some fun. Booted OK and my syslog looks about the same as Eadwine's - "set SATA to AHCI mode" is included. The I tried booting with a usb data stick plugged in. First 5 attempts hung, with the final one locking the machine with a blank screen. There was no video signal because the monitor was cycling through it's 3 modes.

I reset SATA to AHCI mode in the BIOS, and tried again (usb stick still in) to get "missing operating system". A lunch break seemed to sort that and I'm back to normal.

Anyway, I couldn't find an way of reproducing Eadwine's problem.

Posted: **Wed Mar 05, 2014 11:53 pm**

Code: Select all

 *-disk                  
       description: SCSI Disk
       product: DVDR   PX-820A
       vendor: PLEXTOR
       physical id: 0.0.0
       bus info: scsi@0:0.0.0
       logical name: /dev/sda
       version: 1.00
       serial: [
       capabilities: removable
       configuration: ansiversion=5 sectorsize=512
     *-medium
          physical id: 0
          logical name: /dev/sda

logical name: /dev/sda

Ok, work with me here as I try to explain this.

Something believes the Plextor is a SCSI Hard Disk. When this happens the Plextor is mounted by Linux as a hard drive,

Code: Select all

/dev/sda

instead of as a DVD drive,

Code: Select all

sr0

Those intermittent times that the Plextor mounts is what is changing your drive letters (Windows speak) from /sda to /sdb or whatever. Likewise, the problem is resolved by you inserting a DVD in the Plextor and booting the computer. With a Disc in the drive, the computer knows not to mount the Plextor as a SCSI disc drive but as DVD instead. Not mounting the confused Plextor means the drive letters don't change.

Technically, it is correct that the Plextor theoretically could be legitimately recognized a SCSI disk drive but it's obviously not what we desire in this situation. Now, if you recall, the guys were talking about "timing" issues earlier. You have IDE, AHCI and USB all trying to mount drives at roughly the same time. Part of the issue here is the timing in which these drives detect and mount (and thus why it is an intermittent problem, the timings are not always the same). The solution is going to be to manipulate that timing. This might be as simple as moving the Lacie to a different USB port (USB timing issues are the more common sort). Or it might require changing the boot order (or other drive related settings) in the BIOS. Worst case scenario, you reverse DVD drives and make the Plextor the slave drive. Of course, then the Sony would try to mount as sda...

Maybe my reasoning here is flawed or the IDE ribbon cable has gone bad but I think we're getting closer to resolving this issue.

Posted: **Thu Mar 06, 2014 1:23 am**

Then explain to me why this was never an issue in earlier Mepis versions, and ONLY started creeping up in MX14? THAT is what I don't get.

'Sloppy reading' so to speak by the kernel or whatever that thing is called seems more likely to me to be the cause, rather than my hardware that has never given issues.

Posted: **Thu Mar 06, 2014 1:31 am**

Eadwine Rose wrote:Then explain to me why this was never an issue in earlier Mepis versions, and ONLY started creeping up in MX14? THAT is what I don't get.

'Sloppy reading' so to speak by the kernel or whatever that thing is called seems more likely to me to be the cause, rather than my hardware that has never given issues.

Eadwine, how old are those DVD players? How old is the IDE ribbon cable?

Posted: **Thu Mar 06, 2014 1:39 am**

qtech wrote:Something believes the Plextor is a SCSI Hard Disk.

That "something" is the kernel, which was determined from ER's system log a while ago. Here is an excerpt from the most recent system log:

Code: Select all

Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.973162] ata1.01: ATAPI: SONY DVD-ROM DDU1612, DYS1, max UDMA/33
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.989093] ata1.00: configured for UDMA/66
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.989748] ata1.01: configured for UDMA/33
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.991649] scsi scan: INQUIRY result too short (5), using 36
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.991656] scsi 0:0:0:0: Direct-Access                                    PQ: 0 ANSI: 5
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.992101] scsi 0:0:1:0: CD-ROM            SONY     DVD-ROM DDU1612  DYS1 PQ: 0 ANSI: 5
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.016708] ata4: SATA link down (SStatus 0 SControl 300)
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.016773] ata5: SATA link down (SStatus 0 SControl 300)
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.016808] ata6: SATA link down (SStatus 0 SControl 300)
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.048697] usb 6-6: new high-speed USB device number 4 using ehci-pci
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.188644] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.189769] ata3.00: ATA-8: WDC WD5000AAKS-00WWPA0, 01.03B01, max UDMA/133
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.189773] ata3.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.190958] ata3.00: configured for UDMA/133
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.191152] scsi 2:0:0:0: Direct-Access     ATA      WDC WD5000AAKS-0 01.0 PQ: 0 ANSI: 5
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.196115] sr0: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.196123] cdrom: Uniform CD-ROM driver Revision: 3.20
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.196309] sr 0:0:1:0: Attached scsi CD-ROM sr0
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198163] sd 2:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198245] sd 0:0:0:0: Attached scsi generic sg0 type 0
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198279] sd 2:0:0:0: [sdb] Write Protect is off
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198282] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198338] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198342] sr 0:0:1:0: Attached scsi generic sg1 type 5
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198501] sd 2:0:0:0: Attached scsi generic sg2 type 0
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.199311] sd 0:0:0:0: [sda] READ CAPACITY(16) failed
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.199315] sd 0:0:0:0: [sda]  
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.199317] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.199319] sd 0:0:0:0: [sda] Sense not available.
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.204706] sd 0:0:0:0: [sda] Write Protect is off
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.204712] sd 0:0:0:0: [sda] Mode Sense: 00 da 70 00
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.206883] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.217923] sd 0:0:0:0: [sda] READ CAPACITY(16) failed
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.217928] sd 0:0:0:0: [sda]  
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.217930] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.217931] sd 0:0:0:0: [sda] Sense not available.
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.224647] sd 0:0:0:0: [sda] Attached SCSI disk

It is the kernel that assigns the name sda to the dvd drive. The first time sda appears in the log is in a message that READ CAPACITY failed. I asked for the blkid output for extra confirmation the name sda is coming from the kernel (and not from udev) but when the error condition occurs, the sda device does not show up in the blkid output or in /proc/partitions or /proc/sys/dev/cdrom/info. It is not just a naming problem, the kernel is confused and cannot access the device.

The first error is:

Code: Select all

scan: INQUIRY result too short (5), using 36

Google(INQUIRY result too short) yielded a lot of hits. One [url=http://comments.gmane.org/gmane.linux.scsi/74353]succinct explanation was:

Well, it means what it says: the device wrongly returned only 5 bytes
for the INQUIRY command. Why it did this is a hardware issue.

qtech wrote:Technically, it is correct that the Plextor theoretically could be legitimately recognized a SCSI disk drive

This is simply not true. It is either a problem with the hardware/harware-configuration or it is a bug in the kernel. If the hardware is working correctly then dvd drives should always be recognized as dvd drives, otherwise it is a bug in the kernel.

You have IDE, AHCI and USB all trying to mount drives at roughly the same time.

As I said before, I don't think physically different buses are directly affecting the IDE bus. That would be rather magical. Although it is possible they are affecting each other indirectly via the power supply. It takes a lot of power to spin up a hard drive (or even an optical drive). If they are all spinning up together then maybe this causes a small dip in the power that affects the Plextor drive. As I've said before, it is now legitimate for the device names to change each boot due to race conditions between the various devices becoming available. But it is not legitimate to classify a dvd drive as a hard drive.

Part of the issue here is the timing in which these drives detect and mount (and thus why it is an intermittent problem, the timings are not always the same.

I'm glad we agree.

The solution is going to be to manipulate that timing.

This may fix the problem but if so, it is a work-around, not a solution. IMO, once we have ruled out a hardware/hardware-config problem then the next step is to report a possible kernel bug.

I like your idea of swapping the jumper config on the Sony and Plextor drives. It will be interesting to see if the problem really does affect the Sony as well. This would help rule out that something in the Plextor drive is contributing to the problem. Another thing to try is to disconnect the Sony and see if the problem persists. I also like your idea of swapping out the ribbon cable. Just unplugging and replugging the connectors might help. Physical connectors have a relatively high failure rate, although it is curious that the problem always manifests the same way. Faulty connectors should create random errors whenever you access the drives.

Posted: **Thu Mar 06, 2014 1:47 am**

How old are the drives, well they are the old kind, so they are not new. Can't remember how old exactly but the Plextor was relatively new when this system was build so I wager about 4 - 4.5 years old. The Sony is likely a bit older than that.

The cables and mobo and stuff were all bought in Sept 2010.

The drives were unplugged taken out of the case and replugged Tuesday, in order to get the jumpers switched. I don't remember this correctly, but the cable does not look to be long enough to switch the cable order around.

I will have my friend read and see what he says.

Posted: **Thu Mar 06, 2014 5:43 pm**

Eadwine Rose wrote:Then explain to me why this was never an issue in earlier Mepis versions, and ONLY started creeping up in MX14? THAT is what I don't get.

Have you tested it to see if the problem now occurs with older kernels? I don't think it will but if it does then that means it is a hardware problem the developed around the time you started using MX-14.

'Sloppy reading' so to speak by the kernel or whatever that thing is called seems more likely to me to be the cause, rather than my hardware that has never given issues.

If you are willing to change "sloppy reading" to "more aggressive reading" then I would agree with you, although this is only a guess. It is not unusual for newer kernels to have problems with older hardware. Sometimes a new boot parameter is needed that wasn't needed before. For example, on both my desktop computers I need to add nomodeset. If I don't then the nouveau driver makes them unusable.

Here is an official (but incomplete) list of kernel boot parameters. The boot parameter acpi=off often helps to boot older laptops. Older versions of the kernel have code that links ide to acpi so maybe that boot parameter will help you.

If it is not onerous then it would be interesting to see if the problem persists when you keep the Sony drive unplugged (IIUC, that is the only other drive on your ide bus). If this fixes things then it would add credence to the idea that the problem was caused by more aggressive scanning by the kernel, which caused a conflict on the ide bus. If it doesn't fix things then the problem is most likely in the Plextor drive and it might also occur with older kernels. Either answer could bring us closer to a solution.

Posted: **Thu Mar 06, 2014 6:13 pm**

BitJam wrote:
Eadwine Rose wrote:Then explain to me why this was never an issue in earlier Mepis versions, and ONLY started creeping up in MX14? THAT is what I don't get.
Have you tested it to see if the problem now occurs with older kernels? I don't think it will but if it does then that means it is a hardware problem the developed around the time you started using MX-14.

Not installing a different kernel on this thing; 10 foot pole rule

As for the disconnect Sony, yes they are both on the same bus, and I can do that. Wait and see though if I physically can. Likely not sooner than this weekend though.

Mind.. that link to the code is making me go

Posted: **Thu Mar 06, 2014 8:50 pm**

BitJam wrote:
qtech wrote:Something believes the Plextor is a SCSI Hard Disk.
That "something" is the kernel, which was determined from ER's system log a while ago. Here is an excerpt from the most recent system log:
Code: Select all
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.973162] ata1.01: ATAPI: SONY DVD-ROM DDU1612, DYS1, max UDMA/33
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.989093] ata1.00: configured for UDMA/66
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.989748] ata1.01: configured for UDMA/33
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.991649] scsi scan: INQUIRY result too short (5), using 36
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.991656] scsi 0:0:0:0: Direct-Access                                    PQ: 0 ANSI: 5
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    2.992101] scsi 0:0:1:0: CD-ROM            SONY     DVD-ROM DDU1612  DYS1 PQ: 0 ANSI: 5
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.016708] ata4: SATA link down (SStatus 0 SControl 300)
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.016773] ata5: SATA link down (SStatus 0 SControl 300)
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.016808] ata6: SATA link down (SStatus 0 SControl 300)
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.048697] usb 6-6: new high-speed USB device number 4 using ehci-pci
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.188644] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.189769] ata3.00: ATA-8: WDC WD5000AAKS-00WWPA0, 01.03B01, max UDMA/133
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.189773] ata3.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.190958] ata3.00: configured for UDMA/133
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.191152] scsi 2:0:0:0: Direct-Access     ATA      WDC WD5000AAKS-0 01.0 PQ: 0 ANSI: 5
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.196115] sr0: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.196123] cdrom: Uniform CD-ROM driver Revision: 3.20
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.196309] sr 0:0:1:0: Attached scsi CD-ROM sr0
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198163] sd 2:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198245] sd 0:0:0:0: Attached scsi generic sg0 type 0
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198279] sd 2:0:0:0: [sdb] Write Protect is off
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198282] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198338] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198342] sr 0:0:1:0: Attached scsi generic sg1 type 5
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.198501] sd 2:0:0:0: Attached scsi generic sg2 type 0
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.199311] sd 0:0:0:0: [sda] READ CAPACITY(16) failed
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.199315] sd 0:0:0:0: [sda]  
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.199317] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.199319] sd 0:0:0:0: [sda] Sense not available.
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.204706] sd 0:0:0:0: [sda] Write Protect is off
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.204712] sd 0:0:0:0: [sda] Mode Sense: 00 da 70 00
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.206883] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.217923] sd 0:0:0:0: [sda] READ CAPACITY(16) failed
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.217928] sd 0:0:0:0: [sda]  
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.217930] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.217931] sd 0:0:0:0: [sda] Sense not available.
Mar  5 13:15:42 eadwinemx14beta2 kernel: [    3.224647] sd 0:0:0:0: [sda] Attached SCSI disk
It is the kernel that assigns the name sda to the dvd drive. The first time sda appears in the log is in a message that READ CAPACITY failed. I asked for the blkid output for extra confirmation the name sda is coming from the kernel (and not from udev) but when the error condition occurs, the sda device does not show up in the blkid output or in /proc/partitions or /proc/sys/dev/cdrom/info. It is not just a naming problem, the kernel is confused and cannot access the device.

The first error is:
Code: Select all
scan: INQUIRY result too short (5), using 36
Google(INQUIRY result too short) yielded a lot of hits. One [url=http://comments.gmane.org/gmane.linux.scsi/74353]succinct explanation was:
Well, it means what it says: the device wrongly returned only 5 bytes
for the INQUIRY command. Why it did this is a hardware issue.

qtech wrote:Technically, it is correct that the Plextor theoretically could be legitimately recognized a SCSI disk drive
This is simply not true. It is either a problem with the hardware/harware-configuration or it is a bug in the kernel. If the hardware is working correctly then dvd drives should always be recognized as dvd drives, otherwise it is a bug in the kernel.
You have IDE, AHCI and USB all trying to mount drives at roughly the same time.
As I said before, I don't think physically different buses are directly affecting the IDE bus. That would be rather magical. Although it is possible they are affecting each other indirectly via the power supply. It takes a lot of power to spin up a hard drive (or even an optical drive). If they are all spinning up together then maybe this causes a small dip in the power that affects the Plextor drive. As I've said before, it is now legitimate for the device names to change each boot due to race conditions between the various devices becoming available. But it is not legitimate to classify a dvd drive as a hard drive.
Part of the issue here is the timing in which these drives detect and mount (and thus why it is an intermittent problem, the timings are not always the same.
I'm glad we agree.
The solution is going to be to manipulate that timing.
This may fix the problem but if so, it is a work-around, not a solution. IMO, once we have ruled out a hardware/hardware-config problem then the next step is to report a possible kernel bug.

I like your idea of swapping the jumper config on the Sony and Plextor drives. It will be interesting to see if the problem really does affect the Sony as well. This would help rule out that something in the Plextor drive is contributing to the problem. Another thing to try is to disconnect the Sony and see if the problem persists. I also like your idea of swapping out the ribbon cable. Just unplugging and replugging the connectors might help. Physical connectors have a relatively high failure rate, although it is curious that the problem always manifests the same way. Faulty connectors should create random errors whenever you access the drives.

Ok. You win. I'm not interested in a pissing contest.

@Eadwine

I wish you luck.

Posted: **Thu Mar 06, 2014 10:11 pm**

You're right. That comment was snarky. I apologize. I'm sorry I posted it. I was in a lot of physical pain last night and I took it out on you which I should not have done. I hope you will forgive me.

Posted: **Fri Mar 07, 2014 12:28 pm**

I don't think the fstab.backup file will do what you want as it stands. It uses /dev/sdx identification, which in your problem is already screwed up by the time fstab is read. This is one of the reasons why current fstab files use UUID.

You may solve your problem by editing the fstab to use UUID, or you could make it easier to read by labelling your partitions and using label= instead of UUID=

Posted: **Fri Mar 07, 2014 12:29 pm**

Split the topic about automounting to its own topic: http://forum.mepiscommunity.org/viewtop ... 91&t=35709

Posted: **Fri Mar 07, 2014 12:29 pm**

Gear boy, can you please repost in the new thread? Thanks

Posted: **Tue Mar 11, 2014 10:53 am**

Problem has not been solved. Even with both drives' jumpers on cable select and the boot from harddrive first option it STILL wishes to at times use sdb (Plextor).

I opened the cabinet and yippee my left hand wanted to do it haha.. so the power cable has now been pulled out of the Sony drive. Wait and see what gives.

Posted: **Tue Mar 11, 2014 3:29 pm**

When in doubt, unplug it (if you can)...works for me.

Posted: **Tue Mar 11, 2014 3:40 pm**

Well yeah it was one of the things I was told I could try you know

Just don't unplug the harddrive

Though I must say: that will successfully solve the renaming issue

Posted: **Tue Mar 11, 2014 3:47 pm**

Hey Eadwine, just unplug the monitor, then you won't have to see that stuff.-)

Posted: **Tue Mar 11, 2014 4:44 pm**

*facepalm* Why didn't I think of that??

(I want a like button.. heh)

Posted: **Thu Mar 13, 2014 4:20 pm**

Happened again. Last thing to try is putting the Plextor on slave with the jumpers (currently on CS, and becomes master during the boot).

Posted: **Tue Apr 08, 2014 4:48 pm**

I just ran into this for the first time. I just got a USB 3.0 stick. I have always used USB 2.0 in USB 2.0 ports. When I booted the USB 3.0 stick in a USB 3.0 port, what was sda, the internal hard drive, became sdb and the stick was sda.

It would seem to be a timing problem. Is it possible the stick beat the hd when booting?

Posted: **Tue Apr 08, 2014 4:52 pm**

richb wrote:I just ran into this for the first time. I just got a USB 3.0 stick. I have always used USB 2.0 in USB 2.0 ports. When I booted the USB 3.0 stick in a USB 3.0 port, what was sda, the internal hard drive, became sdb and the stick was sda.

It would seem to be a timing problem. Is it possible the stick beat the hd when booting?

Yes and it is all pretty random now how devices are labelled ie sda or sdc

Posted: **Tue Apr 08, 2014 4:53 pm**

Rich: Could very well be!

I am getting this about 20-25% of the time still with my system. Still need to change that jumper on plextor to slave though. Other stuff is keeping me occupied at the moment

Anti: you mean there is a newer kernel and such now that will avoid such problems as I have here in the future?

Posted: **Tue Apr 08, 2014 4:54 pm**

anticapitalista wrote:
richb wrote:I just ran into this for the first time. I just got a USB 3.0 stick. I have always used USB 2.0 in USB 2.0 ports. When I booted the USB 3.0 stick in a USB 3.0 port, what was sda, the internal hard drive, became sdb and the stick was sda.

It would seem to be a timing problem. Is it possible the stick beat the hd when booting?
Yes and it is all pretty random now how devices are labelled ie sda or sdc

Then unexplained.

Posted: **Tue Apr 08, 2014 4:54 pm**

Eadwine Rose wrote: Anti: you mean there is a newer kernel and such now that will avoid such problems as I have here in the future?

No, the opposite :)

Posted: **Tue Apr 08, 2014 4:56 pm**

richb wrote:
anticapitalista wrote:
richb wrote:I just ran into this for the first time. I just got a USB 3.0 stick. I have always used USB 2.0 in USB 2.0 ports. When I booted the USB 3.0 stick in a USB 3.0 port, what was sda, the internal hard drive, became sdb and the stick was sda.

It would seem to be a timing problem. Is it possible the stick beat the hd when booting?
Yes and it is all pretty random now how devices are labelled ie sda or sdc
Then unexplained.

Newer kernels set the device name (sda/sdc etc) on a first come first served basis. This means that your usb stick might be shown as sda on one box, but sdc on another or even possibly sda on first boot and sdc on second boot. It is a race.
BitJam posted somewhere about this.

Posted: **Tue Apr 08, 2014 5:00 pm**

anticapitalista wrote:
richb wrote:
anticapitalista wrote:
Yes and it is all pretty random now how devices are labelled ie sda or sdc
Then unexplained.
Newer kernels set the device name (sda/sdc etc) on a first come first served basis. This means that your usb stick might be shown as sda on one box, but sdc on another or even possibly sda on first boot and sdc on second boot. It is a race.
BitJam posted somewhere about this.

That was what I meant, in-artfully stated.

Posted: **Tue Apr 08, 2014 5:01 pm**

Cool.. we can expect more of these situations then with newbies coming in asking why their dvd players aren't recognized.

Something to keep in the back of the mind then when something unexplained like this comes along: ask for that drive naming command.

Posted: **Tue Apr 08, 2014 5:41 pm**

I don't boot with a USB FlashDrive drive plugged in. My two USB HDDs are plugged in all the time....but they aren't turned on when booting.

Posted: **Tue Apr 08, 2014 5:48 pm**

@Eadwine, there are two very different things going on here. Your problem has to do with a cdrom drive being treated like a hard drive and thus rendering it inoperable. IMO if this is not due to a hardware problem or a misconfiguration (including a possible misconfiguration in the BIOS) then it is a bug in the kernel.

@everyone,
The other "problem" is less severe. All the device still work, but the names like /dev/sda can be different on different boots. This is exacerbated when you boot from a LiveUSB because that changes the timing of when devices get recognized. This "problem" will not go away. We have been warned about this literally for years. We went through the sometimes painful process of converting our bootloaders and fstabs to use UUIDs instead of device names in preparation for it. We should not be surprised that the this change has finally arrived on our doorstep.

The only way the kernel can reliably provide consistent /dev/sdX names is to delay the boot process until it is sure that all devices of a certain type have been recognized. It was realized years ago that as hardware become more modular and more convoluted, it no longer made sense for people rely on consistent /dev/sdX names. That is why we have the /dev/disk-by/ directories. That is why we identify the root partition by UUID in a boot parameter. That is why we identify partitions in fstab by UUID and not device name.

It's not because people like UUIDs or find them easier or more intuitive to work with. It is because it is no longer practical to keep the /dev/sdX names consistent. Going forward, the solution is actually pretty simple and I've posted it before. We simply stop using /dev/sdX names when identifying devices in the installer. AFAIK, almost all of the information we should use to identify a device is in the output of the command:

Code: Select all

lsblk -o LABEL,MODEL,FSTYPE,RM,MOUNTPOINT,SIZE

See:
Persistent block device naming:

This article describes how to use persistent names for your block devices. This has been made possible by the introduction of udev and has some advantages over bus-based naming. If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary. This may result in device names like /dev/sda and /dev/sdb switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.

Persistent storage device names:

In a Linux system (and every other Unix like system), every device known to the kernel gets its own name during the device probing at bootup time. If the probing order does not change across reboots and if the hardware configuration remains the same, those names are stable and there is nothing to worry about.

With new technologies like FireWire, USB and Fibrechannel, devices can be added and removed at runtime. But even in the good old days it was not uncommon to add and remove drives, or to experience hardware failures at runtime. All this leads to a different probing order and the stable kernel device names are in danger for the next boot.

Posted: **Tue Apr 08, 2014 5:56 pm**

That resolves the installer issue, but what about the issue of booting with a USB stick in a port, not from the stick. My internal drives are designated by UUID in fstab but still show sdx designations in a file manager.

I can live with it as I label my drives to avoid confusion. So it is not an issue for me.

Posted: **Tue Apr 08, 2014 6:03 pm**

richb - the mount points for devices/partitions should also appear as labels or uuid under media in the future. That should also be the case in fstab.

Here is an example of my fstab that we are working on in antiX and MX with Adrian.:

Code: Select all

# Pluggable devices are handled by uDev, they are not in fstab
UUID=3b6c6562-2de0-4f14-993d-8af446a6bf57 / ext4 defaults,noatime 1 1
#LABEL="antiX-64" / ext4 defaults,noatime 1 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts mode=0622 0 0
#UUID=c0c16fbc-1e5a-46a8-9ecd-d064800b1dca swap swap sw, 0 0
LABEL="swap" swap swap sw, 0 0
#UUID=8fa6aecc-c2ee-48c5-9dd8-2e4027187922 /media/sda1 ext4 noauto,users,exec,relatime 0 0
LABEL="antiX-32" /media/antiX-32 ext4 noauto,users,exec,relatime 0 0
#UUID=2c53bf5a-8caa-4534-beb1-f5aa04050918 /media/sda3 ext3 auto,users,exec,relatime 0 0
LABEL="Torrents" /media/Torrents ext3 auto,users,exec,relatime 0 0
#UUID=f56325d7-99bc-4d6d-b84d-b81554a404dd /media/sdb3 ext3 auto,users,exec,relatime 0 0
LABEL="Data" /media/Data ext3 auto,users,exec,relatime 0 0
#UUID=d5b1c53b-8c62-4731-8492-021f22c45b69 /media/sdb5 btrfs auto,users,exec,relatime 0 0 
LABEL="Docs" /media/Docs btrfs auto,users,exec,relatime 0 0
#UUID=8fa6aecc-c2ee-48c5-9dd8-2e4027187922 /media/sdb6 ext4 noauto,users,exec,relatime 0 0
LABEL="MX-14" /media/MX-14 ext4 noauto,users,exec,relatime 0 0

Posted: **Tue Apr 08, 2014 6:24 pm**

I'd get more lost if I didn't have everything labeled. I need something I can actually read and know what it is.

Posted: **Tue Apr 08, 2014 6:42 pm**

I should also have mentioned in my post above the work done/in progress by BitJam in creating an /etc/fstab with labels/uuid which has been incorportaed into the gui installer.

Posted: **Wed Apr 09, 2014 10:51 am**

I have managed to change the jumper on the Plextor to slave, yay left hand. Sony is still disconnected. Boot order is back to cdrom first. Wait and see what is going to happen from now on!

Posted: **Sun Apr 13, 2014 3:06 am**

So.. Sony unplugged, Plextor on Slave, nope, not helping either, still happening.

That is all I can do. Going to put this baby's boot order back to harddrive first now. *shrug*