From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Quvqk-0005yG-SM for mharc-grub-devel@gnu.org; Sat, 20 Aug 2011 20:25:14 -0400 Received: from eggs.gnu.org ([140.186.70.92]:45124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Quvqg-0005up-TG for grub-devel@gnu.org; Sat, 20 Aug 2011 20:25:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Quvqf-0006xj-AW for grub-devel@gnu.org; Sat, 20 Aug 2011 20:25:10 -0400 Received: from mail-fx0-f41.google.com ([209.85.161.41]:44089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Quvqf-0006xE-5K for grub-devel@gnu.org; Sat, 20 Aug 2011 20:25:09 -0400 Received: by fxg9 with SMTP id 9so3242807fxg.0 for ; Sat, 20 Aug 2011 17:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; bh=z0sUms9ei2eClCxZcWmhuXscNCwBS2+s0W9I+4pxNhk=; b=HOF/8cgxypby4OMsA7Njw7VGesQic+/n5EevYiC2JDw01nZob6DTPG2f0NXE5lcMDO oaU4ov05/fteXAFCCM23egIQdEvS/V8nv7R1P+gfGs3M6Urm3z117PHuJUw5pER5gAf3 Ec0v0D9ni7ErHhx4cUhqihP/yh05Uf9OWVqm0= Received: by 10.223.56.80 with SMTP id x16mr1356266fag.36.1313886306218; Sat, 20 Aug 2011 17:25:06 -0700 (PDT) Received: from debian.x201.phnet (44-141.62-81.cust.bluewin.ch [81.62.141.44]) by mx.google.com with ESMTPS id 25sm3721389fay.7.2011.08.20.17.25.03 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Aug 2011 17:25:04 -0700 (PDT) Message-ID: <4E50505D.1050306@gmail.com> Date: Sun, 21 Aug 2011 02:25:01 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: The development of GRUB 2 , =?UTF-8?B?R3LDqWdvaXJl?= =?UTF-8?B?IFN1dHJl?= Subject: [RFC, RFT] LDM ("Dynamic disk") support X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1B2DB237648C0AAF0D6DA725" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.161.41 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 00:25:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B2DB237648C0AAF0D6DA725 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig1B2DB237648C0AAF0D6DA725 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk5QUF0ACgkQNak7dOguQgnaoAD8Dey7brXITQI4WHR9LpannhWL UT6wq3vUUiZGN0AL+4cA/jOBYmf0hgp0ZlYLSSoshZxagNUvhRcti/OjIjv9CJCu =OwrZ -----END PGP SIGNATURE----- --------------enig1B2DB237648C0AAF0D6DA725--