[gentoo-user] General weirdness - a tale of woe.

[gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

Hello list,

Over the last few weeks I've been having odd things go bump in the night. This 
is a KDE amd64 system with /usr under / and no initrd.

The first thing was that my screen saver was being overlaid with a plain 
default desktop. That was fixed by creating a new user for myself and setting 
it up from scratch. Tedium galore, especially importing into KMail. Then I 
found KMail creating duplicates of existing e-mails. It would make a few when 
I started the program, then some more when I told it to fetch mail, and even 
more when I clicked into the folder containing the copies.

Several other little oddities were happening too, and I began to suspect my 
six-year-old disks. Well, I wanted to put some shiny new SSDs in anyway, so I 
used this as the excuse. That seemed to fix everything and I ran for a week or 
two in welcome peace.

Then this morning when I came back to the machine (it runs 24x7x52 running 
BOINC projects) the screen saver overlay was back. Then I noticed that the 
three Konsole windows I keep on one desktop had been resized one pixel 
smaller, so that the last line didn't fit. I'm particular about that (OCPD?) 
and would never have left it that way.

When I came to KMail I found that it wouldn't loop outside the current folder. 
I have it set to loop through all of them, so I changed it, restarted KMail, 
changed it back to loop through all folders and restarted KMail. It still 
wouldn't go outside the current folder. I also notice it's ignoring my one 
auto-correction setting - to capitalise the initial letter of a sentence.

So I ran an emerge -eK world and restarted. No change. Clearly something is 
changing in my home directory tree, but what? I can't keep on creating new 
user accounts.

The last thing is that at reboot the RAID-1 volume manager often fails to 
start. It says afterwards that it's running, but all the /dev/vg7/* are absent 
(that's where the logical volumes live). The file system root lives on /dev/md5 
with metadata < 1.0, while /dev/vg7 has metadata >1.0. The fact that it 
happens often but not always suggests a timing problem to me.

# rc-update -s -v | grep -e raid -e lvm
                  lvm | boot                                   
       lvm-monitoring |                                        
              lvmetad |                                        
               mdraid | boot                                   

(This reminds me that since the last update of lvm2 I haven't been able to 
work out how to set it up to cause no errors.)

Can anyone suggest a way to tackle all these? I'm puzzled in particular by the 
apparent consistency in symptoms, apart from the RAID problem which I think 
only became a nuisance after installing the SSDs. Gkrellm shows CPU temps of 
50 to 55C, which seems normal enough. Could I have something misconfigured in 
the kernel?

I'm reduced to making general arm-waving noises...

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Canek Peláez Valdés]

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

On Wed, May 27, 2015 at 6:59 AM, Peter Humphrey <peter@prh.myzen.co.uk>
wrote:
>
> Hello list,

Hi.

> Over the last few weeks I've been having odd things go bump in the night.
This
> is a KDE amd64 system with /usr under / and no initrd.

I have no idea what your problem can be. But as a friendly reminder, your
setup ("/usr under / and no initrd") hasn't been supported since at least a
year and a half. From [1]:

"""
If you have / and /usr on separate file systems and you are not
currently using an initramfs, you must set one up before this date.
Otherwise, at some point on or after this date, upgrading packages
will make your system unbootable.
"""

It is of course possible that your problem has nothing to do with not using
an initramfs. Then again, *IT IS* also possible that you NEED an initramfs,
and that's one of the many reasons the council decided to stop supporting
such a configuration.

Regards.

[1]
https://www.gentoo.org/support/news-items/2013-09-27-initramfs-required.html
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

[-- Attachment #2: Type: text/html, Size: 1510 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Alan McKinnon]

On 27/05/2015 14:31, Canek Peláez Valdés wrote:
> On Wed, May 27, 2015 at 6:59 AM, Peter Humphrey <peter@prh.myzen.co.uk
> <mailto:peter@prh.myzen.co.uk>> wrote:
>>
>> Hello list,
> 
> Hi.
> 
>> Over the last few weeks I've been having odd things go bump in the
> night. This
>> is a KDE amd64 system with /usr under / and no initrd.
> 
> I have no idea what your problem can be. But as a friendly reminder,
> your setup ("/usr under / and no initrd") hasn't been supported since at
> least a year and a half.

I read what Peter said to mean that he doesn't have /usr as a separate
volume - it is directly under / ....



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] General weirdness - a tale of woe.

[Canek Peláez Valdés]

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

On Wed, May 27, 2015 at 8:02 AM, Alan McKinnon <alan.mckinnon@gmail.com>
wrote:
>
> On 27/05/2015 14:31, Canek Peláez Valdés wrote:
> > On Wed, May 27, 2015 at 6:59 AM, Peter Humphrey <peter@prh.myzen.co.uk
> > <mailto:peter@prh.myzen.co.uk>> wrote:
> >>
> >> Hello list,
> >
> > Hi.
> >
> >> Over the last few weeks I've been having odd things go bump in the
> > night. This
> >> is a KDE amd64 system with /usr under / and no initrd.
> >
> > I have no idea what your problem can be. But as a friendly reminder,
> > your setup ("/usr under / and no initrd") hasn't been supported since at
> > least a year and a half.
>
> I read what Peter said to mean that he doesn't have /usr as a separate
> volume - it is directly under / ....

Oh, sorry, I understand the opposite.

Regards.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

[-- Attachment #2: Type: text/html, Size: 1296 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Rich Freeman]

On Wed, May 27, 2015 at 7:59 AM, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> This is a KDE amd64 system with /usr under / and no initrd.

Just to clarify, is /usr on a separate filesystem, or the same as /?
I don't think that is your problem in any case, but it might be
relevant.

> ... bunch of KDE stuff

I've had the odd KDE issue along the way, like having extra panels
spawning off-screen with notifications showing up in wierd places as a
result.  That doesn't sound like your specific problem, but assuming a
KDE expert doesn't chime in here you might consider pursuing those
questions in a KDE forum/list, or maybe even in the Gentoo forums
where there is a section for desktop environments.  Again, assuming
somebody doesn't recognize your problem here.

> The last thing is that at reboot the RAID-1 volume manager often fails to
> start. It says afterwards that it's running, but all the /dev/vg7/* are absent
> (that's where the logical volumes live). The file system root lives on /dev/md5
> with metadata < 1.0, while /dev/vg7 has metadata >1.0. The fact that it
> happens often but not always suggests a timing problem to me.

I've sometimes seen this sort of thing with kernel raid autodetection,
especially with metadata <1.  I suspect that an initramfs might help
you out, assuming the filesystems on that RAID are useful in early
boot.  However, openrc and the raid init scripts should do a good job
of configuring your raid if your mdadm.conf and such is correct, so if
you don't need those filesystems until late in boot I don't think an
initramfs will make much of a difference, since it would likely use
the exact same userspace tools as openrc already does.  Make sure your
mdadm.conf is set up to search all devices that could contain RAID
(drive device names can get re-ordered), and it doesn't hurt to put
ARRAY lines in mdadm.conf to give it hints.

I do recommend just using an initramfs if you're using RAID for
early-boot filesystems.  While it is an extra step I find it is much
more robust than kernel autodetection (and if something goes wrong you
usually get an emergency shell where you can just manually get the
RAID up and type exit and watch the system boot).  It also lets you
use metadata >1 and I find that to be a lot more robust in general.
With an initramfs you can basically boot anything you can mount from a
booted system, but without one your options are more limited.

-- 
Rich

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Wednesday 27 May 2015 09:21:37 Rich Freeman wrote:
> On Wed, May 27, 2015 at 7:59 AM, Peter Humphrey <peter@prh.myzen.co.uk> 
wrote:
> > This is a KDE amd64 system with /usr under / and no initrd.
> 
> Just to clarify, is /usr on a separate filesystem, or the same as /?
> I don't think that is your problem in any case, but it might be
> relevant.

I didn't realise I wasn't clear, sorry. It might have been better if I'd said 
usr/ is under /. Anyway, it's not a separate partition.

> > ... bunch of KDE stuff
> 
> I've had the odd KDE issue along the way, like having extra panels
> spawning off-screen with notifications showing up in wierd places as a
> result.  That doesn't sound like your specific problem, but assuming a
> KDE expert doesn't chime in here you might consider pursuing those
> questions in a KDE forum/list, or maybe even in the Gentoo forums
> where there is a section for desktop environments.  Again, assuming
> somebody doesn't recognize your problem here.

Since writing, I've found that my fonts have all changed as well. It's almost 
as though something were cruising my home directories and flipping bits. And 
KMail insists on using American English in the composer, despite my telling it 
UK. That may not be new though.

I'm signed up to the KDE-Linux list already but I see hardly any traffic, and I 
suspect dark things about what happens to posts of mine on it.

> > The last thing is that at reboot the RAID-1 volume manager often fails to
> > start. It says afterwards that it's running, but all the /dev/vg7/* are
> > absent (that's where the logical volumes live). The file system root
> > lives on /dev/md5 with metadata < 1.0, while /dev/vg7 has metadata >1.0.
> > The fact that it happens often but not always suggests a timing problem
> > to me.
> 
> I've sometimes seen this sort of thing with kernel raid autodetection,
> especially with metadata <1.

More clarity needed on my part. The file-system root is /dev/md5 which has 
metadata < 1.0. It's found reliably by kernel autodetection. Subsidiary 
partitions are in /dev/md7 which has metadata > 1.0 and lvm2 volumes. Here's a 
bit of fstab:

/dev/vg7/portage    /usr/portage            ext4  relatime,discard  1 3
/dev/vg7/packages   /usr/portage/packages   ext4  relatime,discard  1 2
/dev/vg7/distfiles  /usr/portage/distfiles  ext4  relatime,discard  1 2
/dev/vg7/local      /usr/local              ext4  relatime,discard  1 2

It's the detection of md7 that often fails; I've had no trouble with md5.

Several other directories are in lvm2 volumes in /dev/vg7, but nothing that's 
part of system.

> I suspect that an initramfs might help
> you out, assuming the filesystems on that RAID are useful in early
> boot.  However, openrc and the raid init scripts should do a good job
> of configuring your raid if your mdadm.conf and such is correct, so if
> you don't need those filesystems until late in boot I don't think an
> initramfs will make much of a difference, since it would likely use
> the exact same userspace tools as openrc already does.  Make sure your
> mdadm.conf is set up to search all devices that could contain RAID
> (drive device names can get re-ordered), and it doesn't hurt to put
> ARRAY lines in mdadm.conf to give it hints.

Like this?
ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5
ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7

> I do recommend just using an initramfs if you're using RAID for
> early-boot filesystems.  While it is an extra step I find it is much
> more robust than kernel autodetection (and if something goes wrong you
> usually get an emergency shell where you can just manually get the
> RAID up and type exit and watch the system boot).  It also lets you
> use metadata >1 and I find that to be a lot more robust in general.
> With an initramfs you can basically boot anything you can mount from a
> booted system, but without one your options are more limited.

Well, that's an interesting idea - thanks. I'll give it some thought.

I've just switched on a few more sensors in gkrellm, and I see Vcor2 at 3.00 
and +3.3v at 3.34. Is it worth fiddling with those and related settings in the 
BIOS? I've always hesitated to do that, preferring to let it sort itself out.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 5912 bytes --]

On Wednesday 27 May 2015 15:16:35 Peter Humphrey wrote:
> On Wednesday 27 May 2015 09:21:37 Rich Freeman wrote:
> > On Wed, May 27, 2015 at 7:59 AM, Peter Humphrey <peter@prh.myzen.co.uk>
> 
> wrote:
> > > This is a KDE amd64 system with /usr under / and no initrd.
> > 
> > Just to clarify, is /usr on a separate filesystem, or the same as /?
> > I don't think that is your problem in any case, but it might be
> > relevant.
> 
> I didn't realise I wasn't clear, sorry. It might have been better if I'd
> said usr/ is under /. Anyway, it's not a separate partition.

It was clear to me.  It did a double take after Canek's email and still 
arrived at the same conclusion, but I accept that others read it differently.


> > > ... bunch of KDE stuff
> > 
> > I've had the odd KDE issue along the way, like having extra panels
> > spawning off-screen with notifications showing up in wierd places as a
> > result.  That doesn't sound like your specific problem, but assuming a
> > KDE expert doesn't chime in here you might consider pursuing those
> > questions in a KDE forum/list, or maybe even in the Gentoo forums
> > where there is a section for desktop environments.  Again, assuming
> > somebody doesn't recognize your problem here.
> 
> Since writing, I've found that my fonts have all changed as well. It's
> almost as though something were cruising my home directories and flipping
> bits. And KMail insists on using American English in the composer, despite
> my telling it UK. That may not be new though.
> 
> I'm signed up to the KDE-Linux list already but I see hardly any traffic,
> and I suspect dark things about what happens to posts of mine on it.

Disclaimer:  I am not using the full KDE desktop, but use a few KDE apps with 
an enlightenment desktop.

In the last week or two I noticed an oddity with kdeinit4, which I haven't yet 
been able to explain.  I share it here in case it is related to your problem, 
but even so my setup is different to yours and I have no explanation for it:

When away from base using insecure WiFi I run 'proxychains kdeinit4' to tunnel 
back to a local machine at home and bounce off to the Internet from there.

Suddenly, my (old) Kmail-1.13.7 stopped using the tunnel.  My (new) 
Knode-4.4.11 is also not using the tunnel.  They both just hang not 
establishing a connection whatsoever.  Konsole-2.14.2 is not using the tunnel 
either.

Strangely, Konqueror-4.14.3 *is* using the tunnel as before.  Launching 
konsole directly with 'proxychains konsole' is using the tunnel.  Kmail just 
fails to get anywhere even when invoked directly with proxychains, rather than 
via kdeinit4.

Proxychains was updated a couple of weeks ago and this problem may be related 
to it (I've raised a bug just in case), or it may be that something changed in 
KDE and this is the cause of both of our problems?  


> > > The last thing is that at reboot the RAID-1 volume manager often fails
> > > to start. It says afterwards that it's running, but all the /dev/vg7/*
> > > are absent (that's where the logical volumes live). The file system
> > > root lives on /dev/md5 with metadata < 1.0, while /dev/vg7 has
> > > metadata >1.0. The fact that it happens often but not always suggests
> > > a timing problem to me.
> > 
> > I've sometimes seen this sort of thing with kernel raid autodetection,
> > especially with metadata <1.
> 
> More clarity needed on my part. The file-system root is /dev/md5 which has
> metadata < 1.0. It's found reliably by kernel autodetection. Subsidiary
> partitions are in /dev/md7 which has metadata > 1.0 and lvm2 volumes.
> Here's a bit of fstab:
> 
> /dev/vg7/portage    /usr/portage            ext4  relatime,discard  1 3
> /dev/vg7/packages   /usr/portage/packages   ext4  relatime,discard  1 2
> /dev/vg7/distfiles  /usr/portage/distfiles  ext4  relatime,discard  1 2
> /dev/vg7/local      /usr/local              ext4  relatime,discard  1 2
> 
> It's the detection of md7 that often fails; I've had no trouble with md5.
> 
> Several other directories are in lvm2 volumes in /dev/vg7, but nothing
> that's part of system.
> 
> > I suspect that an initramfs might help
> > you out, assuming the filesystems on that RAID are useful in early
> > boot.  However, openrc and the raid init scripts should do a good job
> > of configuring your raid if your mdadm.conf and such is correct, so if
> > you don't need those filesystems until late in boot I don't think an
> > initramfs will make much of a difference, since it would likely use
> > the exact same userspace tools as openrc already does.  Make sure your
> > mdadm.conf is set up to search all devices that could contain RAID
> > (drive device names can get re-ordered), and it doesn't hurt to put
> > ARRAY lines in mdadm.conf to give it hints.
> 
> Like this?
> ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1
> ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5
> ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7

No, I have always used something like:

ARRAY /dev/md7 metadata=1.2 UUID=f9516418:7ef43875:4e922ca1:43796eb1 \ 
name=data_server:0

It may be that the /dev/sdaX takes longer to settle and this causes your 
problem, but I can't tell for sure.


> I've just switched on a few more sensors in gkrellm, and I see Vcor2 at
> 3.00 and +3.3v at 3.34. Is it worth fiddling with those and related
> settings in the BIOS? I've always hesitated to do that, preferring to let
> it sort itself out.

If you haven't O/C'ed it, I'd leave it alone.  However, if the voltage used to 
be something different in the past and is now registering a lower value using 
the same version BIOS firmware, then you could have a failing PSU.  We all 
know that this will inevitably lead to behavioural problems (inc. waving your 
arms around and making noises ...  :-))

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Wednesday 27 May 2015 21:40:37 Mick wrote:
> On Wednesday 27 May 2015 15:16:35 Peter Humphrey wrote:
> > On Wednesday 27 May 2015 09:21:37 Rich Freeman wrote:
> > > I suspect that an initramfs might help
> > > you out, assuming the filesystems on that RAID are useful in early
> > > boot.  However, openrc and the raid init scripts should do a good job
> > > of configuring your raid if your mdadm.conf and such is correct, so if
> > > you don't need those filesystems until late in boot I don't think an
> > > initramfs will make much of a difference, since it would likely use
> > > the exact same userspace tools as openrc already does.  Make sure your
> > > mdadm.conf is set up to search all devices that could contain RAID
> > > (drive device names can get re-ordered), and it doesn't hurt to put
> > > ARRAY lines in mdadm.conf to give it hints.
> > 
> > Like this?
> > ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1
> > ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5
> > ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7
> 
> No, I have always used something like:
> 
> ARRAY /dev/md7 metadata=1.2 UUID=f9516418:7ef43875:4e922ca1:43796eb1 \
> name=data_server:0

My mdadm.conf is now this:
DEVICE /dev/sd[ab]1
DEVICE /dev/sd[ab]5
DEVICE /dev/sd[ab]7
ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5
ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7

I'll see how that goes; so far no complaints about finding no arrays in the 
config file. I've never used UUIDs, preferring to be able to read what I'm 
specifying.

> It may be that the /dev/sdaX takes longer to settle and this causes your
> problem, but I can't tell for sure.

That does sound unlikely, especially as /dev/sdXN is suggested in the comments 
in mdadm.conf.

> > I've just switched on a few more sensors in gkrellm, and I see Vcor2 at
> > 3.00 and +3.3v at 3.34. Is it worth fiddling with those and related
> > settings in the BIOS? I've always hesitated to do that, preferring to let
> > it sort itself out.
> 
> If you haven't O/C'ed it, I'd leave it alone.  However, if the voltage used
> to be something different in the past and is now registering a lower value
> using the same version BIOS firmware, then you could have a failing PSU. 

No, no over-clocking here. Let the hardware work as designed, say I. And I 
haven't looked at voltages before so I don't know what's normal.

Failing PSU? Could be, and I have wondered. Maybe I'll make yet another 
attempt at setting up a new user and run without BOINC for a while, see if 
it's been applying too much load to this old bone-shaker.

> We all know that this will inevitably lead to behavioural problems (inc.
> waving your arms around and making noises ...  :-))

:-)  Thanks for your comments, Mick and friends.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Rich Freeman]

On Wed, May 27, 2015 at 8:01 PM, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> My mdadm.conf is now this:
> DEVICE /dev/sd[ab]1
> DEVICE /dev/sd[ab]5
> DEVICE /dev/sd[ab]7
> ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1
> ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5
> ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7
>
> I'll see how that goes; so far no complaints about finding no arrays in the
> config file. I've never used UUIDs, preferring to be able to read what I'm
> specifying.
>

The problem with this sort of approach is that you're hard-coding
device names.  If for whatever reason your devices are lettered
differently, mdadm may not assemble the array.

Here is an example of one of my old mdadm.conf files:
DEVICE /dev/sd[abcdefgh][12345] /dev/hd[abcde][12345]
#ARRAY /dev/md126 UUID=e424848a:593e3c8e:0e120ac2:958f662e
#ARRAY /dev/md124 UUID=dae2458d:e144dbde:34d5107b:2f8c859e
#ARRAY /dev/md127 UUID=4096c546:a0d9d5c4:5063dd02:38d16c75

This tells mdadm to scan all those permutations of device names, find
anything with those UUIDs and attempt to assemble the arrays, giving
them the preferred minor numbers.

Some of those device names probably don't even exist (not all of those
drives have 5 partitions, etc).  It doesn't matter - mdadm just checks
the ones that do exist.  Then if for whatever reason sdd is now hdc it
doesn't matter.

With an approach like yours, mdadm will attempt to create md1 by
looking ONLY at sda1 and sdb1, and if that pair forms a valid array it
is started, and if not it is not.  If you add a new drive to your
system or for whatever reason the kernel/udev rules change a little or
some race condition changes a little then your devices might get
different names, and the array will not be assembled.

UUIDs are often preferable in these kinds of configurations, because
you're less likely to run into duplicate identifiers, they don't
change, and so on.  If I mount root=UUID=foo, then my initramfs will
try really hard to find that partition and mount it.  If I mount
root=label=foo then it will still try hard, but if for some reason I
have more than one device with that label I could end up booting from
the wrong one.  If I mount root=/dev/sda1 then my boot may fail if I
add a new drive, if the kernel behavior changes, if the udev behavior
changes, and so on.

I don't believe either the kernel or udev makes promises about device
names being stable.  It often works out this way, but it isn't ideal
to depend on this.

-- 
Rich

Re: [gentoo-user] General weirdness - a tale of woe.

[Todd Goodman]

* Rich Freeman <rich0@gentoo.org> [150528 08:45]:
> On Wed, May 27, 2015 at 8:01 PM, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
[..SNIP..]
> UUIDs are often preferable in these kinds of configurations, because
> you're less likely to run into duplicate identifiers, they don't
> change, and so on.  If I mount root=UUID=foo, then my initramfs will
> try really hard to find that partition and mount it.  If I mount
> root=label=foo then it will still try hard, but if for some reason I
> have more than one device with that label I could end up booting from
> the wrong one.  If I mount root=/dev/sda1 then my boot may fail if I
> add a new drive, if the kernel behavior changes, if the udev behavior
> changes, and so on.
> 
> I don't believe either the kernel or udev makes promises about device
> names being stable.  It often works out this way, but it isn't ideal
> to depend on this.
> 
> -- 
> Rich

It's worse than just getting the wrong filesystem mounted if the wrong
filesystem gets mounted as /tmp.

OpenRC's bootmisc will wipe the /tmp directory at boot (and likely
systemd as well, but I haven't checked.)

This means if disk device names get shifted and something other than the
proper /tmp device gets mounted as /tmp then it's "restore-from-backups"
time.

This happened to me and wiped /home (the /dev/md* devices got renumbered
once.)

So I've switched to UUID mounts so that problem doesn't happen in the
future.

It's really unpleasant if that happens.

Todd

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Thursday 28 May 2015 08:44:27 Rich Freeman wrote:
> On Wed, May 27, 2015 at 8:01 PM, Peter Humphrey 
<peter@prh.myzen.co.uk> wrote:
> > My mdadm.conf is now this:
> > DEVICE /dev/sd[ab]1
> > DEVICE /dev/sd[ab]5
> > DEVICE /dev/sd[ab]7
> > ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1
> > ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5
> > ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7
> > 
> > I'll see how that goes; so far no complaints about finding no arrays in
> > the
> > config file. I've never used UUIDs, preferring to be able to read what I'm
> > specifying.
> 
> The problem with this sort of approach is that you're hard-coding
> device names.  If for whatever reason your devices are lettered
> differently, mdadm may not assemble the array.
> 
> Here is an example of one of my old mdadm.conf files:
> DEVICE /dev/sd[abcdefgh][12345] /dev/hd[abcde][12345]
> #ARRAY /dev/md126 UUID=e424848a:593e3c8e:0e120ac2:958f662e
> #ARRAY /dev/md124 UUID=dae2458d:e144dbde:34d5107b:2f8c859e
> #ARRAY /dev/md127 UUID=4096c546:a0d9d5c4:5063dd02:38d16c75
> 
> This tells mdadm to scan all those permutations of device names, find
> anything with those UUIDs and attempt to assemble the arrays, giving
> them the preferred minor numbers.
> 
> Some of those device names probably don't even exist (not all of those
> drives have 5 partitions, etc).  It doesn't matter - mdadm just checks
> the ones that do exist.  Then if for whatever reason sdd is now hdc it
> doesn't matter.
> 
> With an approach like yours, mdadm will attempt to create md1 by
> looking ONLY at sda1 and sdb1, and if that pair forms a valid array it
> is started, and if not it is not.  If you add a new drive to your
> system or for whatever reason the kernel/udev rules change a little or
> some race condition changes a little then your devices might get
> different names, and the array will not be assembled.

