Microsoft Storage Space and ImDisk issues

I don't have one set up, but a user of Easy2Boot was using the MPI Tool Kit which uses ImDisk to create a backing file for a virtual FAT32 volume.

He found that if the backing file was created on a 'Microsoft storage space pool with software RAID 1 (mirroring) on a 3.6 TB partition' no error was returned by ImDisk, but the UUID was 0000-0000 and files could not be copied to the virtual drive. Screenshot attached.

Is this to be expected in this situation?

P.S. UUID is obtained using secinspect -dsec \\.\U: 0 1  after the ImDisk command completed.

Edited by steve6375, 07 July 2018 - 07:14 PM.

... like it  was mounted without (or before) being formatted?

Maybe it is a timing problem.

Wonko

What does "the UUID" refer to in this case? A disk id? Or a volume serial number? Or something else? In any case it cannot be a UUID since UUID values (also called GUID) are 16 bit numbers usually formatted as a hex string with a rather different format compared to the format shown here.

its obtained by reading the first sector of the FAT32 partition.

I think it is just a side effect of the partition not being formatted.

Hi you both ,

it's normally used as numeric-volume-name  , so in linux too, there a fstab from OpenMandriva..

UID and GID be User-Identification number and Group Identification, so UID and GID  in the Userland ..

slowly also in Win10 for more coming in direction linux and supporting the Linux variables too and mappng the name, becase with numbers be more possible for possibility's and like in the past up to now on the Web ip mapping to the human read able "Names" (webname.domain) from this is coming the whole, because with numbers be more possibility to decide, and later it's more possible to decide for mapping this number with the builddate/number of the Factoryname of the harddisk, with exactly this UUID and saving later for a recognition of this device with this volumes and partitions .. because on this it's also possible for make a device UUID and at this point it is coming the confusion "danger" because a couples peoples of programmers do not really know and use a couple of different UUID for it and then becomes a muddled up.

sda = harddisk0

sdb = harddisk1

sdc = harddisk2

sdd = harddisk3

sde = harddisk4

sda1= Harddisk0/partition0  /+unique UUID

sda2= Harddisk0/partition1  /+unique UUID

sda3= Harddisk0/partition2  /+unique UUID

sda4= Harddisk0/partition3  /+unique UUID

sda5= Harddisk0/partition-extended-0  /+unique UUID

sda6= Harddisk0/partition-extended-1  /+unique UUID

sdb1= Harddisk1/partition0  /+unique UUID

sdb2= Harddisk1/partition1  /+unique UUID

sdb3= Harddisk1/partition2  /+unique UUID

sdb4= Harddisk1/partition3  /+unique UUID

sdb5= Harddisk1/partition-extended-0  /+unique UUID

sdb6= Harddisk1/partition-extended-1  /+unique UUID

the UUID it is setting up by creating and formatting of the partitions (imho) and it is writing also in the partitions tables.

therewith it is possible for changing/moving the hardware on different ports and be ever found to use..

so can you use this partition on port sda or sdz and the partition with UUID it is ever found and

mounting in the right mount point and can mount on the right place, behind the boot of the bootloader

up to the fstab and booting the system with the right partitions to the right mount points .

best regards

Blacky

What does "the UUID" refer to in this case? A disk id? Or a volume serial number? Or something else? In any case it cannot be a UUID since UUID values (also called GUID) are 16 bit numbers usually formatted as a hex string with a rather different format compared to the format shown here.

It depends.

That is the field "Volume Serial" of the PBR.

grub4dos (as an example) uses it as UUID (for FAT volumes).

The Windows GUID has the different format you mention.

See also:

http://reboot.pro/to...ed-drive-image/

Wonko

Ah, so it is actually the volume serial number from the VBR in this case? I was just surprised to see the term UUID refer to something that is obviously not a UUID (aka GUID). UUID is a standard, a 16 bit number usually formatted as a hex string divided into groups. It is used a lot in Windows but not only there, GPT partitions use them too and many other cases where a globally unique identifier is required.

