Re: [gentoo-user] WARNING: Crucial MX300 drives SUUUUUCK!!!!

[Poison BL.]

On Mon, Feb 13, 2017 at 4:49 PM, Mick  wrote:

> On Monday 13 Feb 2017 13:17:14 Poison BL. wrote:
> > On Mon, Feb 13, 2017 at 11:44 AM, Daniel Frey  wrote:
> > > On 02/12/2017 02:40 PM, Alan Grimes wrote:
> > > > So does anyone have any evidence of a current generation SSD lasting
> > > > more than 20 days?
> > >
> > > I have tried various SSDs (multiple brands and generations) over the
> > > last maybe five years and found that they're very unreliable (multiple
> > > brands too.)
> > >
> > > I know everyone's saying these things are reliable but out of four SSDs
> > > I own, I've had to replace three, some more than once.
> > >
> > > I just don't use them for anything I want to stay working. Right now I
> > > keep them in my mythtv frontends as I can restore the OS easily. One
> one
> > > of them the company involved (Kingston) even sent me a newer
> drive/model
> > > as it was replaced more than once.
> > >
> > > I know they're fast. But what's the point of going 500 MPH and crashing
> > > into a mountain with no chance of repair/recovery. I went back to a
> > > (relatively) slower rust raid10, and it's been reliable for the last
> > > four years. At least with a hard drive failure, you stand /some/ chance
> > > at recovery, not zero.
> > >
> > > The one SSD that hasn't had to have been replaced under warranty is in
> > > my laptop which I generally use maybe a dozen times a year. I fully
> > > expect it to die one of these times when I boot the laptop (it's one of
> > > the old models.)
> > >
> > > My experiences are with Samsung, Kingston, Intel, Crucial and AData
> > > SSDs. The last one I bought because these things I view as throwaway
> > > devices (the warranty expired on the original Crucial) and don't want
> to
> > > spend big money on them. I have noticed the AData SSD's performance is
> > > not as fast now as it was new (maybe 1.5 years ago?) So it'll probably
> > > pack it in soon too.
> > >
> > > Dan
> >
> > I've had more than one spinning rust drive fail hard over the years as
> > well, though yes, you do usually have some chance of recovery from those.
> > Gambling on that chance by leaving a given disk as a single point of
> > failure is still a bad idea, spinning disk or not. The point that you
> went
> > from single-disk SSD back to raid10 makes me question why, if your uptime
> > requirements (even if only for your own desires on a personal machine)
> > justify raid10, you weren't on at least raid1 with the SSD setup.
> >
> > As for performance degredation on SSDs, that I've definitely seen on
> pretty
> > much every brand, though I've had good luck doing clean reloads on
> samsungs
> > once or twice to get speeds back up some (somehow, even trim doesn't seem
> > to keep things at their best).
> >
> > I can't say they're more or less reliable than spinning disks, though
> they
> > do have the benefit of no moving parts to wear out over time (thermal
> > cycles can still cause a physical failure on them, though).
>
> Have you noticed a difference between mounting partitions on them with the
> discard option, Vs running fstrim on a cron job?
> --
> Regards,
> Mick


I actually only have one (exceptionally cheap, and little used) in a linux
box at all, and haven't tested with anything other than having discard set.
I sadly have to live the windows life on all my work machines :(

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] Building a new root for my Gentoo: Permission denied?

[Johannes Rosenberger]

On 13.02.2017 19:20, meino.cra...@gmx.de wrote:
> Johannes Rosenberger  [17-02-13 19:04]:
>> On 13.02.2017 17:57, meino.cra...@gmx.de wrote:
>>
>>> Hogren  [17-02-13 17:06]:
 On 13/02/2017 04:42, meino.cra...@gmx.de wrote:
