[gentoo-amd64] urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[gentoo-amd64] urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Dieter Ries]

Hi,

i have a very severe and urgent problem:

We had a gaming party tonight, and this morning at about 6 AM i was downloading 30GB of data from the local network, emerging world and burning a DVD iso image with K3b. 

Then the emerge stopped with some error i dont remember, and after that, everything got somehow slow. because i didnt want the dvd to be ruined i waited till it was burned and the 30G were downloade. during my waiting i tried $top or $ps -A to see the running processes, but i got "Speicherzugriffsfehler", which is AFAIK the same as segmentation fault.

i got it for everything i tried, and when i tried something from the KDE menu, nothing happened.

then i tried another console using Ctrl-Alt-F1, but when i typed the username, the cursor went down about ten lines and that was all, i could not write anything anymore.

when the data was downloaded and the dvd burned, i tried to shutdown from KDE, no success. the i tried to shutdown from the console, no success either. in the end i had to use the reset button.

then, just after "freeing unused kernel memory" there are many errors, all looking quite the same, something like:

[hotplug]<some hexcode, each different> Segmentation Fault
<something cryptical> Error 4

init hung at that state, nothing worked.

so i got my livecd, botted from it, then i ran fsck for all the partitions, without any errors or anything, everything seemed fine.

i then mounted my system and home partition and proc and typed 
chroot /mnt/gentoo /bin/bash, which was followed by, guess it:
segmentation fault.

the data on all my partitions from sda5 to 10 is still there and i can mount them all, but i cant chroot and i cant boot.

so no gentoo anymore, and to get a working system i tried to install debian etch quickly, which didnt work because of no NF4 chipset support n the dvd.

so in the end, i am now using knoppix 4.0 to write for help.

is there any chance to get my gentoo back to life without completely install it again? and why does the system break when doing some things simultaneously?

can this be a hardware issue? i am using an athlon64 3000+ on an elitegroup NF4 board with NVidia GF 6200 TC PCIx Grafics-Adapter, 2x512MB of RAM, Single channel, and my Maxtor 7V300 with 16M of buffer.

I hope someone can help me soon, because I need my computer to work with.

cu and Thanks in advance,

Dieter

-- 


Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
      Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
    
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Duncan]

Dieter Ries <Clip2@gmx.de> posted 20060527083416.76720@gmx.net, excerpted
below, on  Sat, 27 May 2006 10:34:16 +0200:

> i have a very severe and urgent problem:
> 
> Then the emerge stopped with some error i dont remember, and after that,
> everything got somehow slow. because i didnt want the dvd to be ruined i
> waited till it was burned and the 30G were downloade. during my waiting i
> tried $top or $ps -A to see the running processes, but i got
> "Speicherzugriffsfehler", which is AFAIK the same as segmentation fault.
> 
> i got it for everything i tried, and when i tried something from the KDE
> menu, nothing happened.
 
> when the data was downloaded and the dvd burned, i tried to shutdown from
> KDE, no success. the i tried to shutdown from the console, no success
> either. in the end i had to use the reset button.
> 
> then, just after "freeing unused kernel memory" there are many errors, all
> looking quite the same[.] init hung at that state, nothing worked.
> 
> so i got my livecd, botted from it, then i ran fsck for all the
> partitions, without any errors or anything, everything seemed fine.
> 
> i then mounted my system and home partition and proc and typed chroot
> /mnt/gentoo /bin/bash, which was followed by, guess it: segmentation
> fault.
> 
> the data on all my partitions from sda5 to 10 is still there and i can
> mount them all, but i cant chroot and i cant boot.
> 
> so no gentoo anymore[,] i am now using knoppix 4.0 to write for help.
> 
> is there any chance to get my gentoo back to life without completely
> install it again? and why does the system break when doing some things
> simultaneously?
> 
> can this be a hardware issue?

OUCH!

It /could/ be a hardware issue, but as you can boot from LiveCD and the
fscks all come out fine, it wouldn't appear to be.

I think the problem is much more likely a glibc update gone bad. 
Virtually /everything/ on a system links to glibc, so when it goes bad,
you end up as they say "Up a creek without a paddle!"

I've actually had it happen once, when a portage bug was triggered by an
obscure series of events that happened to all come together in a glibc
update.  I was able to recover, however, as the problem in that case was a
bunch of missing symlinks, and I happened to have mc open at the time and
just didn't close it, but restored enough symlinks by hand based on
trying to run something and getting the error and fixing that symlink
and trying again, using mc to get enough of a working system to finish
recovery by opening up a binpkged version (thanks to FEATURES=buildpkg,
that's one of the times it saved my butt!) of glibc and restoring the
symlinks with a mass copy from there.  (I had to do the manual error,
rebuild symlink cycle several times, until I got enough of them rebuilt to
at least run bzip2 so I could untar the appropriate glibc tbz2 binpkg.)

So anyway, yeah, I know the feeling!

Assuming the problem is indeed glibc

If you have been using FEATURES=buildpkg, recovery shouldn't be too
difficult.  Simply boot the LiveCD, mount the hard drive root and /usr and
/var partitions if you have them, and untar the last correctly working
glibc package over the hard drive root.  Don't chroot to it until after
the untar, so you don't kill functionality, just untar the package to the
mounted hard drive root with any other partitions it might write to
mounted to the correct place on top of that root.

Note that you'll probably want to save copies of any of the following
files in /etc that you've modified, as the untarring will overwrite them. 
You can restore them afterward.  host.conf, init.d/nscd, nscd.conf,
nsswitch.conf, rpc.

If you haven't been using FEATURES=buildpkg, the process is a bit more
complicated, but still nothing to panic over.  You'll have to use the
quickpkg feature on the CD to build a copy of the glibc package on the CD,
then untar it over the mounted hard drive root as above (saving backups of
the /etc files as above too).

After this and recovery of the backed up /etc files, if the problem was
indeed glibc, you should again have a working system.  Since you bypassed
portage by untarring the glibc directly, however, the version of glibc
that portage thinks is installed will probably be wrong.  Thus, you'll
want to remerge a known working version using portage.  Again, that won't
be a big deal if you've been using FEATURES=buildpkg, since you can just
emerge -K the version you untarred.  If not, you'll need to recompile a
new version, which of course will take awhile.  You may wish to wait until
after tonite's gaming thing, if you won't have time to recompile it before
then.

After you have your system back up and running, consider a couple things
that might make life easier next time.

Obviously, I'm going to recommend adding buildpkg to your features if you
haven't got it there already.  It really /can/ help.  To jumpstart the
binary package store then, consider using quickpkg to package up all your
vital packages, gcc, glibc, portage, python, binutils, etc, at a minimum. 
If you want to get everything packaged right away, use emerge --pretend
--emptytree to get a list, and package all those up using quickpkg.  (You
can automate the process if you wish using tools such as cut to get the
appropriate fields out of the emerge --pretend output, then feed that
to a file for further editing if desired, and then into quickpkg as the 
list of packages it needs to package.  I did it this way when I
jumpstarted my binpkg cache.)  Alternatively, you can just add the
buildpkg feature and emerge --emptytree world, but that will of course
take awhile.

Second suggestion and something I'm again doing here, consider creating a
second copy of your root partition, with /var and /usr as well if you have
them separate.  Then, periodically, when you know you have a stable
running system, erase the copy and recopy everything over from your known
stable running system.  The idea here is that if your system goes haywire
for whatever reason, you can simply boot the backup root partition, which
will have a complete working system on it as of the time you did the
backup.  Thus, no worries about this happening again, as you can just boot
the backup system (provided you keep the snapshot fairly close to your
working system so you aren't trying to use something terribly outdated).

I actually do this with most of my system.  The root partition has /usr
and /var on it as well, so the portage database (stored in /var/db) is
current with what's on that partition, and I keep a copy of that
partition, which I refer to as my rootmirror.  Likewise, I keep a copy of
/home, a copy of my media partition, a copy of my packages (the result of
FEATURES=buildpkg) partition, etc.  I don't worry about a copy of /var/log
(which is on a separate partition than /var), or about the portage tree
(which I can simply resync if it's lost), or /tmp (since the stuff in
there by definition need not survive a reboot).  I make sure I keep the
backup copies updated to the point where if I lose everything on the
working copy, I am comfortable resuming from the backup copy, knowing that
I can redo anything changed between them in a reasonable time, should it
come to that.

If you had been doing this, then you wouldn't be sweating it now, as you'd
just have booted your backup copy and resumed from there.  Thus, consider
setting up your system that way once you are back up and running, so you
aren't left in that sort of situation ever again.  (Of course, if your
hard drive dies, that's another matter.  Here, I use a 4-disk RAID-6 to
address that problem -- I can loose any two of the four hard drives
without losing anything vital.  It's software RAID, so if the board goes,
I can buy another board, install the drives and CPUs, rebuild my kernel
for the new board using an emergency CD, and be up and running once again.
That is, however, about the only case where I'd have to use the emergency
CD, as in the other cases, I should still be able to boot to the backup
root snapshot and recover from there.)

Good luck!  I hope it /is/ just glibc, as that's scary to recover from
when the problem occurs, but not the end of the world.  If it's not glibc,
things get rather more complex, but all evidence so far says that's what
it is.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Dieter Ries]

