Re: Release Candidate 2 of Debian Installer

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Florian Weimer
* Otavio Salvador:

> See the errata[2] for details and a full list of known issues.

What needs to be done so that these two issues can be fixed?

| Disk devices may change on reboot
|
|     On systems with multiple disk controllers, the kernel/udev may
|     assign a different device node on reboot of the system than was
|     used during installation due to difference in load order of
|     drivers.  This can lead to failure to boot the system. In most
|     cases this can be corrected by changing the bootloader
|     configuration and /etc/fstab, possibly using the rescue mode of
|     the installer.  Note however that this problem may occur again on
|     subsequent boots.
|
| Reboot problems when installing from a USB stick
|
|     The former problem may also happen when installing from a USB
|     stick. Temporarily keeping the USB stick in place will allow you
|     to boot the installed system and correct the bootloader
|     configuration file. See #506263 for details about such workaround.

We've been dragging this problem along for quite some time now. 8-(


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Bernd Eckenfels
In article <[hidden email]> you wrote:
> What needs to be done so that these two issues can be fixed?
>
> | Disk devices may change on reboot

A good option would be to use LABEL or UID instead. However I am not sure if that has some drawbacks as well:

- for uuid the system is less forgiving if you swap disks
- for label the system is less forgiving if you bring in temp. new disks

So I think UUID has less risks.

Gruss
Bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Andrew Deason-2
On Sun, 01 Feb 2009 00:19:33 +0100
Bernd Eckenfels <[hidden email]> wrote:

> In article <[hidden email]> you wrote:
> > What needs to be done so that these two issues can be fixed?
> >
> > | Disk devices may change on reboot
>
> A good option would be to use LABEL or UID instead.

I believe this still doesn't solve the problem in the case of lilo.conf
or grub's device.map, when specifying e.g. where to write the MBR. Is
there any way around that?

> However I am not sure if that has some drawbacks as well:
>
> - for uuid the system is less forgiving if you swap disks
> - for label the system is less forgiving if you bring in temp. new
> disks

Label names could be generated to minimize collisions.  Something like
${hostname}-/ instead of /, or maybe something even more specific.

--
Andrew Deason
[hidden email]


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Jeremy Stanley
On Sat, Jan 31, 2009 at 07:56:01PM -0600, Andrew Deason wrote:
[...]
> Label names could be generated to minimize collisions.  Something like
> ${hostname}-/ instead of /, or maybe something even more specific.
[...]

