Bug 1006883

Maybe, the current RHEL6.4 image has the same problem.

https://rhn.redhat.com/rhn/software/channel/downloads/Download.do?cid=16952

Etsuji,

Can you go into more detail as to why those entries should be removed? Basic boot/login testing looks ok from my perspective, just need to know for documentation rather than blindly removing them. This will also affect the default kvm image so we also need to make sure it's compatible with opentack / rhevm and as just a standalone kvm image.

First, due to the wrong /dev/sda1 entry, wrong /dev/sda1 entry is recorded in /etc/mtab and as a result, mount or df command shows the wrong /dev/sda1 entry even though there's no such a device file.
----------------
$ mount
/dev/sda1 on / type ext4 (rw,noatime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
none on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda1        5905712 1979400   3866316  34% /
tmpfs            1027324       0   1027324   0% /dev/shm
none             1027324       0   1027324   0% /dev/shm
 
$ ls -l /dev/sda1
ls: cannot access /dev/sda1: No such file or directory
----------------

lsblk command shows the correct device on the other hand.
----------------
$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    252:0    0   20G  0 disk 
`-vda1 252:1    0  5.7G  0 part /

$ ls -l /dev/vda1
brw-rw----. 1 root disk 252, 1 Sep 11 18:08 /dev/vda1
----------------

Secondly, duplicated enties of pseudo-devices, they are doubly mounted. For example:
---------------------
$ mount | grep /dev/shm
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
none on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
$ umount /dev/shm
umount: it seems /dev/shm is mounted multiple times
---------------------

IMHO, /etc/fstab is really a fundamental configuration in Linux. If it's not reasonably/appropiately configured (even if it passes some black box test cases), it confuses a lot of system admins and causes a mistrust in the fundamental stability of the system.

I tested it with OpenStack Grizzly, by the way.

I hit this in the RHEL 6.4 images as well. In my case it caused issues with doing kernel updates as grubby reads /etc/mtab and gets confused and fails with:

grubby fatal error: unable to find a suitable template

This makes bootable volumes / snapshots (persistence) etc less useful in openstack so i wound up editing the image BEFORE importing into glance with:

guestfish --rw -a sys-rhel-server-x86_64-kvm-6.4_20130130.0-8-sda.qcow2 -i edit /etc/fstab

Worked perfectly after that :-)

Verified:
  rhel-guest-image-6-6.5-20131101.2-1-sda.qcow2

-bash-4.1# cat /etc/fstab 
UUID=1a3c3989-0ace-471c-9ded-f37cd5e7600c  / ext4    defaults,noatime 0 0
devpts     /dev/pts  devpts  gid=5,mode=620   0 0
tmpfs      /dev/shm  tmpfs   defaults         0 0
proc       /proc     proc    defaults         0 0
sysfs      /sys      sysfs   defaults         0 0
-bash-4.1# cat /etc/mtab
/dev/vda1 / ext4 rw,noatime 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw,rootcontext="system_u:object_r:tmpfs_t:s0" 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
-bash-4.1# df
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/vda1        5905728 882236   4963492  16% /
tmpfs             509988      0    509988   0% /dev/shm
-bash-4.1# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    252:0    0    6G  0 disk 
└─vda1 252:1    0  5.7G  0 part /
-bash-4.1# ls -l /dev/vda1
brw-rw----. 1 root disk 252, 1 Nov  3 20:39 /dev/vda1
-bash-4.1#

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1735.html