[-- Attachment #1: Type: text/plain, Size: 7641 bytes --]


THANK YOU DUNCAN!

YOU FIXED IT.
or better, i fixed it, but i would have been lost without your help. the 
quickpkg thing did the trick.

first i was in doubt, cause quickpkg is not on the livecd fs, but then i 
started thinking, and then i untared stage and portage and made the package.

first i untar'ed the package over /etc, but the i did it on root and it 
worked.

once again THANK YOU, you saved me a LOT of work!

cu all

Dieter


>
> OUCH!
>
> It /could/ be a hardware issue, but as you can boot from LiveCD and the
> fscks all come out fine, it wouldn't appear to be.
>
> I think the problem is much more likely a glibc update gone bad.
> Virtually /everything/ on a system links to glibc, so when it goes bad,
> you end up as they say "Up a creek without a paddle!"
>
> I've actually had it happen once, when a portage bug was triggered by an
> obscure series of events that happened to all come together in a glibc
> update.  I was able to recover, however, as the problem in that case was a
> bunch of missing symlinks, and I happened to have mc open at the time and
> just didn't close it, but restored enough symlinks by hand based on
> trying to run something and getting the error and fixing that symlink
> and trying again, using mc to get enough of a working system to finish
> recovery by opening up a binpkged version (thanks to FEATURES=buildpkg,
> that's one of the times it saved my butt!) of glibc and restoring the
> symlinks with a mass copy from there.  (I had to do the manual error,
> rebuild symlink cycle several times, until I got enough of them rebuilt to
> at least run bzip2 so I could untar the appropriate glibc tbz2 binpkg.)
>
> So anyway, yeah, I know the feeling!
>
> Assuming the problem is indeed glibc
>
> If you have been using FEATURES=buildpkg, recovery shouldn't be too
> difficult.  Simply boot the LiveCD, mount the hard drive root and /usr and
> /var partitions if you have them, and untar the last correctly working
> glibc package over the hard drive root.  Don't chroot to it until after
> the untar, so you don't kill functionality, just untar the package to the
> mounted hard drive root with any other partitions it might write to
> mounted to the correct place on top of that root.
>
> Note that you'll probably want to save copies of any of the following
> files in /etc that you've modified, as the untarring will overwrite them.
> You can restore them afterward.  host.conf, init.d/nscd, nscd.conf,
> nsswitch.conf, rpc.
>
> If you haven't been using FEATURES=buildpkg, the process is a bit more
> complicated, but still nothing to panic over.  You'll have to use the
> quickpkg feature on the CD to build a copy of the glibc package on the CD,
> then untar it over the mounted hard drive root as above (saving backups of
> the /etc files as above too).
>
> After this and recovery of the backed up /etc files, if the problem was
> indeed glibc, you should again have a working system.  Since you bypassed
> portage by untarring the glibc directly, however, the version of glibc
> that portage thinks is installed will probably be wrong.  Thus, you'll
> want to remerge a known working version using portage.  Again, that won't
> be a big deal if you've been using FEATURES=buildpkg, since you can just
> emerge -K the version you untarred.  If not, you'll need to recompile a
> new version, which of course will take awhile.  You may wish to wait until
> after tonite's gaming thing, if you won't have time to recompile it before
> then.
>
> After you have your system back up and running, consider a couple things
> that might make life easier next time.
>
> Obviously, I'm going to recommend adding buildpkg to your features if you
> haven't got it there already.  It really /can/ help.  To jumpstart the
> binary package store then, consider using quickpkg to package up all your
> vital packages, gcc, glibc, portage, python, binutils, etc, at a minimum.
> If you want to get everything packaged right away, use emerge --pretend
> --emptytree to get a list, and package all those up using quickpkg.  (You
> can automate the process if you wish using tools such as cut to get the
> appropriate fields out of the emerge --pretend output, then feed that
> to a file for further editing if desired, and then into quickpkg as the
> list of packages it needs to package.  I did it this way when I
> jumpstarted my binpkg cache.)  Alternatively, you can just add the
> buildpkg feature and emerge --emptytree world, but that will of course
> take awhile.
>
> Second suggestion and something I'm again doing here, consider creating a
> second copy of your root partition, with /var and /usr as well if you have
> them separate.  Then, periodically, when you know you have a stable
> running system, erase the copy and recopy everything over from your known
> stable running system.  The idea here is that if your system goes haywire
> for whatever reason, you can simply boot the backup root partition, which
> will have a complete working system on it as of the time you did the
> backup.  Thus, no worries about this happening again, as you can just boot
> the backup system (provided you keep the snapshot fairly close to your
> working system so you aren't trying to use something terribly outdated).
>
> I actually do this with most of my system.  The root partition has /usr
> and /var on it as well, so the portage database (stored in /var/db) is
> current with what's on that partition, and I keep a copy of that
> partition, which I refer to as my rootmirror.  Likewise, I keep a copy of
> /home, a copy of my media partition, a copy of my packages (the result of
> FEATURES=buildpkg) partition, etc.  I don't worry about a copy of /var/log
> (which is on a separate partition than /var), or about the portage tree
> (which I can simply resync if it's lost), or /tmp (since the stuff in
> there by definition need not survive a reboot).  I make sure I keep the
> backup copies updated to the point where if I lose everything on the
> working copy, I am comfortable resuming from the backup copy, knowing that
> I can redo anything changed between them in a reasonable time, should it
> come to that.
>
> If you had been doing this, then you wouldn't be sweating it now, as you'd
> just have booted your backup copy and resumed from there.  Thus, consider
> setting up your system that way once you are back up and running, so you
> aren't left in that sort of situation ever again.  (Of course, if your
> hard drive dies, that's another matter.  Here, I use a 4-disk RAID-6 to
> address that problem -- I can loose any two of the four hard drives
> without losing anything vital.  It's software RAID, so if the board goes,
> I can buy another board, install the drives and CPUs, rebuild my kernel
> for the new board using an emergency CD, and be up and running once again.
> That is, however, about the only case where I'd have to use the emergency
> CD, as in the other cases, I should still be able to boot to the backup
> root snapshot and recover from there.)
>
> Good luck!  I hope it /is/ just glibc, as that's scary to recover from
> when the problem occurs, but not the end of the world.  If it's not glibc,
> things get rather more complex, but all evidence so far says that's what
> it is.
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman

-- 
Frank Castle is dead!
Call me 'The PUNISHER'!

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

[gentoo-amd64] Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Duncan]

Dieter Ries <clip2@gmx.de> posted 200605280030.06641.clip2@gmx.de,
excerpted below, on  Sun, 28 May 2006 00:30:04 +0200:

> THANK YOU DUNCAN!
> 
> YOU FIXED IT.
> or better, i fixed it, but i would have been lost without your help. the
> quickpkg thing did the trick.
> 
> first i was in doubt, cause quickpkg is not on the livecd fs, but then i
> started thinking, and then i untared stage and portage and made the
> package.
> 
> first i untar'ed the package over /etc, but the i did it on root and it
> worked.
> 
> once again THANK YOU, you saved me a LOT of work!

Very glad to be of help! =8^)