https://en.wikipedia...ique_identifier

Ah, so it is actually the volume serial number from the VBR in this case? I was just surprised to see the term UUID refer to something that is obviously not a UUID (aka GUID). UUID is a standard, a 16 bit number usually formatted as a hex string divided into groups. It is used a lot in Windows but not only there, GPT partitions use them too and many other cases where a globally unique identifier is required.

https://en.wikipedia...ique_identifier

Well, you were there on the mentioned thread:

http://reboot.pro/to...ed-drive-image/

so you should have been shocked at that time, not now.

Seriously , I believe that the use was initiated by good ol' GRUB a lot of years ago, before the UUID was defined in this or that standard.

As a side note (and JFYI) the actual GUID that Windows assigns to volumes (i.e. what you see in MOUNTVOL command) and NTFS Object_ID's are V1 and can be decoded to have the date they were created (and MAC):

https://www.forensic...586892/#6586892

Wonko

yes, the term 'UUID' is used by linux and grub2 and grub4dos for the PBR Volume Serial number.

e.g. 

search --no-floppy --fs-uuid --set fd0c6442-dc3d-49ba-8e46-91657460fe52
linux /boot/vmlinuz-2.6.31-17-generic root=UUID=fd0c6442-dc3d-49ba-8e46-91657460fe52 ro  
initrd /boot/initrd.img-2.6.31-17-generic

but all this is irrelevant. The points is that ImDisk is failing to make a formatted volume for some reason on an MS Storage Pool (apparently, I have not been able to personally test it).

@wonko

Haha okay, or I was just not in the mood to be shocked back then! (Or something like that.)

But yes, you are probably right. This could be a very old term confusion since we are talking about very old terminology.

@steve

Of course, sorry about the UUID discussion here. I can check and see what happens really. I am a little bit surprised how this could be any different from creating an image at any other kind of disk, physical or virtual. My "best guess" right now is that the formatting fails at some point because some kind of sector-alignment issue or something similar that relies on properties of underlying storage.

Yes, the volume U: seems to be made by ImDisk, but it does not seem to be formatted.

The user did also mention something about perhaps a timing issue as sometimes it seemed to work (but I did not diagnose this aspect with him).

I put a delay in of 4 seconds after the ImDisk command had completed, but he got the same error.

It's not a big problem as I can just say you have to use a 'real' volume and not a virtual one...

steve6375

Maybe if you "separate" the format command it will have enough time?

JFYI, you just posted a GRUB2 example showing NOT a PBR/VBR volume serial BUT rather a "well-formed" UUID. (right idea, wrong example)

Wonko

sorry, the point was that grub2, linux kernels and grub4dos all use the term 'UUID'.

sorry, the point was that grub2, linux kernels and grub4dos all use the term 'UUID'.

I understand, but the point is actually that calling UUID something *like* "fd0c6442-dc3d-49ba-8e46-91657460fe52" (as used by GRUB2 and Linux in most examples) is appropriate (and possibly fully conforming to the standards) whilst using UUID for something like "0AC4-AF63" (like grub4dos uses for FAT and NTFS volumes) is NOT (strictly speaking).

Even the grub4dos readme uses a "proper" UUID :

 

 

******************************************************************************
*** New command 'uuid' to identify partitions ***
******************************************************************************

Usage:

uuid [DEVICE] [UUID]

If DEVICE is not specified, search for filesystem with UUID in all partitions
and set the partition containing the filesystem as new root (if UUID is
specified), or just list uuid's of all filesystems on all devices (if UUID is
not specified). If DEVICE is specified, return true or false according to
whether or not the DEVICE matches the specified UUID (if UUID is specified),
or just list the uuid of DEVICE (if UUID is not specified).

Example 1:

find --set-root uuid () 7f95820f-5e33-4e6c-8f50-0760bf06d79c

which will find a partition with uuid=7f95820f-5e33-4e6c-8f50-0760bf06d79c
and set the partition as root if found.

Example 2:

uuid ()

which will print the uuid of the current root device.

