Re: EZ-Bios and embeding stage 1.5

[Jochen Hoenicke]

On Jan 7, Michael Haub wrote:
> Thanks a lot Jochen,
> 
> Correct me if i am wrong:
> AFIAK Ontrack's Diskmanager has the same features and hides its
> presence better than EZ-BIOS. The lost bytes in the first track
> don't matter for nowadays disk sizes.

Yes, as long as the Diskmanager is installed it is completely
invisible.  But when you boot from floppy without the diskmanager, the
harddisk is not accessible.

> Where can I get a disk image (grub + ext2fs or at best FATfs) of the latest
> CVS version? I have no access to CVS as the box i am working on now has
> only Windows 98 SE and the Overhead to install CVS (and learning to deal
> with it) is much too high at that moment.

For your pleasure, I put a floppy image (build with mtools and grub
shell) at http://www.informatik.uni-oldenburg.de/~delwi/grub/ 
This just contains the latest CVS version, it is not a official
release.  You have to provide your own menu.lst if you want a menu.

> I think it would be nice to exactly tell which sector grub writes some bytes.
> Things like (hd0)1 could be interpreted as the second sector on the first 
> disk.

Changing install, that the destination partition can also be a
blocklist consisting of a single block, shouldn't be too hard.  The
question is if this is worth it as you can't normally boot from a
random block.

> Things like (hd0)17+14 could be interpreted as 14 sectors beginning with the
> 18th sector on the first disk. Such a range may not mean anything to grub as
> it knows how many sectors it is going to write, but this could be checked and
> an comprehensive error could be issued if it is longer than the stated range.
> The other thing is - it would be more logical.

There could be a new command for this purpose, e.g. 
"write FILE BLOCKLIST", which could then be used as backend for embed. 
But again the question is how many people would need this feature.

> A feature to copy files from the boot disk to a file system on a hard disk 
> partition would be nice.

I don't think that is likely to be done.  Writing to a file system is
much more difficult than reading it, think e.g. of reiserfs, where you
have to reorganize a Btree, find empty blocks in the blocklist, add
directory entries, split nodes, etc.

Most importantly it means, that you have to validate and test the file
system code thoroughly.  Every small bug will someday scramble
somebody elses hard disk.  The current file system support is read
only, so the worst that can happen, is that you can't access a file
with grub.

  Jochen