Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays
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, then you will have a usable initrd with lvm2/evms/dmraid (via --lvm2, --evms, or --dmraid) capabilities and tools for rescuing your system. This is only good for filesystem rescue, though. It won't help you if you emerge a bad copy of binutils or gcc. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays
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). in those years, the newer revs which don't jump up and bite me in the ass probably go unnoticed.. abstractly speaking, the clearest working example of what breaks is oft-times a recent kernel on a recent install disk. slopping an install disk on a modern hard-drive consumes but a gnat's real-estate. using a symlink foundation does a pretty good job of allowing emerge to over-write the static known-good binaries with dynamics, but occasionally the gcc and/or libc is a repeatable failure and having the ro overlay handy allows wholesale excision of the broken installs, esp on young architectures. for whatever reasons, I pack my cd-rom drive bays with hard drives, and install with a cd-rom hanging off the side of the case tethered by its cables... right about the time its a bootable system the cd- rom comes off and the box is tucked into some crawl-space or other behind desks, shelves, etc. and hopefully forgotten. On May 25, 2005, at 6:32 AM, Chris Gianelloni wrote: 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, then you will have a usable initrd with lvm2/evms/dmraid (via --lvm2, --evms, or --dmraid) capabilities and tools for rescuing your system. This is only good for filesystem rescue, though. It won't help you if you emerge a bad copy of binutils or gcc. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays
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 latter, then the new busybox can help ... just boot with init=/bin/bb and you should have plenty of tools to recover with -mike great advice. I've learned whenever md or devfs rework occurs, or the **/sbin tools get rev'd, its foolish to proceed without a rescue nearby. 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 Jim -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays
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
Re: [gentoo-dev] i have an idea ! (erescue)
-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 and executed from there, being completely self-contained. This keeps it from stomping on system files and breaking collision-protect or doing anything else nasty like hosing configuration files (ever made the mistake of extracting a stage onto a live filesystem?) when unpacked. This sounds a lot like saying, use an initrd, but when you pivot roots to the live filesystem, leave it mounted somewhere. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCiirqXVaO67S1rtsRAgHyAJ49adhPpYhwHqUeFNMw4I6h+GUyDwCfbwMB rgA0GKbYsBjd8K9I7X2pyE8= =tZSe -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue)
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
Re: [gentoo-dev] i have an idea ! (erescue)
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 updated binary packages. Or maybe rebuilding from source is preferable. Anyway, it would be very useful to be able to revert to a known good state with a single command. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue)
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 subarches, and you have an additional 1GB just from x86/ppc. i don't believe this was meant to be a full replace anything that breaks kind of system here. just a simple rescue program that would get you very basic stuff, like portage, python, the toolchain. for any arch they could be optimized to the lowest common denominator, like i386... and then once they are installed and the user's system works again, they use the again working portage or compiler to rebuild the exact version they want. it isn't a huge substantial hit, and the rescue packages don't have to be the latest version in question, they can be updated once a release, or once a year, leaving a fairly small footprint. i also like the idea of it being wholly seperate from portage, which neatly eliminates several points of failure, and keeps the portage code a bit easier to control. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue)
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 subarches, and you have an additional 1GB just from x86/ppc. 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 the mirrors.. Around 168 megs for the content of a stage1 or 300 megs for the stage2.. [EMAIL PROTECTED] releases $ find . -name stage1-*-2005.0.tar.bz2 |xargs du -c 21084 ./amd64/2005.0/stages/stage1-amd64-2005.0.tar.bz2 17292 ./sparc/2005.0/sparc32/stages/stage1-sparc-2005.0.tar.bz2 20520 ./sparc/2005.0/sparc64/stages/stage1-sparc64-2005.0.tar.bz2 18012 ./x86/2005.0/stages/hardened/2.4/stage1-x86-hardened-2.4-2005.0.tar.bz2 18252 ./x86/2005.0/stages/hardened/2.6/stage1-x86-hardened-2.6-2005.0.tar.bz2 16424 ./x86/2005.0/stages/x86/stage1-x86-2005.0.tar.bz2 18720 ./ppc64/2005.0/stages/stage1-ppc64-2005.0.tar.bz2 18756 ./alpha/2005.0/stages/stage1-alpha-2005.0.tar.bz2 19468 ./ia64/2005.0/stages/stage1-ia64-2005.0.tar.bz2 168528 total -- Olivier Crête [EMAIL PROTECTED] x86 Security Liaison signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] i have an idea ! (erescue)
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 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 running `emerge` a few times, you run `erescue broken package` 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 compiler/libc combinations so the user can just wget the file and run `emerge binutils.tbz2` and be on their way the packages that would be eligible for an 'erescue' package would be just about everything when you do `USE=-* emerge system -ep` ... i'm sure we can trim many of those out though :) maybe even create a new USE flag for some of these core packages so that we can trim out more files the idea would be to create very bare min packages so that the user can simply 'rescue' themselves ... after that, they it's up to them to re-emerge the package to apply all their fun ricer-optimizations as they see fit 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 -mike I like the ideia :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] i have an idea ! (erescue)
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/ Never forget: 2 + 2 = 5 for extremely large values of 2. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue)
-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) iD8DBQFCh84IXVaO67S1rtsRAibiAKD6i0twE/06iCEqe+uiHa8ht3tUVQCgoYTo A+8VR9nD42r+NlH3M4tVFUE= =+Fva -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue)
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 RLU #322999[EMAIL PROTECTED] gentoo base system - kernel 2.6.11-ck8 GPG:0x7E226904 http://fatcat.ftj.agh.edu.pl/~nelchael/ According to my calculations the problem doesn't exist. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue)
* 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 provides yet another choice for one to use in recovery then that sounds good to me. :) -- Sami Samhuri pgpuMMGhtbdVw.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
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 portage. This way tar cannot be broken. Add an option to emerge, --backup or something similar, that will automatically run quickpkg. Then make a erescue executable that can parse the command line to figure out which package the user wants to be rescued from, and execute the new tar command. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpQUoBThCuhI.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
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 signature
Re: [gentoo-dev] i have an idea ! (erescue)
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 for you. No need to add new support. That would build a binary package for the potentially broken package. What it would need to do is build a binary package of the existing merged package. So a user can recover from a botched upgrade. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpXNiuhdlWu3.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
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 set FEATURES=buildpkg, portage automatically makes binary packages for you. No need to add new support. That would build a binary package for the potentially broken package. What it would need to do is build a binary package of the existing merged package. So a user can recover from a botched upgrade. Actually a very simple safe-emerge script can be easily written. It could first do an 'emerge --buildpkg' on the existing merged package, if that package was already merged. The other part would be to create a statically linked version of tar that can be used in a recovery situation. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpvGsYgziGCW.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
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 ... then next time you break a core system package which cannot be recovered by simply running `emerge` a few times, you run `erescue broken package` Everyone who is saying that Portage can already sort of handle this seems to be missing one important point. If Python is broken then emerge won't work. The proposed erescue would still work in that case. If erescue is a statically built binary that basically untars a backed up copy of a package, why would it depend on Python? -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpxBL8wrNK4r.pgp Description: PGP signature
