Hello, all. I've implemented LDM ("Dynamic disk") support. It allows to
easily have dual-bootable RAIDed volumes. I've tested only with simple
volumes but it should work with spanned, mirrored and mirrored-spanned
ones but not with stripped or RAID5 (TODO, use separate /boot for now).
I've pushed it to
http://bzr.savannah.gnu.org/lh/grub/branches/ldm/changes. I've also
successfully installed GRUB to a LDM. For this we need a small (1M)
simple volume on boot disk for embedding similar to what we have on GPT.
In my test I've just manually set it to use "Volume5". This obviously
isn't appropriate for deployement. So we need a way to choose embedding
partition. The ways I see are:
1) Let user specify. While seems to make sense in prectice it would mean
that user choice is stored somewhere and on disk manipulations it may
get out of sync and result in data loss on next install.
2) Use the partition type field. On LDM it's only one byte so it's more
difficult to choose an unique id. But more importantly Windows Disk
Manager tools allow only to choose either type NTFS or FAT and I'm not
aware of any other LDM-editing tools (but would be happy to be wrong
about this) which makes it difficult for end user to mark his embedding
partition.
3) Use a partition with FS which supports embedding. BtrFS and FAT
(specifically formatted with large number of reserved sectors) are
likely candidates and additionally allow to host GRUB files or even an
entire OS. However, it's difficult to check that its embedding zone
isn't in use by some other booting tool since we don't know if we have
ownership of any sense of the partition in question.
4) Use some kind of marker in the partition itself and supply a tool to
set this marker. Seems to be the most attractive choice. But we need to
ensure that this marker is destroyed if partition is formatted in any of
the FS or partitioned with common formats. We could just fill sectors
with string "GRUB". To cover just the FS supported in GRUB we need to
fill following ones:
0 (FAT, NTFS, AFFS, XFS,romfs,SFS,SquashFS,UFS,msdos,gpt,apple,dvh,Sun),
1 (BFS, BSD,sunpc), 2 (AFS, EXT*, HFS, HFS+, minix, nilfs2), 6 (Acorn),
0-15 (amiga), 16 (UFS), 32 (ZFS), 64 (ISO9660, JFS), 128 (BtrFS,
reiserfs, UFS), 256 (UDF), 512 (UDF,UFS), 1024(UDF), 2048 (UDF), 4096
(UDF), 8192 (UDF)
It seems that FS devs like using powers of 2. So to avoid storing this
sequence and future robustness I propose to fill sectors 0-32 (16KiB)
and all powers of 2 until 8192. It results in some need for fragmented
blocklists but it's not too bad.
Also whichever method we choose I also intend to apply it to various bsd
cases as well.-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