in its example but that kind of UUID will only come out of the grub4dos UUID command for some filesystem/volumes (EXT2/3/4 and most other Unix/Linux "oriented" filesystems I believe), and also Linux uses the "non-UUID" for FATand NTFS:

https://wiki.debian.org/Part-UUID

 

 

UUID stands for Universally Unique Identifier and is a mechanism to give each filesystem a unique identifier. All Linux filesystems support filesystem UUIDs; FAT and NTFS filesystems don't support true UUIDs, but are still listed in /dev/disk/by-uuid with a unique identifier:

$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Oct 16 10:27 2d781b26-0285-421a-b9d0-d4a0d3b55680 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 16 10:27 31f8eb0d-612b-4805-835e-0e6d8b8c5591 -> ../../sda7
lrwxrwxrwx 1 root root 10 Oct 16 10:27 3FC2-3DDB -> ../../sda6
lrwxrwxrwx 1 root root 10 Oct 16 10:27 5090093f-e023-4a93-b2b6-8a9568dd23dc -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 16 10:27 912c7844-5430-4eea-b55c-e23f8959a8ee -> ../../sda5
lrwxrwxrwx 1 root root 10 Oct 16 10:27 B0DC1977DC193954 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 16 10:27 bae98338-ec29-4beb-aacf-107e44599b2e -> ../../sdb2

As you can see, the FAT and NTSF filesystems have shorter names (sda6 and sdb1), but are still listed by UUID. The point of the 32-digit base-62 strings is to make collisions astronomically unlikely; if it happened that sda1 and sda2 had the same UUID the system would fail to boot.

and GRUB2 of course follows the same implementation.

To sum up, the output of the UUID command in grub4dos can be:

1) for FAT12/16/32 the Volume serial, four bytes, two sets of two separated by a hyphen, i.e. "3A24-1219" (same as what you would find with the VOL command in Windows)

2) for NTFS the Volume serial (the "real" one, not the one shown in VOL command in windows)  8 bytes, no hyphen, i.e. "1D035E6A332C73C7"

3) for "Linux oriented filesystems" an actual UUID, i.e. bae98338-ec29-4beb-aacf-107e44599b2e

The Mountvol command in windows actually uses UUID's, i.e.:

\\?\Volume{dcb7316e-341c-11e3-b06c-001fc6bb76ce}\
E:\

that have NOTHING to do with the UUIDs generated by the UUID command in grub4dos (or similar in GRUB2 and Linux) as they are generated by the system at detection time (and they are V1 UUID's).

Wonko

What does "the UUID" refer to in this case? A disk id? Or a volume serial number? Or something else? In any case it cannot be a UUID since UUID values (also called GUID) are 16 bit numbers usually formatted as a hex string with a rather different format compared to the format shown here.

Ah, so it is actually the volume serial number from the VBR in this case? I was just surprised to see the term UUID refer to something that is obviously not a UUID (aka GUID). UUID is a standard, a 16 bit number usually formatted as a hex string divided into groups. It is used a lot in Windows but not only there, GPT partitions use them too and many other cases where a globally unique identifier is required.

https://en.wikipedia...ique_identifier

I would rather say: a 16-byte number.

I would rather say: a 16-byte number.

I would rather say a 16 bytes one

Wonko

I would rather say a 16 bytes one

I persist:
https://en.wikipedia.org/wiki/16-bit

If it is correct with "bit", it should be correct with "byte" as well.

I persist:
https://en.wikipedia.org/wiki/16-bit

If it is correct with "bit", it should be correct with "byte" as well.

No problem whatever , AFAICT both "16-byte" and "16 bytes" are correct, the hyphen makes the difference, anyway:

https://en.wikipedia...ique_identifier

it is actually a 128-bit number :

https://en.wikipedia.org/wiki/128-bit

 

In computer architecture, 128-bit integers, memory addresses, or other data units are those that are 128 bits (16 octets) wide. 

which is 128 bits wide.

Wonko

Sorry about "16-bit", of course I meant "16-byte"!