From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1W2Zq1-0006lu-EG for mharc-grub-devel@gnu.org; Mon, 13 Jan 2014 00:13:25 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Zpy-0006ld-SK for grub-devel@gnu.org; Mon, 13 Jan 2014 00:13:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2Zpx-0006Zi-Dw for grub-devel@gnu.org; Mon, 13 Jan 2014 00:13:22 -0500 Received: from mail-ie0-x233.google.com ([2607:f8b0:4001:c03::233]:49403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Zpx-0006ZX-7S for grub-devel@gnu.org; Mon, 13 Jan 2014 00:13:21 -0500 Received: by mail-ie0-f179.google.com with SMTP id tp5so1644974ieb.10 for ; Sun, 12 Jan 2014 21:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=KjbezaeywIG+lRxDP7B15tPmBO/JNQQSd0pr9iaH/h8=; b=h4ZadieBtHPSbypd93NOddwQBxlXMbNVe0rCbCbL8MigsydLJjsojZYgwYJE9CTaJW FahhabRPnFJUqC5J68l8g8keLNYbSmB6xdn4pffkxADOKjBdiqiyPn+by2+vr36VAeJy DLX73wPIi2S3axyZ5VjGf9g0vjkexfamECTbjyt68vUpJnlU2qH/u/Kxb1NoczPyMl/N dhY7nyF28JLjXIN0Py5wQIbB7NbG5hzgrSr4YiXYG4liShod1vRZXbxrX/SAFVa4T16Y WLKH5QOHHUoYNisYvrqMiZStCI10y3BBvrv/iLUALAvdr/g2fPC/NwjucnQ3MJz04AlD 2HUQ== MIME-Version: 1.0 X-Received: by 10.43.82.69 with SMTP id ab5mr45360icc.95.1389590000662; Sun, 12 Jan 2014 21:13:20 -0800 (PST) Sender: mchang.novell@gmail.com Received: by 10.64.57.199 with HTTP; Sun, 12 Jan 2014 21:13:20 -0800 (PST) In-Reply-To: References: <52B3376A.7030301@gmail.com> <52B4364F.9020900@gmail.com> <946948C6-BC06-4E4E-A22A-DF6EF86802DE@colorremedies.com> <2FA74EFF-1716-4BDA-A8CA-4C63B0682325@colorremedies.com> <20131230101816.GA12355@linux-dsax.tai.apac.novell.com> <52C158EC.1030508@gmail.com> <20131231075048.GA16706@linux-dsax.tai.apac.novell.com> <39363BA7-BC57-4731-AD1D-3BD659109E77@colorremedies.com> Date: Mon, 13 Jan 2014 13:13:20 +0800 X-Google-Sender-Auth: LMTSfPm5NFee-Dxtp3T3yzyZjZ0 Message-ID: Subject: Re: booting btrfs From: Michael Chang To: The development of GNU GRUB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::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: Mon, 13 Jan 2014 05:13:24 -0000 2014/1/10 Chris Murphy : > > On Jan 9, 2014, at 3:03 AM, Michael Chang wrote: > >> 2014/1/9 Chris Murphy : >>> >>> On Jan 7, 2014, at 10:55 AM, Chris Murphy wro= te: >>> >>>> >>>> On Jan 1, 2014, at 10:17 PM, Michael Chang wrote: >>>>> >>>>> We snapshot /boot for kernel and initrd, otherwise the rollback would >>>>> encounter problem of incompatible userland and kernel/kernel modules. >>>>> And we need the ability to rollback them in terms of usefulness. >>>> >>>> Of course, understood. >>>> >>>> core.img is only going to point to one /boot, which may not be the /bo= ot snapshot needed for the kernel and initrd. This will be really confusing= for mortal users. They'd be unlikely to figure it out and understand it, w= ithout documentation. >>>> >>>> If core.img points to the "current" /boot, which it should, that boot = has the accumulated knowledge of all snapshots, and any recently updated gr= ub modules. Choosing to boot a snapshot means using a different /boot for k= ernel/initramfs than what grub is using for its root. I don't off hand see = a problem with this because it's literally just two files that grub loads f= rom a different boot subvolume, found with an absolute path to that snapsho= t. And it also uses rootflags=3Dsubvol=3D to use the matching root snapshot= . >>>> >>>> A separate issue that's not grub's problem is how to deal with the (no= w wrong) fstab entries. systemd looks at fstab and generates mount jobs fro= m that; if taught to understand it's booting a snapshot it could second gue= ss parts of the fstab. Based on the name of the currently booting root snap= shot, which systemd definitely knows, it could mount that subvol=3D instead= of what's in fstab. It can use name substitution to do the same thing with= the other subvolume-snapshots that match the root one. Meaning all of the = snapshots for a system have the same base (re)naming convention. >>> >>> Another hiccup. Maybe it's a silly use case. Consider /boot on Btrfs, m= ultiple-device, raid1 data/metadata profile, UEFI Secure Boot. A drive dies= , and the system needs to be rebooted before a rebuild occurs. >>> >>> This works today with /boot on raid1/10 Btrfs. Yes, I manually have to = add a degraded mount option as this isn't automatically done by Btrfs yet. = But the GRUB boot part works. Even degraded, the path to grub.cfg is valid.= And the file system itself keeps multiple copies so there's no work keepin= g it current. >>> >>> With Secure Boot it's a problem. The signed grubx64.efi has a fixed pre= fix location, valid on any computer, to search for grub.cfg, which is on th= e ESP. So now we need to have multiple copies of grub.cfg, somehow synced, = on each ESP. Or another solution. If we had a Btrfs subvolumetypeGUID, anal= ogous to the GPT partitiontypeGUID, and specify that as the baked in partuu= id for a signed grubx64.efi to search for /boot/grub/grub.cfg. >> >> Isn't search --fs-uuid sufficient for this task? Or I'm afraid that I >> didn't understand your problem enough. >> >> cat < /boot/efi/EFI//grub.cfg >> search --fs-uuid --set=3Droot `grub-probe --target=3Dfs_uuid /boot/grub= ` >> set prefix=3D(\$root)/boot/grub >> configfile \$prefix/grub.cfg >> EOF >> >> grub-mkconfig -o /boot/grub/grub.cfg >> >> This way we can avoid calling "grub-mkconfig -o >> /boot/efi/EFI//grub.cfg" and hopefully can get rid of >> the problem you have. > > Yes I think that will work. Do you agree that a GUI installer permitting,= e.g. /boot on Btrfs raid1, should implement this? Honestly I'm not clear about the benefit of it on your case (/boot on Btrfs) but it would be helpful if you want managing your config path more in common and general, so use it if you find it useful. :) > Or should it be a future feature of grub-mkconfig to figure out, that two= grub.cfgs are needed? No. I don't think grub-mkconfig should be changed at all. Use it in your UI wrapper scripts to grub-mkcofig would be better. Regards, Michael > > > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >