Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Sun, 23 Dec 2012 19:03:25 +0200
nunojsi...@ist.utl.pt (Nuno J. Silva) wrote:

> On 2012-12-23, Alan McKinnon wrote:
> 
> > On Sun, 23 Dec 2012 12:22:24 +0200
> > nunojsi...@ist.utl.pt (Nuno J. Silva) wrote:
> >
> >> On 2012-12-18, Alan McKinnon wrote:
> >> 
> >> > On Tue, 18 Dec 2012 09:08:53 -0500
> >> > Michael Mol  wrote:
> >> >
> >> >
> >> > This sentence summarizes my understanding of your post nicely:
> >> >
> >> >> Now, why is /usr special? It's because it contains executable
> >> >> code the system might require while launching.
> >> >
> >> > Now there are only two approaches that could solve that problem:
> >> >
> >> > 1. Avoid it entirely
> >> > 2. Deal with it using any of a variety of bootstrap techniques
> >> >
> >> > #1 is handled by policy, whereby any code the system might
> >> > require while launching is not in /usr.
> >> >
> >> > #2 already has a solution, it's called an init*. Other solutions
> >> > exist but none are as elegant as a throwaway temporary filesystem
> >> > in RAM.
> >> 
> >> What about just mounting /usr as soon as the system boots?
> >
> >
> > Please read the thread next time. The topic under discussion is
> > solutions to the problem of not being able to do exactly that.
> 
> Then I suppose you can surely explain in a nutshell why can't init
> scripts simply do that?
> 

It is trivially easy to create a circular loop whereby code required to
mount /usr now resides on /usr.

Which is the entire thrust of this whole thread.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Re: android and mtp

[Nilesh Govindrajan]

On Monday 24 December 2012 09:24:16 AM IST, Grant Edwards wrote:
> On 2012-12-23, luis jure  wrote:
>> on 2012-12-22 at 17:13 Alan McKinnon wrote:
>>
>>> Now, imagine you are the guy at Samsung deciding what features the S2
>>> will support. Which option you gonna pick?
>>
>> yeah, you're right, i guess. but for once i'd like the guys at the
>> corporations to think like me, and not to be forced to think like
>> them...
>
> I'm glad they chose MTP: I want my phone to continue to work while I'm
> transferring files.  In order to mount the filesystem via USB, the
> phone would have to unmount it (which means it's nothing but a flash
> drive).  In order to mount the filesystem via USB, it also means
> they'd be forced to use VFAT for the Linux root filesystem, and that
> sucks bad.
>

They still use VFAT for the so called sdcard (my Xperia S has internal 
storage, not extensible).

--
Nilesh Govindarajan
http://nileshgr.com

Re: [gentoo-user] Re: 3.7.1 SATA errors

[Nilesh Govindrajan]

On Monday 24 December 2012 08:37:50 AM IST, Nikos Chantziaras wrote:
> On 23/12/12 23:00, fe...@crowfix.com wrote:
>> On Sun, Dec 23, 2012 at 10:49:46PM +0200, Nikos Chantziaras wrote:
>>> On 23/12/12 21:23, fe...@crowfix.com wrote:
 A few weeks ago I had a scare when a reboot paniced the kernel with a
 complaint that it could not find the root device (/dev/sde), and
 further reboots couldn't even see the USB keyboard.  Leavng the
 system powered off overnight "fixed" the problem and the system has
 been working fine ever since.
>>>
>>> Do a memtest first.  emerge sys-apps/memtest86+ and then add an entry
>>> for it in Grub:
>>>
>>> title=Memtest86+
>>> root (hd0,0) # <- adapt this to your partition
>>> kernel /boot/memtest86plus/memtest.bin
>>>
>>> Then boot that entry and see if you get any errors in the first 5
>>> minutes or so.
>>
>> Starting the emerge etc.  But why would this be a memory problem when
>> it is so clearly 3.6 vs 3.7?
>
> It's simply an easy check to do and can rule RAM failure out early on.
> When RAM dies, various seemingly unrelated issues can pop up.
>
> But since your RAM seems clean, it's not the issue.
>
>

On an interesting note, I'm on 3.7.1 pf-kernel and uptime is more than 
11 hours. No such issue.

--
Nilesh Govindarajan
http://nileshgr.com

[gentoo-user] Re: android and mtp

[Grant Edwards]

On 2012-12-23, luis jure  wrote:
> on 2012-12-22 at 17:13 Alan McKinnon wrote:
>
>>Now, imagine you are the guy at Samsung deciding what features the S2
>>will support. Which option you gonna pick?
>
> yeah, you're right, i guess. but for once i'd like the guys at the
> corporations to think like me, and not to be forced to think like
> them...

I'm glad they chose MTP: I want my phone to continue to work while I'm
transferring files.  In order to mount the filesystem via USB, the
phone would have to unmount it (which means it's nothing but a flash
drive).  In order to mount the filesystem via USB, it also means
they'd be forced to use VFAT for the Linux root filesystem, and that
sucks bad.

-- 
Grant

[gentoo-user] Re: 3.7.1 SATA errors

[Nikos Chantziaras]

On 23/12/12 23:00, fe...@crowfix.com wrote:

On Sun, Dec 23, 2012 at 10:49:46PM +0200, Nikos Chantziaras wrote:

On 23/12/12 21:23, fe...@crowfix.com wrote:

A few weeks ago I had a scare when a reboot paniced the kernel with a
complaint that it could not find the root device (/dev/sde), and
further reboots couldn't even see the USB keyboard.  Leavng the
system powered off overnight "fixed" the problem and the system has
been working fine ever since.


Do a memtest first.  emerge sys-apps/memtest86+ and then add an entry
for it in Grub:

title=Memtest86+
root (hd0,0) # <- adapt this to your partition
kernel /boot/memtest86plus/memtest.bin

Then boot that entry and see if you get any errors in the first 5
minutes or so.


Starting the emerge etc.  But why would this be a memory problem when
it is so clearly 3.6 vs 3.7?


It's simply an easy check to do and can rule RAM failure out early on. 
When RAM dies, various seemingly unrelated issues can pop up.


But since your RAM seems clean, it's not the issue.

Re: [gentoo-user] problem with lilo and one of my kernels

[covici]

Walter Dnes  wrote:

> On Sat, Dec 22, 2012 at 05:40:05AM -0500, cov...@ccs.covici.com wrote
> > Hi.  Today on one of my test kernels where I am using git bisect to find
> > a bug, I got the following when running lilo:
> > Boot image: /boot/vmlinuz-3.6.0-rc4-00011-g2273929-dirty
> > Fatal: Setup length exceeds 63 maximum; kernel setup will overwrite boot
> > loader
> 
>   See messages #12 and #14 in
> http://www.linuxquestions.org/questions/slackware-14/lilo-setup-length-exceeds-63-maximum%3B-943467/
I think that is where it said to upgrade lilo, but I have the latest
version and no joy.


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] problem with lilo and one of my kernels

