I put

/dev/sdb1               /                       ext3    defaults        1 1

in /etc/fstab as a workaround.

This more sounds like an installer bug; was this during install?

FYI fstab-sync won't add entries to /etc/fstab if the drive is fixed; it only
works for hotpluggable and removable drives.

I think it was after I added

LABEL=/                 /mnt/rhel3              ext3    defaults        1 2

to /etc/fstab and did

# mount -av

Next time when I rebooted machine, / entry was gone. lshal shows

udi = '/org/freedesktop/Hal/devices/block_d6abef0d-75c3-495d-b126-683a3b169d0a'
 volume.mount_point = '/'  (string)
  volume.policy.desired_mount_point = 'scsidisk'  (string)
  volume.policy.mount_filesystem = 'ext3'  (string)
  volume.policy.should_mount = false  (bool)
  info.udi =
'/org/freedesktop/Hal/devices/block_d6abef0d-75c3-495d-b126-683a3b169d0a'  (string)
  volume.partition.msdos_part_table_type = 238  (0xee)  (int)
  volume.size = 10485743104  (0x270ffbe00)  (uint64)
  volume.block_size = 512  (0x200)  (int)
  volume.num_blocks = 20479967  (0x1387fdf)  (int)
  volume.partition.number = 1  (0x1)  (int)
  volume.is_partition = true  (bool)
  volume.is_mounted = true  (bool)
  volume.is_disc = false  (bool)
  volume.uuid = 'd6abef0d-75c3-495d-b126-683a3b169d0a'  (string)
  volume.label = '/1'  (string)
  volume.fsversion = ''  (string)
  volume.fsusage = 'filesystem'  (string)
  volume.fstype = 'ext3'  (string)
  info.product = '/1'  (string)
  block.storage_device =
'/org/freedesktop/Hal/devices/block_ST373453LC-3HW2GQ6M00007521UMX3'  (string)
  block.minor = 17  (0x11)  (int)
  block.major = 8  (0x8)  (int)
  info.capabilities = 'block volume'  (string)
  info.category = 'volume'  (string)
  info.parent =
'/org/freedesktop/Hal/devices/block_ST373453LC-3HW2GQ6M00007521UMX3'  (string)
  block.device = '/dev/sdb1'  (string)
  block.is_volume = true  (bool)
  block.have_scanned = false  (bool)
  block.no_partitions = false  (bool)
  linux.sysfs_path_device = '/sys/block/sdb/sdb1'  (string)
  linux.sysfs_path = '/sys/block/sdb/sdb1'  (string)
  info.bus = 'block'  (string)

fstab-sync will only remove entries if the 'managed' option is set so I don't
know why your /etc/fstab entry for LABEL=/1 was removed. 

IIRC, the fstab-sync shipped with RHEL4 prints messages to the /var/log/messages
logfile when it modifies the /etc/fstab file. So, to questions

 1. Is there anything there about fstab-sync removing the mount point
    for LABEL=/1?

 2. Are there entries for removing/adding the entry for /media/cdrom?
    (should be on every boot)

There are

Mar 16 17:25:33 gnu-4 fstab-sync[3123]: removed all generated mount points
Mar 16 17:25:34 gnu-4 fstab-sync[3270]: added mount point /media/cdrom for /dev/scd0

My / entry has

  volume.policy.should_mount = false  (bool)
  volume.partition.msdos_part_table_type = 238  (0xee)  (int)

As stated in comment 2 fstab-sync will not add an /etc/fstab entry for your
device that has LABEL=/1 - that is per design.  

If you manually add the entry to /etc/fstab is it still there after a reboot?

When I added LABEL=/1 entry by hand, it was gone after hald started. It seems
that hald doesn't like my / partition.

Please paste exactly the line that disappears.

After adding it, try running 'fstab-sync --clean'. Is it gone after that?

I have 2 disks, sda and sdb, on my ia64 machine. The EFI partition is on
sda. My sdb has a GPT partition table:

[root@gnu-4 tools]# parted /dev/sdb
GNU Parted 1.6.19
Copyright (C) 1998 - 2004 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.  See the GNU General Public License for more details.

Using /dev/sdb
(parted) p
Disk geometry for /dev/sdb: 0.000-70007.196 megabytes
Disk label type: gpt
Minor    Start       End     Filesystem  Name                  Flags
1          0.017  10000.000  ext3
2      10000.000  20000.000  ext2
3      20000.000  70007.180  ext3
(parted)

But fdisk sees it as

[root@gnu-4 tools]# fdisk /dev/sdb

The number of cylinders for this disk is set to 8924.
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/sdb: 73.4 GB, 73407865856 bytes
255 heads, 63 sectors/track, 8924 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        8925    71687368+  ee  EFI GPT

But hal doesn't handle it right. It thinks my sdb1 as

  volume.policy.should_mount = false  (bool)
  volume.partition.msdos_part_table_type = 238  (0xee)  (int)
  volume.partition.number = 1  (0x1)  (int)

The fix is to make hal, or libraries used, to correctly handle GPT
partition, like parted.

Can't hal just use libparted? It will reduce code duplication and handle
all types of partition tables correctly.

Any updates for this bug?

Is anyone working on it? I can give it a try if no one is working on it.

HJ at Intel - still need your help on this one.

What kinds of help do you need?

From Intel last year, reposting...

Can't hal just use libparted? It will reduce code duplication and handle
all types of partition tables correctly.

Upstream says that they will not move to libparted because it is a large change
and volume_id is far wider tested and deployed.  We are looking into patching
the internal libvolume_id to support GPT.

Last time when I checked, libparted supported many more partition tables and
anaconda used pyparted which used libparted. I doubt libparted is less
tested than volume_id when dealing with partion tables.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Hi,

I'm the upstream maintainer of HAL. It is true that the HAL shipped in RHEL4
doesn't handle GPT partition tables correctly insofar that the property

 volume.partition.msdos_part_table_type

is exported even for GPT partitions. This is minor issue only, because HAL still
gets the partitions right due to the fact that the kernel have a GPT partition
table scanner. And no software besides HAL itself uses the property
volume.partition.msdos_part_table_type so even if you hotplug a USB harddisk
with GPT things will still work.

It's also important to keep in mind that the HAL version in RHEL4 was never
designed to handle anything but removable and hotpluggable drives and media so
while it's certainly possible to add a new property, say
volume.partition.gpt_part_table_uuid it wouldn't buy you much.

As such, there is little incentive for adding this feature.

By the way, more sophisticated partition table scanning is planned for future
upstream HAL releases that will eventually be part of a RHEL release. Thanks.

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.