amtm amtm - the Asuswrt-Merlin Terminal Menu

[thelonelycoder]

This was on my AC86U with a 2TB ext4 HDD.

Let me check that with an SSD and HDD.
The original script I copied the code from will act the same, I'm sure.

 

[skeal]

This happened to me when I first got the old script. It stayed that way until a hint from you guys. dos2unix fixed it and it started working. Not sure if this is relevant information.

 

[Adamm]

This happened to me when I first got the old script. It stayed that way until a hint from you guys. dos2unix fixed it and it started working. Not sure if this is relevant information.

Line endings on the script are fine, the file permissions were alittle off but that again was irrelevant (-rw-rw-rw-). I'll take a look in the morning if @thelonelycoder hasn't found the cause by then, I'm sure its a simple scripting error somewhere.

 

[thelonelycoder]

Line endings on the script are fine, the file permissions were alittle off but that again was irrelevant (-rw-rw-rw-).

pre-mount is 0755, while the actual check file disk-check does not need 0755 since it is sourced from pre-mount and therefore inherits the rights.

I'll take a look in the morning if @thelonelycoder hasn't found the cause by then, I'm sure its a simple scripting error somewhere.

80GB SSD is fine:

Mar  5 23:55:21 amtm: Running disk check 'e2fsck -p' on /dev/sdb1
Mar  5 23:55:21 amtm: Disk check done on /dev/sdb1
Mar  5 23:55:21 syslog: USB ext4 fs at /dev/sdb1 mounted on /tmp/mnt/ext4ssd
Mar  5 23:55:21 usb: USB ext4 fs at /dev/sdb1 mounted on /tmp/mnt/ext4ssd.
Mar  5 23:55:21 kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: user_xattr

 

[thelonelycoder]

This happened to me when I first got the old script. It stayed that way until a hint from you guys. dos2unix fixed it and it started working. Not sure if this is relevant information.

The check script disk-check is directly created and written from within amtm, the code is 100% unix EOL.

 

[thelonelycoder]

I'm using EXT2 for flash drive and EXT4 for MyBook 4TB.

In the terminal, enter:

fdisk -l

I'm interested in the tail of the output. For my two thumb drives I get Linux (sda1 and sda2) as the identifier, for the ext4 SSD (sdb) its the same:

Disk /dev/sda: 8020 MB, 8020819968 bytes
247 heads, 62 sectors/track, 1022 cylinders
Units = cylinders of 15314 * 512 = 7840768 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               1         511     3912696  83 Linux
/dev/sda2             512        1022     3912727  83 Linux

Disk /dev/sdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sdb1               1        9729    78148161  83 Linux

 

[Adamm]

pre-mount is 0755, while the actual check file disk-check does not need 0755 since it is sourced from pre-mount and therefore inherits the rights.


80GB SSD is fine:

Mar  5 23:55:21 amtm: Running disk check 'e2fsck -p' on /dev/sdb1
Mar  5 23:55:21 amtm: Disk check done on /dev/sdb1
Mar  5 23:55:21 syslog: USB ext4 fs at /dev/sdb1 mounted on /tmp/mnt/ext4ssd
Mar  5 23:55:21 usb: USB ext4 fs at /dev/sdb1 mounted on /tmp/mnt/ext4ssd.
Mar  5 23:55:21 kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: user_xattr

So quickly glancing over the script, the issue seems to be within;

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

I assume $1 in my case would be /dev/sda1 ... Unfortunately that string isn't showing in fdisk to grep, to essentially we are grepping nothing hence the case statement failing.

Here's the fdisk output by itsself;

admin@RT-AC86U-2EE8:/jffs/scripts# fdisk -l ${1:0:8}

Disk /dev/mtdblock0: 95 MB, 95027200 bytes
255 heads, 63 sectors/track, 11 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/mtdblock0 doesn't contain a valid partition table

Disk /dev/mtdblock1: 95 MB, 95027200 bytes
255 heads, 63 sectors/track, 11 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/mtdblock1 doesn't contain a valid partition table

Disk /dev/mtdblock2: 8 MB, 8388608 bytes
255 heads, 63 sectors/track, 1 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/mtdblock2 doesn't contain a valid partition table