> Hi,
>
> got a mysterious error message this morning (still building a new 
> root...)
>
> One of the updates was gnutls:
> It ends with:
> ...
> checking for i686-pc-linux-gnu-pkg-config... 
> /usr/bin/i686-pc-linux-gnu-pkg-config
> checking pkg-config is at least version 0.9.0... 
> /var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9/configure: line 
> 5020: /usr/bin/i686-pc-linux-gnu-pkg-config: Permission denied
> no
> checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... configure: error: in 
> `/var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9-abi_x86_32.x86':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> ...
>
> I tried:
> computer# ldd /usr/bin/i686-pc-linux-gnu-pkg-config
>   not a dynamic executable
> computer# /usr/bin/i686-pc-linux-gnu-pkg-config 
> zsh: permission denied: /usr/bin/i686-pc-linux-gnu-pkg-config
>
> computer# file /usr/bin/i686-pc-linux-gnu-pkg-config
> /usr/bin/i686-pc-linux-gnu-pkg-config: ELF 32-bit LSB executable, Intel 
> 80386, version 1 (SYSV), dynamically linked, interpreter 
> /lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped, with debug_info
>
> I choosed multilib right from the beginning of this adventure ...
>
> How can I check, whether the problem is caysed by gnutls or by the 
> system setup (regarding 32bit)?
>
> Cheers
> Meino
>
>
>
>
>
 Hello,

 Can you give us more details of what do you want to do, what do you
 already do, etc.

 Does /usr/bin/i686-pc-linux-gnu-pkg-config have the x (executable) 
 permission ? (ls -l /usr/bin/i686-pc-linux-gnu-pkg-config)



 Hogren




>>> More mysterious hickups:
>>>
>> Regenerating /etc/ld.so.cache...
>>> /sbin/ldconfig: File /lib64/ld-linux.so.2 is empty, not checked.
>>>
>>> Did it screwed up my new root?
>>>
>>> Cheers
>>> Meino
>>>
>>>
>>>
>>>
>> Maybe. But maybe it is fixable. /lib64/ld-linux.so.2 is a symlink to
>> glibc. But glibc cannot be wholly broken because if it were, then
>> nothing would work at all.
>>
>> I'd first investigate if only the symlink needs to be fixed (should
>> point to /lib/ld-.so).
>>
>> Have you updated glibc recently?Or any other important package/package
>> from @system?
>> Have you tried if 'revdep-rebuild' finds any broken libraries?
>>
>> If glibc is really broken you can
>>
>> 1. chroot into a stage3
>> 2. build a binpkg (type 'quickpkg glibc')
>> 3. copy the binpkg from
>> '/usr/portage/packages/sys-libs/glibc-*.tbz2' in the stage3 to
>>the same directory in your new root
>> 4. install the binary glibc ('emerge ')
>>
>> Then you should have a clean glibc install.
>>
>> If you suspect an update of breaking anything you can always build
>> binary packages ahead. They are built from the installed package, so you
>> don't have any additional compiling. Then you can roll back quickly if
>> anything is damaged.
>>
>> If you have a working glibc then you could also try re-emerging pkg-config.
>>
>> Regards
>> Johannes
>>
>>
> Hi Johannes,
>
> thanks for your offered help! :)
>
> I fixed that symlink but I ran into more weird problems... :(
> Normally I alway run a revdep-rebuild cycle after each 
> update...
>
> How did you set ABI_X86 in make.conf?
> Do you use multilib or a pure 64bit setup?
>
> Cheers
> Meino
>

Hi Meino,

you are welcome!

With the portage FEATURE 'preserve-libs' (active by default) you don't
need to revep-rebuild, normally. Just emerge @preserved-rebuild after
every update.

Does pkg-config work, now? Can you describe your "weird problems"? Have
you emerged any potentially broken and important (e.g. from @system)
packages recently?

Since I use a pure 64bit setup with abi_x86_32 activated selectively for
399 packages (mostly graphics related, because i still have flash
installed), i have no ABI_X86 var in my make.conf but use a pure amd64
profile (where this var is set).
What do you need 32bit for? 3rd-party binaries?

Regards
Johannes

Re: [gentoo-user] Re: Kernel modules: initramfs vs. /lib/modules

[Daniel Frey]

On 02/13/2017 10:51 AM, Remy Blank wrote:
> Daniel Frey wrote on 2017-02-13 17:34:
>> On 02/13/2017 03:34 AM, Rich Freeman wrote:
>>> Anytime you see something like root=UUID=* that is being handled by an
>>> initramfs.  And of course a UUID is more reliable than a device name,
>>> since the latter can change if you add/remove a device, or maybe even
>>> if your firmware is having a bad day.  Identifying devices by UUID
>>> ensures the right one gets found, assuming it is available.  If you're
>>> using something like mdadm/lvm there are alternatives to UUID, but the
>>> point is the same, you're using a logical identifier that is based on
>>> what is stored on the disks and not just what port it is connected to.
>>>
>>
>> Are you sure? When I set up my EFI stub kernel on my Surface tablet, I
>> did not use an initramfs and I use PARTUUID= in the kernel built in init
>> line and it boots.
> 
> Note that Rich wrote "UUID=", but you used "PARTUUID=". The former
> requires an initramfs, the latter doesn't. The details why escape me: if
> the filesystem code is built into the kernel (as opposed to a module), I
> see no practical reason why the FS UUID couldn't be determined by the
> kernel directly.
> 
>> I thought I was going to have to use an initramfs but I tried without it
>> and it boots with no issues.
> 
> 

Yes, but I [incorrectly, apparently] assumed that UUID and PARTUUID
would work the same way. Now I'm curious as to why it doesn't, I'm going
to look it up later.

Dan

Re: [gentoo-user] WARNING: Crucial MX300 drives SUUUUUCK!!!!

[Mick]

On Monday 13 Feb 2017 13:17:14 Poison BL. wrote:
> On Mon, Feb 13, 2017 at 11:44 AM, Daniel Frey  wrote:
> > On 02/12/2017 02:40 PM, Alan Grimes wrote:
> > > So does anyone have any evidence of a current generation SSD lasting
> > > more than 20 days?
> > 
> > I have tried various SSDs (multiple brands and generations) over the
> > last maybe five years and found that they're very unreliable (multiple
> > brands too.)
> > 
> > I know everyone's saying these things are reliable but out of four SSDs
> > I own, I've had to replace three, some more than once.
> > 
> > I just don't use them for anything I want to stay working. Right now I
> > keep them in my mythtv frontends as I can restore the OS easily. One one
> > of them the company involved (Kingston) even sent me a newer drive/model
> > as it was replaced more than once.
> > 
> > I know they're fast. But what's the point of going 500 MPH and crashing
> > into a mountain with no chance of repair/recovery. I went back to a
> > (relatively) slower rust raid10, and it's been reliable for the last
> > four years. At least with a hard drive failure, you stand /some/ chance
> > at recovery, not zero.
> > 
> > The one SSD that hasn't had to have been replaced under warranty is in
> > my laptop which I generally use maybe a dozen times a year. I fully
> > expect it to die one of these times when I boot the laptop (it's one of
> > the old models.)
> > 
> > My experiences are with Samsung, Kingston, Intel, Crucial and AData
> > SSDs. The last one I bought because these things I view as throwaway
> > devices (the warranty expired on the original Crucial) and don't want to
> > spend big money on them. I have noticed the AData SSD's performance is
> > not as fast now as it was new (maybe 1.5 years ago?) So it'll probably
> > pack it in soon too.
> > 
> > Dan
> 
> I've had more than one spinning rust drive fail hard over the years as
> well, though yes, you do usually have some chance of recovery from those.
> Gambling on that chance by leaving a given disk as a single point of
> failure is still a bad idea, spinning disk or not. The point that you went
> from single-disk SSD back to raid10 makes me question why, if your uptime
> requirements (even if only for your own desires on a personal machine)
> justify raid10, you weren't on at least raid1 with the SSD setup.
> 
> As for performance degredation on SSDs, that I've definitely seen on pretty
> much every brand, though I've had good luck doing clean reloads on samsungs
> once or twice to get speeds back up some (somehow, even trim doesn't seem
> to keep things at their best).
> 
> I can't say they're more or less reliable than spinning disks, though they
> do have the benefit of no moving parts to wear out over time (thermal
> cycles can still cause a physical failure on them, though).

Have you noticed a difference between mounting partitions on them with the 
discard option, Vs running fstrim on a cron job?
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] xorg wiki and graphics drivers

[Harry Putnam]

Setup:
   gentoo (no-X) installed into vbox vm on win 10 (64bit) host.

I've gotten a solid base going but now want to setup LXDE.  Gentoo LXDE
wiki starts after you've already setup the X server so I went to Gentoo
Xorg wiki

Following the gentoo Xorg setup pages.  I'm having some confusion
regarding which graphics driver is needed.

The pages at https://wiki.gentoo.org/wiki/Xorg/Guide say to turn off
any drivers you have selected in your kernel conifg at
`Device Drvrs
  -> Graphics support
   -> Frame buffer devices':

   Here it says to deselect any drivers in there.

Move on down to `Console display driver support' and select
`Frame buffer console support'

So far easy enough, but I guess I'd still need a driver for whatever
graphics adaptier vbox has on offer.  In my case it is (from lspci):

  VGA compatible controller: InnoTek Systemberatun GmbH virtualBox
  Graphics adaptor

Back at the wiki:

The the discussion goes on to a few common graphics adapters and tells
you what to do about them.  So I'm kind of lost as to what to do about
the vbox setup.

The wiki tells you to use KMS as its an improvement over other
approaches.

I like to boot with a hi-res framebuffer and do some of my chores in
console mode where I like that framebuffer.  I'm wondering if with KMS
one still can have that large or hi-res framebuffer when in console
mode.  I'm pretty sure the things I had selected in the Framebuffer
Kernel area were what makes the hi-res frame buffer possible (When not
using KMS).

So, following the Xorg pages I've deselected what settings I had there.

Haven't rebooted as yet.

Anyway, cutting to the chase:
So I'm hoping someone here is familiar with the requirements of a vbox vm
graphics adaptier and can recommend a driver, but I'd also like to hear
about how a frame buffer works in KMS.

Re: [gentoo-user] xorg wiki and graphics drivers

[Willie Mattthews]