[Walter Dnes]

On Sat, Dec 22, 2012 at 05:40:05AM -0500, cov...@ccs.covici.com wrote
> Hi.  Today on one of my test kernels where I am using git bisect to find
> a bug, I got the following when running lilo:
> Boot image: /boot/vmlinuz-3.6.0-rc4-00011-g2273929-dirty
> Fatal: Setup length exceeds 63 maximum; kernel setup will overwrite boot
> loader

  See messages #12 and #14 in
http://www.linuxquestions.org/questions/slackware-14/lilo-setup-length-exceeds-63-maximum%3B-943467/

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Walter Dnes]

On Sun, Dec 23, 2012 at 08:39:41PM +, Neil Bothwick wrote

> You are only considering the case of /usr being on a plain hard disk
> partition, what if it in on an LVM volume, or encrypted (or both)
> of mounted over the network? All of these require something to be
> run before they can be mounted, and if that cannot be run until udev
> has started, we have been painted into a corner.

  I agree that there will always be a small number of corner-cases where
an initr* is required.  What annoys me, and probably a lot of other
people, is the-dog-in-the-manger attitude
http://en.wikipedia.org/wiki/The_Dog_in_the_Manger where some people
seem to say "If my weirdo, corner-case system can't boot a separate /usr
without an initr* then, by-golly, I'll see to it that *NOBODY* can boot
a separate /usr without an initr*".

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: android and mtp

[luis jure]

on 2012-12-22 at 19:55 Daniel Frey wrote:

> I really struggled with my Nexus 7 and mtpfs. I did finally get it to
> work, 

well, it seems i have been very lucky indeed. i just emerged jmtpfs as per
mark's suggestion, and it just worked. i just created a /media/galaxy
directory, and an entry in fstab (like yours, but with jmtpfs instead of
mtpfs) and that was it. now i can simply mount /media/galaxy.

and the best, for those of you using xfce and thunar, in the "multimedia"
tab of preferences -> advanced -> volume manager, i clicked the "portable
music players" check box, and added the command "mount /media/galaxy/".
now when i connect my phablet it is automatically mounted, and i can
umount/eject it from thunar. couldn't be easier, a perfect solution for my
needs!


best,


lj

Re: [gentoo-user] Re: 3.7.1 SATA errors

[felix]

On Sun, Dec 23, 2012 at 10:49:46PM +0200, Nikos Chantziaras wrote:

> Then boot that entry and see if you get any errors in the first 5 
> minutes or so.

Let it run a complete pass, about an hour, no errors.

-- 
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
 Felix Finch: scarecrow repairman & rocket surgeon / fe...@crowfix.com
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

Re: [gentoo-user] Problem installing PHP pdo

[Mike Diehl]

Sounds like I just need to emerge egroupware.

Per your advise, I tried:
emerge --info | grep -i pdo

I did get my USE flag as output, and it looked sane.

Thanks for your help; I'll let you know.

Mike.

"Michael Orlitzky"  wrote:
> On 12/23/2012 04:36 PM, Mike Diehl wrote:
>> Forgive the top-posting, but I think my response will be more concise
this
>> way.
>> 
>> I have pdo in my USE flag in /etc/make.conf, so I thought I had this
>> covered.
>> 
> 
> Does it show up in emerge --info? If not, you might have a typo. If so,
> it's probably some other missing dependency. (Have you re-emerged PHP
> since the USE change?)
> 
> 
>> I'm also not a fan of the netapps mechanism because I put my web-space in
a
>> nonstandard location for ease of backing up.  Also, I probably just don't
>> understand it as well as I'd like.  
>> 
> 
> Nah, it's inflexible.
> 
> 
>> So, I could emerge egroupware and let emerge handle the dependencies for
me.
>>  then I cold just emerge -C and re-install just the application by hand. 
>> Sound right?
>> 
> 
> This will get the dependencies, but once you uninstall egroupware,
> portage won't know why you have them. So if you do an emerge --depclean
> later, they'll come up for removal. Eventually you'll forget why you had
> them, and let it remove something important (personal experience).
> 
> That's why I go to all that trouble with the ebuild in an overlay. A
> simpler workaround would be to install the egroupware from portage, and
> then ignore it but leave it installed.
> 
> 

--

Take care and have fun,
Mike Diehl.

Re: [gentoo-user] Problem installing PHP pdo

[Michael Orlitzky]

On 12/23/2012 04:36 PM, Mike Diehl wrote:
> Forgive the top-posting, but I think my response will be more concise this
> way.
> 
> I have pdo in my USE flag in /etc/make.conf, so I thought I had this
> covered.
> 

Does it show up in emerge --info? If not, you might have a typo. If so,
it's probably some other missing dependency. (Have you re-emerged PHP
since the USE change?)


> I'm also not a fan of the netapps mechanism because I put my web-space in a
> nonstandard location for ease of backing up.  Also, I probably just don't
> understand it as well as I'd like.  
> 

Nah, it's inflexible.


> So, I could emerge egroupware and let emerge handle the dependencies for me.
>  then I cold just emerge -C and re-install just the application by hand. 
> Sound right?
> 

This will get the dependencies, but once you uninstall egroupware,
portage won't know why you have them. So if you do an emerge --depclean
later, they'll come up for removal. Eventually you'll forget why you had
them, and let it remove something important (personal experience).

That's why I go to all that trouble with the ebuild in an overlay. A
simpler workaround would be to install the egroupware from portage, and
then ignore it but leave it installed.

Re: [gentoo-user] Problem installing PHP pdo

[Mike Diehl]

Forgive the top-posting, but I think my response will be more concise this
way.

I have pdo in my USE flag in /etc/make.conf, so I thought I had this
covered.

I'm also not a fan of the netapps mechanism because I put my web-space in a
nonstandard location for ease of backing up.  Also, I probably just don't
understand it as well as I'd like.  

So, I could emerge egroupware and let emerge handle the dependencies for me.
 then I cold just emerge -C and re-install just the application by hand. 
Sound right?

Thanks for such a detailed reply.

Mike.