Disk /dev/mtdblock3: 1 MB, 1048576 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/mtdblock3 doesn't contain a valid partition table

Disk /dev/mtdblock4: 99 MB, 99614720 bytes
255 heads, 63 sectors/track, 12 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/mtdblock4 doesn't contain a valid partition table

Disk /dev/mtdblock5: 99 MB, 99614720 bytes
255 heads, 63 sectors/track, 12 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/mtdblock5 doesn't contain a valid partition table

Disk /dev/mtdblock6: 4 MB, 4587520 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/mtdblock6 doesn't contain a valid partition table

Disk /dev/mtdblock7: 4 MB, 4587520 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/mtdblock7 doesn't contain a valid partition table

Disk /dev/mtdblock8: 50 MB, 50331648 bytes
255 heads, 63 sectors/track, 6 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/mtdblock8 doesn't contain a valid partition table

Disk /dev/mtdblock9: 8 MB, 8388608 bytes
255 heads, 63 sectors/track, 1 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/mtdblock9 doesn't contain a valid partition table
Found valid GPT with protective MBR; using GPT

Disk /dev/sda: 3906963456 sectors, 3057M
Logical sector size: 512
Disk identifier (GUID): 8f22e256-1fcf-4034-8764-a8c67d3bcf65
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3906963422

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      3906961407       1862G   0700  Basic data partition
admin@RT-AC86U-2EE8:/jffs/scripts#

Do note this is post mount, im too tired to remember if this would affect the output. Hope this helps while I get some much needed zzzz's

 

[Klaus]

This is what I get:

Disk /dev/sda: 30965760 sectors, 14.7G
Logical sector size: 512
Disk identifier (GUID): 4e0a6ba0-3da4-03a7-e89a-821369cfe900
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30965726

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        30963711       14.7G   0700  Basic data partition
fdisk: device has more than 2^32 sectors, can't use all of them
Found valid GPT with protective MBR; using GPT

Disk /dev/sdb: 4294967295 sectors, 2047G
Logical sector size: 512
Disk identifier (GUID): 4306a34d-4557-45fd-a196-e2d6bd6cabd5
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7814035422

Number  Start (sector)    End (sector)  Size       Code  Name
   1            4096      7814035415       3726G   0700  Linux data partition

 

[thelonelycoder]

I assume $1 in my case would be /dev/sda1 ... Unfortunately that string isn't showing in fdisk to grep, to essentially we are grepping nothing hence the case statement failing.

While booting pre-mount is called with the device as argument, hence $1 would be /dev/whateverdevice
If run manually, you'd have to do the same.
But the problem is the identifier, same for @Klaus :

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      3906961407       1862G   0700  Basic data partition

I'd have to do some digging, but Basic data partition is nowhere near Linux.
And likely neither is Linux data partition @Klaus , what is the return of:

fdisk -l ${1:0:8} | grep /dev/sdb | cut -c55-65

It will be:

Linux data partition

Which is not recognised since the script only looks for Linux.

 

[thelonelycoder]

Aargh...
No one ever complained or made a remark about the original filesystem check script not working. At least I have never come across a complaint.
It has the same limitation that it only supports a small set of partitions. For lack of testing out the identifiers for other types, as the author writes in his verbose tutorial.

So here I am, trying to help users fix their file errors by simplifying installation of said script and what do I end up in?
Some sort of Armageddon! With both sides only intending to do good.

But we'll sort it out and will end up with another great addition to the collection of Asuswrt-Merlin scripts.

 

[Klaus]

But the problem is the identifier, same for @Klaus :

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      3906961407       1862G   0700  Basic data partition

I'd have to do some digging, but Basic data partition is nowhere near Linux.
And likely neither is Linux data partition @Klaus , what is the return of:

fdisk -l ${1:0:8} | grep /dev/sdb | cut -c55-65

It will be:

Linux data partition

Which is not recognised since the script only looks for Linux.

The output of that command is actually:

fdisk: device has more than 2^32 sectors, can't use all of them

 

[thelonelycoder]

The output of that command is actually:

fdisk: device has more than 2^32 sectors, can't use all of them