On 02/13/2017 04:11 PM, Harry Putnam wrote:
> Setup:
>gentoo (no-X) installed into vbox vm on win 10 (64bit) host.
> 
> I've gotten a solid base going but now want to setup LXDE.  Gentoo LXDE
> wiki starts after you've already setup the X server so I went to Gentoo
> Xorg wiki
> 
> Following the gentoo Xorg setup pages.  I'm having some confusion
> regarding which graphics driver is needed.
> 
> The pages at https://wiki.gentoo.org/wiki/Xorg/Guide say to turn off
> any drivers you have selected in your kernel conifg at
> `Device Drvrs
>   -> Graphics support
>-> Frame buffer devices':
> 
>Here it says to deselect any drivers in there.
> 
> Move on down to `Console display driver support' and select
> `Frame buffer console support'
> 
> So far easy enough, but I guess I'd still need a driver for whatever
> graphics adaptier vbox has on offer.  In my case it is (from lspci):
> 
>   VGA compatible controller: InnoTek Systemberatun GmbH virtualBox
>   Graphics adaptor
> 
> Back at the wiki:
> 
> The the discussion goes on to a few common graphics adapters and tells
> you what to do about them.  So I'm kind of lost as to what to do about
> the vbox setup.
> 
> The wiki tells you to use KMS as its an improvement over other
> approaches.
> 
> I like to boot with a hi-res framebuffer and do some of my chores in
> console mode where I like that framebuffer.  I'm wondering if with KMS
> one still can have that large or hi-res framebuffer when in console
> mode.  I'm pretty sure the things I had selected in the Framebuffer
> Kernel area were what makes the hi-res frame buffer possible (When not
> using KMS).
> 
> So, following the Xorg pages I've deselected what settings I had there.
> 
> Haven't rebooted as yet.
> 
> Anyway, cutting to the chase:
> So I'm hoping someone here is familiar with the requirements of a vbox vm
> graphics adaptier and can recommend a driver, but I'd also like to hear
> about how a frame buffer works in KMS.
> 
> 

Found a link for you also.
https://wiki.gentoo.org/wiki/VirtualBox#Linux_guest-related

-- 

Willie Matthews
matthews.willi...@gmail.com



signature.asc
Description: OpenPGP digital signature

[gentoo-user] Re: xorg wiki and graphics drivers

[Harry Putnam]

Willie Mattthews  writes:

> If I am not mistaken you would need to install,
>
> * app-emulation/virtualbox-guest-additions
>  Available versions:  4.3.38 ~4.3.40 ~5.0.16 ~5.0.30 5.0.32 ~5.1.12
> ~5.1.14 {X KERNEL="linux"}
>  Homepage:http://www.virtualbox.org/
>  Description: VirtualBox kernel modules and user-space tools
> for Gentoo guests
>
> I think you would have to install it in the VM itself. I don't know
> about the rest of it.

Not sure I'm following you here.  THe guest addtions come with the
Vbox and I've already installed them.

This is a windows 10 host and the vbox is the one installable on
windows. This is version 5.1.14

Guest additinos have nothing to do with gentoo kernel config.

What I'm asking about it setting up a kernel for gentoo os preparatory
to installing X.  As described in the Xorg gentoo wiki. Vbox vm's need
drivers like any other os.

I'm asking which driver works with the vbox graphics adapter.
And how to get a hi-res frame buffer using kernel KMS.

Re: [gentoo-user] Building a new root for my Gentoo: Permission denied?

[Meino . Cramer]

Johannes Rosenberger  [17-02-14 02:43]:
> On 13.02.2017 19:20, meino.cra...@gmx.de wrote:
> > Johannes Rosenberger  [17-02-13 19:04]:
> >> On 13.02.2017 17:57, meino.cra...@gmx.de wrote:
> >>
> >>> Hogren  [17-02-13 17:06]:
>  On 13/02/2017 04:42, meino.cra...@gmx.de wrote:
> > Hi,
> >
> > got a mysterious error message this morning (still building a new 
> > root...)
> >
> > One of the updates was gnutls:
> > It ends with:
> > ...
> > checking for i686-pc-linux-gnu-pkg-config... 
> > /usr/bin/i686-pc-linux-gnu-pkg-config
> > checking pkg-config is at least version 0.9.0... 
> > /var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9/configure: 
> > line 5020: /usr/bin/i686-pc-linux-gnu-pkg-config: Permission denied
> > no
> > checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
> > checking whether the C compiler works... yes
> > checking for C compiler default output file name... a.out
> > checking for suffix of executables... 
> > checking whether we are cross compiling... configure: error: in 
> > `/var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9-abi_x86_32.x86':
> > configure: error: cannot run C compiled programs.
> > If you meant to cross compile, use `--host'.
> > See `config.log' for more details
> > ...
> >
> > I tried:
> > computer# ldd /usr/bin/i686-pc-linux-gnu-pkg-config
> > not a dynamic executable
> > computer# /usr/bin/i686-pc-linux-gnu-pkg-config 
> > zsh: permission denied: /usr/bin/i686-pc-linux-gnu-pkg-config
> >
> > computer# file /usr/bin/i686-pc-linux-gnu-pkg-config
> > /usr/bin/i686-pc-linux-gnu-pkg-config: ELF 32-bit LSB executable, Intel 
> > 80386, version 1 (SYSV), dynamically linked, interpreter 
> > /lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped, with debug_info
> >
> > I choosed multilib right from the beginning of this adventure ...
> >
> > How can I check, whether the problem is caysed by gnutls or by the 
> > system setup (regarding 32bit)?
> >
> > Cheers
> > Meino
> >
> >
> >
> >
> >
>  Hello,
> 
>  Can you give us more details of what do you want to do, what do you
>  already do, etc.
> 
>  Does /usr/bin/i686-pc-linux-gnu-pkg-config have the x (executable) 
>  permission ? (ls -l /usr/bin/i686-pc-linux-gnu-pkg-config)
> 
> 
> 
>  Hogren
> 
> 
> 
> 
> >>> More mysterious hickups:
> >>>
> >> Regenerating /etc/ld.so.cache...
> >>> /sbin/ldconfig: File /lib64/ld-linux.so.2 is empty, not checked.
> >>>
> >>> Did it screwed up my new root?
> >>>
> >>> Cheers
> >>> Meino
> >>>
> >>>
> >>>
> >>>
> >> Maybe. But maybe it is fixable. /lib64/ld-linux.so.2 is a symlink to
> >> glibc. But glibc cannot be wholly broken because if it were, then
> >> nothing would work at all.
> >>
> >> I'd first investigate if only the symlink needs to be fixed (should
> >> point to /lib/ld-.so).
> >>
> >> Have you updated glibc recently?Or any other important package/package
> >> from @system?
> >> Have you tried if 'revdep-rebuild' finds any broken libraries?
> >>
> >> If glibc is really broken you can
> >>
> >> 1. chroot into a stage3
> >> 2. build a binpkg (type 'quickpkg glibc')
> >> 3. copy the binpkg from
> >> '/usr/portage/packages/sys-libs/glibc-*.tbz2' in the stage3 to
> >>the same directory in your new root
> >> 4. install the binary glibc ('emerge ')
> >>
> >> Then you should have a clean glibc install.
> >>
> >> If you suspect an update of breaking anything you can always build
> >> binary packages ahead. They are built from the installed package, so you
> >> don't have any additional compiling. Then you can roll back quickly if
> >> anything is damaged.
> >>
> >> If you have a working glibc then you could also try re-emerging pkg-config.
> >>
> >> Regards
> >> Johannes
> >>
> >>
> > Hi Johannes,
> >
> > thanks for your offered help! :)
> >
> > I fixed that symlink but I ran into more weird problems... :(
> > Normally I alway run a revdep-rebuild cycle after each 
> > update...
> >
> > How did you set ABI_X86 in make.conf?
> > Do you use multilib or a pure 64bit setup?
> >
> > Cheers
> > Meino
> >
> 
> Hi Meino,
> 
> you are welcome!
> 
> With the portage FEATURE 'preserve-libs' (active by default) you don't
> need to revep-rebuild, normally. Just emerge @preserved-rebuild after
> every update.
> 
> Does pkg-config work, now? Can you describe your "weird problems"? Have
> you emerged any potentially broken and important (e.g. from @system)
> packages recently?
> 
> Since I use a pure 64bit setup with abi_x86_32 activated selectively for
> 399 packages (mostly graphics related, because i still have flash
> installed), i have no ABI_X86 var in my make.conf but use a pure amd64
> profile (where this var is set).
> What do you 

Re: [gentoo-user] WARNING: Crucial MX300 drives SUUUUUCK!!!!

[wabe]

Mick  wrote:

> On Monday 13 Feb 2017 13:17:14 Poison BL. wrote:
> > On Mon, Feb 13, 2017 at 11:44 AM, Daniel Frey 
> > wrote:  
> > > On 02/12/2017 02:40 PM, Alan Grimes wrote:  
> > > > So does anyone have any evidence of a current generation SSD
> > > > lasting more than 20 days?  
> > > 
> > > I have tried various SSDs (multiple brands and generations) over
> > > the last maybe five years and found that they're very unreliable
> > > (multiple brands too.)
> > > 
> > > I know everyone's saying these things are reliable but out of
> > > four SSDs I own, I've had to replace three, some more than once.
> > > 
> > > I just don't use them for anything I want to stay working. Right
> > > now I keep them in my mythtv frontends as I can restore the OS
> > > easily. One one of them the company involved (Kingston) even sent
> > > me a newer drive/model as it was replaced more than once.
> > > 
> > > I know they're fast. But what's the point of going 500 MPH and
> > > crashing into a mountain with no chance of repair/recovery. I
> > > went back to a (relatively) slower rust raid10, and it's been
> > > reliable for the last four years. At least with a hard drive
> > > failure, you stand /some/ chance at recovery, not zero.
> > > 
> > > The one SSD that hasn't had to have been replaced under warranty
> > > is in my laptop which I generally use maybe a dozen times a year.
> > > I fully expect it to die one of these times when I boot the
> > > laptop (it's one of the old models.)
> > > 
> > > My experiences are with Samsung, Kingston, Intel, Crucial and
> > > AData SSDs. The last one I bought because these things I view as
> > > throwaway devices (the warranty expired on the original Crucial)
> > > and don't want to spend big money on them. I have noticed the
> > > AData SSD's performance is not as fast now as it was new (maybe
> > > 1.5 years ago?) So it'll probably pack it in soon too.
> > > 
> > > Dan  
> > 
> > I've had more than one spinning rust drive fail hard over the years
> > as well, though yes, you do usually have some chance of recovery
> > from those. Gambling on that chance by leaving a given disk as a
> > single point of failure is still a bad idea, spinning disk or not.
> > The point that you went from single-disk SSD back to raid10 makes
> > me question why, if your uptime requirements (even if only for your
> > own desires on a personal machine) justify raid10, you weren't on
> > at least raid1 with the SSD setup.
> > 
> > As for performance degredation on SSDs, that I've definitely seen
> > on pretty much every brand, though I've had good luck doing clean
> > reloads on samsungs once or twice to get speeds back up some
> > (somehow, even trim doesn't seem to keep things at their best).

It really helps when you always left some free space on the drives.
I used fstrim to reserve additional 20% free space on my SSD drives.
I said additional because manufacturers always(?) reserve some 
percentage free space for overprovisioning. This not only expands 
the lifetime of SSDs but also helps to preserve write performance.

> > I can't say they're more or less reliable than spinning disks,
> > though they do have the benefit of no moving parts to wear out over
> > time (thermal cycles can still cause a physical failure on them,
> > though).  
> 
> Have you noticed a difference between mounting partitions on them
> with the discard option, Vs running fstrim on a cron job?

I noticed a big performance impact with my old Corsair 60GB SSD 
(Force3 IIRC) when I used the discard option in fstab. So I decided
to use the fstrim command instead, before I did my weekly backups.
The fstrim command always needed about 10 minutes or so to complete
its job.

About 1 year ago I replaced the Corsair with a Samsung SSD 850 PRO.
With this device I did not notice a performance impact when the 
discard option is enabled and so I decided to use it.
Btw: On the Samsung SSDs the fstrim command only needs a second or 
so to do its job.

I never used a benchmark program to check if there is really no 
difference. But at least I don't notice any in my every day use.

My old Corsair SSD (bought it in 2011) is still in use as swap
space device in my Win7 machine (together with a SSD 850 PRO as
system device). Before that, I used it as system disk on my gentoo
machine. I also used it for my users mail and thumbnail directories
and also for /log, /tmp, /var and the whole portage tree. Before
I upgraded my gentoo machine to 16GB RAM I also used the SSD for 
portages temporary files. So it was really in heavy use. And is 
still running without problems.
Before I installed the Corsair SSD into my Win machine, I used 
fstrim to increase the reserved space to 50%. I hope that it will 
run for at least another 6 years. ;-)

--
Regards
wabe


pgp_2HmSIJKiB.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-user] xorg wiki and graphics drivers

