From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XuSXe-0005IO-As for mharc-grub-devel@gnu.org; Fri, 28 Nov 2014 15:53:26 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuSXX-0005Di-IJ for grub-devel@gnu.org; Fri, 28 Nov 2014 15:53:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuSXR-0004Sz-Vh for grub-devel@gnu.org; Fri, 28 Nov 2014 15:53:19 -0500 Received: from mail-wg0-x233.google.com ([2a00:1450:400c:c00::233]:52584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuSXR-0004Sn-PX for grub-devel@gnu.org; Fri, 28 Nov 2014 15:53:13 -0500 Received: by mail-wg0-f51.google.com with SMTP id k14so9556164wgh.38 for ; Fri, 28 Nov 2014 12:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=MJEmTUOh/BrJWq1op8WVd36xmezkASbKAq0neDxfxFA=; b=pjWTB6GmK5S/pY35DkuipyQ9//K/t6AJ6Raz6HokYZHrG6uQjvstQrtcAp1GueXgmy nVmKoyQdrLVlpbUKSg1n0rJg0rPbj3lcF3S47JWD5HHdSu1djahlycRsWHvozCNify8b SaTdpgoqXx9xJ7U86DT36kwTse5jz+j6lbIPLgGPdM+bSMRSpGt1/xNNUg5pRzItjdbS oPWqqsp49O7I+oOQApVtcwEY/zroNtbfscsUBlxdFZX7c6WM8/skkAROG0OILas4RTm7 +ZpKppd5AsozRNtLmoyveeLBVUz3XT1RSEzaKfjC2XmBVaSBJDsE4PfxdUd8Hp8eAfqw eACQ== X-Received: by 10.180.37.142 with SMTP id y14mr27885016wij.47.1417207993184; Fri, 28 Nov 2014 12:53:13 -0800 (PST) Received: from [10.222.38.128] ([212.213.198.101]) by mx.google.com with ESMTPSA id e7sm16475244wjx.31.2014.11.28.12.53.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Nov 2014 12:53:12 -0800 (PST) Message-ID: <5478CBE7.50001@gmail.com> Date: Fri, 28 Nov 2014 21:24:23 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: The development of GNU GRUB , Andrei Borzenkov Subject: Re: Switching to another boot device on failure References: <20141119061654.3de675c8@opensuse.site> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MfULXpa7IRGflnBPNeHUwJXQdMpFSiFJH" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::233 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: Fri, 28 Nov 2014 20:53:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MfULXpa7IRGflnBPNeHUwJXQdMpFSiFJH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 20.11.2014 15:38, Venkata Subbarao wrote: > Once again Thank you Andrei. > Modified the grub source and added grub_exit (). After this BIOS booted= > from next device. >=20 > I am now working on a solution where if the UUID present in the grub.cf= g > goes bad. > One way I am thinking is to check the CRC of the grub.cfg and other > image files required for booting. This may be bit lengthy. > Let me know if you have suggestions. >=20 What is the scenario you want to protect against? checksums are mainly useful against hardware failure but if hardware is defective the only way to surely bring it back is to replace failing components. The most common way for UUID to go unsync is because of software or operator error and both are likely to recompute checksum or change actual disk UUID without changing grub.cfg. > Thanks, > Subbarao >=20 > On Wed, Nov 19, 2014 at 8:57 AM, Venkata Subbarao > > wrot= e: >=20 > Thank you very much Andrei. > I will try out this and update. >=20 >=20 > - Subbarao >=20 > On Wed, Nov 19, 2014 at 8:46 AM, Andrei Borzenkov > > wrote: >=20 > =D0=92 Tue, 18 Nov 2014 10:51:00 +0000 (UTC) > Venkata Subbarao > =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: >=20 > > Hi All, > > > > I am working on a task on XUbuntu OS in which due to any > reason if booting > > fails I would like to switch to another boot device by zeroin= g > the MBR of > > current boot disk. Is this possible ? > > > > For example instead of showing following prompt, I would like= > to zero out > > the MBR so that the BIOS can select next boot device upon res= et. > > > > error: no such partition > > grub rescue> > > >=20 > grub supports only very limited and controlled ways to write to= > device/file. Doing something like this in unattended manner is > probably > way too dangerous. >=20 > What would be possible is to optionally exit grub (after timeou= t) in > this case; then BIOS should proceed to next boot device. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 --MfULXpa7IRGflnBPNeHUwJXQdMpFSiFJH 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 iF4EAREKAAYFAlR4y+cACgkQmBXlbbo5nOtdWAD/TA2yPlOQYhj164++GMeUwuHu g8TLpeDnj8ckp86P68sBAKxIsh226G7tsFe0YgNmbA/OAsj+88rITRLSafHl9rx2 =5Mta -----END PGP SIGNATURE----- --MfULXpa7IRGflnBPNeHUwJXQdMpFSiFJH--