It's 1 o'clock in the morning, for both of us. Good night!

 

[Butterfly Bones]

Aargh...
No one ever complained or made a remark about the original filesystem check script not working. At least I have never come across a complaint.
It has the same limitation that it only supports a small set of partitions. For lack of testing out the identifiers for other types, as the author writes in his verbose tutorial.

So here I am, trying to help users fix their file errors by simplifying installation of said script and what do I end up in?
Some sort of Armageddon! With both sides only intending to do good.

But we'll sort it out and will end up with another great addition to the collection of Asuswrt-Merlin scripts.

Many of us appreciate your work to solve simple issues like this. I ran the script you linked on GitHub and removed it before AMTM update.

I strongly suspect you just put this check script into much more wide distribution than the original script did. I only found it after stumbling into a post after continually search for a solution to my USB errors after every single reboot.

I'm curious if @Klaus and @Adamm ran that script before today when amtm introduced it? Obviously not. Sorry to see you shoot yourself in the foot. As a friend states often -
"No good deed goes unpunished."

 

[thelonelycoder]

I've just pushed an amtm update, no version change

This moves the disk-check log file date to beginning of line, following the command it runs.
It also reports to disk-check log if unknown type is encountered.
Therefore, the logfile will be created even if none of the filesystems are known.

Also, more Linux partitions should be checked now as I have expanded known types from Linux to Linux*.

Run u to update amtm, then dc to remove existing disk-check script and dc again to re-create it with the new settings.
Removing dc also removes the existing dcl logfile, which is stored at /jffs/amtm-disk-check.log

 

[thelonelycoder]

I have formatted and partitioned my largest spare HDD (1TB, sdb) and have 100% success:

Disk /dev/sda: 8020 MB, 8020819968 bytes
247 heads, 62 sectors/track, 1022 cylinders
Units = cylinders of 15314 * 512 = 7840768 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               1         511     3912696  83 Linux
/dev/sda2             512        1022     3912727  83 Linux

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sdb1               1        5637    45279171  83 Linux
/dev/sdb2            5638      121601   931480830  83 Linux

To format disks I use a physical CentOS box, so that might be the reason why it reports a proper Linux identifier.

From the dc logfile:

 Tue Mar  6 09:45:41 MEZ 2018 Starting 'e2fsck -p install'
 hddsecond: clean, 550/58220544 files, 3735214/232870207 blocks

 Tue Mar  6 09:45:43 MEZ 2018 Starting 'e2fsck -p install'
 hddfirst: clean, 7084/2834432 files, 675643/11319792 blocks

 

[XIII]

This is what I get on an ext2 USB flash drive (though formatted using a 3rd party tool on Windows, maybe that causes problems?):

Tue Mar  6 10:29:34 CET 2018 Starting 'fatfsck -a install'
 fatfsck 3014.9.11
 Checking boot region...
 Error: Not a FAT volume - Invalid end of sector signature: 0x0
 Floating point exception

 

[thelonelycoder]

This is what I get on an ext2 USB flash drive (though formatted using a 3rd party tool on Windows, maybe that causes problems?):

Tue Mar  6 10:29:34 CET 2018 Starting 'fatfsck -a install'
 fatfsck 3014.9.11
 Checking boot region...
 Error: Not a FAT volume - Invalid end of sector signature: 0x0
 Floating point exception

Looks like pre-mount it is seen as FAT, but partitions are ext* and recognized once mounted.
What's your output of

fdisk -l

 

[Adamm]

To format disks I use a physical CentOS box, so that might be the reason why it reports a proper Linux identifier.

That could be the common issue here, I use MiniTool Partition Wizard to format the drive

 

[HardCat]

@thelonelycoder - Will amtm menu option 3 update Entware to the 64-bit version for the RT-AC86U? Or should that be done manually? Thanks...

 

[thelonelycoder]

@thelonelycoder - Will amtm menu option 3 update Entware to the 64-bit version for the RT-AC86U? Or should that be done manually? Thanks...

No, please no. It will not do that.
You'd either have to wait for AB4 to come out or start from scratch, with first manually installing Entware-3x, then amtm and create a swap file, then AB and whatever else you might want to install.