[Willie Mattthews]

On 02/13/2017 04:11 PM, Harry Putnam wrote:
> Setup:
>gentoo (no-X) installed into vbox vm on win 10 (64bit) host.
> 
> I've gotten a solid base going but now want to setup LXDE.  Gentoo LXDE
> wiki starts after you've already setup the X server so I went to Gentoo
> Xorg wiki
> 
> Following the gentoo Xorg setup pages.  I'm having some confusion
> regarding which graphics driver is needed.
> 
> The pages at https://wiki.gentoo.org/wiki/Xorg/Guide say to turn off
> any drivers you have selected in your kernel conifg at
> `Device Drvrs
>   -> Graphics support
>-> Frame buffer devices':
> 
>Here it says to deselect any drivers in there.
> 
> Move on down to `Console display driver support' and select
> `Frame buffer console support'
> 
> So far easy enough, but I guess I'd still need a driver for whatever
> graphics adaptier vbox has on offer.  In my case it is (from lspci):
> 
>   VGA compatible controller: InnoTek Systemberatun GmbH virtualBox
>   Graphics adaptor
> 
> Back at the wiki:
> 
> The the discussion goes on to a few common graphics adapters and tells
> you what to do about them.  So I'm kind of lost as to what to do about
> the vbox setup.
> 
> The wiki tells you to use KMS as its an improvement over other
> approaches.
> 
> I like to boot with a hi-res framebuffer and do some of my chores in
> console mode where I like that framebuffer.  I'm wondering if with KMS
> one still can have that large or hi-res framebuffer when in console
> mode.  I'm pretty sure the things I had selected in the Framebuffer
> Kernel area were what makes the hi-res frame buffer possible (When not
> using KMS).
> 
> So, following the Xorg pages I've deselected what settings I had there.
> 
> Haven't rebooted as yet.
> 
> Anyway, cutting to the chase:
> So I'm hoping someone here is familiar with the requirements of a vbox vm
> graphics adaptier and can recommend a driver, but I'd also like to hear
> about how a frame buffer works in KMS.
> 
> 

If I am not mistaken you would need to install,

* app-emulation/virtualbox-guest-additions
 Available versions:  4.3.38 ~4.3.40 ~5.0.16 ~5.0.30 5.0.32 ~5.1.12
~5.1.14 {X KERNEL="linux"}
 Homepage:http://www.virtualbox.org/
 Description: VirtualBox kernel modules and user-space tools
for Gentoo guests

I think you would have to install it in the VM itself. I don't know
about the rest of it.

-- 

Willie Matthews
matthews.willi...@gmail.com



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] WARNING: Crucial MX300 drives SUUUUUCK!!!!

[Mick]

On Tuesday 14 Feb 2017 01:51:01 wabe wrote:
> Mick  wrote:

> > Have you noticed a difference between mounting partitions on them
> > with the discard option, Vs running fstrim on a cron job?
> 
> I noticed a big performance impact with my old Corsair 60GB SSD
> (Force3 IIRC) when I used the discard option in fstab. So I decided
> to use the fstrim command instead, before I did my weekly backups.
> The fstrim command always needed about 10 minutes or so to complete
> its job.
> 
> About 1 year ago I replaced the Corsair with a Samsung SSD 850 PRO.
> With this device I did not notice a performance impact when the
> discard option is enabled and so I decided to use it.
> Btw: On the Samsung SSDs the fstrim command only needs a second or
> so to do its job.
> 
> I never used a benchmark program to check if there is really no
> difference. But at least I don't notice any in my every day use.
> 
> My old Corsair SSD (bought it in 2011) is still in use as swap
> space device in my Win7 machine (together with a SSD 850 PRO as
> system device). Before that, I used it as system disk on my gentoo
> machine. I also used it for my users mail and thumbnail directories
> and also for /log, /tmp, /var and the whole portage tree. Before
> I upgraded my gentoo machine to 16GB RAM I also used the SSD for
> portages temporary files. So it was really in heavy use. And is
> still running without problems.
> Before I installed the Corsair SSD into my Win machine, I used
> fstrim to increase the reserved space to 50%. I hope that it will
> run for at least another 6 years. ;-)
> 
> --
> Regards
> wabe

Thanks wabe, this is really interesting.  I was using discard and can't say I 
noticed any performance penalty on the OCZ drive.  I removed it and set up a 
fstrim cron job and suddenly there is a major I/O bottleneck when the cron job 
runs.  Perhaps I should be running it more often ...

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] GUI-less (non-dbus) virt-manager (to run Tails in Gentoo)

[Miroslav Rovis]

Not about Tails, this message, but yes it is about GUI-less (non-dbus)
virt-manager.

About its use for installing and running a Tails' relative: Whonix.

I made a well-accepted, I believe, push for Whonix to be installable and
runnable (actually it maybe already is!) in sans-dbus systems.

Pls. if anybody feels passionate enough about Unix heredity staying
sound and prosperous, and you feel you can contribute by helping in this
thread:

Whonix on Gentoo issues
https://forums.whonix.org/t/whonix-on-gentoo-issues/3188

then pls. do contribute!

There is a poor-eyesight old man that I am useless digression somewhere
in one of the first three posts (which I can't remove anymore, old posts
are not editable in Whonix forums), and also previous to below all
attempts of mine were unsuccessful, so...

So maybe if you start from:

https://forums.whonix.org/t/whonix-on-gentoo-issues/3188/7

[from] post 7, you will be sufficiently in the clear what the issue is.

And on a sidenote on this thread that you're reading. I probably need to
re-evaluate the current status of no-dbus virt-manager using virt-viewer
as GUI, with the last night update of Gentoo installtion of mine (always
such a pleasure).

Pls. contribute if you are familiar with Whonix and the issues there!

I've top posted this, because it regards the entire thread, not this
particular email below.

On 170114-22:53+0100, Miroslav Rovis wrote:
> More errata.
> 
> On 170114-13:06+0100, Miroslav Rovis wrote:
...
> > If anybody is interested, I attach the install log:
> > 
> > app-emulation_virt-viewer-5.0-r1_20170113-164725.log.gz
> > (that's from /var/log/portage, just I replaced the : with _)
> > 
> > where it's easy to spot lines like:
> > 
> > virt-viewer-app.h:47:5: error: unknown type name 'GtkApplicationClass'
> > 
> > because the new API is missing in GTK2. And the package virt-viewer cannot
> > possibly compile.
> > 
> you can read in the changelog of the source of virt-viewer-5.0, if you
> unpack the virt-viewer-5.0.tar.gz, these lines:
> 
> /usr/portage/distfiles/virt-viewer-5.0.tar.gz
> 
> virt-viewer-5.0/ChangeLog :
> 
>   [...]
> 
> 2016-02-15  Fabiano Fidêncio  
> 
>   Drop support to gtk2
>   The 3.0 release was the last one that still supports GTK2. For the
>   Windows builds the support to GTK2 was dropped in the previous release.
>   Let's do the same for the entire project now.
> 
> 2016-02-15  Pavel Grunt  
> 
>   display: Use correct variable name
>   Fix gtk2 build
> 
>   [...]
> 
...

Regards!

-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature

Re: [gentoo-user] Bad luck with new installation: Compilation issues (eudev)

[Miroslav Rovis]

On 170213-04:19+0100, meino.cra...@gmx.de wrote:
> Miroslav Rovis  [17-02-12 14:03]:
...
> > C'mon, give people the link to that bug that you reported, pls.! Thanks!
> > Thanks! Thanks! Thanks!
Sorry for this. I forgot to delete it, because I saw I was wrong. Wasn't
actually going to send it.  Sent it eventually by mistake.

> 
> From the first answer in this thread: 
> 
> Alexander Openkowski  [17-02-05 18:28]:
> > Have you seen this thread in the forums? It looks like your problem:
> > 
> > https://forums.gentoo.org/viewtopic-t-1057500-view-previous.html?sid=9c8b57325eef824a0748ec4ca94ac8b1
> > 
> > Found via a quick google search. Keywords: "eudev 3.2.1 error gentoo".
> > No offense, really. But you do not need to wait for an answer if you
> > search for yourself. :-)
You are right. Sorry!

-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


signature.asc
Description: Digital signature

Re: [gentoo-user] Building a new root for my Gentoo: Permission denied?

[Meino . Cramer]

Hogren  [17-02-13 17:06]:
> On 13/02/2017 04:42, meino.cra...@gmx.de wrote:
> > Hi,
> >
> > got a mysterious error message this morning (still building a new 
> > root...)
> >
> > One of the updates was gnutls:
> > It ends with:
> > ...
> > checking for i686-pc-linux-gnu-pkg-config... 
> > /usr/bin/i686-pc-linux-gnu-pkg-config
> > checking pkg-config is at least version 0.9.0... 
> > /var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9/configure: line 
> > 5020: /usr/bin/i686-pc-linux-gnu-pkg-config: Permission denied
> > no
> > checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
> > checking whether the C compiler works... yes
> > checking for C compiler default output file name... a.out
> > checking for suffix of executables... 
> > checking whether we are cross compiling... configure: error: in 
> > `/var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9-abi_x86_32.x86':
> > configure: error: cannot run C compiled programs.
> > If you meant to cross compile, use `--host'.
> > See `config.log' for more details
> > ...
> >
> > I tried:
> > computer# ldd /usr/bin/i686-pc-linux-gnu-pkg-config
> > not a dynamic executable
> > computer# /usr/bin/i686-pc-linux-gnu-pkg-config 
> > zsh: permission denied: /usr/bin/i686-pc-linux-gnu-pkg-config
> >
> > computer# file /usr/bin/i686-pc-linux-gnu-pkg-config
> > /usr/bin/i686-pc-linux-gnu-pkg-config: ELF 32-bit LSB executable, Intel 
> > 80386, version 1 (SYSV), dynamically linked, interpreter 
> > /lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped, with debug_info
> >
> > I choosed multilib right from the beginning of this adventure ...
> >
> > How can I check, whether the problem is caysed by gnutls or by the 
> > system setup (regarding 32bit)?
> >
> > Cheers
> > Meino
> >
> >
> >
> >
> >
> 
> Hello,
> 
> Can you give us more details of what do you want to do, what do you
> already do, etc.
> 
> Does /usr/bin/i686-pc-linux-gnu-pkg-config have the x (executable) permission 
> ? (ls -l /usr/bin/i686-pc-linux-gnu-pkg-config)
> 
> 
> 
> Hogren
> 
> 
> 
> 

