How do I find a partition while in WSL2?

[linuxyne]

Attached is a sample binary which fills sector #0 with 0xcd 0xab 0xcd 0xab pattern. Use it with care if you do decide to, as it overwrites a region which usually contains MBR, on the virtual disk.

I wasn't able to upload the a.bin directly; please run the below command to decode:

Code: Select all

base64 -d a.txt > a.bin

# In case you want to see the instructions:

#Skip 32 bytes of multiboot header
dd if=a.bin of=b.bin skip=32 bs=1

objdump -D -b binary -m i386 b.bin

Code: Select all

qemu-system-i386 -kernel a.bin -hda disk.img -trace enable=ide_*
WARNING: Image format was not specified for 'disk.img' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
. . .
. . .

ide_ioport_write IDE PIO wr @ 0x1f6 (Device/Head); val 0x40; bus 0x5617afa3a4d0 IDEState 0x5617afa3a928
ide_ioport_write IDE PIO wr @ 0x1f2 (Sector Count); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f3 (Sector Number); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f4 (Cylinder Low); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f5 (Cylinder High); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f2 (Sector Count); val 0x01; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f3 (Sector Number); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f4 (Cylinder Low); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f5 (Cylinder High); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f7 (Command); val 0x34; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_exec_cmd IDE exec cmd: bus 0x5617afa3a4d0; state 0x5617afa3a558; cmd 0x34
ide_ioport_read IDE PIO rd @ 0x1f7 (Status); val 0x58; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558

ide_data_writew IDE PIO wr @ 0x1f0 (Data: Word); val 0xabcd; bus 0x5617afa3a4d0; IDEState 0x5617afa3a558
ide_data_writew IDE PIO wr @ 0x1f0 (Data: Word); val 0xabcd; bus 0x5617afa3a4d0; IDEState 0x5617afa3a558
. . .
# 256 such 0xabcd writes.
. . .
ide_data_writew IDE PIO wr @ 0x1f0 (Data: Word); val 0xabcd; bus 0x5617afa3a4d0; IDEState 0x5617afa3a558
ide_data_writew IDE PIO wr @ 0x1f0 (Data: Word); val 0xabcd; bus 0x5617afa3a4d0; IDEState 0x5617afa3a558

ide_sector_write sector=0 nsectors=1
ide_ioport_write IDE PIO wr @ 0x1f7 (Command); val 0xe7; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_exec_cmd IDE exec cmd: bus 0x5617afa3a4d0; state 0x5617afa3a558; cmd 0xe7

After the write is done, close qemu and check disk.img using hexdump to see if it wrote the pattern.
It helps if the disk.img is filled with zeros before running the binary.

Even with the warning, the data was written, and it remained persistent.

You may want to check if this binary works on your qemu setup.

---
Edit: In the qemu's monitor/compatmonitor view, run "info block" to see if there's anything that suggests that qemu is treating the disk as read-only.

Code: Select all

