0

I have a new google compute engine instance running CentOS6 with two persistent storage volumes attached. I have followed the instructions here: https://cloud.google.com/compute/docs/disks/add-persistent-disk

My attached volumes are:

/dev/sdb or /dev/disk/by-id/google-admin-backup
/dev/sdc or /dev/disk/by-id/google-admin-media

/etc/fstab looks like:

UUID=6e64a346-b01d-45d6-8bb0-549535b4b3cc /                       ext4    defaults,barrier=1 1 1
/dev/sdb        /backups        ext4    defaults    0 0
/dev/disk/by-id/google-admin-media /www/icapture/capture    ext4    discard,defaults    1   1
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

note: I realize that I am pointing at the disks differently, I have tried both by doing the /dev/sdc and the /by-id/ way

My problem is that when I reboot the machine /www/icapture/capture doesn't mount.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        59G  5.3G   51G  10% /
tmpfs           2.9G     0  2.9G   0% /dev/shm
/dev/sdb        493G   70M  467G   1% /backups

However, I can simply do 

sudo mount /www/icapture/capture

And it mounts correctly.

I would like my volumes to mount on boot. What am I overlooking that is preventing /www/icapture/capture from mounting at boot?

For reference: From /var/log/dmesg

    scsi0 : Virtio SCSI HBA
scsi 0:0:1:0: Direct-Access     Google   PersistentDisk   1    PQ: 0 ANSI: 6
scsi 0:0:2:0: Direct-Access     Google   PersistentDisk   1    PQ: 0 ANSI: 6
scsi 0:0:3:0: Direct-Access     Google   PersistentDisk   1    PQ: 0 ANSI: 6
sd 0:0:2:0: [sdb] 1048576000 512-byte logical blocks: (536 GB/500 GiB)
sd 0:0:1:0: [sda] 125829120 512-byte logical blocks: (64.4 GB/60.0 GiB)
sd 0:0:1:0: [sda] 4096-byte physical blocks
sd 0:0:3:0: [sdc] 209715200 512-byte logical blocks: (107 GB/100 GiB)
sd 0:0:3:0: [sdc] 4096-byte physical blocks
sd 0:0:1:0: [sda] Write Protect is off
sd 0:0:1:0: [sda] Mode Sense: 1f 00 00 08
sd 0:0:3:0: [sdc] Write Protect is off
sd 0:0:3:0: [sdc] Mode Sense: 1f 00 00 08
sd 0:0:1:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:3:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda:
 sdc: sda1
 unknown partition table
sd 0:0:2:0: [sdb] 4096-byte physical blocks
sd 0:0:2:0: [sdb] Write Protect is off
sd 0:0:1:0: [sda] Attached SCSI disk
sd 0:0:3:0: [sdc] Attached SCSI disk
sd 0:0:2:0: [sdb] Mode Sense: 1f 00 00 08
sd 0:0:2:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sdb: unknown partition table
sd 0:0:2:0: [sdb] Attached SCSI disk
Dustin Simpson
  • 101
  • 2
  • Are there any relevant messages in your logs ? – user9517 Jul 01 '16 at 15:36
  • Thank you for the quick reply. I added a section of /var/log/dmesg I read up on the "unkown partition table" message and apparently you can get that if you format the entire disk instead of partitioning. Looks like Google is recommending *not* partitioning though. I appreciate any help you can give. – Dustin Simpson Jul 01 '16 at 15:58
  • That's for sdb, you appear to be having trouble with sdc? – user9517 Jul 01 '16 at 16:03
  • You are correct, sdc. I apologize for introducing confusion :) – Dustin Simpson Jul 01 '16 at 16:04
  • 2
    I'm voting to close this question as off-topic because errors and omissions in external documentation should be addressed to their author so they can be corrected. – user9517 Jul 01 '16 at 16:04
  • Do you really think it is a Google problem? I can certainly go that direction with them, I just find it hard to believe that I set up two and one works fine. Seems more likely it is something I am doing wrong. – Dustin Simpson Jul 01 '16 at 16:06
  • 1
    If you have followed the documentation correctly then it must be a documentation error. – user9517 Jul 01 '16 at 16:15
  • I have purchased gold support from Google and will report back the findings. – Dustin Simpson Jul 02 '16 at 19:42

1 Answers1

1

Configuration of your /etc/fstab is correct except dump and pass values for /dev/sdc. Setting 1 1 value for a non-root file system might circumvent auto-mounting under some circumstances. The recommended values for dump and pass are described in manual of FSTAB(5):

The fifth field, (fs_freq), is used for these filesystems by the dump(8) command to determine which filesys- tems need to be dumped. If the fifth field is not present, a value of zero is returned and dump will assume that the filesystem does not need to be dumped.

The sixth field, (fs_passno), is used by the fsck(8) program to determine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.

Kamran
  • 1,415
  • 7
  • 16