Hi Hogren,

my old root is no longer updatable in a efficient way (much too much
workarounds, quirks, exceptions etc. pp.) and it is old.

So I decided to build a new one.

I created a directory on a partition with enough space, chrooted into
it and installed the stage3 archive.

Then I started to install the software I used to use.

Yesterday I wanted (as done before) to update via
eix-sync.emerge@world...andBUMMER!
The above mention error happens.

What to compile and how to compile it depended completly on decisions
made by emerge...I dont know why it wants to compile a 32bit version
of gnutls...the only thing I know is that I choosed the multilib
version of the stage3 by intention.

This is from the chrooted environment, which complains while
updateing...:
ls -l /usr/bin/i686-pc-linux-gnu-pkg-config
-rwxr-xr-x 1 root root 46836 Feb  7 04:24 /usr/bin/i686-pc-linux-gnu-pkg-config

It was a normal and often done successfully update process, which
triggers this...

Any idea what's the reason for it and how to fix it?

Cheers
Meino

Re: [gentoo-user] WARNING: Crucial MX300 drives SUUUUUCK!!!!

[Daniel Frey]

On 02/12/2017 02:40 PM, Alan Grimes wrote:
> So does anyone have any evidence of a current generation SSD lasting
> more than 20 days?
> 

I have tried various SSDs (multiple brands and generations) over the
last maybe five years and found that they're very unreliable (multiple
brands too.)

I know everyone's saying these things are reliable but out of four SSDs
I own, I've had to replace three, some more than once.

I just don't use them for anything I want to stay working. Right now I
keep them in my mythtv frontends as I can restore the OS easily. One one
of them the company involved (Kingston) even sent me a newer drive/model
as it was replaced more than once.

I know they're fast. But what's the point of going 500 MPH and crashing
into a mountain with no chance of repair/recovery. I went back to a
(relatively) slower rust raid10, and it's been reliable for the last
four years. At least with a hard drive failure, you stand /some/ chance
at recovery, not zero.

The one SSD that hasn't had to have been replaced under warranty is in
my laptop which I generally use maybe a dozen times a year. I fully
expect it to die one of these times when I boot the laptop (it's one of
the old models.)

My experiences are with Samsung, Kingston, Intel, Crucial and AData
SSDs. The last one I bought because these things I view as throwaway
devices (the warranty expired on the original Crucial) and don't want to
spend big money on them. I have noticed the AData SSD's performance is
not as fast now as it was new (maybe 1.5 years ago?) So it'll probably
pack it in soon too.

Dan

Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules

[Daniel Frey]

On 02/13/2017 03:34 AM, Rich Freeman wrote:
> Anytime you see something like root=UUID=* that is being handled by an
> initramfs.  And of course a UUID is more reliable than a device name,
> since the latter can change if you add/remove a device, or maybe even
> if your firmware is having a bad day.  Identifying devices by UUID
> ensures the right one gets found, assuming it is available.  If you're
> using something like mdadm/lvm there are alternatives to UUID, but the
> point is the same, you're using a logical identifier that is based on
> what is stored on the disks and not just what port it is connected to.
> 