As I said, I've been there, so I know it's not a pleasant feeling!

Fortunately, I had read about the glibc thing over a year earlier, in
O'Reilly's Running Linux, which I had picked up on a recommendation when I
started getting serious about Linux.  That book paid for itself many times
over, and that was one of them!  Had it not been for that, I too would
have been posting a frantic HELP!! message to an appropriate list, in my
case, after booting from my backup root.

So now I can say I've passed on the wisdom to at least one other person in
dire need!  As I said, very glad I could help!  =8^)



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Sergio Polini]

Duncan:
> Obviously, I'm going to recommend adding buildpkg to your features
> if you haven't got it there already.  It really /can/ help. 

Sure, but when I used FEATURES=buildpkg, emerge --sync took a long 
time; i.e. after emerging I was prompted to call fixpackages and it 
took a loooong time.

> Second suggestion and something I'm again doing here, consider
> creating a second copy of your root partition, with /var and /usr
> as well if you have them separate.

Just done ;-)

Thanks
Sergio
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Duncan]

Sergio Polini <sp_rm_it@yahoo.it> posted
200605281925.51615.sp_rm_it@yahoo.it, excerpted below, on  Sun, 28 May
2006 19:25:51 +0200:

> Sure, but when I used FEATURES=buildpkg, emerge --sync took a long time;
> i.e. after emerging I was prompted to call fixpackages and it took a
> loooong time.

You gotta understand what they are saying that for and act accordingly.

What happens is that sometimes packages will move from one category to
another, or be renamed or replaced with something of a different name. 
When you sync the tree, portage gets a notice of the move and adjusts its
tracking of what you have merged (the /var/db/pkg database) to match
what's now in the tree.  In doing so, it not only adjusts the packages
that moved themselves, but the dependencies.

An example would be libgif/libungif.  A gif patent expired a year or two
ago.  While it was in force, libungif provided a patent-free workaround
for those in locations where the libgif package wasn't legal due to the
patent.  After it expired, there was no longer a need for a distinction,
as the libraries were designed to be drop-in replacements for each other,
only the one didn't include the patented functionality.  Thus, Gentoo was
able to remove libungif.  What they did was tell portage that libungif was
now libgif.

Because the libraries were drop-in replacements for each other, anything
that depended on libungif could now be changed to depend on libgif
instead.  The devs did that in-tree, but portage had to adjust its
dependency database so it didn't get out of sync with what the tree said
the dependency was supposed to be.

The catch is that binpackages include copies of the ebuild used to
create them, and said ebuild specifies dependencies.  In ordered to use
those packages with the updated tree, they too have to be updated.  This
takes awhile, as you noticed, so it's not handled automatically unless you
have FEATURES=fixpackages set.

The key thing to realize, however, is that as long as you aren't actually
trying to merge those binpkgs, they are fine as they are.  There's no
reason you have to run fixpackages every time something changes in portage
that asks you to, unless you are going to actually be using those binpkgs.

Further, in the event of a crash and a need to actually use those binpkgs,
you could use the manual untar method regardless of what the attached
ebuild said, because it bypasses that.  If you were actually using portage
to do remerge the binpkg, you could run fixpackages at that point, before
you actually remerged anything.  If you forgot to do so, it would simply
give you an error, which would probably get you thinking "Hey, I gotta run
fixpackages before this will work, as I had not yet done so."

As for the fixpackages process itself, you are absolutely correct,
currently stable portage (2.0.5x) takes a VERY VERY long time, because it
goes over EVERY SINGLE CHANGE EVER MADE EVERY SINGLE TIME YOU RUN THE
THING, even ones that were made the LAST time you ran fixpackages and thus
don't need to be made again, even ones made before you were even running
Gentoo, so there's no way they could ever apply to you! As such, with
stable portage, it's actually best NOT to run fixpackages until you have
to, because it redoes everything it did the last time anyway.

Fortunately, fixpackages is much smarter with the current ~arch portage
(2.1 release candidates ATM).  With 2.1, it timestamps the last time it ran
fixpackages, and skips everything before that, so it only processes what
has changed since the last time it ran.  Basically, that means that if you
run it every time it tells you to, it will only have the changes that
happened to come in with that portage sync to worry about, and it is MUCH
MUCH MUCH MUCH FASTER!!!  Usually, it only has a couple things to change,
instead of going thru the probably hundreds of changes that have happened
since the first move portage ever had.  As a result, it's actually
practical to add FEATURES=fixpackages now, and let portage manage it
automatically, as it's fast enough the sync normally takes longer than the
fixpackages does.  You can still do manually, and skip doing it until you
need to remerge one of those packages, if desired, but there's really no
need to do so.  Letting portage handle it automatically now actually makes
sense.

