Is there a difference in how gujin handles partitions (with iso image on it via 'cat'), that are on a hdd rather than a usb drive?
i've found spasmodic behaviour when using a usb drive on certain distros.
1. dsl-n = boots great from hdd partition. refuses to boot from usb partition.
2. dsl-4 = sometimes boots from usb partition. often refuses to boot when mounting cd rom. (really strange with differing results).
also, as the data on the partition is simply a copy of the .iso file, is there a way for gujin to mount the .iso file directly as a cdrom rather than mounting a partition?
I haven't yet found a use for .bdi as i have to cat all my .iso files to a partition anyway.
if i 'cat' the partition back to a .bdi, would that work at all for
1. an el-torito image?
2. my linux installed partition? - and would it be read/write or read only?
> Is there a difference in how gujin handles partitions (with iso image on it via 'cat'),
> that are on a hdd rather than a usb drive?
The partition treatement (i.e. C function) is not aware of the access method of the medium
(i.e. another C function in a completely different file), so there should not be any difference.
> i've found spasmodic behaviour when using a usb drive on certain distros.
Sometimes due to the distro finding a root partition which looks like its own root partition,
but in fact it is not - because two of the distributions "looks" like each over. For instance,
the two distributions are in fact two different versions of the same distribution and use the
same method to detect their own root filesystem, then dsl-4 mounts dsl-n root partition (or the
opposite) and strange things happen. Sometimes it even happen with a distribution which is
"derived" from another distribution - they use the same method to detect their root partition
and find the wrong one...
> also, as the data on the partition is simply a copy of the .iso file, is there a way for
> gujin to mount the .iso file directly as a cdrom rather than mounting a partition?
You seem to assume that Gujin mounts the partition for Linux, when in fact Gujin does a
"quick and read-only" mount/umount and Linux does what it wants later, mounting filesystems
when it see fit.
> I haven't yet found a use for .bdi as i have to cat all my .iso files to a partition anyway.
Initially, I have written the BDI interface to get rid of the bootable floppies I had, so
it is mainly designed to boot DOS or simple operating systems. It may work for CDROM images,
but keep in mind that the BDI file has to be contigous on disk (the floppy emulator - as a
Terminate and Stay Resident program - has to be written in assembly, so is quite simple).
> if i 'cat' the partition back to a .bdi, would that work at all for
> 1. an el-torito image?
Maybe - if it does not this can probably be fixed in Gujin, but it will work only up to
the point where the Gujin floppy emulator is disabled and/or erased by the operating system
being launched. I do not know of any distribution which will search its root filesystem
by listing all the BDI files present in /boot, and there is no command line whatsoever
defined by el-torito. So you will not get what you want without modifying the content
of the ISO.
> 2. my linux installed partition? - and would it be read/write or read only?
If you take care of the init scripts of your linux partition, mounting the root
filesystem in loop mode on the bdi file of the main partition mounted, I do not see
right now why it could fail. The Gujin floppy emulator is read/write and auto-adapt to
512 bytes hardware sectors (like hard disk or floppy) and 2048 bytes hardware sectors
(like CDROM, DVD and some SCSI devices) but the fact that your root partition is read-write
under Linux just depends on how you have mounted it under Linux. Keep in mind that
the BDI file has to be contigous, that may be a problem.
When I say "Gujin floppy emulator is read/write on 2048 bytes/sectors", I assume that
the filesystem block size is superior than 2048 bytes/sectors and that filesystem blocks
are aligned to 2048 bytes.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.