Are you sure? When I set up my EFI stub kernel on my Surface tablet, I
did not use an initramfs and I use PARTUUID= in the kernel built in init
line and it boots.

I thought I was going to have to use an initramfs but I tried without it
and it boots with no issues.

Dan

Re: [gentoo-user] Bad luck with new installation: Compilation issues (eudev)

[Meino . Cramer]

Miroslav Rovis  [17-02-13 17:06]:
> On 170213-04:19+0100, meino.cra...@gmx.de wrote:
> > Miroslav Rovis  [17-02-12 14:03]:
> ...
> > > C'mon, give people the link to that bug that you reported, pls.! Thanks!
> > > Thanks! Thanks! Thanks!
> Sorry for this. I forgot to delete it, because I saw I was wrong. Wasn't
> actually going to send it.  Sent it eventually by mistake.
> 
> > 
> > From the first answer in this thread: 
> > 
> > Alexander Openkowski  [17-02-05 18:28]:
> > > Have you seen this thread in the forums? It looks like your problem:
> > > 
> > > https://forums.gentoo.org/viewtopic-t-1057500-view-previous.html?sid=9c8b57325eef824a0748ec4ca94ac8b1
> > > 
> > > Found via a quick google search. Keywords: "eudev 3.2.1 error gentoo".
> > > No offense, really. But you do not need to wait for an answer if you
> > > search for yourself. :-)
> You are right. Sorry!
> 
> -- 
> Miroslav Rovis
> Zagreb, Croatia
> http://www.CroatiaFidelis.hr

Hi Miroslav,

no problem...we are all human...and thats the best we can be... :)

Cheers
Meino

Re: [gentoo-user] Building a new root for my Gentoo: Permission denied?

[Meino . Cramer]

Hogren  [17-02-13 17:06]:
> On 13/02/2017 04:42, meino.cra...@gmx.de wrote:
> > Hi,
> >
> > got a mysterious error message this morning (still building a new 
> > root...)
> >
> > One of the updates was gnutls:
> > It ends with:
> > ...
> > checking for i686-pc-linux-gnu-pkg-config... 
> > /usr/bin/i686-pc-linux-gnu-pkg-config
> > checking pkg-config is at least version 0.9.0... 
> > /var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9/configure: line 
> > 5020: /usr/bin/i686-pc-linux-gnu-pkg-config: Permission denied
> > no
> > checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
> > checking whether the C compiler works... yes
> > checking for C compiler default output file name... a.out
> > checking for suffix of executables... 
> > checking whether we are cross compiling... configure: error: in 
> > `/var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9-abi_x86_32.x86':
> > configure: error: cannot run C compiled programs.
> > If you meant to cross compile, use `--host'.
> > See `config.log' for more details
> > ...
> >
> > I tried:
> > computer# ldd /usr/bin/i686-pc-linux-gnu-pkg-config
> > not a dynamic executable
> > computer# /usr/bin/i686-pc-linux-gnu-pkg-config 
> > zsh: permission denied: /usr/bin/i686-pc-linux-gnu-pkg-config
> >
> > computer# file /usr/bin/i686-pc-linux-gnu-pkg-config
> > /usr/bin/i686-pc-linux-gnu-pkg-config: ELF 32-bit LSB executable, Intel 
> > 80386, version 1 (SYSV), dynamically linked, interpreter 
> > /lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped, with debug_info
> >
> > I choosed multilib right from the beginning of this adventure ...
> >
> > How can I check, whether the problem is caysed by gnutls or by the 
> > system setup (regarding 32bit)?
> >
> > Cheers
> > Meino
> >
> >
> >
> >
> >
> 
> Hello,
> 
> Can you give us more details of what do you want to do, what do you
> already do, etc.
> 
> Does /usr/bin/i686-pc-linux-gnu-pkg-config have the x (executable) permission 
> ? (ls -l /usr/bin/i686-pc-linux-gnu-pkg-config)
> 
> 
> 
> Hogren
> 
> 
> 
> 

More mysterious hickups:

>>> Regenerating /etc/ld.so.cache...
/sbin/ldconfig: File /lib64/ld-linux.so.2 is empty, not checked.

Did it screwed up my new root?

Cheers
Meino

Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules

[Rich Freeman]

On Mon, Feb 13, 2017 at 5:53 AM, marco restelli  wrote:
>
> Could you suggest any reference about how an initramfs can help making
> it easier to identify the correct root filesystem? Does this
> functionality overlap with what grub can do, or is something
> different?
>

The dracut references are fairly extensive, but they probably assume
that you already know about something like this.  Keep in mind that on
virtually all other distros end-users aren't expected to set up their
own kernels or initramfs so there isn't a lot of general documentation
out there.  And even within Gentoo a lot of people seem to avoid an
initramfs, so our own docs may not be as extensive as they could be.

The short version is that the kernel is very limited in what it can
take in the root= option on the command line, and grub and other
bootloaders don't do anything to ID the root filesystem other than
passing whatever root= parameter you specify (I'd be interested in any
info to the contrary).

The kernel itself can't handle UUIDs or filesystem labels.  It
actually can handle some situations like lvm on top of mdadm, but that
is about as complex as it gets as far as I'm aware, and even in that
situation there are some limitations.

An initramfs is typically implemented in a bunch of shell scripts
(though it is really a full userspace so in theory you can really have
it do anything).  That gives it a lot more flexibility.  Typically
they run udev which gives you all the /dev/disk/by-id symlinks and so
on.  They can also do things like fsck root before mounting it (though
mounting it read-only and having it fsck itself isn't a terrible
alternative, which is how things work without an initramfs).

Basically an initramfs should be viewed as an extended bootloader.
For more exotic setups they're essentially required (such as
network-based root filesystems).  The trend has also been to not add
new root-finding capabilities to the kernel as the initramfs is the
preferred way of doing things.  If lvm+mdadm were being built today,
I'm not sure they would make the kernel capable of directly mounting
them as root.

Anytime you see something like root=UUID=* that is being handled by an
initramfs.  And of course a UUID is more reliable than a device name,
since the latter can change if you add/remove a device, or maybe even
if your firmware is having a bad day.  Identifying devices by UUID
ensures the right one gets found, assuming it is available.  If you're
using something like mdadm/lvm there are alternatives to UUID, but the
point is the same, you're using a logical identifier that is based on
what is stored on the disks and not just what port it is connected to.

-- 
Rich

Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules

[Johannes Rosenberger]

On 13.02.2017 12:34, Rich Freeman wrote:
> On Mon, Feb 13, 2017 at 5:53 AM, marco restelli  wrote:
>> Could you suggest any reference about how an initramfs can help making
>> it easier to identify the correct root filesystem? Does this
>> functionality overlap with what grub can do, or is something
>> different?
>>
> The dracut references are fairly extensive, but they probably assume
> that you already know about something like this.  Keep in mind that on
> virtually all other distros end-users aren't expected to set up their
> own kernels or initramfs so there isn't a lot of general documentation
> out there.  And even within Gentoo a lot of people seem to avoid an
> initramfs, so our own docs may not be as extensive as they could be.
>
> [...]

There is some very good documentation about crafting your own initramfs
it the Gentoo wiki:
https://wiki.gentoo.org/wiki/Custom_Initramfs
https://wiki.gentoo.org/wiki/Early_Userspace_Mounting

Re: [gentoo-user] Building a new root for my Gentoo: Permission denied?

[Johannes Rosenberger]

On 13.02.2017 17:57, meino.cra...@gmx.de wrote:

> Hogren  [17-02-13 17:06]:
>> On 13/02/2017 04:42, meino.cra...@gmx.de wrote:
>>> Hi,
>>>
>>> got a mysterious error message this morning (still building a new 
>>> root...)
>>>
>>> One of the updates was gnutls:
>>> It ends with:
>>> ...
>>> checking for i686-pc-linux-gnu-pkg-config... 
>>> /usr/bin/i686-pc-linux-gnu-pkg-config
>>> checking pkg-config is at least version 0.9.0... 
>>> /var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9/configure: line 
>>> 5020: /usr/bin/i686-pc-linux-gnu-pkg-config: Permission denied
>>> no
>>> checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
>>> checking whether the C compiler works... yes
>>> checking for C compiler default output file name... a.out
>>> checking for suffix of executables... 
>>> checking whether we are cross compiling... configure: error: in 
>>> `/var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9-abi_x86_32.x86':
>>> configure: error: cannot run C compiled programs.
>>> If you meant to cross compile, use `--host'.
>>> See `config.log' for more details
>>> ...
>>>
>>> I tried:
>>> computer# ldd /usr/bin/i686-pc-linux-gnu-pkg-config
>>> not a dynamic executable
>>> computer# /usr/bin/i686-pc-linux-gnu-pkg-config 
>>> zsh: permission denied: /usr/bin/i686-pc-linux-gnu-pkg-config
>>>
>>> computer# file /usr/bin/i686-pc-linux-gnu-pkg-config
>>> /usr/bin/i686-pc-linux-gnu-pkg-config: ELF 32-bit LSB executable, Intel 
>>> 80386, version 1 (SYSV), dynamically linked, interpreter 
>>> /lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped, with debug_info
>>>
>>> I choosed multilib right from the beginning of this adventure ...
>>>
>>> How can I check, whether the problem is caysed by gnutls or by the 
>>> system setup (regarding 32bit)?
>>>
>>> Cheers
>>> Meino
>>>
>>>
>>>
>>>
>>>
>> Hello,
>>
>> Can you give us more details of what do you want to do, what do you
>> already do, etc.
>>
>> Does /usr/bin/i686-pc-linux-gnu-pkg-config have the x (executable) 
>> permission ? (ls -l /usr/bin/i686-pc-linux-gnu-pkg-config)
>>
>>
>>
>> Hogren
>>
>>
>>
>>
> More mysterious hickups:
>
 Regenerating /etc/ld.so.cache...