FWIW, 2.1 is targeted at stabilization for use with Gentoo 2006.1, which
is targeted for July.  This is only one of a number of HUGE improvements
in 2.1, and you guys still running 2.0.5x have a lot to look forward to
when 2.1 goes stable!  =8^)  Don't forget to reread the emerge manpage,
the make.conf manpage, and make.conf.example when it happens, as portage
will keep doing things the slow old way in a number of cases, if you don't
properly configure it to take advantage of the new features.  In
particular, pay attention to FEATURES=confcache (especially anyone using
KDE!) and FEATURES=-metadata-transfer (that one's on by default, so you
use - to turn it off, it's now faster to regenerate the metadata than it
is to transfer it, for many people).  FEATURES=parallel-fetch can also be
useful, and FEATURES=user-fetch is something anyone who has ever wondered
about the security implications of exposing root to the wilds of the net
during the fetch phase should definitely appreciate!  There's also a new
tool in the matching gentoolkit, also in -rc now.  It's called eclean and
it can be used to help clean out the staleness in both $DISTDIR (the
portage tarball cache location) and $PKGDIR.  There are also a couple
changes to the way emerge works.  The old way still works for 2.1 but will
be removed later, and portage now warns you if you use the old way. 
emerge actions (sync, metadata, fetch, etc) now want -- in front of them,
as emerge --sync, and a couple make.conf variables have changed their
name.  Again, the old way will still work for now, it just generates a
warning, so no worries, but there will be some things that you'll need to
change eventually, probably before 2.2.

That make things a bit clearer, now, and buildpkg a bit more tolerable? 
It should, as it certainly helps make buildpkg tolerable here!  =8^)



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Peter Humphrey]

On Saturday 27 May 2006 14:38, Duncan wrote:

> Second suggestion and something I'm again doing here, consider creating a
> second copy of your root partition

What tool or command do you use to make your copies? I remember seeing an 
invocation of tar piped to tar to ensure that all dates, permissions etc 
are preserved, even on pipes and other esoteric things, but my memory being 
what it is of course I can't remember it.

You may remember that I've been using Partition Magic for this task (version 
8 can boot from its installation CD), but I keep discovering more ways in 
which its Windows nature and consequent arrogance make it more difficult 
than it should be. For instance, I discovered last night on my laptop that, 
when I copied my root partition to an empty space on the same disk, it 
changed all my grub.conf entries to point to the copy. Then, when I 
upgraded to modular X, deleted the copy and copied over the new root 
partition, guess what? Not knowing of the subterfuge, I destroyed all that 
work (finding 101 lines to add to package.keywords the most tiring) and had 
to go for a pint to calm my temper. (Still, it's an ill wind that blows 
no-one any good.)

I've known for a while that PM changes /etc/fstab, and always gets it wrong 
so that I can't boot until I've corrected it, but this is the first time 
it's caused real data loss and anger.

-- 
Rgds
Peter.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Anthony E. Caudel]

Peter Humphrey wrote:
> 
> What tool or command do you use to make your copies? I remember seeing an 
> invocation of tar piped to tar to ensure that all dates, permissions etc 
> are preserved, even on pipes and other esoteric things, but my memory being 
> what it is of course I can't remember it.
> 

Maybe: cd /sourcedir; tar -cpf - . | (cd /destdir; tar -xvf -)

Tony
-- 
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[John Myers]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

On Monday 29 May 2006 09:11, Anthony E. Caudel wrote:
> Peter Humphrey wrote:
> > What tool or command do you use to make your copies? I remember seeing an
> > invocation of tar piped to tar to ensure that all dates, permissions etc
> > are preserved, even on pipes and other esoteric things, but my memory
> > being what it is of course I can't remember it.
>
> Maybe: cd /sourcedir; tar -cpf - . | (cd /destdir; tar -xvf -)
>
perhaps
	cp -a
would be simpler?
-- 
# 
# electronerd, the electronerdian from electronerdia
#

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Anthony E. Caudel]

John Myers wrote:
> On Monday 29 May 2006 09:11, Anthony E. Caudel wrote:
> 
>>Peter Humphrey wrote:
>>
>>>What tool or command do you use to make your copies? I remember seeing an
>>>invocation of tar piped to tar to ensure that all dates, permissions etc
>>>are preserved, even on pipes and other esoteric things, but my memory
>>>being what it is of course I can't remember it.
>>
>>Maybe: cd /sourcedir; tar -cpf - . | (cd /destdir; tar -xvf -)
>>
> 
> perhaps
> 	cp -a
> would be simpler?

My experience is that cp -a is much slower than tar.

Tony

-- 
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Bernhard Auzinger]

> What tool or command do you use to make your copies? I remember seeing an
> invocation of tar piped to tar to ensure that all dates, permissions etc
> are preserved, even on pipes and other esoteric things, but my memory being
> what it is of course I can't remember it.

I'm using flexbackup. flexbackup is a script written in perl which uses tar. 
It has always preserved the right permissions for my backups and it's very 
comfortable to use.

rgds

Berhard
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Duncan]

Peter Humphrey <prh@gotadsl.co.uk> posted
200605290931.52350.prh@gotadsl.co.uk, excerpted below, on  Mon, 29 May
2006 09:31:52 +0100:

> On Saturday 27 May 2006 14:38, Duncan wrote:
> 
>> Second suggestion and something I'm again doing here, consider creating
>> a second copy of your root partition
> 
> What tool or command do you use to make your copies? I remember seeing an
> invocation of tar piped to tar to ensure that all dates, permissions etc
> are preserved, even on pipes and other esoteric things, but my memory
> being what it is of course I can't remember it.

I use mc (midnight commander) quite heavily, both at the console and in
X, both for file management and editing.  My EDITOR variable is set to
mcedit, I have a seriously customized system-wide "user" menu (mc key F2),
I have konqueror and kwrite set to use many of the same keyboard
shortcuts (like F2 for save in mcedit/kwrite, F8/delete, F5/copy, F6/move
in mc/konqueror, etc) 

mc defaults to retaining ownership and permissions, and just does "the
right thing" by default on all that exotic stuff (pipes, sockets,
symlinks, device files, etc).

I use partitions/volumes quite heavily here, and the one issue I did run
into originally was efficiently doing a copy of my root partition (only)
to rootbak.  There are various ways to do it including booting to single
user mode and unmounting everything but the root file system.  However,
it's far simpler, I found, to simply setup an entry in fstab for a mount
--bind rootfs, thus getting a view of the filesystem without all the
submounts, and with the /dev dir on disk available to be copied as well,
instead of the udev overmount I'd normally get copying that dir.  Here's
the entry I use:

#Dev/Part MntPnt    Type MntOpt      D F
# for mount --bind, --rbind, and --move
#/old/dir /new/dir  none bind        0 0
/.        /rootbind none bind,noauto 0 0

