[PLUG] fsck: recommended options?

wes plug at the-wes.com
Sun Aug 4 18:44:54 UTC 2019


On Sun, Aug 4, 2019 at 11:13 AM Rich Shepard <rshepard at appl-ecosys.com>
wrote:

> On Sun, 4 Aug 2019, wes wrote:
>
> > fsck does pretty well without parameters. If you wish to dispense with
> the
> > need to authorize any repairs it suggests, having it just perform them,
> you
> > can supply -p and/or -y.
>
> Wes/Cathy:
>
> At first, fsck did not work when I specified the device as /dev/sdb which
> is
> how I access it when I need to restore a specific file. In /etc/fstab
> that's
> how it's listed:
> /dev/sdb         /mnt/hd          ext3        noauto,users,rw  0   0
>
> Looking at the output of fdisk -l found no /dev/sdb, but a /dev/sdc which
> is
> not specifically in /etc/fstab. What is shown in that file is:
>
> UUID=da596a77-2fb4-41ed-881c-a3f8bb0ab437 /mnt/backup  auto defaults  0 0
>
> and fsck is working its way through the 500G on that drive.
>
> I'd like to understand how, when I turn on the drive after logging off so
> cron can run dirvish each night, it's mounted on /mnt/backup as /dev/sdc
> through the UUID designation, but when I want to access it manually I can
> mount /dev/sdb on /dev/hd.
>
> TIA,
>
>
Insufficient data for a meaningful answer.

My best guess is that it's simple luck: on the occasion(s) you wanted to
access the drive manually, it happened to be identified as sdb. Today, it
happens to have been assigned sdc.

This inability to predict which device name will be assigned to a given
device is the reason the switch to the UUID method was done.

-wes



More information about the PLUG mailing list