Mallaichte

Learning experience: A typo in fstab

I made an error during an activity in my studies that, in other circumstances, could have been a disaster. Here’s what happened and here’s what I learned.

This took place today while studying a topic in the Open University TM129 – Technologies in practice module. The topic is on disk management and the activity related to mounting a disk on Linux. At this stage I hade already created a virtual disk and attached it to my Linux VM in VirtualBox. It has been, partioned, formatted and temporarily mounted with the mount command. Now it was time to learn how to ensure it mounts on startup with the fstab file.

After making the necessary amendments to /etc/fstab to have both partitions mount as FAT and ext4 respectively, I reboot the VM to check that it worked. That was when I was hit with an error message: root account is locked.

Oops! Did I do that? Well… yeah. I must have, but how? Well the title probably gave this away but I was just working on the fstab file which is used during the boot process, so that is a good starting point. Good thing I was documenting the activity with screenshots, so I could take another look at what I entered in the file before saving. Depending on your sense of humour, it may amuse you to know that I mistyped vfat with an extra character (assuming you have a QWERTY keyboard, look next to the T and guess what extra character and where). Great! Now I know the problem can I fix it?

If I can’t fix this then it’s no big deal. Not only am I using a VM, but I made a clone just before the start of this batch of activities. But let’s see if I can fix this first. Pressing Enter to continue just resulted in the message being repeated. The same with recovery mode from the GRUB menu.

I also thought about removing the disk (detaching through settings) in the hopes that this would cause the boot to skip over this part of the process. With no disk to mount, it doesn’t matter what the file system is, right? That probably didn’t matter because now the boot was dealing with a missing drive instead. However, this still led to the same boot error.

I started to look into ways to attach and mount the the VMs main disk image (sda) to another VM so I could edit the file, but this was a linked clone and I wasn’t sure how that would affect my approach. It was only while typing up a post in the module forums that a simpler solution occurred to me. I don’t need to take that disk image into another distro, I could still launch another distro from the same faulty VM using a live boot image.

Although it wasn’t necessary to use this particular distro for this problem, I did have an excuse to try out KNOPPIX. After all, it is intended for recovery purposes. So I loaded an ISO into the virtual optical drive, boot up the VM and from KNOPPIX (though just about any distro should work for this particular issue) found and amended the fstab file (/media/sda1/etc/fstab). “eject” the disc and reboot. Problem solved!

What did I learn?

• First of all, you can’t take too much care when checking your work on critical system files (or commands).
  • I was more concerned with the partitions and folders, and making sure I didn’t type unmask that I missed the actual mistake. Call it a brainfart (not sorry).
• It doesn’t hurt to document your work.
• VMs are a good way to get some practice in on this type of thing without puting your actual computer at risk.
• Making clones of VMs are a good way of protecting progress you’ve made on an actual VM.
• Many errors can be recovered from even if they initially appear to be a disaster.