overall I'm quite pleased with genkernel and have relegated much
tedium to its functions over time. perhaps it's a worthy mule for
more responsibility.
I have mirror volumes which have survived almost 8 years with 2nd and
third generation drives, motherboard, and architecture (32->64 bit).
On Tue, 2005-05-24 at 14:11 -0700, Jim Northrup wrote:
> I'm very happy with new GUID-based volume mounting and more stable raid
> tools, but a CF-based or initrd root available when /lib goes to hell is
> an absolute must for supporting fault tolerance.
If you use genkernel to build your kernel
Mike Frysinger wrote:
> On Tuesday 24 May 2005 06:34 pm, Jim Northrup wrote:
>
>>of course bb is a space-saver, but i find myself turning the room upside
>>down for full-static versions of tar, nc and fileutils
>
>
> bb is static and it supports tar, nc, and many fileutils ;)
> -mike
If only a
On Tuesday 24 May 2005 06:34 pm, Jim Northrup wrote:
> of course bb is a space-saver, but i find myself turning the room upside
> down for full-static versions of tar, nc and fileutils
bb is static and it supports tar, nc, and many fileutils ;)
-mike
--
gentoo-dev@gentoo.org mailing list
Mike Frysinger wrote:
On Tuesday 24 May 2005 05:11 pm, Jim Northrup wrote:
but a CF-based or initrd root available when /lib goes to hell is
an absolute must for supporting fault tolerance.
do you mean like the disk underneath /lib is blown to crap or a bad glibc is
merged ?
if the
On Tuesday 24 May 2005 05:11 pm, Jim Northrup wrote:
> but a CF-based or initrd root available when /lib goes to hell is
> an absolute must for supporting fault tolerance.
do you mean like the disk underneath /lib is blown to crap or a bad glibc is
merged ?
if the latter, then the new busybox ca
I had smashing success migratingraid volumes to a new motherboard by
building a readonly loopback boot-cd rootfs volume, and using
cp -sr /mnt/rescue /mnt/newroot
before building stage2,3; with minor /etc grumbling, the system
bootstrapped flawlessly while still borrowing a few sensitive stat
On Tue, 2005-05-17 at 10:33 -0700, Donnie Berkholz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Chris Gianelloni wrote:
> > A much better approach would be for there to be a rescue build,
> > completely independent of the stages, since it doesn't need to mirror
> > them in any way.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Gianelloni wrote:
> A much better approach would be for there to be a rescue build,
> completely independent of the stages, since it doesn't need to mirror
> them in any way. It should be extracted (self-extracted?) to something
> like /rescue a
On Mon, 2005-05-16 at 20:48 -0400, Olivier CrÃte wrote:
> I would tend to believe that the content of a stage1 or stage2 would be
> enough and just for the majors architectures (those that have a
> stage1).. Anyways people will rebuild said packages once that's done,
> right? That's not much for th
On Mon, 2005-16-05 at 09:57 -0400, Chris Gianelloni wrote:
> This would add quite a bit of space to the mirrors. The average stage3
> tarball is about 100MB. So you can assume that the packages would equal
> about the same. Multiply this by the number of releasing arches, and
> possibly even sub
On 5/16/05, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> This would add quite a bit of space to the mirrors. The average stage3
> tarball is about 100MB. So you can assume that the packages would equal
> about the same. Multiply this by the number of releasing arches, and
> possibly even subarc
On Sun, 2005-05-15 at 17:31 -0400, Olivier CrÃte wrote:
> I had exactly the same problem recently and I had a hard time finding a
> fitting tbz2 since the package was part of the stages and not the GRP.
>
> Just having packages built as part of a stage3 uploaded somewhere
> as .tbz2s on the mirror
On Sun, 2005-05-15 at 22:24 +0100, Carlos Silva wrote:
> > i dont think it'd be too hard to integrate this 'rescue set' into a
> > catalyst
> > target so that it'll become part of our normal release schedule of stage
> > tarballs
Weren't we just talking about people proposing work for other pro
I've been in this position more than once, and had to go through the
bootcd+binaries (thanks to http://dev.gentoo.org/~avenj/bins/)
restore. Argh. I've often thought that atomic updates and rollback
within portage would be useful - maybe it could just be done as a
layer over subversion for Gentoo u
On 5/16/05, David Stanek <[EMAIL PROTECTED]> wrote:
> If erescue is a statically built binary that basically untars a
> backed up copy of a package, why would it depend on Python?
It won't. Thats the whole point.
Colin
--
gentoo-dev@gentoo.org mailing list
On Sun, May 15, 2005 at 09:07:15PM -0700, Sami Samhuri wrote:
> * On Sun May-15-2005 at 05:18:06 PM -0400, Mike Frysinger said:
> [...]
> > my proposal is to implement a new utility (called 'erescue' for lack of a
> > better name) that is written in C and designed to be statically linked ...
> >
* On Sun May-15-2005 at 05:18:06 PM -0400, Mike Frysinger said:
[...]
> my proposal is to implement a new utility (called 'erescue' for lack of a
> better name) that is written in C and designed to be statically linked ...
> then next time you break a core system package which cannot be recovered
On Sun, May 15, 2005 at 09:56:54PM -0400, David Stanek wrote:
> On Sun, May 15, 2005 at 06:12:13PM -0700, John Myers wrote:
> > On Sunday 15 May 2005 16:41, david stanek wrote:
> > > Add an option to emerge, --backup or something
> > > similar, that will automatically run quickpkg.
> >
> > If you
On Sun, 2005-15-05 at 17:18 -0400, Mike Frysinger wrote:
> for example, when i broke binutils in unstable with a gcc4 patch, i noticed
> that it's hard for users to *easily* recover from this ... we developers end
> up scrambling to build a bunch of binary packages for a variety of compatible
>
On Sun, May 15, 2005 at 06:12:13PM -0700, John Myers wrote:
> On Sunday 15 May 2005 16:41, david stanek wrote:
> > Add an option to emerge, --backup or something
> > similar, that will automatically run quickpkg.
>
> If you set FEATURES="buildpkg", portage automatically makes binary packages
> fo
On Sunday 15 May 2005 16:41, david stanek wrote:
> Add an option to emerge, --backup or something
> similar, that will automatically run quickpkg.
If you set FEATURES="buildpkg", portage automatically makes binary packages
for you. No need to add new support.
pgpqwMjzk44tL.pgp
Description: PGP
On Sunday 15 May 2005 07:41 pm, david stanek wrote:
> On Sun, May 15, 2005 at 03:32:40PM -0700, Donnie Berkholz wrote:
> > Krzysiek Pawlik wrote:
> > > Use `quickpkg` before dangerous updates/merges. If something brakes -
> > > untar the package.
> >
> > Doesn't work too well when tar's broken too.
On Sun, May 15, 2005 at 03:32:40PM -0700, Donnie Berkholz wrote:
>
> Krzysiek Pawlik wrote:
> > Use `quickpkg` before dangerous updates/merges. If something brakes -
> > untar the package.
>
> Doesn't work too well when tar's broken too. =)
How about statically linking a version of tar with porta
* On Sun May-15-2005 at 04:48:04 PM -0600, Ryan said:
[...]
> something, then its your fault for not having a backup. Of coarse this
> is just ONE way to backup. There are a bazillion ways to do it. The
> choice is up to you. Besides, if you are running the unstable branch
And if Gentoo provide
Donnie Berkholz wrote:
>> Use `quickpkg` before dangerous updates/merges. If something brakes -
>> untar the package.
>
> Doesn't work too well when tar's broken too. =)
Use static tar na bzip2 ;) Seriously: I'm for erescue (or whatever name
will be chosen).
--
Krzysiek 'Nelchael' Pawlik RL
Heres the easiest way to do your "erescue"
dd if=/dev/hda of=backup.iso
"Three days later: AAAHHH! I blew up the /usr dir!"
mkdir /backup
mount -o loop backup.iso /backup
cp -f -r -a /backup/usr /
Pretty simple no?
And there you have it. Backup shouldnt really be the burdon of
developers. T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Krzysiek Pawlik wrote:
> Use `quickpkg` before dangerous updates/merges. If something brakes -
> untar the package.
Doesn't work too well when tar's broken too. =)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCh84IXVaO67S1rt
Mike Frysinger wrote:
> [...]
Use `quickpkg` before dangerous updates/merges. If something brakes -
untar the package.
--
Krzysiek 'Nelchael' Pawlik RLU #322999[EMAIL PROTECTED]
gentoo base system - kernel 2.6.11-ck8 GPG:0x7E226904
http://fatcat.ftj.agh.edu.pl/~nelchael
On Sun, 2005-05-15 at 17:18 -0400, Mike Frysinger wrote:
> one advantage that other binary based package managers have over Gentoo is
> ease of recovery from broken core packages ... break your gcc ? no problem !
>
> simply do `apt-get install gcc` or `rpm -i gcc` or whatever
>
> my proposal
On Sun, 2005-05-15 at 17:18 -0400, Mike Frysinger wrote:
> my proposal is to implement a new utility (called 'erescue' for lack of a
> better name) that is written in C and designed to be statically linked ...
> then next time you break a core system package which cannot be recovered by
> simply
On Sun, 2005-05-15 at 17:18 -0400, Mike Frysinger wrote:
> one advantage that other binary based package managers have over Gentoo is
> ease of recovery from broken core packages ... break your gcc ? no problem !
>
> simply do `apt-get install gcc` or `rpm -i gcc` or whatever
>
> my proposal
one advantage that other binary based package managers have over Gentoo is
ease of recovery from broken core packages ... break your gcc ? no problem !
simply do `apt-get install gcc` or `rpm -i gcc` or whatever
my proposal is to implement a new utility (called 'erescue' for lack of a
better
33 matches
Mail list logo