"Michael Orlitzky"  wrote:
> On 12/23/2012 03:44 PM, Mike Diehl wrote:
>> 
>> I did an emerge -s for pdo and didn't find anything so I followed the
>> directions given on the eGroupware installation guide and ran:
>> 
>> pecl install pdo
>> 
>> Is there an ebuild that I should/could use instead?
>> 
> 
> Yep, it's a USE flag for dev-lang/php. In /etc/portage/package.use, you
> can add,
> 
>   dev-lang/php ... pdo ...
> 
> where the ellipses represent any other USE flags you may have set. The
> re-emerge php with,
> 
>   emerge -1 dev-lang/php
> 
> and it should work, although you may need to restart your web server
first.
> 
> Digression: personally, I don't like Gentoo's webapp framework and I
> don't use the ebuilds for any of the web applications that we run. But,
> egroupware is in portage, as www-apps/egroupware.
> 
> This may make your life easier if you're familiar with webapps under
> Gentoo: you can just emerge it, and it will make sure all of the
> dependencies are satisfied.
> 
> If you *don't* want to go the webapp route, it still makes your life
> easier, since somebody already went to the trouble of figuring out the
> right dependencies. From the ebuild,
> 
>   RDEPEND="jpgraph? ( dev-php/jpgraph )
>dev-php/pear
>dev-php/PEAR-Auth_SASL
>virtual/httpd-php
>dev-lang/php[gd,imap,pdo,posix,session,sqlite,ssl,
>  unicode,xml,zip,zlib,ldap?,mysql?,postgres?]
>virtual/cron"
> 
> You should make sure you have each of these installed for eGroupware to
> work. The stuff in square brackets [] are USE flags, in this case for
> dev-lang/php.
> 
> Since I already mentioned that I don't use the webapp framework, what I
> usually do in a case like this (where something's in portage but I don't
> want to use it) is create my own ebuild just for the dependencies. So
> basically, I would create an ebuild called egroupware-dependencies in an
> overlay, and copy (R)DEPEND from the egroupware ebuild. The rest of the
> ebuild would do nothing.
> 
> Then I emerge it, and it gets added to @world. This prevents someone
> from later removing e.g. dev-php/PEAR-Auth_SASL because they don't know
> what it's for. (That person would be me in, say, a year.)
> 
> 

--

Take care and have fun,
Mike Diehl.

Re: [gentoo-user] Problem installing PHP pdo

[Michael Orlitzky]

On 12/23/2012 03:44 PM, Mike Diehl wrote:
> 
> I did an emerge -s for pdo and didn't find anything so I followed the
> directions given on the eGroupware installation guide and ran:
> 
> pecl install pdo
> 
> Is there an ebuild that I should/could use instead?
> 

Yep, it's a USE flag for dev-lang/php. In /etc/portage/package.use, you
can add,

  dev-lang/php ... pdo ...

where the ellipses represent any other USE flags you may have set. The
re-emerge php with,

  emerge -1 dev-lang/php

and it should work, although you may need to restart your web server first.

Digression: personally, I don't like Gentoo's webapp framework and I
don't use the ebuilds for any of the web applications that we run. But,
egroupware is in portage, as www-apps/egroupware.

This may make your life easier if you're familiar with webapps under
Gentoo: you can just emerge it, and it will make sure all of the
dependencies are satisfied.

If you *don't* want to go the webapp route, it still makes your life
easier, since somebody already went to the trouble of figuring out the
right dependencies. From the ebuild,

  RDEPEND="jpgraph? ( dev-php/jpgraph )
   dev-php/pear
   dev-php/PEAR-Auth_SASL
   virtual/httpd-php
   dev-lang/php[gd,imap,pdo,posix,session,sqlite,ssl,
 unicode,xml,zip,zlib,ldap?,mysql?,postgres?]
   virtual/cron"

You should make sure you have each of these installed for eGroupware to
work. The stuff in square brackets [] are USE flags, in this case for
dev-lang/php.

Since I already mentioned that I don't use the webapp framework, what I
usually do in a case like this (where something's in portage but I don't
want to use it) is create my own ebuild just for the dependencies. So
basically, I would create an ebuild called egroupware-dependencies in an
overlay, and copy (R)DEPEND from the egroupware ebuild. The rest of the
ebuild would do nothing.

Then I emerge it, and it gets added to @world. This prevents someone
from later removing e.g. dev-php/PEAR-Auth_SASL because they don't know
what it's for. (That person would be me in, say, a year.)

Re: [gentoo-user] Re: 3.7.1 SATA errors

[felix]

On Sun, Dec 23, 2012 at 10:49:46PM +0200, Nikos Chantziaras wrote:
> On 23/12/12 21:23, fe...@crowfix.com wrote:
> > A few weeks ago I had a scare when a reboot paniced the kernel with a
> > complaint that it could not find the root device (/dev/sde), and
> > further reboots couldn't even see the USB keyboard.  Leavng the
> > system powered off overnight "fixed" the problem and the system has
> > been working fine ever since.
> 
> Do a memtest first.  emerge sys-apps/memtest86+ and then add an entry 
> for it in Grub:
> 
>title=Memtest86+
>root (hd0,0) # <- adapt this to your partition
>kernel /boot/memtest86plus/memtest.bin
> 
> Then boot that entry and see if you get any errors in the first 5 
> minutes or so.

Starting the emerge etc.  But why would this be a memory problem when
it is so clearly 3.6 vs 3.7?

-- 
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
 Felix Finch: scarecrow repairman & rocket surgeon / fe...@crowfix.com
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

[gentoo-user] Re: 3.7.1 SATA errors

[Nikos Chantziaras]

On 23/12/12 21:23, fe...@crowfix.com wrote:

A few weeks ago I had a scare when a reboot paniced the kernel with a
complaint that it could not find the root device (/dev/sde), and
further reboots couldn't even see the USB keyboard.  Leavng the
system powered off overnight "fixed" the problem and the system has
been working fine ever since.


Do a memtest first.  emerge sys-apps/memtest86+ and then add an entry 
for it in Grub:


  title=Memtest86+
  root (hd0,0) # <- adapt this to your partition
  kernel /boot/memtest86plus/memtest.bin

Then boot that entry and see if you get any errors in the first 5 
minutes or so.

Re: [gentoo-user] Problem installing PHP pdo

[Mike Diehl]

"Michael Orlitzky"  wrote:
> On 12/22/2012 08:55 PM, Mike Diehl wrote:
>> Hi all,
>> 
>> I'm not a PHP programmer, so I'm a bit out of my water.  But, I'm trying
>> to install the latest eGroupware and need to get PHP to support pdo
>> database connectivigy.
>> 
>> After a recent emerge --sync, I did a new emerge of php with --newuse...
>> after adding pdo to my tags list.
>> 
>> What I get is:
>> 
> 
> Can you give us the usual bug report stuff?
> 
>   * emerge --info
>   * emerge -pv 
>   * The command that you ran which failed
>   * The full output of that command
>   * Anything else you think might be relevant

