Re: [gentoo-user] bindmount or symlink?

[Alan McKinnon]

On Tue, 13 Mar 2012 12:04:00 +0700
Pandu Poluan  wrote:

> I am seriously thinking of splitting the storage of directories
> under /usr, e.g., /usr/portage and /usr/source actually living
> somewhere else, on different partition and different filesystem.
> Let's say something mounted on /mnt/Persistent.
> 
> My question: should I use bindmount or symlinks to do that? What's the
> drawbacks/benefits for either?
> 
> Rgds,

You should do neither as they do not give you split storage, they
both give you the same thing in two different places.

Create two new filesystems and mount them.

I personally use /var/portage as there is no good reason for it to be
under /usr where it is just clutter.

Code goes in /usr
Data goes in /var

You have to change PORTDIR in /etc/make.conf for this to work as well
as /etc/make.profile. Nothing breaks without it, you just get errors
from portage


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

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Alan McKinnon]

On Tue, 13 Mar 2012 02:41:15 +
Peter Humphrey  wrote:

> On Monday 12 March 2012 12:21:17 Neil Bothwick wrote:
> > On Sun, 11 Mar 2012 22:34:27 +0200, Alan McKinnon wrote:
> > > My mother swears blind I watched England win the World Cup but I
> > > don't remember (being only 1 year old at the time).
> > 
> > I fell asleep during it. To be fair I was nine and had just had an
> > overnight car journey returning from holiday.
> 
> I can't remember it at all, even though I was 23 or so. (Aside: my 
> father used to say that football is a game, and games are what
> children play.)
> 

Football is not a game.
Football is a religion.

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

Re: [gentoo-user] Can't boot upgraded kerne;

[Mick]

On Tuesday 13 Mar 2012 05:36:38 ro...@cs.wisc.edu wrote:
> I recently decided to update my AMD64 box from 2.38 to the new 3.2 kernel.
> I used genkernel all to compile the upgraded kernel but when I go to boot
> I get the following error.
> 
> >>Loading modules
> >>Determining root device
> 
> !!Block device /dev/sdb2 is not a valid root device
> !!Could not find the root block device in .
> Pleas specify another value or" press enter for the same, type "shell" for
> a shell, or "q"to skip..
> root block device()::
> 
> However at this point the computer is hung and I am no longer able to
> input anything. I just switched over to gentoo from bsd a year or so ago
> and am still a newbie at some of the installation procedures but I believe
> I have followed the manual correctly with the only change being that /boot
> is located on the root partition and not a seperate partition. I'm still
> able to use my older kernel without a problem and the only difference that
> I can note between the two is that older kernel seems to load in a bunch
> of modules and starts mdev, I believe, before trying to locate root. I am
> also using Lilo since my motherboard doesn't seem to like grub. Any help I
> could get would be appreciated.
> 
> roger
> 
> Here is a print out of lilo.conf
> boot=/dev/sdb
> map=/boot/map
> 
> prompt
> timeout=50
> default=Windows
> 
> image=/boot/kernel-genkernel-x86_64-2.6.38-gentoo-r6
>   label=2.6.38
>   read-only
>   append="real_root=/dev/sdb2"
>   vga=773
>   initrd=/boot/initramfs-genkernel-x86_64-2.6.38-gentoo-r6
> 
> image=/boot/kernel-genkernel-x86_64-3.2.1-gentoo-r2
>   label=3.2.1
>   read-only
>   append="real_root=/dev/sdb2"
>   initrd=/boot/initramfs-genkernel-x86_64-3.2.1-gentoo-r2
> 
> 
> other=/dev/sda1
>   label=Windows
> 
> 
> Here is a print out of fdisk
> Disk /dev/sdb: 80.0 GB, 80026361856 bytes
> 255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x37cd3650
> 
>Device Boot  Start End  Blocks   Id  System
> /dev/sdb1204812584959 6291456   82  Linux swap /
> Solaris /dev/sdb2   *1258496014682111 1048576   83  Linux
> /dev/sdb314682112   156301487708096885  Extended
> /dev/sdb51468416018878463 2097152   83  Linux
> /dev/sdb61888051223074815 2097152   83  Linux
> /dev/sdb7230768646501990320971520   83  Linux
> /dev/sdb865021952   15630148745639768   83  Linux
> 
> Here is a print out of fstab
> # /etc/fstab: static file system information.
> #
> # noatime turns off atimes for increased performance (atimes normally
> aren't # needed); notail increases performance of ReiserFS (at the expense
> of storage
> # efficiency).  It's safe to drop the noatime options if you want and to
> # switch between notail / tail freely.
> #
> # The root filesystem should have a pass number of either 0 or 1.
> # All other filesystems should have a pass number of 0 or greater than 1.
> #
> # See the manpage fstab(5) for more information.
> #
> 
> # 
> 
> 
> # NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
> /dev/sdb2/ext3noatime
>   0 1
> /dev/sdb1noneswapsw
> 0 0
> 
> /dev/sdb5/varext3defaults
>1 2
> /dev/sdb6/tmpext3defaults
>   1 2
> /dev/sdb7/usrext3defaults
>   1 2
> /dev/sdb8/homeext3defaults
>1 2
> 
> /dev/cdrom/mnt/cdromautonoauto,ro
>   0 0
> 
> /dev/sda2/mnt/Windowsntfsdefaults
>   1 2
> 
> proc /procproc
> defaults0 0
> shm/dev/shmtmpfs
> nodev,nouisd,noexec0 0
> 
> #tmpfs /var/tmp/portagetmpfs
> size=500M,mode=07770 0


In all likelihood you have not included in your kernel (built in, not as 
modules) the corresponding SATA controller driver.  Run a diff between old and 
new kernel .config to find out what's missing, or cp your old .config into your 
new kernel tree and run 'make oldconfig'.
-- 
Regards,
Mick


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

Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[Alan McKinnon]

On Tue, 13 Mar 2012 11:54:58 +0700
Pandu Poluan  wrote:

> > The idea of trying to launch udevd and initialize devices without
> > the software, installed in /usr, which is required by those devices
> > is a configuration that causes problems in many real-world,
> > practical situations.
> >
> > The requirement of having /usr on the same partition as / is also a
> > configuration that causes problems in many real-world, practical
> > situations.
> >
> 
> I quite often read about this, and after some thinking, I have to
> ask: why?
> 

I've also thought about this and I also want to ask why?

I stopped using a separate /usr on my workstations a long time ago when
I realized it was pointless. The days of 5M hard disks when the entire
OS didn't fit on one are long gone. The days of my software going tits
up at the drop of a hat requiring a minimal repair environment to fix
it at boot are also long gone (my desk is littered with LiveCDs and
bootable flash drives).

So I can't find a single good reason why /usr *must* be separate and my
workstations are the only machines that will ever have hotplug booting
issues.

I'm even considering changing the install standards for the company
servers to dispense with separate /usr, as long as there are safeguards
against clowns who don't read INSTALL files and happily
accept /usr/local//var as a storage area.

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

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Walter Dnes]

On Mon, Mar 12, 2012 at 09:24:32AM +, Alan Mackenzie wrote

> Help would be appreciated.

  Sorry, mdev is not for you, it looks like udev is a mandatory
dependancy for lvm2.  I tried "emerge -pv lvm2" and it came back with...

waltdnes@d530 ~ $ emerge -pv lvm2

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy ">=sys-fs/udev-151-r4" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-fs/udev-::gentoo (masked by: package.mask, missing keyword)
/etc/portage/package.mask:

  I'll update my instructions to mention this.  Thanks for your help.
Even a negative result, i.e. knowing what doesn't work, is one more
piece of information in my quest.

-- 
Walter Dnes 

Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[Pandu Poluan]

On Mar 13, 2012 2:19 PM, "Alan McKinnon"  wrote:
>
> On Tue, 13 Mar 2012 11:54:58 +0700
> Pandu Poluan  wrote:
>
> > > The idea of trying to launch udevd and initialize devices without
> > > the software, installed in /usr, which is required by those devices
> > > is a configuration that causes problems in many real-world,
> > > practical situations.
> > >
> > > The requirement of having /usr on the same partition as / is also a
> > > configuration that causes problems in many real-world, practical
> > > situations.
> > >
> >
> > I quite often read about this, and after some thinking, I have to
> > ask: why?
> >
>
> I've also thought about this and I also want to ask why?
>
> I stopped using a separate /usr on my workstations a long time ago when
> I realized it was pointless. The days of 5M hard disks when the entire
> OS didn't fit on one are long gone. The days of my software going tits
> up at the drop of a hat requiring a minimal repair environment to fix
> it at boot are also long gone (my desk is littered with LiveCDs and
> bootable flash drives).
>
> So I can't find a single good reason why /usr *must* be separate and my
> workstations are the only machines that will ever have hotplug booting
> issues.
>
> I'm even considering changing the install standards for the company
> servers to dispense with separate /usr, as long as there are safeguards
> against clowns who don't read INSTALL files and happily
> accept /usr/local//var as a storage area.
>

I just did some more thinking, and *maybe* the reason is to prevent
something under /usr (src and share comes to mind) from growing too big and
messes up the root filesystem.

Place the offenders on a separate partition, then mount them under /usr,
and all should be well...

Rgds,

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Walter Dnes]

On Mon, Mar 12, 2012 at 09:24:32AM +, Alan Mackenzie wrote

  Once you're back to your old setup, can you do me a favour?  Please do
the following...

1) Add the line...

sys-fs/udev

to /etc/portage/package.mask.


2) Run the 2 commands
emerge -pv system > system.txt
emerge -pv world > world.txt

3) Remove the "sys-fs/udev" entry from /etc/portage/package.mask.

and gzip or zip the files system.txt and world.txt and file-attach them.
My guess is that at the end of world.txt, there will be a complaint
about udev being masked.  I intend to add that sanity-check to the
instructions, so that people will know ahead of time whether or not
they'll run into this problem.

  Again, sorry about putting you through this trouble.  You did what a
beta tester is supposed to do, i.e. find problems/bugs.

-- 
Walter Dnes 

Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 1:31 AM, Pandu Poluan  wrote:
>
> On Mar 13, 2012 2:19 PM, "Alan McKinnon"  wrote:
>>
>> On Tue, 13 Mar 2012 11:54:58 +0700
>> Pandu Poluan  wrote:
>>
>> > > The idea of trying to launch udevd and initialize devices without
>> > > the software, installed in /usr, which is required by those devices
>> > > is a configuration that causes problems in many real-world,
>> > > practical situations.
>> > >
>> > > The requirement of having /usr on the same partition as / is also a
>> > > configuration that causes problems in many real-world, practical
>> > > situations.
>> > >
>> >
>> > I quite often read about this, and after some thinking, I have to
>> > ask: why?
>> >
>>
>> I've also thought about this and I also want to ask why?
>>
>> I stopped using a separate /usr on my workstations a long time ago when
>> I realized it was pointless. The days of 5M hard disks when the entire
>> OS didn't fit on one are long gone. The days of my software going tits
>> up at the drop of a hat requiring a minimal repair environment to fix
>> it at boot are also long gone (my desk is littered with LiveCDs and
>> bootable flash drives).
>>
>> So I can't find a single good reason why /usr *must* be separate and my
>> workstations are the only machines that will ever have hotplug booting
>> issues.
>>
>> I'm even considering changing the install standards for the company
>> servers to dispense with separate /usr, as long as there are safeguards
>> against clowns who don't read INSTALL files and happily
>> accept /usr/local//var as a storage area.
>>
>
> I just did some more thinking, and *maybe* the reason is to prevent
> something under /usr (src and share comes to mind) from growing too big and
> messes up the root filesystem.
>
> Place the offenders on a separate partition, then mount them under /usr, and
> all should be well...

The always used example is to have /usr shared as a read only NFS
partition among several workstations. In corporate environments it is
certainly used this way (or at least it was when I worked, and the way
I used it in my office seven or eight years ago).

Of course, for a normal desktop user, a separate /usr is basically useless.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[Pandu Poluan]

On Mar 13, 2012 2:41 PM, "Canek Peláez Valdés"  wrote:
>
> On Tue, Mar 13, 2012 at 1:31 AM, Pandu Poluan  wrote:
> >
> > On Mar 13, 2012 2:19 PM, "Alan McKinnon" 
wrote:
> >>
> >> On Tue, 13 Mar 2012 11:54:58 +0700
> >> Pandu Poluan  wrote:
> >>
> >> > > The idea of trying to launch udevd and initialize devices without
> >> > > the software, installed in /usr, which is required by those devices
> >> > > is a configuration that causes problems in many real-world,
> >> > > practical situations.
> >> > >
> >> > > The requirement of having /usr on the same partition as / is also a
> >> > > configuration that causes problems in many real-world, practical
> >> > > situations.
> >> > >
> >> >
> >> > I quite often read about this, and after some thinking, I have to
> >> > ask: why?
> >> >
> >>
> >> I've also thought about this and I also want to ask why?
> >>
> >> I stopped using a separate /usr on my workstations a long time ago when
> >> I realized it was pointless. The days of 5M hard disks when the entire
> >> OS didn't fit on one are long gone. The days of my software going tits
> >> up at the drop of a hat requiring a minimal repair environment to fix
> >> it at boot are also long gone (my desk is littered with LiveCDs and
> >> bootable flash drives).
> >>
> >> So I can't find a single good reason why /usr *must* be separate and my
> >> workstations are the only machines that will ever have hotplug booting
> >> issues.
> >>
> >> I'm even considering changing the install standards for the company
> >> servers to dispense with separate /usr, as long as there are safeguards
> >> against clowns who don't read INSTALL files and happily
> >> accept /usr/local//var as a storage area.
> >>
> >
> > I just did some more thinking, and *maybe* the reason is to prevent
> > something under /usr (src and share comes to mind) from growing too big
and
> > messes up the root filesystem.
> >
> > Place the offenders on a separate partition, then mount them under
/usr, and
> > all should be well...
>
> The always used example is to have /usr shared as a read only NFS
> partition among several workstations. In corporate environments it is
> certainly used this way (or at least it was when I worked, and the way
> I used it in my office seven or eight years ago).
>
> Of course, for a normal desktop user, a separate /usr is basically
useless.
>

Ah, thanks for the explanation. Makes sense.

Rgds,

Re: [gentoo-user] bindmount or symlink?

[Pandu Poluan]

On Mar 13, 2012 2:00 PM, "Alan McKinnon"  wrote:
>
> On Tue, 13 Mar 2012 12:04:00 +0700
> Pandu Poluan  wrote:
>
> > I am seriously thinking of splitting the storage of directories
> > under /usr, e.g., /usr/portage and /usr/source actually living
> > somewhere else, on different partition and different filesystem.
> > Let's say something mounted on /mnt/Persistent.
> >
> > My question: should I use bindmount or symlinks to do that? What's the
> > drawbacks/benefits for either?
> >
> > Rgds,
>
> You should do neither as they do not give you split storage, they
> both give you the same thing in two different places.
>
> Create two new filesystems and mount them.
>
> I personally use /var/portage as there is no good reason for it to be
> under /usr where it is just clutter.
>
> Code goes in /usr
> Data goes in /var
>
> You have to change PORTDIR in /etc/make.conf for this to work as well
> as /etc/make.profile. Nothing breaks without it, you just get errors
> from portage
>

Eh? But I put portage, src, share, etc. on a different partition mounted
under /mnt ... doesn't that mean I am using a split filesystem?

Rgds,

Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[Walter Dnes]

On Mon, Mar 12, 2012 at 06:22:39PM -0500, Dale wrote

> I think mdev has shown it can be fixed.  Given time, it just may replace
> udev then the udev dev can screw up his own stuff on not bother other
> distros.  I'm giving mdev some thought here.  I want /usr on LVM which
> means it has to be separate.

  Sorry, in lste-breaking news, it looks like udev is a mandatory
dependancy for lvm2.  No udev ==> No lvm2

  Can you run a test for me?  What happens when you...

1) insert the line
sys-fs/udev
into /etc/portage/package.mask

2) execute "emerge -pv system"

3) execute "emerge -pv world"

4) Remember to remove the "sys-fs/udev" line from package.mask

  I expect that you should get an error message about not being able to
emerge lvm2 due to udev being masked.  This is something I intend to add
to the instructions, so people can check ahead of time whether their
particular setup is able to run without udev.

-- 
Walter Dnes 

Re: [gentoo-user] bindmount or symlink?

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 2:05 AM, Pandu Poluan  wrote:
>
> On Mar 13, 2012 2:00 PM, "Alan McKinnon"  wrote:
>>
>> On Tue, 13 Mar 2012 12:04:00 +0700
>> Pandu Poluan  wrote:
>>
>> > I am seriously thinking of splitting the storage of directories
>> > under /usr, e.g., /usr/portage and /usr/source actually living
>> > somewhere else, on different partition and different filesystem.
>> > Let's say something mounted on /mnt/Persistent.
>> >
>> > My question: should I use bindmount or symlinks to do that? What's the
>> > drawbacks/benefits for either?
>> >
>> > Rgds,
>>
>> You should do neither as they do not give you split storage, they
>> both give you the same thing in two different places.
>>
>> Create two new filesystems and mount them.
>>
>> I personally use /var/portage as there is no good reason for it to be
>> under /usr where it is just clutter.
>>
>> Code goes in /usr
>> Data goes in /var
>>
>> You have to change PORTDIR in /etc/make.conf for this to work as well
>> as /etc/make.profile. Nothing breaks without it, you just get errors
>> from portage
>>
>
> Eh? But I put portage, src, share, etc. on a different partition mounted
> under /mnt ... doesn't that mean I am using a split filesystem?

You are; but in an incredible complicated and convulted way.

If I'm understanding you, you want:

fstab:
/dev/XX   /mnt/p1   ...
/dev/YY   /mnt/p2   ...

and then

/usr/portage -> /mnt/p1
/usr/src -> /mnt/p2

(or using bindmounting, whatever).

This makes no sense at all (at least not to me), when you can simply:

fstab:
/dev/XX   /usr/portage   ...
/dev/YY   /usr/src   ...

and get the same split filesystem, but without all the complication
you are proposing.

Unless there is something I don't understand, in which case I'm not
following your reasoning.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] LVM, /usr and really really bad thoughts.

[Walter Dnes]

On Sat, Mar 10, 2012 at 09:50:02PM +0100, pk wrote

> So udev-181 (masked) is ok to use without initrd and separate /usr
> then? Thanks for the info!

  I believe that 180 or 181 is the first version that requires /usr on /
(or an initramfs or whatever).  And that's why it's currently masked.

-- 
Walter Dnes 

Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 2:09 AM, Walter Dnes  wrote:
> On Mon, Mar 12, 2012 at 06:22:39PM -0500, Dale wrote
>
>> I think mdev has shown it can be fixed.  Given time, it just may replace
>> udev then the udev dev can screw up his own stuff on not bother other
>> distros.  I'm giving mdev some thought here.  I want /usr on LVM which
>> means it has to be separate.
>
>  Sorry, in lste-breaking news, it looks like udev is a mandatory
> dependancy for lvm2.  No udev ==> No lvm2

It seems so; from lvm2 2.02.93:

DEPEND_COMMON="!!sys-fs/device-mapper
readline? ( sys-libs/readline )
clvm? ( =sys-cluster/dlm-2*
cman? ( =sys-cluster/cman-2* ) )
>=sys-fs/udev-151-r4"

...

econf $(use_enable readline) \
$(use_enable selinux) \
--enable-pkgconfig \
--with-confdir="${EPREFIX}/etc" \
--sbindir="${EPREFIX}/sbin" \
--with-staticdir="${EPREFIX}/sbin" \
--libdir="${EPREFIX}/$(get_libdir)" \
--with-usrlibdir="${EPREFIX}/usr/$(get_libdir)" \
--enable-udev_rules \
--enable-udev_sync \
--with-udevdir="${EPREFIX}/lib/udev/rules.d/" \
${myconf} \
CLDFLAGS="${LDFLAGS}" || die

Maybe you could try to modify the LVM ebuild to point udevdir to a
black hole and disable udev_rules and udev_sync. But that would be at
best a hack; I'm not familiar enough with the LVM code to know if they
actually need udev to run, or it only installs some rules so it can
run better with it.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Can I do a one-time boot to non-default kernel in Lilo?

[Walter Dnes]

On Sun, Mar 11, 2012 at 11:35:33PM -0400, Bruce Hill, Jr. wrote

> Unless I misunderstand you, after you issue "lilo" to write to the MBR,
> then issue:
> lilo -R experimental
> 
> where experimental is the name of the kernel image you want to boot. The R
> creates a one time command which it will use the next time you boot, then
> it will be erased.
> 
> And give the kernel an append statement:
> append="panic=10"
> 
> so that if the kernel does not boot, you get automatically rebooted back
> into the good kernel.

  Thanks.  That's exactly what I was looking for.  I vaguely remembered
reading about something this, but my Google-fu didn't quite work.

-- 
Walter Dnes 

Re: [gentoo-user] bindmount or symlink?

[Philipp Riegger]

On 13.03.2012 09:15, Canek Peláez Valdés wrote:

If I'm understanding you, you want:

fstab:
/dev/XX   /mnt/p1   ...
/dev/YY   /mnt/p2   ...

and then

/usr/portage ->  /mnt/p1
/usr/src ->  /mnt/p2

(or using bindmounting, whatever).

This makes no sense at all (at least not to me), when you can simply:

fstab:
/dev/XX   /usr/portage   ...
/dev/YY   /usr/src   ...

and get the same split filesystem, but without all the complication
you are proposing.

Unless there is something I don't understand, in which case I'm not
following your reasoning.


There are 2 possible things one can do:

1) Split everything, /usr, /usr/src, /usr/portage each on a seperate 
filesystem.
2) Seperate multiple paths from /usr: Have 1 fs /mnt/data and link (or 
bind mount) /usr/src, /usr/portage there. You have a shared fs for dirx, 
that are usually not shared.


What would be the benefits of symlinks and bind mounts for doing 2)?

Philipp

Re: [gentoo-user] bindmount or symlink?

[Pandu Poluan]

On Tue, Mar 13, 2012 at 15:15, Canek Peláez Valdés  wrote:
>
> You are; but in an incredible complicated and convulted way.
>
> If I'm understanding you, you want:
>
> fstab:
> /dev/XX   /mnt/p1   ...
> /dev/YY   /mnt/p2   ...
>
> and then
>
> /usr/portage -> /mnt/p1
> /usr/src -> /mnt/p2
>
> (or using bindmounting, whatever).
>
> This makes no sense at all (at least not to me), when you can simply:
>
> fstab:
> /dev/XX   /usr/portage   ...
> /dev/YY   /usr/src   ...
>
> and get the same split filesystem, but without all the complication
> you are proposing.
>
> Unless there is something I don't understand, in which case I'm not
> following your reasoning.
>

The point is: It's not just 2 (two) directories, but several of them,
and I just can't see myself creating a partition (or an LV) for each
and everyone of them.

So, here's my thoughts:

There are 2 filesystems that are suitable for different purposes:
* reiserfs = for space efficiency (w/o notail option) and/or no inode#
limitation
* ext4 = for general purpose

The directories I'm going to split:

