Bad File Descriptor

[EmeraldDeer]

Int step 2 above: Does the OS support GPT with ext4?

While the OS may support GPT disks, I have found that amtm disk check script does not support GPT. It returns "Unknown filesystem type'. If I do nothing, the entware filesystem will never have a full e2fsck.

Found valid GPT with protective MBR; using GPT

Disk /dev/sda: 976773168 sectors,  465G
Logical sector size: 512
Disk identifier (GUID): 74e5cee0-c1af-03a9-b873-39dd6b70ea00
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         4194303       2047M   0700  Basic data partition
   2         4194304         8388607       2048M   0700  Basic data partition
   3         8388608       847249407        400G   0700  Basic data partition

The ext4 filesystems on the GPT disk show in both fdisk and gdisk as code 0700 when it should be 8300. I am not sure why Minitool Partition Wizard does this. Without a solid indicator, I do do not see @thelonelycoder considering adding GPT support to amtm disk check script.

FSTYPE=$(fdisk -l ${1:0:8} | grep $1 | cut -c55-65)

case "$FSTYPE" in
   Linux*) CHKCMD="e2fsck -p";;
   Win95* | FAT*) CHKCMD="fatfsck -a";;
   HPFS/NTFS) CHKCMD="ntfsck -a";;
   *) logger -t amtm "Disk check: Unknown filesystem type $FSTYPE on $1 - skipping check."
  printf "\n$(date) Unknown filesystem type $FSTYPE on $1 - skipping check.\n" >> /jffs/amtm-disk-check.log
  exit 1;;
esac

logger -t amtm "Running disk check '$CHKCMD' on $1"
printf "\n$(date) Starting '$CHKCMD $1'\n" >> /jffs/amtm-disk-check.log
$CHKCMD $1 >> /jffs/amtm-disk-check.log 2>&1
logger -t amtm "Disk check done on $1"

For now, I will just do this crude hack when I think of it:

#FSTYPE=$(fdisk -l ${1:0:8} | grep $1 | cut -c55-65)
FSTYPE=Linux

 

[ColinTaylor]

The ext4 filesystems on the GPT disk show in both fdisk and gdisk as code 0700 when it should be 8300.

There are a couple of problems here. Firstly, the use of partition type codes is arbitrary and therefore might not represent the actual filesystem being used. This is true for both MBR and GPT. There's an interesting insight into this from the author of GPT fdisk here. So this method of identifying the filesystem type is unreliable.

Secondly, it is unwise to trust any of the partition information returned by a non-GPT compatible version of fdisk. The purpose of the protective MBR is only to indicate that you shouldn't be using it. This is especially true when using disks with a capacity greater than 2TB. It is impossible for an MBR to address (and therefore display) any start or end locations beyond the 2TB limit.

@RMerlin Given the problems above of identifying the filesystem present in a partition, would you consider passing a second parameter ($2) to pre-mount that contains the filesystem type? This information has already been detected in usb.c just before pre-mount is called:

    if ((type = detect_fs_type(dev_name)) == NULL)
        return 0;

    find_label_or_uuid(dev_name, the_label, uuid);

    run_custom_script_blocking("pre-mount", dev_name, NULL);

This would also help to prevent inappropriate operations on incompatible filesystems, such e2fsck on swap or vfat.

 

[EmeraldDeer]

There are a couple of problems here. Firstly, the use of partition type codes is arbitrary and therefore might not represent the actual filesystem being used. This is true for both MBR and GPT. There's an interesting insight into this from the author of GPT fdisk here. So this method of identifying the filesystem type is unreliable.

Agreed, but nevertheless the partition table is all that amtm disk check has. As far as I can tell, the MBR partition table with fdisk has been good enough for amtm disk check to determine three filesystem types.

Secondly, it is unwise to trust any of the partition information returned by a non-GPT compatible version of fdisk. The purpose of the protective MBR is only to indicate that you shouldn't be using it. This is especially true when using disks with a capacity greater than 2TB. It is impossible for an MBR to address (and therefore display) any start or end locations beyond the 2TB limit.

