Bug#366853: udev: vol_id returns incorrect information for my root device

2006-05-13 Thread Bob McGowan
The system I'm using is a Dell server, originally purchased with Red Hat 
Linux 7.1 (may have been 7.0, I don't recall for sure) installed at the 
factory.  I did not presume that they would have loaded any Windows 
software on a new system with new disks purchased this way.


Is there a way to write zeros, as it were, or otherwise fix this, 
without destroying the current installation?


Could you also tell me what formatting tools would be libparted based? 
Or suggest how I would go about finding out?


Thanks,

Bob

Kay Sievers wrote:

I've found that the problem appears to be related to vol_id failing to
find proper information for my root device, /dev/sda1.  I've run the
commands 'e2label', '/lib/udev/vol_id', 'mount' and 'fdisk' with the
following results:



Never use any of the all broken mkfs* tools without writing zeros to the
start and the end of the partition before applying a different format.
Overwrite at least 64kb. (Sane formatting applications like everything that
is libparted based don't need this.)

Kay




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



Bug#366853: udev: vol_id returns incorrect information for my root device

2006-05-11 Thread Bob McGowan
Package: udev
Version: 0.091-2
Severity: normal


Subject: udev: vol_id returns incorrect information for my boot device
Package: udev
Version: 0.091-2
Severity: normal

I've been trying to get the 'root=LABEL=label_name' functionality to
work for my system, since it's SCSI based and the presence or absence of
SCSI emulation devices sometimes changes the device name assigned.  But
when I set it up, the initramfs environment reports and error and drops
me into the Busybox shell.

I've found that the problem appears to be related to vol_id failing to
find proper information for my root device, /dev/sda1.  I've run the
commands 'e2label', '/lib/udev/vol_id', 'mount' and 'fdisk' with the
following results:

  #  mount
  /dev/sda1 on / type ext3 (rw,errors=remount-ro)
  

  # e2label /dev/sda1
  /root

  # fdisk /dev/sda

  The number of cylinders for this disk is set to 4427.
  There is nothing wrong with that, but this is larger than 1024,
  and could in certain setups cause problems with:
  1) software that runs at boot time (e.g., old versions of LILO)
  2) booting and partitioning software from other OSs
 (e.g., DOS FDISK, OS/2 FDISK)

  Command (m for help): p

  Disk /dev/sda: 36.4 GB, 36420075008 bytes
  255 heads, 63 sectors/track, 4427 cylinders
  Units = cylinders of 16065 * 512 = 8225280 bytes

 Device Boot  Start End  Blocks   Id  System
  /dev/sda1   1243219535008+  83  Linux
  /dev/sda22433442716024837+   5  Extended
  /dev/sda52433442716024806   83  Linux

  Command (m for help): q

  # /lib/udev/vol_id /dev/sda1
  ID_FS_USAGE=filesystem
  ID_FS_TYPE=vfat
  ID_FS_VERSION=FAT16
  ID_FS_UUID=F010-C0E4
  ID_FS_LABEL=
  ID_FS_LABEL_SAFE=

Note that I've changed the root devices label from the default '/' to
'/root', because initially I thought the problem was related to not
being able to create a link in /dev/disk/by-label/, since the single
character '/' would leave a null value for ID_FS_LABEL_SAFE.  This did
not help, due to the incorrect data from vol_id, but may still be an
issue.

-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 8
lrwxrwxrwx 1 root root  20 2006-04-04 09:49 020_permissions.rules - 
../permissions.rules
lrwxrwxrwx 1 root root  19 2006-04-03 10:07 025_libgphoto2.rules - 
../libgphoto2.rules
lrwxrwxrwx 1 root root  16 2006-05-05 09:11 025_libsane.rules - 
../libsane.rules
lrwxrwxrwx 1 root root  22 2006-04-03 10:08 025_logitechmouse.rules - 
../logitechmouse.rules
lrwxrwxrwx 1 root root  12 2006-05-09 08:25 050_hal-plugdev.rules - 
../hal.rules
-rw-r--r-- 1 root root  82 2006-03-05 14:14 90-hal.rules
lrwxrwxrwx 1 root root  19 2006-04-04 09:49 cd-aliases.rules - 
../cd-aliases.rules
lrwxrwxrwx 1 root root  13 2006-04-04 09:49 udev.rules - ../udev.rules
lrwxrwxrwx 1 root root  25 2006-04-05 16:38 z20_persistent-input.rules - 
../persistent-input.rules
lrwxrwxrwx 1 root root  19 2006-04-04 09:49 z20_persistent.rules - 
../persistent.rules
-rw-r--r-- 1 root root 473 2006-05-09 11:08 z25_persistent-net.rules
lrwxrwxrwx 1 root root  33 2006-05-09 11:08 z45_persistent-net-generator.rules 
- ../persistent-net-generator.rules
lrwxrwxrwx 1 root root  12 2006-04-04 09:49 z50_run.rules - ../run.rules
lrwxrwxrwx 1 root root  16 2006-04-04 09:49 z55_hotplug.rules - 
../hotplug.rules
lrwxrwxrwx 1 root root  17 2006-04-04 09:49 z70_hotplugd.rules - 
../hotplugd.rules

