Freshly formatted disk and fixdisk finds things to grumble about

M

mumble_myopia

New Member
Is this to be expected - it sounds wrong to me but maybe it is ok.
Whizzing by too fast ATM to be specific but I can see "Illegal blocks"
Can post the log if wanted when done but it is the general Q I am asking ATM

Ta in advance
 
Doesn't sound good, no, but "illegal blocks" sounds like a file system thing rather than a HDD thing. You formatted it how?

I wouldn't worry too much, just let fix-disk do its thing. The killer will be how the HDD/file system performs subsequently.
 
formatted using the Hummy standard system menu (obviously prior to installing the custom FW)
ta, sort of what I thought/hoped but considering how few operations there had been, I was mightily surprised
 
mumble_myopia said:
Is this to be expected - it sounds wrong to me but maybe it is ok.
Click to expand...
I had that too when I used the Humax formatter. I was just as perplexed. I reformatted the partitions manually in maintenance mode:
Code: 
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda1
humax# mkfs.ext3 -m 0 -O sparse_super -T largefile /dev/sda2
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda3
 
prpr said:
I had that too when I used the Humax formatter. I was just as perplexed. I reformatted the partitions manually in maintenance mode:
Code: 
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda1
humax# mkfs.ext3 -m 0 -O sparse_super -T largefile /dev/sda2
humax# /
Click to expand...
Many thanks for all that - nice to know it is not just me ;-)
I've stopped the fixdisk and will use your spell - if, as I suspect, these are soft (file system structure errors) rather than hard (media problems), there's not much point in continuing the run.
I had to umount the volumes 1st
I'm just running fixdisk after that (me being the eternal sceptic!)
 
... and following that recipe and adding the WebIf resulted in fixdisk being happy as Larry :)
Many thanks!

It does make me wonder how the on screen menu format made a horlicks of it though
 
The Humax binary that does the on-screen disk format calls functions from /usr/lib/libext2fs.so.2 (actually .2.4), so they basically implemented their own mke2fs. One can imagine how horlickingly well that went: well enough not to block shipping, but no better. The same library is invoked indirectly by the disk maintenance utilities in /sbin, but we can choose the parameters when running them.

However the filesystem checks seem to be done by running fsck, judging by these strings in the binary (-p for startup check, -f -y for manually initiated):
Code: 
e2fsck -F -j ext3 -p %s
e2fsck -F -j ext3 -f -y %s

The CF libext2fs.so.2.4 contains version string 1.41.11. A more recent build of e2fsprogs (eg 1.42.13) is available as a package but wouldn't normally be available in Maintenance Mode. The package versions build monolithic programs with no libext2fs.

Strangely there are actual duplicates of all the CF e2fsprogs libraries from /usr/lib in /usr/lib/ext. The firmware programs all seem to be bound to the /usr/lib versions, including the main programs in /usr/lib/ext/bin that are invoked from the /sbin scripts. A chance to get 600kB back in CF ?3.15? with some straightforward hard-linking (I wondered: stat shows no extra links)?
 
/df said:
The Humax binary that does the on-screen disk format calls functions from /usr/lib/libext2fs.so.2 (actually .2.4), so they basically implemented their own mke2fs. One can imagine how horlickingly well that went: well enough not to block shipping, but no better. The same library is invoked indirectly by the disk maintenance utilities in /sbin, but we can choose the parameters when running them.

However the filesystem checks seem to be done by running fsck, judging by these strings in the binary (-p for startup check, -f -y for manually initiated):
Code: 
e2fsck -F -j ext3 -p %s
e2fsck -F -j ext3 -f -y %s

The CF libext2fs.so.2.4 contains version string 1.41.11. A more recent build of e2fsprogs (eg 1.42.13) is available as a package but wouldn't normally be available in Maintenance Mode. The package versions build monolithic programs with no libext2fs.

Strangely there are actual duplicates of all the CF e2fsprogs libraries from /usr/lib in /usr/lib/ext. The firmware programs all seem to be bound to the /usr/lib versions, including the main programs in /usr/lib/ext/bin that are invoked from the /sbin scripts. A chance to get 600kB back in CF ?3.15? with some straightforward hard-linking (I wondered: stat shows no extra links)?
Click to expand...
Wow! That is a significantly complete answer and makes sense as I read it. Many thanks!
 
You must log in or register to reply here.
Back
Top