Note that due to the way the Gentoo initscripts work, you can't simply use
/ as the /old/dir entry as that will mess up checkroot.  I had a time
figuring out what /would/ work, until I remembered that a single dot points
to "me", the same as .. points to the parent dir, so be sure to use /. as
the old dir entry, not simply /.  It'll save you some trouble!  Of course,
you can change the /rootbind to /mnt/rootbind or some such if you prefer. 
Don't forget to create the dir so the system has someplace to do the
mount!  As you can see, I use the "noauto" option in addition to "bind",
so it's not mounted unless I tell it to mount.  The fstab entry does save
having to look up the correct mount --bind command line syntax, however,
and a simple "mount /r<tab>" to get autocompletion based on the fstab
entry is far easier than typing the whole long command in, if I didn't
have an fstab entry for it, as well.

Of course, one /could/ use dd or similar to do a direct bit-for-bit image
copy of the filesystem image itself.  As that would be sequential and have
less overhead, it would be rather faster.  Doing the mount --bind dance
above wouldn't be necessary, either.  However, the file-by-file copy is
conceptually easier since it's something we all do every day, and it also
has the effect of cleaning up filesystem fragmentation and other such
cruft.  Thus, I normally do a mkfs to wipe the old backup clean, then
mount /rootbind and /bak, load mc with a view on each, select everything
in /rootbind, and hit F5 to initiate the copy.  Again, mc manages all
the permissions stuff so it just works, so I don't have to worry about
that at all.

> You may remember that I've been using Partition Magic for this task
> (version 8 can boot from its installation CD), but I keep discovering
> more ways in which its Windows nature and consequent arrogance make it
> more difficult than it should be. For instance, I discovered last night
> on my laptop that, when I copied my root partition to an empty space on
> the same disk, it changed all my grub.conf entries to point to the copy.
> Then, when I upgraded to modular X, deleted the copy and copied over the
> new root partition, guess what? Not knowing of the subterfuge, I
> destroyed all that work (finding 101 lines to add to package.keywords
> the most tiring) and had to go for a pint to calm my temper. (Still,
> it's an ill wind that blows no-one any good.)
> 
> I've known for a while that PM changes /etc/fstab, and always gets it
> wrong so that I can't boot until I've corrected it, but this is the
> first time it's caused real data loss and anger.

I used to swear by Partition Magic.  I had actually tried Quarterdeck's
Partition It at one time instead of upgrading PM, and had problems.  When
I gave up and switched back to PM, I found out why -- PI had screwed up
the partition entries and had incorrect data for some stuff!  I Considered
myself lucky not to have lost anything, and /only/ used PM from then on --
until I made the jump to Linux-only, anyway.

At that point, I wrote them, asking when they were going to support stuff
like reiserfs and ext3.  They said they'd support whichever one became the
official upgrade from ext2 (which they did support at the time and which I
had used while I was playing around with Linux a bit).  Well, I knew both
were supported in the 2.4 kernel, along with JFS, XFS, etc, and decided PM
wasn't so hot when it came to Linux stuff as it was on MSWormOS. 

I asked about support for a Linux executable as well.  They said none was
planned but that the DOS based floppy version would work (that was before
bootable CDs became common place).  Well, yes, but that wasn't the same
thing.

So... I decided to try out the Linux alternatives.  I'm glad I did.

Mandrake (which I was using at the time) had a (GPL licensed) GTK based
partitioning client with an interface that any PM user would have been
comfortable with.  It was called DiskDrake.  I still don't know why it
hasn't become far more popular, because it was (and I assume still is,
tho the name will have changed) as simple as PM to use, and lowers the
barrier to entry for MSWormOS types /dramatically/.  I assume the thing is
still available on the first Mandriva install CD, tho I have no idea what
it would be called, now.

When I switched to Gentoo, I settled on cfdisk, which I had experimented
with on Mandrake, but never used extensively.  It's curses based, and
should seem familiar to those who have used the PM text based interface
that they at least used to have on that floppy I mentioned.  Anyone who
has used MS' FDISK utility should find it familiar as well.  It's quite
usable and I've had zero problems with it, but it's not the fancy
graphical interface of PM or Mandrake's DiskDrake.

Now, of course, I wouldn't use PM in any case, as it's slaveryware.  As
well, for Linux, it was more limited than diskdrake was, even back with
Mandrake 8.x, altho diskdrake was of course more limited with NTFS
partitions and the like.  From what you've said, it seems like it still
has some limitations on the Linux side, tho I'd hope by now it at least
supports the basic Linux filesystem types, including
reiserfs/ext3/jfs/xfs.  It'd be a shame if it didn't.  By now, I'd be
asking when they were adding reiser4 support, if it wasn't yet included. 
I've not used it yet, but I'm expecting I eventually will, and would
expect an app like PM that I actually had to pay money for to have support
for it by the time it became part of the mainstream kernel, in any case.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Duncan]

"Duncan" <1i5t5.duncan@cox.net> posted e5fl6m$k5s$1@sea.gmane.org,
excerpted below, on  Mon, 29 May 2006 20:22:47 +0000:

> so be sure to use /. as the old dir entry, not simply /.

LOL!  Talk about a bad place for a period!  I didn't even realize I'd done
that until I just read it.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Peter Humphrey]

On Monday 29 May 2006 17:20, John Myers wrote:

> perhaps
> 	cp -a
> would be simpler?

I can't understand the manual entry for cp -a. It says 

-a, --archive
              Preserve as much as possible of the structure and attributes 
of the original files  in the copy (but do not preserve directory 
structure).

Where does it put the files if it doesn't preserve the directory structure? 
What happens to the directory structure?

-- 
Rgds
Peter.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Peter Humphrey]

On Monday 29 May 2006 17:11, Anthony E. Caudel wrote:

> Maybe: cd /sourcedir; tar -cpf - . | (cd /destdir; tar -xvf -)

That looks good - thanks!

-- 
Rgds
Peter.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Peter Humphrey]

On Monday 29 May 2006 17:11, Anthony E. Caudel wrote:

> Maybe: cd /sourcedir; tar -cpf - . | (cd /destdir; tar -xvf -)

...but shouldn't there be a p in the destination untar?

-- 
Rgds
Peter.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Peter Humphrey]

On Monday 29 May 2006 21:22, Duncan wrote:

> #Dev/Part MntPnt    Type MntOpt      D F
> # for mount --bind, --rbind, and --move
> #/old/dir /new/dir  none bind        0 0
> /.        /rootbind none bind,noauto 0 0

[etc...]

Looks interesting. Thanks.

> Now, of course, I wouldn't use PM in any case, as it's slaveryware. 

No, I thought not.

> From what you've said, it seems like it still has some limitations on the
> Linux side, tho I'd hope by now it at least supports the basic Linux
> filesystem types, including reiserfs/ext3/jfs/xfs.