Hmm. I wonder if that's what's happening to me. Perhaps I'd better adopt 
UUIDs then, once I work out what mine are. Thanks for the advice.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Thursday 28 May 2015 15:36:04 I wrote:
> On Thursday 28 May 2015 08:44:27 Rich Freeman wrote:
> > With an approach like yours, mdadm will attempt to create md1 by
> > looking ONLY at sda1 and sdb1, and if that pair forms a valid array it
> > is started, and if not it is not.  If you add a new drive to your
> > system or for whatever reason the kernel/udev rules change a little or
> > some race condition changes a little then your devices might get
> > different names, and the array will not be assembled.
> 
> Hmm. I wonder if that's what's happening to me. Perhaps I'd better adopt
> UUIDs then, once I work out what mine are. Thanks for the advice.

I've found blkid, which tells me the UUIDs of my various devices, thus:

# blkid /dev/md7
/dev/md7: UUID="ycGMf9-hEP2-tjT4-AtkJ-n8RI-pZ44-RqvlEY" 
TYPE="LVM2_member"

Two odd things:
1.	/dev/md7 is the physical volume in which logical volumes are defined, 
so I'm surprised to see TYPE="LVM2_member".
2.	There is no entry corresponding to /dev/md7 under /dev/disk/by-uuid, 
though /dev/md1 and /dev/md5 do have entries there [1].

