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 31C7013834F for ; Mon, 7 Jan 2013 22:55:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3EEDB21C056; Mon, 7 Jan 2013 22:55:08 +0000 (UTC) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DBEF221C00C for ; Mon, 7 Jan 2013 22:53:57 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id fg15so10534047wgb.9 for ; Mon, 07 Jan 2013 14:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:reply-to:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=xPOEfG8BQ1SpP6Gcv5wG+kmIqyX3yqjvvhLQ3zXnKwk=; b=rYkDt4q/BXcg7RP72Bv0xwXwh0BcQPbpQuzimOBKoANbYFjI6uXKZEUJoE/BQASWZH 0zXJlb0c93fVKeXVdG5QQscYKu3ng3CR6kcSnaIzmniuFjV3V/SjQyd07IVNE8CKgXXI UVIe92SDW7/ur7i+Xkol2zmt8pI3M8HGX+fIZ76q3GJksMgtfsdwsulBeNYgqfbZe8gM l1KwjBaQo9Q9UMY8SPfJds1usJnTy8rLB1SMfAKfqHWcyae9DyxAhs9OxS9k9pG3ZpjG 2E0E7Fcb7U4V9QaDCXGu2E4HIn0XSEiRC/RS7gi1g0Gqg883ilfRt8Wh7CPlKVBL+BqO KWMg== X-Received: by 10.180.82.69 with SMTP id g5mr11890959wiy.21.1357599236554; Mon, 07 Jan 2013 14:53:56 -0800 (PST) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by mx.google.com with ESMTPS id p3sm14178324wic.8.2013.01.07.14.53.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jan 2013 14:53:46 -0800 (PST) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore Date: Mon, 7 Jan 2013 22:53:19 +0000 User-Agent: KMail/1.13.7 (Linux/3.6.11-gentoo; KDE/4.9.3; x86_64; ; ) References: <50EA7AC4.10206@gmail.com> In-Reply-To: <50EA7AC4.10206@gmail.com> 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 Content-Type: multipart/signed; boundary="nextPart2907492.KCp3372e1K"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201301072253.30360.michaelkintzios@gmail.com> X-Archives-Salt: da740e6f-faa3-4931-83b5-a85aba9fff3f X-Archives-Hash: 17ceeb813f50655a08512f24a99e5de8 --nextPart2907492.KCp3372e1K Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Monday 07 Jan 2013 07:35:32 Dale wrote: > I think you misunderstand or I didn't make myself clear. I'm not saying > it was udev that did this. I am pretty sure it was the kernel. All > this happened when people with older IDE drives, myself included on my > old machine, had to switch to the new drivers and devices. Before the > change, old IDE drives and CD/DVD drives were given hd* devices and udev > made a link to that with /dev/cdrom or dvd or whatever for optical > devices which is what you seem to expect now. The reason udev did that > was for it to be consistent which I have no problem with . When the > kernel folks changed this, they also changed it from /dev/cdrom and > /dev/dvd to /dev/sr0. From my understanding, all optical devices such > as CD and DVD readers/burners are supposed to be sr0. I know k3b > updated theirs too. I seem to recall I had to run a unstable version > for a bit because the older version didn't have the code to see sr* > devices. >=20 > I never said anything was broke, just that it was changed. There was > several things that was changed at about the same time that were related > and this was just one of them. Another was the change from /dev/hdXX to > /dev/sdXX for ALL hard drives. This change happened even if you was > using the old IDE drives. As I understand it, /dev/hdxx is no longer > supported on current kernels. All hard drives are /dev/sdxx and optical > drives are /dev/sr0(1,2,3,4 etc). >=20 > Also, I didn't remove anything. It was changed by the kernel which also > lead to udev changing what it did. Again, as much as I dislike what > udev is planning, I never said udev did this one. I'm pretty sure this > was all started with the kernel devs. The udev folks just followed along. >=20 > The biggest thing I recall is everyone with IDE drives having to update > the kernel config, edit fstab and grub or lilo before rebooting. This > was discussed on this list and I don't recall much fuss except for > having to change it and update everything. It was sort of a one time > thing and had a long term goal. All hard drives are sdxx and optical > devices are srx. All this happened when I was on my old rig which was > at least a few years ago. >=20 > Does that make more sense now? >=20 > Dale >=20 > :-) :-) I think that you are conflating two issues which are separate in terms of=20 chronology at least. Years ago we moved to libata and hdX changed to sdX. = =20 The udev confguration was updated at the time to link /dev/cd* and /dev/dvd= *=20 to srX. More recently, the udev rules nomenclature changed. The udev persistent-cd= =20 rules however was not changed. I moved it, remerged stable udev and the fi= le=20 was not recreated. So something in udev has changed and it no longer=20 generates the persistent-cd rules. BTW, pressing the touch sensitive button on the laptop to eject the CD won'= t=20 work, neither will typing eject in a terminal: $ eject eject: tried to use `/mnt/cdrom' as device name but it is no block device eject: unable to find or open device for: `cdrom' So, eject is still looking for cdrom ... Either all commands and legacy apps should update themselves, or I better=20 follow Mark's suggestion? =2D-=20 Regards, Mick --nextPart2907492.KCp3372e1K Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlDrUeoACgkQVTDTR3kpaLbHUACgr6RAJQR7XC4L33SpFlLlh3P3 ekQAn3ljWii3zKG895Gk1JG9gT8zpAF9 =9zM4 -----END PGP SIGNATURE----- --nextPart2907492.KCp3372e1K--