(qemu) info block
ide0-hd0 (#block108): disk.img (raw)
    Attached to:      /machine/unattached/device[23]
    Cache mode:       writeback
. . .

[Caffeine]

Attached is a sample binary which fills sector #0 with 0xcd 0xab 0xcd 0xab pattern. Use it with care if you do decide to, as it overwrites a region which usually contains MBR, on the virtual disk.

I wasn't able to upload the a.bin directly; please run the below command to decode:

Code: Select all

base64 -d a.txt > a.bin

# In case you want to see the instructions:

#Skip 32 bytes of multiboot header
dd if=a.bin of=b.bin skip=32 bs=1

objdump -D -b binary -m i386 b.bin

Code: Select all

qemu-system-i386 -kernel a.bin -hda disk.img -trace enable=ide_*
WARNING: Image format was not specified for 'disk.img' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
. . .
. . .

ide_ioport_write IDE PIO wr @ 0x1f6 (Device/Head); val 0x40; bus 0x5617afa3a4d0 IDEState 0x5617afa3a928
ide_ioport_write IDE PIO wr @ 0x1f2 (Sector Count); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f3 (Sector Number); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f4 (Cylinder Low); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f5 (Cylinder High); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f2 (Sector Count); val 0x01; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f3 (Sector Number); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f4 (Cylinder Low); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f5 (Cylinder High); val 0x00; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_ioport_write IDE PIO wr @ 0x1f7 (Command); val 0x34; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_exec_cmd IDE exec cmd: bus 0x5617afa3a4d0; state 0x5617afa3a558; cmd 0x34
ide_ioport_read IDE PIO rd @ 0x1f7 (Status); val 0x58; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558

ide_data_writew IDE PIO wr @ 0x1f0 (Data: Word); val 0xabcd; bus 0x5617afa3a4d0; IDEState 0x5617afa3a558
ide_data_writew IDE PIO wr @ 0x1f0 (Data: Word); val 0xabcd; bus 0x5617afa3a4d0; IDEState 0x5617afa3a558
. . .
# 256 such 0xabcd writes.
. . .
ide_data_writew IDE PIO wr @ 0x1f0 (Data: Word); val 0xabcd; bus 0x5617afa3a4d0; IDEState 0x5617afa3a558
ide_data_writew IDE PIO wr @ 0x1f0 (Data: Word); val 0xabcd; bus 0x5617afa3a4d0; IDEState 0x5617afa3a558

ide_sector_write sector=0 nsectors=1
ide_ioport_write IDE PIO wr @ 0x1f7 (Command); val 0xe7; bus 0x5617afa3a4d0 IDEState 0x5617afa3a558
ide_exec_cmd IDE exec cmd: bus 0x5617afa3a4d0; state 0x5617afa3a558; cmd 0xe7

After the write is done, close qemu and check disk.img using hexdump to see if it wrote the pattern.
It helps if the disk.img is filled with zeros before running the binary.

Even with the warning, the data was written, and it remained persistent.

You may want to check if this binary works on your qemu setup.

---
Edit: In the qemu's monitor/compatmonitor view, run "info block" to see if there's anything that suggests that qemu is treating the disk as read-only.

Code: Select all

(qemu) info block
ide0-hd0 (#block108): disk.img (raw)
    Attached to:      /machine/unattached/device[23]
    Cache mode:       writeback
. . .

Here's the qemu info block:

Code: Select all

../disk.img:     file format binary


Disassembly of section .data:

00000000 <.data>:
        ...

It should be writing to the hard disk and not the iso.
And data is being written to the drive. How do I see the ATA PIO driver is writing to the VHD and not the iso?

[linuxyne]

Here's the qemu info block:

Code: Select all

../disk.img:     file format binary


Disassembly of section .data:

00000000 <.data>:
        ...

That's not the output of the "info block" command.

It should be writing to the hard disk and not the iso.
And data is being written to the drive.

Is that a confirmation that a.bin wrote to the disk.img hard drive?
Note that the command line I gave in the example above did not assign a iso/cdrom.

How do I see the ATA PIO driver is writing to the VHD and not the iso?

Which device does your driver select before attempting the writes?

The a.bin sample binary begins by writing 0x40 to 0x1f6 (admittedly, it should write 0xe0 for back-ward compat); that selects the MASTER drive (DRV bit is being set to 0) on the PRIMARY (0x1f0) bus for LBA addressing(LBA bit is being set to 1). That corresponds with "-hda disk.img" option.

Edit: You may have to read up on how the boot order changes (if at all) the master/slave drive assignments on primary/secondary busses. If all this time we have been writing on to the ISO, then it is no surprise that the harddisk image remains unmodified.

[Caffeine]

That's not the output of the "info block" command.

I copied and pasted the wrong thing. Here is the right output.

Code: Select all

ide0-hd0 (#block112): disk.img (raw)
    Attached to:      /machine/unattached/device[23]
    Cache mode:       writeback

ide1-cd0 (#block359): Binaries/caffieneOS.iso (raw, read-only)
    Attached to:      /machine/unattached/device[24]
    Removable device: not locked, tray closed
    Cache mode:       writeback

Is that a confirmation that a.bin wrote to the disk.img hard drive?
Note that the command line I gave in the example above did not assign a iso/cdrom.

Here are the commands I used:

Code: Select all

dd if=a.bin of=../disk.img skip=32 bs=1
base64 -d a.txt > a.bin
objdump -D -b binary -m i386 ../disk.img

You may have to read up on how the boot order changes (if at all) the master/slave drive assignments on primary/secondary busses. If all this time we have been writing on to the ISO, then it is no surprise that the hard disk image remains unmodified.

Any links that you think would be useful?

Other than that, I checked using objdump -D -b binary -m i386 ../disk.img before and after writting to it, and the contents of the disk are different. Here is the output to to the command after writing some values to it: https://pastebin.com/YSk0EY2g

[linuxyne]

I copied and pasted the wrong thing. Here is the right output.

Code: Select all

ide0-hd0 (#block112): disk.img (raw)
    Attached to:      /machine/unattached/device[23]
    Cache mode:       writeback

ide1-cd0 (#block359): Binaries/caffieneOS.iso (raw, read-only)
    Attached to:      /machine/unattached/device[24]
    Removable device: not locked, tray closed
    Cache mode:       writeback

The harddisk is the PRIMARY:MASTER, and the cdrom is the SECONDARY:MASTER.

Here are the commands I used:

Code: Select all

dd if=a.bin of=../disk.img skip=32 bs=1
base64 -d a.txt > a.bin
objdump -D -b binary -m i386 ../disk.img

a.bin isn't supposed to be written into disk.img. a.bin is supposed to be run like so:

Code: Select all

# Download a.txt
base64 -d a.txt > a.bin

# Create an empty disk.img
qemu-img create -f raw disk.img 1M

# See the contents of disk.img. Should be all zeroes.
hexdump -C disk.img

# Run qemu
qemu-system-i386 -kernel a.bin -hda disk.img -trace enable=ide_*
# After the traces end (signifying that the qemu is done writing), close qemu

# See the contents of disk.img. Should have changed.
hexdump -C disk.img

a.bin is a small kernel meant to verify that your qemu setup does indeed write into the harddisk image.
It is to be used instead of your kernel. Since your kernel resides in an ISO, testing a.bin requires us to avoid specifying the cdrom.

You may have to read up on how the boot order changes (if at all) the master/slave drive assignments on primary/secondary busses. If all this time we have been writing on to the ISO, then it is no surprise that the hard disk image remains unmodified.

Any links that you think would be useful?

qemu's documentation should help.

It will help if you could upload your latest ISO somewhere, for me to test. It seems that there's a gap in our understanding of the problem.

[Caffeine]

I copied and pasted the wrong thing. Here is the right output.

Code: Select all

ide0-hd0 (#block112): disk.img (raw)
    Attached to:      /machine/unattached/device[23]
    Cache mode:       writeback

ide1-cd0 (#block359): Binaries/caffieneOS.iso (raw, read-only)
    Attached to:      /machine/unattached/device[24]
    Removable device: not locked, tray closed
    Cache mode:       writeback

The harddisk is the PRIMARY:MASTER, and the cdrom is the SECONDARY:MASTER.

Here are the commands I used:

Code: Select all

dd if=a.bin of=../disk.img skip=32 bs=1
base64 -d a.txt > a.bin
objdump -D -b binary -m i386 ../disk.img

a.bin isn't supposed to be written into disk.img. a.bin is supposed to be run like so:

Code: Select all

# Download a.txt
base64 -d a.txt > a.bin

# Create an empty disk.img
qemu-img create -f raw disk.img 1M

# See the contents of disk.img. Should be all zeroes.
hexdump -C disk.img

# Run qemu
qemu-system-i386 -kernel a.bin -hda disk.img -trace enable=ide_*
# After the traces end (signifying that the qemu is done writing), close qemu

# See the contents of disk.img. Should have changed.
hexdump -C disk.img

a.bin is a small kernel meant to verify that your qemu setup does indeed write into the harddisk image.
It is to be used instead of your kernel. Since your kernel resides in an ISO, testing a.bin requires us to avoid specifying the cdrom.

You may have to read up on how the boot order changes (if at all) the master/slave drive assignments on primary/secondary busses. If all this time we have been writing on to the ISO, then it is no surprise that the hard disk image remains unmodified.

Any links that you think would be useful?

qemu's documentation should help.

It will help if you could upload your latest ISO somewhere, for me to test. It seems that there's a gap in our understanding of the problem.

I ran the qemu command and nothing got written to the disk. Attached is the current ISO file, I am running it with the command:

Code: Select all

qemu-system-i386 -drive file=disk.img,media=disk,format=raw -cdrom Binaries/caffieneOS.iso -m 16M -boot order=dc

EDIT: I have just uploaded the iso to my github because the file was too large: https://github.com/zachary-d-r/CaffeineOS
You can find the iso in Binaries/caffeineOS.iso

[linuxyne]

Thanks for the upload.

I tested the ISO with the commands:

Code: Select all

# Create an empty disk.img, filled with zeroes
qemu-img create -f raw disk.img 1M

# Run
qemu-system-i386 -drive file=disk.img,media=disk,format=raw -cdrom Binaries/caffieneOS.iso -m 16M -boot order=dc

The disk.img saw its sector #2 (i.e. the sector at offset 0x200 * 2 = 0x400) written with the pattern 0x0f 0x00 0x0f 0x00... etc.

So the disk is being written to.

[Caffeine]

Thanks for the upload.

I tested the ISO with the commands:

Code: Select all

# Create an empty disk.img, filled with zeroes
qemu-img create -f raw disk.img 1M

# Run
qemu-system-i386 -drive file=disk.img,media=disk,format=raw -cdrom Binaries/caffieneOS.iso -m 16M -boot order=dc

The disk.img saw its sector #2 (i.e. the sector at offset 0x200 * 2 = 0x400) written with the pattern 0x0f 0x00 0x0f 0x00... etc.

So the disk is being written to.

Strange, when you boot the OS, do you same the same screen each time, or do the numbers when reading change?
Below is the screen that I see each time I boot the OS. Why?

[linuxyne]

Attached is the screen I get. Seems to be the same as yours.

Are you saying that the read values "64 0 0 48 ..." are unexpected?

Edit:
Even when the disk.img contains all zeroes, the read values are "64 0 0 48 ...", so it is very likely not reading from disk.img.

[Caffeine]

Attached is the screen I get. Seems to be the same as yours.

Are you saying that the read values "64 0 0 48 ..." are unexpected?

To me yes, I am trying to read whatever values I wrote after closing and re-opening the OS.

[Octocontrabass]

That means your code to read the disk doesn't work. (Which is why I suggested using a hex editor to confirm you were writing the disk.)

[Caffeine]

That means your code to read the disk doesn't work. (Which is why I suggested using a hex editor to confirm you were writing the disk.)

Here is the code for reading the driver:

Code: Select all

void ataPioRead(unsigned long long LBA, unsigned short sectorcount, unsigned char *target) {
    outportb(ATA_PRIMARY_DRIVE_HEAD, 0x40); // Select master
    outportb(ATA_PRIMARY_SECCOUNT, (sectorcount >> 8) & 0xFF);  // Sector Count hi
    outportb(ATA_PRIMARY_LBA_LO, (LBA >> 24) & 0xFF); // LBA4
    outportb(ATA_PRIMARY_LBA_MID, (LBA >> 32) & 0xFF);  //LBA5
    outportb(ATA_PRIMARY_LBA_HI, (LBA >> 40) & 0xFF);  // LBA6

    outportb(ATA_PRIMARY_SECCOUNT, sectorcount & 0xFF); // Sector Count lo
    outportb(ATA_PRIMARY_LBA_LO, LBA & 0xFF); // LBA1
    outportb(ATA_PRIMARY_LBA_MID, (LBA >> 8) & 0xFF);  //LBA2
    outportb(ATA_PRIMARY_LBA_HI, (LBA >> 16) & 0xFF);  // LBA3
    outportb(ATA_PRIMARY_COMM_REGSTAT, 0x24);  // READ SECTORS EXT command

    for (unsigned int i = 0; i < sectorcount; i++) {
        pollATA();  // Wait for it to be able to transfer data

        // Transfer the data
        for (int j = 0; j < 256; j++) { target[j] = inportw(ATA_PRIMARY_DATA); }
        target += 256;
    }
}

It works when I write and then read the disk. I tried putting another read command right after the first one in my kernel, and it worked. Why is this happening?

Code: Select all

unsigned int lba = 0x02;

    unsigned int *target;
    ataPioRead(lba, 1, target);
    ataPioRead(lba, 1, target);

[Octocontrabass]

What are you doing with the disk before you try reading it for the first time?

[linuxyne]

The "64 0 0 48 ..." seems to be the response to the IDENTIFY command.

You are sending IDENTIFY (0xec) command but are not consuming the 256 16-bit words of its response.
And soon you send READ SECTORS EXT (0x24).

Edit: And this content appears even before the disk is written for the first time, that is, even when the disk contains all zeroes. Some strings in the response being sent as part of 0x24 (but actually seems to be part of 0xec):

"QM00001",
"2.5+ QEMU HARDDISK "

Another problem:
The code you are using has a mistake. It passes the sector to be read/written as uint8_t *, but then it increments the pointer by only 256. When reading/writing 16-bit words, it is true that we need to process 256 words for a sector, but if the data pointer is uint8_t *, you will have to increment the pointer by 512.

[Caffeine]

The "64 0 0 48 ..." seems to be the response to the IDENTIFY command.

You are sending IDENTIFY (0xec) command but are not consuming the 256 16-bit words of its response.
And soon you send READ SECTORS EXT (0x24).

Edit: And this content appears even before the disk is written for the first time, that is, even when the disk contains all zeroes. Some strings in the response being sent as part of 0x24 (but actually seems to be part of 0xec):

"QM00001",
"2.5+ QEMU HARDDISK "

Another problem:
The code you are using has a mistake. It passes the sector to be read/written as uint8_t *, but then it increments the pointer by only 256. When reading/writing 16-bit words, it is true that we need to process 256 words for a sector, but if the data pointer is uint8_t *, you will have to increment the pointer by 512.

I'm pretty sure that did it! Thanks!