To recap, md1 and md5 are raid-1 with metadata < 1.0; they contain extN 
file-systems; md7 has metadata > 1.0 and is a container for 15 logical 
volumes, each of which has an extN file-system and is mounted somewhere 
under / (/usr is not among them; it's in the root file-system).

What should I be doing about this?

[1]	For reference, here's the complete list of entries under /dev/disk/by-
uuid, minus the date etc:

1bb4ba53-677a-4a0e-b737-f3e274f0e71e -> ../../sda2
1e20e3e6-e218-485b-b5ff-be85a287e364 -> ../../sda3
3a2a6e94-a6f0-4479-ae87-44887946148c -> ../../sda6
3befff76-2a0e-49fa-9e6f-2bd0ed73cf31 -> ../../md5
43e655ca-a6ef-4931-99b6-3aa2ad6c30cb -> ../../sda8
443ae151-0dd5-47a5-9ff6-56cc1027b4f7 -> ../../dm-3
47b057a0-3454-4777-8b53-ae5d240b608c -> ../../dm-11
47fe6d95-38be-4581-983c-a6368bd085b2 -> ../../dm-6
53f0c9c2-c21f-4c26-942d-8760e0697fe4 -> ../../dm-9
72b063b2-76bd-4080-aca0-f0109c1ab25d -> ../../dm-4
8e2a7e68-ac48-4aa2-9d33-64fd5ffbe759 -> ../../dm-1
94612986-3a94-4de0-85b4-3ee822dca0ef -> ../../dm-8
96ba30f0-dc69-4083-ab76-df117432bfae -> ../../sdb2
b24e7a6f-8f27-420b-aed5-bc1272ba4856 -> ../../dm-12
c05dab85-aff2-4402-ae91-7d9097e68206 -> ../../sdb8
c1145ff8-f3c0-48ad-a4fe-50330280be69 -> ../../dm-5
d0f6c604-2ef9-4812-afbf-5fd6965201e2 -> ../../md1
d531c442-7a7f-4595-a4f3-4e7416b3ec47 -> ../../dm-13
d66bad37-84d6-4cf7-9414-3d9535261c41 -> ../../dm-2
db56ddb3-3106-40fc-8345-d92a2354eb58 -> ../../dm-0
e69863b9-8fcd-4d7a-b94f-64baa3a77852 -> ../../sdb3
e7ed40e0-826e-406d-bc5a-5e5b9ef37434 -> ../../dm-10
ee1f1925-3e2b-4964-9ad5-248fff623b3c -> ../../sdb6
ee39723d-b950-4d00-8c8e-9dac75fe478c -> ../../dm-7

(It would have been nice to sort on the final field but I can't see how to do 
that.)

I assume that the ../../dm-N links refer to the LVs - there are 15 of them. 
md7 is conspicuous by its absence. This seems like a problem to me, and it 
may account for /dev/md7 sometimes not being started at boot time.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Rich Freeman]

