From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id AECDA138340 for ; Mon, 7 Jan 2013 17:38:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1DEDD21C002; Mon, 7 Jan 2013 17:38:30 +0000 (UTC) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 919AF21C030 for ; Mon, 7 Jan 2013 17:37:07 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so8671967bkc.13 for ; Mon, 07 Jan 2013 09:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HlY74bcX34ink7asiI1j3rUQBzkvT/UXVzPjBuz9b3E=; b=HqJE9HQtk0gELEi6fZn07heyvpDzi2yRmaJ0Z/EA+hDP7Adqj2GA2BYJdyF9eFHGgC Bs4fs+F31Im4fLlOGzqFDedEM9M89LK/Yq5YvBcQIeRdwkTQQPu68aLKj2tduJuvhXNW YbxyNU6K5nhd7n0ny+1+kgU/vyjKOAdO7S0xE4X9sXn3dLGmDn5xbYlEIJRLaLMalM4a JZbSFhzgB9tC9jXvZ4y3WWwoDocpIfIQbfFbo2T10vmnuynGzlQMr5p/4kwXyL7dN/9a 1NrPEv9pHfad2TNZiTH0WObhv5kKmJ10OCMu2phdg/+bAr5GecZkzyVlZ1V3JPfsNf6q YnsQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.150.205 with SMTP id z13mr31146113bkv.16.1357580226064; Mon, 07 Jan 2013 09:37:06 -0800 (PST) Received: by 10.204.199.144 with HTTP; Mon, 7 Jan 2013 09:37:05 -0800 (PST) In-Reply-To: References: <201301061119.56710.michaelkintzios@gmail.com> <50EA2364.4080604@gmail.com> Date: Mon, 7 Jan 2013 09:37:05 -0800 Message-ID: Subject: Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore From: Mark Knecht To: Gentoo User Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: fae9da32-70fe-4915-b725-84212c33dbb4 X-Archives-Hash: 5dda6156b2f27db601d4f111daf4284b On Mon, Jan 7, 2013 at 7:18 AM, Grant Edwards wrote: > On 2013-01-07, Dale wrote: > >> I'm not sure that is a bug. As I posted earlier, this was changed a >> good while back. There was a reason for it but I can't recall what it >> was. The new devices for CD/DVDs is /dev/sr*. > > It's been something like 6-8 years hasn't it? IIRC the SATA interface has always labeled them as /dev/sdX /dev/srX. Everything I've built using new hardware in the last 5 years has been SATA based and I've not had a new machine with /dev/hdX in longer than I can remember. However, best I can tell, that has _nothing_ to do with why /dev/cdrom /dev/dvd disappeared in the last couple of months. Remember, my machines have all had /dev/srX. Going back to my post with one of many solutions to this issue: First - the old way that udev was recognizing the cdrw/dvd drive on my system was via an ID_PATH value for the pci device: #SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1" However you will note that ID_PATH (the key used by udev) doesn't exist any more c2stable ~ # udevadm info --query=all --name=/dev/sr0 | grep ID_PATH c2stable ~ # Best guess I have is that ID_PATH may have been changed to DEVPATH c2stable ~ # udevadm info --query=all --name=/dev/sr0 | grep DEVPATH E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata11/host10/target10:0:0/10:0:0:0/block/sr0 c2stable ~ # What I did was ask udev to identify by the drive's model number using ID_MODEL: New way: SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_MODEL}=="Optiarc_DVD_RW_AD-7241S", SYMLINK+="cdrom", ENV{GENERATED}="1" A little playing around suggest you can use anything unique to the device. Now, my point is that change to /dev/srX was the root cause is FUD. It isn't the root cause of this change because it didn't change on my systems. All I know is that ID_PATH (from the old file) used to work and no longer does. Whatever is responsible for creating that, likely some portion of the kernel, changed the value and created a need to modify how udev looks at the system. Is it a bug? I don't know. It's just the way it is. Just my views, Mark