On Thu, Mar 08, 2007 at 11:21:05AM +, 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
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
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
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] [EMAIL PROTECTED] wrote:
I urge you to reconsider severity of this problem. There's another
situation
that makes it much
On Tue, Mar 06, 2007 at 09:44:31AM -0300, Otavio Salvador wrote:
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Mar 06, Robert Millan [ackstorm] [EMAIL PROTECTED] wrote:
I urge you to reconsider severity of this problem. There's another
situation
that makes it much worse:
The correct
On Wed, Mar 07, 2007 at 12:05:09PM +0100, Marco d'Itri wrote:
On Mar 07, Robert Millan [ackstorm] [EMAIL PROTECTED] 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
On Wed, Mar 07, 2007 at 09:33:47AM -0300, Otavio Salvador wrote:
Robert Millan [ackstorm] [EMAIL PROTECTED] writes:
On Tue, Mar 06, 2007 at 09:44:31AM -0300, Otavio Salvador wrote:
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Mar 06, Robert Millan [ackstorm] [EMAIL PROTECTED] wrote
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,
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
Package: partman-auto
Severity: normal
When installing on a machine without any hard disk [1], I'd expect partman to
show an error telling me that. Currently it just loops over the Guided
partitioning template.
[1] or a machine whose disks aren't properly configured, and remain
undetectable
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:
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
Hi!
d-i now offers the possibility of installing with disabled root logins. If you
do that, the default GNOME desktop is broken because a lot of the links use gksu
instead of gksudo:
/usr/share/applications/gdmsetup.desktop:Exec=gksu gdmsetup
Hi!
udev 0.097-1 contains fixes necessary support of I2O drives (see #373921). I
understand that the version of udev currently in sid (or later) will forcibly
get into etch because of #369479, but I'm not sure if this will affect d-i
image generation.
Is d-i etch RC1 expected to include udev =
On Thu, Jun 15, 2006 at 02:54:47PM -0400, Joey Hess wrote:
Robert Millan wrote:
Which architectures include support for i2o_block?
It's available on amd64, hppa, i386, ia64, powerpc. I tested it on amd64.
And dpt_i2o is not available on 64 bit, so if we're adding i2o_block to
only
Btw, I've noticed that discover updates its module list from a master copy in:
http://people.debian.org/~joeyh/d-i/modules-list
Perhaps i2o_block should be there as well?
--
Robert Millan
[EMAIL PROTECTED]
Departamento de Asistencia Técnica
Oficina central: (+34) 902 888 345
Asistencia
On Fri, Jun 16, 2006 at 10:50:10AM +0200, Frans Pop wrote:
On Friday 16 June 2006 09:50, Robert Millan [ackstorm] wrote:
For the d-i rescue system, I thought this was handled by discover. Am
I right? There's i2o_block support in discover, although not working on
my hardware. I think
Package: kernel-wedge
Severity: important
Tags: patch
scsi-extra-modules includes dpt_i2o module, but this is only available on 32bit
platforms. On 64bit, there's no mechanism in d-i to access I2O devices. This
normaly makes the system uninstallable.
Please could you add the i2o_block module
18 matches
Mail list logo
