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
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 fr
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
> man
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 g
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 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 kno
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&#
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 th
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
o
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
undetectabl
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
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
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
/usr/share/applications/foomatic-gui.desktop:Exec=gk
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 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
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 técn
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
Package: libdebian-installer
Severity: wishlist
Tags: patch
Please could you add mapping for I2O hard disks? Patch follows.
diff -ur libdebian-installer-0.29.old/src/system/devfs.c
libdebian-installer-0.29/src/system/devfs.c
--- libdebian-installer-0.29.old/src/system/devfs.c 2004-06-15
18
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 as
19 matches
Mail list logo