On Thu, May 28, 2015 at 1:03 PM, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> On Thursday 28 May 2015 15:36:04 I wrote:
>> On Thursday 28 May 2015 08:44:27 Rich Freeman wrote:
>> > With an approach like yours, mdadm will attempt to create md1 by
>> > looking ONLY at sda1 and sdb1, and if that pair forms a valid array it
>> > is started, and if not it is not.  If you add a new drive to your
>> > system or for whatever reason the kernel/udev rules change a little or
>> > some race condition changes a little then your devices might get
>> > different names, and the array will not be assembled.
>>
>> Hmm. I wonder if that's what's happening to me. Perhaps I'd better adopt
>> UUIDs then, once I work out what mine are. Thanks for the advice.
>
> I've found blkid, which tells me the UUIDs of my various devices, thus:
>
> # blkid /dev/md7
> /dev/md7: UUID="ycGMf9-hEP2-tjT4-AtkJ-n8RI-pZ44-RqvlEY"
> TYPE="LVM2_member"

Just keep in mind that the UUID that goes into mdadm.conf might not be
the same UUID returned by blkid.  I'm honestly not certain either way.
You can get the mdadm ID from mdadm --detail --scan.

>
> Two odd things:
> 1.      /dev/md7 is the physical volume in which logical volumes are defined,
> so I'm surprised to see TYPE="LVM2_member".

I'm pretty sure this is fine.  It recognizes it as an LVM pv, so that
makes it an LVM2 member.

> 2.      There is no entry corresponding to /dev/md7 under /dev/disk/by-uuid,
> though /dev/md1 and /dev/md5 do have entries there [1].

udev may be configured to not create uuid symlinks for LVM pvs (since
you wouldn't directly mount them anyway).  The others contain
filesystems and do get symlinks.


>
> What should I be doing about this?

I'd probably just edit your mdadm.conf to be more liberal with
scanning, and add the arrays output by mdadm --detail --scan to your
config file.  That alone may make your problems go away, and it should
be pretty harmless.

>
> I assume that the ../../dm-N links refer to the LVs - there are 15 of them.
> md7 is conspicuous by its absence. This seems like a problem to me, and it
> may account for /dev/md7 sometimes not being started at boot time.
>

LVM is just a wrapper around DM, so that is normal.  Nothing about
what you've written here concerns me.

-- 
Rich

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Thursday 28 May 2015 19:51:24 Rich Freeman wrote:
> On Thu, May 28, 2015 at 1:03 PM, Peter Humphrey <peter@prh.myzen.co.uk> 
wrote:
> > I've found blkid, which tells me the UUIDs of my various devices, thus:
> > 
> > # blkid /dev/md7
> > /dev/md7: UUID="ycGMf9-hEP2-tjT4-AtkJ-n8RI-pZ44-RqvlEY"
> > TYPE="LVM2_member"
> 
> Just keep in mind that the UUID that goes into mdadm.conf might not be
> the same UUID returned by blkid.  I'm honestly not certain either way.
> You can get the mdadm ID from mdadm --detail --scan.

Good grief! When is a UUID not a UUID? Or, how can one device have more than 
one UUID?


> > Two odd things:
> > 1.      /dev/md7 is the physical volume in which logical volumes are
> > defined, so I'm surprised to see TYPE="LVM2_member".
> 
> I'm pretty sure this is fine.  It recognizes it as an LVM pv, so that
> makes it an LVM2 member.

If you say so. It still smells a bit to me.

> > 2.      There is no entry corresponding to /dev/md7 under
> > /dev/disk/by-uuid, though /dev/md1 and /dev/md5 do have entries there
> > [1].
> 
> udev may be configured to not create uuid symlinks for LVM pvs (since
> you wouldn't directly mount them anyway).  The others contain
> filesystems and do get symlinks.
> 
> > What should I be doing about this?
> 
> I'd probably just edit your mdadm.conf to be more liberal with
> scanning, and add the arrays output by mdadm --detail --scan to your
> config file.  That alone may make your problems go away, and it should
> be pretty harmless.

OK, so this is what I have at present. I haven't booted with it yet to test it 
- I'll do that in the morning:

DEVICE /dev/sd[abcde][123456789]
ARRAY /dev/md1 UUID=ea156c7f:183ca28e:c44c77eb:7ee19756
ARRAY /dev/md5 UUID=e7640378:966a5b3a:c44c77eb:7ee19756
ARRAY /dev/md7 UUID=c2d056c4:9118021f:ad73c633:b38fa97c

> Nothing about what you've written here concerns me.

Well, let us be thankful for small mercies :-)

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Neil Bothwick]

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

On Fri, 29 May 2015 01:10:52 +0100, Peter Humphrey wrote:

> > Just keep in mind that the UUID that goes into mdadm.conf might not be
> > the same UUID returned by blkid.  I'm honestly not certain either way.
> > You can get the mdadm ID from mdadm --detail --scan.
> 
> Good grief! When is a UUID not a UUID? Or, how can one device have more
> than one UUID?

There's the UUID for the partition and the UUID for the filesystem living
on it. 

> > > Two odd things:
> > > 1.      /dev/md7 is the physical volume in which logical volumes are
> > > defined, so I'm surprised to see TYPE="LVM2_member".
> > 
> > I'm pretty sure this is fine.  It recognizes it as an LVM pv, so that
> > makes it an LVM2 member.
> 
> If you say so. It still smells a bit to me.

It makes sense to me. TYPE refers to the filesystem type, look at the
blkid output for your boot or swap partition. blkid is simply recognising
that this partition is a member of an LVM group.


-- 
Neil Bothwick

I have seen things you lusers would not believe.
I've seen Sun monitors on fire off the side of the multimedia lab.
I've seen NTU lights glitter in the dark near the Mail Gate.
All these things will be lost in time, like the root partition last week.
Time to die.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Stephan Müller]

