From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1N80vJ-0004nk-QZ for mharc-grub-devel@gnu.org; Tue, 10 Nov 2009 19:18:57 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N80vH-0004lP-Nn for grub-devel@gnu.org; Tue, 10 Nov 2009 19:18:55 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N80vC-0004gR-KH for grub-devel@gnu.org; Tue, 10 Nov 2009 19:18:55 -0500 Received: from [199.232.76.173] (port=35996 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N80vB-0004gD-DA for grub-devel@gnu.org; Tue, 10 Nov 2009 19:18:49 -0500 Received: from mail-ew0-f228.google.com ([209.85.219.228]:62093) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N80vA-0000aN-OZ for grub-devel@gnu.org; Tue, 10 Nov 2009 19:18:49 -0500 Received: by ewy28 with SMTP id 28so1408017ewy.42 for ; Tue, 10 Nov 2009 16:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=2BlmbNe2hwy4uCzBA2RHWHGBQowb0rJsrTHgtCwtwiU=; b=JeeZ0dAEpPVdvkfRWVaxa3lGlwJ9vEdBS2xYVHbFm02ssd/w4+bG4P/0fq3lpB9jFM G1ASkRLKiMg2fsz/ow8bYUczfRH84cvO9GPcq9wOKlpsJp7zPNFdxLruRB8EWadodox2 MCGiIjen2nVJ1XVfClL8si/grWCU0y+Zqz/XY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=b/zPJZXvhw30SH8Nosc7g0EW+3T47EbCX/CM3xpD7A09mm9u7e8ASHUEmt2MuaVXfK YvbD2HG0gX/RWO4ukYTr4OGeaowt+iPVuhSkTgSVx3Mq3D/uZ8KGmLWswhgXdxtYaQVu 6llLSKaZ0yh3lLqfrPlOp5xixQN4lIV+qM02M= Received: by 10.213.1.5 with SMTP id 5mr923430ebd.9.1257898727752; Tue, 10 Nov 2009 16:18:47 -0800 (PST) Received: from debian.bg45.phnet (gprs37.swisscom-mobile.ch [193.247.250.37]) by mx.google.com with ESMTPS id 28sm2880649eyg.46.2009.11.10.16.18.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Nov 2009 16:18:47 -0800 (PST) Message-ID: <4AFA02D2.6030108@gmail.com> Date: Wed, 11 Nov 2009 01:18:26 +0100 From: Vladimir 'phcoder' Serbinenko User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: The development of GNU GRUB References: <845635.69741.qm@web110304.mail.gq1.yahoo.com> In-Reply-To: <845635.69741.qm@web110304.mail.gq1.yahoo.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA403B4FE941A3CAB54B0FAB7" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: LVM write support from grub2. Writing to environment block in core.img X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 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: Wed, 11 Nov 2009 00:18:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA403B4FE941A3CAB54B0FAB7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Roger Cruz wrote: > Hi there developers, > > I posted this message last night and I was wondering if one of you > would be kind enough to make a reply as to your assessment of having > an LVM write function implemented. I am in dire need to have this > capability so I'm willing to code myself if need to. I just need to > understand the pitfalls and get an idea of the amount of time and work > to implement it. I have looked at the grub_lvm_read and it appears to > have all the necessary logic to decode the lvm format. I was thinking > of reusing that code and at the end of it simply do a disk->dev->write > which should invoke the underlying hard disk write routine (I'm new to > grub2 so this is my understanding from a quick parse of the code). > When writing to devices we prefer to be careful. We don't often need to write so the writing code isn't well-tested and any bug in it can have grave consequences. LVM is problematic because if you have multi-disk LVM some volumes may be invisible due to BIOS limitations. I'm not familiar with LVM but if it has checksums they need to be updated as well or volume will become inconsistent. In one word writing to LVM is dangerous and I would prefer bootloader with less functionality rather than one damaging my disks. I'm not the only developper but overall there is a relative consensus not to write if it can be avoided. On the other hand writing to embedding zone is a good idea and with Seth Goldberg we decided that it's best sollution for root on ZFS which has similar problems > Any help is extremely appreciate it... even if it is a short message > to say my idea doesn't work because... > > Thanks > R. > > Date: Mon, 9 Nov 2009 17:11:53 -0800 (PST) > From: Roger Cruz > > Subject: LVM write support from grub2. Writing to environment block in > core.img > > I have a system where the boot partition is on top of an LVM. I'm > using the loadenv module to save state and remember the previously > booted entry. I have something like this: > > if [ ${prev_saved_entry} ]; then saved_entry=3D${prev_saved_entry}=20 > save_env saved_entry prev_saved_entry=3D save_env prev_saved_entryfi > In examining why save_env is not writing to grubenv, I came across > this LVM routine that says LVM writes are not supported. > static grub_err_t > grub_lvm_write (grub_disk_t disk __attribute ((unused)), > grub_disk_addr_t sector __attribute ((unused)), > grub_size_t size __attribute ((unused)), > const char *buf __attribute ((unused))) > { > return GRUB_ERR_NOT_IMPLEMENTED_YET; > } > Is there a plan to add this support? Anyone currently working on it > that I may get an early implementation from? If not, is there a > technical reason why this would be hard for someone (maybe me) to > implement? > > As a work-around, I'm considering using the environment block in > core.img. Are there routines that can be run at boot time to allow > grub to change the variables there, perhaps using the same module > (loadenv) and so it can be used as "save_env -f core.img"? Anyone see > any reasons why I shouldn't write to that space? > > Thanks > Roger > > -----------------------------------------------------------------------= - > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > =20 --=20 Regards Vladimir 'phcoder' Serbinenko --------------enigA403B4FE941A3CAB54B0FAB7 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREKAAYFAkr6AuMACgkQNak7dOguQglBXwEAjggqP1d/HtTeuoov9v5r1Ydj Sd5lW8ESSDI1HIM8hasA/3mlZN1KteIFYP8M6iVvPfI3/8UIPW9omwpPvoLXmOCc =xY0u -----END PGP SIGNATURE----- --------------enigA403B4FE941A3CAB54B0FAB7--