-- /sys/:
/sys/block/fd0/dev
/sys/block/hda/dev
/sys/block/ram0/dev
/sys/block/ram1/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/block/sda/dev
/sys/block/sda/sda1/dev
/sys/block/sda/sda2/dev
/sys/block/sda/sda5/dev
/sys/block/sdb/dev
/sys/block/sdb/sdb1/dev
/sys/block/sdb/sdb2/dev
/sys/block/sdb/sdb5/dev
/sys/block/sdc/dev
/sys/block/sdc/sdc1/dev
/sys/block/sdd/dev
/sys/block/sdd/sdd1/dev
/sys/block/sde/dev
/sys/block/sde/sde1/dev
/sys/class/input/input0/event0/dev
/sys/class/input/input1/event1/dev
/sys/class/input/input2/event2/dev
/sys/class/input/input2/mouse0/dev
/sys/class/input/mice/dev
/sys/class/misc/hpet/dev
/sys/class/misc/psaux/dev
/sys/class/misc/rtc/dev
/sys/class/printer/lp0/dev
/sys/class/scsi_generic/sg0/dev
/sys/class/scsi_generic/sg1/dev
/sys/class/scsi_generic/sg2/dev
/sys/class/scsi_generic/sg3/dev
/sys/class/scsi_generic/sg4/dev
/sys/class/scsi_generic/sg5/dev
/sys/class/usb_device/usbdev1.1/dev

-- Kernel configuration:


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages udev depends on:
ii  initscripts   

Bug#366853: udev: vol_id returns incorrect information for my root device

2006-05-11 Thread Kay Sievers
 I've found that the problem appears to be related to vol_id failing to
 find proper information for my root device, /dev/sda1.  I've run the
 commands 'e2label', '/lib/udev/vol_id', 'mount' and 'fdisk' with the
 following results:

Never use any of the all broken mkfs* tools without writing zeros to the
start and the end of the partition before applying a different format.
Overwrite at least 64kb. (Sane formatting applications like everything that
is libparted based don't need this.)

Kay


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



Bug#366853: udev: vol_id returns incorrect information for my root device

2006-05-11 Thread Bob McGowan

Wonderful ;(

There's nothing in any of the installation documentation that I can 
remember that warns me about any of this.  I suppose this could be 
considered a documentation bug?


As mentioned in my response to Kay Sievers, so far as I know this system 
had never had any other operating system than Linux installed.  It's a 
Dell server originally purchased with Red Hat 7.0 or 7.1 installed at 
the factory.  This could of course be part of the problem, in that the 
tools used by that OS are relatively old.  It's not something I'd 
considered, prior to hearing from Kay.


The tool I used to create the filesystem is whatever it is that's in 
the basic Debian etch net install.  I have no idea what tool is actually 
run, in this case.  Can you provide a pointer or two, as to who I should 
contact or what package is involved?


Thank you.

Marco d'Itri wrote:

On May 11, Kay Sievers [EMAIL PROTECTED] wrote:



Never use any of the all broken mkfs* tools without writing zeros to the
start and the end of the partition before applying a different format.
Overwrite at least 64kb. (Sane formatting applications like everything that
is libparted based don't need this.)


The upstream maintainer is right, this cannot really be fixed in udev
because a filesystem may contain ambiguous metadata.
I am closing the bug, I suggest you further discuss this with the
maintainer of the tool you used to create the file system.




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



Bug#366853: udev: vol_id returns incorrect information for my root device

2006-05-11 Thread Marco d'Itri
On May 12, Bob McGowan [EMAIL PROTECTED] wrote:

 There's nothing in any of the installation documentation that I can 
 remember that warns me about any of this.  I suppose this could be 
 considered a documentation bug?
I agree with Kay that this should be considered a bug in the program
used to create the file system.

 As mentioned in my response to Kay Sievers, so far as I know this system 
 had never had any other operating system than Linux installed.  It's a 
 Dell server originally purchased with Red Hat 7.0 or 7.1 installed at 
 the factory.  This could of course be part of the problem, in that the 
 tools used by that OS are relatively old.  It's not something I'd 
 considered, prior to hearing from Kay.
It may had a FAT file system on it, I understand that some hard disks
get one in the factory.
Our mke2fs should probably have overwritten the beginning and the end of
the partition anyway.

 The tool I used to create the filesystem is whatever it is that's in 
 the basic Debian etch net install.  I have no idea what tool is actually 
 run, in this case.  Can you provide a pointer or two, as to who I should 
 contact or what package is involved?
I suggest you discuss this with the e2fsprogs maintainer, Theodore Ts'o
[EMAIL PROTECTED].

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#366853: udev: vol_id returns incorrect information for my root device

2006-05-11 Thread Marco d'Itri
On May 12, md wrote:

 I suggest you discuss this with the e2fsprogs maintainer, Theodore Ts'o
 [EMAIL PROTECTED].
Or even better ask about this on debian-boot, it could be argued that
it's up to whatever d-i uses to partition the disk to deal with it.

-- 
ciao,
Marco


signature.asc
Description: Digital signature