Re: booting btrfs
2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko :
> On 19.12.2013 17:13, Andrey Borzenkov wrote:
>> В Mon, 28 Oct 2013 01:44:26 +0100
>> Vladimir 'φ-coder/phcoder' Serbinenko пишет:
>>
>>> I changed in trunk to make / refer to real root and modified
>>> grub-mkrelpath to follow the same convention, even if disk is mounted
>>> with subvolid.
>>>
>>
>> Can it cause compatibility issues? It means if config file that works
>> for grub before this change will stop working after. So e.g. attempt to
>> "configfile /file/from/partition/with/old/grub-mkconfig" will fail.
>>
> Normally I'd consider this a problem but the current behaviour is the
> intended one, just back when the code was written thre were no changing
> default yes
>> May be subvolume support should use different syntax. Something like
>>
>> (hd0,1){sv=subvolume}/xxx
>> (hd0,1){svid=NNN}/yyy
>>
> This would complicate the code a lot and commit us to maintaining it
> long-term. Given that btrfs isn't clasified as stable, I consider this
> behaviour change acceptable and it's better to handle this now rather
> than perpetuating the issue.
Please consider the case if a snapshot was taken against real root fs
tree to a subvolume with SNAPSHOT_ID. With syntax above providing
mount option support we can possibly boot that snapshot with this
config.
set root=(hd0,1){svid=}
set prefix=($root)/boot/grub2
normal
Without the syntax support it's almost impossible to do that. At lease
I can't figure out any.
Besides we may leverage that mount option support in grub-mount to
test/develop and so on. For modern innovative file systems the mount
option support is becoming necessary for dealing many different use
cases.
Thanks,
Michael
>> And continue to interpret old syntax as relative to default.
>>
>>
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] pvgrub2 is merged
On 19.12.2013 12:54, Stefano Stabellini wrote: > On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >> On 18.12.2013 20:39, Stefano Stabellini wrote: >>> On Wed, 18 Dec 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 17.12.2013 15:35, Fabio Fantoni wrote: > Il 17/12/2013 15:10, Fabio Fantoni ha scritto: >> Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: Thanks. Now there is another error, probably introduced by xenfb support: >>> doesn't look like related to xenfb. Is it 64-bit or PAE guest? >> >> 64 bit > > I did "git reset --hard" to commit "Remove grub_bios_interrupt on > coreboot." and then I applied only > "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation." > commit. > Now the Sid domU boot correctly, therefore the regression is caused by > "xenfb" or "xen grants to v1" commit, should I find the exact commit > that causes that problem or these informations are enough for you? It's because of vfb. Apparently vfb framebuffer stays mapped as rw even after vfb shutdown phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls /local/domain/54/device/vfb 0 = "" backend = "/local/domain/0/backend/vfb/54/0" backend-id = "0" state = "1" phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls /local/domain/0/backend/vfb/54/0 frontend = "/local/domain/54/device/vfb/0" frontend-id = "54" online = "1" state = "2" domain = "grub" vnc = "1" vnclisten = "127.0.0.1" vncdisplay = "0" vncunused = "1" sdl = "0" opengl = "0" feature-resize = "1" hotplug-status = "connected" When I do "dry vfb": do everything except writing vfb state problem disappears. So my question would be: - how can I inspect how backend maps framebuffer pages? >>> >>> There is only one xenfb backend: hw/display/xenfb.c in the QEMU source >>> tree. >>> >>> - Why does it map as rw and not ro? It doesn't need to write to framebuffer? >>> >>> Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb >>> >> ./tools/qemu-xen-dir-remote/hw/xenfb.c: >> xenfb->pixels = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom, >> PROT_READ | PROT_WRITE, fbmfns, >> xenfb->fbpages); > > You are right, my bad. > I did a quick test and it should be safe to modify it to PROT_READ only. > > - How do I force it to drop the mapping? >>> >>> Theoretically QEMU should drop the mapping at disconnect time: >>> >>> hw/display/xenfb.c:fb_disconnect >>> >>> /* >>> * FIXME: qemu can't un-init gfx display (yet?). >>> * Replacing the framebuffer with anonymous shared memory >>> * instead. This releases the guest pages and keeps qemu happy. >>> */ >>> fb->pixels = mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE, >>> PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON, >>> -1, 0); >>> >> Could this fail? > > Yes and we don't check for the return value (-1 in case of error). Well > spotted! > Do you want to submit a patch to fix both issues or should I do it? > I'm fine with you doing it. signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Important EHCI bugfix (Re: grub-2.02~beta1 happened)
On 19.12.2013 20:59, Aleš Nesrsta wrote: > Hi Vladimir, > > it would be fine if the bugfix, posted by me in ML thread "EHCI/USBMS > corrections" (12/16/2013), will be included in the final release. It > solves serious bug. > Check the git, it's already there, in cleaned up form. > I tested it on four different PCs - it is working fine, I saw no > negative results, and it helps on PCs where the problem, described in > "flash drive timing out, can't boot vmlinuz/initrd (coreboot payload)", > appeared. > > Would be nice if the initial reporter "The Gluglug" will do test of this > patch. Do you know him? Could you arrange such test with him? I don't > see any further reaction from his side in ML thread "flash drive timing > out, can't boot vmlinuz/initrd (coreboot payload)". > > BR, > Ales > > Dne 19.12.2013 02:51, Vladimir 'φ-coder/phcoder' Serbinenko napsal(a): >> Hello, all. I've just uploaded 2.02~beta1. This also means that we're >> now in freeze. I'm willing to consider exceptions on case-by-case basis >> but it would be exceptions. The major points to do before release: >> - ARM64 loader. >> - Yeeloong 3A support needs some love. >> - XEN would probably need config adjustments. >> - XNU loader needs fixes. >> - NEWS needs contents. >> - Documentation. >> - Loads and loads of testing and some bugfixes. >> ... >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] add --boot-directory option to grub-mkstandalone
On Fri, Dec 13, 2013 at 07:40:54PM +0400, Andrey Borzenkov wrote:
> > 2) make it possible for grub-mkstandalone to build images with the
> >prefix set to something other than (memdisk)/boot/grub
>
> Like below?
Indeed, I like this general approach, and it's probably better than
fiddling around with "search".
> I'm not keen on using --boot-directory; may be using full
> --grub-directory (without implied ../grub) will actually be more
> logical.
I agree - I would prefer to explicitly specify the whole thing. Could
you redo the patch that way?
> enum
>{
> OPTION_OUTPUT = 'o',
> -OPTION_FORMAT = 'O'
> +OPTION_FORMAT = 'O',
> +OPTION_BOOT_DIRECTORY = 0x301,
> +
>};
Stray newline.
> @@ -346,8 +359,8 @@ main (int argc, char *argv[])
>grub_install_push_module ("tar");
>
>grub_install_make_image_wrap (grub_install_source_directory,
> - "(memdisk)/boot/grub", output_image,
> - memdisk_img, NULL,
> + xasprintf ("(memdisk)%s/%s", bootdir, "grub"),
> + output_image, memdisk_img, NULL,
> grub_util_get_target_name (format), 0);
>
>grub_util_unlink (memdisk_img);
I'd probably assign the result of that xasprintf to a variable in order
to be able to free it, for valgrind-friendliness.
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting btrfs
On 20.12.2013 10:46, Michael Chang wrote:
> 2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko :
>> On 19.12.2013 17:13, Andrey Borzenkov wrote:
>>> В Mon, 28 Oct 2013 01:44:26 +0100
>>> Vladimir 'φ-coder/phcoder' Serbinenko пишет:
>>>
I changed in trunk to make / refer to real root and modified
grub-mkrelpath to follow the same convention, even if disk is mounted
with subvolid.
>>>
>>> Can it cause compatibility issues? It means if config file that works
>>> for grub before this change will stop working after. So e.g. attempt to
>>> "configfile /file/from/partition/with/old/grub-mkconfig" will fail.
>>>
>> Normally I'd consider this a problem but the current behaviour is the
>> intended one, just back when the code was written thre were no changing
>> default yes
>>> May be subvolume support should use different syntax. Something like
>>>
>>> (hd0,1){sv=subvolume}/xxx
>>> (hd0,1){svid=NNN}/yyy
>>>
>> This would complicate the code a lot and commit us to maintaining it
>> long-term. Given that btrfs isn't clasified as stable, I consider this
>> behaviour change acceptable and it's better to handle this now rather
>> than perpetuating the issue.
>
> Please consider the case if a snapshot was taken against real root fs
> tree to a subvolume with SNAPSHOT_ID. With syntax above providing
> mount option support we can possibly boot that snapshot with this
> config.
>
> set root=(hd0,1){svid=}
> set prefix=($root)/boot/grub2
> normal
>
> Without the syntax support it's almost impossible to do that. At lease
> I can't figure out any.
>
Every volume has a name, even if you don't know it. Use grub-mkrelpath
to find out.
> Besides we may leverage that mount option support in grub-mount to
> test/develop and so on. For modern innovative file systems the mount
> option support is becoming necessary for dealing many different use
> cases.
>
This is feature request without usecase. As such it's rejected
automatically.
> Thanks,
> Michael
>
>>> And continue to interpret old syntax as relative to default.
>>>
>>>
>>>
>>> ___
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>
>>
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting btrfs
2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko :
> On 20.12.2013 10:46, Michael Chang wrote:
>> 2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko :
>>> On 19.12.2013 17:13, Andrey Borzenkov wrote:
В Mon, 28 Oct 2013 01:44:26 +0100
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> I changed in trunk to make / refer to real root and modified
> grub-mkrelpath to follow the same convention, even if disk is mounted
> with subvolid.
>
Can it cause compatibility issues? It means if config file that works
for grub before this change will stop working after. So e.g. attempt to
"configfile /file/from/partition/with/old/grub-mkconfig" will fail.
>>> Normally I'd consider this a problem but the current behaviour is the
>>> intended one, just back when the code was written thre were no changing
>>> default yes
May be subvolume support should use different syntax. Something like
(hd0,1){sv=subvolume}/xxx
(hd0,1){svid=NNN}/yyy
>>> This would complicate the code a lot and commit us to maintaining it
>>> long-term. Given that btrfs isn't clasified as stable, I consider this
>>> behaviour change acceptable and it's better to handle this now rather
>>> than perpetuating the issue.
>>
>> Please consider the case if a snapshot was taken against real root fs
>> tree to a subvolume with SNAPSHOT_ID. With syntax above providing
>> mount option support we can possibly boot that snapshot with this
>> config.
>>
>> set root=(hd0,1){svid=}
>> set prefix=($root)/boot/grub2
>> normal
>>
>> Without the syntax support it's almost impossible to do that. At lease
>> I can't figure out any.
>>
> Every volume has a name, even if you don't know it. Use grub-mkrelpath
> to find out.
That means we need to modify the grub,cfg in snapshot to make files
used by config refer to new path output by grub-mkrelpath (relative to
real root), right ? That could be difficult to manage especially if
you have a lot of snapshots and the update takes time to finish.
Compare to use path relative to snapshot's fs root, we can leave the
grub.cfg in snapshot unmodified and by setting snapshot id or name in
a master config to switch the snapshot we want to boot. That will make
things a lot easier.
>> Besides we may leverage that mount option support in grub-mount to
>> test/develop and so on. For modern innovative file systems the mount
>> option support is becoming necessary for dealing many different use
>> cases.
>>
> This is feature request without usecase. As such it's rejected
> automatically.
Probably a case is in os-prober, we can use that feature to have
grub-mount test subvolumes without resorting to linux mount. But I
admit that the gain is little.
Regards,
Michael
>> Thanks,
>> Michael
>>
And continue to interpret old syntax as relative to default.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>>
>>>
>>> ___
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting btrfs
On 20.12.2013 15:54, Michael Chang wrote:
> 2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko :
>> On 20.12.2013 10:46, Michael Chang wrote:
>>> 2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko :
On 19.12.2013 17:13, Andrey Borzenkov wrote:
> В Mon, 28 Oct 2013 01:44:26 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko пишет:
>
>> I changed in trunk to make / refer to real root and modified
>> grub-mkrelpath to follow the same convention, even if disk is mounted
>> with subvolid.
>>
>
> Can it cause compatibility issues? It means if config file that works
> for grub before this change will stop working after. So e.g. attempt to
> "configfile /file/from/partition/with/old/grub-mkconfig" will fail.
>
Normally I'd consider this a problem but the current behaviour is the
intended one, just back when the code was written thre were no changing
default yes
> May be subvolume support should use different syntax. Something like
>
> (hd0,1){sv=subvolume}/xxx
> (hd0,1){svid=NNN}/yyy
>
This would complicate the code a lot and commit us to maintaining it
long-term. Given that btrfs isn't clasified as stable, I consider this
behaviour change acceptable and it's better to handle this now rather
than perpetuating the issue.
>>>
>>> Please consider the case if a snapshot was taken against real root fs
>>> tree to a subvolume with SNAPSHOT_ID. With syntax above providing
>>> mount option support we can possibly boot that snapshot with this
>>> config.
>>>
>>> set root=(hd0,1){svid=}
>>> set prefix=($root)/boot/grub2
>>> normal
>>>
>>> Without the syntax support it's almost impossible to do that. At lease
>>> I can't figure out any.
>>>
>> Every volume has a name, even if you don't know it. Use grub-mkrelpath
>> to find out.
>
> That means we need to modify the grub,cfg in snapshot to make files
> used by config refer to new path output by grub-mkrelpath (relative to
> real root), right ? That could be difficult to manage especially if
> you have a lot of snapshots and the update takes time to finish.
>
> Compare to use path relative to snapshot's fs root, we can leave the
> grub.cfg in snapshot unmodified and by setting snapshot id or name in
> a master config to switch the snapshot we want to boot. That will make
> things a lot easier.
>
This is not a reason to force part of path name to become part of device
name. Also it leaves problem of passing right options to kernel to mount
right root open.
Because generated config in snapshot will reset $root, any attempt to
alter its behaviour by setting $root will fail anyway.
Sounds like this needs additional complications in generated grub.cfg
when on btrfs (E.g. overrideable $subvolume variable) and attempts to
change device naming schemes don't really solve any of problems but
create bunch of new ones.
The real solution for your problem has to involve sth like:
if [ x$bootdir = x ]; then
bootdir=
fi
if [ x$rootdir = x ]; then
rootdir=
fi
...
search
linux $bootdir/vmlinuz- root=.. subvol=$rootdir
initrd $bootdir/initrd.img
> Probably a case is in os-prober, we can use that feature to have
> grub-mount test subvolumes without resorting to linux mount. But I
> admit that the gain is little.
>
Why isn't the use of subvolume name appropriate?
One of these days, just for the people who insist un numeric ids rather
than names I should write a patch to Linux which ones files only by
inode id and no file name.
> Regards,
> Michael
>
>>> Thanks,
>>> Michael
>>>
> And continue to interpret old syntax as relative to default.
>
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>> ___
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>
>>
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v3 2/2] arm64: add EFI Linux loader
Bugfix of v2 loaded_fdt handling and removal of redundant typedefs.
---
grub-core/Makefile.core.def|3 +-
grub-core/loader/arm64/linux.c | 479
include/grub/arm64/linux.h | 54 +
include/grub/efi/api.h |4 +
4 files changed, 539 insertions(+), 1 deletion(-)
create mode 100644 grub-core/loader/arm64/linux.c
create mode 100644 include/grub/arm64/linux.h
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index e5e558c..c916246 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1672,7 +1672,8 @@ module = {
sparc64_ieee1275 = loader/sparc64/ieee1275/linux.c;
ia64_efi = loader/ia64/efi/linux.c;
arm = loader/arm/linux.c;
- arm = lib/fdt.c;
+ arm64 = loader/arm64/linux.c;
+ fdt = lib/fdt.c;
common = loader/linux.c;
common = lib/cmdline.c;
enable = noemu;
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
new file mode 100644
index 000..52c6160
--- /dev/null
+++ b/grub-core/loader/arm64/linux.c
@@ -0,0 +1,479 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2013 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see
Re: Important EHCI bugfix (Re: grub-2.02~beta1 happened)
Dne 20.12.2013 13:16, Vladimir 'φ-coder/phcoder' Serbinenko napsal(a): > On 19.12.2013 20:59, Aleš Nesrsta wrote: >> Hi Vladimir, >> >> it would be fine if the bugfix, posted by me in ML thread "EHCI/USBMS >> corrections" (12/16/2013), will be included in the final release. It >> solves serious bug. >> > Check the git, it's already there, in cleaned up form. Nice, thanks! BR, Ales signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting btrfs
On Dec 20, 2013, at 7:54 AM, Michael Chang wrote: >> Every volume has a name, even if you don't know it. Use grub-mkrelpath >> to find out. > > That means we need to modify the grub,cfg in snapshot to make files > used by config refer to new path output by grub-mkrelpath (relative to > real root), right ? That could be difficult to manage especially if > you have a lot of snapshots and the update takes time to finish. This isn't just a problem for core.img looking for the wrong grub.cfg for a /boot on Btrfs subvolume snapshot. It's a problem for that grub.cfg pointing to the wrong root snapshot. And it's a problem for the /etc/fstab on that root snapshot, which is likewise incorrect and will be asking for the wrong subvolumes to be mounted. I really don't think snapshot management is GRUB's job. I think all of this snapshot management is a userspace tool, and it's going to have to figure out a way to deal with this. And probably the simplest solution in the short term is for this user space tool to rename the subvolumes. So e.g. subvolumes: boot root home And their read only snapshots: boot_ro.1 boot_ro.2 root_ro.1 root_ro.2 home_ro.1 home_ro.2 The user uses a tool to indicate they now want to boot "the most recent snapshot", and the tool does: mv boot boot_ro.0 mv root root_ro.0 mv home home_ro.0 btrfs subvol snapshot boot_ro.1 boot btrfs subvol snapshot root_ro.1 root btrfs subvol snapshot home_ro.1 root The lack of -r makes the snapshots rw, the file system metadata contains relationship information: each snapshot has a uuid, and a parent uuid. And the parent contains information about each snapshot made of it. But all of this is domain of the snapshot tool. That's a lot easier than having to go find fstab, grub.cfg, and figure out how to get core.img to know what boot subvolume was intended, etc. > Compare to use path relative to snapshot's fs root, we can leave the > grub.cfg in snapshot unmodified and by setting snapshot id or name in > a master config to switch the snapshot we want to boot. That will make > things a lot easier. That sounds something like the Bootloaderspec, which I like in principle in that it recognizes how hostile the distributions are at breaking the boot behavior of the prior OS, in multiboot contexts. But there's some other things that just don't seem workable, and it's also not even adopted upstream yet by GRUB and I don't know what the status of this whole idea is. I think the idea of snapshots in the domain of a boot manager/boot loader is really overly complicated. For another thing, it's not really appropriate to do a rollback and then immediately start modifying it by booting from it. What you'd want to do is snapshot the rollback, and then use that "cloned" copy of the rollback, leaving the original rollback in place. Otherwise the provenance of that snapshot is obliterated. And with all of these snapshots being created, something to clean up all these bouquets is necessary. Do we really want GRUB doing that also? I just this this is out of scope for GRUB. An FHS for Btrfs installation locations and shapshot behaviors is possibly needed, so the distributions aren't stepping all over each other in an even worse way that booting already is. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting btrfs
В Fri, 20 Dec 2013 21:38:47 -0700 Chris Murphy пишет: > > On Dec 20, 2013, at 7:54 AM, Michael Chang wrote: > > >> Every volume has a name, even if you don't know it. Use grub-mkrelpath > >> to find out. > > > > That means we need to modify the grub,cfg in snapshot to make files > > used by config refer to new path output by grub-mkrelpath (relative to > > real root), right ? That could be difficult to manage especially if > > you have a lot of snapshots and the update takes time to finish. > > This isn't just a problem for core.img looking for the wrong grub.cfg for a > /boot on Btrfs subvolume snapshot. It's a problem for that grub.cfg pointing > to the wrong root snapshot. And it's a problem for the /etc/fstab on that > root snapshot, which is likewise incorrect and will be asking for the wrong > subvolumes to be mounted. > > I really don't think snapshot management is GRUB's job. I think all of this > snapshot management is a userspace tool, and it's going to have to figure out > a way to deal with this. Yes I completely agree here. Expecting to be able to boot from pure btrfs snapshot is naïve. Michael, here is what openSUSE does by default when you tell it to use btrfs: linux-dwhw:~ # btrfs subvolume list / ID 256 gen 47 top level 5 path boot/grub2/i386-pc ID 258 gen 18 top level 5 path home ID 259 gen 18 top level 5 path opt ID 260 gen 18 top level 5 path srv ID 261 gen 65 top level 5 path tmp ID 262 gen 52 top level 5 path usr/local ID 263 gen 18 top level 5 path var/crash ID 264 gen 67 top level 5 path var/log ID 265 gen 18 top level 5 path var/opt ID 266 gen 62 top level 5 path var/spool ID 267 gen 57 top level 5 path var/tmp ID 269 gen 59 top level 5 path .snapshots ID 270 gen 58 top level 5 path .snapshots/1/snapshot ID 271 gen 78 top level 5 path test linux-dwhw:~ # grep btrfs /proc/self/mountinfo 21 1 0:17 / / rw,relatime shared:1 - btrfs /dev/sda2 rw,space_cache "test" is snapshot of / which I set as default and am currently booted with it. linux-dwhw:~ # btrfs subvolume get-default / ID 271 gen 78 top level 5 path test And if I now try to access any other subvolumes ... linux-dwhw:~ # ls -l /boot/grub2/i386-pc/ total 0 linux-dwhw:~ # touch /boot/grub2/i386-pc/x touch: cannot touch ‘/boot/grub2/i386-pc/x’: Permission denied linux-dwhw:~ # ls -l /var/spool total 0 linux-dwhw:~ # touch /var/spool/x touch: cannot touch ‘/var/spool/x’: Permission denied linux-dwhw:~ # ls -l /var/log total 0 linux-dwhw:~ # touch /var/log/x touch: cannot touch ‘/var/log/x’: Permission denied So booting from this snapshot is rather useless. The point here is - creating of fully functional alternate boot environment involves a bit more than single "btrfs subvolume snapshot" invocation. Adding "grub-mkconfig" (or even grub-mkimage to record correct prefix) is really just the minor part of it. > And probably the simplest solution in the short term is for this user > space tool to rename the subvolumes. So e.g. subvolumes: > > boot > root > home > > And their read only snapshots: > > boot_ro.1 > boot_ro.2 > root_ro.1 > root_ro.2 > home_ro.1 > home_ro.2 > > The user uses a tool to indicate they now want to boot "the most recent > snapshot", and the tool does: > > mv boot boot_ro.0 > mv root root_ro.0 > mv home home_ro.0 > btrfs subvol snapshot boot_ro.1 boot > btrfs subvol snapshot root_ro.1 root > btrfs subvol snapshot home_ro.1 root > Do you need to reinvent the wheel? /Boot-Environments /Boot_Environment_1 /root /boot ... /Boot_Environment_2 ... The only thing you need to do to switch is equivalent of "btrfs set-default /Boot-Environments/Boot_Envirnment_2 ... except it is not that straightforward in current btrfs because path names are resolved relative to current root :) > The lack of -r makes the snapshots rw, the file system metadata contains > relationship information: each snapshot has a uuid, and a parent uuid. And > the parent contains information about each snapshot made of it. But all of > this is domain of the snapshot tool. That's a lot easier than having to go > find fstab, grub.cfg, and figure out how to get core.img to know what boot > subvolume was intended, etc. > > > > Compare to use path relative to snapshot's fs root, we can leave the > > grub.cfg in snapshot unmodified and by setting snapshot id or name in > > a master config to switch the snapshot we want to boot. That will make > > things a lot easier. > Michael, snapshot of *what*? Whatever means you will use (set-default, environment variable, mount options) can set only one single property - root of filesystem. You *STILL* need to describe relationships between different (snapshots of) multiple subvolumes. I.e. *which* snapshot of /boot/grub2/i386-pc are you going to access? Having grub to always use full pathnames makes it unambiguous. Otherwise it is unmanageable on grub level (*any* directory you access may potentially have multiple versions). This must really be solved on OS le