Am 28.05.2015 um 19:03 schrieb Peter Humphrey:
> 1bb4ba53-677a-4a0e-b737-f3e274f0e71e -> ../../sda2
> 1e20e3e6-e218-485b-b5ff-be85a287e364 -> ../../sda3
> 3a2a6e94-a6f0-4479-ae87-44887946148c -> ../../sda6
> 3befff76-2a0e-49fa-9e6f-2bd0ed73cf31 -> ../../md5
> 43e655ca-a6ef-4931-99b6-3aa2ad6c30cb -> ../../sda8
> 443ae151-0dd5-47a5-9ff6-56cc1027b4f7 -> ../../dm-3
> 47b057a0-3454-4777-8b53-ae5d240b608c -> ../../dm-11
> 47fe6d95-38be-4581-983c-a6368bd085b2 -> ../../dm-6
> 53f0c9c2-c21f-4c26-942d-8760e0697fe4 -> ../../dm-9
> 72b063b2-76bd-4080-aca0-f0109c1ab25d -> ../../dm-4
> 8e2a7e68-ac48-4aa2-9d33-64fd5ffbe759 -> ../../dm-1
> 94612986-3a94-4de0-85b4-3ee822dca0ef -> ../../dm-8
> 96ba30f0-dc69-4083-ab76-df117432bfae -> ../../sdb2
> b24e7a6f-8f27-420b-aed5-bc1272ba4856 -> ../../dm-12
> c05dab85-aff2-4402-ae91-7d9097e68206 -> ../../sdb8
> c1145ff8-f3c0-48ad-a4fe-50330280be69 -> ../../dm-5
> d0f6c604-2ef9-4812-afbf-5fd6965201e2 -> ../../md1
> d531c442-7a7f-4595-a4f3-4e7416b3ec47 -> ../../dm-13
> d66bad37-84d6-4cf7-9414-3d9535261c41 -> ../../dm-2
> db56ddb3-3106-40fc-8345-d92a2354eb58 -> ../../dm-0
> e69863b9-8fcd-4d7a-b94f-64baa3a77852 -> ../../sdb3
> e7ed40e0-826e-406d-bc5a-5e5b9ef37434 -> ../../dm-10
> ee1f1925-3e2b-4964-9ad5-248fff623b3c -> ../../sdb6
> ee39723d-b950-4d00-8c8e-9dac75fe478c -> ../../dm-7
> 
> (It would have been nice to sort on the final field but I can't see how to do 
> that.)

For example like this: 

  $ ls -l /dev/disk/by-uuid/ | awk '{print $11, $9}' | sort


Nice thread though. I am curious how all this relates to your initial problems.. good luck.

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Friday 29 May 2015 11:13:22 Stephan Müller wrote:
> Am 28.05.2015 um 19:03 schrieb Peter Humphrey:
> > (It would have been nice to sort on the final field but I can't see how to
> > do that.)
> 
> For example like this:
> 
>   $ ls -l /dev/disk/by-uuid/ | awk '{print $11, $9}' | sort

That's something like what I was thinking, yes.

> Nice thread though. I am curious how all this relates to your initial
> problems.. good luck.

I had two sets of problems: one in KDE which I might have nailed finally [1], 
and one at boot time in which /dev/md7 (RAID-1 with metadata > 1.0) was not 
being started.

[1]	Whenever I've had KMail screw up I've created a new user and re-imported 
its 14,000 e-mails, and until this latest time I've copied the .mozilla 
directory from the old user to the new. This time I did not, and so far all 
looks rosy. I'm not counting any chickens yet though.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 774 bytes --]

On Friday 29 May 2015 10:36:37 Peter Humphrey wrote:

> I had two sets of problems: one in KDE which I might have nailed finally
> [1], and one at boot time in which /dev/md7 (RAID-1 with metadata > 1.0)
> was not being started.
> 
> [1]	Whenever I've had KMail screw up I've created a new user and
> re-imported its 14,000 e-mails, and until this latest time I've copied the
> .mozilla directory from the old user to the new. This time I did not, and
> so far all looks rosy. I'm not counting any chickens yet though.

Did you try deleting the akonadi database file(s) and restarting it instead of 
creating a new user?  You will have to be patient, probably let it run 
overnight to asynchronously sync and re-index all your messages.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Alan Grimes]

Mick wrote:
> On Friday 29 May 2015 10:36:37 Peter Humphrey wrote:
>
>> I had two sets of problems: one in KDE which I might have nailed finally
>> [1], and one at boot time in which /dev/md7 (RAID-1 with metadata > 1.0)
>> was not being started.
>>
>> [1]	Whenever I've had KMail screw up I've created a new user and
>> re-imported its 14,000 e-mails, and until this latest time I've copied the
>> .mozilla directory from the old user to the new. This time I did not, and
>> so far all looks rosy. I'm not counting any chickens yet though.
> Did you try deleting the akonadi database file(s) and restarting it instead of 
> creating a new user?  You will have to be patient, probably let it run 
> overnight to asynchronously sync and re-index all your messages.

What in god's name is that stupid database for anyway? Does it perform
any useful function? Is there any tool that gives the user any
measurable benefit that even justifies one one hundredth of the CPU and
disk bandwidth consumed by this missfeature?


-- 
IQ is a measure of how stupid you feel.

Powers are not rights.

Re: [gentoo-user] General weirdness - a tale of woe.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1647 bytes --]

On Friday 29 May 2015 16:28:57 Alan Grimes wrote:
> Mick wrote:
> > On Friday 29 May 2015 10:36:37 Peter Humphrey wrote:
> >> I had two sets of problems: one in KDE which I might have nailed finally
> >> [1], and one at boot time in which /dev/md7 (RAID-1 with metadata > 1.0)
> >> was not being started.
> >> 
> >> [1]	Whenever I've had KMail screw up I've created a new user and
> >> re-imported its 14,000 e-mails, and until this latest time I've copied
> >> the .mozilla directory from the old user to the new. This time I did
> >> not, and so far all looks rosy. I'm not counting any chickens yet
> >> though.
> > 
> > Did you try deleting the akonadi database file(s) and restarting it
> > instead of creating a new user?  You will have to be patient, probably
> > let it run overnight to asynchronously sync and re-index all your
> > messages.
> 
> What in god's name is that stupid database for anyway? Does it perform
> any useful function? Is there any tool that gives the user any
> measurable benefit that even justifies one one hundredth of the CPU and
> disk bandwidth consumed by this missfeature?

I think you're preaching to the converted here.  I don't think you'll find 
many advocates in this M/L who support the KDE4 desktop design decision as a 
sound architectural choice for your average Linux user.  I think they were 
trying to market a desktop for the enterprise and were following Gnome's 
approach of semantic content searches.

Other than the odd bug here and there I was perfectly happy with KDE3 and 
Kmail1 (still using with kde-base/kdepim-meta-4.4.11.1-r1).

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Friday 29 May 2015 16:54:33 Mick wrote:
> On Friday 29 May 2015 16:28:57 Alan Grimes wrote:
> > What in god's name is that stupid database for anyway? Does it perform
> > any useful function? Is there any tool that gives the user any
> > measurable benefit that even justifies one one hundredth of the CPU and
> > disk bandwidth consumed by this missfeature?
> 
> I think you're preaching to the converted here.

He is, no doubt about it.

> I don't think you'll find many advocates in this M/L who support the KDE4
> desktop design decision as a sound architectural choice for your average
> Linux user.

He was talking about tying the e-mail client to a database, not about the KDE4 
desktop, and I've protested at the same thing more than once, sometimes in 
vigorous terms. Made no difference of course, but then I'm just an insufficiently 
humble user.

> I think they were trying to market a desktop for the enterprise and were
> following Gnome's approach of semantic content searches.

It seems to me that, KMail being such a capable e-mail client, there ought to 
be more than one way of installing it. One of those would be as you say: the 
way it's going, aimed at corporations with PIM functions and sharing of all 
manner of things among colleagues. At the other end of the spectrum would be 
what I think all of us on this list would prefer (those who like KDE, that 
is), namely a textual manipulator of simple e-mail files.

The choice could be exercised using something like our USE flags, or it could 
have dual implementations derived more-or-less automatically from a common 
code base.

(In the mid-80s I was working in a project to replace the grid-control 
computer system in England and Wales. The spec had come from our hardware 
people (yes, I know) and required us to develop code that would run equally 
well on Ferranti and GEC machines. The Ferranti scheduling and context-
switching methods heavily favoured small numbers of large processes, whereas 
the GEC imposed a hardware limit of 8K bytes on any running process. We were 
well on the way to making it work, too. What I suggest for KMail pales into 
insignificance compared with that mess. It's just a Simple Matter Of 
Programming, isn't it?)

> Other than the odd bug here and there I was perfectly happy with KDE3 and
> Kmail1 (still using with kde-base/kdepim-meta-4.4.11.1-r1).

I wonder if there's a way to go back to KMail-1 and import all my e-mails from 
KMail-2 archive files into it. Would you like to help me, Mick, with ebuilds 
etc?

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Neil Bothwick]

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

