1

Silly me obliterated the contents of /etc/fstab via this:

echo xxxx xxxx xxxx xxx > /etc/fstab

Now the server is still up and running. How can I recover the contents of /etc/fstab before it fails upon the next reboot?

I remember something about anaconda which generated the file? Can it still be used to regenerate the file?

I want to recover a swap entry and a UUID entry (commented out or not) which I don't remember. Other entries than these 2 I can recover myself.

Are the 2 entries crucial in system reboot?

UPDATE

Here's the content of mount command:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=1931388k,nr_inodes=482847,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/vda1 on / type ext4 (rw,relatime,data=ordered)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=31,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
/dev/vdb1 on /mnt type ext4 (rw,relatime,data=ordered)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=388232k,mode=700)
tmpfs on /run/user/1006 type tmpfs (rw,nosuid,nodev,relatime,size=388232k,mode=700,uid=1006,gid=1006)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)

ls -l /dev/disk/by-uuid/

lrwxrwxrwx 1 root root 10 Jul 13 23:52 80b9b662-0a1d-4e84-b07b-c1bf19e72d97 -> ../../vda1
lrwxrwxrwx 1 root root 10 Jul 13 23:52 d5860b20-6f44-4731-a103-5ea4e1bd12e6 -> ../../vdb1

cat /etc/mtab

rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=1931388k,nr_inodes=482847,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/vda1 / ext4 rw,relatime,data=ordered 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=31,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
/dev/vdb1 /mnt ext4 rw,relatime,data=ordered 0 0
tmpfs /run/user/0 tmpfs rw,nosuid,nodev,relatime,size=388232k,mode=700 0 0
tmpfs /run/user/1006 tmpfs rw,nosuid,nodev,relatime,size=388232k,mode=700,uid=1006,gid=1006 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0

blkid

/dev/vda1: UUID="80b9b662-0a1d-4e84-b07b-c1bf19e72d97" TYPE="ext4"
/dev/vdb1: UUID="d5860b20-6f44-4731-a103-5ea4e1bd12e6" TYPE="ext4"

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       118G   48G   65G  43% /
devtmpfs        1.9G     0  1.9G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G  344K  1.9G   1% /run
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/vdb1       985G  226G  709G  25% /mnt
tmpfs           380M     0  380M   0% /run/user/0
tmpfs           380M     0  380M   0% /run/user/1006

cat /proc/swaps

Filename                                Type            Size    Used    Priority
/swapfile                               file            1048572 0       -1

The /etc/fstab file was actually very simple with just a UUID entry (commented out maybe) and a swap file entry before I was trying to add more entries to it and accidentally erasing it.

Can you please help me reconstruct it from the info above?

  • You can get a fair way to reconstructing it from the output of mount and cat /etc/mtab and restructuring it into a valid filesystem table. – DopeGhoti Jul 13 '17 at 16:37
  • You can find the UUIDs with blkid. And the rest you can confirm by checking /etc/mtab, as @DopeGhoti suggested. – giusti Jul 13 '17 at 16:43
  • Also, this answer contains a few remarks that would probably be useful to you: superuser.com/a/792178/682704 – giusti Jul 13 '17 at 16:45
  • @DopeGhoti Thank you so much for the help. I posted the contents of the various output in the question. Can you please help me reconstruct the /etc/fstab? I don't know what to put in /etc/fstab from there. – datasn.io Jul 13 '17 at 16:45
  • cat /proc/swaps as well – derobert Jul 13 '17 at 16:46
3

Making this community wiki to invite contribution from someone familiar with CentOS/RHEL 7.2

The UUIDs come from your blkid output. The paths come from the other output, and the filesystem type and options from /etc/mtab. The dump and fsck order fields are guesses. (I used the same fsck pass because it's two different disks.)

# dev                                     path  fs    opts     dump fsck
UUID=80b9b662-0a1d-4e84-b07b-c1bf19e72d97 /     ext4  relatime 0    1
UUID=d5860b20-6f44-4731-a103-5ea4e1bd12e6 /mnt  ext4  relatime 0    1

/swapfile                                 none  swap  sw       0    0

There are probably other things that need to go there (e.g., an entry for /proc or /sys). I don't have a CentOS 7.2 machine to check. Hence the community wiki for someone to complete this answer.

And once you've fixed your fstab, you next should fix your lack of backups. Even something as simple as installing etckeeper would have saved you here (though that's not really a backup, unless you git push it off the machine).

  • I see no /proc nor /sys entries in the original /etc/fstab. It didn't have any /dev/vda1 entry neither. What I'm recovering myself is this entry for the 1000GB disk: /dev/vdd1 /mnt ext4 defaults 0 0 – datasn.io Jul 13 '17 at 17:16
  • @kavoir.com Errr... your output clearly shows a vdb1 not vdd1 on /mnt. – derobert Jul 13 '17 at 17:17
  • Agh sorry you are right it's /dev/vdb1 – datasn.io Jul 13 '17 at 17:18
  • @kavoir.com And.... you have the original fstab available? I'm confused what you're asking us, then. – derobert Jul 13 '17 at 17:19
  • No I just remember it. I meant I saw, not I see. Sorry. Now I'm worried that when I reboot things would go haywire. – datasn.io Jul 13 '17 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.