Debian Bug report logs - #389881
SCSI device renaming breaks install

version graph

Package: partman-target; Maintainer for partman-target is Debian Install System Team <debian-boot@lists.debian.org>; Source for partman-target is src:partman-target.

Reported by: rmh@aybabtu.com

Date: Thu, 28 Sep 2006 09:03:08 UTC

Severity: normal

Tags: patch

Merged with 225802, 295134, 308565, 509378

Fixed in version partman-target/60

Done: Colin Watson <cjwatson@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package debian-installer. Full text and rfc822 format available.

Acknowledgement sent to "Robert Millan [ackstorm]" <rmillan@ackstorm.es>:
New Bug report received and forwarded. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: submit@bugs.debian.org
Subject: SCSI device renaming breaks install
Date: Thu, 28 Sep 2006 10:41:31 +0200
Package: debian-installer
Severity: grave

I'm sorry I can't provide the exact details (dmesg logs, etc) as the hardware I
was testing on died, but the breakage is as follows:

 - d-i Linux boots and detects USB ports using SCSI emulation.  They're mapped
   as /dev/sda and /dev/sdb.  Note: there's nothing attached to these ports.

 - After accessing the CD, d-i loads extra SCSI modules for the RAID that wasn't
   detected using the standard SCSI drivers.  It is detected and mapped as
   /dev/sdc.

 - Installation proceeds normaly using /dev/sdc.

 - After install we boot normaly, and then detection happens in a different
   order: /dev/sda is the SCSI RAID and /dev/sdb and /dev/sdc are USB drives.

 - System won't boot because /boot/grub/menu.lst and /etc/fstab point to the
   wrong paths.

I'm not sure what the right fix is.  Perhaps disabling the USB-SCSI emulation ?

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package debian-installer. Full text and rfc822 format available.

Acknowledgement sent to Frans Pop <elendil@planet.nl>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 389881@bugs.debian.org (full text, mbox):

From: Frans Pop <elendil@planet.nl>
To: 389881@bugs.debian.org, control@bugs.debian.org
Cc: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
Subject: Re: Bug#389881: SCSI device renaming breaks install
Date: Thu, 28 Sep 2006 11:50:23 +0200
severity 389881 normal
thanks

This is a known issue listed in the errata. It is also fairly easy to 
repair by editing /etc/fstab and changing grub's menu.list using the 
installer's rescue mode.

Yes, it is an important issue, but certainly not 'grave'.



Severity set to `normal' from `grave' Request was from Frans Pop <elendil@planet.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package debian-installer. Full text and rfc822 format available.

Acknowledgement sent to "Robert Millan [ackstorm]" <rmillan@ackstorm.es>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #17 received at 389881@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: Frans Pop <elendil@planet.nl>
Cc: 389881@bugs.debian.org
Subject: Re: Bug#389881: SCSI device renaming breaks install
Date: Thu, 28 Sep 2006 12:36:00 +0200
On Thu, Sep 28, 2006 at 11:50:23AM +0200, Frans Pop wrote:
> severity 389881 normal
> thanks
> 
> This is a known issue listed in the errata.

Oops.  Sorry I should have checked better.

> It is also fairly easy to 
> repair by editing /etc/fstab and changing grub's menu.list using the 
> installer's rescue mode.

It is when you know the problem.  Currently user just sees that Linux boots
and then some part of the initrd scripts sit there and hang.  It is diffitult to
figure out (unless you had this issue before).

> Yes, it is an important issue, but certainly not 'grave'.

As you like.

thanks,

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package debian-installer. Full text and rfc822 format available.

Acknowledgement sent to Stephen Gran <sgran@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #22 received at 389881@bugs.debian.org (full text, mbox):

From: Stephen Gran <sgran@debian.org>
To: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, 389881@bugs.debian.org
Subject: Re: Bug#389881: SCSI device renaming breaks install
Date: Thu, 28 Sep 2006 11:50:05 +0100
[Message part 1 (text/plain, inline)]
This one time, at band camp, Robert Millan [ackstorm] said:
> Package: debian-installer
> Severity: grave
> 
> I'm sorry I can't provide the exact details (dmesg logs, etc) as the hardware I
> was testing on died, but the breakage is as follows:
> 
>  - d-i Linux boots and detects USB ports using SCSI emulation.  They're mapped
>    as /dev/sda and /dev/sdb.  Note: there's nothing attached to these ports.
> 
>  - After accessing the CD, d-i loads extra SCSI modules for the RAID that wasn't
>    detected using the standard SCSI drivers.  It is detected and mapped as
>    /dev/sdc.
> 
>  - Installation proceeds normaly using /dev/sdc.
> 
>  - After install we boot normaly, and then detection happens in a different
>    order: /dev/sda is the SCSI RAID and /dev/sdb and /dev/sdc are USB drives.
> 
>  - System won't boot because /boot/grub/menu.lst and /etc/fstab point to the
>    wrong paths.
> 
> I'm not sure what the right fix is.  Perhaps disabling the USB-SCSI emulation ?

Either use udev rules to map the RAID array to a consistent device name,
or use filesystem labels in fstab and menu.lst.
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package debian-installer. Full text and rfc822 format available.

Acknowledgement sent to Rick Thomas <rbthomas55@pobox.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #27 received at 389881@bugs.debian.org (full text, mbox):

From: Rick Thomas <rbthomas55@pobox.com>
To: 389881@bugs.debian.org
Subject: Re: Bug#389881: SCSI device renaming breaks install
Date: Thu, 28 Sep 2006 14:46:29 -0400
On Sep 28, 2006, at 6:50 AM, Stephen Gran wrote:

>
> Either use udev rules to map the RAID array to a consistent device  
> name,
> or use filesystem labels in fstab and menu.lst.


Which is great if you know about the problem and can deal with it in  
advance.  Just because it's listed in the errata is not an excuse for  
not fixing the problem.   Is it possible to generalize the fix that  
worked for network interfaces to also deal with disk drives?

It's definitely a case where the Debian Installer does not "just work".

Rick




Bug reassigned from package `debian-installer' to `hw-detect'. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Message #32 received at 389881@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: 389881@bugs.debian.org
Cc: debian-release@lists.debian.org, udev@packages.debian.org
Subject: RC-ness of this bug
Date: Tue, 6 Mar 2007 11:34:40 +0100
Hi,

I urge you to reconsider severity of this problem.  There's another situation
that makes it much worse:

  - User boots off USB stick
  - sda is USB, sdb is SCSI or SATA
  - GRUB install on (hd0) (i.e. sda) fails.
  - Manual repairing is not possible, because if you boot a rescue system
    off USB stick, root disk will still be sdb.

This makes USB sticks unusable for any computer using SATA or SCSI (i.e.,
almost every modern x86).  I would rather not ship any USB images at all
than shipping them in this state.

As for finding a solution, I'm not sure what can be done.  Perhaps d-i could
tell udev in some way that device node names need to be reordered, right
after disks have been detected ?

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #37 received at 389881@bugs.debian.org (full text, mbox):

From: md@Linux.IT (Marco d'Itri)
To: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
Cc: 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: RC-ness of this bug
Date: Tue, 6 Mar 2007 13:15:23 +0100
[Message part 1 (text/plain, inline)]
On Mar 06, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:

> I urge you to reconsider severity of this problem.  There's another situation
> that makes it much worse:
The correct solution is to make d-i use labels in fstab and to find the
root file system. udev has not much to do with this.

-- 
ciao,
Marco
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Otavio Salvador <otavio@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #42 received at 389881@bugs.debian.org (full text, mbox):

From: Otavio Salvador <otavio@debian.org>
To: md@Linux.IT
Cc: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Tue, 06 Mar 2007 09:44:31 -0300
md@Linux.IT (Marco d'Itri) writes:

> On Mar 06, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:
>
>> I urge you to reconsider severity of this problem.  There's another situation
>> that makes it much worse:
> The correct solution is to make d-i use labels in fstab and to find the
> root file system. udev has not much to do with this.

I think it's too late for that kind of change on d-i side. This "right
solution" looks to be post-Etch material to me.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Mike Hommey <mh@glandium.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #47 received at 389881@bugs.debian.org (full text, mbox):

From: Mike Hommey <mh@glandium.org>
To: md@Linux.IT, "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: RC-ness of this bug
Date: Tue, 6 Mar 2007 16:41:19 +0100
On Tue, Mar 06, 2007 at 01:15:23PM +0100, Marco d'Itri wrote:
> On Mar 06, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:
> 
> > I urge you to reconsider severity of this problem.  There's another situation
> > that makes it much worse:
> The correct solution is to make d-i use labels in fstab and to find the
> root file system. udev has not much to do with this.

Which will enable a whole lot of other broken setups. Even uuids would be
better to use, though I'm not sure all filesystem types expose one (ditto
for labels, actually).

Mike



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to "peter green" <plugwash@P10Link.net>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #52 received at 389881@bugs.debian.org (full text, mbox):

From: "peter green" <plugwash@P10Link.net>
To: "Mike Hommey" <mh@glandium.org>, <389881@bugs.debian.org>
Subject: RE: Bug#389881: RC-ness of this bug
Date: Tue, 6 Mar 2007 18:47:03 -0000
> > > I urge you to reconsider severity of this problem.  There's 
> another situation
> > > that makes it much worse:
> > The correct solution is to make d-i use labels in fstab and to find the
> > root file system. udev has not much to do with this.
> 
> Which will enable a whole lot of other broken setups. Even uuids would be
> better to use, though I'm not sure all filesystem types expose one (ditto
> for labels, actually).
isn't udev supposed to provide persistant device naming avoiding this problem?




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Message #55 received at 389881@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: Mike Hommey <mh@glandium.org>
Cc: md@Linux.IT, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: RC-ness of this bug
Date: Wed, 7 Mar 2007 11:12:53 +0100
On Tue, Mar 06, 2007 at 04:41:19PM +0100, Mike Hommey wrote:
> On Tue, Mar 06, 2007 at 01:15:23PM +0100, Marco d'Itri wrote:
> > On Mar 06, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:
> > 
> > > I urge you to reconsider severity of this problem.  There's another situation
> > > that makes it much worse:
> > The correct solution is to make d-i use labels in fstab and to find the
> > root file system. udev has not much to do with this.
> 
> Which will enable a whole lot of other broken setups. Even uuids would be
> better to use, though I'm not sure all filesystem types expose one (ditto
> for labels, actually).