/usr/share ==> ext4
/usr/portage ==> reiserfs
/usr/portage/packages ==> ext4
/usr/portage/distfiles ==> ext4
/usr/src ==> reiserfs
/var/cache/rtorrent (don't ask) ==> reiserfs
/var/spool/postfix ==> ext4
/var/lib/postgresql ==> ext4

Now, I create 2 partitions:

/dev/sdc1 (reiserfs) --> /mnt/Persistent1
/dev/sdd1 (ext4) --> /mnt/Persistent2

Then I create subdirectories:

/mnt/Persistent1/portage
/mnt/Persistent1/src
/mnt/Persistent1/rtorrent

/mnt/Persistent2/share
/mnt/Persistent2/packages
/mnt/Persistent2/distfiles
/mnt/Persistent2/postfix
/mnt/Persistent2/postgresql

Finally, I need to redirect the directories-I-want-to-split to the
above subdirs under /mnt/Persistent[12]

SO.

mount -o bind ... or ln -s ?

Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

[gentoo-user] Update of cryptsetup 1.4.1 fails

[Uwe Scholz]

Hi,

I have an annoying problem with the current version update of
cryptsetup-1.4.1. Already in the configure step emerge stops with the
error message:

...
checking for gcry_check_version in -lgcrypt... no
configure: error: Cannot find static gcrypt library
...

Actually, libgcrypt-1.4.6 is installed with the static-libs flag. Also
after reemerging libgcrypt the update to cryptsetup-1.4.1 fails.

I'm working on a amd64 machine, cryptsetup useflags are "static"
(compulsory) and "nls". Can anyone confirm this problem and has a
solution for it?

Thanks in advance,
Uwe


pgpzcZmqpqT8N.pgp
Description: PGP signature

Re: [gentoo-user] bindmount or symlink?

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 3:00 AM, Pandu Poluan  wrote:
> On Tue, Mar 13, 2012 at 15:15, Canek Peláez Valdés  wrote:
>>
>> You are; but in an incredible complicated and convulted way.
>>
>> If I'm understanding you, you want:
>>
>> fstab:
>> /dev/XX   /mnt/p1   ...
>> /dev/YY   /mnt/p2   ...
>>
>> and then
>>
>> /usr/portage -> /mnt/p1
>> /usr/src -> /mnt/p2
>>
>> (or using bindmounting, whatever).
>>
>> This makes no sense at all (at least not to me), when you can simply:
>>
>> fstab:
>> /dev/XX   /usr/portage   ...
>> /dev/YY   /usr/src   ...
>>
>> and get the same split filesystem, but without all the complication
>> you are proposing.
>>
>> Unless there is something I don't understand, in which case I'm not
>> following your reasoning.
>>
>
> The point is: It's not just 2 (two) directories, but several of them,
> and I just can't see myself creating a partition (or an LV) for each
> and everyone of them.
>
> So, here's my thoughts:
>
> There are 2 filesystems that are suitable for different purposes:
> * reiserfs = for space efficiency (w/o notail option) and/or no inode#
> limitation
> * ext4 = for general purpose
>
> The directories I'm going to split:
>
> /usr/share ==> ext4
> /usr/portage ==> reiserfs
> /usr/portage/packages ==> ext4
> /usr/portage/distfiles ==> ext4
> /usr/src ==> reiserfs
> /var/cache/rtorrent (don't ask) ==> reiserfs
> /var/spool/postfix ==> ext4
> /var/lib/postgresql ==> ext4
>
> Now, I create 2 partitions:
>
> /dev/sdc1 (reiserfs) --> /mnt/Persistent1
> /dev/sdd1 (ext4) --> /mnt/Persistent2
>
> Then I create subdirectories:
>
> /mnt/Persistent1/portage
> /mnt/Persistent1/src
> /mnt/Persistent1/rtorrent
>
> /mnt/Persistent2/share
> /mnt/Persistent2/packages
> /mnt/Persistent2/distfiles
> /mnt/Persistent2/postfix
> /mnt/Persistent2/postgresql
>
> Finally, I need to redirect the directories-I-want-to-split to the
> above subdirs under /mnt/Persistent[12]
>
> SO.
>
> mount -o bind ... or ln -s ?

OK, now I understand. I still think is kinda crazy, but to each its own.

I would definitely use symlinks.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] bindmount or symlink?

[Nilesh Govindrajan]

On Mar 13, 2012 2:42 PM, "Canek Peláez Valdés"  wrote:
>
> On Tue, Mar 13, 2012 at 3:00 AM, Pandu Poluan  wrote:
> > On Tue, Mar 13, 2012 at 15:15, Canek Peláez Valdés 
wrote:
> >>
> >> You are; but in an incredible complicated and convulted way.
> >>
> >> If I'm understanding you, you want:
> >>
> >> fstab:
> >> /dev/XX   /mnt/p1   ...
> >> /dev/YY   /mnt/p2   ...
> >>
> >> and then
> >>
> >> /usr/portage -> /mnt/p1
> >> /usr/src -> /mnt/p2
> >>
> >> (or using bindmounting, whatever).
> >>
> >> This makes no sense at all (at least not to me), when you can simply:
> >>
> >> fstab:
> >> /dev/XX   /usr/portage   ...
> >> /dev/YY   /usr/src   ...
> >>
> >> and get the same split filesystem, but without all the complication
> >> you are proposing.
> >>
> >> Unless there is something I don't understand, in which case I'm not
> >> following your reasoning.
> >>
> >
> > The point is: It's not just 2 (two) directories, but several of them,
> > and I just can't see myself creating a partition (or an LV) for each
> > and everyone of them.
> >
> > So, here's my thoughts:
> >
> > There are 2 filesystems that are suitable for different purposes:
> > * reiserfs = for space efficiency (w/o notail option) and/or no inode#
> > limitation
> > * ext4 = for general purpose
> >
> > The directories I'm going to split:
> >
> > /usr/share ==> ext4
> > /usr/portage ==> reiserfs
> > /usr/portage/packages ==> ext4
> > /usr/portage/distfiles ==> ext4
> > /usr/src ==> reiserfs
> > /var/cache/rtorrent (don't ask) ==> reiserfs
> > /var/spool/postfix ==> ext4
> > /var/lib/postgresql ==> ext4
> >
> > Now, I create 2 partitions:
> >
> > /dev/sdc1 (reiserfs) --> /mnt/Persistent1
> > /dev/sdd1 (ext4) --> /mnt/Persistent2
> >
> > Then I create subdirectories:
> >
> > /mnt/Persistent1/portage
> > /mnt/Persistent1/src
> > /mnt/Persistent1/rtorrent
> >
> > /mnt/Persistent2/share
> > /mnt/Persistent2/packages
> > /mnt/Persistent2/distfiles
> > /mnt/Persistent2/postfix
> > /mnt/Persistent2/postgresql
> >
> > Finally, I need to redirect the directories-I-want-to-split to the
> > above subdirs under /mnt/Persistent[12]
> >
> > SO.
> >
> > mount -o bind ... or ln -s ?
>
> OK, now I understand. I still think is kinda crazy, but to each its own.
>
> I would definitely use symlinks.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>

For critically performance wise, I think bindmounts would do better because
it is done at kernel level whereas symlinks will have to be resolved on
access, no dobut a kernel maintains cache but I can't really say much about
it because I don't know the code behind either.

--
Nilesh Govindrajan
http://nileshgr.com

Re: [gentoo-user] bindmount or symlink?

[Alan McKinnon]

On Tue, 13 Mar 2012 15:05:59 +0700
Pandu Poluan  wrote:

> On Mar 13, 2012 2:00 PM, "Alan McKinnon" 
> wrote:
> >
> > On Tue, 13 Mar 2012 12:04:00 +0700
> > Pandu Poluan  wrote:
> >
> > > I am seriously thinking of splitting the storage of directories
> > > under /usr, e.g., /usr/portage and /usr/source actually living
> > > somewhere else, on different partition and different filesystem.
> > > Let's say something mounted on /mnt/Persistent.
> > >
> > > My question: should I use bindmount or symlinks to do that?
> > > What's the drawbacks/benefits for either?
> > >
> > > Rgds,
> >
> > You should do neither as they do not give you split storage, they
> > both give you the same thing in two different places.
> >
> > Create two new filesystems and mount them.
> >
> > I personally use /var/portage as there is no good reason for it to
> > be under /usr where it is just clutter.
> >
> > Code goes in /usr
> > Data goes in /var
> >
> > You have to change PORTDIR in /etc/make.conf for this to work as
> > well as /etc/make.profile. Nothing breaks without it, you just get
> > errors from portage
> >
> 
> Eh? But I put portage, src, share, etc. on a different partition
> mounted under /mnt ... doesn't that mean I am using a split
> filesystem?

Do you have separate filesystems for each of those directories, or one
big storage area? I'm struggling to find out what you are trying to
accomplish and what problem that is a solution for.


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

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Neil Bothwick]

On Tue, 13 Mar 2012 02:41:15 +, Peter Humphrey wrote:

> I can't remember it at all, even though I was 23 or so. (Aside: my 
> father used to say that football is a game, and games are what children 
> play.)

Yes, but that doesn't mean no one else plays them. That's the sort of
argument that could only be used by a parent on a child :-O


-- 
Neil Bothwick

We can sympathize with a child who is afraid of the dark, but the
tragedy of life is that most people are afraid of the light.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[Neil Bothwick]

On Tue, 13 Mar 2012 01:38:26 -0600, Canek Peláez Valdés wrote:

> Of course, for a normal desktop user, a separate /usr is basically
> useless.

If you need to encrypt /etc but don't want the overhead of encrypting
everything is /usr, which is basically publicly available files anyway,
separating / and /usr makes sense. Compiling a kernel already takes long
enough on a lower powered machine, encrypting /usr/src only makes it
worse.


-- 
Neil Bothwick

C:\BELFRY is where I keep my .BAT files ^^^oo^^^


signature.asc
Description: PGP signature

Re: [gentoo-user] bindmount or symlink?

[Alan McKinnon]

On Tue, 13 Mar 2012 16:00:08 +0700
Pandu Poluan  wrote:

> On Tue, Mar 13, 2012 at 15:15, Canek Peláez Valdés 
> wrote:
> >
> > You are; but in an incredible complicated and convulted way.
> >
> > If I'm understanding you, you want:
> >
> > fstab:
> > /dev/XX   /mnt/p1   ...
> > /dev/YY   /mnt/p2   ...
> >
> > and then
> >
> > /usr/portage -> /mnt/p1
> > /usr/src -> /mnt/p2
> >
> > (or using bindmounting, whatever).
> >
> > This makes no sense at all (at least not to me), when you can
> > simply:
> >
> > fstab:
> > /dev/XX   /usr/portage   ...
> > /dev/YY   /usr/src   ...
> >
> > and get the same split filesystem, but without all the complication
> > you are proposing.
> >
> > Unless there is something I don't understand, in which case I'm not
> > following your reasoning.
> >
> 
> The point is: It's not just 2 (two) directories, but several of them,
> and I just can't see myself creating a partition (or an LV) for each
> and everyone of them.
> 
> So, here's my thoughts:
> 
> There are 2 filesystems that are suitable for different purposes:
> * reiserfs = for space efficiency (w/o notail option) and/or no inode#
> limitation
> * ext4 = for general purpose
> 
> The directories I'm going to split:
> 
> /usr/share ==> ext4
> /usr/portage ==> reiserfs
> /usr/portage/packages ==> ext4
> /usr/portage/distfiles ==> ext4
> /usr/src ==> reiserfs
> /var/cache/rtorrent (don't ask) ==> reiserfs
> /var/spool/postfix ==> ext4
> /var/lib/postgresql ==> ext4
> 
> Now, I create 2 partitions:
> 
> /dev/sdc1 (reiserfs) --> /mnt/Persistent1
> /dev/sdd1 (ext4) --> /mnt/Persistent2
> 
> Then I create subdirectories:
> 
> /mnt/Persistent1/portage
> /mnt/Persistent1/src
> /mnt/Persistent1/rtorrent
> 
> /mnt/Persistent2/share
> /mnt/Persistent2/packages
> /mnt/Persistent2/distfiles
> /mnt/Persistent2/postfix
> /mnt/Persistent2/postgresql
> 
> Finally, I need to redirect the directories-I-want-to-split to the
> above subdirs under /mnt/Persistent[12]
> 
> SO.
> 
> mount -o bind ... or ln -s ?
> 
> Rgds,

Ah, now I see. You have many sub-directories of /usr that you don't
want to be part of the same volume as /usr. This is quite valid, I can
think of several lines of reasoning:

- you'd rather not have the pain of dealing with many smaller
  filesystems even if LVM is available.
- you just want a large storage area for "stuffs", and don't feel like
  finding out how much space each one needs
- you'd rather keep the bulk of /usr static and don't growing much

So instead make two big mount points in /mnt, one each for the
destination filesystem types you are interested in and link the
subdirectories there to the right place in /usr.

You want bindmounts for that.

Someone else here (I forget whom) did the same thing with his home
directories and /var. It's a valid need, but rare. And nobody else
understood his reasoning for a long time either :-)


OT: I can't wait for the day when ZFS- and btrfs-like filesystems are
the norm and we can dispense with all this physical disk, partitions,
LVM, volumes, file systems and mounting nonsense.

I want this model: I have X bytes of storage, I would like Y bytes to
be mounted here with these charactertics, and Z bytes mounted there
with those characteristics. Kernel, make it so, thanksverymuch and
have a nice day

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

Re: [gentoo-user] How are Fn-F# ACPI events mapped?

[YoYo Siska]

On Sun, Mar 11, 2012 at 03:23:28PM -0700, Mark Knecht wrote:
> Hi,
>I'm trying to figure out how my Asus laptop maps function key
> events. This is being driven by an emerge message telling me that the
> acpi4asus package is being obsoleted and removed in 30 days and
> replaced by an in-kernel driver. I've removed the package and rebuilt
> my kernels to use this driver, and for vanilla-sources-3.2.7 the
> results are similar as with the acpi4asus package.

don't know anything about the assus packages/drivers, but the general
direction in all such drivers is to move these things where they belong:
to the input subsystem, so my guess is the new driver doesn't produce
acpi events, but insted create a "input device" and produce key
press/release events on that device...

(note that sleep / hibernate actions are usually still reported also
throgh acpi, because some programs expect them to come from there, that
would explaing your Fn-F1/sleep working)

to test this, just run as root on the linux console (not in a termnal in
X):

showkey -s

and then pres the keys (ie Fn-F4,) to stop showkeys, just don't press
anything for 10 seconds...
if you see numbers appearing after each keypress / release, then the key
directly generates keyboard ivents  and its possible you will see them
directly in X, for that jus run (now under X)

xev

and (the window that appears must have focus / be active) press the keys
again, xev will print the X keycodes/keysyms to its output...
if you see reasonable names there, then you should be able to map those
keys in the programs you are using (ie global hotkeys in kde, etc...)
note however that qt/kde doesn't recognise some of the more exotic
keysyms...  (in my case XF86TouchpadToggle produced by Fn-F8 on
thinkpads ;)

if you can see the key in showkey -s  but not in xev, the problem might
be in kernel keyboard map (though i'm not sure if the x's evdev driver
uses that) or in the evdev driver not mapping that key

basically the kernel driver reports scan codes (what showkey -s shows),
kernel translates that to keycodes (showkey -k to see them) and then X's
input driver (ie evdev) translates those to the X keycodes X server
again trasnlates them to keysym-s

yoyo



> 
>However, for vanilla-sources-3.2.9 the only key that is doing
> anything seems to be Fn-F1 which says 'button/sleep' (using
> acpi_listen) but actually just turns on the screen saver as best I can
> tell.
> 
>Note that even with 3.2.7 most keys don't actually work, but at
> least they all produce acpi_listen events. The only ones that do work
> in 3.2.7 and earlier are:
> 
> Fn-F1 - screen saver
> Fn-F5 - turns off screen but doesn't seem to generate an ACPI event in
> acpi_listen (may be hardware mapped)
> Fn-F11 - turn volume down
> Fn-F12 - turn volume up
> 
> I haven't tested the external monitor one.
> 
>The ones I really want to figure out are Fn-F3 & F4 as they turn
> the keyboard lighting up and down. With 3.2.7 I had lighting, but with
> 3.2.9 I have no keyboard lighting at all so it will have hard to use
> in the dark.
> 
>Before I call this a 3.2.9 regression I figured I should determine
> if I'm supposed to configure this stuff by hand, or maybe load some
> new machine specific package that sets up the mappings.
> 
> Thanks in advance,
> Mark
> 
> 
> vanilla-sources-3.2.9
> 
> slinky events # acpi_listen
> button/sleep SLPB 0080 0003
> button/sleep SLPB 0080 0004
> 
> 
> 
> vanilla-sources-3.2.7
> 
> slinky ~ # acpi_listen
> button/sleep SLPB 0080 0001
> hotkey ATKD 005d 
> hotkey ATKD 007e 
> hotkey ATKD 00c5 
> hotkey ATKD 00c4 
> hotkey ATKD 002e 
> hotkey ATKD 001a 
> hotkey ATKD 0034 
> hotkey ATKD 0033 
> hotkey ATKD 0034 0001
> hotkey ATKD 0033 0001
> hotkey ATKD 0061 
> hotkey ATKD 006b 
> hotkey ATKD 0032 
> hotkey ATKD 0032 0001
> hotkey ATKD 0032 0002
> hotkey ATKD 0031 
> hotkey ATKD 0031 0001
> hotkey ATKD 0031 0002
> hotkey ATKD 0030 
> hotkey ATKD 0030 0001
> hotkey ATKD 0030 0002
> hotkey ATKD 0030 0003
> 

Re: [gentoo-user] Best file system for portage tree?

[YoYo Siska]

On Mon, Mar 12, 2012 at 10:23:49AM +0100, Alex Schuster wrote:
> José Romildo Malaquias writes:
> 
> > On Sat, Mar 10, 2012 at 07:36:07PM +0100, YoYo Siska wrote:
> 
> > > mke2fs -f -b1024 -i2048 /usr/img_portage
> > 
> > The -f option from mke2fs is to specify a fragment size and expects an
> > argument. Do you -F (which forces mke2fs to create a filesystem, even if
> > the specified device is not a partittion on a block special device)?
> 
> I'm pretty sure that's what he meant, without the -F you need to confirm
> that you really want to create the FS. I forgot to mention this when I
> also quoted this line in my reply.
> 

yes, that's exactly what I had in mind
was writing that from memory and forgot the the case... 
thanks for the correction

yoyo

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

Hello, Walter.

On Tue, Mar 13, 2012 at 03:14:55AM -0400, Walter Dnes wrote:
> On Mon, Mar 12, 2012 at 09:24:32AM +, Alan Mackenzie wrote

>   Sorry, mdev is not for you, it looks like udev is a mandatory
> dependancy for lvm2.  I tried "emerge -pv lvm2" and it came back with...

> waltdnes@d530 ~ $ emerge -pv lvm2

> These are the packages that would be merged, in order:

> Calculating dependencies... done!

> !!! All ebuilds that could satisfy ">=sys-fs/udev-151-r4" have been masked.
> !!! One of the following masked packages is required to complete your request:
> - sys-fs/udev-::gentoo (masked by: package.mask, missing keyword)
> /etc/portage/package.mask:

>   I'll update my instructions to mention this.  Thanks for your help.
> Even a negative result, i.e. knowing what doesn't work, is one more
> piece of information in my quest.

It seems it's not quite as simple as that.  I've looked at it again, and
after booting (unsuccessfuly (without non-root partitions)), the devices
/dev/md-0, /dev/md-1,  existed.  Also existing was the directory
/dev/mapper, containing devices like /dev/mapper/vg-usr.  (They're sort
of symlinks, I think).

When I mounted all of these LVM partitions by hand, my system worked
(modulo the services which had failed to start).  So I then modified my
/etc/fstab to use /dev/mapper/vg-usr, and my system came up (almost).
What didn't work was X-Windows - when I started it, the keyboard and
mouse were dead.  (Good job the reset button still worked.)

I don't know if booting this way loses any LVM functionality.  I haven't
tested that out yet.  I suspect it will.

The only other wierd thing was, when I restarted my "working" system,
eth0 was missing.  When I rebooted, it was there again.

> -- 
> Walter Dnes 

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Can't boot upgraded kerne;

[Bruce Hill, Jr.]

On March 13, 2012 at 3:10 AM Mick  wrote:

> On Tuesday 13 Mar 2012 05:36:38 ro...@cs.wisc.edu wrote:
> > I recently decided to update my AMD64 box from 2.38 to the new 3.2
kernel.
> > I used genkernel all to compile the upgraded kernel but when I go to
boot
> > I get the following error.
> >
> > >>Loading modules
> > >>Determining root device
> >
> > !!Block device /dev/sdb2 is not a valid root device
> > !!Could not find the root block device in .
> > Pleas specify another value or" press enter for the same, type "shell"
for
> > a shell, or "q"to skip..
> > root block device()::
> >
> > However at this point the computer is hung and I am no longer able to
> > input anything. I just switched over to gentoo from bsd a year or so
ago
> > and am still a newbie at some of the installation procedures but I
believe
> > I have followed the manual correctly with the only change being that
/boot
> > is located on the root partition and not a seperate partition. I'm
still
> > able to use my older kernel without a problem and the only difference
that
> > I can note between the two is that older kernel seems to load in a
bunch
> > of modules and starts mdev, I believe, before trying to locate root. I
am
> > also using Lilo since my motherboard doesn't seem to like grub. Any
help I
> > could get would be appreciated.
> >
> > roger
> >
> > Here is a print out of lilo.conf
> > boot=/dev/sdb
> > map=/boot/map
> >
> > prompt
> > timeout=50
> > default=Windows
> >
> > image=/boot/kernel-genkernel-x86_64-2.6.38-gentoo-r6
> >   label=2.6.38
> >   read-only
> >   append="real_root=/dev/sdb2"
> >   vga=773
> >   initrd=/boot/initramfs-genkernel-x86_64-2.6.38-gentoo-r6
> >
> > image=/boot/kernel-genkernel-x86_64-3.2.1-gentoo-r2
> >   label=3.2.1
> >   read-only
> >   append="real_root=/dev/sdb2"
> >   initrd=/boot/initramfs-genkernel-x86_64-3.2.1-gentoo-r2
> >
> >
> > other=/dev/sda1
> >   label=Windows
> >
> >
> > Here is a print out of fdisk
> > Disk /dev/sdb: 80.0 GB, 80026361856 bytes
> > 255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
> > Units = sectors of 1 * 512 = 512 bytes
> > Sector size (logical/physical): 512 bytes / 512 bytes
> > I/O size (minimum/optimal): 512 bytes / 512 bytes
> > Disk identifier: 0x37cd3650
> >
> >Device Boot  Start End  Blocks   Id  System
> > /dev/sdb1204812584959 6291456   82  Linux swap /
> > Solaris /dev/sdb2   *1258496014682111 1048576   83  Linux
> > /dev/sdb314682112   156301487708096885  Extended
> > /dev/sdb51468416018878463 2097152   83  Linux
> > /dev/sdb61888051223074815 2097152   83  Linux
> > /dev/sdb7230768646501990320971520   83  Linux
> > /dev/sdb865021952   15630148745639768   83  Linux
> >
> > Here is a print out of fstab
> > # /etc/fstab: static file system information.
> > #
> > # noatime turns off atimes for increased performance (atimes normally
> > aren't # needed); notail increases performance of ReiserFS (at the
expense
> > of storage
> > # efficiency).  It's safe to drop the noatime options if you want and
to
> > # switch between notail / tail freely.
> > #
> > # The root filesystem should have a pass number of either 0 or 1.
> > # All other filesystems should have a pass number of 0 or greater than
1.
> > #
> > # See the manpage fstab(5) for more information.
> > #
> >
> > # 
> > 
> >
> > # NOTE: If your BOOT partition is ReiserFS, add the notail option to
opts.
> > /dev/sdb2/ext3noatime
> >   0 1
> > /dev/sdb1noneswapsw
> > 0 0
> >
> > /dev/sdb5/varext3
defaults
> >1 2
> > /dev/sdb6/tmpext3
defaults
> >   1 2
> > /dev/sdb7/usrext3
defaults
> >   1 2
> > /dev/sdb8/homeext3
defaults
> >1 2
> >
> > /dev/cdrom/mnt/cdromauto
noauto,ro
> >   0 0
> >
> > /dev/sda2/mnt/Windowsntfs
defaults
> >   1 2
> >
> > proc /procproc
> > defaults0 0
> > shm/dev/shmtmpfs
> > nodev,nouisd,noexec0 0
> >
> > #tmpfs /var/tmp/portagetmpfs
> > size=500M,mode=07770 0
>
>
> In all likelihood you have not included in your kernel (built in, not as
> modules) the corresponding SATA controller driver.  Run a diff between
old and
> new kernel .config to find out what's missing, or cp your old .config
into your
> new kernel tree and run 'make oldconfig'.
> --
> Regards,
> Mick