No sign of Reiser yet, as far as I can see, but ext3 is there so I've been 
using that for my Linux partitions. But for me, by far the worst part of PM 
is not a limitation but a swaggering arrogance - that its programmers know 
my system and my needs better than I do, so that I have no option but to 
yield. That makes the program simply unusable, and I intend to tell them 
so.

-- 
Rgds
Peter.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 136 bytes --]

Tuesday 30 May 2006 10:26 skrev Peter Humphrey:
> ...but shouldn't there be a p in the destination untar?

Yes.

-- 
Bo Andresen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Duncan]

Peter Humphrey <prh@gotadsl.co.uk> posted
200605300953.21346.prh@gotadsl.co.uk, excerpted below, on  Tue, 30 May
2006 09:53:21 +0100:

> No sign of Reiser yet, as far as I can see, but ext3 is there so I've been 
> using that for my Linux partitions. But for me, by far the worst part of PM 
> is not a limitation but a swaggering arrogance - that its programmers know 
> my system and my needs better than I do, so that I have no option but to 
> yield. That makes the program simply unusable, and I intend to tell them 
> so.

Well, it's possible that's due to them being bought out by Symantec
(according to a recent /. comment I was reading, with several replies
agreeing). I don't know when it happened, but it couldn't have been too
long ago as the comment I read mentioning it said they'd probably destroy
it, like they did all the other stuff they've bought over the years, which
implies they haven't had it long enough for it to occur yet.

In any case, that's one of the reasons I don't do closed source any more
-- Libreware devs just seem so much more willing to listen to the
user -- and if they don't, someone will likely fork it and do the
listening the original author wouldn't.  It's like thinking back on a bad
dream, or like an abuse victim looking back at what happened, and
shuddering at how bad it was and how it seemed there wasn't a way out, and
resolving "never again will I allow myself to be subjected to that!"  Yes,
it's an almost physical revulsion, and yes, it is to that extent.  To
subject myself to that type of environment once again is unthinkable.

...  And people wonder at why I call it slaveryware.  One of the Gentoo
devs actually took issue with that, saying I had no right to call it that,
as it was making light of slavery.  In the ensuing rather heated
discussion, I eventually explained that I DID feel it was a freedom issue,
and that while I couldn't say for sure that I'd be willing to die rather
than submit again to slavery, I felt that the issue was significant enough
that I /should/ feel that way.  After he realized how strongly I felt
about it, that it was NOT making light of slavery, but rather,
deliberately chosen terminology to show exactly how strong my feeling was
on the subject, and that if I wouldn't quite die for it, I thought I
/should/ be willing to die for it, he did allow that while he could never
feel that way about it and he still didn't agree with the term, he could
at least now see why I insisted on using the term, and that for me at
least, it /was/ that serious an issue -- tho he obviously thought I was
rather misguided in giving it that sort of importance.

Too bad they aren't doing reiserfs yet, tho PM being commercial closed
source and the file system code being GPL and Namesys a commercial entity
as well, I expect Namesys may have required a license to code for it, so I
can see how they may not be willing to support it given the demand. 
Still, if they don't yet support it, I'm glad I switched when I did, as
reiserfs is all I use on the hard drive.  (I have it built-into the
kernel, with ext2 and fat as modules, to be loaded for use with floppies
and the like -- only.)  They probably don't support Linux kernel RAID
volumes or LVM on kernel-raid, either, which means they'd be scoring a big
fat ZERO in terms of supporting what I'm now running.  I guess that means
I've entirely outgrown them -- like a kid outgrowing his GI JOE figures. 
<shrug>  Just as well for me anyway, since regardless, I couldn't and
wouldn't go back, for the reasons explained above, but too bad others
can't be using it for that.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

Tuesday 30 May 2006 11:34 skrev Duncan:
> Well, it's possible that's due to them being bought out by Symantec
> (according to a recent /. comment I was reading, with several replies
> agreeing). I don't know when it happened, but it couldn't have been too
> long ago as the comment I read mentioning it said they'd probably destroy
> it, like they did all the other stuff they've bought over the years, which
> implies they haven't had it long enough for it to occur yet.

Symantec took over PowerQuest in September 2003 [1] so it is a while ago. The
latest release is of May 2004 [2] (an information I wasn't able to locate
anywhere on the Symantec home page..). I wasn't able to locate what changed in
8.05 either but 8.0 is from before Symantec took over PowerQuest. So I'd say
it has occured already since I don't see any signs of progress on this
software.

It does support all file systems that may be used on Windows, so I'm guessing
from a Windows users perspective it is feature complete and Symantec will be
able to make money of it for many years in the future without spending any
money on it themselves...

On my system support for reiserfs wouldn't amount to much since it does, as
you suggested, not support LVM2. But with a properly setup system using lvm2
and reiserfs who needs Partition Magic anyway? Isn't that what LVM2 is for?

[1] http://news.com.com/Symantec+buys+storage+software+maker/2100-7350_3-5081273.html
[2] http://en.wikipedia.org/wiki/Partition_Magic

-- 
Bo Andresen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Hamish Marson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony E. Caudel wrote:
> Peter Humphrey wrote:
>>
>> What tool or command do you use to make your copies? I remember
>> seeing an invocation of tar piped to tar to ensure that all
>> dates, permissions etc are preserved, even on pipes and other
>> esoteric things, but my memory being what it is of course I can't
>> remember it.
>>
>
> Maybe: cd /sourcedir; tar -cpf - . | (cd /destdir; tar -xvf -)
>

Just be careful with this one. If the destination directory doesn't
exist, then you'll overwrite the sourcefiles with the first block...
Ooops... (Having said that, it's still my favourite way of copying
lots of files from one place to another).

H


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEfH+D/3QXwQQkZYwRAjZmAKCVqxsFYgG0EKhP+G3PNNxuuJsaqQCdGcbo
sLp76j0jK7U/A29RUjUoFUY=
=YCPh
-----END PGP SIGNATURE-----

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

Tuesday 30 May 2006 19:23 skrev Hamish Marson:
> Just be careful with this one. If the destination directory doesn't
> exist, then you'll overwrite the sourcefiles with the first block...
> Ooops... (Having said that, it's still my favourite way of copying
> lots of files from one place to another).

That's why it should be like this:

# cd /sourcedir && tar -cpf - . | (cd /destdir && tar -xvpf -)

Then it will fail and abort if any of the cd operations fails. Also the 
destdir should be given either as an absolute path or relative to the 
sourcedir (not relative to whatever your path is when you issue the command 
above.

With GNU tar one can simply do this:

# tar -C /sourcedir -cpf - . | tar -C /destdir -xvpf - 

-- 
Bo Andresen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Sergio Polini]

Duncan:
> That make things a bit clearer, now, and buildpkg a bit more
> tolerable? It should, as it certainly helps make buildpkg tolerable
> here!  =8^)

Sorry, I've been busy for a few days and I've read your message just 
today.
I see that there are several posts about the same subject. I'm going 
to read them, but I wish to thank you for your clear explication.

Sergio
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] AGAIN URGENT: Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Dieter Ries]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