Labels are not well tested and a source of problems indeed.

Can't we just give a different namespace to USB sticks than /dev/sd[a-z] ?

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Message #58 received at 389881@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: Otavio Salvador <otavio@debian.org>
Cc: md@Linux.IT, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 7 Mar 2007 11:11:09 +0100
On Tue, Mar 06, 2007 at 09:44:31AM -0300, Otavio Salvador wrote:
> md@Linux.IT (Marco d'Itri) writes:
> 
> > On Mar 06, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:
> >
> >> I urge you to reconsider severity of this problem.  There's another situation
> >> that makes it much worse:
> > The correct solution is to make d-i use labels in fstab and to find the
> > root file system. udev has not much to do with this.
> 
> I think it's too late for that kind of change on d-i side. This "right
> solution" looks to be post-Etch material to me.

Then we should remove the USB images from the release.  They're utterly broken
and only work on old hardware.  It'd be a shame if we label this as "stable".

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #63 received at 389881@bugs.debian.org (full text, mbox):

From: md@Linux.IT (Marco d'Itri)
To: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
Cc: Mike Hommey <mh@glandium.org>, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: RC-ness of this bug
Date: Wed, 7 Mar 2007 12:05:09 +0100
[Message part 1 (text/plain, inline)]
On Mar 07, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:

> Labels are not well tested and a source of problems indeed.
The /dev/disk/by-*/ devices are well tested and I do not know about
problems posed by them.

-- 
ciao,
Marco
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to "peter green" <plugwash@P10Link.net>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #68 received at 389881@bugs.debian.org (full text, mbox):

From: "peter green" <plugwash@P10Link.net>
To: "Marco d'Itri" <md@Linux.IT>, <389881@bugs.debian.org>
Subject: RE: Bug#389881: RC-ness of this bug
Date: Wed, 7 Mar 2007 12:17:31 -0000

> -----Original Message-----
> From: Marco d'Itri [mailto:md@Linux.IT]
> Sent: 07 March 2007 11:05
> To: Robert Millan [ackstorm]
> Cc: Mike Hommey; 389881@bugs.debian.org; debian-release@lists.debian.org
> Subject: Bug#389881: RC-ness of this bug
> 
> 
> On Mar 07, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:
> 
> > Labels are not well tested and a source of problems indeed.
> The /dev/disk/by-*/ devices are well tested and I do not know about
> problems posed by them.
but if we are going to use those which set should we use?

by-path seems like a reasonable choice though it will break if users move anything (but then so would the old system in many cases)

by-id seems to use the make/model of the drive and maybe some unique id of the drive, 

by-uuid contains my two ext3 partitions but not my swap partition, it also seems like it may be vulnerable to becoming confused.

maybe an answer would be to use by-path if drives are presenent on multiple controllers during installation and use conventional names otherwise (possiblly with a way to override this behaviour for experts).





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Message #71 received at 389881@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: md@Linux.IT, Mike Hommey <mh@glandium.org>, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: RC-ness of this bug
Date: Wed, 7 Mar 2007 13:26:47 +0100
On Wed, Mar 07, 2007 at 12:05:09PM +0100, Marco d'Itri wrote:
> On Mar 07, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:
> 
> > Labels are not well tested and a source of problems indeed.
> The /dev/disk/by-*/ devices are well tested and I do not know about
> problems posed by them.

I thought we were talking about fstab device labels.  fsck doesn't seem to
work well with them.

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #76 received at 389881@bugs.debian.org (full text, mbox):

From: md@Linux.IT (Marco d'Itri)
To: peter green <plugwash@P10Link.net>
Cc: 389881@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 7 Mar 2007 13:28:33 +0100
[Message part 1 (text/plain, inline)]
On Mar 07, peter green <plugwash@P10Link.net> wrote:

> by-uuid contains my two ext3 partitions but not my swap partition, it also seems like it may be vulnerable to becoming confused.

Only if the admin is a moron and keeps around multiple file systems
cloned with dd.

-- 
ciao,
Marco
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Otavio Salvador <otavio@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #81 received at 389881@bugs.debian.org (full text, mbox):

From: Otavio Salvador <otavio@debian.org>
To: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
Cc: md@Linux.IT, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 07 Mar 2007 09:33:47 -0300
"Robert Millan [ackstorm]" <rmillan@ackstorm.es> writes:

> On Tue, Mar 06, 2007 at 09:44:31AM -0300, Otavio Salvador wrote:
>> md@Linux.IT (Marco d'Itri) writes:
>> 
>> > On Mar 06, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:
>> >
>> >> I urge you to reconsider severity of this problem.  There's another situation
>> >> that makes it much worse:
>> > The correct solution is to make d-i use labels in fstab and to find the
>> > root file system. udev has not much to do with this.
>> 
>> I think it's too late for that kind of change on d-i side. This "right
>> solution" looks to be post-Etch material to me.
>
> Then we should remove the USB images from the release.  They're utterly broken
> and only work on old hardware.  It'd be a shame if we label this as "stable".

There's no workaround for the issue?

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Mike Hommey <mh@glandium.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #86 received at 389881@bugs.debian.org (full text, mbox):

From: Mike Hommey <mh@glandium.org>
To: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
Cc: md@Linux.IT, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: RC-ness of this bug
Date: Wed, 7 Mar 2007 13:40:58 +0100
On Wed, Mar 07, 2007 at 01:26:47PM +0100, Robert Millan [ackstorm] wrote:
> On Wed, Mar 07, 2007 at 12:05:09PM +0100, Marco d'Itri wrote:
> > On Mar 07, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:
> > 
> > > Labels are not well tested and a source of problems indeed.
> > The /dev/disk/by-*/ devices are well tested and I do not know about
> > problems posed by them.
> 
> I thought we were talking about fstab device labels.  fsck doesn't seem to
> work well with them.

I don't know what /dev/disk/by-* do with name collisions, but the result is
pretty much everything but what you would expect with the LABEL= syntax
(i.e. when libblkid is used). Name collisions on labels are really not
unlikely.

Mike



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Message #89 received at 389881@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: Otavio Salvador <otavio@debian.org>
Cc: md@Linux.IT, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 7 Mar 2007 13:48:18 +0100
On Wed, Mar 07, 2007 at 09:33:47AM -0300, Otavio Salvador wrote:
> "Robert Millan [ackstorm]" <rmillan@ackstorm.es> writes:
> 
> > On Tue, Mar 06, 2007 at 09:44:31AM -0300, Otavio Salvador wrote:
> >> md@Linux.IT (Marco d'Itri) writes:
> >> 
> >> > On Mar 06, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:
> >> >
> >> >> I urge you to reconsider severity of this problem.  There's another situation
> >> >> that makes it much worse:
> >> > The correct solution is to make d-i use labels in fstab and to find the
> >> > root file system. udev has not much to do with this.
> >> 
> >> I think it's too late for that kind of change on d-i side. This "right
> >> solution" looks to be post-Etch material to me.
> >
> > Then we should remove the USB images from the release.  They're utterly broken
> > and only work on old hardware.  It'd be a shame if we label this as "stable".
> 
> There's no workaround for the issue?

With USB, you can't just boot a rescue system and repair a broken install
from there, because /dev/sda will still be your USB drive.

Of course, there are lots of hacks you can do to workaround that, but if
we go this way, why bother using d-i anyway ?  I could just boot from USB
and run debootstrap by hand.

If we remove USB sticks from etch, then at least people will know they're
broken and switch to CDs (or use the dailies).

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to "peter green" <plugwash@P10Link.net>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #94 received at 389881@bugs.debian.org (full text, mbox):

From: "peter green" <plugwash@P10Link.net>
To: "Marco d'Itri" <md@Linux.IT>, <389881@bugs.debian.org>
Subject: RE: Bug#389881: RC-ness of this bug
Date: Wed, 7 Mar 2007 12:53:06 -0000
> > by-uuid contains my two ext3 partitions but not my swap 
> partition, it also seems like it may be vulnerable to becoming confused.
> 
> Only if the admin is a moron and keeps around multiple file systems
> cloned with dd.
are you calling it moronic to make a backup of a partition by dding to to a spare one? since this was a perfectly workable system of backup under the conventional way of doing things i'd call that pretty unexpected breakage.

the fact it doesn't seem to work for all partition types would seem to rule it out anyway.





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Otavio Salvador <otavio@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #99 received at 389881@bugs.debian.org (full text, mbox):

From: Otavio Salvador <otavio@debian.org>
To: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
Cc: md@Linux.IT, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 07 Mar 2007 09:55:45 -0300
"Robert Millan [ackstorm]" <rmillan@ackstorm.es> writes:

> On Wed, Mar 07, 2007 at 09:33:47AM -0300, Otavio Salvador wrote:
>> "Robert Millan [ackstorm]" <rmillan@ackstorm.es> writes:
>> 
>> > On Tue, Mar 06, 2007 at 09:44:31AM -0300, Otavio Salvador wrote:
>> >> md@Linux.IT (Marco d'Itri) writes:
>> >> 
>> >> > On Mar 06, "Robert Millan [ackstorm]" <rmillan@ackstorm.es> wrote:
>> >> >
>> >> >> I urge you to reconsider severity of this problem.  There's another situation
>> >> >> that makes it much worse:
>> >> > The correct solution is to make d-i use labels in fstab and to find the
>> >> > root file system. udev has not much to do with this.
>> >> 
>> >> I think it's too late for that kind of change on d-i side. This "right
>> >> solution" looks to be post-Etch material to me.
>> >
>> > Then we should remove the USB images from the release.  They're utterly broken
>> > and only work on old hardware.  It'd be a shame if we label this as "stable".
>> 
>> There's no workaround for the issue?
>
> With USB, you can't just boot a rescue system and repair a broken install
> from there, because /dev/sda will still be your USB drive.
>
> Of course, there are lots of hacks you can do to workaround that, but if
> we go this way, why bother using d-i anyway ?  I could just boot from USB
> and run debootstrap by hand.
>
> If we remove USB sticks from etch, then at least people will know they're
> broken and switch to CDs (or use the dailies).

I don't know how invasive those changes might be. AFAIK Ubuntu already
does it (Colin?) and wouldn't be too hard to pick the changes from
them but we would also need RM and Frans approval :(

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Otavio Salvador <otavio@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #104 received at 389881@bugs.debian.org (full text, mbox):

From: Otavio Salvador <otavio@debian.org>
To: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
Cc: md@Linux.IT, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 07 Mar 2007 10:08:43 -0300
"Robert Millan [ackstorm]" <rmillan@ackstorm.es> writes:

> On Wed, Mar 07, 2007 at 09:55:45AM -0300, Otavio Salvador wrote:
>> >
>> > With USB, you can't just boot a rescue system and repair a broken install
>> > from there, because /dev/sda will still be your USB drive.
>> >
>> > Of course, there are lots of hacks you can do to workaround that, but if
>> > we go this way, why bother using d-i anyway ?  I could just boot from USB
>> > and run debootstrap by hand.
>> >
>> > If we remove USB sticks from etch, then at least people will know they're
>> > broken and switch to CDs (or use the dailies).
>> 
>> I don't know how invasive those changes might be. AFAIK Ubuntu already
>> does it (Colin?) and wouldn't be too hard to pick the changes from
>> them but we would also need RM and Frans approval :(
>
> I thought you were talking about user workarounds.

Yes I was but when I saw that there's no easy workarounds I thought
would be possible to try to resolve it "the right way".

> Well, Ubuntu uses fstab labels, and they seem to be quite unstable (my
> first experience with them resulted in fsck interrupting boot, leaving you
> with a root shell).  I wouldn't recommend using them (even if we have to drop
> support for USB boot).

Humm, that's _ugly_ :(

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Message #107 received at 389881@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: Otavio Salvador <otavio@debian.org>
Cc: md@Linux.IT, 389881@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 7 Mar 2007 14:03:35 +0100
On Wed, Mar 07, 2007 at 09:55:45AM -0300, Otavio Salvador wrote:
> >
> > With USB, you can't just boot a rescue system and repair a broken install
> > from there, because /dev/sda will still be your USB drive.
> >
> > Of course, there are lots of hacks you can do to workaround that, but if
> > we go this way, why bother using d-i anyway ?  I could just boot from USB
> > and run debootstrap by hand.
> >
> > If we remove USB sticks from etch, then at least people will know they're
> > broken and switch to CDs (or use the dailies).
> 
> I don't know how invasive those changes might be. AFAIK Ubuntu already
> does it (Colin?) and wouldn't be too hard to pick the changes from
> them but we would also need RM and Frans approval :(

I thought you were talking about user workarounds.

Well, Ubuntu uses fstab labels, and they seem to be quite unstable (my
first experience with them resulted in fsck interrupting boot, leaving you
with a root shell).  I wouldn't recommend using them (even if we have to drop
support for USB boot).

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to "peter green" <plugwash@P10Link.net>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #112 received at 389881@bugs.debian.org (full text, mbox):

From: "peter green" <plugwash@P10Link.net>
To: "Otavio Salvador" <otavio@debian.org>, <389881@bugs.debian.org>
Subject: RE: Bug#389881: RC-ness of this bug
Date: Wed, 7 Mar 2007 13:23:28 -0000
> I don't know how invasive those changes might be. AFAIK Ubuntu already
> does it (Colin?) and wouldn't be too hard to pick the changes from
> them but we would also need RM and Frans approval :(
ubuntu already does what? there are four possible soloutions proposed aren't there (labels in fstab and the 3 different /dev/by-* trees)




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Otavio Salvador <otavio@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #117 received at 389881@bugs.debian.org (full text, mbox):

From: Otavio Salvador <otavio@debian.org>
To: peter green <plugwash@P10Link.net>
Cc: <389881@bugs.debian.org>
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 07 Mar 2007 10:50:46 -0300
"peter green" <plugwash@P10Link.net> writes:

>> I don't know how invasive those changes might be. AFAIK Ubuntu already
>> does it (Colin?) and wouldn't be too hard to pick the changes from
>> them but we would also need RM and Frans approval :(

> ubuntu already does what? there are four possible soloutions
> proposed aren't there (labels in fstab and the 3 different /dev/by-*
> trees)

labels on fstab IIRC.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #122 received at 389881@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: "Otavio Salvador" <otavio@debian.org>, 389881@bugs.debian.org
Cc: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, md@linux.it, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 7 Mar 2007 15:18:19 +0100 (CET)
On Wed, March 7, 2007 13:55, Otavio Salvador said:
> I don't know how invasive those changes might be. AFAIK Ubuntu already
> does it (Colin?) and wouldn't be too hard to pick the changes from
> them but we would also need RM and Frans approval :(

initramfs-tools already supports using /dev/disk/by-* entries in fstab. As
for the installer, I'm not sure that looking at Ubuntu will help since
they use something different than d-i for the regular installs (and I
don't know if their d-i based installer has any
mount-by-label/uuid/whatever fixes).

It would be pretty simple to implement as a late_command script though,
quick pseudo-code:

---

for each line in /target/etc/fstab; do
  read device mountpoint fs options dump order
  if $device matches regex ^/dev/[sh]da[[:digit:]]*$; then
    for each link in /dev/disk/by-id/*; do
      if $(readlink "$link") == $device; then
        device=$link
        break
      fi
    done
  fi

  echo "$device $mountpoint $fs $options $dump $order" \
    >> /target/etc/fstab.tmp
done
mv /target/etc/fstab.tmp /target/etc/fstab
in-target update-initramfs -u

---

I doubt something like this would be accepted though since it would be
hard to get sufficient testing for such a large change so late in the
game...

-- 
David Härdeman




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #127 received at 389881@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@ubuntu.com>
To: Otavio Salvador <otavio@debian.org>, 389881@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 7 Mar 2007 08:39:31 -0800
On Wed, Mar 07, 2007 at 10:50:46AM -0300, Otavio Salvador wrote:
> "peter green" <plugwash@P10Link.net> writes:
> 
> >> I don't know how invasive those changes might be. AFAIK Ubuntu already
> >> does it (Colin?) and wouldn't be too hard to pick the changes from
> >> them but we would also need RM and Frans approval :(
> 
> > ubuntu already does what? there are four possible soloutions
> > proposed aren't there (labels in fstab and the 3 different /dev/by-*
> > trees)
> 
> labels on fstab IIRC.

Ubuntu uses mount by UUID, not labels.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #132 received at 389881@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
Cc: 389881@bugs.debian.org, debian-release@lists.debian.org, udev@packages.debian.org
Subject: Re: RC-ness of this bug
Date: Wed, 7 Mar 2007 12:28:09 -0500
[Message part 1 (text/plain, inline)]
Robert Millan [ackstorm] wrote:
> I urge you to reconsider severity of this problem.  There's another situation
> that makes it much worse:
> 
>   - User boots off USB stick
>   - sda is USB, sdb is SCSI or SATA
>   - GRUB install on (hd0) (i.e. sda) fails.
>   - Manual repairing is not possible, because if you boot a rescue system
>     off USB stick, root disk will still be sdb.

Is this theoretical with SATA, or have you reproduced it?

The usb sticks include sata-modules as well as usb-modules, so AFAICS,
hardware detection should happen in the same order when booting from the
usb stick as booting from eg, netboot.

And I don't understand your report about problems with SCSI either,
since the USB stick also includes all SCSI modules.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Mike Hommey <mh@glandium.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #137 received at 389881@bugs.debian.org (full text, mbox):

From: Mike Hommey <mh@glandium.org>
To: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, 389881@bugs.debian.org, debian-release@lists.debian.org, udev@packages.debian.org
Subject: Re: RC-ness of this bug
Date: Wed, 7 Mar 2007 19:34:14 +0100
On Wed, Mar 07, 2007 at 12:28:09PM -0500, Joey Hess <joeyh@debian.org> wrote:
> Robert Millan [ackstorm] wrote:
> > I urge you to reconsider severity of this problem.  There's another situation
> > that makes it much worse:
> > 
> >   - User boots off USB stick
> >   - sda is USB, sdb is SCSI or SATA
> >   - GRUB install on (hd0) (i.e. sda) fails.
> >   - Manual repairing is not possible, because if you boot a rescue system
> >     off USB stick, root disk will still be sdb.
> 
> Is this theoretical with SATA, or have you reproduced it?
> 
> The usb sticks include sata-modules as well as usb-modules, so AFAICS,
> hardware detection should happen in the same order when booting from the
> usb stick as booting from eg, netboot.
> 
> And I don't understand your report about problems with SCSI either,
> since the USB stick also includes all SCSI modules.

It sound pretty simple, in netboot case, there is no usb stick to take
sda...

Mike




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #142 received at 389881@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: Otavio Salvador <otavio@debian.org>, 389881@bugs.debian.org
Cc: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, md@linux.it, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 08 Mar 2007 00:44:05 +0100
[Message part 1 (text/plain, inline)]
On Wed, Mar 07, 2007 at 03:18:19PM +0100, David Härdeman wrote:
>On Wed, March 7, 2007 13:55, Otavio Salvador said:
>> I don't know how invasive those changes might be. AFAIK Ubuntu already
>> does it (Colin?) and wouldn't be too hard to pick the changes from
>> them but we would also need RM and Frans approval :(
>
>initramfs-tools already supports using /dev/disk/by-* entries in fstab. As
>for the installer, I'm not sure that looking at Ubuntu will help since
>they use something different than d-i for the regular installs (and I
>don't know if their d-i based installer has any
>mount-by-label/uuid/whatever fixes).
>
>It would be pretty simple to implement as a late_command script though,
>quick pseudo-code:
>...

I've attached a patch which implements persistent device names in 
partman by checking for devices which are mounted under /target and 
which have a suitable link in /dev/disk/by-id/*

For each device that is found, /target/etc/fstab is modified 
appropriately.

I've done one test install using the patch and it sucessfully changed 
/dev/sda1 to /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 in 
/target/etc/fstab, it's currenlty busy installing the base system.

I believe this patch would fix #225802, #295134, #308565, #389881

-- 
David Härdeman

[partman-use-persistent-device-nodes.patch (text/x-diff, inline)]
Index: debian/changelog
===================================================================
--- debian/changelog	(revision 45633)
+++ debian/changelog	(working copy)
@@ -1,3 +1,10 @@
+partman-target (49) UNRELEASED; urgency=low
+
+  * Add script to use persistent device nodes in /etc/fstab where
+    possible
+
+ -- David Härdeman <david@hardeman.nu>  Thu,  8 Mar 2007 00:17:24 +0100
+
 partman-target (48) unstable; urgency=low
 
   [ Updated translations ]
Index: finish.d/fstab_persistent
===================================================================
--- finish.d/fstab_persistent	(revision 0)
+++ finish.d/fstab_persistent	(revision 0)
@@ -0,0 +1,47 @@
+#!/bin/sh
+
+[ -f /target/etc/fstab ] || exit 0
+fstab=$(
+	cat /target/etc/fstab |
+	while read line; do
+		# Make sure this is a proper entry
+		if echo "$line" | grep -q "^[[:space:]]*$\|^#"; then
+			echo "$line"
+			continue
+		fi
+
+		# Parse entry
+		echo -n "$line" > /tmp/partman-target
+		read fs mp type options dump pass < /tmp/partman-target
+		rm -f /tmp/partman-target
+
+		# Ignore devices not mounted under /target
+		if [ "$mp" = "/" ]; then
+			tmpmp="/target"
+		else
+			tmpmp="/target$mp"
+		fi
+		if ! grep -q " $tmpmp " /proc/mounts; then
+			echo "$line"
+			continue
+		fi
+
+		# See if we can find a persistent device name
+		for link in /dev/disk/by-id/*; do
+			linktarget=$(mapdevfs $(readlink -f "$link"))
+			if [ "$linktarget" = "$fs" ]; then
+				break
+			fi
+			linktarget=
+		done
+		if [ -z "$linktarget" ]; then
+			echo "$line"
+			continue
+		fi
+
+		printf "%-15s %-15s %-7s %-15s %-7s %s\n" "${link}" "${mp}" "$type" "$options" "$dump" "$pass"
+	done
+)
+
+echo "$fstab" > /target/etc/fstab
+exit 0

Property changes on: finish.d/fstab_persistent
___________________________________________________________________
Name: svn:executable
   + *

Index: finish.d/_numbers
===================================================================
--- finish.d/_numbers	(revision 45633)
+++ finish.d/_numbers	(working copy)
@@ -4,3 +4,4 @@
 40 fstab_hd_entries
 50 fstab_removable_media_entries
 95 reformat_after_restart
+98 fstab_persistent


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #147 received at 389881@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Otavio Salvador <otavio@debian.org>, 389881@bugs.debian.org, "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, md@linux.it, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 7 Mar 2007 16:09:48 -0800
On Thu, Mar 08, 2007 at 12:44:05AM +0100, David Härdeman wrote:
> >initramfs-tools already supports using /dev/disk/by-* entries in fstab. As
> >for the installer, I'm not sure that looking at Ubuntu will help since
> >they use something different than d-i for the regular installs (and I
> >don't know if their d-i based installer has any
> >mount-by-label/uuid/whatever fixes).

> >It would be pretty simple to implement as a late_command script though,
> >quick pseudo-code:
> >...

> I've attached a patch which implements persistent device names in 
> partman by checking for devices which are mounted under /target and 
> which have a suitable link in /dev/disk/by-id/*

> For each device that is found, /target/etc/fstab is modified 
> appropriately.

Thanks for the patch, David.

I don't believe this should be changed for etch at this point in the release
process, and that's speaking as someone who's run into this problem myself
with SCSI device renumbering -- it's awkward and annoying to have to
manually fiddle your boot config because a USB device is no longer
registering as /dev/sda, and it's not in line with the quality of experience
that our users have come to expect when installing Debian >:), but I don't
think that makes anything unreleasable.  Changing the fstab handling at this
point could break many other scenarios that we haven't thought of and tested
for, whereas the USB issue can be documented in the errata.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to "peter green" <plugwash@P10Link.net>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #152 received at 389881@bugs.debian.org (full text, mbox):

From: "peter green" <plugwash@P10Link.net>
To: "Steve Langasek" <vorlon@debian.org>, <389881@bugs.debian.org>
Subject: RE: Bug#389881: RC-ness of this bug
Date: Thu, 8 Mar 2007 00:45:12 -0000
> I don't believe this should be changed for etch at this point in 
> the release
> process, and that's speaking as someone who's run into this problem myself
> with SCSI device renumbering -- it's awkward and annoying to have to
> manually fiddle your boot config because a USB device is no longer
> registering as /dev/sda, and it's not in line with the quality of 
> experience
> that our users have come to expect when installing Debian >:), but I don't
> think that makes anything unreleasable.  Changing the fstab 
> handling at this
> point could break many other scenarios that we haven't thought of 
> and tested
> for, whereas the USB issue can be documented in the errata.
what about writing out a /etc/fstab.by-id file with the header below 
followed by a copy of thier normal fstab changed to use the 
/dev/disk/by-id/ syntax? that way we could instruct newbies who run 
into this problem to just boot in rescue mode and run 
"cp /etc/fstab.by-id /etc/fstab". that seems to be much simpler to
explain to people than a manual fixup whilst not risking breakage 
for anyone who doesn't run into the device rearangement problem.

header for /etc/fstab.by-id

# /etc/fstab.by-id
#
# This file was generated by the debian installer. It represents the same 
# partition structure as the /etc/fstab that the installer generated but 
# references disks by thier "id" rather than by thier traditional unix names
# which are prone to change on first boot after installation or on changing 
# hardware. 
#
# This structure is not used by default for etch installations (but probablly 
# will be for lenny) because of the possibility of regressions from such a 
# major change late in the release process. If you wish to use it and have not
# modified /etc/fstab after installation you may copy this file to "/etc/fstab"
#




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package hw-detect. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #157 received at 389881@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: Otavio Salvador <otavio@debian.org>, 389881@bugs.debian.org, "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, md@linux.it, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 08 Mar 2007 02:06:51 +0100
On Wed, Mar 07, 2007 at 04:09:48PM -0800, Steve Langasek wrote:
>On Thu, Mar 08, 2007 at 12:44:05AM +0100, David Härdeman wrote:
>> I've attached a patch which implements persistent device names in 
>> partman by checking for devices which are mounted under /target and 
>> which have a suitable link in /dev/disk/by-id/*
>
>> For each device that is found, /target/etc/fstab is modified 
>> appropriately.
>
>Thanks for the patch, David.
>
>I don't believe this should be changed for etch at this point in the release
>process, and that's speaking as someone who's run into this problem myself
>with SCSI device renumbering -- it's awkward and annoying to have to
>manually fiddle your boot config because a USB device is no longer
>registering as /dev/sda, and it's not in line with the quality of experience
>that our users have come to expect when installing Debian >:), but I don't
>think that makes anything unreleasable.  Changing the fstab handling at this
>point could break many other scenarios that we haven't thought of and tested
>for, whereas the USB issue can be documented in the errata.

Yes, I just finished the install under qemu, and it turns out that 
grub-installer (but not update-grub from the real grub package) breaks 
with /boot on /dev/disk/by-*/something. It creates kernel and initrd 
entries of the form /boot/something rather than /something.

-- 
David Härdeman




Bug reassigned from package `hw-detect' to `partman-target'. Request was from David Härdeman <david@hardeman.nu> to control@bugs.debian.org. Full text and rfc822 format available.

Forcibly Merged 225802 295134 308565 389881. Request was from David Härdeman <david@hardeman.nu> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: patch Request was from David Härdeman <david@hardeman.nu> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Message #166 received at 389881@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: Otavio Salvador <otavio@debian.org>, 389881@bugs.debian.org, md@linux.it, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 8 Mar 2007 10:06:09 +0100
On Wed, Mar 07, 2007 at 04:09:48PM -0800, Steve Langasek wrote:
> 
> I don't believe this should be changed for etch at this point in the release
> process, and that's speaking as someone who's run into this problem myself
> with SCSI device renumbering -- it's awkward and annoying to have to
> manually fiddle your boot config because a USB device is no longer
> registering as /dev/sda, and it's not in line with the quality of experience
> that our users have come to expect when installing Debian >:), but I don't
> think that makes anything unreleasable.  Changing the fstab handling at this
> point could break many other scenarios that we haven't thought of and tested
> for, whereas the USB issue can be documented in the errata.

If you're going to document it, don't forget to mention that in your repair
rescue boot you have to remove the stick quickly after initrd.gz is loaded
but before Linux has a chance to detect it.

If we're going that way, I would strongly recommend NOT to link the USB
images from the download pages.  They'll just make Debian look broken...

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Message #169 received at 389881@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: 389881@bugs.debian.org, debian-release@lists.debian.org, udev@packages.debian.org
Subject: Re: RC-ness of this bug
Date: Thu, 8 Mar 2007 10:10:29 +0100
On Wed, Mar 07, 2007 at 12:28:09PM -0500, Joey Hess wrote:
> 
> Is this theoretical with SATA, or have you reproduced it?

I've only reproduced it for SCSI.

> The usb sticks include sata-modules as well as usb-modules, so AFAICS,
> hardware detection should happen in the same order when booting from the
> usb stick as booting from eg, netboot.
> 
> And I don't understand your report about problems with SCSI either,
> since the USB stick also includes all SCSI modules.

USB is detected first, which takes /dev/sda.  Then SCSI is detected as
/dev/sdb.  All of this happens during boot.  I can send logs if you want.

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #174 received at 389881@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, 389881@bugs.debian.org
Cc: Otavio Salvador <otavio@debian.org>, md@Linux.IT, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 8 Mar 2007 11:16:01 +0000
On Wed, Mar 07, 2007 at 02:03:35PM +0100, Robert Millan [ackstorm] wrote:
> On Wed, Mar 07, 2007 at 09:55:45AM -0300, Otavio Salvador wrote:
> > I don't know how invasive those changes might be. AFAIK Ubuntu already
> > does it (Colin?) and wouldn't be too hard to pick the changes from
> > them but we would also need RM and Frans approval :(
> 
> I thought you were talking about user workarounds.
> 
> Well, Ubuntu uses fstab labels,

No, it uses UUIDs.

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #179 received at 389881@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Otavio Salvador <otavio@debian.org>, 389881@bugs.debian.org, "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, md@linux.it, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 8 Mar 2007 11:21:05 +0000
[Message part 1 (text/plain, inline)]
On Thu, Mar 08, 2007 at 12:44:05AM +0100, David Härdeman wrote:
> I've attached a patch which implements persistent device names in 
> partman by checking for devices which are mounted under /target and 
> which have a suitable link in /dev/disk/by-id/*

I've attached the Ubuntu patch for the same issue; it's been deployed
for some time and I think it's largely a cleaner approach than fixing it
up post-facto as your patch does. However, I tend to agree with Steve
that doing that at the last minute is risky; we had a fair few little
bits and pieces around the distribution to fix up, IIRC.

-- 
Colin Watson                                       [cjwatson@debian.org]
[partman-target.uuid.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #184 received at 389881@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Otavio Salvador <otavio@debian.org>, 389881@bugs.debian.org, "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, md@linux.it, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 8 Mar 2007 11:32:18 +0000
[Message part 1 (text/plain, inline)]
Oh, at least one additional thing that's likely needed in this scenario
is the attached patch to make busybox's mkswap generate UUIDs.

  * util-linux/mkswap.c: Set UUIDs on version 1 swap areas.
  * util-linux/Makefile.in: mkswap needs uuid/uuid.h from e2fsprogs.
  * e2fsprogs/Makefile.in: Build libuuid if building mkswap.

Ubuntu's volumeid.postinst also has some nasty code to add a UUID to
swap partitions that don't have one (due to busybox's mkswap not doing
this in the past). This was necessary because we were expecting to have
to change a lot of hard disk device names due to recent libata changes
in the kernel and forcibly moving over to UUIDs in /etc/fstab in advance
was the only way we could think of to prevent wholesale breakage.

UUIDs certainly have their disadvantages (verbosity being the main one),
but they're a hell of a lot better than labels for automatic use like
this. UUIDs are suitable for automatic generation while labels should
only be set by the sysadmin. The fiasco with Red Hat's installer setting
labels which can then end up conflicting with itself if you do multiple
parallel installs should demonstrate this (and some of the people
involved in Anaconda development said to me in person that in hindsight
this was probably a mistake). We've already backed away from automatic
use of labels once (http://bugs.debian.org/310754) so let's not have to
do so again!

-- 
Colin Watson                                       [cjwatson@debian.org]
[busybox.swap-uuid.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #189 received at 389881@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: "Colin Watson" <cjwatson@debian.org>
Cc: 389881@bugs.debian.org, 389881-submitter@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 8 Mar 2007 13:29:37 +0100 (CET)
I took the liberty of trimming the CC list since the details of a
persistent device node script would probably not interest everyone...

On Thu, March 8, 2007 12:21, Colin Watson said:
> On Thu, Mar 08, 2007 at 12:44:05AM +0100, David Härdeman wrote:
>> I've attached a patch which implements persistent device names in
>> partman by checking for devices which are mounted under /target and
>> which have a suitable link in /dev/disk/by-id/*
>
> I've attached the Ubuntu patch for the same issue; it's been deployed
> for some time and I think it's largely a cleaner approach than fixing it
> up post-facto as your patch does.

I considered doing the changes directly rather than as a post fixup, but I
opted not to for a couple of reasons:

You explicitly have to exclude some volumes, with my patch that decision
(i.e. which devices it is sane to have persistent device names for) is
left to udev.

It becomes much easier to switch between different kinds of persistent
device names with the standalone script. With the post-fix script, it
would be simple to support an argument such as "by-id" or "by-uuid" which
changed the type of symlinks that were used (then we could have that in a
priority "low" question so that the propellerheads can change it
themselves, experience so far seems to indicate that some people will
never be happy with the choice of persistent device names whether they are
based on label, uuid, id, path, etc).

At some point the future we're going to have to help users convert their
fstabs to persistent device names to avoid breakage (which I think is the
only argument that supported implementing persistent device names before
the release of Etch, although I think we'll have to live without it). One
such example will be the libata introduction (whether that will be during
the Etch -> Lenny upgrade or at some different point in time). If we have
one such standalone script, and use it both in the installer and in
upgrading older systems, it will receive much more testing.

Using "vol_id" directly rather than reading the symlinks, which would be
required if this is implemented in fstab_hd_entries, also has the
disadvantage that we'd need to duplicate the string conversions that udev
performs on the output from vol_id before it creates the device nodes.

And on a related note, one disadvantage of using "UUID=something" or
"LABEL=something" instead of /dev/disk/by-something/something is that the
former requires every script that will ever parse fstab to add code to
parse and handle "X=Y" (it would break cryptsetup and possibly other
boot-related scripts right now).

"X=Y" also makes it impossible to add new schemes without having to change
all related scripts to support the new values of "X" (we already have
by-path and by-id) while doing so is easy with the symlinks.

Phew, this came out a bit longer than expected :)

> However, I tend to agree with Steve
> that doing that at the last minute is risky; we had a fair few little
> bits and pieces around the distribution to fix up, IIRC.

I agree with Steve as well

-- 
David Härdeman




Message sent on to "Robert Millan [ackstorm]" <rmillan@ackstorm.es>:
Bug#389881. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #197 received at 389881@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: "Colin Watson" <cjwatson@debian.org>
Cc: 389881@bugs.debian.org, 389881-submitter@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 8 Mar 2007 13:33:18 +0100 (CET)
On Thu, March 8, 2007 12:32, Colin Watson said:
> UUIDs certainly have their disadvantages (verbosity being the main one),
> but they're a hell of a lot better than labels for automatic use like
> this. UUIDs are suitable for automatic generation while labels should
> only be set by the sysadmin. The fiasco with Red Hat's installer setting
> labels which can then end up conflicting with itself if you do multiple
> parallel installs should demonstrate this (and some of the people
> involved in Anaconda development said to me in person that in hindsight
> this was probably a mistake). We've already backed away from automatic
> use of labels once (http://bugs.debian.org/310754) so let's not have to
> do so again!

I agree. We had similar pains with the default naming of volume groups for
lvm installations, people will do multiple installs and the labels *will*
collide.

(And I find by-id even better than by-uuid since by-uuid still might break
due to careless admins doing whole-partition backups using dd.)

-- 
David Härdeman




Message sent on to "Robert Millan [ackstorm]" <rmillan@ackstorm.es>:
Bug#389881. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Otavio Salvador <otavio@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #205 received at 389881@bugs.debian.org (full text, mbox):

From: Otavio Salvador <otavio@debian.org>
To: 389881@bugs.debian.org
Cc: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>, md@linux.it, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 08 Mar 2007 09:55:25 -0300
Colin Watson <cjwatson@debian.org> writes:

> On Thu, Mar 08, 2007 at 12:44:05AM +0100, David Härdeman wrote:
>> I've attached a patch which implements persistent device names in 
>> partman by checking for devices which are mounted under /target and 
>> which have a suitable link in /dev/disk/by-id/*
>
> I've attached the Ubuntu patch for the same issue; it's been deployed
> for some time and I think it's largely a cleaner approach than fixing it
> up post-facto as your patch does. However, I tend to agree with Steve
> that doing that at the last minute is risky; we had a fair few little
> bits and pieces around the distribution to fix up, IIRC.

To full support it, another change would be need on Parted IIRC. You
reported the patch for it but I hadn't applied yet since we weren't
using it that time.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #210 received at 389881@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: "Otavio Salvador" <otavio@debian.org>
Cc: 389881@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 8 Mar 2007 14:03:24 +0100 (CET)
On Thu, March 8, 2007 13:55, Otavio Salvador said:
> To full support it, another change would be need on Parted IIRC. You
> reported the patch for it but I hadn't applied yet since we weren't
> using it that time.

Do you have a link? The fstab things should take place well after the
partitioning stage so I don't understand how parted would be affected?

-- 
David Härdeman




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Otavio Salvador <otavio@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #215 received at 389881@bugs.debian.org (full text, mbox):

From: Otavio Salvador <otavio@debian.org>
To: David Härdeman <david@hardeman.nu>
Cc: 389881@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 08 Mar 2007 10:07:27 -0300
David Härdeman <david@hardeman.nu> writes:

> On Thu, March 8, 2007 13:55, Otavio Salvador said:
>> To full support it, another change would be need on Parted IIRC. You
>> reported the patch for it but I hadn't applied yet since we weren't
>> using it that time.
>
> Do you have a link? The fstab things should take place well after the
> partitioning stage so I don't understand how parted would be affected?

To support UUID for swap.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to "peter green" <plugwash@P10Link.net>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #220 received at 389881@bugs.debian.org (full text, mbox):

From: "peter green" <plugwash@P10Link.net>
To: "Colin Watson" <cjwatson@debian.org>, <389881@bugs.debian.org>
Subject: RE: Bug#389881: RC-ness of this bug
Date: Thu, 8 Mar 2007 20:03:43 -0000
> UUIDs certainly have their disadvantages (verbosity being the main one),
> but they're a hell of a lot better than labels for automatic use like
> this. UUIDs are suitable for automatic generation while labels should
> only be set by the sysadmin. The fiasco with Red Hat's installer setting
> labels which can then end up conflicting with itself if you do multiple
> parallel installs should demonstrate this (and some of the people
> involved in Anaconda development said to me in person that in hindsight
> this was probably a mistake). We've already backed away from automatic
> use of labels once (http://bugs.debian.org/310754) so let's not have to
> do so again!
i'd still be happier with hardware IDs or paths than partition UUIDs, UUIDs seem very prone to things breaking on filesystem or disk cloning which is not something a *nix admin would expect to break stuff (unlike changing hardware)





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Message #223 received at 389881@bugs.debian.org (full text, mbox):

From: "Robert Millan [ackstorm]" <rmillan@ackstorm.es>
To: Otavio Salvador <otavio@debian.org>, 389881@bugs.debian.org, md@linux.it, debian-release@lists.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Fri, 9 Mar 2007 10:09:08 +0100
On Thu, Mar 08, 2007 at 11:21:05AM +0000, Colin Watson wrote:
> +		uuid="$(PATH="/lib/udev:$PATH" vol_id -u $fs)"
> +		if [ "$uuid" ]; then
> +		    printf "# %s\n" "$(mapdevfs $fs)"
> +		    printf "%-15s %-15s %-7s %-15s %-7s %s\n" "UUID=$uuid" "${mp}" "$type" "$options" "$dump" "$pass"

I've seen these UUID tags break fsck on edgy (after it was released as stable).
I don't think it's a good idea to switch to this in the last minute.

Besides, what's the point of fixing it at the fstab generation?  grub still
expects device ordering to be consistent (and doesn't rely on fstab for device
mapping).

If device ordering can't be made consistent, you can still workaround the
problem in device.map, but then you'll have to change it again post
grub-install or installed system's device.map will be broken.

-- 
Robert Millan

ACK STORM, S.L.  -  http://www.ackstorm.es/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Frans Pop <elendil@planet.nl>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #228 received at 389881@bugs.debian.org (full text, mbox):

From: Frans Pop <elendil@planet.nl>
To: 389881@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Tue, 13 Mar 2007 17:49:02 +0100
[Message part 1 (text/plain, inline)]
On Tuesday 06 March 2007 11:34, Robert Millan [ackstorm] wrote:
>   - User boots off USB stick
>   - sda is USB, sdb is SCSI or SATA
>   - GRUB install on (hd0) (i.e. sda) fails.
>   - Manual repairing is not possible, because if you boot a rescue
> system off USB stick, root disk will still be sdb.

I've just done a hd-media installation from USB-stick on my EM64t box 
(SATA disc controller) and everything worked out of the box [0]. Both 
grub and /etc/fstab were set up correctly [1].

I will not deny that users _can_ hit this issue, but it has been a known 
issue since Sarge. Unfortunately no one has yet been able to help us find 
a "good enough for Debian" solution for this.

To be honest, I'm a bit surprised that this is generating so much 
confusion at the moment. As I said, it is hardly a new issues and 
persistent device naming has been a topic on the list on and off for the 
past year.

Colin has said a few times that he consideres the Ubuntu solution not 
clean enough for Debian. David's script is nice (I've not looked at it in 
detail), but probably not fundamentally different from a similar script I 
proposed back in October [2].

Conclusion:
- no, I don't feel this issue makes hd-media unreleasable;
- yes, it would have been great if this was solved already;
- yes, it is definitely too late to solve this issue for Etch;
- yes, we should definitely document how people can fix a broken
  configuration (which is entirely possible) if they run into this issue;
- yes, we should find a solution for this post-etch and we should probably
  implement something ASAP so we have plenty of time to tune it.

Note that we need to find a solution that works for all architectures, for 
all file systems and for both permanent and removable media.

Personally I also feel that all possible solutions effectively make
/etc/fstab unreadable and unmaintainable. Maybe Debian should lead the way 
to make /etc/fstab a generated file (like e.g. modules.conf used to be).

Cheers,
FJP

[0] Which in some ways is a pity as I had planned to use the boot failure 
as a basis to document how to recover from it :-/
[1] Except for creating a completely bogus entry for the usb stick itself 
using the devfs device name (bug filed, with patch :-)
[2] http://lists.debian.org/debian-boot/2006/10/msg00710.html
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Jim Paris <jim@jtan.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #233 received at 389881@bugs.debian.org (full text, mbox):

From: Jim Paris <jim@jtan.com>
To: Frans Pop <elendil@planet.nl>, 389881@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Tue, 13 Mar 2007 14:54:48 -0400
Frans Pop wrote:
> I will not deny that users _can_ hit this issue, but it has been a known 
> issue since Sarge. Unfortunately no one has yet been able to help us find 
> a "good enough for Debian" solution for this.
...
> Personally I also feel that all possible solutions effectively make
> /etc/fstab unreadable and unmaintainable. Maybe Debian should lead the way 
> to make /etc/fstab a generated file (like e.g. modules.conf used to
> be).

One potential workaround for anyone running into this issue might be
to create the root disk as a 1-disk RAID1, and then it should (?) get
mounted by RAID UUID at boot.

-jim



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to "peter green" <plugwash@P10Link.net>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #238 received at 389881@bugs.debian.org (full text, mbox):

From: "peter green" <plugwash@P10Link.net>
To: "Frans Pop" <elendil@planet.nl>, <389881@bugs.debian.org>
Subject: RE: Bug#389881: RC-ness of this bug
Date: Wed, 14 Mar 2007 21:05:31 -0000
 
> Personally I also feel that all possible solutions effectively make
> /etc/fstab unreadable and unmaintainable. Maybe Debian should 
> lead the way 
> to make /etc/fstab a generated file (like e.g. modules.conf used to be).
what is so bad about /dev/disk/by-path/pci-0000:00:07.1-ide-0:0-part1 ?

it says exactly where the controller is on the PCI bus, which device it is on the controller and which partition it is. Someone seeing that pattern should easilly be able to add entries for other drives and partitions on the same controller and with a bit more work (e.g. reading lspci and/or looking through /dev/disk/by-path) for drives on other controllers.

sure its a little on the long side and you might want to change the spacing in fstab to reflect that but we have editors with copy and paste. A bit of extra verbosity in device names seems a small price to pay to get device names that are stable and reliable. The hd? system was very nice when most people just had a single ide controller with all their (sd? was alwats nasty afaict but few enough people had scsi that it didn't hit too many newbies) but times have moved on and it simply isn't possible to reliablly indentify drives with an identifier that short anymore. 

i don't see what generating fstab would gain. you are still going to have to have a configuration file that contains all the information about what to mount where including a method for identifying drives even accross addition of new hardware.







Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #243 received at 389881@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: peter green <plugwash@P10Link.net>, 389881@bugs.debian.org
Cc: Frans Pop <elendil@planet.nl>
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 14 Mar 2007 15:43:16 -0700
On Wed, Mar 14, 2007 at 09:05:31PM -0000, peter green wrote:

> > Personally I also feel that all possible solutions effectively make
> > /etc/fstab unreadable and unmaintainable. Maybe Debian should 
> > lead the way 
> > to make /etc/fstab a generated file (like e.g. modules.conf used to be).
> what is so bad about /dev/disk/by-path/pci-0000:00:07.1-ide-0:0-part1 ?

That it's not a persistent means of identifying a filesystem.  It changes if
you move the PCI device, it changes if you change the SCSI/IDE bus address
of the drive, it changes if the kernel changes the name of the storage
subsystem used to access the device (on kernel upgrades), it breaks down
miserably if you use fiberchannel.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to "peter green" <plugwash@P10Link.net>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #248 received at 389881@bugs.debian.org (full text, mbox):

From: "peter green" <plugwash@P10Link.net>
To: "Steve Langasek" <vorlon@debian.org>, <389881@bugs.debian.org>
Subject: RE: Bug#389881: RC-ness of this bug
Date: Wed, 14 Mar 2007 23:22:03 -0000
> That it's not a persistent means of identifying a filesystem.  
for most users fstab has always identified by rough position (e.g. hda=ide primary master), changing to a system based on partition IDs would mean a lot of relearning for admins (e.g. its no longer ok to backup a partition by dding it to another one)

>It 
> changes if
> you move the PCI device
true, not that i imagine people do that much.

>, it changes if you change the SCSI/IDE bus address
> of the drive
the same applied in the old hd? and sd? days, drives names changing when you change thier IDE/SCSI ids is something admins expect and are used to.

, it changes if the kernel changes the name of the storage
> subsystem used to access the device (on kernel upgrades)
true, i wish they'd stop behaving like that.

>, it breaks down
> miserably if you use fiberchannel.
never used fiberchanel so can't comment on this.


to clarify my position on the overall issue

i agree that this is too late for etch (sadly) 
by-path and by-id each have some pros and cons over each other but both are far better than the old scheme now that multiple controllers and usb devices in sd? are becoming the norm.
by-uuid and uuid's in fstab (which seem to achive the same) is a very bad idea, it means that using dd to back up a partition to another one could result in the wrong one being mounted with potentially disasterous consequences. It could also be a severe security issue with the help of a carefully crafted usb stick (especially in an environment where deployment is done by imaging).
labels suffer from the problems given above for uuids
users installing on expert and possiblly medium should be given the choice between traditional names and the various new options.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #253 received at 389881@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: peter green <plugwash@P10Link.net>, 389881@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Wed, 14 Mar 2007 16:57:51 -0700
On Wed, Mar 14, 2007 at 11:22:03PM -0000, peter green wrote:

> > That it's not a persistent means of identifying a filesystem.  
> for most users fstab has always identified by rough position (e.g. hda=ide
> primary master), changing to a system based on partition IDs would mean a
> lot of relearning for admins (e.g. its no longer ok to backup a partition
> by dding it to another one)

> >It 
> > changes if
> > you move the PCI device
> true, not that i imagine people do that much.

That doesn't make it a negligible use case.

> >, it changes if you change the SCSI/IDE bus address
> > of the drive
> the same applied in the old hd? and sd? days, drives names changing when
> you change thier IDE/SCSI ids is something admins expect and are used to.

Um.  Have you ever even used SCSI?

> , it changes if the kernel changes the name of the storage
> > subsystem used to access the device (on kernel upgrades)
> true, i wish they'd stop behaving like that.

Wishes don't get you robust systems.

> >, it breaks down
> > miserably if you use fiberchannel.
> never used fiberchanel so can't comment on this.

Well, some of us have, and I don't think any admin of such systems enjoys
having to fix /etc/fstab by hand.

> to clarify my position on the overall issue

> i agree that this is too late for etch (sadly) 
> by-path and by-id each have some pros and cons over each other but both
> are far better than the old scheme now that multiple controllers and usb
> devices in sd? are becoming the norm.

No, the trade-offs of by-path and by-id are *not* a clear win over the
trade-offs of the current scheme.

> by-uuid and uuid's in fstab (which seem to achive the same) is a very bad
> idea, it means that using dd to back up a partition to another one could
> result in the wrong one being mounted with potentially disasterous
> consequences.

Using dd to back up a partition to another isn't a very sensible backup
schema anyway.  I think more people move PCI devices than back up systems
this way...

> It could also be a severe security issue with the help of a carefully
> crafted usb stick (especially in an environment where deployment is done
> by imaging).

Heh, that seems oddly possible, yes.  I guess it's not hard to read the uuid
right out of the fstab, after all...

What does the kernel do when it finds two filesystems with colliding uuids?
Ideally, to avoid any accidents, it should rename them both.  With that fix
(if indeed it needs fixing), I think all the main problems of by-uuid go
away.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #258 received at 389881@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Steve Langasek <vorlon@debian.org>, 389881@bugs.debian.org
Cc: peter green <plugwash@P10Link.net>
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 15 Mar 2007 08:56:39 +0100
[Message part 1 (text/plain, inline)]
On Wed, Mar 14, 2007 at 04:57:51PM -0700, Steve Langasek wrote:
> > >, it changes if you change the SCSI/IDE bus address
> > > of the drive
> > the same applied in the old hd? and sd? days, drives names changing when
> > you change thier IDE/SCSI ids is something admins expect and are used to.
> Um.  Have you ever even used SCSI?

Someone which uses scsi-over-fc have much better identification, the wwnn,
which is used in by-id:

| $ ls -al /dev/disk/by-id/scsi-320000020371a*
| lrwxrwxrwx 1 root root  9 Mar  2 23:24 /dev/disk/by-id/scsi-320000020371a2f24 -> ../../sda
| lrwxrwxrwx 1 root root 10 Mar  2 23:24 /dev/disk/by-id/scsi-320000020371a2f24-part1 -> ../../sda1
| lrwxrwxrwx 1 root root 10 Mar  2 23:24 /dev/disk/by-id/scsi-320000020371a2f24-part2 -> ../../sda2

> Well, some of us have, and I don't think any admin of such systems enjoys
> having to fix /etc/fstab by hand.

Also many fc-users wants multipath anyway, which also uses the wwnn for
identification.

> Using dd to back up a partition to another isn't a very sensible backup
> schema anyway.  I think more people move PCI devices than back up systems
> this way...

It is widely used in form of snapshots.

> What does the kernel do when it finds two filesystems with colliding uuids?
> Ideally, to avoid any accidents, it should rename them both.  With that fix
> (if indeed it needs fixing), I think all the main problems of by-uuid go
> away.

It does nothing special. This is completely userspace. And current udev just
uses the last seen one, which is usualy the removable device in this case.

Bastian

-- 
Every living thing wants to survive.
		-- Spock, "The Ultimate Computer", stardate 4731.3
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #263 received at 389881@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Bastian Blank <waldi@debian.org>
Cc: 389881@bugs.debian.org, peter green <plugwash@P10Link.net>
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 15 Mar 2007 02:19:11 -0700
On Thu, Mar 15, 2007 at 08:56:39AM +0100, Bastian Blank wrote:
> On Wed, Mar 14, 2007 at 04:57:51PM -0700, Steve Langasek wrote:
> > > >, it changes if you change the SCSI/IDE bus address
> > > > of the drive
> > > the same applied in the old hd? and sd? days, drives names changing when
> > > you change thier IDE/SCSI ids is something admins expect and are used to.
> > Um.  Have you ever even used SCSI?

> Someone which uses scsi-over-fc have much better identification, the wwnn,
> which is used in by-id:

So it's used in by-id, but not in by-path, right?  Hence this is still an
argument against by-path.

> | $ ls -al /dev/disk/by-id/scsi-320000020371a*
> | lrwxrwxrwx 1 root root  9 Mar  2 23:24 /dev/disk/by-id/scsi-320000020371a2f24 -> ../../sda
> | lrwxrwxrwx 1 root root 10 Mar  2 23:24 /dev/disk/by-id/scsi-320000020371a2f24-part1 -> ../../sda1
> | lrwxrwxrwx 1 root root 10 Mar  2 23:24 /dev/disk/by-id/scsi-320000020371a2f24-part2 -> ../../sda2

> > Well, some of us have, and I don't think any admin of such systems enjoys
> > having to fix /etc/fstab by hand.

> Also many fc-users wants multipath anyway, which also uses the wwnn for
> identification.

True; though supported multipath implementations sadly vary with vendor.

> > Using dd to back up a partition to another isn't a very sensible backup
> > schema anyway.  I think more people move PCI devices than back up systems
> > this way...

> It is widely used in form of snapshots.

Yes, snapshots are fairly common, and at least in the case of a power outage
/ system crash you'd have to worry about them being around on reboot.  Hmm,
having the system unable to mount a root fs at all on reboot would be even
worse for recovery than having it accidentally mount a snapshot, which is
already bad enough...

> > What does the kernel do when it finds two filesystems with colliding uuids?
> > Ideally, to avoid any accidents, it should rename them both.  With that fix
> > (if indeed it needs fixing), I think all the main problems of by-uuid go
> > away.

> It does nothing special. This is completely userspace. And current udev just
> uses the last seen one, which is usualy the removable device in this case.

Right.  Do you think it would be sensible to rename both devices on
collision?  Do you think that would be sufficient for making by-uuid a safe
default?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #268 received at 389881@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 389881@bugs.debian.org, peter green <plugwash@P10Link.net>
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 15 Mar 2007 11:10:26 +0100
[Message part 1 (text/plain, inline)]
On Thu, Mar 15, 2007 at 02:19:11AM -0700, Steve Langasek wrote:
> > Someone which uses scsi-over-fc have much better identification, the wwnn,
> > which is used in by-id:
> So it's used in by-id, but not in by-path, right?  Hence this is still an
> argument against by-path.

No, similar identifiers are listed in both. And for s390 the initramfs scripts
expects that the by-path name is used as root to be able to activate the
complete device.

> > | lrwxrwxrwx 1 root root  9 Mar  2 23:24 /dev/disk/by-id/scsi-320000020371a2f24 -> ../../sda
> > | lrwxrwxrwx 1 root root 10 Mar  2 23:24 /dev/disk/by-id/scsi-320000020371a2f24-part1 -> ../../sda1
> > | lrwxrwxrwx 1 root root 10 Mar  2 23:24 /dev/disk/by-id/scsi-320000020371a2f24-part2 -> ../../sda2

320000020371a2f24 is the unique identifier of the disk.

| lrwxrwxrwx 1 root root   9 Mar  2 23:24 ccw-0.0.2900-zfcp-0x21000020371a2f24:0x0000000000000000 -> ../../sda
| lrwxrwxrwx 1 root root  10 Mar  2 23:24 ccw-0.0.2900-zfcp-0x21000020371a2f24:0x0000000000000000-part1 -> ../../sda1
| lrwxrwxrwx 1 root root  10 Mar  2 23:24 ccw-0.0.2900-zfcp-0x21000020371a2f24:0x0000000000000000-part2 -> ../../sda2

21000020371a2f24 is the identifier of the path to the disk. In this case there
exists two paths to the disk via one controller.

> > > Using dd to back up a partition to another isn't a very sensible backup
> > > schema anyway.  I think more people move PCI devices than back up systems
> > > this way...
> > It is widely used in form of snapshots.
> Yes, snapshots are fairly common, and at least in the case of a power outage
> / system crash you'd have to worry about them being around on reboot.  Hmm,
> having the system unable to mount a root fs at all on reboot would be even
> worse for recovery than having it accidentally mount a snapshot, which is
> already bad enough...

But irrelevant in this case, as udev does not set links for dm devices in
by-uuid, they have a unique name per definition. (Yes, two lvm vgs with
the same name have weird effects ...)

> Right.  Do you think it would be sensible to rename both devices on
> collision?  Do you think that would be sufficient for making by-uuid a safe
> default?

I'm not sure. You always get a race condition between the events for the two
devices.

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
		-- Spock, "This Side of Paradise", stardate 3417.3
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #273 received at 389881@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Frans Pop <elendil@planet.nl>, 389881@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 15 Mar 2007 16:44:24 +0000
On Tue, Mar 13, 2007 at 05:49:02PM +0100, Frans Pop wrote:
> Colin has said a few times that he consideres the Ubuntu solution not 
> clean enough for Debian.

If I said that I misspoke; I only meant that it's not settled enough for
Etch at this point. As I indicated on #debian-boot yesterday, I don't
see anything wrong with Ubuntu's approach to this problem for Debian in
general.

> Personally I also feel that all possible solutions effectively make
> /etc/fstab unreadable and unmaintainable.

The approach we took in Ubuntu was to put comments above each UUID entry
in /etc/fstab documenting which traditional device name they
corresponded to at the point of installation. Of course this can get out
of date, but I don't think there's really any sensible way around that.

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #278 received at 389881@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: peter green <plugwash@P10Link.net>, 389881@bugs.debian.org
Cc: Steve Langasek <vorlon@debian.org>
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 15 Mar 2007 16:48:14 +0000
On Wed, Mar 14, 2007 at 11:22:03PM -0000, peter green wrote:

> for most users fstab has always identified by rough position (e.g.
> hda=ide primary master), changing to a system based on partition IDs
> would mean a lot of relearning for admins (e.g. its no longer ok to
> backup a partition by dding it to another one)

Note that various of the solutions suggested in this thread break the
case where you *restore* from a dd'ed backup onto a new disk. If you
restore such a backup after a fatal disk crash, you want the result to
be mounted in the same place as before even though the drive ID and
possibly its physical location are different. Thus I don't agree that
by-id or by-path are good solutions to this problem; by-id even breaks
where old-style "IDE primary master"-type identification would have
worked fine.

-- 
Colin Watson                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Frans Pop <elendil@planet.nl>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #283 received at 389881@bugs.debian.org (full text, mbox):

From: Frans Pop <elendil@planet.nl>
To: 389881@bugs.debian.org
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 15 Mar 2007 18:12:30 +0100
[Message part 1 (text/plain, inline)]
On Thursday 15 March 2007 17:44, Colin Watson wrote:
> > Personally I also feel that all possible solutions effectively make
> > /etc/fstab unreadable and unmaintainable.
>
> The approach we took in Ubuntu was to put comments above each UUID
> entry in /etc/fstab documenting which traditional device name they
> corresponded to at the point of installation. Of course this can get
> out of date, but I don't think there's really any sensible way around
> that.

My main point is not that the UUID itself is not readable, but rather that 
the lines get way too long and, depending on your editor (settings), 
either get wrapped or disappear off screen. You loose the easy overview 
of what's in fstab.
/etc/fstab used to be fairly maintainable because the info could be kept 
in columns fairly easily for most cases and because the info would mostly 
fit on one line [1].

IMO with a switch to UUIDs we are going to need an fstab editor (console 
based) that:
- does the translation to the "normal" device names on the fly (and thus
  does always reflect the actual situation)
- provides different 'views' of what's in fstab
- allows to select what representation for the file system should be
  used in the fstab (traditional, path, uuid, id, ...)
- allows to set mount point, type, mount options, etc.
- sorts partitions into a logical order
- maybe knows about removable devices
- has a simple interface to add new entries for e.g. USB sticks
- ...

[1] Yeah, I know this is not true for NFS volumes and if a lot of options 
are used, but in general it was true.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. Full text and rfc822 format available.

Acknowledgement sent to Rick Thomas <rbthomas55@pobox.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #288 received at 389881@bugs.debian.org (full text, mbox):

From: Rick Thomas <rbthomas55@pobox.com>
To: 389881@bugs.debian.org
Cc: Debian-users <debian-user@lists.debian.org>
Subject: Re: Bug#389881: RC-ness of this bug
Date: Thu, 15 Mar 2007 15:06:27 -0400
On Mar 15, 2007, at 1:12 PM, Frans Pop wrote:

> On Thursday 15 March 2007 17:44, Colin Watson wrote:
>>> Personally I also feel that all possible solutions effectively make
>>> /etc/fstab unreadable and unmaintainable.
>>
>> The approach we took in Ubuntu was to put comments above each UUID
>> entry in /etc/fstab documenting which traditional device name they
>> corresponded to at the point of installation. Of course this can get
>> out of date, but I don't think there's really any sensible way around
>> that.
>
> My main point is not that the UUID itself is not readable, but  
> rather that
> the lines get way too long and, depending on your editor (settings),
> either get wrapped or disappear off screen. You loose the easy  
> overview
> of what's in fstab.
> /etc/fstab used to be fairly maintainable because the info could be  
> kept
> in columns fairly easily for most cases and because the info would  
> mostly
> fit on one line [1].
>
> IMO with a switch to UUIDs we are going to need an fstab editor  
> (console
> based) that:
> - does the translation to the "normal" device names on the fly (and  
> thus
>   does always reflect the actual situation)
> - provides different 'views' of what's in fstab
> - allows to select what representation for the file system should be
>   used in the fstab (traditional, path, uuid, id, ...)
> - allows to set mount point, type, mount options, etc.
> - sorts partitions into a logical order
> - maybe knows about removable devices
> - has a simple interface to add new entries for e.g. USB sticks
> - ...
>
> [1] Yeah, I know this is not true for NFS volumes and if a lot of  
> options
> are used, but in general it was true.


If you're going to all the trouble of a smart fstab editor, why not  
simply define a more modern format (e.g. like that of dhcpd.conf) for  
the information that can accommodate line breaks and nesting.  Change  
the name to something else, don't call it fstab; if the new file  
doesn't exist the mount command (and the rest of them that currently  
read fstab) will default to /etc/fstab if present.

The biggest problem will be identifying all the places where fstab is  
currently *assumed* to be present and making them all use the new  
file.  A library is probably needed that does the deciding of which  
format to use.

Are there POSIX/LSB/etc ramifications?

just a thought,

Rick



Changed Bug submitter from "Robert Millan [ackstorm]" <rmillan@ackstorm.es> to "Robert Millan [ackstorm]" <robert.millan@ackstorm.es>. Request was from "Robert Millan [ackstorm]" <robert.millan@ackstorm.es> to control@bugs.debian.org. (Tue, 05 Jun 2007 07:48:05 GMT) Full text and rfc822 format available.

Changed Bug submitter from "Robert Millan [ackstorm]" <robert.millan@ackstorm.es> to rmh@aybabtu.com. Request was from "Robert Millan [ackstorm]" <robert.millan@ackstorm.es> to control@bugs.debian.org. (Mon, 13 Aug 2007 11:18:02 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#389881; Package partman-target. (Wed, 24 Dec 2008 07:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christian Perrier <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 24 Dec 2008 07:03:02 GMT) Full text and rfc822 format available.

Message #297 received at 389881@bugs.debian.org (full text, mbox):

From: Christian Perrier <bubulle@debian.org>
To: Daniel Pocock <daniel@pocock.com.au>, 509378@bugs.debian.org, 389881@bugs.debian.org
Subject: Re: Bug#509378: should use labels for all partitions in fstab
Date: Wed, 24 Dec 2008 07:57:52 +0100
[Message part 1 (text/plain, inline)]
reassign 509378 partman-target
forcemerge 509378 389881
thanks

I now have the right reference:

http://bugs.debian.org/389881

...is roughly the same suggestion than the one you're doing right
now. It talks about SCSI devices but the bug discussion makes it clear
that persistent naming goes much beyond SCSI devices.

There is even a patch proposed by David Härdeman (who was very active
implementing encrypted partitions support in the past)...but
unfortunately, nobody cared to try incorporating this in D-I, when we
moved to the Lenny D-I release cycle..:-(

It is even listed in the D-I Lenny release goals:
http://wiki.debian.org/DebianInstaller/LennyGoals

As you'll see by looking around this release goals list, there's still
a lot that we *didn't* do.


[signature.asc (application/pgp-signature, inline)]

Forcibly Merged 225802 295134 308565 389881 509378. Request was from Christian Perrier <bubulle@debian.org> to control@bugs.debian.org. (Wed, 24 Dec 2008 07:03:06 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 18 Oct 2009 07:27:18 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 07:36:20 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.