Problem with pre-cooked GRUB floppy image

[Colonel Kernel]

I'm playing around with grub_disk.img, and I can't seem to get at it with mtools. Here is what I try (it's the same under Cygwin and Linux):

Code: Select all

$ mdir -i grub_disk.img ::
Total number of sectors not a multiple of sectors per track!
Add mtools_skip_check=1 to your .mtoolsrc file to skip this test

I get the feeling this image isn't formatted as FAT. Mounting this image as a virtual floppy in my Linux VM works fine. Booting it works fine (except for the fact that it has no kernel image to boot, of course). I want to be able to copy my kernel to this image using something make-friendly, running under Cygwin. Is there any way to do this...?

[Solar]

As always when something I made is concerned, I got this eerie "oh my god, I f***ed up" when I saw the thread name.

I never tried mtools, but used FileDisk to mount the image file.

[Curufir]

Easy way to check if it's the image or mtools.

On Cygwin:

Code: Select all

dd if=my.image of=test bs=1 skip=19 count=2 &&
dump test &&
rm test

Anything other than 0x400b is wrong for a 1.44Mb floppy.

[Solar]

Hmpf. Trying to download the disk image, that's about the umpteenth' time I see this "sorry, we're down for maintenance" from SourceForge...

Edit: Now SF is back, and I tried Curufir's test. Indeed, it gives me a 0x3f0b, but I have no idea what that tells me.

Curufir: What's that 'dd' of yours supposed to test?

[Solar]

I checked the image file in my hex editor, and cross-referenced the "FAT12 document" in our FAQ to find that the image file seems to be screwed up just as much as the FAT12 document... the image file has a version string saying "MSDOS5.0" all right (where the FAQ tells about "strange encrypted text), but the layout information seems to be pretty much broken.

I'll assemble a new disk image as soon as I find the time, and test it with MTools.

[Pype.Clicker]

now i'm less surprised about why my linux kernel (2.4.x) entered panic mode when i tried to read that image with a loop device, though it never bothered to tell me *why* it was crashing so hard...

[Candy]

wasn't the point behind the grub disk that it was based on a concatenation of stage1 and stage2? Where it after writing those wasn't fat12 anymore?

[Solar]

No, the idea was having a "real" installation of GRUB, where stage 1 is in the boot sector and stage 2 in the (FAT 12) filesystem - so you can copy your kernel image onto it and boot it in Bochs...

[proxy]

i actually made a boot disk for grub formatted to ext2, works beutifully if anyone wants it let me know.

BTW the easiest by far way to make an boot floppy image is to actually make a boot disk (cause grub wont install to a non-block device) and then just dd it to a file

now i just mount the image with -o, copy my new kernel in unmount and boot my VM to test.

proxy

[Curufir]

Curufir: What's that 'dd' of yours supposed to test?

19th byte of the BPB is the offset to the 16-bit sector count (BPB_TotSec16 in the FAT12 documentation).

On a 1.44Mb floppy it should be 0x400b, which thanks to the wonder of Intel word formation gives a real value of 0xb40 or 2880 sectors.

Yours give 0x3f0b, or 0xb3f, or 2879, which is incorrect and not divisible by 18. So I guess mtools is right, wonder how it came to be one off though.

I figured it was easier to write the test instructions than say "Go off and find the 19th and 20th bytes". Just forgot to say why to test them, oops .

[Solar]

Mpfh. I would have generated a new floppy image and a CD-ROM image this morning...

First, GRUB ./configure tells me Cygwin has no "absolute objcopy". Lucky I know my stuff about relative vs. absolute addressing, or that message would have left me none the wiser.

So I boot the Knoppix CD, mount my data drive (/mnt/hda5), make it writeable, and ./configure && make GRUB from there. Thing is, when I shut down Knoppix and rebooted to Win2k - the complete source directory including the binaries was no longer there.

WTF? I thought, and repeated the process, taking extra care for correctly mounting the /dev/hda5 writeable. Again, back in Windows land, everything was gone.

If a "ls /mnt/hda5" gives me "foo/, grub-0.95/, grub-0.95.tar.gz", and no three minutes later a "dir D:" gives me "foo/, grub-0.95.tar.gz", someone's handling of persistent storage is broken, and this time it's not Windows' drive letters.

>:(

OK, sit tight. I'll try again tonight.

[Pype.Clicker]

you should take care to umount your partitions before you restart a linux system. This is usually handled automagically by init scripts, but i don't know too much for a demonstration CD that doesn't mount partitions by itself.

until you umount, some blocks may not have been sync'd and may be left in the disk cache ...

[Solar]

Sick, sick, sick, sick, ... ::)

[distantvoices]

In case of a demo cd, each partition mounted by hand needs also to be umounted by hand. Thats so even with the famous knoppix live cd. *gg*

But I'll check out if one can have an automatic umount of *all mounted* file systems in the vfs tree upon shut down. It would be a fine thing.

[Solar]

Sorry but when I make an orderly shut-down, I fully expect any buffers to be correctly flushed. Everything else is just plain broken.