Re: Upgrade script for libata transition
On Mon, Feb 15, 2010 at 10:51:59PM +, Ben Hutchings wrote: Oops, I'm sure I had that working at one point. Please try http://people.debian.org/~benh/linux-2.6_2.6.32-8a~test1.dsc. Here's what happens upon installation of this package: ju...@debian:~/linux$ sudo dpkg -i linux-base_2.6.32-8a~test1_all.deb Selecting previously deselected package linux-base. (Reading database ... 64420 files and directories currently installed.) Unpacking linux-base (from linux-base_2.6.32-8a~test1_all.deb) ... Setting up linux-base (2.6.32-8a~test1) ... Error parsing silo config file /etc/silo.conf Error setting debconf substitutions in linux-base/disk-id-manual: Unsupported command config (full line was Config file error: Syntax error near line 2 in file /etc/silo.conf) received from confmodule. at /var/lib/dpkg/info/linux-base.postinst line 1406, STDIN line 11. dpkg: error processing linux-base (--install): subprocess installed post-installation script returned error exit status 9 Errors were encountered while processing: linux-base Trying to install it again succeeds, I guess because it skips some already-asked debconf question, as it does not try to modify /etc/silo.conf the second time. The new silo.conf looks like this: # root = /dev/sdb2 root = UUID=c6cd1add-df06-4bea-a511-76a0802d74b0 partition=1 default=Linux read-only timeout=100 image=/vmlinuz label=Linux initrd=/initrd.img image=/vmlinuz.old label=LinuxOLD initrd=/initrd.img.old which, quite predictably, is not understood by silo: ju...@debian:~/linux$ sudo silo -f Config file error: Syntax error near line 2 in file /etc/silo.conf Error parsing silo config file /etc/silo.conf I glanced through the SILO code and have not find any evidence that it supports device identification by UUID. Do you have any reason to believe that it should work, because I fail to see one. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216222912.ga2...@droopy.oc.cox.net
Re: Upgrade script for libata transition
On Tue, 2010-02-16 at 22:29 +, Jurij Smakov wrote: [...] Trying to install it again succeeds, I guess because it skips some already-asked debconf question, as it does not try to modify /etc/silo.conf the second time. The new silo.conf looks like this: # root = /dev/sdb2 root = UUID=c6cd1add-df06-4bea-a511-76a0802d74b0 [...] which, quite predictably, is not understood by silo: ju...@debian:~/linux$ sudo silo -f Config file error: Syntax error near line 2 in file /etc/silo.conf Error parsing silo config file /etc/silo.conf I glanced through the SILO code and have not find any evidence that it supports device identification by UUID. Do you have any reason to believe that it should work, because I fail to see one. LILO/SILO/etc. don't interpret the root - this string is passed to the kernel and then to the initramfs. However, because it has an '=' in it, I think it needs to be quoted. Can you test that this works with double-quotes around the UUID= string? Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Re: Upgrade script for libata transition
On Tue, Feb 16, 2010 at 10:44:57PM +, Ben Hutchings wrote: On Tue, 2010-02-16 at 22:29 +, Jurij Smakov wrote: [...] Trying to install it again succeeds, I guess because it skips some already-asked debconf question, as it does not try to modify /etc/silo.conf the second time. The new silo.conf looks like this: # root = /dev/sdb2 root = UUID=c6cd1add-df06-4bea-a511-76a0802d74b0 [...] which, quite predictably, is not understood by silo: ju...@debian:~/linux$ sudo silo -f Config file error: Syntax error near line 2 in file /etc/silo.conf Error parsing silo config file /etc/silo.conf I glanced through the SILO code and have not find any evidence that it supports device identification by UUID. Do you have any reason to believe that it should work, because I fail to see one. LILO/SILO/etc. don't interpret the root - this string is passed to the kernel and then to the initramfs. However, because it has an '=' in it, I think it needs to be quoted. Can you test that this works with double-quotes around the UUID= string? Hmm, whaddaya know, with quotes it works :-). I've also checked what Ubuntu has been doing, and they switched to UUID by replacing /dev/sdXN by /dev/disk/by-uuid/uuid. The package available at https://launchpad.net/ubuntu/+source/silo/1.4.13a+git20070930-1ubuntu1 contains the postinst script which accomplishes that. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216230819.ga3...@droopy.oc.cox.net
Re: Upgrade script for libata transition
On Fri, Feb 12, 2010 at 05:28:04AM +, Ben Hutchings wrote:
On Thu, 2010-01-07 at 22:49 +, Ben Hutchings wrote:
On Tue, 2009-12-29 at 12:06 +, Ben Hutchings wrote:
Linux kernel packages for squeeze will use libata-based drivers in
preference to old-style IDE drivers. On some systems this will change
the names of PATA devices and will also change the names of SCSI devices
already present in those systems if they are enumerated after the PATA
devices.
On upgrade, we will recommend that users identify hard disk volumes in
configuration files by label or UUID (unique identifier) rather than by
device name, which will work with both old and new kernel versions. I
think that in most cases it should be possible to update the system
configuration automatically, if the user agrees to this. The following
script implements this. Please review and verify that it does the right
thing for your package's configuration file(s). (I would also welcome a
more general review of the code.)
[...]
I have not yet seen any comments from maintainers of the various boot
loaders. It is vital that this upgrade process is reliable and does not
prevent systems from booting, so please do review the code for your boot
loader.
If you prefer, I can prepare packages that include this script on
postinst and upload them to people.debian.org for you or others to test.
Sorry about the delay in doing this. You can now get a source package
by doing:
$ apt-get -d source linux-2.6
$ dget http://people.debian.org/~benh/linux-2.6_2.6.32-8a~test.dsc
To build a kernel image package, follow the instructions at:
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
Note in particular the instructions beginning 'For example, to build
only the binary packages for 686 flavour...'
That does not quite work, one should replace the command
fakeroot debian/rules debian/build debian/stamps
from this doc with
fakeroot debian/rules setup
for the current linux-2.6 packages.
The kernel image packages will depend on the linux-base package which
contains the transition script. To build that, run:
$ fakeroot make -f debian/rules.real install-linux-base
Please test both the transition script and the new drivers so far as you
can (most are x86-only but some are available for all architectures with
PCI). I suggest starting with an emulated/virtualised system before you
risk breaking anything real!
For me the installation of linux-base (on sparc) just hangs while
configuring the package. It appears that it loops forever in the
lilo_list function, presumably after hitting the token corresponding
to 'image=/vmlinuz' line in /etc/silo.conf, as the following code
snippet fails to increment the counter used to loop through the
tokens:
if ($name eq 'image') {
$in_generic = ($value =~ m|^/vmlinuz(?:\.old)?$|);
next;
}
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100215181357.ga5...@droopy.oc.cox.net
Re: Upgrade script for libata transition
On Mon, 2010-02-15 at 18:13 +, Jurij Smakov wrote:
On Fri, Feb 12, 2010 at 05:28:04AM +, Ben Hutchings wrote:
[...]
To build a kernel image package, follow the instructions at:
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
Note in particular the instructions beginning 'For example, to build
only the binary packages for 686 flavour...'
That does not quite work, one should replace the command
fakeroot debian/rules debian/build debian/stamps
from this doc with
fakeroot debian/rules setup
for the current linux-2.6 packages.
The examples are wrong but the instructions are right!
'debian/rules source' is sufficient so I'm going to recommend that. I
have fixed this in svn and will update the web site some time soon.
The kernel image packages will depend on the linux-base package which
contains the transition script. To build that, run:
$ fakeroot make -f debian/rules.real install-linux-base
Please test both the transition script and the new drivers so far as you
can (most are x86-only but some are available for all architectures with
PCI). I suggest starting with an emulated/virtualised system before you
risk breaking anything real!
For me the installation of linux-base (on sparc) just hangs while
configuring the package. It appears that it loops forever in the
lilo_list function, presumably after hitting the token corresponding
to 'image=/vmlinuz' line in /etc/silo.conf, as the following code
snippet fails to increment the counter used to loop through the
tokens:
if ($name eq 'image') {
$in_generic = ($value =~ m|^/vmlinuz(?:\.old)?$|);
next;
}
Oops, I'm sure I had that working at one point. Please try
http://people.debian.org/~benh/linux-2.6_2.6.32-8a~test1.dsc.
Ben.
--
Ben Hutchings
Humour is the best antidote to reality.
signature.asc
Description: This is a digitally signed message part
Re: Upgrade script for libata transition
On Thu, 2010-01-07 at 22:49 +, Ben Hutchings wrote: On Tue, 2009-12-29 at 12:06 +, Ben Hutchings wrote: Linux kernel packages for squeeze will use libata-based drivers in preference to old-style IDE drivers. On some systems this will change the names of PATA devices and will also change the names of SCSI devices already present in those systems if they are enumerated after the PATA devices. On upgrade, we will recommend that users identify hard disk volumes in configuration files by label or UUID (unique identifier) rather than by device name, which will work with both old and new kernel versions. I think that in most cases it should be possible to update the system configuration automatically, if the user agrees to this. The following script implements this. Please review and verify that it does the right thing for your package's configuration file(s). (I would also welcome a more general review of the code.) [...] I have not yet seen any comments from maintainers of the various boot loaders. It is vital that this upgrade process is reliable and does not prevent systems from booting, so please do review the code for your boot loader. If you prefer, I can prepare packages that include this script on postinst and upload them to people.debian.org for you or others to test. Sorry about the delay in doing this. You can now get a source package by doing: $ apt-get -d source linux-2.6 $ dget http://people.debian.org/~benh/linux-2.6_2.6.32-8a~test.dsc To build a kernel image package, follow the instructions at: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official Note in particular the instructions beginning 'For example, to build only the binary packages for 686 flavour...' The kernel image packages will depend on the linux-base package which contains the transition script. To build that, run: $ fakeroot make -f debian/rules.real install-linux-base Please test both the transition script and the new drivers so far as you can (most are x86-only but some are available for all architectures with PCI). I suggest starting with an emulated/virtualised system before you risk breaking anything real! Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus signature.asc Description: This is a digitally signed message part
Re: Upgrade script for libata transition
On Tue, 2009-12-29 at 14:17 +0100, Daniel Baumann wrote:
Ben Hutchings wrote:
Please review and verify that it does the right
thing for your package's configuration file(s).
extlinux in experimental does not reflect the final location and layout
of the configuration file:
/etc/default/extlinux
EXTLINUX_ROOT=${DEVICE}
At first I thought you meant that the package in experimental would read
this configuration file, but this doesn't seem to be the case. So I
don't understand what you mean. Which version(s) of extlinux read
/etc/default/extlinux? Do I need to worry about this?
Ben.
--
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.
signature.asc
Description: This is a digitally signed message part
Re: Upgrade script for libata transition
* Ben Hutchings b...@decadent.org.uk [2009-12-29 12:06]:
Linux kernel packages for squeeze will use libata-based drivers in
preference to old-style IDE drivers. On some systems this will change
Some comments:
- Machines needing the DELO boot loader are no longer supported but
I guess it doesn't hurt to have it there.
(BTW, is there a reason we list all these boot loaders in
temp.image.plain/postinst?)
- Support for CoLo is needed (Cobalt machines). A patch is below.
It generates a good boot config. Hmm, actually, there is a
problem: it won't boot. mips/mipsel don't use a ramdisk and the
kernel doesn't like root=UUID=... I guess the solution is to
convert hdaX to sdaX. Comments? (The same problem applies to
delo/arcboot but there we could simply skip the UUID conversion
since the machines use SCSI anyway and so have always used sdaX)
- I wonder if you should run update-initramfs -u on machines
where flash-kernel is installed and `flash-kernel --supported` is true
(the root device is stored in the ramdisk).
- grub1_update on line 308 has:
if (defined(my $new_value = kernel_update($value))) {
Don't you have to pass $map to kernel_update() as the 2nd paramter?
--- upgrade 2010-01-11 19:22:06.0 +
+++ colo2 2010-01-11 20:26:51.0 +
@@ -819,6 +819,36 @@
}
}
+### colo
+
+sub colo_list {
+my ($file) = @_;
+while ($file) {
+ # If CoLo is not configured to use the generic symlink, ignore it.
+ if (/^load.*vmlinux-/) {
+ return ();
+ }
+ if (/^execute root=(\S+)/) {
+ return $1;
+ }
+}
+return ();
+}
+
+sub colo_update {
+my ($old, $new, $map) = @_;
+while ($old) {
+ my $text = $_;
+ if (/^mount hda/) {
+ $text = # CoLo uses hda rather than sda to refer to the
disk\n$text;
+ }
+ if (/^execute root=(\S+)(.*)/) {
+ $text = # $text . execute root= . $map-{$1} . $2\n;
+ }
+ $new-print($text);
+}
+}
+
### Filesystem relabelling
sub ext2_label {
@@ -974,7 +1004,11 @@
{packages = 'aboot',
path = '/etc/aboot.conf',
list = \aboot_list,
-update = \aboot_update});
+update = \aboot_update},
+ {packages = 'colo',
+path = '/boot/default.colo',
+list = \colo_list,
+update = \colo_update});
my %bdev_map = ();
my @matched_configs = ();
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upgrade script for libata transition
You wrote: Ben Hutchings wrote: I have not yet seen any comments from maintainers of the various boot loaders. did you see http://lists.debian.org/debian-kernel/2009/12/msg00596.html I'm sorry, I did see that and I should have acknowledged it. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Re: Upgrade script for libata transition
On Tue, 2009-12-29 at 14:54 +0100, Marco d'Itri wrote: On Dec 29, Ben Hutchings b...@decadent.org.uk wrote: Is it not possible to add corresponding rules, e.g.: Two issues: I am not sure that it is possible to determine the new $ID_PATH value and I fear that multiple rules for the same link name may confuse the scripts. Please can you test whether this is the case. Although CD device names are not as critical as disks, I do want to make this upgrade as smooth as possible. Ben. -- Ben Hutchings To err is human; to really foul things up requires a computer. signature.asc Description: This is a digitally signed message part
Re: Upgrade script for libata transition
On Tue, 2009-12-29 at 12:06 +, Ben Hutchings wrote: Linux kernel packages for squeeze will use libata-based drivers in preference to old-style IDE drivers. On some systems this will change the names of PATA devices and will also change the names of SCSI devices already present in those systems if they are enumerated after the PATA devices. On upgrade, we will recommend that users identify hard disk volumes in configuration files by label or UUID (unique identifier) rather than by device name, which will work with both old and new kernel versions. I think that in most cases it should be possible to update the system configuration automatically, if the user agrees to this. The following script implements this. Please review and verify that it does the right thing for your package's configuration file(s). (I would also welcome a more general review of the code.) [...] I have not yet seen any comments from maintainers of the various boot loaders. It is vital that this upgrade process is reliable and does not prevent systems from booting, so please do review the code for your boot loader. If you prefer, I can prepare packages that include this script on postinst and upload them to people.debian.org for you or others to test. Ben. -- Ben Hutchings To err is human; to really foul things up requires a computer. signature.asc Description: This is a digitally signed message part
Re: Upgrade script for libata transition
On Thu, Jan 07, 2010 at 10:49:56PM +, Ben Hutchings wrote: On Tue, 2009-12-29 at 12:06 +, Ben Hutchings wrote: Linux kernel packages for squeeze will use libata-based drivers in preference to old-style IDE drivers. On some systems this will change the names of PATA devices and will also change the names of SCSI devices already present in those systems if they are enumerated after the PATA devices. On upgrade, we will recommend that users identify hard disk volumes in configuration files by label or UUID (unique identifier) rather than by device name, which will work with both old and new kernel versions. I think that in most cases it should be possible to update the system configuration automatically, if the user agrees to this. The following script implements this. Please review and verify that it does the right thing for your package's configuration file(s). (I would also welcome a more general review of the code.) I have not yet seen any comments from maintainers of the various boot loaders. It is vital that this upgrade process is reliable and does not prevent systems from booting, so please do review the code for your boot loader. Well, aboot is effectively unmaintained, along with the port as a whole, since I no longer have an alpha that boots (and I don't think doing test builds on a buildd is adequate for uploading a bootloader with a different toolchain, so I haven't officially orphaned the package). If you care about getting feedback for alpha, I'd suggest mailing debian-al...@lists.debian.org. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Upgrade script for libata transition
Ben Hutchings wrote: I have not yet seen any comments from maintainers of the various boot loaders. did you see http://lists.debian.org/debian-kernel/2009/12/msg00596.html -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upgrade script for libata transition
Linux kernel packages for squeeze will use libata-based drivers in
preference to old-style IDE drivers. On some systems this will change
the names of PATA devices and will also change the names of SCSI devices
already present in those systems if they are enumerated after the PATA
devices.
On upgrade, we will recommend that users identify hard disk volumes in
configuration files by label or UUID (unique identifier) rather than by
device name, which will work with both old and new kernel versions. I
think that in most cases it should be possible to update the system
configuration automatically, if the user agrees to this. The following
script implements this. Please review and verify that it does the right
thing for your package's configuration file(s). (I would also welcome a
more general review of the code.)
For optical disc drives, it may be possible to update udev naming rules
in /etc/udev/rules.d/70-persistent-cd.rules; I have not tried to
implement this yet.
For tape drives, I have no suggestions (in fact I have little idea which
packages would use tape drive names) but hopefully the affected users
are competent to update the configuration themselves.
Ben.
#!/usr/bin/perl
# Copyright 2009 Ben Hutchings
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
use strict;
use warnings;
use Debconf::Client::ConfModule ':all';
use FileHandle;
use POSIX ();
### utility
sub id_to_path {
my ($id) = @_;
$id =~ m|^/|
or $id =~ s{^(LABEL|UUID)=}{'/dev/disk/by-' . lc($1) . '/'}x
or die Could not map id $id to path;
return $id;
}
### /etc/fstab
sub fstab_next {
# Based on my_getmntent() in mount_mntent.c
my ($file) = @_;
my $text = $file;
unless (defined($text)) {
return ();
}
my $line = $text;
$line =~ s/\r?\n$//;
$line =~ s/^[ \t]*//;
if ($line =~ /^(#|$)/) {
return ($text);
} else {
return ($text,
map({ s/\\([0-7][0-7][0-7])/chr(oct($1) 0xff)/eg; $_; }
split(/[ \t]+/, $line)));
}
}
sub fstab_list {
my ($file) = @_;
my @bdevs;
while (1) {
my ($text, $bdev) = fstab_next($file);
last unless defined($text);
if (defined($bdev)) {
push @bdevs, $bdev;
}
}
return @bdevs;
}
sub fstab_update {
my ($old, $new, $map) = @_;
while (1) {
my ($text, $bdev) = fstab_next($old);
last unless defined($text);
if (defined($bdev) defined(my $id = $map-{$bdev})) {
$text =~ s/^(\s*\S+)(.*)/# $1$2\n$id$2/;
}
$new-print($text);
}
}
### Kernel parameters
sub kernel_list {
my ($cmd_line) = @_;
return ($cmd_line =~ /\broot=(\S+)/) ? ($1) : ();
}
sub kernel_update {
my ($cmd_line, $map) = @_;
if ($cmd_line =~ /\broot=(\S+)/ defined(my $id = $map-{$1})) {
$cmd_line =~ s/\broot=(\S+)/root=$id/;
return $cmd_line;
} else {
return undef;
}
}
### shell script variable assignment
# Maintains enough context to find statement boundaries, and can parse
# variable definitions that do not include substitutions. I think.
sub shellvars_next {
my ($file) = @_;
my $text = '';
my @context = ('');
my $first = 1;
my $in_value = 0;
my ($name, $value);
my $unhandled = 0;
LINE:
while ($file) {
$text .= $_;
# variable assignment
if ($first m/^\s*([A-Za-z_][A-Za-z0-9_]*)=/g) {
$name = $1;
$value = '';
$in_value = 1;
}
while (/\G(.*?)([#`'(){}\s]|\\.|\$[({]?)/gs) {
my $end_pos = pos;
my $special = $2;
if ($in_value) {
# add non-special characters to the value verbatim
$value .= $1;
}
if ($context[$#context] eq '') {
# space outside quotes or brackets ends the value
if ($special =~ /^\s/) {
$in_value = 0;
if ($special eq \n) {
last LINE;
}
}
# something else after the value means this is a command
# with an environment override, not a variable definition
elsif (defined($name) !$in_value) {
$unhandled
Re: Upgrade script for libata transition
On Dec 29, Ben Hutchings b...@decadent.org.uk wrote: For optical disc drives, it may be possible to update udev naming rules in /etc/udev/rules.d/70-persistent-cd.rules; I have not tried to implement this yet. It looks hard. Just deleting it on upgrades will solve the problem for most users. The new Linux kernel version provides different drivers for some IDE/ATA disk controllers. The names of some hard disk, CD-ROM and tape devices may change. Maybe the text should be amended to clarify that this is about old parallel ATA devices and not SATA devices. -- ciao, Marco signature.asc Description: Digital signature
Re: Upgrade script for libata transition
Ben Hutchings wrote:
Please review and verify that it does the right
thing for your package's configuration file(s).
extlinux in experimental does not reflect the final location and layout
of the configuration file:
/etc/default/extlinux
EXTLINUX_ROOT=${DEVICE}
Regards,
Daniel
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baum...@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upgrade script for libata transition
On Tue, Dec 29, 2009 at 01:39:46PM +0100, Marco d'Itri wrote: On Dec 29, Ben Hutchings b...@decadent.org.uk wrote: For optical disc drives, it may be possible to update udev naming rules in /etc/udev/rules.d/70-persistent-cd.rules; I have not tried to implement this yet. It looks hard. Just deleting it on upgrades will solve the problem for most users. I agree the enumeration order is not likely to change for most users. However this will cause problems for people who switch back and forth between different kernel versions (e.g. when testing whether a bug is fixed in unstable). The new Linux kernel version provides different drivers for some IDE/ATA disk controllers. The names of some hard disk, CD-ROM and tape devices may change. Maybe the text should be amended to clarify that this is about old parallel ATA devices and not SATA devices. Good point; I'll do that. Ben. -- Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds signature.asc Description: Digital signature
Re: Upgrade script for libata transition
On Dec 29, Ben Hutchings b...@decadent.org.uk wrote: I agree the enumeration order is not likely to change for most users. However this will cause problems for people who switch back and forth between different kernel versions (e.g. when testing whether a bug is fixed in unstable). I can't see any solution for these people, and not having the device change name for the others looks like a more important goal to me. -- ciao, Marco signature.asc Description: Digital signature
Re: Upgrade script for libata transition
On Tue, Dec 29, 2009 at 02:23:10PM +0100, Marco d'Itri wrote:
On Dec 29, Ben Hutchings b...@decadent.org.uk wrote:
I agree the enumeration order is not likely to change for most users.
However this will cause problems for people who switch back and forth
between different kernel versions (e.g. when testing whether a bug is
fixed in unstable).
I can't see any solution for these people, and not having the device
change name for the others looks like a more important goal to me.
Is it not possible to add corresponding rules, e.g.:
if ($text =~
/^ENV{ID_CDROM}==\?\*,\s*
ENV{ID_PATH}==([^]*)-ide-(\d+):(\d+),\s*
SYMLINK+=([^]+),\s*
ENV{GENERATED}=1\n$/x) {
$text .= sprintf(ENV{ID_CDROM}==\?*\,
. ENV{ID_PATH}==\%s-scsi-%s:0:0:%s\,
. SYMLINK\+=\%s\, ENV{GENERATED}=1\n,
$1, $2, $3, $4);
}
Ben.
--
Ben Hutchings
When you say `I wrote a program that crashed Windows', people just stare ...
and say `Hey, I got those with the system, *for free*'. - Linus Torvalds
signature.asc
Description: Digital signature
Re: Upgrade script for libata transition
On Dec 29, Ben Hutchings b...@decadent.org.uk wrote: Is it not possible to add corresponding rules, e.g.: Two issues: I am not sure that it is possible to determine the new $ID_PATH value and I fear that multiple rules for the same link name may confuse the scripts. -- ciao, Marco signature.asc Description: Digital signature
Re: Re: Upgrade script for libata transition
My apologies if I am interfering by posting to this thread. I mostly
run kernels that I have compiled myself, but keep a Debian stock kernel
installed in case bad things happen to my custom kernels.
I try to keep up to date on the LKML happenings, and the writing is
clearly on the wall that the developers there are favoring the new
libata subsystem, and are all but deprecating the old IDE stuff.
For 2.6.32, I decided to switch my custom '.config' over to libata. I
hadn't done the proper amount of reading beforehand, and had a hell of a
time getting a device name assigned for my optical drives in /dev. Once
I figure that out, I found that 'udev' was giving me non-optimal symlink
names for those devices.
After some playing around with 'udevadm info ...', I was able to craft
this (apologies for the line breaks, which are not present in the actual
file):
$ cat /etc/udev/rules.d/70-persistent-cd.rules
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, probably run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line
# and set the $GENERATED variable.
# ASUS DRW-1814BL (pci-:00:14.1-scsi-0:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*, \
ENV{ID_PATH}==pci-:00:14.1-scsi-0:0:0:0, SYMLINK+=cdrom1, \
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*, \
ENV{ID_PATH}==pci-:00:14.1-scsi-0:0:0:0, SYMLINK+=cdrw, \
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*, \
ENV{ID_PATH}==pci-:00:14.1-scsi-0:0:0:0, SYMLINK+=dvd1, \
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*, \
ENV{ID_PATH}==pci-:00:14.1-scsi-0:0:0:0, SYMLINK+=dvdrw, \
ENV{GENERATED}=1
# TSSTcorpDVD-ROM_SH-D162C (pci-:00:14.1-scsi-0:0:1:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*, \
ENV{ID_PATH}==pci-:00:14.1-scsi-0:0:1:0, SYMLINK+=cdrom, \
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*, \
ENV{ID_PATH}==pci-:00:14.1-scsi-0:0:1:0, SYMLINK+=dvd, \
ENV{GENERATED}=1
# TSSTcorpDVD-ROM_SH-D162C (pci-:00:14.1)
SUBSYSTEM==block, ENV{ID_MODEL}==TSSTcorpDVD-ROM_SH-D162C, \
ENV{ID_PATH}==pci-:00:14.1, SYMLINK+=cdrom, ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_MODEL}==TSSTcorpDVD-ROM_SH-D162C, \
ENV{ID_PATH}==pci-:00:14.1, SYMLINK+=dvd, ENV{GENERATED}=1
# ASUS_DRW-1814BL (pci-:00:14.1)
SUBSYSTEM==block, ENV{ID_MODEL}==ASUS_DRW-1814BL, \
ENV{ID_PATH}==pci-:00:14.1, SYMLINK+=cdrom1, ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_MODEL}==ASUS_DRW-1814BL, \
ENV{ID_PATH}==pci-:00:14.1, SYMLINK+=cdrw, ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_MODEL}==ASUS_DRW-1814BL, \
ENV{ID_PATH}==pci-:00:14.1, SYMLINK+=dvd1, ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_MODEL}==ASUS_DRW-1814BL, \
ENV{ID_PATH}==pci-:00:14.1, SYMLINK+=dvdrw, ENV{GENERATED}=1
Aside from the problem I had with the old IDE driver layer not
distinguishing the two drives properly (both matching ID_PATH of
0:0:14.1, forcing me to distinguish using ID_MODEL), my purposing in
posting this is to show that -- on my machine, at least -- it is
possible to have two different sets of rules that deliver the same symlinks.
(OTOH, a recent upgrade from udev 149-1 to 149-2 caused a complete
disconnection of inputs, so I had to downgrade back to 149-1. I doubt
that confusion here had anything to do with it, but now I have something
else to look into, at least. The machine doesn't roll over and die, so
I can still get in with 'ssh' and do the downgrade. Just haven't had
time to gather info and debug the issue yet.)
HTH,
Dave W.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