Agreed, but fdisk can be assumed while gdisk is an extra Entware install. In this context we are not doing any sector math, we just want to know which filesystem type (if any) is contained in each partition. An automatic boot time full filesystem check only makes sense for a small Entware filesystem. Anything else should be done manually.

So I thought to myself that surely gdisk would provide better information than fdisk does against a protective MBR. And it turns out not so much. Note that gdisk allows changing the Code without losing the filesystem but it is not reflected in the protective MBR.

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         4194303   2.0 GiB     0700  Basic data partition
   2         4194304         8388607   2.0 GiB     0700  Basic data partition
   3         8388608       847249407   400.0 GiB   8300  Basic data partition

MBR in practice in this regard is better than GPT. However, I do not regret using GPT because maximum reliability is my concern.

EDIT: That is an interesting find in usb.c

 

[EmeraldDeer]

There is another "shared" rather than "rc" usb.c which does the low level swap/filesystem detection. It is written specifically for MBR, not GPT.
https://github.com/RMerl/asuswrt-me...9d5b48f6e/release/src/router/shared/usb.c#L66

 

[ColinTaylor]

There is another "shared" rather than "rc" usb.c which does the low level swap/filesystem detection. It is written specifically for MBR, not GPT.
https://github.com/RMerl/asuswrt-me...9d5b48f6e/release/src/router/shared/usb.c#L66

They're both part of the same thing. release/src/router/rc/usb.c calls detect_fs_type and detect_fs_type is in release/src/router/shared/usb.c. It's the output of that function that would be useful if it was passed to pre-mount.

Whilst it does detect MBR partitions I don't believe that it is dependent on that. It is just looking for known signatures of the device it is passed, be that a partition table, swap or a filesystem. This is the same code that the router uses to mount the filesystems and we already know that it can mount filesystems in GPT partitions. So having that extra piece of information would solve your disk check problem.

 

[ColinTaylor]

In this context we are not doing any sector math, we just want to know which filesystem type (if any) is contained in each partition.

That was my second point. It's nothing to do with sector maths. If a partition starts after the 2TB limit of the protected MBR then it won't show up at all in the router's fdisk output. As far as AMTM is concerned it doesn't exist. And there have been quite a few posts here from people that have attached disks larger than 2TB to their routers. I'm not saying this is a common problem, just that it can happen.

 

[ColinTaylor]

If a partition starts after the 2TB limit of the protected MBR then it won't show up at all in the router's fdisk output. As far as AMTM is concerned it doesn't exist.

@EmeraldDeer Merlin and John recently committed the change I suggested in post #22. This has led me to look again at this in a bit more detail. I'm embarrassed to say that my statement above is not true. When I wrote it I was using a different version of fdisk. I can see from the firmware changelogs that GPT and large disk support was added to fdisk in the past. That doesn't mean that fdisk can edit GPT disks but it is "GPT aware" and appears to be able to show the partition sizes correctly (as per your post #23), although I can't verify this as I don't have a disk larger than 2TB.

If you're interested I am working on an updated disk check script that uses the new parameter discussed in post #22. The script is compatible with John's current firmware but you'll have to wait for that change to be released by Merlin.

 

[maxbraketorque]

Was the OP's issue resolved and/or was its cause determined?

 

[EmeraldDeer]

Was the OP's issue resolved and/or was its cause determined?

https://www.snbforums.com/threads/bad-file-descriptor.54784/#post-470801

The OP nuked it from space.

With regard to GPT USB drives, I will continue to use disk-check with a hacked hard code of FSTYPE as a workaround for now while keeping an eye on Colin's effort.

 

[maxbraketorque]

https://www.snbforums.com/threads/bad-file-descriptor.54784/#post-470801

The OP nuked it from space.

With regard to GPT USB drives, I will continue to use disk-check with a hacked hard code of FSTYPE as a workaround for now while keeping an eye on Colin's effort.

Thanks. I wasn't sure if OP meant that he had eliminated the issue.