FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 06-02-2010, 07:04 PM
Jon Masters
 
Default suggestion: rescue boot extension

Folks,

There are various projects implementing LiveCD, rescue, or snapshotted
updates. I would like to propose a feature in which some of the
rescue/LiveCD bits are (optionally) installed to a spare volume during
install such that there's always a rescue/Live boot option that can boot
up to a recovery desktop without needing to grab media, etc.

Modern disks are large and cheap (even some SSDs). I can't see a
downside and it helps with all manner of botched updates. Snapshots help
aswell, but there are many times where you just want something more than
a single user boot to fix some breakage.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 07:21 PM
seth vidal
 
Default suggestion: rescue boot extension

On Wed, 2010-06-02 at 15:04 -0400, Jon Masters wrote:
> Folks,
>
> There are various projects implementing LiveCD, rescue, or snapshotted
> updates. I would like to propose a feature in which some of the
> rescue/LiveCD bits are (optionally) installed to a spare volume during
> install such that there's always a rescue/Live boot option that can boot
> up to a recovery desktop without needing to grab media, etc.
>
> Modern disks are large and cheap (even some SSDs). I can't see a
> downside and it helps with all manner of botched updates. Snapshots help
> aswell, but there are many times where you just want something more than
> a single user boot to fix some breakage.
>

Maybe this request is better made to anaconda?

so it stuffs a rescue image in place when it writes grub to begin with?

or do you envision it as a 'rescue image' pkg that is installed in @base
or some-such?

-sv


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 07:54 PM
Bill Nottingham
 
Default suggestion: rescue boot extension

Jon Masters (jonathan@jonmasters.org) said:
> There are various projects implementing LiveCD, rescue, or snapshotted
> updates. I would like to propose a feature in which some of the
> rescue/LiveCD bits are (optionally) installed to a spare volume during
> install such that there's always a rescue/Live boot option that can boot
> up to a recovery desktop without needing to grab media, etc.
>
> Modern disks are large and cheap (even some SSDs). I can't see a
> downside and it helps with all manner of botched updates. Snapshots help
> aswell, but there are many times where you just want something more than
> a single user boot to fix some breakage.

Hm. I can see the use of this, but I can also see issues with how you
do updates for it sanely (if at all.)

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 08:02 PM
Jon Masters
 
Default suggestion: rescue boot extension

On Wed, 2010-06-02 at 15:54 -0400, Bill Nottingham wrote:
> Jon Masters (jonathan@jonmasters.org) said:
> > There are various projects implementing LiveCD, rescue, or snapshotted
> > updates. I would like to propose a feature in which some of the
> > rescue/LiveCD bits are (optionally) installed to a spare volume during
> > install such that there's always a rescue/Live boot option that can boot
> > up to a recovery desktop without needing to grab media, etc.
> >
> > Modern disks are large and cheap (even some SSDs). I can't see a
> > downside and it helps with all manner of botched updates. Snapshots help
> > aswell, but there are many times where you just want something more than
> > a single user boot to fix some breakage.
>
> Hm. I can see the use of this, but I can also see issues with how you
> do updates for it sanely (if at all.)

Yea. I think you don't do updates for it in general. I think I agree
with Seth that this is something Anaconda stuffs in place when it
installs grub. Optionally, maybe you upgrade it once per release when
you next run Anaconda, but basically it doesn't change. It's about "get
me booted to more than a command line to fix stuff", not latest glitz.

That said, of course eventually you could have two of these images and
allow for them to be upgraded, etc. etc. To start with though, I think
there's a lot of value in pre-committing a couple hundred MB of disk
space to having a rescue environment always on.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 08:03 PM
Roland McGrath
 
Default suggestion: rescue boot extension

> Hm. I can see the use of this, but I can also see issues with how you
> do updates for it sanely (if at all.)

Why would you do updates for it? Your install CD/DVD to use for rescue
boot doesn't get updated. I'd think you'd just install a pristine newer
one verbatim if you had a reason to bother, like deciding to burn a new CD.
Hence the nice automagic deployment feature would reserve two partitions
(or whatevers) for the purpose, so you can install the new image on B and
still have the option to boot A if the new one is bad.


Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 08:10 PM
Jon Masters
 
Default suggestion: rescue boot extension

On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote:
> > Hm. I can see the use of this, but I can also see issues with how you
> > do updates for it sanely (if at all.)
>
> Why would you do updates for it? Your install CD/DVD to use for rescue
> boot doesn't get updated. I'd think you'd just install a pristine newer
> one verbatim if you had a reason to bother, like deciding to burn a new CD.
> Hence the nice automagic deployment feature would reserve two partitions
> (or whatevers) for the purpose, so you can install the new image on B and
> still have the option to boot A if the new one is bad.

So I'm willing to help out on this (once RHEL stuff calms down a bit).
Do you think it's worth us putting together a wiki feature proposal?

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 08:13 PM
Eric Sandeen
 
Default suggestion: rescue boot extension

Jon Masters wrote:
> On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote:
>>> Hm. I can see the use of this, but I can also see issues with how you
>>> do updates for it sanely (if at all.)
>> Why would you do updates for it? Your install CD/DVD to use for rescue
>> boot doesn't get updated. I'd think you'd just install a pristine newer
>> one verbatim if you had a reason to bother, like deciding to burn a new CD.
>> Hence the nice automagic deployment feature would reserve two partitions
>> (or whatevers) for the purpose, so you can install the new image on B and
>> still have the option to boot A if the new one is bad.
>
> So I'm willing to help out on this (once RHEL stuff calms down a bit).
> Do you think it's worth us putting together a wiki feature proposal?
>
> Jon.
>
>

Is it better to have a separate volume for this, or to just have a sort
of rescue initramfs ...?

Seems like the latter is more flexible but then I'm no boot process wizard.

-Eric
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 08:22 PM
"Richard W.M. Jones"
 
Default suggestion: rescue boot extension

On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote:
> Jon Masters wrote:
> > On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote:
> >>> Hm. I can see the use of this, but I can also see issues with how you
> >>> do updates for it sanely (if at all.)
> >> Why would you do updates for it? Your install CD/DVD to use for rescue
> >> boot doesn't get updated. I'd think you'd just install a pristine newer
> >> one verbatim if you had a reason to bother, like deciding to burn a new CD.
> >> Hence the nice automagic deployment feature would reserve two partitions
> >> (or whatevers) for the purpose, so you can install the new image on B and
> >> still have the option to boot A if the new one is bad.
> >
> > So I'm willing to help out on this (once RHEL stuff calms down a bit).
> > Do you think it's worth us putting together a wiki feature proposal?
> >
> > Jon.
> >
> >
>
> Is it better to have a separate volume for this, or to just have a sort
> of rescue initramfs ...?

Or if you are able to run a little bit of C code[1] and can read files
from the root partition (as grub can), you can build one on the fly
using binaries, libraries etc found on the root disk, which is what we
do in libguestfs.

Rich.

[1] http://git.annexia.org/?p=febootstrap.git;a=blob;f=febootstrap-supermin-helper.c;hb=HEAD

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 08:25 PM
Eric Sandeen
 
Default suggestion: rescue boot extension

Richard W.M. Jones wrote:
> On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote:
>> Jon Masters wrote:
>>> On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote:
>>>>> Hm. I can see the use of this, but I can also see issues with how you
>>>>> do updates for it sanely (if at all.)
>>>> Why would you do updates for it? Your install CD/DVD to use for rescue
>>>> boot doesn't get updated. I'd think you'd just install a pristine newer
>>>> one verbatim if you had a reason to bother, like deciding to burn a new CD.
>>>> Hence the nice automagic deployment feature would reserve two partitions
>>>> (or whatevers) for the purpose, so you can install the new image on B and
>>>> still have the option to boot A if the new one is bad.
>>> So I'm willing to help out on this (once RHEL stuff calms down a bit).
>>> Do you think it's worth us putting together a wiki feature proposal?
>>>
>>> Jon.
>>>
>>>
>> Is it better to have a separate volume for this, or to just have a sort
>> of rescue initramfs ...?
>
> Or if you are able to run a little bit of C code[1] and can read files
> from the root partition (as grub can), you can build one on the fly
> using binaries, libraries etc found on the root disk, which is what we
> do in libguestfs.

.... which then solves the "how do I update it?" problem.

(of course if you're trying to recover from an update that borked your
system, I guess you hope you didn't update the rescue recently!)

-Eric

> Rich.
>
> [1] http://git.annexia.org/?p=febootstrap.git;a=blob;f=febootstrap-supermin-helper.c;hb=HEAD
>

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-02-2010, 08:33 PM
Jon Masters
 
Default suggestion: rescue boot extension

On Wed, 2010-06-02 at 21:22 +0100, Richard W.M. Jones wrote:
> On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote:

> > Is it better to have a separate volume for this, or to just have a sort
> > of rescue initramfs ...?
>
> Or if you are able to run a little bit of C code[1] and can read files
> from the root partition (as grub can), you can build one on the fly
> using binaries, libraries etc found on the root disk, which is what we
> do in libguestfs.

I specifically think this is not the solution It's great for
libguestfs, but the idea here is to have known-good binaries that can be
used to recover a system - and that change very rarely indeed (on the
same order as the "physical" media containing the installer) - when it
is broken during an update or otherwise. If the system is already
busticated, then building images from it will not help.

A recovery initramfs could be used. It could just basically be the
rescue mode anaconda bits in one image shoved in place to start.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 07:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org