On Sat, 30 May 2015 00:20:51 +0100, Peter Humphrey wrote:

> He was talking about tying the e-mail client to a database, not about
> the KDE4 desktop, and I've protested at the same thing more than
> once, sometimes in vigorous terms. Made no difference of course, but
> then I'm just an insufficiently humble user.

I can see the point in using a database to index mails for faster
searching, but relying on it for the mail program to work is plain daft.


-- 
Neil Bothwick

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1900 bytes --]

On Saturday 30 May 2015 00:20:51 Peter Humphrey wrote:
> > Other than the odd bug here and there I was perfectly happy with KDE3 and
> > Kmail1 (still using with kde-base/kdepim-meta-4.4.11.1-r1).
> 
> I wonder if there's a way to go back to KMail-1 and import all my e-mails
> from  KMail-2 archive files into it. Would you like to help me, Mick, with
> ebuilds etc?

On my laptop which has stayed on Kmail-1 I have this:

$ cat /etc/portage/package.mask 
>=kde-base/akonadiconsole-4.5.50
>=kde-base/akregator-4.5.50
>=kde-base/blogilo-4.5.50
>=kde-base/kabcclient-4.5.50
>=kde-base/kaddressbook-4.5.50
>=kde-base/kalarm-4.5.50
>=kde-base/kdepim-common-libs-4.5.50
>=kde-base/kdepim-icons-4.5.50
>=kde-base/kdepim-l10n-4.5.50
>=kde-base/kdepim-kresources-4.5.50
>=kde-base/kdepim-meta-4.5.50
>=kde-base/kdepim-strigi-analyzer-4.5.50
>=kde-base/kdepim-runtime-4.5.50
>=kde-base/kdepim-wizards-4.5.50
>=kde-base/kjots-4.5.50
>=kde-base/kleopatra-4.5.50
>=kde-base/kmail-4.5.50
>=kde-base/knode-4.5.50
>=kde-base/knotes-4.5.50
>=kde-base/konsolekalendar-4.5.50
>=kde-base/kontact-4.5.50
>=kde-base/korganizer-4.5.50
>=kde-base/ktimetracker-4.5.50


I don't know if going back to Kmail-1 from Kmail-2 is a viable proposal.  Some 
of the Kmail-1 packages have abi_x86_32 dependencies, so expect some 
rebuilding of e.g. sys-libs/readline-6.3_p8-r2  I performed it a number of 
times on an old laptop, which would not work with Kmail-2, but this was done 
some years ago.  In each case I restored my Mail folder from back up and 
eventually gave up on Kmail-2.


Have a look here for more details and warnings:

https://wiki.gentoo.org/wiki/KDE/KDEPIM-4.7_upgrade


I expect that sooner or later bitrot will catch up with Kmail-1 and it will 
stop working.  I dread for this happening, but I will not move to Kmail-2 
until then.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Saturday 30 May 2015 12:49:51 Mick wrote:

> On my laptop which has stayed on Kmail-1 I have this:
--->8
> Have a look here for more details and warnings:
> 
> https://wiki.gentoo.org/wiki/KDE/KDEPIM-4.7_upgrade

Many thanks Mick - that's very helpful.

> I expect that sooner or later bitrot will catch up with Kmail-1 and it will
> stop working.  I dread for this happening, but I will not move to Kmail-2
> until then.

I don't blame you, and I wish I hadn't either. I'll see if it's possible to go 
back.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Saturday 30 May 2015 16:43:13 Peter Humphrey wrote:
> On Saturday 30 May 2015 12:49:51 Mick wrote:
> > On my laptop which has stayed on Kmail-1 I have this:
> --->8
> 
> > Have a look here for more details and warnings:
> > 
> > https://wiki.gentoo.org/wiki/KDE/KDEPIM-4.7_upgrade
> 
> Many thanks Mick - that's very helpful.
> 
> > I expect that sooner or later bitrot will catch up with Kmail-1 and it
> > will
> > stop working.  I dread for this happening, but I will not move to Kmail-2
> > until then.
> 
> I don't blame you, and I wish I hadn't either. I'll see if it's possible to
> go back.

Well, it did look promising right up to the last gasp. I put those 
package.mask entries in, and I found I needed a couple of package.use entries 
as well, and then everything went suspiciously well. Portage downgraded 
several packages and recompiled several others, and I was ready to go.

At this point I must put in a word of commendation for portage: it handled 
this major regression with aplomb throughout. That is one professional 
program.

I created a new user (this is now really tedious), started KMail-1 and 
imported 14000-odd messages from the old KMail-2 - and in a fraction of the 
time that KMail-2 takes for the same task. Great! I thought. Then I found 
there was no inbox to copy its e-mails into, and I couldn't copy the folder 
because one existed already - I just couldn't see it. I think I remember it 
disappearing once or twice before in the days of KMail-1. Anyway, I couldn't 
see a way forward so I've reverted to the original KMail-2 pro tem.

Maybe I'll have another go if I remember the way out of having no inbox. 
Anyway, thanks Mick for steering me the way I wanted to go.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2612 bytes --]

On Sunday 31 May 2015 01:39:34 Peter Humphrey wrote:
> On Saturday 30 May 2015 16:43:13 Peter Humphrey wrote:
> > On Saturday 30 May 2015 12:49:51 Mick wrote:
> > > On my laptop which has stayed on Kmail-1 I have this:
> > --->8
> > 
> > > Have a look here for more details and warnings:
> > > 
> > > https://wiki.gentoo.org/wiki/KDE/KDEPIM-4.7_upgrade
> > 
> > Many thanks Mick - that's very helpful.
> > 
> > > I expect that sooner or later bitrot will catch up with Kmail-1 and it
> > > will
> > > stop working.  I dread for this happening, but I will not move to
> > > Kmail-2 until then.
> > 
> > I don't blame you, and I wish I hadn't either. I'll see if it's possible
> > to go back.
> 
> Well, it did look promising right up to the last gasp. I put those
> package.mask entries in, and I found I needed a couple of package.use
> entries as well, and then everything went suspiciously well. Portage
> downgraded several packages and recompiled several others, and I was ready
> to go.
> 
> At this point I must put in a word of commendation for portage: it handled
> this major regression with aplomb throughout. That is one professional
> program.
> 
> I created a new user (this is now really tedious), started KMail-1 and
> imported 14000-odd messages from the old KMail-2 - and in a fraction of the
> time that KMail-2 takes for the same task. Great! I thought. Then I found
> there was no inbox to copy its e-mails into, and I couldn't copy the folder
> because one existed already - I just couldn't see it. I think I remember it
> disappearing once or twice before in the days of KMail-1. Anyway, I
> couldn't see a way forward so I've reverted to the original KMail-2 pro
> tem.
> 
> Maybe I'll have another go if I remember the way out of having no inbox.
> Anyway, thanks Mick for steering me the way I wanted to go.

You're welcome.

You could look into ~/Mail/ or wherever you keep your mails and find the Inbox 
directory.  Then copy any messages you want shown there manually.  The index 
will be recreated when you restart Kmail, or if you click on 'Recreate Index' 
under the Properties/Maintenance of the folder.

Also, under Settings/Configure Kmail/Misc there is a field to specify which 
folder to open on start up.

Some combination of the above should work.

Please note there is a known bug which has come about due to bitrot:  All sent 
messages are placed in the local Sent-Mail folder.  I have to manually drag 
and drop them in the respective email account sent folders from which they 
were sent.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Sunday 31 May 2015 13:18:06 Mick wrote:

> You could look into ~/Mail/ or wherever you keep your mails and find the
> Inbox directory.  Then copy any messages you want shown there manually. 
> The index will be recreated when you restart Kmail, or if you click on
> 'Recreate Index' under the Properties/Maintenance of the folder.
> 
> Also, under Settings/Configure Kmail/Misc there is a field to specify which
> folder to open on start up.
> 
> Some combination of the above should work.

The trouble is that the in-box folder is missing, so there's no way to 
manipulate what's in it.

> Please note there is a known bug which has come about due to bitrot:  All
> sent messages are placed in the local Sent-Mail folder.  I have to manually
> drag and drop them in the respective email account sent folders from which
> they were sent.

Ah, well that shouldn't bother me because I have only one outgoing account, so 
only one sent-mail folder.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1246 bytes --]

On Sunday 31 May 2015 15:01:10 Peter Humphrey wrote:
> On Sunday 31 May 2015 13:18:06 Mick wrote:
> > You could look into ~/Mail/ or wherever you keep your mails and find the
> > Inbox directory.  Then copy any messages you want shown there manually.
> > The index will be recreated when you restart Kmail, or if you click on
> > 'Recreate Index' under the Properties/Maintenance of the folder.
> > 
> > Also, under Settings/Configure Kmail/Misc there is a field to specify
> > which folder to open on start up.
> > 
> > Some combination of the above should work.
> 
> The trouble is that the in-box folder is missing, so there's no way to
> manipulate what's in it.