> /sbin/ldconfig: File /lib64/ld-linux.so.2 is empty, not checked.
>
> Did it screwed up my new root?
>
> Cheers
> Meino
>
>
>
>
Maybe. But maybe it is fixable. /lib64/ld-linux.so.2 is a symlink to
glibc. But glibc cannot be wholly broken because if it were, then
nothing would work at all.

I'd first investigate if only the symlink needs to be fixed (should
point to /lib/ld-.so).

Have you updated glibc recently?Or any other important package/package
from @system?
Have you tried if 'revdep-rebuild' finds any broken libraries?

If glibc is really broken you can

1. chroot into a stage3
2. build a binpkg (type 'quickpkg glibc')
3. copy the binpkg from
'/usr/portage/packages/sys-libs/glibc-*.tbz2' in the stage3 to
   the same directory in your new root
4. install the binary glibc ('emerge ')

Then you should have a clean glibc install.

If you suspect an update of breaking anything you can always build
binary packages ahead. They are built from the installed package, so you
don't have any additional compiling. Then you can roll back quickly if
anything is damaged.

If you have a working glibc then you could also try re-emerging pkg-config.

Regards
Johannes

Re: [gentoo-user] WARNING: Crucial MX300 drives SUUUUUCK!!!!

[Poison BL.]

On Mon, Feb 13, 2017 at 11:44 AM, Daniel Frey  wrote:

> On 02/12/2017 02:40 PM, Alan Grimes wrote:
> > So does anyone have any evidence of a current generation SSD lasting
> > more than 20 days?
> >
>
> I have tried various SSDs (multiple brands and generations) over the
> last maybe five years and found that they're very unreliable (multiple
> brands too.)
>
> I know everyone's saying these things are reliable but out of four SSDs
> I own, I've had to replace three, some more than once.
>
> I just don't use them for anything I want to stay working. Right now I
> keep them in my mythtv frontends as I can restore the OS easily. One one
> of them the company involved (Kingston) even sent me a newer drive/model
> as it was replaced more than once.
>
> I know they're fast. But what's the point of going 500 MPH and crashing
> into a mountain with no chance of repair/recovery. I went back to a
> (relatively) slower rust raid10, and it's been reliable for the last
> four years. At least with a hard drive failure, you stand /some/ chance
> at recovery, not zero.
>
> The one SSD that hasn't had to have been replaced under warranty is in
> my laptop which I generally use maybe a dozen times a year. I fully
> expect it to die one of these times when I boot the laptop (it's one of
> the old models.)
>
> My experiences are with Samsung, Kingston, Intel, Crucial and AData
> SSDs. The last one I bought because these things I view as throwaway
> devices (the warranty expired on the original Crucial) and don't want to
> spend big money on them. I have noticed the AData SSD's performance is
> not as fast now as it was new (maybe 1.5 years ago?) So it'll probably
> pack it in soon too.
>
> Dan
>
>
I've had more than one spinning rust drive fail hard over the years as
well, though yes, you do usually have some chance of recovery from those.
Gambling on that chance by leaving a given disk as a single point of
failure is still a bad idea, spinning disk or not. The point that you went
from single-disk SSD back to raid10 makes me question why, if your uptime
requirements (even if only for your own desires on a personal machine)
justify raid10, you weren't on at least raid1 with the SSD setup.

As for performance degredation on SSDs, that I've definitely seen on pretty
much every brand, though I've had good luck doing clean reloads on samsungs
once or twice to get speeds back up some (somehow, even trim doesn't seem
to keep things at their best).

I can't say they're more or less reliable than spinning disks, though they
do have the benefit of no moving parts to wear out over time (thermal
cycles can still cause a physical failure on them, though).

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] Building a new root for my Gentoo: Permission denied?

[Meino . Cramer]

