Bug#389881: RC-ness of this bug
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" "$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/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
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: > >> > > >> >> 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
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 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
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 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
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 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406325: partman-auto: missing "no disks found" error
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 by Linux Found when using yesterday's (2007-01-09) daily netinst build for amd64. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: SCSI device renaming breaks install
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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: SCSI device renaming breaks install
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
disabled-root-login installs and default GNOME setup
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=gksu -u root /usr/bin/foomatic-gui /usr/share/applications/users.desktop:TryExec=gksu /usr/share/applications/users.desktop:Exec=gksu users-admin /usr/share/applications/shares.desktop:TryExec=gksu /usr/share/applications/shares.desktop:Exec=gksu shares-admin /usr/share/applications/services.desktop:TryExec=gksu /usr/share/applications/services.desktop:Exec=gksu services-admin /usr/share/applications/network.desktop:TryExec=gksu /usr/share/applications/network.desktop:Exec=gksu -u root network-admin /usr/share/applications/disks.desktop:TryExec=gksu /usr/share/applications/disks.desktop:Exec=gksu disks-admin /usr/share/applications/time.desktop:TryExec=gksu /usr/share/applications/time.desktop:Exec=gksu time-admin /usr/share/applications/software-properties.desktop:Exec=gksu /usr/bin/software-properties /usr/share/applications/synaptic.desktop:Exec=gksu -u root /usr/sbin/synaptic /usr/share/applications/update-manager.desktop:Exec=gksu /usr/bin/update-manager Should these applications be using gksudo instead? Should gksu be smarter and try different ways of getting root [1]? Should d-i do some workaround? [1] Since it is possible that user might setup password-less sudo, I would suggest attempting "the sudo way" first, then trying su. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
udev and I2O support
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 >= 0.097-1 ? If not, I think this should be contemplated, since otherwise user would have to load i2o_block manualy during install. Thanks, -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370667: I2O modules for 64bit platforms
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 it just needs a new entry for this PCI id. > > No, device detection and module loading within d-i is now handled (almost) > completely by udev; discover is no longer used. Ok. Filed as #373921. -- Robert Millan [EMAIL PROTECTED] Departamento de Asistencia Técnica Oficina central: (+34) 902 888 345 Asistencia técnica: (+34) 902 888 408 ACK STORM, S.L. http://www.ackstorm.es Este mensaje electrónico contiene información de ACK STORM, S.L. que es privada y confidencial, siendo para el uso exclusivo de las personas o entidades arriba mencionadas. Si usted no es el destinatario señalado, le informamos que cualquier divulgación, copia, distribución o uso de los contenidos está prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido y comuníquenoslo en la dirección [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370667: I2O modules for 64bit platforms
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écnica: (+34) 902 888 408 ACK STORM, S.L. http://www.ackstorm.es Este mensaje electrónico contiene información de ACK STORM, S.L. que es privada y confidencial, siendo para el uso exclusivo de las personas o entidades arriba mencionadas. Si usted no es el destinatario señalado, le informamos que cualquier divulgación, copia, distribución o uso de los contenidos está prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido y comuníquenoslo en la dirección [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370667: I2O modules for 64bit platforms
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 arches that lack dpt_i20, then i2o_block should be added to > ia64, hppa, powerpc(64?). And amd64. > > > And if dpt_i2o does > > > the same thing for i386, whouldn't we include i2o_block only for those > > > architectures that do not have dpt_i2o? > > > > Seems fine. Unless there are other advantages in using i2o_block that would > > justify replacing dpt_i2o in 32bit arches; but I don't know about that. > > Right, of course the user would need to load it by hand in that case, > since at least on i386 there's nothing to make udev load it. 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 it just needs a new entry for this PCI id. For the installed system, doesn't the patch in #318120 address this? -- Robert Millan [EMAIL PROTECTED] Departamento de Asistencia Técnica Oficina central: (+34) 902 888 345 Asistencia técnica: (+34) 902 888 408 ACK STORM, S.L. http://www.ackstorm.es Este mensaje electrónico contiene información de ACK STORM, S.L. que es privada y confidencial, siendo para el uso exclusivo de las personas o entidades arriba mencionadas. Si usted no es el destinatario señalado, le informamos que cualquier divulgación, copia, distribución o uso de los contenidos está prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido y comuníquenoslo en la dirección [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373730: libdebian-installer: mapping for I2O devices (/dev/i2o)
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:55:41.0 +0200
+++ libdebian-installer-0.29/src/system/devfs.c 2006-06-15 12:16:44.0
+0200
@@ -90,6 +90,7 @@
{ 77, 0, "ida", ENTRY_TYPE_DISC_ARRAY_CONTROLLER,
5, 4 },
{ 78, 0, "ida", ENTRY_TYPE_DISC_ARRAY_CONTROLLER,
6, 4 },
{ 79, 0, "ida", ENTRY_TYPE_DISC_ARRAY_CONTROLLER,
7, 4 },
+{ 80, 0, "i2o/hd", ENTRY_TYPE_DISC,0, 4 },
{ 88, 0, "hd", ENTRY_TYPE_DISC,12, 6 },
{ 89, 0, "hd", ENTRY_TYPE_DISC,14, 6 },
{ 90, 0, "hd", ENTRY_TYPE_DISC,16, 6 },
--
Robert Millan
[EMAIL PROTECTED]
Departamento de Asistencia Técnica
Oficina central: (+34) 902 888 345
Asistencia técnica: (+34) 902 888 408
ACK STORM, S.L.
http://www.ackstorm.es
Este mensaje electrónico contiene información de ACK STORM, S.L. que es privada
y confidencial, siendo para el uso exclusivo de las personas o entidades arriba
mencionadas. Si usted no es el destinatario señalado, le informamos que
cualquier divulgación, copia, distribución o uso de los contenidos está
prohibida. Si usted ha recibido este mensaje por error, por favor borre su
contenido y comuníquenoslo en la dirección [EMAIL PROTECTED]
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370667: I2O modules for 64bit platforms
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 well? -- Robert Millan [EMAIL PROTECTED] Departamento de Asistencia Técnica Oficina central: (+34) 902 888 345 Asistencia técnica: (+34) 902 888 408 ACK STORM, S.L. http://www.ackstorm.es Este mensaje electrónico contiene información de ACK STORM, S.L. que es privada y confidencial, siendo para el uso exclusivo de las personas o entidades arriba mencionadas. Si usted no es el destinatario señalado, le informamos que cualquier divulgación, copia, distribución o uso de los contenidos está prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido y comuníquenoslo en la dirección [EMAIL PROTECTED] -- diff -ur kernel-wedge-2.22.old/modules/scsi-extra-modules kernel-wedge-2.22/modules/scsi-extra-modules --- kernel-wedge-2.22.old/modules/scsi-extra-modules2005-12-07 03:28:15.0 +0100 +++ kernel-wedge-2.22/modules/scsi-extra-modules2006-06-06 10:52:47.0 +0200 @@ -6,6 +6,7 @@ cciss cpqarray dpt_i2o ? +i2o_block dtc ? eata fdomain
