* Replacing the top-level root
@ 2010-10-25 20:20 C Anthony Risinger
2010-10-27 5:53 ` David Brown
0 siblings, 1 reply; 3+ messages in thread
From: C Anthony Risinger @ 2010-10-25 20:20 UTC (permalink / raw)
To: Chris Mason, Sage Weil, linux-btrfs
On Mon, Oct 25, 2010 at 2:58 PM, Chris Mason <chris.mason@oracle.com> wrote:
>
> Oh, and it shouldn't work on the root of the FS either ;)
>
> -chris
This is not 100% related but...
Will removing [replacing] the top-level root be something that
can/will be supported? I've asked in the past about this regarding an
initramfs hook i maintain implementing system rollbacks, but I never
really got a solid answer.
For example, right now extlinux support booting btrfs, but _only_ from
the top-level root. if i just had a way to "swap" the top-level root
with a different subvol, i could overcome several problems i have with
users all at once:
) users install their system to the top-level root, which means it is
no longer manageable by snapshot scripts [currently]
) if the top-level root could be swapped, extlinux could then boot my
snapshot? (i'm probably wrong here)
"set-default" is not enough; i'm looking for a way to gain control
over the system state when the system has been installed into the
top-level root. currently, i have no way to manipulate/move/change
it, because the top-level is essentially "immutable", or so it seems.
thus it's not possible to support kernel rollbacks without manually
syncing <snapshot>/boot to /boot.
is there a solution to this that i'm missing?
C Anthony
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Replacing the top-level root 2010-10-25 20:20 Replacing the top-level root C Anthony Risinger @ 2010-10-27 5:53 ` David Brown 2010-10-27 16:52 ` C Anthony Risinger 0 siblings, 1 reply; 3+ messages in thread From: David Brown @ 2010-10-27 5:53 UTC (permalink / raw) To: C Anthony Risinger; +Cc: Chris Mason, Sage Weil, linux-btrfs On Mon, Oct 25, 2010 at 03:20:58PM -0500, C Anthony Risinger wrote: >For example, right now extlinux support booting btrfs, but _only_ from >the top-level root. if i just had a way to "swap" the top-level root >with a different subvol, i could overcome several problems i have with >users all at once: > >) users install their system to the top-level root, which means it is >no longer manageable by snapshot scripts [currently] >) if the top-level root could be swapped, extlinux could then boot my >snapshot? (i'm probably wrong here) I don't think this is a solution to the extlinux problem, but I've moved roots into new subvolumes, basically something like this. Root is mounted as /, I've also mounted the volume on /mounted in this example. # btrfs subvolume snapshot /mounted /mounted/newrootname Now reboot, adding the subvol option to use the newrootname. Go into /mounted and make sure files touced there don't show up in '/' (we really are mounting the submount). Then just use rm -rf to remove everything that isn't a subvol. I don't know of an easy way to do that, and be careful. This doesn't really change the default root, but by making a snapshot of it, can move all of the data elsewhere. David ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Replacing the top-level root 2010-10-27 5:53 ` David Brown @ 2010-10-27 16:52 ` C Anthony Risinger 0 siblings, 0 replies; 3+ messages in thread From: C Anthony Risinger @ 2010-10-27 16:52 UTC (permalink / raw) To: David Brown; +Cc: Chris Mason, Sage Weil, linux-btrfs On Wed, Oct 27, 2010 at 12:53 AM, David Brown <btrfs@davidb.org> wrote: > On Mon, Oct 25, 2010 at 03:20:58PM -0500, C Anthony Risinger wrote: > >> For example, right now extlinux support booting btrfs, but _only_ fr= om >> the top-level root. =A0if i just had a way to "swap" the top-level r= oot >> with a different subvol, i could overcome several problems i have wi= th >> users all at once: >> >> ) users install their system to the top-level root, which means it i= s >> no longer manageable by snapshot scripts [currently] >> ) if the top-level root could be swapped, extlinux could then boot m= y >> snapshot? (i'm probably wrong here) > > I don't think this is a solution to the extlinux problem, but I've > moved roots into new subvolumes, basically something like this. > > Root is mounted as /, I've also mounted the volume on /mounted in thi= s > example. > > =A0# btrfs subvolume snapshot /mounted /mounted/newrootname > > Now reboot, adding the subvol option to use the newrootname. > Go into /mounted and make sure files touced there don't show up in '/= ' > (we really are mounting the submount). > > Then just use rm -rf to remove everything that isn't a subvol. =A0I > don't know of an easy way to do that, and be careful. yeah, this is precisely what i do currently... the problem is i have to tell the user to do this themselves, as there isn't a way to safely accomplish it automatically. i expect this will become a more common problem, esp. for those trying to integrate advanced btrfs handlers into their distro; like myself. basically, i have ultimate control over all subvols, except top-level, and i want to why/how to address this. imo, if there really is not a proper solution to this issue because of some technical reason, i think mkfs.btrfs should automatically create a subvol, and mark it default... because from the feedback i'm getting or lack thereof, the top-level subvol is dangerous because it's not manageable. this should be done immediately imo, but at the very least, once grub2/extlinux support booting from subvols. thoughts? C Anthony -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-10-27 16:52 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-10-25 20:20 Replacing the top-level root C Anthony Risinger 2010-10-27 5:53 ` David Brown 2010-10-27 16:52 ` C Anthony Risinger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).