Hi all,

my problem has not ended. aufter being happy that my system worked again, i 
now wanted to emerge -e system and world, but fater installing/uninstalling 
one package and Cleaning up, there are errors while scanning /etc, and then 
there are the segfaults again.

i now have done your workaround with the quickpkg of glibc 5 times i think. i 
have now made an glibc quickpackage of the recent version, so this should not 
be a problem anymore. i tried emerge -e glibc, but then it starts with some 
other packages and doesnt wor either.

i am going to try again, but i dont think it will work. any ideas how to fix 
that?

cu
Dieter

Am Freitag 02 Juni 2006 14:11 schrieb Sergio Polini:
> Duncan:
> > That make things a bit clearer, now, and buildpkg a bit more
> > tolerable? It should, as it certainly helps make buildpkg tolerable
> > here!  =8^)
>
> Sorry, I've been busy for a few days and I've read your message just
> today.
> I see that there are several posts about the same subject. I'm going
> to read them, but I wish to thank you for your clear explication.
>
> Sergio

-- 
Frank Castle is dead!
Call me 'The PUNISHER'!

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-amd64] AGAIN URGENT: Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Dieter Ries]

and here is the output of emerge -e system:

localhost / # emerge -ev system
Calculating system dependencies ...done!
>>> emerge (1 of 116) sys-devel/patch-2.5.9 to /
>>> md5 files   ;-) patch-2.5.9.ebuild
>>> md5 files   ;-) patch-2.5.9-r1.ebuild
>>> md5 files   ;-) files/digest-patch-2.5.9
>>> md5 files   ;-) files/patch-2.5.9-cr-stripping.patch
>>> md5 files   ;-) files/digest-patch-2.5.9-r1
>>> md5 src_uri ;-) patch-2.5.9.tar.gz
>>> Unpacking source...
>>> Unpacking patch-2.5.9.tar.gz to /var/tmp/portage/patch-2.5.9/work
>>> Source unpacked.
./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man 
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc 
--localstatedir=/var/lib --libdir=/usr/lib64 --build=x86_64-pc-linux-gnu
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking for a BSD-compatible install... /bin/install -c
checking whether make sets $(MAKE)... yes
checking for ed... /bin/ed
checking for egrep... grep -E
checking for AIX... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking for library containing strerror... none required
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for _LARGE_FILES value needed for large files... no
checking for function prototypes... yes
checking for an ANSI C-conforming const... yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking varargs.h usability... no
checking varargs.h presence... no
checking for varargs.h... no
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for utime.h... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking for struct utimbuf... yes
checking whether closedir returns void... no
checking for limits.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking whether getenv is declared... yes
checking whether malloc is declared... yes
checking whether system is Windows or MSDOS... no
checking for unistd.h... (cached) yes
checking for d_ino member in directory struct... yes
checking for long file names... (cached) yes
checking for pathconf... yes
checking for vprintf... yes
checking for _doprnt... no
checking for error_at_line... yes
checking for strerror... yes
checking whether strerror is declared... yes
checking whether strerror_r is declared... yes
checking for strerror_r... yes
checking whether strerror_r returns char *... yes
checking for memchr... yes
checking whether stat file-mode macros are broken... no
checking for rmdir... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking for iswprint... yes
checking for mbsinit... yes
checking for mbstate_t... yes
checking whether mbrtowc and mbstate_t are properly declared... yes
checking for pathconf... (cached) yes
checking for limits.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking whether free is declared... yes
checking whether getenv is declared... (cached) yes
checking whether malloc is declared... (cached) yes
checking whether mktemp is declared... yes
checking for _doprintf... no
checking for geteuid... yes
checking for getuid... yes
checking for isascii... yes
checking for memcmp... yes
checking for mktemp... yes
checking for pathconf... (cached) yes
checking for raise... yes
checking for sigaction... yes
checking for sigprocmask... yes
checking for sigsetmask... yes
checking for strerror... (cached) yes
checking for mkdir... yes
checking for strncasecmp... yes
checking for _LARGEFILE_SOURCE value needed for large files... no
checking for fseeko... yes
checking whether clearerr_unlocked is declared... yes
checking whether feof_unlocked is declared... yes
checking whether ferror_unlocked is declared... yes
checking whether fflush_unlocked is declared... yes
checking whether fgets_unlocked is declared... yes
checking whether fputc_unlocked is declared... yes
checking whether fputs_unlocked is declared... yes
checking whether fread_unlocked is declared... yes
checking whether fwrite_unlocked is declared... yes
checking whether getc_unlocked is declared... yes
checking whether getchar_unlocked is declared... yes
checking whether putc_unlocked is declared... yes
checking whether putchar_unlocked is declared... yes
checking whether closedir returns void... (cached) no
checking for fcntl.h... (cached) yes
checking for unistd.h... (cached) yes
checking for DOS-style setmode... no
checking for vprintf... (cached) yes
checking for _doprnt... (cached) no
checking for mkdir... (cached) yes
checking whether mkdir takes only one argument... no
checking whether system is Windows or MSDOS... (cached) no
checking for long file names... (cached) yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 addext.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 argmatch.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 backupfile.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 basename.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 dirname.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 getopt.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 getopt1.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 inp.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 maketime.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 partime.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 patch.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 pch.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 quote.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 quotearg.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 quotesys.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 util.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 version.c
x86_64-pc-linux-gnu-gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. 
-O2 -march=k8 -pipe -DLINUX -D_XOPEN_SOURCE=500 xmalloc.c
x86_64-pc-linux-gnu-gcc -o patch -O2 -march=k8 -pipe -DLINUX 
-D_XOPEN_SOURCE=500   addext.o argmatch.o backupfile.o basename.o dirname.o 
getopt.o getopt1.o inp.o maketime.o partime.o patch.o pch.o quote.o 
quotearg.o quotesys.o util.o version.o xmalloc.o
patch.o: In function `make_temp':
patch.c:(.text+0xa26): warning: the use of `mktemp' is dangerous, better use 
`mkstemp'
>>> Test phase [not enabled]: sys-devel/patch-2.5.9

>>> Install patch-2.5.9 into /var/tmp/portage/patch-2.5.9/image/ category 
sys-devel
/bin/sh ./mkinstalldirs /var/tmp/portage/patch-2.5.9/image//usr/bin /var/tmp/portage/patch-2.5.9/image//usr/share/man/man1
mkdir -p 
-- /var/tmp/portage/patch-2.5.9/image//usr/bin /var/tmp/portage/patch-2.5.9/image//usr/share/man/man1
/bin/install -c patch /var/tmp/portage/patch-2.5.9/image//usr/bin/`echo patch 
| sed 's,x,x,'`
/bin/install -c -m 
644 ./patch.man /var/tmp/portage/patch-2.5.9/image//usr/share/man/man1/`echo 
patch | sed 's,x,x,'`.1
man:
gzipping man page: patch.1
strip: x86_64-pc-linux-gnu-strip --strip-unneeded
   /usr/bin/patch
>>> Completed installing patch-2.5.9 into /var/tmp/portage/patch-2.5.9/image/

>>> Merging sys-devel/patch-2.5.9 to /
--- /usr/
--- /usr/bin/
>>> /usr/bin/patch
--- /usr/share/
--- /usr/share/man/
--- /usr/share/man/man1/
>>> /usr/share/man/man1/patch.1.gz
--- /usr/share/doc/
--- /usr/share/doc/patch-2.5.9/
>>> /usr/share/doc/patch-2.5.9/AUTHORS.gz
>>> /usr/share/doc/patch-2.5.9/NEWS.gz
>>> /usr/share/doc/patch-2.5.9/ChangeLog.gz
>>> /usr/share/doc/patch-2.5.9/README.gz
>>> Safely unmerging already-installed instance...
--- !mtime obj /usr/share/man/man1/patch.1.gz
--- !mtime obj /usr/share/doc/patch-2.5.9/README.gz
--- !mtime obj /usr/share/doc/patch-2.5.9/NEWS.gz
--- !mtime obj /usr/share/doc/patch-2.5.9/ChangeLog.gz
--- !mtime obj /usr/share/doc/patch-2.5.9/AUTHORS.gz
--- !mtime obj /usr/bin/patch
--- !empty dir /usr/share/man/man1
--- !empty dir /usr/share/man
--- !empty dir /usr/share/doc/patch-2.5.9
--- !empty dir /usr/share/doc
--- !empty dir /usr/share
--- !empty dir /usr/bin
--- !empty dir /usr
>>> original instance of package unmerged safely.
>>> Regenerating /etc/ld.so.cache...
>>> sys-devel/patch-2.5.9 merged.
localhost / # emerge -ev system
Speicherzugriffsfehler
localhost / #   


Am Samstag 03 Juni 2006 14:02 schrieb Dieter Ries:
> Hi all,
>
> my problem has not ended. aufter being happy that my system worked again, i
> now wanted to emerge -e system and world, but fater installing/uninstalling
> one package and Cleaning up, there are errors while scanning /etc, and then
> there are the segfaults again.
>
> i now have done your workaround with the quickpkg of glibc 5 times i think.
> i have now made an glibc quickpackage of the recent version, so this should
> not be a problem anymore. i tried emerge -e glibc, but then it starts with
> some other packages and doesnt wor either.
>
> i am going to try again, but i dont think it will work. any ideas how to
> fix that?
>
> cu
> Dieter
>
> Am Freitag 02 Juni 2006 14:11 schrieb Sergio Polini:
> > Duncan:
> > > That make things a bit clearer, now, and buildpkg a bit more
> > > tolerable? It should, as it certainly helps make buildpkg tolerable
> > > here!  =8^)
> >
> > Sorry, I've been busy for a few days and I've read your message just
> > today.
> > I see that there are several posts about the same subject. I'm going
> > to read them, but I wish to thank you for your clear explication.
> >
> > Sergio

-- 
Frank Castle is dead!
Call me 'The PUNISHER'!
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: AGAIN URGENT: Re: Re: urgent: Segfaults after synchronously emerging|downloading 30GB|burnng a DVD iso image

[Duncan]

Dieter Ries <clip2@gmx.de> posted 200606031405.30495.clip2@gmx.de,
excerpted below, on  Sat, 03 Jun 2006 14:05:30 +0200:

> and here is the output of emerge -e system:
> 
> localhost / # emerge -ev system
> Calculating system dependencies ...done!
>>>> emerge (1 of 116) sys-devel/patch-2.5.9 to /
[snip]
>>>> sys-devel/patch-2.5.9 merged.
> localhost / # emerge -ev system
> Speicherzugriffsfehler
> localhost / #   

So it emerges the first of 116 packages and returns to the prompt, no
error or anything, then trying it again results in (courtesy babelfish)
"memory access error"?

Ouch!

That single package merged, patch, yet replacing glibc fixes the problem? 
It makes no sense!  If the problem is glibc, it shouldn't occur until you
reach glibc in the emerge --emptytree cycle.  Patch is simple and wouldn't
be invoked by a second emerge attempt, that early in the attempt, so it
can't be patch that's the problem.  It has to be either portage (or
python or bash, portage dependencies), or glibc, or your hardware (still).

What happens if you "emerge -pe > pkg.list", to get a list of packages,
and then emerge each one in order by itself (use --oneshot so you don't
clog up your world file), going down the list one at a time?

What about doing the quickpkg-off-the-CD thing with the packages listed
above? Maybe your earlier issues caused one of them to emerge defective,
and it's causing portage to do strange things.  If so, once you replace
the right one, you'll be back in business.  I'd try python and portage
first. as bash appears to be reasonably stable or your shell would be
crashing and you'd be having to relogin all the time.

It's also possible that your portage installed-package database is screwed
up.  Actually, this seems the most likely to me as it would explain a bit
of the symptoms, being able to emerge a single package using --emptytree,
which tries to write the new package info to the db, which then crashes
emerge so it goes no further, and further attempts to emerge just crash. 
(There are still unanswered questions, but let's ignore them for the
moment.)

What's your disk layout?  Do you have /var on a separate partition or is
it on your main / partition?  What filesystem are you using on it, ext3,
reiserfs, something else?

First, try copying /var/db/pkg to a different location for backup.  Then
delete it if possible.  Unmount that partition if possible and do an fsck
on it (maybe from a LiveCD if it's your root partition).  Now boot or
remount your system and NOW try an emerge -e system (-e = --emptytree).
Does it work any better?

You also mention errors scanning /etc, presumably using etc-update or
similar.  It may be that it needs fscked as well.

If those don't work, it may be a lot of work, but it may be simpler to
to think about starting from scratch again, with a new stage-3 install.
Something's screwed up, and it's defying major attempts at finding and
fixing it. I'm also beginning to wonder about the stability of your
hardware.  Someone recently posted with bad memory problems, and I've had
both that and dying hard drives* in the last couple years, so I'm all too
familiar with hardware issues.

Good luck!  I'm glad it's not me dealing with it, but you certainly have
my sympathies!  I've had close enough experiences in the past to know what
it's like, and it's not fun!

(BTW, quoting the context you are replying to, snipped from the entire
message just to what you are replying to, then replying underneath, so a
reader knows exactly what you are replying to, tends to work better for
mailing lists and newsgroups than reply on top, unsnipped quote
underneath.  I know you have a lot to worry about right now, just sayin'.)

* The hard drive thing was a case of a bad AC last summer causing drive
overheating -- not surprising when summer temps here in Phoenix are known
to routinely pass 46C (115F) and un-air-conditioned inside or sun baked
temps can easily reach 60C (150F).  The CPUs and rest of the hardware were
fine, and the drive wasn't entirely dead either, but apparently had
head-crash rings from the heat-expanded spinning platters contacting the
head.  I'm now running RAID-6 with Seagate drives with a 5 year warrantee,
and have a new AC, so hopefully no more of that this year!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list