Johannes Rosenberger  [17-02-13 19:04]:
> On 13.02.2017 17:57, meino.cra...@gmx.de wrote:
> 
> > Hogren  [17-02-13 17:06]:
> >> On 13/02/2017 04:42, meino.cra...@gmx.de wrote:
> >>> Hi,
> >>>
> >>> got a mysterious error message this morning (still building a new 
> >>> root...)
> >>>
> >>> One of the updates was gnutls:
> >>> It ends with:
> >>> ...
> >>> checking for i686-pc-linux-gnu-pkg-config... 
> >>> /usr/bin/i686-pc-linux-gnu-pkg-config
> >>> checking pkg-config is at least version 0.9.0... 
> >>> /var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9/configure: line 
> >>> 5020: /usr/bin/i686-pc-linux-gnu-pkg-config: Permission denied
> >>> no
> >>> checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
> >>> checking whether the C compiler works... yes
> >>> checking for C compiler default output file name... a.out
> >>> checking for suffix of executables... 
> >>> checking whether we are cross compiling... configure: error: in 
> >>> `/var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9-abi_x86_32.x86':
> >>> configure: error: cannot run C compiled programs.
> >>> If you meant to cross compile, use `--host'.
> >>> See `config.log' for more details
> >>> ...
> >>>
> >>> I tried:
> >>> computer# ldd /usr/bin/i686-pc-linux-gnu-pkg-config
> >>>   not a dynamic executable
> >>> computer# /usr/bin/i686-pc-linux-gnu-pkg-config 
> >>> zsh: permission denied: /usr/bin/i686-pc-linux-gnu-pkg-config
> >>>
> >>> computer# file /usr/bin/i686-pc-linux-gnu-pkg-config
> >>> /usr/bin/i686-pc-linux-gnu-pkg-config: ELF 32-bit LSB executable, Intel 
> >>> 80386, version 1 (SYSV), dynamically linked, interpreter 
> >>> /lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped, with debug_info
> >>>
> >>> I choosed multilib right from the beginning of this adventure ...
> >>>
> >>> How can I check, whether the problem is caysed by gnutls or by the 
> >>> system setup (regarding 32bit)?
> >>>
> >>> Cheers
> >>> Meino
> >>>
> >>>
> >>>
> >>>
> >>>
> >> Hello,
> >>
> >> Can you give us more details of what do you want to do, what do you
> >> already do, etc.
> >>
> >> Does /usr/bin/i686-pc-linux-gnu-pkg-config have the x (executable) 
> >> permission ? (ls -l /usr/bin/i686-pc-linux-gnu-pkg-config)
> >>
> >>
> >>
> >> Hogren
> >>
> >>
> >>
> >>
> > More mysterious hickups:
> >
>  Regenerating /etc/ld.so.cache...
> > /sbin/ldconfig: File /lib64/ld-linux.so.2 is empty, not checked.
> >
> > Did it screwed up my new root?
> >
> > Cheers
> > Meino
> >
> >
> >
> >
> Maybe. But maybe it is fixable. /lib64/ld-linux.so.2 is a symlink to
> glibc. But glibc cannot be wholly broken because if it were, then
> nothing would work at all.
> 
> I'd first investigate if only the symlink needs to be fixed (should
> point to /lib/ld-.so).
> 
> Have you updated glibc recently?Or any other important package/package
> from @system?
> Have you tried if 'revdep-rebuild' finds any broken libraries?
> 
> If glibc is really broken you can
> 
> 1. chroot into a stage3
> 2. build a binpkg (type 'quickpkg glibc')
> 3. copy the binpkg from
> '/usr/portage/packages/sys-libs/glibc-*.tbz2' in the stage3 to
>the same directory in your new root
> 4. install the binary glibc ('emerge ')
> 
> Then you should have a clean glibc install.
> 
> If you suspect an update of breaking anything you can always build
> binary packages ahead. They are built from the installed package, so you
> don't have any additional compiling. Then you can roll back quickly if
> anything is damaged.
> 
> If you have a working glibc then you could also try re-emerging pkg-config.
> 
> Regards
> Johannes
> 
> 

Hi Johannes,

thanks for your offered help! :)

I fixed that symlink but I ran into more weird problems... :(
Normally I alway run a revdep-rebuild cycle after each 
update...

How did you set ABI_X86 in make.conf?
Do you use multilib or a pure 64bit setup?

Cheers
Meino

Re: [gentoo-user] logrotate ... won't!

[Neil Bothwick]

On Sun, 12 Feb 2017 21:26:51 -0600, Dale wrote:

> >> Thanks Alexander, it pays going back to basics ... for some reason my
> >> cronie service was not running.  o_O
> >>
> >> I added it to default runlevel and hopefully it will do its magic
> >> from now on.  
> > I'm glad I'm not the only one prone to this kind of thing. :(
> >  
> 
> You're not.  ;-)


You're part of a large group of people that make such mistakes and a much
smaller group of those that admit to them ;-)


-- 
Neil Bothwick

One-seventh of life is spent on Monday.


pgpYV2FrAIoHU.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules

[marco restelli]

2017-02-10 13:35 GMT+01:00, Rich Freeman :
> On Fri, Feb 10, 2017 at 6:58 AM, marco restelli 
> wrote:
>> Hi all,
>>I am trying to understand a bit initramfs and genkernel and I have
>> few (basic) questions.
>
>> - how does genkernel decide which modules to put in the initramfs ?
>
> I can't speak to genkernel specifically, but most initramfs generators
> include all modules.  Other than space and miniscule load time there
> isn't much reason not to.

After checking, genkernel copies only some modules into the initramfs,
unless the --all-ramdisk-modules flag is used.

Concerning the rest of your reply: thank you so much, it really helped
me a lot!

Could you suggest any reference about how an initramfs can help making
it easier to identify the correct root filesystem? Does this
functionality overlap with what grub can do, or is something
different?

Thank you,
   Marco

[gentoo-user] Re: Kernel modules: initramfs vs. /lib/modules

[Remy Blank]

Daniel Frey wrote on 2017-02-13 17:34:
> On 02/13/2017 03:34 AM, Rich Freeman wrote:
>> Anytime you see something like root=UUID=* that is being handled by an
>> initramfs.  And of course a UUID is more reliable than a device name,
>> since the latter can change if you add/remove a device, or maybe even
>> if your firmware is having a bad day.  Identifying devices by UUID
>> ensures the right one gets found, assuming it is available.  If you're
>> using something like mdadm/lvm there are alternatives to UUID, but the
>> point is the same, you're using a logical identifier that is based on
>> what is stored on the disks and not just what port it is connected to.
>>
> 
> Are you sure? When I set up my EFI stub kernel on my Surface tablet, I
> did not use an initramfs and I use PARTUUID= in the kernel built in init
> line and it boots.

Note that Rich wrote "UUID=", but you used "PARTUUID=". The former
requires an initramfs, the latter doesn't. The details why escape me: if
the filesystem code is built into the kernel (as opposed to a module), I
see no practical reason why the FS UUID couldn't be determined by the
kernel directly.

> I thought I was going to have to use an initramfs but I tried without it
> and it boots with no issues.

Re: [gentoo-user] Re: Kernel modules: initramfs vs. /lib/modules

[Mike Gilbert]

On Mon, Feb 13, 2017 at 1:51 PM, Remy Blank  wrote:
> Daniel Frey wrote on 2017-02-13 17:34:
>> On 02/13/2017 03:34 AM, Rich Freeman wrote:
>>> Anytime you see something like root=UUID=* that is being handled by an
>>> initramfs.  And of course a UUID is more reliable than a device name,
>>> since the latter can change if you add/remove a device, or maybe even
>>> if your firmware is having a bad day.  Identifying devices by UUID
>>> ensures the right one gets found, assuming it is available.  If you're
>>> using something like mdadm/lvm there are alternatives to UUID, but the
>>> point is the same, you're using a logical identifier that is based on
>>> what is stored on the disks and not just what port it is connected to.
>>>
>>
>> Are you sure? When I set up my EFI stub kernel on my Surface tablet, I
>> did not use an initramfs and I use PARTUUID= in the kernel built in init
>> line and it boots.
>
> Note that Rich wrote "UUID=", but you used "PARTUUID=". The former
> requires an initramfs, the latter doesn't. The details why escape me: if
> the filesystem code is built into the kernel (as opposed to a module), I
> see no practical reason why the FS UUID couldn't be determined by the
> kernel directly.

Determining the FS UUID would require scanning all partitions of all
attached disks, and invoking filesystem-specific code to parse out the
UUID.

Determining the PARTUUID only requires scanning the partition table of
each drive, and is only supported for GPT and MBR partition tables.
It's a much simpler task.

Re: [gentoo-user] Building a new root for my Gentoo: Permission denied?

[Hogren]

On 13/02/2017 04:42, meino.cra...@gmx.de wrote:
> Hi,
>
> got a mysterious error message this morning (still building a new 
> root...)
>
> One of the updates was gnutls:
> It ends with:
> ...
> checking for i686-pc-linux-gnu-pkg-config... 
> /usr/bin/i686-pc-linux-gnu-pkg-config
> checking pkg-config is at least version 0.9.0... 
> /var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9/configure: line 
> 5020: /usr/bin/i686-pc-linux-gnu-pkg-config: Permission denied
> no
> checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... configure: error: in 
> `/var/tmp/portage/net-libs/gnutls-3.5.9/work/gnutls-3.5.9-abi_x86_32.x86':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> ...
>
> I tried:
> computer# ldd /usr/bin/i686-pc-linux-gnu-pkg-config
>   not a dynamic executable
> computer# /usr/bin/i686-pc-linux-gnu-pkg-config 
> zsh: permission denied: /usr/bin/i686-pc-linux-gnu-pkg-config
>
> computer# file /usr/bin/i686-pc-linux-gnu-pkg-config
> /usr/bin/i686-pc-linux-gnu-pkg-config: ELF 32-bit LSB executable, Intel 
> 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, 
> for GNU/Linux 2.6.32, stripped, with debug_info
>
> I choosed multilib right from the beginning of this adventure ...
>
> How can I check, whether the problem is caysed by gnutls or by the 
> system setup (regarding 32bit)?
>
> Cheers
> Meino
>
>
>
>
>

Hello,

Can you give us more details of what do you want to do, what do you
already do, etc.

Does /usr/bin/i686-pc-linux-gnu-pkg-config have the x (executable) permission ? 
(ls -l /usr/bin/i686-pc-linux-gnu-pkg-config)



Hogren