The namespace here is, unfortunately, pretty limited. The manpages
for mkreiserfs and mke2fs mention a 16-character limit for
filesystem labels, so you'd be out of luck trying to (for example)
represent /usr/local in the scheme above without truncating the
hostname to 5 characters. You can't fully represent a mount path
greater than 16 characters in a filesystem label even unprefixed.
Maybe a 14-byte hash of the hostname and path (or even just a
14-byte pseudo-random number, for that matter) represented in 7-bit
ASCII characters would achieve the desired goal? That'd look pretty
ugly though...
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([hidden email]); IRC([hidden email]#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([hidden email]);
MUD([hidden email]:6669); WWW(http://fungi.yuggoth.org/); }


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Arthur de Jong-2
On Sun, 2009-02-01 at 03:46 +0000, The Fungi wrote:
> On Sat, Jan 31, 2009 at 07:56:01PM -0600, Andrew Deason wrote:
> > Label names could be generated to minimize collisions.  Something like
> > ${hostname}-/ instead of /, or maybe something even more specific.
>
> The namespace here is, unfortunately, pretty limited. The manpages
> for mkreiserfs and mke2fs mention a 16-character limit for
> filesystem labels [...]

Also using slashes in labels causes problems with the symlinks showing
up in /dev/disk/by-label.

--
-- arthur - [hidden email] - http://people.debian.org/~adejong --

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

William Pitcock-2
In reply to this post by Bernd Eckenfels
On Sun, 2009-02-01 at 00:19 +0100, Bernd Eckenfels wrote:

> In article <[hidden email]> you wrote:
> > What needs to be done so that these two issues can be fixed?
> >
> > | Disk devices may change on reboot
>
> A good option would be to use LABEL or UID instead. However I am not sure if that has some drawbacks as well:
>
> - for uuid the system is less forgiving if you swap disks
> - for label the system is less forgiving if you bring in temp. new disks
>
> So I think UUID has less risks.
Anaconda uses LABEL. I don't know the full rationale on why this is, but
it may be a good idea to follow suit.

William

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Mike Hommey
On Sun, Feb 01, 2009 at 03:22:07AM -0600, William Pitcock wrote:

> On Sun, 2009-02-01 at 00:19 +0100, Bernd Eckenfels wrote:
> > In article <[hidden email]> you wrote:
> > > What needs to be done so that these two issues can be fixed?
> > >
> > > | Disk devices may change on reboot
> >
> > A good option would be to use LABEL or UID instead. However I am not sure if that has some drawbacks as well:
> >
> > - for uuid the system is less forgiving if you swap disks
> > - for label the system is less forgiving if you bring in temp. new disks
> >
> > So I think UUID has less risks.
>
> Anaconda uses LABEL. I don't know the full rationale on why this is, but
> it may be a good idea to follow suit.

And thanks to that, it's a PITA to have several RH/Fedora installs on the
same computer.

Mike


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

William Pitcock-2
On Sun, 2009-02-01 at 10:46 +0100, Mike Hommey wrote:

> On Sun, Feb 01, 2009 at 03:22:07AM -0600, William Pitcock wrote:
> > On Sun, 2009-02-01 at 00:19 +0100, Bernd Eckenfels wrote:
> > > In article <[hidden email]> you wrote:
> > > > What needs to be done so that these two issues can be fixed?
> > > >
> > > > | Disk devices may change on reboot
> > >
> > > A good option would be to use LABEL or UID instead. However I am not sure if that has some drawbacks as well:
> > >
> > > - for uuid the system is less forgiving if you swap disks
> > > - for label the system is less forgiving if you bring in temp. new disks
> > >
> > > So I think UUID has less risks.
> >
> > Anaconda uses LABEL. I don't know the full rationale on why this is, but
> > it may be a good idea to follow suit.
>
> And thanks to that, it's a PITA to have several RH/Fedora installs on the
> same computer.
Yes, I could indeed see why this would be problematic. So, UUID might
indeed be a better solution.

William

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Florian Weimer
In reply to this post by Andrew Deason-2
* Andrew Deason:

> I believe this still doesn't solve the problem in the case of lilo.conf
> or grub's device.map, when specifying e.g. where to write the MBR. Is
> there any way around that?

The boot loaders would obviously have to scan for UUIDs, which carries
its own risks (like lockup during boot because the wrong device is
touched).  If the expected location is checked first, this could be
minimized, though.

>> However I am not sure if that has some drawbacks as well:
>>
>> - for uuid the system is less forgiving if you swap disks
>> - for label the system is less forgiving if you bring in temp. new
>> disks
>
> Label names could be generated to minimize collisions.  Something like
> ${hostname}-/ instead of /, or maybe something even more specific.

The host name is often "debian" at installation time, so I doubt this
would work.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Christian Perrier
In reply to this post by Florian Weimer
Quoting Florian Weimer ([hidden email]):
> * Otavio Salvador:
>
> > See the errata[2] for details and a full list of known issues.
>
> What needs to be done so that these two issues can be fixed?

This has been discussed numerous times in -boot but among the low number of
ppl working on D-I during the etch->lenny release cycle....nobody
cared enough to work on this and solve it out.

http://wiki.debian.org/DebianInstaller/LennyGoals listed that goal and
#389881 has most of the information.

The Squeeze Goals list mentions it again and, here, Colin Watson
stepped up to work on it.



signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Petter Reinholdtsen
In reply to this post by Florian Weimer

[Florian Weimer]
> * Otavio Salvador:
>
>> See the errata[2] for details and a full list of known issues.
>
> What needs to be done so that these two issues can be fixed?

One solution to this is to stop using device names, and instead of
file system ID, in /etc/fstab and the boot loader configuration.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Gunnar Wolf
In reply to this post by Mike Hommey
Mike Hommey dijo [Sun, Feb 01, 2009 at 10:46:11AM +0100]:

> > > A good option would be to use LABEL or UID instead. However I am not sure if that has some drawbacks as well:
> > >
> > > - for uuid the system is less forgiving if you swap disks
> > > - for label the system is less forgiving if you bring in temp. new disks
> > >
> > > So I think UUID has less risks.
> >
> > Anaconda uses LABEL. I don't know the full rationale on why this is, but
> > it may be a good idea to follow suit.
>
> And thanks to that, it's a PITA to have several RH/Fedora installs on the
> same computer.

Still, it is a saner overall system. Of course, if during install d-i
finds there is already a partition labeled 'root', it could either ask
the user for an alternative name or set it to
d-i-${timestamp}-root. Or label all the partitions with a timestamp,
preemptively avoiding this kind of conflicts.

FWIW, setting them by label is the most flexible and robust way, not
tied to hardware keys or specific hookups.

--
Gunnar Wolf - [hidden email] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

William Pitcock-2
On Mon, 2009-02-02 at 14:09 -0600, Gunnar Wolf wrote:

> Mike Hommey dijo [Sun, Feb 01, 2009 at 10:46:11AM +0100]:
> > > > A good option would be to use LABEL or UID instead. However I am not sure if that has some drawbacks as well:
> > > >
> > > > - for uuid the system is less forgiving if you swap disks
> > > > - for label the system is less forgiving if you bring in temp. new disks
> > > >
> > > > So I think UUID has less risks.
> > >
> > > Anaconda uses LABEL. I don't know the full rationale on why this is, but
> > > it may be a good idea to follow suit.
> >
> > And thanks to that, it's a PITA to have several RH/Fedora installs on the
> > same computer.
>
> Still, it is a saner overall system. Of course, if during install d-i
> finds there is already a partition labeled 'root', it could either ask
> the user for an alternative name or set it to
> d-i-${timestamp}-root. Or label all the partitions with a timestamp,
> preemptively avoiding this kind of conflicts.
>
> FWIW, setting them by label is the most flexible and robust way, not
> tied to hardware keys or specific hookups.
It can't because 'd-i-${timestamp}-root' is longer than 16 characters.

William

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Gunnar Wolf
William Pitcock dijo [Mon, Feb 02, 2009 at 02:42:11PM -0600]:

> > Still, it is a saner overall system. Of course, if during install d-i
> > finds there is already a partition labeled 'root', it could either ask
> > the user for an alternative name or set it to
> > d-i-${timestamp}-root. Or label all the partitions with a timestamp,
> > preemptively avoiding this kind of conflicts.
> >
> > FWIW, setting them by label is the most flexible and robust way, not
> > tied to hardware keys or specific hookups.
>
> It can't because 'd-i-${timestamp}-root' is longer than 16 characters.

Right. But some shortening might be in place. Maybe 090201-root
(i.e. non-y2k, shortened timestamps). Or any other fixed-length
token.

--
Gunnar Wolf - [hidden email] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Paul Wise via nm
How about letting the person doing the installation write the labels
if they want to use LABEL and use UUID by default.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

Harald Braumann
On Tue, 3 Feb 2009 12:35:48 +0900
Paul Wise <[hidden email]> wrote:

> How about letting the person doing the installation write the labels
> if they want to use LABEL and use UUID by default.
>
Or as a third option, put everything in LVM, including boot and root,
and the problem goes away. GRUB2 would have to be used, though.

Cheers,
harry

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release Candidate 2 of Debian Installer

William Pitcock-2
On Tue, 2009-02-03 at 23:43 +0100, Harald Braumann wrote:
> On Tue, 3 Feb 2009 12:35:48 +0900
> Paul Wise <[hidden email]> wrote:
>
> > How about letting the person doing the installation write the labels
> > if they want to use LABEL and use UUID by default.
> >
> Or as a third option, put everything in LVM, including boot and root,
> and the problem goes away. GRUB2 would have to be used, though.

I am not sure GRUB2 is ready for a production release of Debian. It will
be by squeeze, but not yet for lenny IMHO.

Right now for booting off LVM, we use lilo. This is lilo's main use-case
in Debian currently[1], excluding hardware configurations where GRUB1
fails to work correctly.

A configuration resulting in us using lilo as the default bootloader is
probably not a good idea for many reasons, of which I have gone through
before, and do not intend to outline here (mostly related to the age of
the lilo codebase, and the fact that lilo needs to be refactored if it
is to remain relevant for much longer).

William

[1] debian-installer explicitly installs lilo instead of grub when a LVM
is used as the boot partition.

signature.asc (204 bytes) Download Attachment