It would not matter that he has his / fs drive controller as a module and
not built in with an initrd. That's the pur

Re: [gentoo-user] hard drive encryption

[Valmor de Almeida]

On 03/11/2012 02:29 PM, Florian Philipp wrote:
> Am 11.03.2012 16:38, schrieb Valmor de Almeida:
>>
>> Hello,
>>
>> I have not looked at encryption before and find myself in a situation
>> that I have to encrypt my hard drive. I keep /, /boot, and swap outside
>> LVM, everything else is under LVM. I think all I need to do is to
>> encrypt /home which is under LVM. I use reiserfs.
>>
>> I would appreciate suggestion and pointers on what it is practical and
>> simple in order to accomplish this task with a minimum of downtime.
>>
>> Thanks,
>>
>> --
>> Valmor
>>
> 
> 
> Is it acceptable for you to have a commandline prompt for the password
> when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt

I think so.

> init script. /etc/conf.d/dmcrypt should contain some examples. As you
> want to encrypt an LVM volume, the lvm init script needs to be started
> before this. As I see it, there is no strict dependency between those
> two scripts. You can add this by adding this line to /etc/rc.conf:
> rc_dmcrypt_after="lvm"
> 
> For creating a LUKS-encrypted volume, look at
> http://en.gentoo-wiki.com/wiki/DM-Crypt

Currently looking at this.

> 
> You won't need most of what is written there; just section 9,
> "Administering LUKS" and the kernel config in section 2, "Assumptions".
> 
> Concerning downtime, I'm not aware of any solution that avoids copying
> the data over to the new volume. If downtime is absolutely critical, ask
> and we can work something out that minimizes the time.
> 
> Regards,
> Florian Philipp
> 

Since I am planning to encrypt only home/ under LVM control, what kind
of overhead should I expect?

Thanks,

--
Valmor

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

Hi, Walter.

On Tue, Mar 13, 2012 at 03:33:06AM -0400, Walter Dnes wrote:
> On Mon, Mar 12, 2012 at 09:24:32AM +, Alan Mackenzie wrote

>   Once you're back to your old setup, can you do me a favour?  Please do
> the following...

> 1) Add the line...

> sys-fs/udev

> to /etc/portage/package.mask.

DONE.

> 2) Run the 2 commands
> emerge -pv system > system.txt
> emerge -pv world > world.txt

> 3) Remove the "sys-fs/udev" entry from /etc/portage/package.mask.

:-)  I would have forgotten about that.

> and gzip or zip the files system.txt and world.txt and file-attach them.
> My guess is that at the end of world.txt, there will be a complaint
> about udev being masked.  I intend to add that sanity-check to the
> instructions, so that people will know ahead of time whether or not
> they'll run into this problem.

I also did "2> {system,world}.err".  system.err was empty.  I've included
world.err in the enclosed tarball.

>   Again, sorry about putting you through this trouble.  You did what a
> beta tester is supposed to do, i.e. find problems/bugs.

Not at all!  I'd love to get this working on my machine.

> -- 
> Walter Dnes 

-- 
Alan Mackenzie (Nuremberg, Germany).



mdev.tar.gz
Description: Binary data

Re: [gentoo-user] Can't boot upgraded kerne;

[Bruce Hill, Jr.]

On March 13, 2012 at 1:36 AM ro...@cs.wisc.edu wrote:

> I recently decided to update my AMD64 box from 2.38 to the new 3.2
kernel.
> I used genkernel all to compile the upgraded kernel but when I go to boot
> I get the following error.
>
> >>Loading modules
> >>Determining root device
> !!Block device /dev/sdb2 is not a valid root device
> !!Could not find the root block device in .
> Pleas specify another value or" press enter for the same, type "shell"
for
> a shell, or "q"to skip..
> root block device()::
>
> However at this point the computer is hung and I am no longer able to
> input anything. I just switched over to gentoo from bsd a year or so ago
> and am still a newbie at some of the installation procedures but I
believe
> I have followed the manual correctly with the only change being that
/boot
> is located on the root partition and not a seperate partition. I'm still
> able to use my older kernel without a problem and the only difference
that
> I can note between the two is that older kernel seems to load in a bunch
> of modules and starts mdev, I believe, before trying to locate root. I am
> also using Lilo since my motherboard doesn't seem to like grub. Any help
I
> could get would be appreciated.
>
> roger
>
> Here is a print out of lilo.conf
> boot=/dev/sdb
> map=/boot/map
>
> prompt
> timeout=50
> default=Windows
>
> image=/boot/kernel-genkernel-x86_64-2.6.38-gentoo-r6
>   label=2.6.38
>   read-only
>   append="real_root=/dev/sdb2"
>   vga=773
>   initrd=/boot/initramfs-genkernel-x86_64-2.6.38-gentoo-r6
>
> image=/boot/kernel-genkernel-x86_64-3.2.1-gentoo-r2
>   label=3.2.1
>   read-only
>   append="real_root=/dev/sdb2"
>   initrd=/boot/initramfs-genkernel-x86_64-3.2.1-gentoo-r2
>
>
> other=/dev/sda1
>   label=Windows
>
>
> Here is a print out of fdisk
> Disk /dev/sdb: 80.0 GB, 80026361856 bytes
> 255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x37cd3650
>
>Device Boot  Start End  Blocks   Id  System
> /dev/sdb1204812584959 6291456   82  Linux swap /
Solaris
> /dev/sdb2   *1258496014682111 1048576   83  Linux
> /dev/sdb314682112   156301487708096885  Extended
> /dev/sdb51468416018878463 2097152   83  Linux
> /dev/sdb61888051223074815 2097152   83  Linux
> /dev/sdb7230768646501990320971520   83  Linux
> /dev/sdb865021952   15630148745639768   83  Linux
>
> Here is a print out of fstab
> # /etc/fstab: static file system information.
> #
> # noatime turns off atimes for increased performance (atimes normally
aren't
> # needed); notail increases performance of ReiserFS (at the expense of
> storage
> # efficiency).  It's safe to drop the noatime options if you want and to
> # switch between notail / tail freely.
> #
> # The root filesystem should have a pass number of either 0 or 1.
> # All other filesystems should have a pass number of 0 or greater than 1.
> #
> # See the manpage fstab(5) for more information.
> #
>
> # 
> 
>
> # NOTE: If your BOOT partition is ReiserFS, add the notail option to
opts.
> /dev/sdb2/ext3noatime

>   0 1
> /dev/sdb1noneswapsw

> 0 0
>
> /dev/sdb5/varext3defaults
>1 2
> /dev/sdb6/tmpext3defaults
>   1 2
> /dev/sdb7/usrext3defaults
>   1 2
> /dev/sdb8/homeext3
defaults
>1 2
>
> /dev/cdrom/mnt/cdromautonoauto,ro
>   0 0
>
> /dev/sda2/mnt/Windowsntfsdefaults
>   1 2
>
> proc /procproc
> defaults0 0
> shm/dev/shmtmpfs
> nodev,nouisd,noexec0 0
>
> #tmpfs /var/tmp/portagetmpfs
> size=500M,mode=07770 0
>
>
>
>
>

Something else ...

LiLO doesn't need/use this "real_root= " convention. It knows that
/dev/sdb2 is /dev/sdb2. So, according to your fdisk and /etc/fstab output,
I think this /etc/lilo.conf should work for you:

[code]
# Faster, but won't work on all systems:
compact
# Should work for most systems, and does not have the sector limit:
lba32
# If lba32 does not work, use linear:
#linear
vga=773
# MBR to install LILO to:
boot = /dev/sda
map = /boot/.map
default = Windows
install = /boot/boot-menu.b   # Note that for lilo-22.5.5 or later you
  # do not need boot-{text,menu,bmp}.b in
 

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Peter Humphrey]

On Tuesday 13 March 2012 11:01:29 Neil Bothwick wrote:
> On Tue, 13 Mar 2012 02:41:15 +, Peter Humphrey wrote:
> > I can't remember it at all, even though I was 23 or so. (Aside: my
> > father used to say that football is a game, and games are what
> > children play.)
> 
> Yes, but that doesn't mean no one else plays them. That's the sort of
> argument that could only be used by a parent on a child :-O

It is indeed true that, on the rare occasion I've used it myself, it 
hasn't done me any good.  :-)

-- 
Rgds
Peter

Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[Alan McKinnon]

On Mon, 12 Mar 2012 17:53:29 -0600
Canek Peláez Valdés  wrote:

> As Alan said in other thread, it can be "fixed" (if you think is not
> right) for some very specific cases. Alan mentioned servers, really
> simple desktops with simple hotplug devices, and embedded systems. For
> mdev to "fix" the situation in the general case, it would have to
> cover all the setups udev covers. That means bluetooth devices
> (including keyboards and mice), USB soundcards, touch screens and the
> like, all of them being plugged and unplugged at any time in any
> order.
> 
> Maybe someday mdev will be able to handle all the cases that udev
> does. If it does (which I honestly doubt), I'm pretty sure at that
> point it would have become as complex as udev, if not more, and it
> will probably need the same requirements that udev has. Including the
> simple one that for mounting a filesystem, the plumbing needed to
> mounting it has to be available before, and we cannot keep throwing
> everything directly on / so it can mount /usr. 

I'm slowly coming round to this point of view too.

If you want a full blown desktop machine with all the modern bells and
whistles that always JustWorks(tm), realise that you have a complex
system needing complex software. And udev is designed to deal with
that. To accomplish this task, udev needs to apply some constraints.

For almost everything else, that sophistication is not needed and
simpler (i.e. less complex) software will suffice. Currently mdev (or
something else like it) fills that needs.

So 2 different scenarios with different solutions. Horses for courses. 

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

Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[Pandu Poluan]

On Mar 13, 2012 10:39 PM, "Alan McKinnon"  wrote:
>
> On Mon, 12 Mar 2012 17:53:29 -0600
> Canek Peláez Valdés  wrote:
>
> > As Alan said in other thread, it can be "fixed" (if you think is not
> > right) for some very specific cases. Alan mentioned servers, really
> > simple desktops with simple hotplug devices, and embedded systems. For
> > mdev to "fix" the situation in the general case, it would have to
> > cover all the setups udev covers. That means bluetooth devices
> > (including keyboards and mice), USB soundcards, touch screens and the
> > like, all of them being plugged and unplugged at any time in any
> > order.
> >
> > Maybe someday mdev will be able to handle all the cases that udev
> > does. If it does (which I honestly doubt), I'm pretty sure at that
> > point it would have become as complex as udev, if not more, and it
> > will probably need the same requirements that udev has. Including the
> > simple one that for mounting a filesystem, the plumbing needed to
> > mounting it has to be available before, and we cannot keep throwing
> > everything directly on / so it can mount /usr.
>
> I'm slowly coming round to this point of view too.
>
> If you want a full blown desktop machine with all the modern bells and
> whistles that always JustWorks(tm), realise that you have a complex
> system needing complex software. And udev is designed to deal with
> that. To accomplish this task, udev needs to apply some constraints.
>
> For almost everything else, that sophistication is not needed and
> simpler (i.e. less complex) software will suffice. Currently mdev (or
> something else like it) fills that needs.
>
> So 2 different scenarios with different solutions. Horses for courses.
>

Fully agree.

However, currently the 'less complex' mdev solution is not yet a 'first
class citizen' anywhere.

Rgds,

Re: [gentoo-user] hard drive encryption

[Florian Philipp]

Am 13.03.2012 12:55, schrieb Valmor de Almeida:
> On 03/11/2012 02:29 PM, Florian Philipp wrote:
>> Am 11.03.2012 16:38, schrieb Valmor de Almeida:
>>>
>>> Hello,
>>>
>>> I have not looked at encryption before and find myself in a situation
>>> that I have to encrypt my hard drive. I keep /, /boot, and swap outside
>>> LVM, everything else is under LVM. I think all I need to do is to
>>> encrypt /home which is under LVM. I use reiserfs.
>>>
>>> I would appreciate suggestion and pointers on what it is practical and
>>> simple in order to accomplish this task with a minimum of downtime.
>>>
>>> Thanks,
>>>
>>> --
>>> Valmor
>>>
>>
>>
>> Is it acceptable for you to have a commandline prompt for the password
>> when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt
> 
> I think so.
> 
>> init script. /etc/conf.d/dmcrypt should contain some examples. As you
>> want to encrypt an LVM volume, the lvm init script needs to be started
>> before this. As I see it, there is no strict dependency between those
>> two scripts. You can add this by adding this line to /etc/rc.conf:
>> rc_dmcrypt_after="lvm"
>>
>> For creating a LUKS-encrypted volume, look at
>> http://en.gentoo-wiki.com/wiki/DM-Crypt
> 
> Currently looking at this.
> 
>>
>> You won't need most of what is written there; just section 9,
>> "Administering LUKS" and the kernel config in section 2, "Assumptions".
>>
>> Concerning downtime, I'm not aware of any solution that avoids copying
>> the data over to the new volume. If downtime is absolutely critical, ask
>> and we can work something out that minimizes the time.
>>
>> Regards,
>> Florian Philipp
>>
> 
> Since I am planning to encrypt only home/ under LVM control, what kind
> of overhead should I expect?
> 
> Thanks,
> 

What do you mean with overhead? CPU utilization? In that case the
overhead is minimal, especially when you run a 64-bit kernel with the
optimized AES kernel module.