I appreciate the inbox folder is not shown in the GUI.  Is there an inbox 
directory under your main mail storage?  This is mine:

$ ls -al Mail/inbox/
total 92
drwx------  5 michael michael  4096 May 31 15:23 .
drwx------ 16 michael michael  4096 May 31 13:18 ..
drwx------  2 michael michael 73728 May 30 23:38 cur
drwx------  2 michael michael  4096 Jul 17  2010 new
drwx------  2 michael michael  4096 May 30 23:25 tmp

You can check if your messages are shown under ../inbox/cur

If not you can manually copy them there.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Alan McKinnon]

On 29/05/2015 17:54, Mick wrote:
> On Friday 29 May 2015 16:28:57 Alan Grimes wrote:
>> Mick wrote:
>>> On Friday 29 May 2015 10:36:37 Peter Humphrey wrote:
>>>> I had two sets of problems: one in KDE which I might have nailed finally
>>>> [1], and one at boot time in which /dev/md7 (RAID-1 with metadata > 1.0)
>>>> was not being started.
>>>>
>>>> [1]	Whenever I've had KMail screw up I've created a new user and
>>>> re-imported its 14,000 e-mails, and until this latest time I've copied
>>>> the .mozilla directory from the old user to the new. This time I did
>>>> not, and so far all looks rosy. I'm not counting any chickens yet
>>>> though.
>>>
>>> Did you try deleting the akonadi database file(s) and restarting it
>>> instead of creating a new user?  You will have to be patient, probably
>>> let it run overnight to asynchronously sync and re-index all your
>>> messages.
>>
>> What in god's name is that stupid database for anyway? Does it perform
>> any useful function? Is there any tool that gives the user any
>> measurable benefit that even justifies one one hundredth of the CPU and
>> disk bandwidth consumed by this missfeature?
> 
> I think you're preaching to the converted here.  I don't think you'll find 
> many advocates in this M/L who support the KDE4 desktop design decision as a 
> sound architectural choice for your average Linux user.  I think they were 
> trying to market a desktop for the enterprise and were following Gnome's 
> approach of semantic content searches.
> 
> Other than the odd bug here and there I was perfectly happy with KDE3 and 
> Kmail1 (still using with kde-base/kdepim-meta-4.4.11.1-r1).
> 

Akonadi was supposed to be a once-size-fits-all central store of all pim
info (contacts, addresses, mails and all metadata about that) which any
and all apps could use.

The vision was that an enormous awesome ecosystem all buying into the
OneGrandVision(tm) would spontaneously spring up, thereby validating the
existence of akonadi itself due to a magic self-fulfilling prophecy.
This did not happen.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Saturday 30 May 2015 09:53:23 Alan McKinnon wrote:

> Akonadi was supposed to be a once-size-fits-all central store of all pim
> info (contacts, addresses, mails and all metadata about that) which any
> and all apps could use.
> 
> The vision was that an enormous awesome ecosystem all buying into the
> OneGrandVision(tm) would spontaneously spring up, thereby validating the
> existence of akonadi itself due to a magic self-fulfilling prophecy.
> This did not happen.

Nor will it.

It's long since time they had another think.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Friday 29 May 2015 16:19:38 Mick wrote:
> On Friday 29 May 2015 10:36:37 Peter Humphrey wrote:
> > I had two sets of problems: one in KDE which I might have nailed finally
> > [1], and one at boot time in which /dev/md7 (RAID-1 with metadata > 1.0)
> > was not being started.
> > 
> > [1]	Whenever I've had KMail screw up I've created a new user and
> > re-imported its 14,000 e-mails, and until this latest time I've copied the
> > .mozilla directory from the old user to the new. This time I did not, and
> > so far all looks rosy. I'm not counting any chickens yet though.
> 
> Did you try deleting the akonadi database file(s) and restarting it instead
> of creating a new user?  You will have to be patient, probably let it run
> overnight to asynchronously sync and re-index all your messages.

I don't think I dare risk it:

$ find . -name \*akonadi\* | wc
     49      49    2665
$ find . -name \*akonadi\*dat | wc
     13      13     901

How would I know which to delete and which to leave alone? No, it may be more 
work to start again with a clean slate, but at least I can be confident of not 
screwing anything up too badly.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1776 bytes --]

On Friday 29 May 2015 16:36:59 Peter Humphrey wrote:
> On Friday 29 May 2015 16:19:38 Mick wrote:
> > On Friday 29 May 2015 10:36:37 Peter Humphrey wrote:
> > > I had two sets of problems: one in KDE which I might have nailed
> > > finally [1], and one at boot time in which /dev/md7 (RAID-1 with
> > > metadata > 1.0) was not being started.
> > > 
> > > [1]	Whenever I've had KMail screw up I've created a new user and
> > > re-imported its 14,000 e-mails, and until this latest time I've copied
> > > the .mozilla directory from the old user to the new. This time I did
> > > not, and so far all looks rosy. I'm not counting any chickens yet
> > > though.
> > 
> > Did you try deleting the akonadi database file(s) and restarting it
> > instead of creating a new user?  You will have to be patient, probably
> > let it run overnight to asynchronously sync and re-index all your
> > messages.
> 
> I don't think I dare risk it:
> 
> $ find . -name \*akonadi\* | wc
>      49      49    2665
> $ find . -name \*akonadi\*dat | wc
>      13      13     901
> 
> How would I know which to delete and which to leave alone? No, it may be
> more work to start again with a clean slate, but at least I can be
> confident of not screwing anything up too badly.

This is how I would try it out:

1. Create a back up of your complete /home.
2. akonadictl stop
3. Rename/move ~/.local/share/akonadi/db_data/ (or delete it since you now 
have a back up of this mess).
4. akonadictl start.

Then go and make a brew, because this can take some time.  I have hundreds of 
thousands of messages, so mine takes forever.  I even thought of deleting most 
of my Google messages to accelerate this process, if I ever move to Kmail2.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Friday 29 May 2015 17:02:18 Mick wrote:
> On Friday 29 May 2015 16:36:59 Peter Humphrey wrote:
> > On Friday 29 May 2015 16:19:38 Mick wrote:
> > > On Friday 29 May 2015 10:36:37 Peter Humphrey wrote:
> > > > I had two sets of problems: one in KDE which I might have nailed
> > > > finally [1], and one at boot time in which /dev/md7 (RAID-1 with
> > > > metadata > 1.0) was not being started.
> > > > 
> > > > [1]	Whenever I've had KMail screw up I've created a new user and
> > > > re-imported its 14,000 e-mails, and until this latest time I've copied
> > > > the .mozilla directory from the old user to the new. This time I did
> > > > not, and so far all looks rosy. I'm not counting any chickens yet
> > > > though.
> > > 
> > > Did you try deleting the akonadi database file(s) and restarting it
> > > instead of creating a new user?  You will have to be patient, probably
> > > let it run overnight to asynchronously sync and re-index all your
> > > messages.
> > 
> > I don't think I dare risk it:
> > 
> > $ find . -name \*akonadi\* | wc
> > 
> >      49      49    2665
> > 
> > $ find . -name \*akonadi\*dat | wc
> > 
> >      13      13     901
> > 
> > How would I know which to delete and which to leave alone? No, it may be
> > more work to start again with a clean slate, but at least I can be
> > confident of not screwing anything up too badly.
> 
> This is how I would try it out:
> 
> 1. Create a back up of your complete /home.
> 2. akonadictl stop
> 3. Rename/move ~/.local/share/akonadi/db_data/ (or delete it since you now
> have a back up of this mess).
> 4. akonadictl start.
> 
> Then go and make a brew, because this can take some time.  I have hundreds
> of thousands of messages, so mine takes forever.  I even thought of
> deleting most of my Google messages to accelerate this process, if I ever
> move to Kmail2.

Well, I tried it as you suggested, but I shan't bother again. Not only did it 
not take any apparent time at all to run, but the result was loss of a folder 
tree containing more than half of all my e-mails.

So what worked in KMail-1, it seems, doesn't work in KMail-2.

-- 
Rgds
Peter

Re: [gentoo-user] General weirdness - a tale of woe.

[Peter Humphrey]

On Wednesday 27 May 2015 15:16:35 I wrote:

> Since writing, I've found that my fonts have all changed as well.

Yet more clarity: fonts have not been affected in applications that control 
their own fonts - KMail, Firefox... - but system functions and boinc-mgr 
(which uses whatever fonts are given it) are showing fonts several sizes 
larger than before. When I go to set them back again I find they're set right, 
so one part of KDE thinks fonts are, say, 14 points, and the rest of it thinks 
they're 18 points. How is this possible?

> I'm signed up to the KDE-Linux list already but I see hardly any traffic,

Nothing at all in May, in fact.

> and I suspect dark things about what happens to posts of mine on it.

