fsck needs /dev in path to check an ext4 partition

fsck needs /dev in path to check an ext4 partition

[Jonny Grant]

Hello

Apologies I am not using 2.36.1 yet. I'm on latest Ubuntu LTS, but it's using 2.34



I noticed fsck only works if I write as "/dev/sdb1" not just "sdb1" I was in /dev/ as root, so it shouldn't need long path?


These work as expected when called from /dev/ as user root

# fsck.ext4 sdb1  
# fsck.ext4 /dev/sdb1  

This does not work:
# fsck sdb1

Looking at the output, it seems like fsck sometimes goes through to e2fsck and otherwise goes through to fsck.ext4 and then fails.
If I call fsck.ext4 directly it does work.

Could fsck be changed to not require the full /dev/sdb1 path?

Seems a bit risky it defaults to trying to check a device without anything being specified.

# fsck
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/sda5 is mounted.
e2fsck: Cannot continue, aborting.


root@abc:/dev# fsck sdb1
fsck from util-linux 2.34
Usage: fsck.ext4 [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
		[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
		[-E extended-options] [-z undo_file] device

Emergency help:
 -p                   Automatic repair (no questions)
 -n                   Make no changes to the filesystem
 -y                   Assume "yes" to all questions
 -c                   Check for bad blocks and add them to the badblock list
 -f                   Force checking even if filesystem is marked clean
 -v                   Be verbose
 -b superblock        Use alternative superblock
 -B blocksize         Force blocksize when looking for superblock
 -j external_journal  Set location of the external journal
 -l bad_blocks_file   Add to badblocks list
 -L bad_blocks_file   Set badblocks list
 -z undo_file         Create an undo file



root@abc:/dev# fsck -p /dev/sdb1
fsck from util-linux 2.34
Ext4fste: clean, 458/237104 files, 117884/947120 blocks

Cheers, Jonny

Re: fsck needs /dev in path to check an ext4 partition

[John Paul Adrian Glaubitz]

Hello Jonny!

On 1/15/21 9:06 PM, Jonny Grant wrote:
> Apologies I am not using 2.36.1 yet. I'm on latest Ubuntu LTS, but it's using 2.34
> 
> I noticed fsck only works if I write as "/dev/sdb1" not just "sdb1" I was in /dev/ as
> root, so it shouldn't need long path?
> 
> These work as expected when called from /dev/ as user root
> 
> # fsck.ext4 sdb1  
> # fsck.ext4 /dev/sdb1  
> 
> This does not work:
> # fsck sdb1

That's because it must be:

# fsck.ext4 ./sdb1

Filenames are expanded by your shell in this case, not by the fsck utilities.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: fsck needs /dev in path to check an ext4 partition

[Jonny Grant]

Hello Adrian!

On 15/01/2021 20:15, John Paul Adrian Glaubitz wrote:
> Hello Jonny!
> 
> On 1/15/21 9:06 PM, Jonny Grant wrote:
>> Apologies I am not using 2.36.1 yet. I'm on latest Ubuntu LTS, but it's using 2.34
>>
>> I noticed fsck only works if I write as "/dev/sdb1" not just "sdb1" I was in /dev/ as
>> root, so it shouldn't need long path?
>>
>> These work as expected when called from /dev/ as user root
>>
>> # fsck.ext4 sdb1  
>> # fsck.ext4 /dev/sdb1  
>>
>> This does not work:
>> # fsck sdb1
> 
> That's because it must be:
> 
> # fsck.ext4 ./sdb1
> 
> Filenames are expanded by your shell in this case, not by the fsck utilities.
> 
> Adrian

My apologies, I had just used # fdisk sdb
that does work # fsck.ext4 ./sdb1

However, fsck still has the issue even with # fsck ./sdb1
It only works with the full path. I'm sure I used to always just call fsck.

root@abc:/dev# fsck ./sdb1
fsck from util-linux 2.34
Usage: fsck.ext4 [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
		[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
		[-E extended-options] [-z undo_file] device

Emergency help:
 -p                   Automatic repair (no questions)
 -n                   Make no changes to the filesystem
 -y                   Assume "yes" to all questions
 -c                   Check for bad blocks and add them to the badblock list
 -f                   Force checking even if filesystem is marked clean
 -v                   Be verbose
 -b superblock        Use alternative superblock
 -B blocksize         Force blocksize when looking for superblock
 -j external_journal  Set location of the external journal
 -l bad_blocks_file   Add to badblocks list
 -L bad_blocks_file   Set badblocks list
 -z undo_file         Create an undo file
root@abc:/dev#
root@abc:/dev# fsck /dev/sdb1
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Ext4fs: clean, 458/237104 files, 117884/947120 blocks

Re: fsck needs /dev in path to check an ext4 partition

[Theodore Ts'o]

On Fri, Jan 15, 2021 at 09:15:02PM +0100, John Paul Adrian Glaubitz wrote:
> Hello Jonny!
> 
> On 1/15/21 9:06 PM, Jonny Grant wrote:
> > Apologies I am not using 2.36.1 yet. I'm on latest Ubuntu LTS, but it's using 2.34
> > 
> > I noticed fsck only works if I write as "/dev/sdb1" not just "sdb1" I was in /dev/ as
> > root, so it shouldn't need long path?
> > 
> > These work as expected when called from /dev/ as user root
> > 
> > # fsck.ext4 sdb1  
> > # fsck.ext4 /dev/sdb1  
> > 
> > This does not work:
> > # fsck sdb1
> 
> That's because it must be:
> 
> # fsck.ext4 ./sdb1
> 
> Filenames are expanded by your shell in this case, not by the fsck utilities.

That's not what is going on --- and it has nothign to do with PATH
searching.  The way fsck parses its arguments is that it has to
distinguish between:

* device names ("/dev/sdb1")
* label or UUID specifiers (e.g., "LABEL=backup")
* options to be interpreted by fsck (e.g., "-N")
* options to be interpreted by the fsck.XXX driver (e.g., "-f")
* arguments to fsck.XXX's options (e.g.,"discard" in  "-E discard")

The generic fsck driver doesn't know that for fsck.ext4 (aka e2fsck)
that -E takes an argument.  So when you run something like "fsck -E
discard /dev/sdb1", fsck can't distinguish between the file "discard"
in your current working directory, and passing in multiple devices
which are designed to be running in parallel, e.g.: "fsck -p /dev/sda3
/dev/sdb1".

The bottom line is if you want to pass a pathname to a device, it must
not be a relative pathname.

It also means that if you need to pass in an argument to a pathname, e.g.:

	/sbin/e2fsck -j /dev/VG/ext-journal /dev/VG/filesystem

you can't just do something like:

	/sbin/fsck -j /dev/VG/ext-journal /dev/VG/filesystem

since /dev/VG/ext-journal won't be interpreted as an argument to the
-j option.   You could do something like:

	/sbin/fsck /dev/VG/filesystem -- -j /dev/VG/ext-journal

But honestly, you're probably better just explicitly specifying the
file system driver specifier (e.g., /sbin/fsck.ext4 or /sbin/e2fsck)
instead of using the fsck front-end.

The original use of fsck was so we could run multiple fsck processes
in parallel.  With distributions which use systemd, the only real
value which fsck adds is that it will automatically figure out the
file system type.  But if you're manually running fsck, most of the
time you know the file system type --- and if you are using filesystem
type specific option, you really do know the file system type ahead of
time, so you might as well skip using the fsck front-end.

Cheers,

            	     	      	   - Ted
			   

Re: fsck needs /dev in path to check an ext4 partition

[John Paul Adrian Glaubitz]

Hi Ted!

On 1/15/21 10:59 PM, Theodore Ts'o wrote:
> That's not what is going on --- and it has nothign to do with PATH
> searching.  The way fsck parses its arguments is that it has to
> distinguish between:
> (...)

Thanks for the elaborate explanation, interesting tidbits about the
workings of fsck!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: fsck needs /dev in path to check an ext4 partition

[Jonny Grant]

On 15/01/2021 21:59, Theodore Ts'o wrote:
> On Fri, Jan 15, 2021 at 09:15:02PM +0100, John Paul Adrian Glaubitz wrote:
>> Hello Jonny!
>>
>> On 1/15/21 9:06 PM, Jonny Grant wrote:
>>> Apologies I am not using 2.36.1 yet. I'm on latest Ubuntu LTS, but it's using 2.34
>>>
>>> I noticed fsck only works if I write as "/dev/sdb1" not just "sdb1" I was in /dev/ as
>>> root, so it shouldn't need long path?
>>>
>>> These work as expected when called from /dev/ as user root
>>>
>>> # fsck.ext4 sdb1  
>>> # fsck.ext4 /dev/sdb1  
>>>
>>> This does not work:
>>> # fsck sdb1
>>
>> That's because it must be:
>>
>> # fsck.ext4 ./sdb1
>>
>> Filenames are expanded by your shell in this case, not by the fsck utilities.
> 
> That's not what is going on --- and it has nothign to do with PATH
> searching.  The way fsck parses its arguments is that it has to
> distinguish between:
> 
> * device names ("/dev/sdb1")
> * label or UUID specifiers (e.g., "LABEL=backup")
> * options to be interpreted by fsck (e.g., "-N")
> * options to be interpreted by the fsck.XXX driver (e.g., "-f")
> * arguments to fsck.XXX's options (e.g.,"discard" in  "-E discard")
> 
> The generic fsck driver doesn't know that for fsck.ext4 (aka e2fsck)
> that -E takes an argument.  So when you run something like "fsck -E
> discard /dev/sdb1", fsck can't distinguish between the file "discard"
> in your current working directory, and passing in multiple devices
> which are designed to be running in parallel, e.g.: "fsck -p /dev/sda3
> /dev/sdb1".
> 
> The bottom line is if you want to pass a pathname to a device, it must
> not be a relative pathname.
> 
> It also means that if you need to pass in an argument to a pathname, e.g.:
> 
> 	/sbin/e2fsck -j /dev/VG/ext-journal /dev/VG/filesystem
> 
> you can't just do something like:
> 
> 	/sbin/fsck -j /dev/VG/ext-journal /dev/VG/filesystem
> 
> since /dev/VG/ext-journal won't be interpreted as an argument to the
> -j option.   You could do something like:
> 
> 	/sbin/fsck /dev/VG/filesystem -- -j /dev/VG/ext-journal
> 
> But honestly, you're probably better just explicitly specifying the
> file system driver specifier (e.g., /sbin/fsck.ext4 or /sbin/e2fsck)
> instead of using the fsck front-end.
> 
> The original use of fsck was so we could run multiple fsck processes
> in parallel.  With distributions which use systemd, the only real
> value which fsck adds is that it will automatically figure out the
> file system type.  But if you're manually running fsck, most of the
> time you know the file system type --- and if you are using filesystem
> type specific option, you really do know the file system type ahead of
> time, so you might as well skip using the fsck front-end.


Thank you for the reply Ted.

I'll stick to using fsck.ext4 directly I think, and the /dev/sdb1 to keep it simple.

Cheers, Jonny