Re: About usage of floppy with linux guests on gnome-boxes

[Lucas Meneghel Rodrigues <lmr redhat com>]

On 12/01/2011 10:23 PM, Zeeshan Ali (Khattak) wrote:
>     I have no real objections on the cdrom method if:
>
> 1. We already try USB and it doesn't work for some reason (I think I
> tried with Fedora and it worked for that).
> 2. Speed and disk usage isn't very different compared to floppy method.
>
>     Another reason to prefer USB is that that then the code-path won't
> be very different for windows and linux then. Actually IIRC we just
> need to specify in the domain configuration that its a USB image and
> thats it.
>
>     BTW, it will be a big contribution if you could solve this mystery
> for us: https://bugzilla.gnome.org/show_bug.cgi?id=665001

Fortunately, I know what this might be, since the first windows guest 
I've tried my initial unattended install code is windows XP 2 years ago 
and I've hit this issue.

What most likely is going on here is a slight mismatch on the floppy 
image size used to hold the unattended install file. If I recall 
correctly, I was trying to provide 1.44 M to dd at the time to create 
the floppy.

Then we switched to qemu-img and 1440k as the size, so the idea of 
creating a floppy that Windows XP will like (and so all the other OS) is:

c_cmd = '%s create -f raw %s 1440k' % (qemu_img_binary, path)
utils.run(c_cmd, verbose=DEBUG)
f_cmd = 'mkfs.msdos -s 1 %s' % path
utils.run(f_cmd, verbose=DEBUG)
m_cmd = 'mount -o loop,rw %s %s' % (path, self.mount)

This is from

https://github.com/autotest/autotest/blob/master/client/virt/tests/unattended_install.py

I have a class there that prepares the file like this, copies the 
unattended file to the mount point [1], and then we're done, unmount the 
path. There we have a ready floppy image that Windows XP will happily 
accept.

I was looking over and over unattended-installer.vala and what is going 
on on your floppy creation code:

    private async void create_floppy_image (Cancellable? cancellable) 
throws GLib.Error {
        var floppy_file = File.new_for_path (floppy_path);
        var template_path = get_unattended_dir ("floppy.img");
        var template_file = File.new_for_path (template_path);

        debug ("Creating floppy image for unattended installation at 
'%s'..", floppy_path);
        yield template_file.copy_async (floppy_file, 0, 
Priority.DEFAULT, cancellable);
        debug ("Floppy image for unattended installation created at 
'%s'", floppy_path);

        created_floppy = true;
    }

Analyzing the floppy file

[lmr@freedom data]$ file floppy.img
floppy.img: x86 boot sector, mkdosfs boot message display, code offset 
0x3c, OEM-ID " mkdosfs", sectors/cluster 4, root entries 512, sectors 
4096 (volumes <=32 MB) , Media descriptor 0xf8, sectors/FAT 3, heads 64, 
serial number 0x46d6dab4, label: "           ", FAT (12 bit)
[lmr@freedom data]$ du -sh floppy.img
20K	floppy.img

This certainly doesn't look like a well formed floppy, at least for 
Windows XP standards. I see that you copy the unattended file using mcopy

        debug ("Copying unattended file '%s' into floppy drive/image 
'%s'", unattended_dest_name, floppy_path);
        // FIXME: Perhaps we should use libarchive for this?
        string[] argv = { "mcopy", "-i", floppy_path,
                                   unattended_tmp_path,
                                   "::" + unattended_dest_name };
        yield exec (argv, cancellable);

So, although this seems fine at a first look, it's not good enough for 
WinXP standards :) Perhaps you guys are open to a more traditional 
approach like the one we use on our unattended code?

Cheers,

Lucas

[1] And eventually some more stuff, such as windows virtio drivers 
(viostor), but let's get to that later