I did an emerge -s for pdo and didn't find anything so I followed the
directions given on the eGroupware installation guide and ran:

pecl install pdo

Is there an ebuild that I should/could use instead?

Mike.
--

Take care and have fun,
Mike Diehl.

Re: [gentoo-user] Problem installing PHP pdo

[Mike Diehl]

"Nilesh Govindrajan"  wrote:
> On Sunday 23 December 2012 07:25:30 AM IST, Mike Diehl wrote:
>> Hi all,
>>
>> I'm not a PHP programmer, so I'm a bit out of my water.  But, I'm
>> trying to install the latest eGroupware and need to get PHP to support
>> pdo database connectivigy.
>>
>> After a recent emerge --sync, I did a new emerge of php with
>> --newuse... after adding pdo to my tags list.
>>
>> What I get is:
>>
>> ...running: make
>> /bin/sh /root/tmp/pear/temp/pear-build-rootFqdFar/PDO-1.0.3/libtool
>> --mode=compile cc  -I. -I/root/tmp/pear/temp/PDO -DPHP_ATOM_INC
>> -I/root/tmp/pear/temp/pear-build-rootFqdFar/PDO-1.0.3/include
>> -I/root/tmp/pear/temp/pear-build-rootFqdFar/PDO-1.0.3/main
>> -I/root/tmp/pear/temp/PDO -I/usr/lib/php5.3/include/php
>> -I/usr/lib/php5.3/include/php/main -I/usr/lib/php5.3/include/php/TSRM
>> -I/usr/lib/php5.3/include/php/Zend -I/usr/lib/php5.3/include/php/ext
>> -I/usr/lib/php5.3/include/php/ext/date/lib  -DHAVE_CONFIG_H  -g -O2
>> -c /root/tmp/pear/temp/PDO/pdo.c -o pdo.lo
>> libtool: compile:  cc -I. -I/root/tmp/pear/temp/PDO -DPHP_ATOM_INC
>> -I/root/tmp/pear/temp/pear-build-rootFqdFar/PDO-1.0.3/include
>> -I/root/tmp/pear/temp/pear-build-rootFqdFar/PDO-1.0.3/main
>> -I/root/tmp/pear/temp/PDO -I/usr/lib/php5.3/include/php
>> -I/usr/lib/php5.3/include/php/main -I/usr/lib/php5.3/include/php/TSRM
>> -I/usr/lib/php5.3/include/php/Zend -I/usr/lib/php5.3/include/php/ext
>> -I/usr/lib/php5.3/include/php/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c
>> /root/tmp/pear/temp/PDO/pdo.c  -fPIC -DPIC -o .libs/pdo.o
>> /bin/sh /root/tmp/pear/temp/pear-build-rootFqdFar/PDO-1.0.3/libtool
>> --mode=compile cc  -I. -I/root/tmp/pear/temp/PDO -DPHP_ATOM_INC
>> -I/root/tmp/pear/temp/pear-build-rootFqdFar/PDO-1.0.3/include
>> -I/root/tmp/pear/temp/pear-build-rootFqdFar/PDO-1.0.3/main
>> -I/root/tmp/pear/temp/PDO -I/usr/lib/php5.3/include/php
>> -I/usr/lib/php5.3/include/php/main -I/usr/lib/php5.3/include/php/TSRM
>> -I/usr/lib/php5.3/include/php/Zend -I/usr/lib/php5.3/include/php/ext
>> -I/usr/lib/php5.3/include/php/ext/date/lib  -DHAVE_CONFIG_H  -g -O2
>> -c /root/tmp/pear/temp/PDO/pdo_dbh.c -o pdo_dbh.lo
>> libtool: compile:  cc -I. -I/root/tmp/pear/temp/PDO -DPHP_ATOM_INC
>> -I/root/tmp/pear/temp/pear-build-rootFqdFar/PDO-1.0.3/include
>> -I/root/tmp/pear/temp/pear-build-rootFqdFar/PDO-1.0.3/main
>> -I/root/tmp/pear/temp/PDO -I/usr/lib/php5.3/include/php
>> -I/usr/lib/php5.3/include/php/main -I/usr/lib/php5.3/include/php/TSRM
>> -I/usr/lib/php5.3/include/php/Zend -I/usr/lib/php5.3/include/php/ext
>> -I/usr/lib/php5.3/include/php/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c
>> /root/tmp/pear/temp/PDO/pdo_dbh.c  -fPIC -DPIC -o .libs/pdo_dbh.o
>> /root/tmp/pear/temp/PDO/pdo_dbh.c: In function 'pdo_stmt_instantiate':
>> /root/tmp/pear/temp/PDO/pdo_dbh.c:410: error: 'zval' has no member
>> named 'refcount'
>> /root/tmp/pear/temp/PDO/pdo_dbh.c:411: error: 'zval' has no member
>> named 'is_ref'
>> /root/tmp/pear/temp/PDO/pdo_dbh.c: In function 'pdo_stmt_construct':
>> /root/tmp/pear/temp/PDO/pdo_dbh.c:435: error: 'zend_fcall_info' has no
>> member named 'object_pp'
>> /root/tmp/pear/temp/PDO/pdo_dbh.c:458: error: 'zend_fcall_info_cache'
>> has no member named 'object_pp'
>> /root/tmp/pear/temp/PDO/pdo_dbh.c: In function 'zim_PDO_setAttribute':
>> /root/tmp/pear/temp/PDO/pdo_dbh.c:752: error: 'zval' has no member
>> named 'refcount'
>> /root/tmp/pear/temp/PDO/pdo_dbh.c: In function 'zim_PDO_getAttribute':
>> /root/tmp/pear/temp/PDO/pdo_dbh.c:818: error: 'zval' has no member
>> named 'refcount'
>> /root/tmp/pear/temp/PDO/pdo_dbh.c: In function 'pdo_hash_methods':
>> /root/tmp/pear/temp/PDO/pdo_dbh.c:1122: warning: assignment discards
>> qualifiers from pointer target type
>> /root/tmp/pear/temp/PDO/pdo_dbh.c:1126: warning: assignment discards
>> qualifiers from pointer target type
>> make: *** [pdo_dbh.lo] Error 1
>> ERROR: `make' failed
>>
===
>>
>>
>> Any idea on how to fix this?
>>
>> Mike.
>> 
>>
>> Take care and have fun,
>> Mike Diehl.
> 
> Which GCC version? Did you do any GCC updates/etc?

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.5
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.5
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.5/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --enable-nls
--without-included-gettext --with-system-zlib --disable-werror
--enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp
--enable-libgomp
--wit

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Neil Bothwick]

On Sun, 23 Dec 2012 19:44:43 +0200, Nuno J. Silva wrote:

> > Because certain people with influence have rearranged the filesystem
> > so that programs within /usr are absolutely necessary for booting;
> > they are needed _before_ init has a chance to mount /usr.  So
> > either /usr has to be in the root partition, or crazy kludges need to
> > be used to mount /usr before the kernel runs init.  
> 
> I surely don't know the udev architecture well enough, but if this is
> all done by the udev daemon, can't we just "mount /usr" before the
> daemon is started? The only needed things should be mount (which is
> under /bin here) and /etc/fstab.

Because before we can mount thye block device containing the filesystem
for /usr, we have to make that block device available. You are
only considering the case of /usr being on a plain hard disk partition,
what if it in on an LVM volume, or encrypted (or both) of mounted over
the network? All of these require something to be run before they can be
mounted, and if that cannot be run until udev has started, we have been
painted into a corner.


-- 
Neil Bothwick

Top Oxymorons Number 43: Genuine imitation


signature.asc
Description: PGP signature

[gentoo-user] 3.7.1 SATA errors

[felix]

A few weeks ago I had a scare when a reboot paniced the kernel with a complaint 
that it could not find the root device (/dev/sde), and further reboots couldn't 
even see the USB keyboard.  Leavng the system powered off overnight "fixed" the 
problem and the system has been working fine ever since.

I have since had some time to explore this and find it related to the kernel; 
3.6.10 works fine, while 3.7.1 fails.  If I reset during the 3.7.1 boot while 
it is spewing its error messages, but before the kernel ultimately panics, I 
can reboot with 3.6.10, but if 3.7.1 goes all the way to the panic, I have to 
power off and wait a few minutes before a 3.6.10 reboot is succesful.  This is 
repeatable, but I haven't bothered to see how long the system must be off; "a 
few minutes" is enough.

This is a ~amd64 system, dual Opterons, Tyan S2882, Thunder K8S Pro.  The dmesg 
times here start around 30 seconds because it spends 15 seconds on each of two 
SCSI hosts probing for nonexistent drives.  udev etc are all frozen pre-systemd 
nonsense.  Disks are two SSDs, two 4T drives, two 300G drives, and one 320G 
IDE/PATA drive; the main board is so old that there are only three boot 
options: IDE, DVD, network.

There are two error messages during the 3.7.1 boot, repeated for all SATA 
drives:

ata5.00: qc timeout (cmd 0x2f)
ata5.00: failed to set xfermode (err_mask=0x40)

Google does not enlighten me.  One suggestion was change the SATA cable, but 
this is definitely a change from 3.6.10 to 3.7.1.

So here are some details ... You can see everything at 
https://www.dropbox.com/sh/o8j80rps3agvvcf/FBjJLcykRS

I am willing to try reasonable config changes for a new reboot attempt, but it 
is my main home server, not an experimental toy :-)

 dmesg differences

I took some pictures during the boot process and transcribed the results.  The 
3.6.10 dmesg matches, but of course I can't get a 3.7.1 dmesg.

Both 3.6.10 and 3.7.1 appear to be the same up to this point:

ata13.00: ATA-8: WDC WD3200AAJB-00J3A0, 01.03E01, max UDMA/133
ata13.00: 625142448 sectors, multi 16: LBA48
ata13.00: configured for UDMA/133
ata1: SATA link down (SStatus 0 SControl 300)
ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata9.00: ATA-9: M4-CT512M4SD2, 000F, max UDMA/100
ata9.00: 1000215216 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata9.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 300)
ata3: SATA link down (SStatus 0 SControl 300)
ata4: SATA link down (SStatus 0 SControl 300)
ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata5.00: ATA-7: Maxtor 6B300S0, BANC17M0, max UDMA/133
ata5.00: 586114704 sectors, multi 0: LBA48 NCQ (not used)

Around here 3.6.10 begins scrolling so fast that I could not get any pictures, 
so this is from the 3.6.10 dmesg, where it diverges from 3.7.1:

ata5.00: configured for UDMA/133
scsi 6:0:0:0: Direct-Access ATA  Maxtor 6B300S0   BANC PQ: 0 ANSI: 5
sd 6:0:0:0: [sda] 586114704 512-byte logical blocks: (300 GB/279 GiB)
sd 6:0:0:0: [sda] Write Protect is off
sd 6:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 6:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA
 sda:
sd 6:0:0:0: [sda] Attached SCSI disk
ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata6.00: ATA-7: Maxtor 6B300S0, BANC17M0, max UDMA/133
ata6.00: 586114704 sectors, multi 0: LBA48 NCQ (not used)
ata6.00: configured for UDMA/133
scsi 7:0:0:0: Direct-Access ATA  Maxtor 6B300S0   BANC PQ: 0 ANSI: 5
sd 7:0:0:0: [sdb] 586114704 512-byte logical blocks: (300 GB/279 GiB)
sd 7:0:0:0: [sdb] Write Protect is off
sd 7:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 7:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA
 sdb: unknown partition table
sd 7:0:0:0: [sdb] Attached SCSI disk
 and on and on until it boots.  (The unknown partition table is an LVM 
volume.)

But 3.7.1 pokes along slowly enough while generating its errors that I did get 
some pictures to transcribe, and this is where it diverges from 3.6.10.

ata5.00: qc timeout (cmd 0x2f)
ata5.00: failed to set xfermode (err_mask=0x40)
ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata5.00: qc timeout (cmd 0x2f)
ata5.00: failed to set xfermode (err_mask=0x40)
ata5: limiting SATA link speed to 1.5 Gbps
ata5.00: limiting speed to UDMA/133:PIO3
ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata5.00: qc timeout (cmd 0x2f)
ata5.00: failed to set xfermode (err_mask=0x40)
ata5.00: disabled
ata5: hard resetting link
ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata5: EH complete
... for all ATA drives until it eventually panics because the root device, 
/dev/sde, is not found.


 3.6.10 ---> 3.7.1 conf changes

I rebuilt the 3.7.1 kernel and logged 

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-23, Michael Mol wrote:

> On Dec 23, 2012 12:46 PM, "Nuno J. Silva"  wrote:
>>
>> On 2012-12-23, Alan Mackenzie wrote:
>>
>> > On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
>> >> On 2012-12-23, Alan McKinnon wrote:
>> >
>> >> > On Sun, 23 Dec 2012 12:22:24 +0200
>> >> > nunojsi...@ist.utl.pt (Nuno J. Silva) wrote:
>> >
>> >> >> On 2012-12-18, Alan McKinnon wrote:
>> >
>> >> >> > On Tue, 18 Dec 2012 09:08:53 -0500
>> >> >> > Michael Mol  wrote:
>> >
>> >
>> >> >> > This sentence summarizes my understanding of your post nicely:
>> >
>> >> >> >> Now, why is /usr special? It's because it contains executable
> code
>> >> >> >> the system might require while launching.
>> >
>> >> >> > Now there are only two approaches that could solve that problem:
>> >
>> >> >> > 1. Avoid it entirely
>> >> >> > 2. Deal with it using any of a variety of bootstrap techniques
>> >
>> >> >> > #1 is handled by policy, whereby any code the system might require
>> >> >> > while launching is not in /usr.
>> >
>> >> >> > #2 already has a solution, it's called an init*. Other solutions
>> >> >> > exist but none are as elegant as a throwaway temporary filesystem
>> >> >> > in RAM.
>> >
>> >> >> What about just mounting /usr as soon as the system boots?
>> >
>> >
>> >> > Please read the thread next time. The topic under discussion is
>> >> > solutions to the problem of not being able to do exactly that.
>> >
>> >> Then I suppose you can surely explain in a nutshell why can't init
>> >> scripts simply do that?
>> >
>> > Because certain people with influence have rearranged the filesystem so
>> > that programs within /usr are absolutely necessary for booting; they are
>> > needed _before_ init has a chance to mount /usr.  So either /usr has to
>> > be in the root partition, or crazy kludges need to be used to mount /usr
>> > before the kernel runs init.
>>
>> I surely don't know the udev architecture well enough, but if this is
>> all done by the udev daemon, can't we just "mount /usr" before the
>> daemon is started? The only needed things should be mount (which is
>> under /bin here) and /etc/fstab.
>>
>> Or is something outside udev needing stuff under /usr?
>
> Yes. That's the pivot of the problem.

What is it?

I tried and I was able to mount a filesystem other than / shortly after
linux has passed control to init, in fact, with no udev stuff running.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Dec 23, 2012 12:46 PM, "Nuno J. Silva"  wrote:
>
> On 2012-12-23, Alan Mackenzie wrote:
>
> > On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
> >> On 2012-12-23, Alan McKinnon wrote:
> >
> >> > On Sun, 23 Dec 2012 12:22:24 +0200
> >> > nunojsi...@ist.utl.pt (Nuno J. Silva) wrote:
> >
> >> >> On 2012-12-18, Alan McKinnon wrote:
> >
> >> >> > On Tue, 18 Dec 2012 09:08:53 -0500
> >> >> > Michael Mol  wrote:
> >
> >
> >> >> > This sentence summarizes my understanding of your post nicely:
> >
> >> >> >> Now, why is /usr special? It's because it contains executable
code
> >> >> >> the system might require while launching.
> >
> >> >> > Now there are only two approaches that could solve that problem:
> >
> >> >> > 1. Avoid it entirely
> >> >> > 2. Deal with it using any of a variety of bootstrap techniques
> >
> >> >> > #1 is handled by policy, whereby any code the system might require
> >> >> > while launching is not in /usr.
> >
> >> >> > #2 already has a solution, it's called an init*. Other solutions
> >> >> > exist but none are as elegant as a throwaway temporary filesystem
> >> >> > in RAM.
> >
> >> >> What about just mounting /usr as soon as the system boots?
> >
> >
> >> > Please read the thread next time. The topic under discussion is
> >> > solutions to the problem of not being able to do exactly that.
> >
> >> Then I suppose you can surely explain in a nutshell why can't init
> >> scripts simply do that?
> >
> > Because certain people with influence have rearranged the filesystem so
> > that programs within /usr are absolutely necessary for booting; they are
> > needed _before_ init has a chance to mount /usr.  So either /usr has to
> > be in the root partition, or crazy kludges need to be used to mount /usr
> > before the kernel runs init.
>
> I surely don't know the udev architecture well enough, but if this is
> all done by the udev daemon, can't we just "mount /usr" before the
> daemon is started? The only needed things should be mount (which is
> under /bin here) and /etc/fstab.
>
> Or is something outside udev needing stuff under /usr?

Yes. That's the pivot of the problem.

>
> --
> Nuno Silva (aka njsg)
> http://njsg.sdf-eu.org/
>
>

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-23, Alan Mackenzie wrote:

> On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
>> On 2012-12-23, Alan McKinnon wrote:
>
>> > On Sun, 23 Dec 2012 12:22:24 +0200
>> > nunojsi...@ist.utl.pt (Nuno J. Silva) wrote:
>
>> >> On 2012-12-18, Alan McKinnon wrote:
>
>> >> > On Tue, 18 Dec 2012 09:08:53 -0500
>> >> > Michael Mol  wrote:
>
>
>> >> > This sentence summarizes my understanding of your post nicely:
>
>> >> >> Now, why is /usr special? It's because it contains executable code
>> >> >> the system might require while launching.
>
>> >> > Now there are only two approaches that could solve that problem:
>
>> >> > 1. Avoid it entirely
>> >> > 2. Deal with it using any of a variety of bootstrap techniques
>
>> >> > #1 is handled by policy, whereby any code the system might require
>> >> > while launching is not in /usr.
>
>> >> > #2 already has a solution, it's called an init*. Other solutions
>> >> > exist but none are as elegant as a throwaway temporary filesystem
>> >> > in RAM.
>
>> >> What about just mounting /usr as soon as the system boots?
>
>
>> > Please read the thread next time. The topic under discussion is
>> > solutions to the problem of not being able to do exactly that.
>
>> Then I suppose you can surely explain in a nutshell why can't init
>> scripts simply do that?
>
> Because certain people with influence have rearranged the filesystem so
> that programs within /usr are absolutely necessary for booting; they are
> needed _before_ init has a chance to mount /usr.  So either /usr has to
> be in the root partition, or crazy kludges need to be used to mount /usr
> before the kernel runs init.

I surely don't know the udev architecture well enough, but if this is
all done by the udev daemon, can't we just "mount /usr" before the
daemon is started? The only needed things should be mount (which is
under /bin here) and /etc/fstab.

Or is something outside udev needing stuff under /usr?

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

[gentoo-user] Re: ALSA mixer as a capture device with Intel HDA cards

[»Q«]

On Sun, 23 Dec 2012 01:59:50 +0200
nunojsi...@ist.utl.pt (Nuno J. Silva) wrote:

> Hello,
> 
> Today, I got a bit curious, and wanted to get some sound from a
> computer which does not have any speakers at the moment. Mostly for
> fun, I thought about using arecord and then listening to the file.
> 
> I decided to have a look around the mixer, with no luck.  I remember
> alsamixer showing an option to use the PCM mixer as a capture device,
> but this was with other, older cards (possibly an ESS Maestro or a
> Creative Enqsonic). Now, for this "Intel HDA" card, I don't see an
> option to select the card's own output as the input stream.
> 
> From what I see, I'd simply assume this means the new card does not
> have support for this in the hardware mixer, but I wonder whether I'm
> missing something obvious. The card is listed, in lspci, as 
> 
>Audio device: NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High
>Definition Audio (rev a1)
> 
> And alsamixer lists it as 
> 
>Card: HDA NVidia
>Chip: Realtek ALC887  
> 
> Any hints? 

I have exactly same question/problem, but with Realtek ALC275, not
on an nVidia card.  As far as I can tell, I only have one capture option
in alsamixer, and toggling it on only captures sound picked up by the
microphone.

Here's my output of amixer: 

And a screenshot of alsamixer's capture settings:

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan Mackenzie]

On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote:
> On 2012-12-23, Alan McKinnon wrote:

> > On Sun, 23 Dec 2012 12:22:24 +0200
> > nunojsi...@ist.utl.pt (Nuno J. Silva) wrote:

> >> On 2012-12-18, Alan McKinnon wrote:

> >> > On Tue, 18 Dec 2012 09:08:53 -0500
> >> > Michael Mol  wrote:


> >> > This sentence summarizes my understanding of your post nicely:

> >> >> Now, why is /usr special? It's because it contains executable code
> >> >> the system might require while launching.

> >> > Now there are only two approaches that could solve that problem:

> >> > 1. Avoid it entirely
> >> > 2. Deal with it using any of a variety of bootstrap techniques

> >> > #1 is handled by policy, whereby any code the system might require
> >> > while launching is not in /usr.

> >> > #2 already has a solution, it's called an init*. Other solutions
> >> > exist but none are as elegant as a throwaway temporary filesystem
> >> > in RAM.

> >> What about just mounting /usr as soon as the system boots?


> > Please read the thread next time. The topic under discussion is
> > solutions to the problem of not being able to do exactly that.

> Then I suppose you can surely explain in a nutshell why can't init
> scripts simply do that?

Because certain people with influence have rearranged the filesystem so
that programs within /usr are absolutely necessary for booting; they are
needed _before_ init has a chance to mount /usr.  So either /usr has to
be in the root partition, or crazy kludges need to be used to mount /usr
before the kernel runs init.

> -- 
> Nuno Silva (aka njsg)
> http://njsg.sdf-eu.org/

-- 
Alan Mackenzie (Nuremberg, Germany).

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-23, Alan McKinnon wrote:

> On Sun, 23 Dec 2012 12:22:24 +0200
> nunojsi...@ist.utl.pt (Nuno J. Silva) wrote:
>
>> On 2012-12-18, Alan McKinnon wrote:
>> 
>> > On Tue, 18 Dec 2012 09:08:53 -0500
>> > Michael Mol  wrote:
>> >
>> >
>> > This sentence summarizes my understanding of your post nicely:
>> >
>> >> Now, why is /usr special? It's because it contains executable code
>> >> the system might require while launching.
>> >
>> > Now there are only two approaches that could solve that problem:
>> >
>> > 1. Avoid it entirely
>> > 2. Deal with it using any of a variety of bootstrap techniques
>> >
>> > #1 is handled by policy, whereby any code the system might require
>> > while launching is not in /usr.
>> >
>> > #2 already has a solution, it's called an init*. Other solutions
>> > exist but none are as elegant as a throwaway temporary filesystem
>> > in RAM.
>> 
>> What about just mounting /usr as soon as the system boots?
>
>
> Please read the thread next time. The topic under discussion is
> solutions to the problem of not being able to do exactly that.

Then I suppose you can surely explain in a nutshell why can't init
scripts simply do that?

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Alan McKinnon]

On Sun, 23 Dec 2012 12:22:24 +0200
nunojsi...@ist.utl.pt (Nuno J. Silva) wrote:

> On 2012-12-18, Alan McKinnon wrote:
> 
> > On Tue, 18 Dec 2012 09:08:53 -0500
> > Michael Mol  wrote:
> >
> >
> > This sentence summarizes my understanding of your post nicely:
> >
> >> Now, why is /usr special? It's because it contains executable code
> >> the system might require while launching.
> >
> > Now there are only two approaches that could solve that problem:
> >
> > 1. Avoid it entirely
> > 2. Deal with it using any of a variety of bootstrap techniques
> >
> > #1 is handled by policy, whereby any code the system might require
> > while launching is not in /usr.
> >
> > #2 already has a solution, it's called an init*. Other solutions
> > exist but none are as elegant as a throwaway temporary filesystem
> > in RAM.
> 
> What about just mounting /usr as soon as the system boots?


Please read the thread next time. The topic under discussion is
solutions to the problem of not being able to do exactly that.


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Suspend to ram problems

[Volker Armin Hemmann]

and without all that pm stuff - just echo mem > /sys/power/state
?
-- 
#163933

[gentoo-user] Suspend to ram problems

[Jacques Montier]

Hi all,

I upgraded from 3.5.7 to 3.6.11 kernel gentoo-sources and everything works
fine except suspend to ram process.

My configuration : Two hard drives sda (HDD) and sdb (SSD)

Everything works fine with 3.5.7 kernel gentoo-sources

With pm-suspend, the system seems to suspend fine, but with the power on
again, i get :
- black screen, then XFCE desktop appears but nothing is working anymore.
for example : ls, /usr/bin/firefox, etc.. gives I/O error message.

- If i switch to a terminal with : CTRL + ALT + F1, i can't execute
/sbin/shutdown.

- So -> reset.

- In /var/log/pm-powersave.log, i noticed some error lines :

Disabling hard drive power management for /dev/sda...Failed.
Disabling hard drive power management for /dev/sdb...Failed.

--

/usr/lib64/pm-utils/power.d/pcie_aspm: line 9: echo: write error: Operation
not permitted

/usr/sbin/pm-powersave: ligne72: /usr/bin/on_ac_power: Erreur
d'entrée/sortie

---

Enabling power management for /dev/sda...Done.
Enabling power management for /dev/sdb...Failed.



Setting journal commit time for / to
600.../usr/lib64/pm-utils/power.d/journal-commit : ligne 24 :  5024 Erreur
du bus   mount -o remount,$2 $1
Failed.


In pm-suspend.log, i get :

/usr/lib64/pm-utils/sleep.d/99video: ligne97: /usr/bin/deallocvt: Erreur
d'entrée/sortie


What's going on ?

Thank you for your help,

Merry Christmas to all of you !

Regards,

--
Jacques

Re: [gentoo-user] How broken is my raid device /dev/md6?

[Alan Mackenzie]

On Sat, Dec 22, 2012 at 03:24:53PM +0100, Volker Armin Hemmann wrote:
> Am Samstag, 22. Dezember 2012, 13:53:42 schrieb Alan Mackenzie:
> > Hi, all.

> > Just built kernel 3.6.11 and when I tried to install it with lilo, I got
> > this difficult error message:

> > Fatal: Trying to map files from unnamed device 0x (NFS/RAID
> > mirror down ?)

> > .  So I eventually had a look at dmesg for my raid setup, and found this
> > - note lines 15 - 19:

> > [2.148410] md: Waiting for all devices to be available before
> >  autodetect
> > [2.149891] md: If you don't use raid, use raid=noautodetect
> > [2.151546] md: Autodetecting RAID arrays.
> > [2.180356] md: Scanned 4 and added 4 devices.
> > [2.181819] md: autorun ...
> > [2.183244] md: considering sdb6 ...
> > [2.184666] md:  adding sdb6 ...
> > [2.186079] md: sdb3 has different UUID to sdb6
> > [2.187492] md:  adding sda6 ...
> > [2.14] md: sda3 has different UUID to sdb6
> > [2.190484] md: created md6
> > [2.191883] md: bind
> > [2.193224] md: bind
> > [2.194538] md: running: 
> > 15  [2.195855] md: kicking non-fresh sda6 from array!
> > 16  [2.197154] md: unbind
> > 17  [2.205840] md: export_rdev(sda6)
> > [2.207176] bio: create slab  at 1
> > 19  [2.208520] md/raid1:md6: active with 1 out of 2 mirrors
> > [2.209835] md6: detected capacity change from 0 to 34359672832
> > [2.211187] md: considering sdb3 ...
> > [2.212444] md:  adding sdb3 ...
> > [2.213691] md:  adding sda3 ...
> > [2.215117] md: created md3
> > [2.216349] md: bind
> > [2.217569] md: bind
> > [2.218765] md: running: 
> > [2.220025] md/raid1:md3: active with 2 out of 2 mirrors
> > [2.221231] md3: detected capacity change from 0 to 429507543040
> > [2.222508] md: ... autorun DONE.
> > [2.230821]  md6: unknown partition table

> > .  Further perusal of a log file showed this error first happened on
> > 2012-11-29.  It would appear /dev/md6 has been firing on one cylinder
> > ever since, and I've been unaware of this.  :-(

> > What does it mean for sda6 to be "non-fresh"?

> > /dev/md6 is my root partition (including /usr :-(), so I can't unmount
> > it for investigation.

> > Could somebody please suggest how I might go about repairing this
> > problem.

> boot from systemrescuecd
> mdadm -S /dev/md6
> mdadm -A /dev/md6

This didn't quite work, since mdadm -A merely restarted the array without
the non-fresh partition.  Still it got me searching, and what eventually
worked was  mdadm /dev/md6 -a /dev/sda6.  (Where -a stands for "add".)
The mdadm man page is very vague for this use case.


> get some coffee. Make some popcorn. The resync will take some while.

Indeed it did.  The coffee settled me down somewhat.  Thanks again!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] android and mtp

[luis jure]

on 2012-12-22 at 22:57 Neil Bothwick wrote:

> I tried it and soon uninstalled it. Not only does it only allow access to
> the SD card (the internal storage can't be unmounted) but even that was
> unreliable. 

well, that's good to know. by now i already have my phone rooted :-) but
things seem to be working with jmtpfs, so i might just leave it at that.

Re: [gentoo-user] android and mtp

[luis jure]

on 2012-12-22 at 17:13 Alan McKinnon wrote:

>Now, imagine you are the guy at Samsung deciding what features the S2
>will support. Which option you gonna pick?

yeah, you're right, i guess. but for once i'd like the guys at the
corporations to think like me, and not to be forced to think like them...

[gentoo-user] Re: slideshow on USB stick

[Nuno J. Silva]

On 2012-12-19, Joseph wrote:

> Is it possible to create slide show (pictures) on USB stick and play on a TV?
>
> In the past I've used "dvd-slideshow" but that is a bit of work.  I had to 
> re-size the pictures add background music etc.
> DVD only holds 4GB USB sticks have larger capacity.

It depends a lot on the TVs you want to play the slideshow in. If it's a
specific TV, you can just check what does it support. I've seen some LG
TVs which were able to browse photos on USB mass storage devices, and
they probably had a slideshow feature, although I've never tried that.

If you're aiming at broader support, your best chance is really some
widely supported set of settings like DVD-Video, because some table DVD
players (and TVs too, I guess) will be picky regarding framerate, frame
size, codec and other settings. 

For example, technically you could grab some file container and codec,
set the framerate to the time you want between photos and just use the
photos as the video frames (I think ffmpeg allows you to do this, but
some containers have problems with exotic framerates). But I guess many
TV and table DVD players out there would just refuse to play that.

One thing, though, is that what only holds ~4GB is *a specific* format
of DVD media, there are DVDs with larger capacities, and I'd not be
surprised if the size was not restricted at all by the DVD-Video
standard (the file format, filesystem structure and codec
specifications, not the physical medium specifications).

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-20, Volker Armin Hemmann wrote:

> Am Donnerstag, 20. Dezember 2012, 11:45:34 schrieb Mark David Dumlao:
>
>> 3) Most software packagers write their binaries to a PREFIX defaulting
>> to /usr/local, or /usr, as opposed to /. Determining which ones belong
>> in / or /usr can sometimes be dependent on the distro and/or sysad.
>> But since more of them default to /usr, if everything were in /usr
>> it'd be a saner default.
>
> so what? PREFIX can be changed. Set it to /local if you want. Or /var/local. 
> Or /my/happy/place/local. 

Ironically, I think /usr may make for a good /usr/local, as usr could
easily stand for "user-installed software". If that wasn't already the
purpose in some earlier unices...

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

[gentoo-user] Re: Anyone switched to eudev yet?

[Nuno J. Silva]

On 2012-12-18, Alan McKinnon wrote:

> On Tue, 18 Dec 2012 09:08:53 -0500
> Michael Mol  wrote:
>
>
> This sentence summarizes my understanding of your post nicely:
>
>> Now, why is /usr special? It's because it contains executable code the
>> system might require while launching.
>
> Now there are only two approaches that could solve that problem:
>
> 1. Avoid it entirely
> 2. Deal with it using any of a variety of bootstrap techniques
>
> #1 is handled by policy, whereby any code the system might require
> while launching is not in /usr.
>
> #2 already has a solution, it's called an init*. Other solutions exist
> but none are as elegant as a throwaway temporary filesystem in RAM.

What about just mounting /usr as soon as the system boots?



-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/