Re: [gentoo-user] General weirdness - a tale of woe.
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 492665 $ 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.
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] General weirdness - a tale of woe.
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.
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] General weirdness - a tale of woe.
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.
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.mckin...@gmail.com
Re: [gentoo-user] General weirdness - a tale of woe.
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 pgpGJSh7UGOUP.pgp Description: OpenPGP digital signature
Re: [gentoo-user] General weirdness - a tale of woe.
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] General weirdness - a tale of woe.
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.
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.
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. pgpCaNSKdenPR.pgp Description: OpenPGP digital signature
Re: [gentoo-user] General weirdness - a tale of woe.
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.
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.
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.
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 492665 $ 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.
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] General weirdness - a tale of woe.
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] General weirdness - a tale of woe.
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 492665 $ 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] General weirdness - a tale of woe.
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.
On Thu, May 28, 2015 at 1:03 PM, Peter Humphrey pe...@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.
On Thursday 28 May 2015 19:51:24 Rich Freeman wrote: On Thu, May 28, 2015 at 1:03 PM, Peter Humphrey pe...@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.
On Wed, May 27, 2015 at 8:01 PM, Peter Humphrey pe...@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.
* Rich Freeman ri...@gentoo.org [150528 08:45]: On Wed, May 27, 2015 at 8:01 PM, Peter Humphrey pe...@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.
On Thursday 28 May 2015 08:44:27 Rich Freeman wrote: On Wed, May 27, 2015 at 8:01 PM, Peter Humphrey pe...@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.
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.
On 27/05/2015 14:31, Canek Peláez Valdés wrote: On Wed, May 27, 2015 at 6:59 AM, Peter Humphrey pe...@prh.myzen.co.uk mailto:pe...@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.mckin...@gmail.com
Re: [gentoo-user] General weirdness - a tale of woe.
On Wed, May 27, 2015 at 8:02 AM, Alan McKinnon alan.mckin...@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 pe...@prh.myzen.co.uk mailto:pe...@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
[gentoo-user] General weirdness - a tale of woe.
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.
On Wed, May 27, 2015 at 6:59 AM, Peter Humphrey pe...@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
Re: [gentoo-user] General weirdness - a tale of woe.
On Wed, May 27, 2015 at 7:59 AM, Peter Humphrey pe...@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.
On Wednesday 27 May 2015 09:21:37 Rich Freeman wrote: On Wed, May 27, 2015 at 7:59 AM, Peter Humphrey pe...@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/portageext4 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.
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 pe...@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/portageext4 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
Re: [gentoo-user] General weirdness - a tale of woe.
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.
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