Measured on a Core i5:
time cat Video/*.* >/dev/null

real0m42.918s
user0m0.023s
sys 0m2.027s

That was a sequential read of roughly 3.5GB with empty caches. This
corresponds to the normal disk speed.

Regards,
Florian Philipp



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] hard drive encryption

[Michael Mol]

On Tue, Mar 13, 2012 at 12:11 PM, Florian Philipp  wrote:
> Am 13.03.2012 12:55, schrieb Valmor de Almeida:
>> On 03/11/2012 02:29 PM, Florian Philipp wrote:
>>> Am 11.03.2012 16:38, schrieb Valmor de Almeida:

 Hello,

 I have not looked at encryption before and find myself in a situation
 that I have to encrypt my hard drive. I keep /, /boot, and swap outside
 LVM, everything else is under LVM. I think all I need to do is to
 encrypt /home which is under LVM. I use reiserfs.

 I would appreciate suggestion and pointers on what it is practical and
 simple in order to accomplish this task with a minimum of downtime.

 Thanks,

 --
 Valmor

>>>
>>>
>>> Is it acceptable for you to have a commandline prompt for the password
>>> when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt
>>
>> I think so.
>>
>>> init script. /etc/conf.d/dmcrypt should contain some examples. As you
>>> want to encrypt an LVM volume, the lvm init script needs to be started
>>> before this. As I see it, there is no strict dependency between those
>>> two scripts. You can add this by adding this line to /etc/rc.conf:
>>> rc_dmcrypt_after="lvm"
>>>
>>> For creating a LUKS-encrypted volume, look at
>>> http://en.gentoo-wiki.com/wiki/DM-Crypt
>>
>> Currently looking at this.
>>
>>>
>>> You won't need most of what is written there; just section 9,
>>> "Administering LUKS" and the kernel config in section 2, "Assumptions".
>>>
>>> Concerning downtime, I'm not aware of any solution that avoids copying
>>> the data over to the new volume. If downtime is absolutely critical, ask
>>> and we can work something out that minimizes the time.
>>>
>>> Regards,
>>> Florian Philipp
>>>
>>
>> Since I am planning to encrypt only home/ under LVM control, what kind
>> of overhead should I expect?
>>
>> Thanks,
>>
>
> What do you mean with overhead? CPU utilization? In that case the
> overhead is minimal, especially when you run a 64-bit kernel with the
> optimized AES kernel module.

Rough guess: Latency. With encryption, you can't DMA disk data
directly into a process's address space, because you need the decrypt
hop.

Try running bonnie++ on encrypted vs non-encrypted volumes. (Or not; I
doubt you have the time and materials to do a good, meaningful set of
time trials)

-- 
:wq

Re: [gentoo-user] hard drive encryption

[Florian Philipp]

Am 13.03.2012 17:26, schrieb Michael Mol:
> On Tue, Mar 13, 2012 at 12:11 PM, Florian Philipp  
> wrote:
>> Am 13.03.2012 12:55, schrieb Valmor de Almeida:
>>> On 03/11/2012 02:29 PM, Florian Philipp wrote:
 Am 11.03.2012 16:38, schrieb Valmor de Almeida:
>
> Hello,
>
> I have not looked at encryption before and find myself in a situation
> that I have to encrypt my hard drive. I keep /, /boot, and swap outside
> LVM, everything else is under LVM. I think all I need to do is to
> encrypt /home which is under LVM. I use reiserfs.
>
> I would appreciate suggestion and pointers on what it is practical and
> simple in order to accomplish this task with a minimum of downtime.
>
> Thanks,
>
> --
> Valmor
>


 Is it acceptable for you to have a commandline prompt for the password
 when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt
>>>
>>> I think so.
>>>
 init script. /etc/conf.d/dmcrypt should contain some examples. As you
 want to encrypt an LVM volume, the lvm init script needs to be started
 before this. As I see it, there is no strict dependency between those
 two scripts. You can add this by adding this line to /etc/rc.conf:
 rc_dmcrypt_after="lvm"

 For creating a LUKS-encrypted volume, look at
 http://en.gentoo-wiki.com/wiki/DM-Crypt
>>>
>>> Currently looking at this.
>>>

 You won't need most of what is written there; just section 9,
 "Administering LUKS" and the kernel config in section 2, "Assumptions".

 Concerning downtime, I'm not aware of any solution that avoids copying
 the data over to the new volume. If downtime is absolutely critical, ask
 and we can work something out that minimizes the time.

 Regards,
 Florian Philipp

>>>
>>> Since I am planning to encrypt only home/ under LVM control, what kind
>>> of overhead should I expect?
>>>
>>> Thanks,
>>>
>>
>> What do you mean with overhead? CPU utilization? In that case the
>> overhead is minimal, especially when you run a 64-bit kernel with the
>> optimized AES kernel module.
> 
> Rough guess: Latency. With encryption, you can't DMA disk data
> directly into a process's address space, because you need the decrypt
> hop.
> 

Good call. Wouldn't have thought of that.

> Try running bonnie++ on encrypted vs non-encrypted volumes. (Or not; I
> doubt you have the time and materials to do a good, meaningful set of
> time trials)
> 

Yeah, that sounds like something for which you need a very dull winter
day. Besides, I've already lost a poorly cooled HDD on a benchmark.

Regards,
Florian Philipp



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] hard drive encryption

[Neil Bothwick]

On Tue, 13 Mar 2012 17:49:40 +0100, Florian Philipp wrote:

> Besides, I've already lost a poorly cooled HDD on a benchmark.

Better than losing it on real data.


-- 
Neil Bothwick

Why do they call it a TV set when you only get one?


signature.asc
Description: PGP signature

Re: [gentoo-user] hard drive encryption

[Michael Mol]

On Tue, Mar 13, 2012 at 12:49 PM, Florian Philipp  wrote:
> Am 13.03.2012 17:26, schrieb Michael Mol:
>> On Tue, Mar 13, 2012 at 12:11 PM, Florian Philipp  
>> wrote:
>>> Am 13.03.2012 12:55, schrieb Valmor de Almeida:
 On 03/11/2012 02:29 PM, Florian Philipp wrote:
> Am 11.03.2012 16:38, schrieb Valmor de Almeida:
>>
>> Hello,
>>
>> I have not looked at encryption before and find myself in a situation
>> that I have to encrypt my hard drive. I keep /, /boot, and swap outside
>> LVM, everything else is under LVM. I think all I need to do is to
>> encrypt /home which is under LVM. I use reiserfs.
>>
>> I would appreciate suggestion and pointers on what it is practical and
>> simple in order to accomplish this task with a minimum of downtime.
>>
>> Thanks,
>>
>> --
>> Valmor
>>
>
>
> Is it acceptable for you to have a commandline prompt for the password
> when booting? In that case you can use LUKS with the /etc/init.d/dmcrypt

 I think so.

> init script. /etc/conf.d/dmcrypt should contain some examples. As you
> want to encrypt an LVM volume, the lvm init script needs to be started
> before this. As I see it, there is no strict dependency between those
> two scripts. You can add this by adding this line to /etc/rc.conf:
> rc_dmcrypt_after="lvm"
>
> For creating a LUKS-encrypted volume, look at
> http://en.gentoo-wiki.com/wiki/DM-Crypt

 Currently looking at this.

>
> You won't need most of what is written there; just section 9,
> "Administering LUKS" and the kernel config in section 2, "Assumptions".
>
> Concerning downtime, I'm not aware of any solution that avoids copying
> the data over to the new volume. If downtime is absolutely critical, ask
> and we can work something out that minimizes the time.
>
> Regards,
> Florian Philipp
>

 Since I am planning to encrypt only home/ under LVM control, what kind
 of overhead should I expect?

 Thanks,

>>>
>>> What do you mean with overhead? CPU utilization? In that case the
>>> overhead is minimal, especially when you run a 64-bit kernel with the
>>> optimized AES kernel module.
>>
>> Rough guess: Latency. With encryption, you can't DMA disk data
>> directly into a process's address space, because you need the decrypt
>> hop.
>>
>
> Good call. Wouldn't have thought of that.
>
>> Try running bonnie++ on encrypted vs non-encrypted volumes. (Or not; I
>> doubt you have the time and materials to do a good, meaningful set of
>> time trials)
>>
>
> Yeah, that sounds like something for which you need a very dull winter
> day. Besides, I've already lost a poorly cooled HDD on a benchmark.

Sounds like something we can do at my LUG at one of our weekly
socials. The part I don't know is how to set this kind of thing up and
how to tune it; I don't want it to be like Microsoft's comparison of
SQL Server against MySQL from a decade or so ago, where they didn't
tune MySQL for their bench workload.

-- 
:wq

[gentoo-user] Re: virtual/shadow

[»Q«]

On Tue, 13 Mar 2012 01:54:30 +0200
Nikos Chantziaras  wrote:

> On 13/03/12 00:34, »Q« wrote:
> > On Mon, 12 Mar 2012 22:29:10 +0200
> > Alan McKinnon  wrote:
> >  
> >> Anyone care to offer an opinion on what it will take to get
> >> PROVIDES support in portage?  
> >
> > IMO, it would take virtuals causing so many headachy breakages that
> > some devs started keeping up a steady drumbeat on irc and mailing
> > lists.  When the number of virtual packages gets close to a
> > thousand, I'd guess that might happen.  Then there would be years
> > of discussion and GLEP proposals, and by EAPI 207 it should be
> > done.  
> 
> The problem isn't the amount of virtuals.  This doesn't affect the
> users much. 

I expect more virtuals will mean more bugs affecting users.  I don't
know how hairy they will be, but here's one ugly example:
.  It's unresolved, but
less has been added back to @system so stage 3 tarballs aren't broken
for now.  (I guess this could have happened with provides as well.)

> It's the inability for people to offer replacement
> packages in overlays.

Yeah, I see.

Re: [gentoo-user] hard drive encryption

[Frank Steinmetzger]

On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:

> > Since I am planning to encrypt only home/ under LVM control, what kind
> > of overhead should I expect?
> 
> What do you mean with overhead? CPU utilization? In that case the
> overhead is minimal, especially when you run a 64-bit kernel with the
> optimized AES kernel module.

Speaking of that...
I always wondered what the exact difference was between AES and AES i586. I
can gather myself that it's about optimisation for a specific architecture.
But which one would be best for my i686 Core 2 Duo?
-- 
Gruß | Greetings | Qapla'
I forbid any use of my email addresses with Facebook services.

A pessimist is an optimist who's given it some thought.


pgp2QBsinY8SO.pgp
Description: PGP signature

Re: [gentoo-user] bindmount or symlink?

[Walter Dnes]

On Tue, Mar 13, 2012 at 12:04:00PM +0700, Pandu Poluan wrote
> I am seriously thinking of splitting the storage of directories under /usr,
> e.g., /usr/portage and /usr/source actually living somewhere else, on
> different partition and different filesystem. Let's say something mounted
> on /mnt/Persistent.
> 
> My question: should I use bindmount or symlinks to do that? What's the
> drawbacks/benefits for either?

  There might be some really rare occasions when you boot up in rescue
mode ("single") where a program expects a directory.

-- 
Walter Dnes 

Re: [gentoo-user] hard drive encryption

[Florian Philipp]

Am 13.03.2012 18:45, schrieb Frank Steinmetzger:
> On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:
> 
>>> Since I am planning to encrypt only home/ under LVM control, what kind
>>> of overhead should I expect?
>>
>> What do you mean with overhead? CPU utilization? In that case the
>> overhead is minimal, especially when you run a 64-bit kernel with the
>> optimized AES kernel module.
> 
> Speaking of that...
> I always wondered what the exact difference was between AES and AES i586. I
> can gather myself that it's about optimisation for a specific architecture.
> But which one would be best for my i686 Core 2 Duo?

From what I can see in the kernel sources, there is a generic AES
implementation using nothing but portable C code and then there is
"aes-i586" assembler code with "aes_glue" C code. So I assume the i586
version is better for you --- unless GCC suddenly got a lot better at
optimizing code.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] hard drive encryption

[Michael Mol]

On Tue, Mar 13, 2012 at 2:06 PM, Florian Philipp  wrote:
> Am 13.03.2012 18:45, schrieb Frank Steinmetzger:
>> On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:
>>
 Since I am planning to encrypt only home/ under LVM control, what kind
 of overhead should I expect?
>>>
>>> What do you mean with overhead? CPU utilization? In that case the
>>> overhead is minimal, especially when you run a 64-bit kernel with the
>>> optimized AES kernel module.
>>
>> Speaking of that...
>> I always wondered what the exact difference was between AES and AES i586. I
>> can gather myself that it's about optimisation for a specific architecture.
>> But which one would be best for my i686 Core 2 Duo?
>
> From what I can see in the kernel sources, there is a generic AES
> implementation using nothing but portable C code and then there is
> "aes-i586" assembler code with "aes_glue" C code.


> So I assume the i586
> version is better for you --- unless GCC suddenly got a lot better at
> optimizing code.

Since when, exactly? GCC isn't the best compiler at optimization, but
I fully expect current versions to produce better code for x86-64 than
hand-tuned i586. Wider registers, more registers, crypto acceleration
instructions and SIMD instructions are all very nice to have. I don't
know the specifics of AES, though, or what kind of crypto algorithm it
is, so it's entirely possible that one can't effectively parallelize
it except in some relatively unique circumstances.

-- 
:wq

Re: [gentoo-user] Re: LVM, /usr and really really bad thoughts.

[pk]

On 2012-03-13 08:13, Alan McKinnon wrote:

> I've also thought about this and I also want to ask why?

Hm... me too? :-)

> I stopped using a separate /usr on my workstations a long time ago when
> I realized it was pointless. The days of 5M hard disks when the entire

Ok, you realized it was pointless for *you*, right? It's not a universal
fact, as far as I can see... Recall the previous discussion about this
very same subject, where I compared unix to "lego"? Flexibility is the
keyword here, I think, that some of us do not want to forego. For
instance I can very well see myself indulging in some SSDs that I could
put in my 'puter where one is dedicated for /usr, one for /var and one
for the root file system, whereas I would keep a big normal HDD for /home...

In my opinion there's a lot of "hand waving" that basically says
something like "on a modern desktop system, complex software is needed,
therefore /usr needs to be on the root file system (or mounted via
initrd)"... and states this as a universal fact, without answering the
question "Why?". Isn't it those who wants to change that should answer
why they want to change? And I trust Poetterings/Sievers answer why it
needs to change as far as I can throw either of them (I'm quite weak)...
it's all tied in neatly into their (IMO) overly complex software.

Hm, if we want to be modern, perhaps we should abolish partitions
altogether and put everything in the cloud? That would be "modern",
right? ;-)

I'm running a decent desktop system (Xfce4) and I have /usr on a
separate partition without any initrd... Why would I need to change this
(except from being forced if I continue to use udev)? So far the only
technical reason I've heard that somehow requires udev to have access to
files in /usr is a bluetooth keyboard. Anything else that *needs* to be
working during boot (before a separate /usr can be mounted)? And in my
opinion, if a keyboard needs complex software to work then it's broken
by design.

But I digress, I really should start coding my own solutions, as Canek
says...

Best regards

Peter K

[gentoo-user] emerge Break

[siefke_lis...@web.de]

Hello,

i try to install avidemux and so i give emerge avidemux. But at 
media-libs/aften-0.0.8 break emerge with the message:


cmake: error while loading shared libraries: libnettle.so.3: 
cannot open shared object file: No such file or directory


But the libnettle.so.3 is present on my system:
siefke@gentoo-desk ~ $ locate libnettle.so.3
/usr/lib/libnettle.so.3
/usr/lib/libnettle.so.3.0

I try with env-update but nothing change. Has someone a idea?

Regards
Silvio

Re: [gentoo-user] hard drive encryption

[Florian Philipp]

Am 13.03.2012 19:18, schrieb Michael Mol:
> On Tue, Mar 13, 2012 at 2:06 PM, Florian Philipp  
> wrote:
>> Am 13.03.2012 18:45, schrieb Frank Steinmetzger:
>>> On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:
>>>
> Since I am planning to encrypt only home/ under LVM control, what kind
> of overhead should I expect?

 What do you mean with overhead? CPU utilization? In that case the
 overhead is minimal, especially when you run a 64-bit kernel with the
 optimized AES kernel module.
>>>
>>> Speaking of that...
>>> I always wondered what the exact difference was between AES and AES i586. I
>>> can gather myself that it's about optimisation for a specific architecture.
>>> But which one would be best for my i686 Core 2 Duo?
>>
>> From what I can see in the kernel sources, there is a generic AES
>> implementation using nothing but portable C code and then there is
>> "aes-i586" assembler code with "aes_glue" C code.
> 
> 
>> So I assume the i586
>> version is better for you --- unless GCC suddenly got a lot better at
>> optimizing code.
> 
> Since when, exactly? GCC isn't the best compiler at optimization, but
> I fully expect current versions to produce better code for x86-64 than
> hand-tuned i586. Wider registers, more registers, crypto acceleration
> instructions and SIMD instructions are all very nice to have. I don't
> know the specifics of AES, though, or what kind of crypto algorithm it
> is, so it's entirely possible that one can't effectively parallelize
> it except in some relatively unique circumstances.
> 

One sec. We are talking about an Core2 Duo running in 32bit mode, right?
That's what the i686 reference in the question meant --- or at least,
that's what I assumed.

If we talk about 32bit mode, none of what you describe is available.
Those additional registers and instructions are not accessible with i686
instructions. A Core 2 also has no AES instructions.

Of course, GCC could make use of what it knows about the CPU, like
number of parallel pipelines, pipeline depth, cache size, instructions
added in i686 and so on. But even then I doubt it can outperform
hand-tuned assembler, even if it is for a slightly older instruction set.

If instead we are talking about an Core 2 Duo running in x86_64 mode, we
should be talking about the aes-x86_64 module instead of the aes-i586
module and that makes use of the complete instruction set of the Core 2,
including SSE2.

Regards,
Florian Philipp



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] emerge Break

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 12:57 PM, siefke_lis...@web.de
 wrote:
> Hello,
>
> i try to install avidemux and so i give emerge avidemux. But at
> media-libs/aften-0.0.8 break emerge with the message:
>
> 
> cmake: error while loading shared libraries: libnettle.so.3:
> cannot open shared object file: No such file or directory
> 
>
> But the libnettle.so.3 is present on my system:
> siefke@gentoo-desk ~ $ locate libnettle.so.3
> /usr/lib/libnettle.so.3
> /usr/lib/libnettle.so.3.0

The locate library may be out of sync. What does it actually say "ls
-l /usr/lib/libnettle*"?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Walter Dnes]

On Tue, Mar 13, 2012 at 01:05:34PM +, Alan Mackenzie wrote

> I also did "2> {system,world}.err".  system.err was empty.  I've included
> world.err in the enclosed tarball.

  From your error listing, it looks like lvm2, kde, and gnome (including
the XFCE subset) require udev.  Ouch.

-- 
Walter Dnes 

Re: [gentoo-user] emerge Break

[Mark Knecht]

On Tue, Mar 13, 2012 at 11:57 AM, siefke_lis...@web.de
 wrote:
> Hello,
>
> i try to install avidemux and so i give emerge avidemux. But at
> media-libs/aften-0.0.8 break emerge with the message:
>
> 
> cmake: error while loading shared libraries: libnettle.so.3:
> cannot open shared object file: No such file or directory
> 
>
> But the libnettle.so.3 is present on my system:
> siefke@gentoo-desk ~ $ locate libnettle.so.3
> /usr/lib/libnettle.so.3
> /usr/lib/libnettle.so.3.0
>
> I try with env-update but nothing change. Has someone a idea?
>
> Regards
> Silvio
>

First, was the system up-to-date prior to trying to install your new program?

emerge -pvDuN @world

If not get it up-to-date first.

Once up-to-date, and still before the new program install, do

revdep-rebuild -ip

and see if your dependencies are clean.

At this point we don't know if the new program failure is due to the
new program, it's ebuild, or its dependencies, or whether it's due to
some problems with your system that need to be addressed first.

Good luck,
Mark

Re: [gentoo-user] emerge Break

[Michael Mol]

On Tue, Mar 13, 2012 at 2:57 PM, siefke_lis...@web.de
 wrote:
> Hello,
>
> i try to install avidemux and so i give emerge avidemux. But at
> media-libs/aften-0.0.8 break emerge with the message:
>
> 
> cmake: error while loading shared libraries: libnettle.so.3:
> cannot open shared object file: No such file or directory
> 
>
> But the libnettle.so.3 is present on my system:
> siefke@gentoo-desk ~ $ locate libnettle.so.3
> /usr/lib/libnettle.so.3
> /usr/lib/libnettle.so.3.0
>
> I try with env-update but nothing change. Has someone a idea?

I don't know a whole lot about multilib, but I believe /usr/lib is a
32-bit library folder. Perhaps avidemux is looking for a 64-bit
version?

Just started emerging avidemux on one of my boxes, but libnettle
doesn't appear to get pulled in. Finally, My emerge result line reads:

[ebuild  N ] media-video/avidemux-2.5.4-r2  USE="aac aften alsa
dts jack libsamplerate mp3 nls qt4 sdl truetype vorbis x264 xv xvid
-amr (-esd) -gtk -oss -pulseaudio" LINGUAS="-bg -ca -cs -de -el -es
-fr -it -ja -pt_BR -ru -sr -sr@latin -tr -zh_TW" 17,730 kB

-- 
:wq

Re: [gentoo-user] hard drive encryption

[Stroller]

On 13 March 2012, at 18:18, Michael Mol wrote:
> ...
>> So I assume the i586
>> version is better for you --- unless GCC suddenly got a lot better at
>> optimizing code.
> 
> Since when, exactly? GCC isn't the best compiler at optimization, but
> I fully expect current versions to produce better code for x86-64 than
> hand-tuned i586. Wider registers, more registers, crypto acceleration
> instructions and SIMD instructions are all very nice to have. I don't
> know the specifics of AES, though, or what kind of crypto algorithm it
> is, so it's entirely possible that one can't effectively parallelize
> it except in some relatively unique circumstances.

Do you have much experience of writing assembler?

I don't, and I'm not an expert on this, but I've read the odd blog article on 
this subject over the years.

What I've read often has the programmer looking at the compiled gcc bytecode 
and examining what it does. The compiler might not care how many registers it 
uses, and thus a variable might find itself frequently swapped back into RAM; 
the programmer does not have any control over the compiler, and IIRC some flags 
reserve a register for degugging (IIRC -fomit-frame-pointer disables this). I 
think it's possible to use registers more efficiently by swapping them (??) or 
by using bitwise comparisons and other tricks. 

Assembler optimisation is only used on sections of code that are at the core of 
a loop - that are called hundreds or thousands (even millions?) of times during 
the program's execution. It's not for code, such as reading the .config file or 
initialisation, which is only called once. Because the code in the core of the 
loop is called so often, you don't have to achieve much of an optimisation for 
the aggregate to be much more considerable.

The operations in question may only be constitute a few lines of C, or a 
handful of machine operations, so it boils down to an algorithm that a human 
programmer is capable of getting a grip on and comprehending. Whilst compilers 
are clearly more efficient for large programs, on this micro scale, humans are 
more clever and creative than machines. 

Encryption / decryption is an example of code that lends itself to this kind of 
optimisation. In particular AES was designed, I believe, to be amenable to 
implementation in this way. The reason for that was that it was desirable to 
have it run on embedded devices and on dedicated chips. So it boils down to a 
simple bitswap operation (??) - the plaintext is modified by the encryption 
key, input and output as a fast stream. Each byte goes in, each byte goes out, 
the same function performed on each one.

Another operation that lends itself to assembler optimisation is video decoding 
- the video is encoded only once, and then may be played back hundreds or 
millions of times by different people. The same operations must be repeated a 
number of times on each frame, then c 25 - 60 frames are decoded per second, so 
at least 90,000 frames per hour. Again, the smallest optimisation is worthwhile.

Stroller.

Re: [gentoo-user] hard drive encryption

[Michael Mol]

On Tue, Mar 13, 2012 at 2:58 PM, Florian Philipp  wrote:
> Am 13.03.2012 19:18, schrieb Michael Mol:
>> On Tue, Mar 13, 2012 at 2:06 PM, Florian Philipp  
>> wrote:
>>> Am 13.03.2012 18:45, schrieb Frank Steinmetzger:
 On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:

>> Since I am planning to encrypt only home/ under LVM control, what kind
>> of overhead should I expect?
>
> What do you mean with overhead? CPU utilization? In that case the
> overhead is minimal, especially when you run a 64-bit kernel with the
> optimized AES kernel module.

 Speaking of that...
 I always wondered what the exact difference was between AES and AES i586. I
 can gather myself that it's about optimisation for a specific architecture.
 But which one would be best for my i686 Core 2 Duo?
>>>
>>> From what I can see in the kernel sources, there is a generic AES
>>> implementation using nothing but portable C code and then there is
>>> "aes-i586" assembler code with "aes_glue" C code.
>>
>>
>>> So I assume the i586
>>> version is better for you --- unless GCC suddenly got a lot better at
>>> optimizing code.
>>
>> Since when, exactly? GCC isn't the best compiler at optimization, but
>> I fully expect current versions to produce better code for x86-64 than
>> hand-tuned i586. Wider registers, more registers, crypto acceleration
>> instructions and SIMD instructions are all very nice to have. I don't
>> know the specifics of AES, though, or what kind of crypto algorithm it
>> is, so it's entirely possible that one can't effectively parallelize
>> it except in some relatively unique circumstances.
>>
>
> One sec. We are talking about an Core2 Duo running in 32bit mode, right?
> That's what the i686 reference in the question meant --- or at least,
> that's what I assumed.

I think you're right; I missed that part.

>
> If we talk about 32bit mode, none of what you describe is available.
> Those additional registers and instructions are not accessible with i686
> instructions. A Core 2 also has no AES instructions.
>
> Of course, GCC could make use of what it knows about the CPU, like
> number of parallel pipelines, pipeline depth, cache size, instructions
> added in i686 and so on. But even then I doubt it can outperform
> hand-tuned assembler, even if it is for a slightly older instruction set.

I'm still not sure why. I'll posit that some badly-written C could
place constraints on the compiler's optimizer, but GCC should have
little problem handling well-written C, separating semantics from
syntax and finding good transforms of the original code to get
proofably-same results. Unless I'm grossly overestimating the
capabilities of its AST processing and optimization engine.

>
> If instead we are talking about an Core 2 Duo running in x86_64 mode, we
> should be talking about the aes-x86_64 module instead of the aes-i586
> module and that makes use of the complete instruction set of the Core 2,
> including SSE2.

FWIW, SSE2 is available on 32-bit processors; I have code in the field
using SSE2 on Pentium 4s.

-- 
:wq

Re: [gentoo-user] hard drive encryption

[Florian Philipp]

Am 13.03.2012 19:58, schrieb Florian Philipp:
> Am 13.03.2012 19:18, schrieb Michael Mol:
>> On Tue, Mar 13, 2012 at 2:06 PM, Florian Philipp  
>> wrote:
>>> Am 13.03.2012 18:45, schrieb Frank Steinmetzger:
 On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:

>> Since I am planning to encrypt only home/ under LVM control, what kind
>> of overhead should I expect?
>
> What do you mean with overhead? CPU utilization? In that case the
> overhead is minimal, especially when you run a 64-bit kernel with the
> optimized AES kernel module.

 Speaking of that...
 I always wondered what the exact difference was between AES and AES i586. I
 can gather myself that it's about optimisation for a specific architecture.
 But which one would be best for my i686 Core 2 Duo?
>>>
>>> From what I can see in the kernel sources, there is a generic AES
>>> implementation using nothing but portable C code and then there is
>>> "aes-i586" assembler code with "aes_glue" C code.
>>
>>
>>> So I assume the i586
>>> version is better for you --- unless GCC suddenly got a lot better at
>>> optimizing code.
>>
>> Since when, exactly? GCC isn't the best compiler at optimization, but
>> I fully expect current versions to produce better code for x86-64 than
>> hand-tuned i586. Wider registers, more registers, crypto acceleration
>> instructions and SIMD instructions are all very nice to have. I don't
>> know the specifics of AES, though, or what kind of crypto algorithm it
>> is, so it's entirely possible that one can't effectively parallelize
>> it except in some relatively unique circumstances.
>>
> 
> One sec. We are talking about an Core2 Duo running in 32bit mode, right?
> That's what the i686 reference in the question meant --- or at least,
> that's what I assumed.
> 
> If we talk about 32bit mode, none of what you describe is available.
> Those additional registers and instructions are not accessible with i686
> instructions. A Core 2 also has no AES instructions.
> 
> Of course, GCC could make use of what it knows about the CPU, like
> number of parallel pipelines, pipeline depth, cache size, instructions
> added in i686 and so on. But even then I doubt it can outperform
> hand-tuned assembler, even if it is for a slightly older instruction set.
> 

P.S: I just looked up the differences in the instruction sets of i586
and i686. The only significant instruction added in i686 was a
conditional move (CMOV). This helps to avoid condition jumps. However,
in the aes-i586 code there are only two conditional jumps and they both
just end the loop of encryption/decryption rounds for AES-128 and
AES256, respectively. My assembler isn't perfect but I doubt you can
optimize that away with a CMOV.

> If instead we are talking about an Core 2 Duo running in x86_64 mode, we
> should be talking about the aes-x86_64 module instead of the aes-i586
> module and that makes use of the complete instruction set of the Core 2,
> including SSE2.
> 
> Regards,
> Florian Philipp




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] emerge Break

[Mark Knecht]

On Tue, Mar 13, 2012 at 12:07 PM, Michael Mol  wrote:

>
> I don't know a whole lot about multilib, but I believe /usr/lib is a
> 32-bit library folder. Perhaps avidemux is looking for a 64-bit
> version?
>

It's a sim link here:

c2stable ~ # ls -l /usr/lib
lrwxrwxrwx 1 root root 5 Apr 13  2010 /usr/lib -> lib64
c2stable ~ #


> Just started emerging avidemux on one of my boxes, but libnettle
> doesn't appear to get pulled in. Finally, My emerge result line reads:
>
> [ebuild  N     ] media-video/avidemux-2.5.4-r2  USE="aac aften alsa
> dts jack libsamplerate mp3 nls qt4 sdl truetype vorbis x264 xv xvid
> -amr (-esd) -gtk -oss -pulseaudio" LINGUAS="-bg -ca -cs -de -el -es
> -fr -it -ja -pt_BR -ru -sr -sr@latin -tr -zh_TW" 17,730 kB
>
> --
> :wq
>

Same here. nettle isn't pulled in.

I don't see any obvious flags that would do it but I'm not going to
slog through the ebuild... :-)

- Mark

c2stable ~ # eix -I nettle
No matches found.
c2stable ~ # eix -c nettle
[N] dev-libs/nettle (2.4): Low-level cryptographic library
c2stable ~ # emerge -pvDuN avidemux

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N ] media-libs/aften-0.0.8  USE="cxx" 79 kB
[ebuild  N ] media-video/avidemux-2.5.4-r2  USE="aac aften alsa
dts gtk mp3 nls qt4 sdl truetype vorbis x264 xv xvid -amr (-esd) -jack
-libsamplerate -oss -pulseaudio" LINGUAS="-bg -ca -cs -de -el -es -fr
-it -ja -pt_BR -ru -sr -sr@latin -tr -zh_TW" 17,730 kB

Total: 2 packages (2 new), Size of downloads: 17,809 kB
c2stable ~ #

Re: [gentoo-user] hard drive encryption

[Florian Philipp]

Am 13.03.2012 20:13, schrieb Michael Mol:
> On Tue, Mar 13, 2012 at 2:58 PM, Florian Philipp  
> wrote:
>> Am 13.03.2012 19:18, schrieb Michael Mol:
>>> On Tue, Mar 13, 2012 at 2:06 PM, Florian Philipp  
>>> wrote:
 Am 13.03.2012 18:45, schrieb Frank Steinmetzger:
> On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:
>
>>> Since I am planning to encrypt only home/ under LVM control, what kind
>>> of overhead should I expect?
>>
>> What do you mean with overhead? CPU utilization? In that case the
>> overhead is minimal, especially when you run a 64-bit kernel with the
>> optimized AES kernel module.
>
> Speaking of that...
> I always wondered what the exact difference was between AES and AES i586. 
> I
> can gather myself that it's about optimisation for a specific 
> architecture.
> But which one would be best for my i686 Core 2 Duo?

 From what I can see in the kernel sources, there is a generic AES
 implementation using nothing but portable C code and then there is
 "aes-i586" assembler code with "aes_glue" C code.
>>>
>>>
 So I assume the i586
 version is better for you --- unless GCC suddenly got a lot better at
 optimizing code.
>>>
>>> Since when, exactly? GCC isn't the best compiler at optimization, but
>>> I fully expect current versions to produce better code for x86-64 than
>>> hand-tuned i586. Wider registers, more registers, crypto acceleration
>>> instructions and SIMD instructions are all very nice to have. I don't
>>> know the specifics of AES, though, or what kind of crypto algorithm it
>>> is, so it's entirely possible that one can't effectively parallelize
>>> it except in some relatively unique circumstances.
>>>
>>
>> One sec. We are talking about an Core2 Duo running in 32bit mode, right?
>> That's what the i686 reference in the question meant --- or at least,
>> that's what I assumed.
> 
> I think you're right; I missed that part.
> 
>>
>> If we talk about 32bit mode, none of what you describe is available.
>> Those additional registers and instructions are not accessible with i686
>> instructions. A Core 2 also has no AES instructions.
>>
>> Of course, GCC could make use of what it knows about the CPU, like
>> number of parallel pipelines, pipeline depth, cache size, instructions
>> added in i686 and so on. But even then I doubt it can outperform
>> hand-tuned assembler, even if it is for a slightly older instruction set.
> 
> I'm still not sure why. I'll posit that some badly-written C could
> place constraints on the compiler's optimizer, but GCC should have
> little problem handling well-written C, separating semantics from
> syntax and finding good transforms of the original code to get
> proofably-same results. Unless I'm grossly overestimating the
> capabilities of its AST processing and optimization engine.
> 

Well, it's not /that/ good. Otherwise the Firefox ebuild wouldn't need a
profiling run to allow the compiler to predict loop and jump certainties
and so on.

But, by all means, let's test it! It's not like we cannot.
Unfortunately, I don't have a 32bit Gentoo machine at hand where I could
test it right now.

>>
>> If instead we are talking about an Core 2 Duo running in x86_64 mode, we
>> should be talking about the aes-x86_64 module instead of the aes-i586
>> module and that makes use of the complete instruction set of the Core 2,
>> including SSE2.
> 
> FWIW, SSE2 is available on 32-bit processors; I have code in the field
> using SSE2 on Pentium 4s.
> 

Um, yeah. I should have clarified that. I meant that for x86_64
machines, the compiler as well as the assembler programmer can safely
assume that SSE2 is available. For generic i686 assembler code, you cannot.

Regards,
Florian Philipp



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Update of cryptsetup 1.4.1 fails

[Sebastian Pipping]

On 03/13/2012 10:00 AM, Uwe Scholz wrote:
> Hi,
> 
> I have an annoying problem with the current version update of
> cryptsetup-1.4.1. Already in the configure step emerge stops with the
> error message:
> 
> ...
> checking for gcry_check_version in -lgcrypt... no
> configure: error: Cannot find static gcrypt library
> ...
> 
> Actually, libgcrypt-1.4.6 is installed with the static-libs flag. Also
> after reemerging libgcrypt the update to cryptsetup-1.4.1 fails.
> 
> I'm working on a amd64 machine, cryptsetup useflags are "static"
> (compulsory) and "nls". Can anyone confirm this problem and has a
> solution for it?
> 
> Thanks in advance,
> Uwe

Please report this as a bug on https://bugs.gentoo.org/ .

You could give libgcrypt 1.5.0-r2 a try.  Please add to the bug report,
if the problem persists with libgcrypt 1.5.0-r2 or not.

Thanks!



Sebastian

Re: [gentoo-user] hard drive encryption

[Michael Mol]

On Tue, Mar 13, 2012 at 3:07 PM, Stroller
 wrote:
>
> On 13 March 2012, at 18:18, Michael Mol wrote:
>> ...
>>> So I assume the i586
>>> version is better for you --- unless GCC suddenly got a lot better at
>>> optimizing code.
>>
>> Since when, exactly? GCC isn't the best compiler at optimization, but
>> I fully expect current versions to produce better code for x86-64 than
>> hand-tuned i586. Wider registers, more registers, crypto acceleration
>> instructions and SIMD instructions are all very nice to have. I don't
>> know the specifics of AES, though, or what kind of crypto algorithm it
>> is, so it's entirely possible that one can't effectively parallelize
>> it except in some relatively unique circumstances.
>
> Do you have much experience of writing assembler?
>
> I don't, and I'm not an expert on this, but I've read the odd blog article on 
> this subject over the years.

Similar level of experience here. I can read it, even debug it from
time to time. A few regular bloggers on the subject are like candy.
And I used to have pagetable.org, Ars's Technopaedia and specsheets
for early x86 and motorola processors memorized. For the past couple
years, I've been focusing on reading blogs of language and compiler
authors, academics involved in proofing, testing and improving them,
etc.

>
> What I've read often has the programmer looking at the compiled gcc bytecode 
> and examining what it does. The compiler might not care how many registers it 
> uses, and thus a variable might find itself frequently swapped back into RAM; 
> the programmer does not have any control over the compiler, and IIRC some 
> flags reserve a register for degugging (IIRC -fomit-frame-pointer disables 
> this). I think it's possible to use registers more efficiently by swapping 
> them (??) or by using bitwise comparisons and other tricks.

Sure; it's cheaper to null out a register by XORing it with itself
than setting it to 0.

>
> Assembler optimisation is only used on sections of code that are at the core 
> of a loop - that are called hundreds or thousands (even millions?) of times 
> during the program's execution. It's not for code, such as reading the 
> .config file or initialisation, which is only called once. Because the code 
> in the core of the loop is called so often, you don't have to achieve much of 
> an optimisation for the aggregate to be much more considerable.

Sure; optimize the hell out of the code where you spend most of your
time. I wasn't aware that gcc passed up on safe optimization
opportunities, though.

>
> The operations in question may only be constitute a few lines of C, or a 
> handful of machine operations, so it boils down to an algorithm that a human 
> programmer is capable of getting a grip on and comprehending. Whilst 
> compilers are clearly more efficient for large programs, on this micro scale, 
> humans are more clever and creative than machines.

I disagree. With defined semantics for the source and target, a
computer's cleverness is limited only by the computational and memory
expense of its search algorithms. Humans get through this by making
habit various optimizations, but those habits become less useful as
additional paths and instructions are added. As system complexity
increases, humans operate on personally cached techniques derived from
simpler systems. I would expect very, very few people to be intimately
familiar with the the majority of optimization possibilities present
on an amdfam10 processor or a core2. Compiler's aren't necessarily
familiar with them, either; they're just quicker at discovering them,
given knowledge of the individual instructions and the rules of
language semantics.

>
> Encryption / decryption is an example of code that lends itself to this kind 
> of optimisation. In particular AES was designed, I believe, to be amenable to 
> implementation in this way. The reason for that was that it was desirable to 
> have it run on embedded devices and on dedicated chips. So it boils down to a 
> simple bitswap operation (??) - the plaintext is modified by the encryption 
> key, input and output as a fast stream. Each byte goes in, each byte goes 
> out, the same function performed on each one.

I'd be willing to posit that you're right here, though if there isn't
a per-byte feedback mechanism, SIMD instructions would come into
serious play. But I expect there's a per-byte feedback mechanism, so
parallelization would likely come in the form of processing
simultaneous streams.

>
> Another operation that lends itself to assembler optimisation is video 
> decoding - the video is encoded only once, and then may be played back 
> hundreds or millions of times by different people. The same operations must 
> be repeated a number of times on each frame, then c 25 - 60 frames are 
> decoded per second, so at least 90,000 frames per hour. Again, the smallest 
> optimisation is worthwhile.

Absolutely. My position, though, is that compilers are quicker and
more capable o

Re: [gentoo-user] emerge Break

[siefke_lis...@web.de]

On Tue, 13 Mar 2012 12:05:22 -0700 Mark Knecht wrote:
> First, was the system up-to-date prior to trying to install your new
> program?

I has yesterday make emerge world. 
 
> emerge -pvDuN @world
> 
> If not get it up-to-date first.

Okay this i use in future. 

> Once up-to-date, and still before the new program install, do
> 
> revdep-rebuild -ip
> and see if your dependencies are clean.
> 
> At this point we don't know if the new program failure is due to the
> new program, it's ebuild, or its dependencies, or whether it's due to
> some problems with your system that need to be addressed first.

I has work with symlink, because the libnettle was with libnettle.so.4 on 
System not the libnettle.so.3. Now has compiled, but i try the steps, because
with gnupg has the same problem. 


Thanks. Regards
Silvio 

Re: [gentoo-user] hard drive encryption

[Michael Mol]

On Tue, Mar 13, 2012 at 3:30 PM, Florian Philipp  wrote:
> Am 13.03.2012 20:13, schrieb Michael Mol:
>> On Tue, Mar 13, 2012 at 2:58 PM, Florian Philipp  
>> wrote:
>>> Am 13.03.2012 19:18, schrieb Michael Mol:
 On Tue, Mar 13, 2012 at 2:06 PM, Florian Philipp  
 wrote:
> Am 13.03.2012 18:45, schrieb Frank Steinmetzger:
>> On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:
>>
 Since I am planning to encrypt only home/ under LVM control, what kind
 of overhead should I expect?
>>>
>>> What do you mean with overhead? CPU utilization? In that case the
>>> overhead is minimal, especially when you run a 64-bit kernel with the
>>> optimized AES kernel module.
>>
>> Speaking of that...
>> I always wondered what the exact difference was between AES and AES 
>> i586. I
>> can gather myself that it's about optimisation for a specific 
>> architecture.
>> But which one would be best for my i686 Core 2 Duo?
>
> From what I can see in the kernel sources, there is a generic AES
> implementation using nothing but portable C code and then there is
> "aes-i586" assembler code with "aes_glue" C code.


> So I assume the i586
> version is better for you --- unless GCC suddenly got a lot better at
> optimizing code.

 Since when, exactly? GCC isn't the best compiler at optimization, but
 I fully expect current versions to produce better code for x86-64 than
 hand-tuned i586. Wider registers, more registers, crypto acceleration
 instructions and SIMD instructions are all very nice to have. I don't
 know the specifics of AES, though, or what kind of crypto algorithm it
 is, so it's entirely possible that one can't effectively parallelize
 it except in some relatively unique circumstances.

>>>
>>> One sec. We are talking about an Core2 Duo running in 32bit mode, right?
>>> That's what the i686 reference in the question meant --- or at least,
>>> that's what I assumed.
>>
>> I think you're right; I missed that part.
>>
>>>
>>> If we talk about 32bit mode, none of what you describe is available.
>>> Those additional registers and instructions are not accessible with i686
>>> instructions. A Core 2 also has no AES instructions.
>>>
>>> Of course, GCC could make use of what it knows about the CPU, like
>>> number of parallel pipelines, pipeline depth, cache size, instructions
>>> added in i686 and so on. But even then I doubt it can outperform
>>> hand-tuned assembler, even if it is for a slightly older instruction set.
>>
>> I'm still not sure why. I'll posit that some badly-written C could
>> place constraints on the compiler's optimizer, but GCC should have
>> little problem handling well-written C, separating semantics from
>> syntax and finding good transforms of the original code to get
>> proofably-same results. Unless I'm grossly overestimating the
>> capabilities of its AST processing and optimization engine.
>>
>
> Well, it's not /that/ good. Otherwise the Firefox ebuild wouldn't need a
> profiling run to allow the compiler to predict loop and jump certainties
> and so on.

I was thinking more in the context of simple functions and
mathematical operations. Loop probabilities? Yeah, that's a tough one.
Nobody wants to stall a huge CPU pipeline. I remember when the
NetBurst architecture came out. Intel cranked up the amount of die
space dedicated to branch prediction...

>
> But, by all means, let's test it! It's not like we cannot.
> Unfortunately, I don't have a 32bit Gentoo machine at hand where I could
> test it right now.

Now we're talking. :)

Unfortunately, I don't have a 32-bit Gentoo environment available,
either. Actually, I've never run Gentoo in a 32-bit envrionment. >.>

-- 
:wq

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

Hello, Walter,

On Tue, Mar 13, 2012 at 03:00:52PM -0400, Walter Dnes wrote:
> On Tue, Mar 13, 2012 at 01:05:34PM +, Alan Mackenzie wrote

> > I also did "2> {system,world}.err".  system.err was empty.  I've included
> > world.err in the enclosed tarball.

>   From your error listing, it looks like lvm2, kde, and gnome (including
> the XFCE subset) require udev.  Ouch.

:-)  This cannot be the case.  Otherwise somebody would have said.  Hmm.
What we could do with is a "requires xdev", for x in (m u).  I've
forgotten what that's called in portage.

There are surely lots of packages marked "need udev" which don't really
need it at all.  I mean, are there any programs which need precisely
udev to work, as opposed to a populated /dev?

I mean, what does udev give me that mdev won't?  That's not really a
rhetorical question.  What potential benefits am I throwing away by
converting to mdev?

> -- 
> Walter Dnes 

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] hard drive encryption

[Florian Philipp]

Am 13.03.2012 20:07, schrieb Stroller:
> 
> On 13 March 2012, at 18:18, Michael Mol wrote:
>> ...
>>> So I assume the i586 version is better for you --- unless GCC
>>> suddenly got a lot better at optimizing code.
>> 
>> Since when, exactly? GCC isn't the best compiler at optimization,
>> but I fully expect current versions to produce better code for
>> x86-64 than hand-tuned i586. Wider registers, more registers,
>> crypto acceleration instructions and SIMD instructions are all very
>> nice to have. I don't know the specifics of AES, though, or what
>> kind of crypto algorithm it is, so it's entirely possible that one
>> can't effectively parallelize it except in some relatively unique
>> circumstances.
> 
> Do you have much experience of writing assembler?
> 
> I don't, and I'm not an expert on this, but I've read the odd blog
> article on this subject over the years.
> 
> What I've read often has the programmer looking at the compiled gcc
> bytecode and examining what it does. The compiler might not care how
> many registers it uses, and thus a variable might find itself
> frequently swapped back into RAM; the programmer does not have any
> control over the compiler, and IIRC some flags reserve a register for
> degugging (IIRC -fomit-frame-pointer disables this). I think it's
> possible to use registers more efficiently by swapping them (??) or
> by using bitwise comparisons and other tricks.
> 

You recall correctly about the frame pointer.

Concerning the register usage: I'm no expert in this field, either, but
I think the main issue is not simply register allocation but branch and
exception prediction and so on. The compiler can either optimize for a
seamless continuation if the jump happens or if it doesn't. A human or a
just-in-time compiler can better handle these cases by predicting the
outcome of -- in the case of a JIT -- analyze the outcome of the first
few iterations.

OT: IIRC, register reuse is also the main performance problem of
state-of-the-art javascript engines, at the moment. Concerning the code
they compile at runtime, they are nearly as good as `gcc -O0` but they
have the same problem concerning registers (GCC with -O0 produces code
that works exactly as you describe above: Storing the result after every
computation and loading it again).

> Assembler optimisation is only used on sections of code that are at
> the core of a loop - that are called hundreds or thousands (even
> millions?) of times during the program's execution. It's not for
> code, such as reading the .config file or initialisation, which is
> only called once. Because the code in the core of the loop is called
> so often, you don't have to achieve much of an optimisation for the
> aggregate to be much more considerable.
> 
> The operations in question may only be constitute a few lines of C,
> or a handful of machine operations, so it boils down to an algorithm
> that a human programmer is capable of getting a grip on and
> comprehending. Whilst compilers are clearly more efficient for large
> programs, on this micro scale, humans are more clever and creative
> than machines.
> 
> Encryption / decryption is an example of code that lends itself to
> this kind of optimisation. In particular AES was designed, I believe,
> to be amenable to implementation in this way. The reason for that was
> that it was desirable to have it run on embedded devices and on
> dedicated chips. So it boils down to a simple bitswap operation (??)
> - the plaintext is modified by the encryption key, input and output
> as a fast stream. Each byte goes in, each byte goes out, the same
> function performed on each one.
> 

Well, sort of. First of, you are right, AES was designed with hardware
implementations in mind.

The algorithm boils down to a number of substitution and permutation
networks and XOR operations (I assume that's what you meant with byte
swap). If you look at the portable C code
(/usr/src/linux/crypto/aes_generic.c), you can see that it mostly
consists of lookup tables and XORs.

The thing about "each byte goes in, each byte goes out", however, is a
bit wrong. What you think of is a stream cipher like RC4. AES is a block
cipher. These use an (in this case 128 bit long) input string and XOR it
with the encryption (sub-)key and shuffle it around according to the
exact algorithm.

> Another operation that lends itself to assembler optimisation is
> video decoding - the video is encoded only once, and then may be
> played back hundreds or millions of times by different people. The
> same operations must be repeated a number of times on each frame,
> then c 25 - 60 frames are decoded per second, so at least 90,000
> frames per hour. Again, the smallest optimisation is worthwhile.
> 
> Stroller.
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] hard drive encryption

[Florian Philipp]

Am 13.03.2012 20:38, schrieb Michael Mol:
> On Tue, Mar 13, 2012 at 3:07 PM, Stroller 
>  wrote:
>> 
>> On 13 March 2012, at 18:18, Michael Mol wrote:
>>> ...
 So I assume the i586 version is better for you --- unless GCC
 suddenly got a lot better at optimizing code.
>>> 
>>> Since when, exactly? GCC isn't the best compiler at optimization,
>>> but I fully expect current versions to produce better code for
>>> x86-64 than hand-tuned i586. Wider registers, more registers,
>>> crypto acceleration instructions and SIMD instructions are all
>>> very nice to have. I don't know the specifics of AES, though, or
>>> what kind of crypto algorithm it is, so it's entirely possible
>>> that one can't effectively parallelize it except in some
>>> relatively unique circumstances.
>> 
>> Do you have much experience of writing assembler?
>> 
>> I don't, and I'm not an expert on this, but I've read the odd blog
>> article on this subject over the years.
> 
> Similar level of experience here. I can read it, even debug it from 
> time to time. A few regular bloggers on the subject are like candy. 
> And I used to have pagetable.org, Ars's Technopaedia and specsheets 
> for early x86 and motorola processors memorized. For the past couple 
> years, I've been focusing on reading blogs of language and compiler 
> authors, academics involved in proofing, testing and improving them, 
> etc.
> 
>> 
>> What I've read often has the programmer looking at the compiled gcc
>> bytecode and examining what it does. The compiler might not care
>> how many registers it uses, and thus a variable might find itself
>> frequently swapped back into RAM; the programmer does not have any
>> control over the compiler, and IIRC some flags reserve a register
>> for degugging (IIRC -fomit-frame-pointer disables this). I think
>> it's possible to use registers more efficiently by swapping them
>> (??) or by using bitwise comparisons and other tricks.
> 
> Sure; it's cheaper to null out a register by XORing it with itself 
> than setting it to 0.
> 
>> 
>> Assembler optimisation is only used on sections of code that are at
>> the core of a loop - that are called hundreds or thousands (even
>> millions?) of times during the program's execution. It's not for
>> code, such as reading the .config file or initialisation, which is
>> only called once. Because the code in the core of the loop is
>> called so often, you don't have to achieve much of an optimisation
>> for the aggregate to be much more considerable.
> 
> Sure; optimize the hell out of the code where you spend most of your 
> time. I wasn't aware that gcc passed up on safe optimization 
> opportunities, though.
> 
>> 
>> The operations in question may only be constitute a few lines of C,
>> or a handful of machine operations, so it boils down to an
>> algorithm that a human programmer is capable of getting a grip on
>> and comprehending. Whilst compilers are clearly more efficient for
>> large programs, on this micro scale, humans are more clever and
>> creative than machines.
> 
> I disagree. With defined semantics for the source and target, a 
> computer's cleverness is limited only by the computational and
> memory expense of its search algorithms. Humans get through this by
> making habit various optimizations, but those habits become less
> useful as additional paths and instructions are added. As system
> complexity increases, humans operate on personally cached techniques
> derived from simpler systems. I would expect very, very few people to
> be intimately familiar with the the majority of optimization
> possibilities present on an amdfam10 processor or a core2. Compiler's
> aren't necessarily familiar with them, either; they're just quicker
> at discovering them, given knowledge of the individual instructions
> and the rules of language semantics.
> 
>> 
>> Encryption / decryption is an example of code that lends itself to
>> this kind of optimisation. In particular AES was designed, I
>> believe, to be amenable to implementation in this way. The reason
>> for that was that it was desirable to have it run on embedded
>> devices and on dedicated chips. So it boils down to a simple
>> bitswap operation (??) - the plaintext is modified by the
>> encryption key, input and output as a fast stream. Each byte goes
>> in, each byte goes out, the same function performed on each one.
> 
> I'd be willing to posit that you're right here, though if there
> isn't a per-byte feedback mechanism, SIMD instructions would come
> into serious play. But I expect there's a per-byte feedback
> mechanism, so parallelization would likely come in the form of
> processing simultaneous streams.
> 
>> 
>> Another operation that lends itself to assembler optimisation is
>> video decoding - the video is encoded only once, and then may be
>> played back hundreds or millions of times by different people. The
>> same operations must be repeated a number of times on each frame,
>> then c 25 - 60 frames are decode

Re: [gentoo-user] hard drive encryption

[Florian Philipp]

> 
> This thread is becoming ridiculously long. Just as a last side-note:
> 
> One of the primary reasons that the IA64 architecture failed was that it
> relied on the compiler to optimize the code in order to exploit the
> massive instruction-level parallelism the CPU offered. Compilers never
> became good enough for the job. Of course, that happended in the
> nineties and we have much better compilers now (and x86 is easier to
> handle for compilers). But on the other hand: That was Intel's next big
> thing and if they couldn't make the compilers work, I have no reason to
> believe in their efficiency now.
> 
> Regards,
> Florian Philipp

Argh, just as I want to quit: I had the dates garbled up. IA64 came out
in 2001 but the compiler design was of course a product of the late
nineties and the design process started mid-nineties.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 1:47 PM, Alan Mackenzie  wrote:
> Hello, Walter,
>
> On Tue, Mar 13, 2012 at 03:00:52PM -0400, Walter Dnes wrote:
>> On Tue, Mar 13, 2012 at 01:05:34PM +, Alan Mackenzie wrote
>
>> > I also did "2> {system,world}.err".  system.err was empty.  I've included
>> > world.err in the enclosed tarball.
>
>>   From your error listing, it looks like lvm2, kde, and gnome (including
>> the XFCE subset) require udev.  Ouch.
>
> :-)  This cannot be the case.  Otherwise somebody would have said.  Hmm.
> What we could do with is a "requires xdev", for x in (m u).  I've
> forgotten what that's called in portage.
>
> There are surely lots of packages marked "need udev" which don't really
> need it at all.  I mean, are there any programs which need precisely
> udev to work, as opposed to a populated /dev?
>
> I mean, what does udev give me that mdev won't?  That's not really a
> rhetorical question.  What potential benefits am I throwing away by
> converting to mdev?

>From my desktop:

centurion ~ # equery depends udev
 * These packages depend on udev:
dev-libs/libatasmart-0.18 (>=sys-fs/udev-143)
dev-python/python-gudev-147.2 (>=sys-fs/udev-171[gudev])
  (>=sys-fs/udev-147[extras])
gnome-base/gnome-settings-daemon-3.2.2-r1 (packagekit ? sys-fs/udev[gudev])
  (packagekit ? sys-fs/udev[extras])
  (udev ? sys-fs/udev[gudev])
  (udev ? sys-fs/udev[extras])
gnome-base/gvfs-1.10.1 (!prefix ? >=sys-fs/udev-164-r2)
   (>=sys-fs/udev-171[gudev])
   (>=sys-fs/udev-145[extras])
media-gfx/shotwell-0.11.6 (>=sys-fs/udev-171[gudev])
  (>=sys-fs/udev-145[extras])
media-libs/libcanberra-0.28-r5 (udev ? >=sys-fs/udev-160)
media-libs/libgpod-0.8.0 (udev ? sys-fs/udev)
media-libs/mesa-7.11.2 (gbm ? sys-fs/udev)
media-sound/pulseaudio-1.1-r1 (udev ? >=sys-fs/udev-171[hwdb])
  (udev ? >=sys-fs/udev-143[extras])
media-sound/rhythmbox-2.95 (>=sys-fs/udev-171[gudev])
   (>=sys-fs/udev-145[extras])
media-video/cheese-3.2.2 (>=sys-fs/udev-171[gudev])
 (>=sys-fs/udev-145-r1[extras])
net-im/empathy-3.2.2 (v4l ? sys-fs/udev[gudev])
 (v4l ? sys-fs/udev[extras])
net-misc/networkmanager-0.9.2.0-r5 (>=sys-fs/udev-171[gudev])
   (>=sys-fs/udev-147[extras])
net-wireless/bluez-4.98-r2 (>=sys-fs/udev-169)
net-wireless/gnome-bluetooth-3.2.2 (sys-fs/udev)
sys-apps/systemd-43-r1 (>=sys-fs/udev-172)
sys-fs/lvm2-2.02.88 (>=sys-fs/udev-151-r4)
sys-fs/udisks-1.0.4-r1 (>=sys-fs/udev-171[gudev])
   (>=sys-fs/udev-147[extras])
sys-kernel/dracut-017-r2 (>=sys-fs/udev-164)
sys-power/upower-0.9.15 (kernel_linux ? >=sys-fs/udev-171-r1[gudev])
(kernel_linux ? =sys-fs/udev-150)
x11-libs/cairo-1.10.2-r1 (drm ? >=sys-fs/udev-136)
x11-misc/colord-0.1.15 (udev ? sys-fs/udev[gudev])
   (udev ? sys-fs/udev[extras])

I don't know exactly what packages actually *require* udev. What I can
say with some certainty is that more and more "maistream" packages
will require udev either directly or indirectly (by some dep).

You will lose those with mdev.

"Fringe" programs will not require udev, or it will be optional; but
the moment a "fringe" program reaches critical mass to become
"maistream", the probability of it needing udev (directly or
indirectly) will increase.

I'm willing to bet a beer on that prediction.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6

[Walter Dnes]

  This revision includes some checking to see if your system can run
without udev.  In general, if you use any of...
* GNOME
* KDE
* XFCE
* lvm2
... you probably need udev, so mdev is not for you.  I've also found one
situation where I need to take one extra step to run without udev.  I
have a laptop with a Radeon GPU that requires a binary blob for the
video driver.  emerging radeon-ucode downloads a whole slew of binary
blobs, to support umpteen different models.  If I leave all the binary
blobs in the library directory, the kernwl needs udev to figure out
which one of the many binary blobs to load.  If I remove all the other
binary blobs, and leave only the correct one in the library directory,
it loads automatically.

  There is one more imperfect sanity check you can run to check for udev
dependancy if none of the above apply...

a) add the line
sys-fs/udev
to /etc/portage/package.mask

b) execute the 2 commands
emerge -pv system
emerge -pv world

c) if the only errors you get are for not being able to re-install udev
as required by virtual/dev-manager-0, you can proceed to the next stage,
Otherwise, remove the "sys-fs/udev" line from /etc/portage/package.mask
and forget about mdev.

  Proceed here only if the above stages don't find any udev
dependancies.

  The usual warnings apply...
* this is a beta
* use a spare test machine
* if you don't follow the instructions correctly, the result might be
  an unbootable linux
* even if you do follow instructions, the result might be an unbootable
  linux


1) Set up your kernel to support and automount a devtmpfs filesystem at
   /dev

* If you prefer to edit .config directly, set
  CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y

* If you prefer "make menuconfig", the route is as shown below.  Note
  that the "Autount devtmpfs..." option won't appear until you enable
  "Maintain a devtmpf..." option.

make menuconfig
  Device Drivers  --->
Generic Driver Options  --->
  [*] Maintain a devtmpfs filesystem to mount at /dev
  [*]   Automount devtmpfs at /dev, after the kernel mounted the rootfs

  Once you've made the changes, rebuild the kernel.


2) Set up for emerging busybox.  busybox requires the "mdev" flag in
this situation.  The "static" flag is probably also a good idea.  In
file /etc/portage/package.use add the line

sys-apps/busybox static mdev

   Now, "emerge busybox"


3 a) Create /sbin/linuxrc containing at least

#!/bin/busybox ash
mount -t proc proc /proc
mount -t sysfs sysfs /sys
exec /sbin/init

  This should be enough for most users.  If you have an unusual setup,
you may need additional stuff in there.  Remember to
"chmod 744 /sbin/linuxrc" to make it executable.

3 b) In the bootloader "append" line, include "init=/sbin/linuxrc".  If
you're using lilo remember to re-run lilo to implement the changes.  If
you're using another bootloader, make the equivalant initialization.


4) Remove udev from the services list, and replace it with mdev.  Type
   the following 2 commands at the command line
rc-update del udev sysinit
rc-update add mdev sysinit


5) reboot to your new kernel.  You're now running without using udev.


6) Remove udev as per the following instructions...

* execute the following command at the commandline
emerge --unmerge sys-fs/udev

* In file /etc/portage/package.mask, append the line
sys-fs/udev
  Create the file if it doesn't already exist.  You now have a totally
udev-free machine

-- 
Walter Dnes 

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Bruce Hill, Jr.]

On March 13, 2012 at 4:27 PM "Canek Peláez Valdés" 
wrote:

>
> "Fringe" programs will not require udev, or it will be optional; but
> the moment a "fringe" program reaches critical mass to become
> "maistream", the probability of it needing udev (directly or
> indirectly) will increase.
>
> I'm willing to bet a beer on that prediction.
>
> Regards.
> --
> Canek Peláez Valdés



It _sounds_ like your definition of a "fringe" program is one that does not
need udev; but when it becomes "mainstream" it will need udev. If not, you
write us the definition of a "fringe" program and a "mainstream" program.

Excuse me, but that's just incredibly _arrogant_!

I wasn't getting into this ridiculous discussion, but your irresponsible
ranting...

Yes, I dedicate my "Linux life" to killing FUD, and that post of yours is
FUD!

I'm from the South, where FUD is colloquially called bull. <:-)}

Below are some "mainstream" programs that my every computer on the LAN in
my computer business uses _every_ day which don't require udev:

x11-terms/rxvt-unicode
app-editors/vim
net-misc/dhcpcd
...

The more I think about your arrogance, the more ticked off I get! Here's
the very few packages on my workstation that _do_ require udev:

mingdao@workstation ~ $ equery depends udev
 * These packages depend on udev:
media-libs/libcanberra-0.28-r5 (udev ? >=sys-fs/udev-160)
media-libs/mesa-7.11.2 (gbm ? sys-fs/udev)
media-video/vlc-1.1.13 (udev ? >=sys-fs/udev-142)
net-print/hplip-3.11.10 (acl ? >=sys-fs/udev-171[acl])
(acl ? >=sys-fs/udev-145[extras])
(kernel_linux ? >=sys-fs/udev-114)
sys-fs/lvm2-2.02.88 (>=sys-fs/udev-151-r4)
virtual/dev-manager-0 (sys-fs/udev)
x11-base/xorg-server-1.11.2-r2 (udev ? >=sys-fs/udev-150)
x11-libs/cairo-1.10.2-r1 (drm ? >=sys-fs/udev-136)
x11-libs/libva-1.0.15 (video_cards_dummy ? sys-fs/udev)

Perhaps it would be ridiculously easy to get rid of udev on this box. But,
that's not the point I'm making here.

It's not so much that udev is evil, to me; but that requiring an initrd is
stupid.
And, it's not so much udev vs. mdev or whatever, but that your attitude
_STINKS_!

Geez...
--
Happy Penguin Computers>`)
126 Fenco Drive( \
Tupelo, MS 38801^^
662-269-2706; 662-491-8613
support at happypenguincomputers dot com
http://www.happypenguincomputers.com

Re: [gentoo-user] gnome tracker for thunderbird

[Stefan G. Weichinger]

Am 12.03.2012 12:24, schrieb Stefan G. Weichinger:
> 
> I only recently emerged the gnome tracker and try to index my
> thunderbird emails.
> 
> tracker-control -l shows that the "email"-miner is/seems disabled.
> 
> I used USE=thunderbird for app-misc/tracker and I see the addon
> "Trackerbird" within thunderbird. But I saw the addon indexing mails
> (status bar in TB).
> 
> I wonder why it is listed disabled, and how to correctly enable/use it.

disabled "trackerbird" addon ... grabbing CPU and making things slow here.

internal TB search is good enough ...

Now I fiddle with "out of office" addon ... I would need that one badly :-P

Re: [gentoo-user] hard drive encryption

[Frank Steinmetzger]

On Tue, Mar 13, 2012 at 07:58:55PM +0100, Florian Philipp wrote:

> >> From what I can see in the kernel sources, there is a generic AES
> >> implementation using nothing but portable C code and then there is
> >> "aes-i586" assembler code with "aes_glue" C code.
> > 
> >> So I assume the i586
> >> version is better for you --- unless GCC suddenly got a lot better at
> >> optimizing code.
> > 
> > Since when, exactly? GCC isn't the best compiler at optimization, but
> > I fully expect current versions to produce better code for x86-64 than
> > hand-tuned i586. Wider registers, more registers, crypto acceleration
> > instructions and SIMD instructions are all very nice to have. I don't
> > know the specifics of AES, though, or what kind of crypto algorithm it
> > is, so it's entirely possible that one can't effectively parallelize
> > it except in some relatively unique circumstances.
> > 
> 
> One sec. We are talking about an Core2 Duo running in 32bit mode, right?
> That's what the i686 reference in the question meant --- or at least,
> that's what I assumed.

Sorry, I forgot to mention that I'm running 32 bit, yes. I don't really see
the benefit of 64 bit for my use case. For all I know, the executables get
bigger and my poor old laptop will have to shuffle more bits around. :)

However, hardware AES would be *the* reason for me to, instead of a netbook,
buy something with an i5 in my next laptop, some time in the distant future.
-- 
Gruß | Greetings | Qapla'
I forbid any use of my email addresses with Facebook services.

Ein Computer stürzt nur ab, wenn der Text lange nicht gespeichert wurde.


pgpU3gNUbjZL6.pgp
Description: PGP signature

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

Hello, Canek,

I thought you'd be replying to me here.  :-)

On Tue, Mar 13, 2012 at 02:27:25PM -0600, Canek Peláez Valdés wrote:
> On Tue, Mar 13, 2012 at 1:47 PM, Alan Mackenzie  wrote:
> > Hello, Walter,

> > On Tue, Mar 13, 2012 at 03:00:52PM -0400, Walter Dnes wrote:
> >> On Tue, Mar 13, 2012 at 01:05:34PM +, Alan Mackenzie wrote

> >> > I also did "2> {system,world}.err".  system.err was empty.  I've included
> >> > world.err in the enclosed tarball.

> >>   From your error listing, it looks like lvm2, kde, and gnome (including
> >> the XFCE subset) require udev.  Ouch.

> > :-)  This cannot be the case.  Otherwise somebody would have said.  Hmm.
> > What we could do with is a "requires xdev", for x in (m u).  I've
> > forgotten what that's called in portage.

> > There are surely lots of packages marked "need udev" which don't really
> > need it at all.  I mean, are there any programs which need precisely
> > udev to work, as opposed to a populated /dev?

> > I mean, what does udev give me that mdev won't?  That's not really a
> > rhetorical question.  What potential benefits am I throwing away by
> > converting to mdev?

> >>From my desktop:

> centurion ~ # equery depends udev
>  * These packages depend on udev:
> dev-libs/libatasmart-0.18 (>=sys-fs/udev-143)
> dev-python/python-gudev-147.2 (>=sys-fs/udev-171[gudev])
>   (>=sys-fs/udev-147[extras])
> gnome-base/gnome-settings-daemon-3.2.2-r1 (packagekit ? sys-fs/udev[gudev])
>   (packagekit ? sys-fs/udev[extras])
>   (udev ? sys-fs/udev[gudev])
>   (udev ? sys-fs/udev[extras])
> gnome-base/gvfs-1.10.1 (!prefix ? >=sys-fs/udev-164-r2)
>(>=sys-fs/udev-171[gudev])
>(>=sys-fs/udev-145[extras])
> media-gfx/shotwell-0.11.6 (>=sys-fs/udev-171[gudev])
>   (>=sys-fs/udev-145[extras])
> media-libs/libcanberra-0.28-r5 (udev ? >=sys-fs/udev-160)
> media-libs/libgpod-0.8.0 (udev ? sys-fs/udev)
> media-libs/mesa-7.11.2 (gbm ? sys-fs/udev)
> media-sound/pulseaudio-1.1-r1 (udev ? >=sys-fs/udev-171[hwdb])
>   (udev ? >=sys-fs/udev-143[extras])
> media-sound/rhythmbox-2.95 (>=sys-fs/udev-171[gudev])
>(>=sys-fs/udev-145[extras])
> media-video/cheese-3.2.2 (>=sys-fs/udev-171[gudev])
>  (>=sys-fs/udev-145-r1[extras])
> net-im/empathy-3.2.2 (v4l ? sys-fs/udev[gudev])
>  (v4l ? sys-fs/udev[extras])
> net-misc/networkmanager-0.9.2.0-r5 (>=sys-fs/udev-171[gudev])
>(>=sys-fs/udev-147[extras])
> net-wireless/bluez-4.98-r2 (>=sys-fs/udev-169)
> net-wireless/gnome-bluetooth-3.2.2 (sys-fs/udev)
> sys-apps/systemd-43-r1 (>=sys-fs/udev-172)
> sys-fs/lvm2-2.02.88 (>=sys-fs/udev-151-r4)
> sys-fs/udisks-1.0.4-r1 (>=sys-fs/udev-171[gudev])
>(>=sys-fs/udev-147[extras])
> sys-kernel/dracut-017-r2 (>=sys-fs/udev-164)
> sys-power/upower-0.9.15 (kernel_linux ? >=sys-fs/udev-171-r1[gudev])
> (kernel_linux ?  virtual/dev-manager-0 (sys-fs/udev)
> x11-base/xorg-server-1.11.2-r2 (udev ? >=sys-fs/udev-150)
> x11-libs/cairo-1.10.2-r1 (drm ? >=sys-fs/udev-136)
> x11-misc/colord-0.1.15 (udev ? sys-fs/udev[gudev])
>(udev ? sys-fs/udev[extras])

> I don't know exactly what packages actually *require* udev. What I can
> say with some certainty is that more and more "maistream" packages
> will require udev either directly or indirectly (by some dep).

OK.  I haven't heard of anybody here with mdev being unable to run an
application.  Not yet, anyway.

But I really meant what functionality udev has that mdev lacks.  For
example, mdev this morning recognised my USB stick being inserted, and
created /dev/sdc for it.

> You will lose those with mdev.

> "Fringe" programs will not require udev, or it will be optional; but
> the moment a "fringe" program reaches critical mass to become
> "maistream", the probability of it needing udev (directly or
> indirectly) will increase.

> I'm willing to bet a beer on that prediction.

Thanks for the reply.

> Regards.
> -- 
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr.
 wrote:
>
>
>
> On March 13, 2012 at 4:27 PM "Canek Peláez Valdés" 
> wrote:
> 
>>
>> "Fringe" programs will not require udev, or it will be optional; but
>> the moment a "fringe" program reaches critical mass to become
>> "maistream", the probability of it needing udev (directly or
>> indirectly) will increase.
>>
>> I'm willing to bet a beer on that prediction.
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>
>
>
> It _sounds_ like your definition of a "fringe" program is one that does not
> need udev; but when it becomes "mainstream" it will need udev. If not, you
> write us the definition of a "fringe" program and a "mainstream" program.
>
> Excuse me, but that's just incredibly _arrogant_!

Relax man. That's why "fringe" is written QUOTE fringe UNQUOTE, and
"mainstream" is written QUOTE mainstream UNQUOTE. If it makes you
happy, replace "fringe" with "GNOME/KDE/XFCE/lvm2-not-related" and
"mainstream" with "GNOME/KDE/XFCE/lvm2-related". That's using the very
same definition that Walter (the guy behind the mdev-instead-of-udev
effort) used just three mails below (or above, depending on your email
client).

Please chill, no need to get all worked out.

And I maintain my prediction.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Neil Bothwick]

On Tue, 13 Mar 2012 21:07:37 +, Alan Mackenzie wrote:

> But I really meant what functionality udev has that mdev lacks.  For
> example, mdev this morning recognised my USB stick being inserted, and
> created /dev/sdc for it.

udev does a *lot* more than that, for example the persistent naming of
network interfaces. More significantly, it can run programs based on
device rules. For example, usb_modeswitch installs a udev rule to switch a
3G USB modem from CD to modem mode, without which it won't work. That's
fine when you plug it into a running system, but when you boot with it
plugged in, it can trip over itself because the usb_modeswitch executable
is in /usr/sbin.

You could use this to argue that /usr should be mounted before udev is
started, but you could just as well use it to argue that udev should not
be trying to run such rules at the boot runlevel.


-- 
Neil Bothwick

... "I dropped my toothpaste," Tom said, Crestfallen.


signature.asc
Description: PGP signature

Re: [gentoo-user] how updating to gnome3 ?!

[Tamer Higazi]

Hi Alan!
you were right. It is masked! I figured out that "autounmask" is not in
portage, because of that I believe that this might not be the only
package that is masked


tamer@office ~ $ emerge -pv =gnome-3.2.1

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy ">=x11-wm/mutter-3.2.1" have been masked.
!!! One of the following masked packages is required to complete your
request:
- x11-wm/mutter-3.2.2::gentoo (masked by: ~amd64 keyword)
- x11-wm/mutter-3.2.1-r1::gentoo (masked by: ~amd64 keyword)

(dependency required by "gnome-base/gnome-3.2.1" [ebuild])
(dependency required by "=gnome-3.2.1" [argument])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

tamer@office ~ $





Am 12.03.2012 21:35, schrieb Alan McKinnon:
> On your system "emerge gnome" wants to install gnome-2
> 
> So either your tree is outdated (you must re-sync) or gnome-3 is still
> masked. The second option is more likely and there are two
> possibilities for that:
> 
> You run a stable system (gnome-3 is still unstable), or
> you masked it for some reason.
> 
> Run this and examine what output you get:
> 
> emerge -pv =gnome-3.2.1
> 
> 
> 
> 
> 
> On Mon, 12 Mar 2012 13:56:56 +0100
> Tamer Higazi  wrote:
> 
>> Hi Alan!
>> I thought more or less that I have to unmask packages, or making any
>> configurations to unlock the update to gnome3.
>>
>> If I run now:
>>
>> tamer@office ~ $ emerge -pav gnome
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>> [ebuild   R] gnome-base/gnome-2.32.1-r1  USE="cdr cups dvdr ldap
>> policykit -accessibility -mono" 0 kB
>>
>> Total: 1 package (1 reinstall), Size of downloads: 0 kB
>> tamer@office ~ $
>>
>>
>> I get one package to reinstall.
>>
>>
>> If I run "layman -a gnome" and re-execute the command:
>>
>>
>> I got this message:
>>
>> * If you enabled the GNOME overlay to get GNOME 3.2, please disable
>>  * it now, since GNOME 3.2 is already in portage and unmasked.
>>
>>
>>
>> How do I install gnome 3.2, that is now in portage?!
>>
>>
>>
>> Tamer
>>
>>
>>
>>
>> Am 11.03.2012 17:43, schrieb Alan McKinnon:
>>> On Sun, 11 Mar 2012 17:01:41 +0100
>>> Tamer Higazi  wrote:
>>>
 Hi people!
 I want to upgrade gnome 2.32 to gnome 3.

 First question, is it now officially supported by the gentoo team
 or should I keep my fingers away of it?!

 http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-3.2-upgrade.xml

 doesn't tell me a lot how to accomplish this task. Is there any
 official documentation telling me how to doit, unmasking, flags
 etc


 for any advise I would thank you.
>>>
>>> What sort of information are you looking for?
>>>
>>> gnome-3 is marked unstable, so if you run ~x86 or ~amd64 just
>>>
>>> emerge -av gnome
>>>
>>> and deal with any breakage. This is generally how gentoo works for
>>> everything. What were you expecting in terms of documentation ?
>>>
>>>
>>
>>
> 
> 
> 

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Bruce Hill, Jr.]

On March 13, 2012 at 5:22 PM "Canek Peláez Valdés" 
wrote:

> On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr.
>  wrote:
> >
> >
> >
> > On March 13, 2012 at 4:27 PM "Canek Peláez Valdés" 
> > wrote:
> > 
> >>
> >> "Fringe" programs will not require udev, or it will be optional; but
> >> the moment a "fringe" program reaches critical mass to become
> >> "maistream", the probability of it needing udev (directly or
> >> indirectly) will increase.
> >>
> >> I'm willing to bet a beer on that prediction.
> >>
> >> Regards.
> >> --
> >> Canek Peláez Valdés
> >
> >
> >
> > It _sounds_ like your definition of a "fringe" program is one that does
not
> > need udev; but when it becomes "mainstream" it will need udev. If not,
you
> > write us the definition of a "fringe" program and a "mainstream"
program.
> >
> > Excuse me, but that's just incredibly _arrogant_!
>
> Relax man. That's why "fringe" is written QUOTE fringe UNQUOTE, and
> "mainstream" is written QUOTE mainstream UNQUOTE. If it makes you
> happy, replace "fringe" with "GNOME/KDE/XFCE/lvm2-not-related" and
> "mainstream" with "GNOME/KDE/XFCE/lvm2-related". That's using the very
> same definition that Walter (the guy behind the mdev-instead-of-udev
> effort) used just three mails below (or above, depending on your email
> client).
>
> Please chill, no need to get all worked out.
>
> And I maintain my prediction.
>
> Regards.
> --
> Canek Peláez Valdés


So, what qualifies for "the moment a "fringe" program reaches critical mass
to become "maistream", the probability of it needing udev (directly or
indirectly) will increase."

Again, quoting _your_ definition.

I gave you examples of programs which have reached critical mass, which
don't require udev.

And, I'm not attaching your character, for I know you not ... just
attacking your FUD!
--
Happy Penguin Computers>`)
126 Fenco Drive( \
Tupelo, MS 38801^^
662-269-2706; 662-491-8613
support at happypenguincomputers dot com
http://www.happypenguincomputers.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 3:35 PM, Bruce Hill, Jr.
 wrote:
>
>
>
> On March 13, 2012 at 5:22 PM "Canek Peláez Valdés" 
> wrote:
>
>> On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr.
>>  wrote:
>> >
>> >
>> >
>> > On March 13, 2012 at 4:27 PM "Canek Peláez Valdés" 
>> > wrote:
>> > 
>> >>
>> >> "Fringe" programs will not require udev, or it will be optional; but
>> >> the moment a "fringe" program reaches critical mass to become
>> >> "maistream", the probability of it needing udev (directly or
>> >> indirectly) will increase.
>> >>
>> >> I'm willing to bet a beer on that prediction.
>> >>
>> >> Regards.
>> >> --
>> >> Canek Peláez Valdés
>> >
>> >
>> >
>> > It _sounds_ like your definition of a "fringe" program is one that does
> not
>> > need udev; but when it becomes "mainstream" it will need udev. If not,
> you
>> > write us the definition of a "fringe" program and a "mainstream"
> program.
>> >
>> > Excuse me, but that's just incredibly _arrogant_!
>>
>> Relax man. That's why "fringe" is written QUOTE fringe UNQUOTE, and
>> "mainstream" is written QUOTE mainstream UNQUOTE. If it makes you
>> happy, replace "fringe" with "GNOME/KDE/XFCE/lvm2-not-related" and
>> "mainstream" with "GNOME/KDE/XFCE/lvm2-related". That's using the very
>> same definition that Walter (the guy behind the mdev-instead-of-udev
>> effort) used just three mails below (or above, depending on your email
>> client).
>>
>> Please chill, no need to get all worked out.
>>
>> And I maintain my prediction.
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>
>
> So, what qualifies for "the moment a "fringe" program reaches critical mass
> to become "maistream", the probability of it needing udev (directly or
> indirectly) will increase."

Just what I was saying: I said (right there) "the probability of it
needing udev (directly or indirectly) will increase." I did not say it
would *need* udev for sure; just that the probability of it needing
udev would increase.

I'm not spreading FUD; I'm just stating my opinion. And I stick to it;
wanna bet that beer?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan McKinnon]

On Tue, 13 Mar 2012 17:35:05 -0400 (EDT)
"Bruce Hill, Jr."  wrote:

> 
> 
> 
> On March 13, 2012 at 5:22 PM "Canek Peláez Valdés" 
> wrote:
> 
> > On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr.
> >  wrote:
> > >
> > >
> > >
> > > On March 13, 2012 at 4:27 PM "Canek Peláez Valdés"
> > >  wrote:
> > > 
> > >>
> > >> "Fringe" programs will not require udev, or it will be optional;
> > >> but the moment a "fringe" program reaches critical mass to become
> > >> "maistream", the probability of it needing udev (directly or
> > >> indirectly) will increase.
> > >>
> > >> I'm willing to bet a beer on that prediction.
> > >>
> > >> Regards.
> > >> --
> > >> Canek Peláez Valdés
> > >
> > >
> > >
> > > It _sounds_ like your definition of a "fringe" program is one
> > > that does
> not
> > > need udev; but when it becomes "mainstream" it will need udev. If
> > > not,
> you
> > > write us the definition of a "fringe" program and a "mainstream"
> program.
> > >
> > > Excuse me, but that's just incredibly _arrogant_!
> >
> > Relax man. That's why "fringe" is written QUOTE fringe UNQUOTE, and
> > "mainstream" is written QUOTE mainstream UNQUOTE. If it makes you
> > happy, replace "fringe" with "GNOME/KDE/XFCE/lvm2-not-related" and
> > "mainstream" with "GNOME/KDE/XFCE/lvm2-related". That's using the
> > very same definition that Walter (the guy behind the
> > mdev-instead-of-udev effort) used just three mails below (or above,
> > depending on your email client).
> >
> > Please chill, no need to get all worked out.
> >
> > And I maintain my prediction.
> >
> > Regards.
> > --
> > Canek Peláez Valdés
> 
> 
> So, what qualifies for "the moment a "fringe" program reaches
> critical mass to become "maistream", the probability of it needing
> udev (directly or indirectly) will increase."

I'll start the reply with a joke. I read a tongue-in-cheek post
somewhere recently (maybe even here) that for a program to be
considered successful at MIT it always gets to a point where it can
send and receive mail. Any program that can't send and receive mail is
obviously not yet good enough for real-world use. Very tongue-in-cheek.

But it's true enough. Hell, the monitoring guys at work use SMTP as
transport for several time-critical monitor probes (a delay of 5
minutes causes all hell to break loose...)

Why SMTP you ask? Well, because it's there. Because it's ubiquitous.
Because you can panelbeat it to make it work even when you shouldn't.
Because corporate coders are lazy. Because corporate coders don't know
any better. Because all of the above.

I really doubt the majority of apps requiring udev actually require
udev itself. Maybe they just need nodes, or only need a node manager.
Most likely, the dev looked at the scene, listed his possibilities and
saw... udev, and nothing else. Therefore it requires udev. Which is
about as logical as requiring /usr/ if you think about it.

Changing this will take a huge mindshift on the part of large developer
communities (outside of udev) to consider other possibilities. This
will take a while, much like wrestling market share away from Apache.


> Again, quoting _your_ definition.
> 
> I gave you examples of programs which have reached critical mass,
> which don't require udev.

> And, I'm not attaching your character, for I know you not ... just
> attacking your FUD!

I'm in the "let's not emulate Microsoft with udev" camp myself, but I
also see the bigger picture. It's not only that udev is pushing it's
agenda on the rest of the stack, one must also consider that the rest
of the stack is doing things that require udev to react, and one of the
fallout cases is separate /usr needing initramfs. I personally don't
like it but I think I understand the ecosystem that produced it.


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

Re: [gentoo-user] how updating to gnome3 ?!

[Alan McKinnon]

Let's deal with your biggest mistake first. You are running a stable
system (you have ACCEPT_KEYWORDS="amd64" in make,conf) but you want to
install gnome-3.

Now that is highly unlikely to work for a very long time yet as gnome-3
is considered nowhere near stable enough yet to be unmasked. Portage is
going to want to unmask vast chunks of your system to meet the
long deep list of dependencies for gnome-3 and this will cause you
sever amounts of pain.

Trust the folks on this list, over the years we have learned that a
stable system (with maybe a few unmasked packages) is OK, an unstable
system is also mostly OK (you just update lots of things often) but it
doesn't break fantastically every other day.

A system that is half stable, half unstable DOES break fantastically
every other day. And this is what you are trying to do.

You have many options, only two are actually realistic:

1. Stay stable, do not use gnome-3
2. Switch to unstable, do a full "emerge -e world", then emerge
gnome-3. It will go easy and probably JustWork out the box.




On Tue, 13 Mar 2012 22:33:56 +0100
Tamer Higazi  wrote:

> Hi Alan!
> you were right. It is masked! I figured out that "autounmask" is not
> in portage, because of that I believe that this might not be the only
> package that is masked
> 
> 
> tamer@office ~ $ emerge -pv =gnome-3.2.1
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> !!! All ebuilds that could satisfy ">=x11-wm/mutter-3.2.1" have been
> masked. !!! One of the following masked packages is required to
> complete your request:
> - x11-wm/mutter-3.2.2::gentoo (masked by: ~amd64 keyword)
> - x11-wm/mutter-3.2.1-r1::gentoo (masked by: ~amd64 keyword)
> 
> (dependency required by "gnome-base/gnome-3.2.1" [ebuild])
> (dependency required by "=gnome-3.2.1" [argument])
> For more information, see the MASKED PACKAGES section in the emerge
> man page or refer to the Gentoo Handbook.
> 
> tamer@office ~ $
> 
> 
> 
> 
> 
> Am 12.03.2012 21:35, schrieb Alan McKinnon:
> > On your system "emerge gnome" wants to install gnome-2
> > 
> > So either your tree is outdated (you must re-sync) or gnome-3 is
> > still masked. The second option is more likely and there are two
> > possibilities for that:
> > 
> > You run a stable system (gnome-3 is still unstable), or
> > you masked it for some reason.
> > 
> > Run this and examine what output you get:
> > 
> > emerge -pv =gnome-3.2.1
> > 
> > 
> > 
> > 
> > 
> > On Mon, 12 Mar 2012 13:56:56 +0100
> > Tamer Higazi  wrote:
> > 
> >> Hi Alan!
> >> I thought more or less that I have to unmask packages, or making
> >> any configurations to unlock the update to gnome3.
> >>
> >> If I run now:
> >>
> >> tamer@office ~ $ emerge -pav gnome
> >>
> >> These are the packages that would be merged, in order:
> >>
> >> Calculating dependencies... done!
> >> [ebuild   R] gnome-base/gnome-2.32.1-r1  USE="cdr cups dvdr
> >> ldap policykit -accessibility -mono" 0 kB
> >>
> >> Total: 1 package (1 reinstall), Size of downloads: 0 kB
> >> tamer@office ~ $
> >>
> >>
> >> I get one package to reinstall.
> >>
> >>
> >> If I run "layman -a gnome" and re-execute the command:
> >>
> >>
> >> I got this message:
> >>
> >> * If you enabled the GNOME overlay to get GNOME 3.2, please disable
> >>  * it now, since GNOME 3.2 is already in portage and unmasked.
> >>
> >>
> >>
> >> How do I install gnome 3.2, that is now in portage?!
> >>
> >>
> >>
> >> Tamer
> >>
> >>
> >>
> >>
> >> Am 11.03.2012 17:43, schrieb Alan McKinnon:
> >>> On Sun, 11 Mar 2012 17:01:41 +0100
> >>> Tamer Higazi  wrote:
> >>>
>  Hi people!
>  I want to upgrade gnome 2.32 to gnome 3.
> 
>  First question, is it now officially supported by the gentoo team
>  or should I keep my fingers away of it?!
> 
>  http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-3.2-upgrade.xml
> 
>  doesn't tell me a lot how to accomplish this task. Is there any
>  official documentation telling me how to doit, unmasking, flags
>  etc
> 
> 
>  for any advise I would thank you.
> >>>
> >>> What sort of information are you looking for?
> >>>
> >>> gnome-3 is marked unstable, so if you run ~x86 or ~amd64 just
> >>>
> >>> emerge -av gnome
> >>>
> >>> and deal with any breakage. This is generally how gentoo works for
> >>> everything. What were you expecting in terms of documentation ?
> >>>
> >>>
> >>
> >>
> > 
> > 
> > 
> 
> 



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

[gentoo-user] virt-manager-0.9.1 broken?

[Stefan G. Weichinger]

Anyone else seeing this?

No bugreport yet, and I rebuilt and revdeped 

Stefan

Re: [gentoo-user] virt-manager-0.9.1 broken?

[Alan McKinnon]

On Tue, 13 Mar 2012 23:13:33 +0100
"Stefan G. Weichinger"  wrote:

> 
> Anyone else seeing this?
> 
> No bugreport yet, and I rebuilt and revdeped 
> 
> Stefan
> 

I'm thinking you hit send before typing up the bit where you say what
the issue is you are having.

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

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

Hello, Neil.

On Tue, Mar 13, 2012 at 09:33:30PM +, Neil Bothwick wrote:
> On Tue, 13 Mar 2012 21:07:37 +, Alan Mackenzie wrote:

> > But I really meant what functionality udev has that mdev lacks.  For
> > example, mdev this morning recognised my USB stick being inserted, and
> > created /dev/sdc for it.

> udev does a *lot* more than that, for example the persistent naming of
> network interfaces. More significantly, it can run programs based on
> device rules.

This is where I start getting unhappy.  Is there any need for this
blurring?  Having device nodes is essential to a linux system, and
some programs use these nodes.  Why must they be mashed together into a
tasteless mush?  Is there some advantage to this I haven't twigged yet?

> For example, usb_modeswitch installs a udev rule to switch a 3G USB
> modem from CD to modem mode, without which it won't work.

Same question as above: why does that switching have to be done via the
device node system rather than via the driver.  Isn't that what drivers
are for?

> That's fine when you plug it into a running system, but when you boot
> with it plugged in, it can trip over itself because the usb_modeswitch
> executable is in /usr/sbin.

Er, that's a different discussion altogether.  ;-)

> You could use this to argue that /usr should be mounted before udev is
> started, but you could just as well use it to argue that udev should not
> be trying to run such rules at the boot runlevel.

Or that udev shouldn't have "rules".  I still don't understand the basic
concept driving this thing.  My HDDs don't need rules - they just need a
mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
drivers built into my kernel.

Am I being stupid?  Despite your example above, I still don't see what
udev is about, why it's necessary, or even why it's advantageous.

> -- 
> Neil Bothwick

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Bruce Hill, Jr.]

On March 13, 2012 at 5:49 PM "Canek Peláez Valdés" 
wrote:


> Just what I was saying: I said (right there) "the probability of it
> needing udev (directly or indirectly) will increase." I did not say it
> would *need* udev for sure; just that the probability of it needing
> udev would increase.

And I call FUD!

> I'm not spreading FUD; I'm just stating my opinion. And I stick to it;
> wanna bet that beer?

I don't bet or drink, but will say "you're right" if you produce verifiable
facts.

> Regards.
> --
> Canek Peláez Valdés
--
Happy Penguin Computers>`)
126 Fenco Drive( \
Tupelo, MS 38801^^
662-269-2706; 662-491-8613
support at happypenguincomputers dot com
http://www.happypenguincomputers.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie  wrote:
> Hello, Neil.
>
> On Tue, Mar 13, 2012 at 09:33:30PM +, Neil Bothwick wrote:
>> On Tue, 13 Mar 2012 21:07:37 +, Alan Mackenzie wrote:
>
>> > But I really meant what functionality udev has that mdev lacks.  For
>> > example, mdev this morning recognised my USB stick being inserted, and
>> > created /dev/sdc for it.
>
>> udev does a *lot* more than that, for example the persistent naming of
>> network interfaces. More significantly, it can run programs based on
>> device rules.
>
> This is where I start getting unhappy.  Is there any need for this
> blurring?  Having device nodes is essential to a linux system, and
> some programs use these nodes.  Why must they be mashed together into a
> tasteless mush?  Is there some advantage to this I haven't twigged yet?
>
>> For example, usb_modeswitch installs a udev rule to switch a 3G USB
>> modem from CD to modem mode, without which it won't work.
>
> Same question as above: why does that switching have to be done via the
> device node system rather than via the driver.  Isn't that what drivers
> are for?
>
>> That's fine when you plug it into a running system, but when you boot
>> with it plugged in, it can trip over itself because the usb_modeswitch
>> executable is in /usr/sbin.
>
> Er, that's a different discussion altogether.  ;-)
>
>> You could use this to argue that /usr should be mounted before udev is
>> started, but you could just as well use it to argue that udev should not
>> be trying to run such rules at the boot runlevel.
>
> Or that udev shouldn't have "rules".  I still don't understand the basic
> concept driving this thing.  My HDDs don't need rules - they just need a
> mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
> drivers built into my kernel.
>
> Am I being stupid?  Despite your example above, I still don't see what
> udev is about, why it's necessary, or even why it's advantageous.

IMHO, the thing that most people are missing is the fact that neither
udev nor Linux "got complicated". The computing world itself "got
complicated".

We have Linux running in the same beige machines it has been running
since 1991, but it also runs in TVs, tablets, cellphones, fridges,
cars, ebook readers, and (soon enough, I'm sure) the kitchen sink.
This devices behave very differently from our old and beloved beige
boxen. They need to handle lots of different hardware comming and
going, via USB, Firewire, Bluetooth, WIMAX, and who knows what else in
the future.

The principal idea behind udev, is that we *don't* kown (we *can't*
know) what hardware this or that machine is gonna have at some point.
And we want the machine (and the new hardware) to "just work" when
they are connected.

This is overkill for our old and beloved beige boxen? In some cases;
not in mine, where I have bluetooth headphones, cell phones, and
gamepads, and USB speakers, or where I connect different LCD/LED TVs
to my machines. But for some very specific cases it is overkill, in
the sense that fuel injection is "overkill" to get a car moving.

And the guys pushing this changes believe that we don't need to cater
to the simple beige box (usually servers) crowd anymore: we already
got them. We need to cater to everybody else: in particular, at this
moment (if the analysts numbers are right) the users of Linux in
cellphones surpases the users of Linux in beige boxen... and by a lot
it seems. We need to focus in them, and hope they will ask for Linux
in their beige boxen if they like their other gadgets.

We can discuss the merits of their plan, but I for one I'm with them.
I've been using Linux more than 15 years, and with my GNOME 3 system
today (yes, with udev, and systemd, and PulseAudio) I'm much more
productive than with the command line 10 years ago. My servers run
systemd; they not need it, in the sense that they could work without
it (and my car run without fuel injection). But I'm very happy with
the features running systemd in a server gives me (and the fuel
efficiency the fuel injection gives my car).

So, yeah, it's more complicated. The world got complicate; better get
used to it.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] virt-manager-0.9.1 broken?

[Bruce Hill, Jr.]

On March 13, 2012 at 6:13 PM "Stefan G. Weichinger"  wrote:

>
> Anyone else seeing this?
>
> No bugreport yet, and I rebuilt and revdeped 
>
> Stefan
>


There is a stabilization request for it:
https://bugs.gentoo.org/show_bug.cgi?id=407559
--
Happy Penguin Computers>`)
126 Fenco Drive( \
Tupelo, MS 38801^^
662-269-2706; 662-491-8613
support at happypenguincomputers dot com
http://www.happypenguincomputers.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 4:36 PM, Bruce Hill, Jr.
 wrote:
>
>
>
> On March 13, 2012 at 5:49 PM "Canek Peláez Valdés" 
> wrote:
>
>
>> Just what I was saying: I said (right there) "the probability of it
>> needing udev (directly or indirectly) will increase." I did not say it
>> would *need* udev for sure; just that the probability of it needing
>> udev would increase.
>
> And I call FUD!

Call all you want mate, doesn't make it true ;)

>> I'm not spreading FUD; I'm just stating my opinion. And I stick to it;
>> wanna bet that beer?
>
> I don't bet or drink, but will say "you're right" if you produce verifiable
> facts.

I'm making a prediction, man. The only "verifiable fact" is in the
future, and my crystall ball is in the shop.

And I don't care if you (or anybody for that matter) says that I'm
right or wrong. I'm just stating my opinion. And I will keep stating
it.

And really, relax. We are all on gentoo-user trying to learn a little
and get (or give) help from time to time. That's all.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Neil Bothwick]

On Tue, 13 Mar 2012 22:20:19 +, Alan Mackenzie wrote:

> > udev does a *lot* more than that, for example the persistent naming of
> > network interfaces. More significantly, it can run programs based on
> > device rules.
> 
> This is where I start getting unhappy.  Is there any need for this
> blurring?  Having device nodes is essential to a linux system, and
> some programs use these nodes.  Why must they be mashed together into a
> tasteless mush?  Is there some advantage to this I haven't twigged yet?

I agree with you on this. The initial creation of device nodes belongs in
early startup, running arbitrary programs does not.

> > For example, usb_modeswitch installs a udev rule to switch a 3G USB
> > modem from CD to modem mode, without which it won't work.
> 
> Same question as above: why does that switching have to be done via the
> device node system rather than via the driver.  Isn't that what drivers
> are for?

udev is not a device node system, it is a device manager. Requiring
drivers to handle it gets us into the same mess as Windows, where each
driver has to implement the same functionality itself. If a new modem is
released with a different USB ID, but using the same driver, your way
would require a new kernel, the current approach requires one line to be
added to a config file.

> > That's fine when you plug it into a running system, but when you boot
> > with it plugged in, it can trip over itself because the usb_modeswitch
> > executable is in /usr/sbin.
> 
> Er, that's a different discussion altogether.  ;-)

How so? It's central to the whole "when do we need /usr?" debate.

> > You could use this to argue that /usr should be mounted before udev is
> > started, but you could just as well use it to argue that udev should
> > not be trying to run such rules at the boot runlevel.
> 
> Or that udev shouldn't have "rules".  I still don't understand the basic
> concept driving this thing.  My HDDs don't need rules - they just need a
> mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
> drivers built into my kernel.

"I don't need it so no one needs it". It sounds like what you need is
mdev, but many people want or need more from a device manager. There are
many more and varied devices than simple hard disks.

> Am I being stupid?  Despite your example above, I still don't see what
> udev is about, why it's necessary, or even why it's advantageous.

What you don't see is why *you* need it, and that's fair enough. Just
consider that it does things that others need, even if you don't.

But I still think the requirement for /usr to be mounted is a lazy, if
understandable, solution to the way udev's operations are implemented.
After all, the vast majority of PC Linux installations out there already
use an initramfs.


-- 
Neil Bothwick

How do I set my laser printer to stun?


signature.asc
Description: PGP signature

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

On Tue, Mar 13, 2012 at 04:38:08PM -0600, Canek Peláez Valdés wrote:
> On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie  wrote:
> > Hello, Neil.

> > On Tue, Mar 13, 2012 at 09:33:30PM +, Neil Bothwick wrote:
> >> On Tue, 13 Mar 2012 21:07:37 +, Alan Mackenzie wrote:

> >> > But I really meant what functionality udev has that mdev lacks.  For
> >> > example, mdev this morning recognised my USB stick being inserted, and
> >> > created /dev/sdc for it.

> >> udev does a *lot* more than that, for example the persistent naming of
> >> network interfaces. More significantly, it can run programs based on
> >> device rules.

> > This is where I start getting unhappy.  Is there any need for this
> > blurring?  Having device nodes is essential to a linux system, and
> > some programs use these nodes.  Why must they be mashed together into a
> > tasteless mush?  Is there some advantage to this I haven't twigged yet?

> >> For example, usb_modeswitch installs a udev rule to switch a 3G USB
> >> modem from CD to modem mode, without which it won't work.

> > Same question as above: why does that switching have to be done via the
> > device node system rather than via the driver.  Isn't that what drivers
> > are for?

> >> That's fine when you plug it into a running system, but when you boot
> >> with it plugged in, it can trip over itself because the usb_modeswitch
> >> executable is in /usr/sbin.

> > Er, that's a different discussion altogether.  ;-)

> >> You could use this to argue that /usr should be mounted before udev is
> >> started, but you could just as well use it to argue that udev should not
> >> be trying to run such rules at the boot runlevel.

> > Or that udev shouldn't have "rules".  I still don't understand the basic
> > concept driving this thing.  My HDDs don't need rules - they just need a
> > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
> > drivers built into my kernel.

> > Am I being stupid?  Despite your example above, I still don't see what
> > udev is about, why it's necessary, or even why it's advantageous.

> IMHO, the thing that most people are missing is the fact that neither
> udev nor Linux "got complicated". The computing world itself "got
> complicated".

Not really.  It's been getting more complicated since long before I
starting working in it in 1980.  Nothing's changed there.

> We have Linux running in the same beige machines it has been running
> since 1991, but it also runs in TVs, tablets, cellphones, fridges,
> cars, ebook readers, and (soon enough, I'm sure) the kitchen sink.
> This devices behave very differently from our old and beloved beige
> boxen.

Not at the level of needing device nodes under /dev and drivers connected
to them, they haven't.

> They need to handle lots of different hardware comming and going, via
> USB, Firewire, Bluetooth, WIMAX, and who knows what else in the future.

Yes.  That's why there's a generic facility for building arbitrary
drivers into a kernel.  That's not new either.

> The principal idea behind udev, is that we *don't* kown (we *can't*
> know) what hardware this or that machine is gonna have at some point.
> And we want the machine (and the new hardware) to "just work" when
> they are connected.

Huh?  What's that to do with udev?  You're talking at far too high a
level of abstraction.  The new hardware will "just work" if there are the
correct drivers built in.  That's as true of udev as it is of mdev as it
is of the old static /dev with mknod.

[  ]

> So, yeah, it's more complicated. The world got complicate; better get
> used to it.

You're bluffing, aren't you?  You really don't have any more idea than I
do about the technical motivation for udev, do you?

> Regards.
> -- 
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] how updating to gnome3 ?!

[Tamer Higazi]

Thank you very much Alan!
I keep the finger away of it. And continue running Gnome2. Not important
for me updating the wm to gnome3.

It's a developer machine. :-)


Tamer


Am 13.03.2012 23:10, schrieb Alan McKinnon:
> Let's deal with your biggest mistake first. You are running a stable
> system (you have ACCEPT_KEYWORDS="amd64" in make,conf) but you want to
> install gnome-3.
> 
> Now that is highly unlikely to work for a very long time yet as gnome-3
> is considered nowhere near stable enough yet to be unmasked. Portage is
> going to want to unmask vast chunks of your system to meet the
> long deep list of dependencies for gnome-3 and this will cause you
> sever amounts of pain.
> 
> Trust the folks on this list, over the years we have learned that a
> stable system (with maybe a few unmasked packages) is OK, an unstable
> system is also mostly OK (you just update lots of things often) but it
> doesn't break fantastically every other day.
> 
> A system that is half stable, half unstable DOES break fantastically
> every other day. And this is what you are trying to do.
> 
> You have many options, only two are actually realistic:
> 
> 1. Stay stable, do not use gnome-3
> 2. Switch to unstable, do a full "emerge -e world", then emerge
> gnome-3. It will go easy and probably JustWork out the box.
> 
> 
> 
> 
> On Tue, 13 Mar 2012 22:33:56 +0100
> Tamer Higazi  wrote:
> 
>> Hi Alan!
>> you were right. It is masked! I figured out that "autounmask" is not
>> in portage, because of that I believe that this might not be the only
>> package that is masked
>>
>>
>> tamer@office ~ $ emerge -pv =gnome-3.2.1
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>>
>> !!! All ebuilds that could satisfy ">=x11-wm/mutter-3.2.1" have been
>> masked. !!! One of the following masked packages is required to
>> complete your request:
>> - x11-wm/mutter-3.2.2::gentoo (masked by: ~amd64 keyword)
>> - x11-wm/mutter-3.2.1-r1::gentoo (masked by: ~amd64 keyword)
>>
>> (dependency required by "gnome-base/gnome-3.2.1" [ebuild])
>> (dependency required by "=gnome-3.2.1" [argument])
>> For more information, see the MASKED PACKAGES section in the emerge
>> man page or refer to the Gentoo Handbook.
>>
>> tamer@office ~ $
>>
>>
>>
>>
>>
>> Am 12.03.2012 21:35, schrieb Alan McKinnon:
>>> On your system "emerge gnome" wants to install gnome-2
>>>
>>> So either your tree is outdated (you must re-sync) or gnome-3 is
>>> still masked. The second option is more likely and there are two
>>> possibilities for that:
>>>
>>> You run a stable system (gnome-3 is still unstable), or
>>> you masked it for some reason.
>>>
>>> Run this and examine what output you get:
>>>
>>> emerge -pv =gnome-3.2.1
>>>
>>>
>>>
>>>
>>>
>>> On Mon, 12 Mar 2012 13:56:56 +0100
>>> Tamer Higazi  wrote:
>>>
 Hi Alan!
 I thought more or less that I have to unmask packages, or making
 any configurations to unlock the update to gnome3.

 If I run now:

 tamer@office ~ $ emerge -pav gnome

 These are the packages that would be merged, in order:

 Calculating dependencies... done!
 [ebuild   R] gnome-base/gnome-2.32.1-r1  USE="cdr cups dvdr
 ldap policykit -accessibility -mono" 0 kB

 Total: 1 package (1 reinstall), Size of downloads: 0 kB
 tamer@office ~ $


 I get one package to reinstall.


 If I run "layman -a gnome" and re-execute the command:


 I got this message:

 * If you enabled the GNOME overlay to get GNOME 3.2, please disable
  * it now, since GNOME 3.2 is already in portage and unmasked.



 How do I install gnome 3.2, that is now in portage?!



 Tamer




 Am 11.03.2012 17:43, schrieb Alan McKinnon:
> On Sun, 11 Mar 2012 17:01:41 +0100
> Tamer Higazi  wrote:
>
>> Hi people!
>> I want to upgrade gnome 2.32 to gnome 3.
>>
>> First question, is it now officially supported by the gentoo team
>> or should I keep my fingers away of it?!
>>
>> http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-3.2-upgrade.xml
>>
>> doesn't tell me a lot how to accomplish this task. Is there any
>> official documentation telling me how to doit, unmasking, flags
>> etc
>>
>>
>> for any advise I would thank you.
>
> What sort of information are you looking for?
>
> gnome-3 is marked unstable, so if you run ~x86 or ~amd64 just
>
> emerge -av gnome
>
> and deal with any breakage. This is generally how gentoo works for
> everything. What were you expecting in terms of documentation ?
>
>


>>>
>>>
>>>
>>
>>
> 
> 
> 

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

On Tue, Mar 13, 2012 at 11:03:50PM +, Neil Bothwick wrote:
> On Tue, 13 Mar 2012 22:20:19 +, Alan Mackenzie wrote:

> > > udev does a *lot* more than that, for example the persistent naming of
> > > network interfaces. More significantly, it can run programs based on
> > > device rules.

> > This is where I start getting unhappy.  Is there any need for this
> > blurring?  Having device nodes is essential to a linux system, and
> > some programs use these nodes.  Why must they be mashed together into a
> > tasteless mush?  Is there some advantage to this I haven't twigged yet?

> I agree with you on this. The initial creation of device nodes belongs in
> early startup, running arbitrary programs does not.

> > > For example, usb_modeswitch installs a udev rule to switch a 3G USB
> > > modem from CD to modem mode, without which it won't work.

> > Same question as above: why does that switching have to be done via the
> > device node system rather than via the driver.  Isn't that what drivers
> > are for?

> udev is not a device node system, it is a device manager. Requiring
> drivers to handle it gets us into the same mess as Windows, where each
> driver has to implement the same functionality itself. If a new modem is
> released with a different USB ID, but using the same driver, your way
> would require a new kernel, the current approach requires one line to be
> added to a config file.

Right!  Now this is beginning to look like a beginning of an answer to my
lack of understanding.  ;-)

This config file - is this the udev "rules"?  Or am I getting mixed up
with something else?

> > > That's fine when you plug it into a running system, but when you boot
> > > with it plugged in, it can trip over itself because the usb_modeswitch
> > > executable is in /usr/sbin.

> > Er, that's a different discussion altogether.  ;-)

> How so? It's central to the whole "when do we need /usr?" debate.

I meant we'd already had a wide ranging discussion about early /usr.

> > > You could use this to argue that /usr should be mounted before udev is
> > > started, but you could just as well use it to argue that udev should
> > > not be trying to run such rules at the boot runlevel.

> > Or that udev shouldn't have "rules".  I still don't understand the basic
> > concept driving this thing.  My HDDs don't need rules - they just need a
> > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
> > drivers built into my kernel.

> "I don't need it so no one needs it". It sounds like what you need is
> mdev, but many people want or need more from a device manager. There are
> many more and varied devices than simple hard disks.

That's not fair.  I'm convinced _I_ don't need more than mdev; I'm still
trying to get a handle on why other devices need more.

> > Am I being stupid?  Despite your example above, I still don't see what
> > udev is about, why it's necessary, or even why it's advantageous.

> What you don't see is why *you* need it, and that's fair enough. Just
> consider that it does things that others need, even if you don't.

I'm not trying to be combative.  In fact, I'm trying not to be combative.
I'm just trying to get some sort of grasp on what it is I don't yet see.
I want to understand what udev offers that mdev can't, and I'm getting
very frustrated about not being able to find the right questions to ask.

> But I still think the requirement for /usr to be mounted is a lazy, if
> understandable, solution to the way udev's operations are implemented.
> After all, the vast majority of PC Linux installations out there already
> use an initramfs.

They do, and I understand that one - it is the necessity to have a
one-size-fits-all kernel in a binary distribution.  As gentooers, we
don't suffer that constraint, therefore we don't (and shouldn't) need an
initramfs, unless we want one.

Anyhow, it's now European bed time, one hour more for me than for you, so
thanks for the discussion and let's call it quits for today.  :-)

> -- 
> Neil Bothwick

> How do I set my laser printer to stun?

How about a picture of Marilyn Monroe?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie  wrote:
> On Tue, Mar 13, 2012 at 04:38:08PM -0600, Canek Peláez Valdés wrote:
>> On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie  wrote:
>> > Hello, Neil.
>
>> > On Tue, Mar 13, 2012 at 09:33:30PM +, Neil Bothwick wrote:
>> >> On Tue, 13 Mar 2012 21:07:37 +, Alan Mackenzie wrote:
>
>> >> > But I really meant what functionality udev has that mdev lacks.  For
>> >> > example, mdev this morning recognised my USB stick being inserted, and
>> >> > created /dev/sdc for it.
>
>> >> udev does a *lot* more than that, for example the persistent naming of
>> >> network interfaces. More significantly, it can run programs based on
>> >> device rules.
>
>> > This is where I start getting unhappy.  Is there any need for this
>> > blurring?  Having device nodes is essential to a linux system, and
>> > some programs use these nodes.  Why must they be mashed together into a
>> > tasteless mush?  Is there some advantage to this I haven't twigged yet?
>
>> >> For example, usb_modeswitch installs a udev rule to switch a 3G USB
>> >> modem from CD to modem mode, without which it won't work.
>
>> > Same question as above: why does that switching have to be done via the
>> > device node system rather than via the driver.  Isn't that what drivers
>> > are for?
>
>> >> That's fine when you plug it into a running system, but when you boot
>> >> with it plugged in, it can trip over itself because the usb_modeswitch
>> >> executable is in /usr/sbin.
>
>> > Er, that's a different discussion altogether.  ;-)
>
>> >> You could use this to argue that /usr should be mounted before udev is
>> >> started, but you could just as well use it to argue that udev should not
>> >> be trying to run such rules at the boot runlevel.
>
>> > Or that udev shouldn't have "rules".  I still don't understand the basic
>> > concept driving this thing.  My HDDs don't need rules - they just need a
>> > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
>> > drivers built into my kernel.
>
>> > Am I being stupid?  Despite your example above, I still don't see what
>> > udev is about, why it's necessary, or even why it's advantageous.
>
>> IMHO, the thing that most people are missing is the fact that neither
>> udev nor Linux "got complicated". The computing world itself "got
>> complicated".
>
> Not really.  It's been getting more complicated since long before I
> starting working in it in 1980.  Nothing's changed there.
>
>> We have Linux running in the same beige machines it has been running
>> since 1991, but it also runs in TVs, tablets, cellphones, fridges,
>> cars, ebook readers, and (soon enough, I'm sure) the kitchen sink.
>> This devices behave very differently from our old and beloved beige
>> boxen.
>
> Not at the level of needing device nodes under /dev and drivers connected
> to them, they haven't.
>
>> They need to handle lots of different hardware comming and going, via
>> USB, Firewire, Bluetooth, WIMAX, and who knows what else in the future.
>
> Yes.  That's why there's a generic facility for building arbitrary
> drivers into a kernel.  That's not new either.
>
>> The principal idea behind udev, is that we *don't* kown (we *can't*
>> know) what hardware this or that machine is gonna have at some point.
>> And we want the machine (and the new hardware) to "just work" when
>> they are connected.
>
> Huh?  What's that to do with udev?  You're talking at far too high a
> level of abstraction.  The new hardware will "just work" if there are the
> correct drivers built in.  That's as true of udev as it is of mdev as it
> is of the old static /dev with mknod.

No, it is not. You are letting out the sine qua non of the matter: the
device has to be built, *and the /dev file should exists*. I hope you
are not suggesting that we put *ALL* the possible files under /dev,
because that was the idea before devfs, and it doesn't work *IN
GENERAL*.

So, you need something to handle device files on /dev, so you don't
need every possible device file for every possible piece of hardware.
But then you want to handle the same device with the same device name,
so you need some kind of database. Then for the majority of users,
they want to see *something* happen when they connect aa piece of
hardware to their computers. So you need to handle the events
associated with the connections (or discovery, for things like
Bluetooth) of the devices, and since udev is already handling the
database and the detection of connections/discovery, I agree with the
decision of leting udev to execute programs when something gets
connected. You could get that function in another program, but you are
only moving the problem, *and it can also happen very early at boot
time*, so lets udev handle it all the time.

I hope you see where I'm going. As I said before, mdev could (in
theory) do the same that udev does. But then it will be as complicated
as udev, *because it is a complicated problem* in general. And I again

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Pandu Poluan]

On Mar 14, 2012 7:10 AM, "Canek Peláez Valdés"  wrote:
>

 >8 snippage

> So, you need something to handle device files on /dev, so you don't
> need every possible device file for every possible piece of hardware.
> But then you want to handle the same device with the same device name,
> so you need some kind of database. Then for the majority of users,
> they want to see *something* happen when they connect aa piece of
> hardware to their computers. So you need to handle the events
> associated with the connections (or discovery, for things like
> Bluetooth) of the devices, and since udev is already handling the
> database and the detection of connections/discovery, I agree with the
> decision of leting udev to execute programs when something gets
> connected. You could get that function in another program, but you are
> only moving the problem, *and it can also happen very early at boot
> time*, so lets udev handle it all the time.
>
> I hope you see where I'm going. As I said before, mdev could (in
> theory) do the same that udev does. But then it will be as complicated
> as udev, *because it is a complicated problem* in general. And I again
> use my fuel injection analogy: it is not *necessary*. It is just very
> damn convenient.
>

FWIW, mdev is perfectly capable of handling device events, and (optionally)
firing an arbitrary script.

The way I see it, udev is trying to be everything regarding devices, while
mdev is purposefully limiting itself to creating proper nodes under /dev.

That (udev's wanting to do *everything*) to me seems counter against the
philosophy of Unix-y apps: do one thing, and do it well.

And that's why I don't like udev; for it to be able to do everything under
the sun, it needs stuffs.

Rgds,

[gentoo-user] suspend/hibernate and genkernel.

[William Kenworthy]

I am trying to get my system(s) ready for the new (read crappy) way
mandated by udev and am having some issues.

I usually manually compile my kernels, use tuxonice  and dont use an
initrd/initramfs.

As ToI is not available for the latest kernels, I updated openrc and
installed genkernel but then found I couldnt use in-kernel suspend to
disk - googling implies that genkernel doesnt support suspend/hibernate
but there are various kludges to get it to work.

So whats the least invasive, but workable kludge?

hibernate, pmhibernate, swsuspend, uswsuspend, ...

Are there any (up to date) docs?


BillK

Re: [gentoo-user] suspend/hibernate and genkernel.

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 9:13 PM, William Kenworthy  wrote:
> I am trying to get my system(s) ready for the new (read crappy) way
> mandated by udev and am having some issues.
>
> I usually manually compile my kernels, use tuxonice  and dont use an
> initrd/initramfs.
>
> As ToI is not available for the latest kernels, I updated openrc and
> installed genkernel but then found I couldnt use in-kernel suspend to
> disk - googling implies that genkernel doesnt support suspend/hibernate
> but there are various kludges to get it to work.
>
> So whats the least invasive, but workable kludge?
>
> hibernate, pmhibernate, swsuspend, uswsuspend, ...
>
> Are there any (up to date) docs?

Hi; not sure if it will help you, but I have been using
vanilla-sources since forever (sys-kernel/vanilla-sources-2.6.30.3,
since Aug 29, 2009), and my laptop suspends and resumes pretty much
always without any issue. I don't use genkernel: I manually configure
and compile my kernels since always, and I use dracut for my
initramfs.

Anyhow; suspend/resume should be orthogonal to an initramfs, since the
first has nothing to do with the second. I don't know about hibernate
(it's been years since I hibernated my laptop), but it should be
similar, I think.

In my laptop, GNOME does the suspend for me, but it calls pm-suspend
(I believe) from pm-utils.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] suspend/hibernate and genkernel.

[William Kenworthy]

On Wed, 2012-03-14 at 11:13 +0800, William Kenworthy wrote:
> I am trying to get my system(s) ready for the new (read crappy) way
> mandated by udev and am having some issues.
> 
> I usually manually compile my kernels, use tuxonice  and dont use an
> initrd/initramfs.
> 
> As ToI is not available for the latest kernels, I updated openrc and
> installed genkernel but then found I couldnt use in-kernel suspend to
> disk - googling implies that genkernel doesnt support suspend/hibernate
> but there are various kludges to get it to work.
> 
> So whats the least invasive, but workable kludge?
> 
> hibernate, pmhibernate, swsuspend, uswsuspend, ...
> 
> Are there any (up to date) docs?
> 
> 
> BillK
> 
> 
> 
> 

According to the docs I have found you need to patch genkernel to
run /sbin/resume - it was a longstanding argument between two now
retired devs with the result that genkernel wont (ever) support
hibernation.  I dont know from reading the bugs if it was ever fixed now
the dev who "wouldnt" has retired, or is genkernel is still broken.

Also, I have no /sbin/resume on any of my systems (some are years old
and have been successfully running ToI for most of that time) - so how
can the initramfs actually start resumimg?

Though I have a more immediate problem - hangs on hibernation and no log
messages.

BillK

Re: [gentoo-user] suspend/hibernate and genkernel.

[William Kenworthy]

On Wed, 2012-03-14 at 11:49 +0800, William Kenworthy wrote:
> On Wed, 2012-03-14 at 11:13 +0800, William Kenworthy wrote:
> > I am trying to get my system(s) ready for the new (read crappy) way
> > mandated by udev and am having some issues.
> > 
> > I usually manually compile my kernels, use tuxonice  and dont use an
> > initrd/initramfs.
> > 
> > As ToI is not available for the latest kernels, I updated openrc and
> > installed genkernel but then found I couldnt use in-kernel suspend to
> > disk - googling implies that genkernel doesnt support suspend/hibernate
> > but there are various kludges to get it to work.
> > 
> > So whats the least invasive, but workable kludge?
> > 
> > hibernate, pmhibernate, swsuspend, uswsuspend, ...
> > 
> > Are there any (up to date) docs?
> > 
> > 
> > BillK
> > 
> > 
> > 
> > 
> 
> According to the docs I have found you need to patch genkernel to
> run /sbin/resume - it was a longstanding argument between two now
> retired devs with the result that genkernel wont (ever) support
> hibernation.  I dont know from reading the bugs if it was ever fixed now
> the dev who "wouldnt" has retired, or is genkernel is still broken.
> 
> Also, I have no /sbin/resume on any of my systems (some are years old
> and have been successfully running ToI for most of that time) - so how
> can the initramfs actually start resumimg?
> 
> Though I have a more immediate problem - hangs on hibernation and no log
> messages.
> 
> BillK
> 
> 
> 
> 

Well, patching genkernel worked so its still broken as regards
suspend/resume - so I can now suspend/resume still with some errors.

Next problem is that there are error messages implying /usr might not be
mounted by the initramfs (some /usr files not found) ... is there
anything else that needs doing?  Once the system is up /usr and all
other directories are correctly mounted (most are on LVM).

Is there a way to get a detailed log of what the initrd is doing/has
done?

BillK

Re: [gentoo-user] suspend/hibernate and genkernel.

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 12:20 AM, William Kenworthy  wrote:
> On Wed, 2012-03-14 at 11:49 +0800, William Kenworthy wrote:
>> On Wed, 2012-03-14 at 11:13 +0800, William Kenworthy wrote:
>> > I am trying to get my system(s) ready for the new (read crappy) way
>> > mandated by udev and am having some issues.
>> >
>> > I usually manually compile my kernels, use tuxonice  and dont use an
>> > initrd/initramfs.
>> >
>> > As ToI is not available for the latest kernels, I updated openrc and
>> > installed genkernel but then found I couldnt use in-kernel suspend to
>> > disk - googling implies that genkernel doesnt support suspend/hibernate
>> > but there are various kludges to get it to work.
>> >
>> > So whats the least invasive, but workable kludge?
>> >
>> > hibernate, pmhibernate, swsuspend, uswsuspend, ...
>> >
>> > Are there any (up to date) docs?
>> >
>> >
>> > BillK
>> >
>> >
>> >
>> >
>>
>> According to the docs I have found you need to patch genkernel to
>> run /sbin/resume - it was a longstanding argument between two now
>> retired devs with the result that genkernel wont (ever) support
>> hibernation.  I dont know from reading the bugs if it was ever fixed now
>> the dev who "wouldnt" has retired, or is genkernel is still broken.
>>
>> Also, I have no /sbin/resume on any of my systems (some are years old
>> and have been successfully running ToI for most of that time) - so how
>> can the initramfs actually start resumimg?
>>
>> Though I have a more immediate problem - hangs on hibernation and no log
>> messages.
>>
>> BillK
>>
>>
>>
>>
>
> Well, patching genkernel worked so its still broken as regards
> suspend/resume - so I can now suspend/resume still with some errors.
>
> Next problem is that there are error messages implying /usr might not be
> mounted by the initramfs (some /usr files not found) ... is there
> anything else that needs doing?  Once the system is up /usr and all
> other directories are correctly mounted (most are on LVM).

Did you run genkernel with --lvm? Sorry, I don't use genkernel, but
dracut has several options to include arbitrary files on the
initramfs. I'm sure genkernel has something similar; why don't you try
to add the /usr missing files in the initramfs?

Good luck.

> Is there a way to get a detailed log of what the initrd is doing/has
> done?

> BillK
>
>
>
>



-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México