Paranoia as well as OCPD!

-- 
Rgds
Peter

[gentoo-user] Re: General weirdness - a tale of woe.

[James]

Peter Humphrey <peter <at> prh.myzen.co.uk> writes:

> 
> Hello list,
> 
> Over the last few weeks I've been having odd things go bump in the night.
> This is a KDE amd64 system with /usr under / and no initrd.

> 50 to 55C, which seems normal enough. Could I have something 
> misconfigured in  the kernel?


Well I'm going to share a problem I have right now. If you suffer from it,
it could affect a myriad of different applications with different symptoms.
I do not know if this will help you, but it's work checking into. 


Eselect news list 2015-3-28 lists "True multilib support on amd64"

For me, I run a simple profile:  [1]   default/linux/amd64/13.0 *

Because I run lxde and have experimented with several other minimalistic
desktops, including lxqt. Currently, I run lxde. If I emerge with the --deep
option, I get so much breakage that 3000 lines of scrollback is not enough
to get to the head of the problem. Many errors contain the common string
"abi_x86_32" which is central to the aforementioned news item. I have read
this news item many times, tried many ideas, and still have this phantom
problem.   I can delete some packages had at the update, hours to days,
get it cleaned up to where -D works and a couple of emerge --syncs later
the problem reappears. Global update without (-D) --deep are just fine.


I have no idea if this "phantom issue" relates to yours or not. I have
hesitated to post about it, because in  a decade of gentoo usage (and there
have been some ruff patches to say the least) I have never experienced a
transient recurring problem like this.   I think I need a much longer
version of that news item and some cook_book syntax to fixing these
(phantom) multilb issues on my amd64 systems that I am experiencing. 

Some simple questions::

1. How do you test if indeed a system is multilib?
2. Can a system be change, readily, from multilib to not and then back?
3. Is a more specific profile needed for one where you intend to 
run only a minimalist (lxqt) desktop (than what I listed above)?


Note:: My ultimate goal is minimal desktops (lxqt) on most  systems and
excess  resources pledged (dynamically) to a meso cluster underneath my
gentoo systems.


Comments and guidance are warmly appreciated.
Peter I'm not trying to hijack your thread, but enquire as to commonality.

hth,
James
"

Re: [gentoo-user] Re: General weirdness - a tale of woe.

[Neil Bothwick]

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

On Wed, 27 May 2015 18:38:08 +0000 (UTC), James wrote:

> Eselect news list 2015-3-28 lists "True multilib support on amd64"
> 
> For me, I run a simple profile:  [1]   default/linux/amd64/13.0 *
> 
> Because I run lxde and have experimented with several other minimalistic
> desktops, including lxqt. Currently, I run lxde. If I emerge with the
> --deep option, I get so much breakage that 3000 lines of scrollback is
> not enough to get to the head of the problem. Many errors contain the
> common string "abi_x86_32" which is central to the aforementioned news
> item. I have read this news item many times, tried many ideas, and
> still have this phantom problem.   I can delete some packages had at
> the update, hours to days, get it cleaned up to where -D works and a
> couple of emerge --syncs later the problem reappears. Global update
> without (-D) --deep are just fine.
> 
> 
> I have no idea if this "phantom issue" relates to yours or not. I have
> hesitated to post about it, because in  a decade of gentoo usage (and
> there have been some ruff patches to say the least) I have never
> experienced a transient recurring problem like this.   I think I need a
> much longer version of that news item and some cook_book syntax to
> fixing these (phantom) multilb issues on my amd64 systems that I am
> experiencing. 
> 
> Some simple questions::
> 
> 1. How do you test if indeed a system is multilib?

It is, as you are not using a no-multilib profile.

> 2. Can a system be change, readily, from multilib to not and then back?

No.

> 3. Is a more specific profile needed for one where you intend to 
> run only a minimalist (lxqt) desktop (than what I listed above)?

No, that is a fairly basic profile.

> Comments and guidance are warmly appreciated.
> Peter I'm not trying to hijack your thread, but enquire as to
> commonality.

Your problem is different but has been covered in previous threads, as
well as the news item. You could add ABI_X86="32 64" to make.conf, but
that won't fit in with your desire for minimalism. So you need to run
emerge with --autounmask-write then run etc-update or equivalent to apply
the changes to package.use.


-- 
Neil Bothwick

If someone with multiple personalities threatens to kill himself, is it
considered a hostage situation?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: General weirdness - a tale of woe.

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 3092 bytes --]

On Wednesday 27 May 2015 21:09:27 Neil Bothwick wrote:
> On Wed, 27 May 2015 18:38:08 +0000 (UTC), James wrote:
> > Eselect news list 2015-3-28 lists "True multilib support on amd64"
> > 
> > For me, I run a simple profile:  [1]   default/linux/amd64/13.0 *
> > 
> > Because I run lxde and have experimented with several other minimalistic
> > desktops, including lxqt. Currently, I run lxde. If I emerge with the
> > --deep option, I get so much breakage that 3000 lines of scrollback is
> > not enough to get to the head of the problem. Many errors contain the
> > common string "abi_x86_32" which is central to the aforementioned news
> > item. I have read this news item many times, tried many ideas, and
> > still have this phantom problem.   I can delete some packages had at
> > the update, hours to days, get it cleaned up to where -D works and a
> > couple of emerge --syncs later the problem reappears. Global update
> > without (-D) --deep are just fine.
> > 
> > 
> > I have no idea if this "phantom issue" relates to yours or not. I have
> > hesitated to post about it, because in  a decade of gentoo usage (and
> > there have been some ruff patches to say the least) I have never
> > experienced a transient recurring problem like this.   I think I need a
> > much longer version of that news item and some cook_book syntax to
> > fixing these (phantom) multilb issues on my amd64 systems that I am
> > experiencing.
> > 
> > Some simple questions::
> > 
> > 1. How do you test if indeed a system is multilib?
> 
> It is, as you are not using a no-multilib profile.
> 
> > 2. Can a system be change, readily, from multilib to not and then back?
> 
> No.
> 
> > 3. Is a more specific profile needed for one where you intend to
> > run only a minimalist (lxqt) desktop (than what I listed above)?
> 
> No, that is a fairly basic profile.
> 
> > Comments and guidance are warmly appreciated.
> > Peter I'm not trying to hijack your thread, but enquire as to
> > commonality.
> 
> Your problem is different but has been covered in previous threads, as
> well as the news item. You could add ABI_X86="32 64" to make.conf, but
> that won't fit in with your desire for minimalism. So you need to run
> emerge with --autounmask-write then run etc-update or equivalent to apply
> the changes to package.use.

Only to add that maintainers are regularly updating packages and this is why 
you may find that suddenly new packages require USE="abi_x86_32", when a week 
ago they didn't.

It is worth noting that one multilib box of mine has not asked me (yet) to set  
USE="abi_x86_32" on any of its packages, while my laptop is regularly 
prompting me to do so.  I have concluded that the former has no packages which 
are using 32bit code, while the latter does (I know that at least Skype is a 
culprit).

So in extremis you could I guess purge any 32bit coded packages from your PC 
and the "abi_x86_32" prompts should leave you alone.  I shouldn't forget to 
add your usual disclaimer:  "YMMV"  :-)

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-user] Re: General weirdness - a tale of woe.

[James]

Mick <michaelkintzios <at> gmail.com> writes:

> > Your problem is different but has been covered in previous threads, as
> > well as the news item. You could add ABI_X86="32 64" to make.conf, but
> > that won't fit in with your desire for minimalism. So you need to run
> > emerge with --autounmask-write then run etc-update or equivalent to 
> > apply the changes to package.use.
> 
> Only to add that maintainers are regularly updating packages and this is why 
> you may find that suddenly new packages require USE="abi_x86_32", when a week 
> ago they didn't.
> 
> It is worth noting that one multilib box of mine has not asked me (yet) to
set  
> USE="abi_x86_32" on any of its packages, while my laptop is regularly 
> prompting me to do so.  I have concluded that the former has no packages
which 
> are using 32bit code, while the latter does (I know that at least Skype is a 
> culprit).
> 
> So in extremis you could I guess purge any 32bit coded packages from your PC 
> and the "abi_x86_32" prompts should leave you alone.  I shouldn't forget to 
> add your usual disclaimer:  "YMMV"  
> 

Well, here are my extensions found in the make.conf, of interests::

EMERGE_DEFAULT_OPTS="--with-bdeps y --autounmask-write y"

It been in there a while. However, I must "fess up" that often
it does not work and i have to issue --autounmask-write manually followed up
by etc-update.

Maybe I need to do this all at once, but for @system or something?

I did not want to build all of those 32 bit libraries, but maybe that
is necessary?   How can I get the listing of packages that need those 32 bit
libs? Maybe that the way to go?   It just seems like I keep cleaning this
up over and over again.


James