nwsp2 classic gpt support

[fvdw]

So no changes

yes proceed with that step

[minibike12]

Ok, this will take 30~45 minutes i think.
Writing 22329 inode tables.

Code: Select all

root@fvdwsl-base:/ # mke2fs -j /dev/loop1
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
182919168 inodes, 731666546 blocks
36583327 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
22329 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Writing inode tables:   313/22329


When this is done, use fdisk /dev/sda again.
And when this is ok still use this :

Code: Select all

mkdir /tmp/mountpoint


Or should i use an other command?

[fvdw]

yes check with fdisk after finishing it

Creation of the mountpoint should work as the directory is r/w

if it doesn't work try to create a mountpoint in root folder (mkdir /mountpoint)

In fact this should have no negative effects as it is only a folder that is create and mount command tells the kernel to forward requests coming in the "folder" to be forwarded to the device mounted on it (in this case /dev/loop0)

[minibike12]

Okey.
Will post fdisk as soon as it is done.
And i wil try /tmp/mountpoint first.
If this does not work, i will use /mountpoint

I used /dev/loop1 instead of /dev/loop0 (not that it matters).

[fvdw]

ok, yes I meant /dev/loop1 ;)

[Mijzelf]

Can you also execute

Code: Select all

losetup -a

This should list all active loopdevices. I'm wondering if the offset is read correct.

[minibike12]

It is now busy making filesystem with mke2fs -j
Should i use losetup -a when this is done next to fdisk.
Also, is it smart to use

Code: Select all

mount

again to look if everything is ok?

[Mijzelf]

The sequence doesn't matter, and yes, it's a good idea to check the mounts. BTW, you can just open a second shell, and do some analytics in parallel.

[fvdw]

Can you also execute

Code: Select all

losetup -a

This should list all active loopdevices. I'm wondering if the offset is read correct.

There will be only one loop device active in this case, the one we defined here. The other one will appear when defining a disk image to be used with back side usb port.

why should it be read incorrect ?. If the offset was wrong then you would expect it destroyed at least sda7. Mike was still able to mount that and read the directory content. Maybe the problem is having file system bigger then 2.2 TB on the reaming space confusing the bootloader (not likely as it does not read it AFAIK. But if this is the cause then case my suggestion to make a partition sda8 of 2 TB and then using the remaining space with a loop device is a possible workaround. In that case the reaming space will be less then 2 TB. Disadvantage will be that this extra space will need to be mounted on a shared folder present in sda8. It will then be available as one share. Another possibility would be defining a second volume in the firmware, but that will require quite some changes, so not a solution at short notice.

[Mijzelf]

why should it be read incorrect ?.

The value is >2^31 and smaller than 2^32. For a signed int this means that the value can either truncate, or swap negative. I think losetup doesn't have such bugs, as 4GiB is not extremely big, when talking about disks and files. But you'll never know. (BTW, where did you get this losetup?)

If the offset was wrong then you would expect it destroyed at least sda7. Mike was still able to mount that and read the directory content.

Define 'destroy'. When writing a file system only some sectors are written (did I read 27000, some posts ago?). So the main part of the loopdevice isn't touched. If you randomly overwrite some sectors in a filesystem, there is a good chance it will mount fine. Maybe a full filesystem check could tell something is wrong, but maybe not.

Maybe the problem is having file system bigger then 2.2 TB on the reaming space confusing the bootloader

Don't think so. The bootloader reads the partition table, and reads the uImage from partition 6. That's all. And the start of this filesystem is semi-random. Read with any other offset it's just noise.

Disadvantage will be that this extra space will need to be mounted on a shared folder present in sda8. It will then be available as one share. Another possibility would be defining a second volume in the firmware, but that will require quite some changes, so not a solution at short notice.

You could create a JBOD volume. But I suppose that also takes some firmware changes.