Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Daniel Campbell
On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
 Am 19.10.2013 17:02, schrieb Daniel Campbell:
 On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
 https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign

 Not sure if I read that just right... but since nobody is doing cgroup
 management besides systemd, in practice the cgroups implementation in
 Linux wasn't very consistent. So since systemd is doing it, their work
 is helping shape the kernel's cgroups api?

 Interesting...

 From my perspective it looks like systemd developers are trying to push
 their ideas into the kernel, almost like they intend to merge systemd
 *with* the kernel. 
 
 from what I read in the article cgroups are a mess and are cleaned up
 anyway. The only real user of cgroups at the moment is systemd.
 Others are welcome to make use of cgroups too. But in the current state
 nobody blames them for not jumping in.
No complaints here in improving something, but consider the source is
all I'm saying.

 
 If systemd is the only implementation of cgroups and
 their developers are working on cgroup support in the kernel, it spells
 calamity given their history of evangelism and zealotry.
 
 well, going over some old ml threads on fedora mailing lists all I could
 find was that Poettering and Sievers DID listen and DID make changes if
 the demand was high enough.
 
 Sure, I dislike systemd. Sure what happened with udev was a dick move.
 But their 'zealotry' is a lot less developed than the zealotry of those
 who exploded about using an 'init-thingy' in the future.

I'd say their zealotry is less loud and more persistent. Their way is
best, UNIX (and its philosophy) is outmoded, people are thinking 30
years behind where we are, etc etc etc. Those who have separate /usr and
blame systemd for pushing them to use an initramfs aren't seeing the
real problem (upstreams not putting things where they belong, FHS no
longer *really* being worked on, generally just the filesystem being
played with like a toy)


 I truly wish I understood why a single userland program and its
 developers are being given the keys to an entire subsystem of the
 kernel. 
 they aren't.
Of the people who have committed to the cgroup subsystem of the kernel,
how many are not members of the systemd, GNOME, or Red Hat projects?
I'll let that speak for itself.

 
 Their changes to udev have proven to be a headache for users,
 
 yes? which ones?
Persistent NIC naming, for starters. The former maintainer's idea to
merge with systemd (which was influenced by Mr. Poettering in the first
place) when the two are completely separate pieces of software that do
two completely different jobs, and various other troubles with udev 
175 that one can Google for and find tons of results.
 
 and the kernel is held to a much higher standard of stability and
 interoperability. In addition, the top-level developers of systemd (and
 GNOME, and the now-deprecated consolekit/polkit/udisks/etc) are employed
 by a for-profit company (Red Hat), which has a vested interest in
 shaping Linux as a platform. They and other corporations cannot be
 trusted with stuff like this...
 
 hm, Redhat is one of the companies investing the most money into linux
 kernel, userland, graphics... if you 'don't trust them' you are pretty
 much 20 years too late.
Investing money does not make them any more qualified or deserving of
making decisions. Red Hat is not the sole user of Linux. They should
consider themselves lucky that they are even able to profit from
something that's free.

You're right, though. They've been around for a while, and I've never
trusted them or any other corporate interest in *nix. There's always a
catch when dealing with a business.

 

 I'd like to see what Linus has to say about this if/when he finds out.
 He's not impressed with Sievers or Poettering. Personally I'd like to
 see them ostracized from the community and contained to their own
 distro, where they belong.

 so much about zealotry.
 
 
When a tumor is growing, if you cannot excise it, you must make its
environment so harsh that it recedes. I have strong opinions, but I
don't go around shoving my software in peoples' faces or tell people
they're wrong to not use my software. Even Linus, who's known for his
ego, wouldn't cross that line.

If I'm a zealot of anything, it's freedom of choice.



Re: [gentoo-user][SOLVED] Print PDF or PS to file ignores directory selection

2013-10-20 Thread Joseph

On 10/19/13 11:55, Joseph wrote:

After recent upgrade print PDF or PS to file ignores directory selection.

Before, the problem is caused by: x11-libs/gtk+-2.24.16
and downgrade to x11-libs/gtk+-2.24.12 solved the problem or upgrade to 
gtk+-2.24.17 worked as well.

But now, gtk+-2.24.12 is gone and gtk+-2.24.17 is causing the same problem.
What to do?

Unmasking:
gtk+-2.24.21 and gtk+-2.24.22 requires dev-libs/glib-2.36.4-r1 ~amd64 to be 
unmasked.
Once I do that other packages needs to be unmasked.  I don't want to go to far 
this road as this is my stable system.


SOLVED!
Compiling gtk+-2.24.19.ebuild from attic, solves this problem.

--
Joseph



Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Samuli Suominen

On 20/10/13 09:34, Daniel Campbell wrote:
 On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
 Am 19.10.2013 17:02, schrieb Daniel Campbell:
 On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
 https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign

 Not sure if I read that just right... but since nobody is doing cgroup
 management besides systemd, in practice the cgroups implementation in
 Linux wasn't very consistent. So since systemd is doing it, their work
 is helping shape the kernel's cgroups api?

 Interesting...

 From my perspective it looks like systemd developers are trying to push
 their ideas into the kernel, almost like they intend to merge systemd
 *with* the kernel. 
 from what I read in the article cgroups are a mess and are cleaned up
 anyway. The only real user of cgroups at the moment is systemd.
 Others are welcome to make use of cgroups too. But in the current state
 nobody blames them for not jumping in.
 No complaints here in improving something, but consider the source is
 all I'm saying.

 If systemd is the only implementation of cgroups and
 their developers are working on cgroup support in the kernel, it spells
 calamity given their history of evangelism and zealotry.
 well, going over some old ml threads on fedora mailing lists all I could
 find was that Poettering and Sievers DID listen and DID make changes if
 the demand was high enough.

 Sure, I dislike systemd. Sure what happened with udev was a dick move.
 But their 'zealotry' is a lot less developed than the zealotry of those
 who exploded about using an 'init-thingy' in the future.

 I'd say their zealotry is less loud and more persistent. Their way is
 best, UNIX (and its philosophy) is outmoded, people are thinking 30
 years behind where we are, etc etc etc. Those who have separate /usr and
 blame systemd for pushing them to use an initramfs aren't seeing the
 real problem (upstreams not putting things where they belong, FHS no
 longer *really* being worked on, generally just the filesystem being
 played with like a toy)

 I truly wish I understood why a single userland program and its
 developers are being given the keys to an entire subsystem of the
 kernel. 
 they aren't.
 Of the people who have committed to the cgroup subsystem of the kernel,
 how many are not members of the systemd, GNOME, or Red Hat projects?
 I'll let that speak for itself.

 Their changes to udev have proven to be a headache for users,
 yes? which ones?
 Persistent NIC naming, for starters. The former maintainer's idea to
 merge with systemd (which was influenced by Mr. Poettering in the first
 place) when the two are completely separate pieces of software that do
 two completely different jobs, and various other troubles with udev 
 175 that one can Google for and find tons of results.

I can't find anything that would be true. Can you point out some?
A lot of FUD[1] and outright lies coming from people, who, for example,
don't like systemd.

[1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

I know for a fact udev-208 is a full replacement for udev-171 in terms
that both work on same kernels, same libcs, and so forth. That's why
171 is no longer in Portage, because it's completely useless from users
(and developers) point of view.

Adjusting some configs and enabling some kernel options that have been
around for a long time is just part of normal maintenance process,
that's what we have admins for.



Re: [gentoo-user] Re: New mobo change

2013-10-20 Thread Volker Armin Hemmann
Am 20.10.2013 07:39, schrieb Dale:
 Volker Armin Hemmann wrote:
 Am 18.10.2013 05:54, schrieb Dale:
 Walter Dnes wrote:
 On Thu, Oct 17, 2013 at 04:40:52PM -0500, Dale wrote
 Well, this is interesting.  I swapped out the mobo.  First, it has the
 UEFI BIOS thing.  That was interesting for sure.  I'm not complaining
 but not used to it and wasn't expecting it either.  Second, it works
 except for the third part.  Third thing is, no mouse worky.  It works in
 the BIOS but not in the OS.  I have gpm set to start and it doesn't work
 in a console or a GUI.  I tried everything I can think of, no mouse.  I
 had to swap again.  I'm back to my old mobo.  Here is the kicker.  I
 plugged the USB mouse into the old mobo, it works just fine.  It works
 in KDE, console etc.  It just works.  The only kernel change I made was
 for the chipset on the mobo.  I left the USB stuff alone.
   I've run into this in the past.  The USB 2.0 drivers are *SUPPOSED* to
 provide support for lowspeed USB 1.X devices, like mice and keyboards.
 But it doesn't always work that way.  There is direct USB 1.X driver
 support in the kernel.  In make menuconfig, got to...

 Device Drivers  ---
 [*] USB support  ---
   OHCI HCD support
   UHCI HCD (most Intel and VIA) support

   I don't see any mention in your message whether the motherboard cpu is
 AMD or Intel.  Generally, build UHCI for Intel+VIA, OHCI for AMD.  Try
 it out and see what happens.

 Mine is AMD based.  I have this right now but tried every other version
 I could find too.

 *   xHCI HCD (USB 3.0) support
 *   EHCI HCD (USB 2.0) support
 *   OHCI HCD support
 [*] Generic OHCI driver for a platform device
 there you go. platform driver. Take that one out.
 Make the rest modules.
 Amd board? kill uhci while you are at it.
 Change made.  I plan to give this a shot again before to long.  I got a
 few thigns to try out now.  I updated sysrecue and Knoppix.  I also put
 them both on CD/DVD to just in case it is a USB issue.  At least I can
 test some things and hopefully find one that works. 

 Thanks for all the help.  I'll post back what happens.  If it doesn't
 work next time or fails from sysrescue/Knoppix, I plan to RMA the board
 for another one.  If it doesn't work with either of those, then I
 suspect hardware issues again. 
no, the mouse works in bios - so it is not a hardware issue, but in
worst case a bios setting issue.




Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Daniel Campbell
On 10/20/2013 02:37 AM, Samuli Suominen wrote:
 
 On 20/10/13 09:34, Daniel Campbell wrote:
 On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
 Am 19.10.2013 17:02, schrieb Daniel Campbell:
 On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
 https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign

 Not sure if I read that just right... but since nobody is doing cgroup
 management besides systemd, in practice the cgroups implementation in
 Linux wasn't very consistent. So since systemd is doing it, their work
 is helping shape the kernel's cgroups api?

 Interesting...

 From my perspective it looks like systemd developers are trying to push
 their ideas into the kernel, almost like they intend to merge systemd
 *with* the kernel. 
 from what I read in the article cgroups are a mess and are cleaned up
 anyway. The only real user of cgroups at the moment is systemd.
 Others are welcome to make use of cgroups too. But in the current state
 nobody blames them for not jumping in.
 No complaints here in improving something, but consider the source is
 all I'm saying.

 If systemd is the only implementation of cgroups and
 their developers are working on cgroup support in the kernel, it spells
 calamity given their history of evangelism and zealotry.
 well, going over some old ml threads on fedora mailing lists all I could
 find was that Poettering and Sievers DID listen and DID make changes if
 the demand was high enough.

 Sure, I dislike systemd. Sure what happened with udev was a dick move.
 But their 'zealotry' is a lot less developed than the zealotry of those
 who exploded about using an 'init-thingy' in the future.

 I'd say their zealotry is less loud and more persistent. Their way is
 best, UNIX (and its philosophy) is outmoded, people are thinking 30
 years behind where we are, etc etc etc. Those who have separate /usr and
 blame systemd for pushing them to use an initramfs aren't seeing the
 real problem (upstreams not putting things where they belong, FHS no
 longer *really* being worked on, generally just the filesystem being
 played with like a toy)

 I truly wish I understood why a single userland program and its
 developers are being given the keys to an entire subsystem of the
 kernel. 
 they aren't.
 Of the people who have committed to the cgroup subsystem of the kernel,
 how many are not members of the systemd, GNOME, or Red Hat projects?
 I'll let that speak for itself.

 Their changes to udev have proven to be a headache for users,
 yes? which ones?
 Persistent NIC naming, for starters. The former maintainer's idea to
 merge with systemd (which was influenced by Mr. Poettering in the first
 place) when the two are completely separate pieces of software that do
 two completely different jobs, and various other troubles with udev 
 175 that one can Google for and find tons of results.
 
 I can't find anything that would be true. Can you point out some?
 A lot of FUD[1] and outright lies coming from people, who, for example,
 don't like systemd.
 
 [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
 
 I know for a fact udev-208 is a full replacement for udev-171 in terms
 that both work on same kernels, same libcs, and so forth. That's why
 171 is no longer in Portage, because it's completely useless from users
 (and developers) point of view.
 
 Adjusting some configs and enabling some kernel options that have been
 around for a long time is just part of normal maintenance process,
 that's what we have admins for.
 

Do you know the design consequences of opt-in versus opt-out? I'll keep
this short: When evolving a codebase, new behavior for core parts of the
system should not be pushed or forced on users. If you must, keep the
old behavior around as a default and allow users to try the new thing by
explicitly opting in. The new naming in whichever udev started the mess
did it the exact opposite (and wrong) way.

While editing and updating configs is a normal part of system
maintenance, turning a system on its head and screwing it out of network
accessibility until the new default is reversed (by means of a `kernel`
line in GRUB, requiring a reboot) is straight-up wrong design.
Conversely, keeping old behavior, even for systems that *do* have
multiple NICs, will at least be functional (for one of the NICs, anyway)
until they set the option to get their expected behavior sorted out.
Multi-NIC systems are less common than single-NIC systems, and that
alone should've been enough motivation to leave old behavior as default,
with the new behavior a simple config switch away.

The way the new behavior was introduced may have led users of single-NIC
systems to believe that the old way was broken, when as demonstrated
through past use, works *just fine* for single-NIC machines. It was
*multi-NIC* use that wasn't as predictive and needed the fix, not
*single*. It's basically using poor design/defaults decisions to smear
existing 

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Volker Armin Hemmann
Am 20.10.2013 08:34, schrieb Daniel Campbell:
 hm, Redhat is one of the companies investing the most money into linux
 kernel, userland, graphics... if you 'don't trust them' you are pretty
 much 20 years too late.
 Investing money does not make them any more qualified or deserving of
 making decisions. Red Hat is not the sole user of Linux. They should
 consider themselves lucky that they are even able to profit from
 something that's free.

 You're right, though. They've been around for a while, and I've never
 trusted them or any other corporate interest in *nix. There's always a
 catch when dealing with a business.


'have been around for a while' - replace that with 'are financing more
core developers than anybody else'.



[gentoo-user] OT: Tablets

2013-10-20 Thread Silvio Siefke
Hello,


use someone a tablet with Gentoo or alternatives? I want me buy a tablets,
but im not sure i can familiar use Android. Has someone a tablet with
gentoo or other Distri running?

Which tablet i can buy, advice?


Thanks  Greetings
Silvio



[gentoo-user] Re: [O/T] RAID help - now won't boot

2013-10-20 Thread Mick
On Wednesday 16 Oct 2013 21:14:38 Nicolas Sebrecht wrote:
 On Wed, Oct 16, 2013 at 08:10:40PM +0200, Nicolas Sebrecht wrote:
  On Tue, Oct 15, 2013 at 10:42:18PM +0100, Mick wrote:
   mdadm --create --auto=mdp --verbose /dev/md_d0 --level=mirror
   --raid-devices=2 /dev/sda /dev/sdb
   
   which is thereafter partitioned with fdisk.  This is the one I have
   used in the past.
   
   Which one is preferable, or what are the pros  cons of each?
  
  For a basic RAID1, the best is to keep it as simple as possible. So
  mirroring while disk looks better. It will also keep MBR/GPT synced.
 
 s/while/the whole/
 
  I tend to make manual partitions that I mirror but this is because I
  usually require to do more complex setups (e.g. mixing mirror types), or
  because I need to have the setup more flexible.

OK, I spent some time to experiment in a VM.  Two small un-partitioned virtual 
disks which I used to create /dev/md0 as RAID 1 using sysrescuecd.  Then I 
used fdisk to create a MSDOS partition table on /dev/md0, followed by 4 
partitions on /dev/md0:
==
~$ fdisk -l

Disk /dev/sda: 10.5 GB, 10522460160 bytes
255 heads, 63 sectors/track, 1279 cylinders, total 20551680 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: 0x

Disk /dev/sda doesn't contain a valid partition table

Disk /dev/sdb: 10.5 GB, 10522460160 bytes
255 heads, 63 sectors/track, 1279 cylinders, total 20551680 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: 0x

Disk /dev/sdb doesn't contain a valid partition table

Disk /dev/md0: 10.5 GB, 10521337856 bytes
2 heads, 4 sectors/track, 2568686 cylinders, total 20549488 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: 0x000c3148

Device Boot  Start End  Blocks   Id  System
/dev/md0p1   *2048  718847  358400   83  Linux
/dev/md0p2  718848 3790847 1536000   82  Linux swap / Solaris
/dev/md0p3 379084818470911 7340032   83  Linux
/dev/md0p41847091220549487 1039288   83  Linux
==

So, no partition tables on /dev/sda or /dev/sdb drives and of course no 
partitions at all.  The partitions were created on the /dev/md0 block device.

I then rebooted with a Ubuntu server CD and installed the OS in the 
above filesystem.  It seemed to have recognised the RAID1 array as /dev/md127, 
instead of /dev/md0.

Trying to install GRUB on /dev/sda, or /dev/sdb, or /dev/md127p1 failed.  The 
only way to install GRUB and complete the Ubuntu server OS installation was to 
install it on /dev/md127, which it accepted.  However, on rebooting it failed 
with:  FATAL: No boot medium found! System halted.


Rebooting with sysrescueCD and selecting to scan and boot any linux OS it 
could find, it picks up the RAID1 installation and it boots into it without 
any problem.  This is what I can see now:
==
~$ lsblk 
NAME  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda 8:00   9.8G  0 disk  
└─md0   9:00   9.8G  0 raid1 
  ├─md0p1 259:00   350M  0 md/boot
  ├─md0p2 259:10   1.5G  0 md[SWAP]
  ├─md0p3 259:20 7G  0 md/
  └─md0p4 259:30  1015M  0 md/home
sdb 8:16   0   9.8G  0 disk  
└─md0   9:00   9.8G  0 raid1 
  ├─md0p1 259:00   350M  0 md/boot
  ├─md0p2 259:10   1.5G  0 md[SWAP]
  ├─md0p3 259:20 7G  0 md/
  └─md0p4 259:30  1015M  0 md/home
==


==
~$ df -h -T
Filesystem Type   Size  Used Avail Use% Mounted on
/dev/md0p3 ext4   6.9G  1.2G  5.4G  18% /
udev   tmpfs   10M  8.0K   10M   1% /dev
none   tmpfs  146M  352K  146M   1% /run
none   tmpfs  5.0M 0  5.0M   0% /run/lock
none   tmpfs  730M 0  730M   0% /run/shm
/dev/md0p1 ext2   329M   27M  285M   9% /boot
/dev/md0p4 ext4   999M   18M  931M   2% /home
==


==
~$ cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] 
[raid10] 
md0 : active raid1 sda[0] sdb[1]
  10274744 blocks super 1.2 [2/2] [UU]
  
unused devices: none
==


==
~$ sudo blkid 

/dev/sr0: LABEL=sysrcd-3.8.0 TYPE=iso9660 
/dev/sda: UUID=59195572-751a-3bd9-7771-6e5411b032c8 
UUID_SUB=3acd1b2c-1c95-7c07-a8b2-8aa1b2a0a169 LABEL=sysresccd:0 
TYPE=linux_raid_member 
/dev/sdb: UUID=59195572-751a-3bd9-7771-6e5411b032c8 UUID_SUB=c63e97ba-42cb-
c4f8-550d-f1effae33d3f LABEL=sysresccd:0 TYPE=linux_raid_member 
/dev/md0p1: UUID=d9dbe2bc-0453-46e4-a5b0-779e55246004 TYPE=ext2 
/dev/md0p2: 

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Samuli Suominen

On 20/10/13 12:24, Daniel Campbell wrote:
 On 10/20/2013 02:37 AM, Samuli Suominen wrote:
 On 20/10/13 09:34, Daniel Campbell wrote:
 On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
 Am 19.10.2013 17:02, schrieb Daniel Campbell:
 On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
 https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign

 Not sure if I read that just right... but since nobody is doing cgroup
 management besides systemd, in practice the cgroups implementation in
 Linux wasn't very consistent. So since systemd is doing it, their work
 is helping shape the kernel's cgroups api?

 Interesting...

 From my perspective it looks like systemd developers are trying to push
 their ideas into the kernel, almost like they intend to merge systemd
 *with* the kernel. 
 from what I read in the article cgroups are a mess and are cleaned up
 anyway. The only real user of cgroups at the moment is systemd.
 Others are welcome to make use of cgroups too. But in the current state
 nobody blames them for not jumping in.
 No complaints here in improving something, but consider the source is
 all I'm saying.

 If systemd is the only implementation of cgroups and
 their developers are working on cgroup support in the kernel, it spells
 calamity given their history of evangelism and zealotry.
 well, going over some old ml threads on fedora mailing lists all I could
 find was that Poettering and Sievers DID listen and DID make changes if
 the demand was high enough.

 Sure, I dislike systemd. Sure what happened with udev was a dick move.
 But their 'zealotry' is a lot less developed than the zealotry of those
 who exploded about using an 'init-thingy' in the future.

 I'd say their zealotry is less loud and more persistent. Their way is
 best, UNIX (and its philosophy) is outmoded, people are thinking 30
 years behind where we are, etc etc etc. Those who have separate /usr and
 blame systemd for pushing them to use an initramfs aren't seeing the
 real problem (upstreams not putting things where they belong, FHS no
 longer *really* being worked on, generally just the filesystem being
 played with like a toy)

 I truly wish I understood why a single userland program and its
 developers are being given the keys to an entire subsystem of the
 kernel. 
 they aren't.
 Of the people who have committed to the cgroup subsystem of the kernel,
 how many are not members of the systemd, GNOME, or Red Hat projects?
 I'll let that speak for itself.

 Their changes to udev have proven to be a headache for users,
 yes? which ones?
 Persistent NIC naming, for starters. The former maintainer's idea to
 merge with systemd (which was influenced by Mr. Poettering in the first
 place) when the two are completely separate pieces of software that do
 two completely different jobs, and various other troubles with udev 
 175 that one can Google for and find tons of results.
 I can't find anything that would be true. Can you point out some?
 A lot of FUD[1] and outright lies coming from people, who, for example,
 don't like systemd.

 [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

 I know for a fact udev-208 is a full replacement for udev-171 in terms
 that both work on same kernels, same libcs, and so forth. That's why
 171 is no longer in Portage, because it's completely useless from users
 (and developers) point of view.

 Adjusting some configs and enabling some kernel options that have been
 around for a long time is just part of normal maintenance process,
 that's what we have admins for.

 Do you know the design consequences of opt-in versus opt-out? I'll keep
 this short: When evolving a codebase, new behavior for core parts of the
 system should not be pushed or forced on users. If you must, keep the
 old behavior around as a default and allow users to try the new thing by
 explicitly opting in. The new naming in whichever udev started the mess
 did it the exact opposite (and wrong) way.


It's not forced upon you. You received a news item that had instructions
on howto assign names you want, like lan0, internet1, wireless3, and so
forth.
And it also described howto turn off udev from completely renaming the
devices, to keep kernel assigned names.
What they did was they dropped the *broken* feature called 'persistent
rule_generator' which never worked correctly, and in
race conditions still flipped eth0 - eth1 around -- that was a
*security* flaw that *needed* to go.
It would have gone even without providing the alternative of providing
biosdevname -like new name optionality to the users.
Kernel and kernel drivers are designed in a way it's not supported to
flip in-place kernel names and udev tried to workaround that.

https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html


 While editing and updating configs is a normal part of system
 maintenance, turning a system on its head and screwing it out of network
 accessibility until the new default 

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Daniel Campbell
On 10/20/2013 04:55 AM, Samuli Suominen wrote:
 
 On 20/10/13 12:24, Daniel Campbell wrote:
 On 10/20/2013 02:37 AM, Samuli Suominen wrote:
 On 20/10/13 09:34, Daniel Campbell wrote:
 On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
 Am 19.10.2013 17:02, schrieb Daniel Campbell:
 On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
 https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign

 Not sure if I read that just right... but since nobody is doing cgroup
 management besides systemd, in practice the cgroups implementation in
 Linux wasn't very consistent. So since systemd is doing it, their work
 is helping shape the kernel's cgroups api?

 Interesting...

 From my perspective it looks like systemd developers are trying to push
 their ideas into the kernel, almost like they intend to merge systemd
 *with* the kernel. 
 from what I read in the article cgroups are a mess and are cleaned up
 anyway. The only real user of cgroups at the moment is systemd.
 Others are welcome to make use of cgroups too. But in the current state
 nobody blames them for not jumping in.
 No complaints here in improving something, but consider the source is
 all I'm saying.

 If systemd is the only implementation of cgroups and
 their developers are working on cgroup support in the kernel, it spells
 calamity given their history of evangelism and zealotry.
 well, going over some old ml threads on fedora mailing lists all I could
 find was that Poettering and Sievers DID listen and DID make changes if
 the demand was high enough.

 Sure, I dislike systemd. Sure what happened with udev was a dick move.
 But their 'zealotry' is a lot less developed than the zealotry of those
 who exploded about using an 'init-thingy' in the future.

 I'd say their zealotry is less loud and more persistent. Their way is
 best, UNIX (and its philosophy) is outmoded, people are thinking 30
 years behind where we are, etc etc etc. Those who have separate /usr and
 blame systemd for pushing them to use an initramfs aren't seeing the
 real problem (upstreams not putting things where they belong, FHS no
 longer *really* being worked on, generally just the filesystem being
 played with like a toy)

 I truly wish I understood why a single userland program and its
 developers are being given the keys to an entire subsystem of the
 kernel. 
 they aren't.
 Of the people who have committed to the cgroup subsystem of the kernel,
 how many are not members of the systemd, GNOME, or Red Hat projects?
 I'll let that speak for itself.

 Their changes to udev have proven to be a headache for users,
 yes? which ones?
 Persistent NIC naming, for starters. The former maintainer's idea to
 merge with systemd (which was influenced by Mr. Poettering in the first
 place) when the two are completely separate pieces of software that do
 two completely different jobs, and various other troubles with udev 
 175 that one can Google for and find tons of results.
 I can't find anything that would be true. Can you point out some?
 A lot of FUD[1] and outright lies coming from people, who, for example,
 don't like systemd.

 [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

 I know for a fact udev-208 is a full replacement for udev-171 in terms
 that both work on same kernels, same libcs, and so forth. That's why
 171 is no longer in Portage, because it's completely useless from users
 (and developers) point of view.

 Adjusting some configs and enabling some kernel options that have been
 around for a long time is just part of normal maintenance process,
 that's what we have admins for.

 Do you know the design consequences of opt-in versus opt-out? I'll keep
 this short: When evolving a codebase, new behavior for core parts of the
 system should not be pushed or forced on users. If you must, keep the
 old behavior around as a default and allow users to try the new thing by
 explicitly opting in. The new naming in whichever udev started the mess
 did it the exact opposite (and wrong) way.
 
 
 It's not forced upon you. You received a news item that had instructions
 on howto assign names you want, like lan0, internet1, wireless3, and so
 forth.
 And it also described howto turn off udev from completely renaming the
 devices, to keep kernel assigned names.
 What they did was they dropped the *broken* feature called 'persistent
 rule_generator' which never worked correctly, and in
 race conditions still flipped eth0 - eth1 around -- that was a
 *security* flaw that *needed* to go.
 It would have gone even without providing the alternative of providing
 biosdevname -like new name optionality to the users.
 Kernel and kernel drivers are designed in a way it's not supported to
 flip in-place kernel names and udev tried to workaround that.
 
 https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html
 

Like I mentioned in a prior e-mail, the change didn't affect me when it
was pushed, and doesn't affect me 

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Daniel Campbell
On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
 Am 20.10.2013 08:34, schrieb Daniel Campbell:
 hm, Redhat is one of the companies investing the most money into linux
 kernel, userland, graphics... if you 'don't trust them' you are pretty
 much 20 years too late.
 Investing money does not make them any more qualified or deserving of
 making decisions. Red Hat is not the sole user of Linux. They should
 consider themselves lucky that they are even able to profit from
 something that's free.

 You're right, though. They've been around for a while, and I've never
 trusted them or any other corporate interest in *nix. There's always a
 catch when dealing with a business.

 
 'have been around for a while' - replace that with 'are financing more
 core developers than anybody else'.
 
That's less reason to trust, not more. That's like citing the popularity
of something as proof of its quality, when oftentimes it's the exact
opposite that's true.

So they spend a lot of money hiring developers. The more important
question is what is their agenda? What do they tell those developers to
*make*? You don't hire people without a business plan in mind.



Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Volker Armin Hemmann
Am 20.10.2013 12:52, schrieb Daniel Campbell:
 On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
 Am 20.10.2013 08:34, schrieb Daniel Campbell:
 hm, Redhat is one of the companies investing the most money into linux
 kernel, userland, graphics... if you 'don't trust them' you are pretty
 much 20 years too late.
 Investing money does not make them any more qualified or deserving of
 making decisions. Red Hat is not the sole user of Linux. They should
 consider themselves lucky that they are even able to profit from
 something that's free.

 You're right, though. They've been around for a while, and I've never
 trusted them or any other corporate interest in *nix. There's always a
 catch when dealing with a business.

 'have been around for a while' - replace that with 'are financing more
 core developers than anybody else'.

 That's less reason to trust, not more. That's like citing the popularity
 of something as proof of its quality, when oftentimes it's the exact
 opposite that's true.

 So they spend a lot of money hiring developers. The more important
 question is what is their agenda? What do they tell those developers to
 *make*? You don't hire people without a business plan in mind.


without Redhat, there would be no linux. gnu software would be massively
lacking and X would be without drivers.

So calm down.



Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Daniel Campbell
On 10/20/2013 06:02 AM, Volker Armin Hemmann wrote:
 Am 20.10.2013 12:52, schrieb Daniel Campbell:
 On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
 Am 20.10.2013 08:34, schrieb Daniel Campbell:
 hm, Redhat is one of the companies investing the most money into linux
 kernel, userland, graphics... if you 'don't trust them' you are pretty
 much 20 years too late.
 Investing money does not make them any more qualified or deserving of
 making decisions. Red Hat is not the sole user of Linux. They should
 consider themselves lucky that they are even able to profit from
 something that's free.

 You're right, though. They've been around for a while, and I've never
 trusted them or any other corporate interest in *nix. There's always a
 catch when dealing with a business.

 'have been around for a while' - replace that with 'are financing more
 core developers than anybody else'.

 That's less reason to trust, not more. That's like citing the popularity
 of something as proof of its quality, when oftentimes it's the exact
 opposite that's true.

 So they spend a lot of money hiring developers. The more important
 question is what is their agenda? What do they tell those developers to
 *make*? You don't hire people without a business plan in mind.


 without Redhat, there would be no linux. gnu software would be massively
 lacking and X would be without drivers.
 
 So calm down.
 
Linux was created and released in 1991, built with GNU tools. Red Hat
didn't come along until 1993. Linux and GNU would both still be here;
their quality without Red Hat involvement is speculative at best.

I maintain that motives matter more than money and that they (motives)
should continually be audited, especially when receiving contributions
from a company. They may already be; I don't know.

Re: drivers, do you expect me to believe Red Hat is responsible for
every X11 driver out there? How many of this list?[1] What of radeon and
nouveau? nvidia's own driver? xf86-input-wacom (and linuxwacom)[2]? I'm
sure Red Hat has contributed plenty to X11, but your statement is
flat-out false.

[1]: http://www.usinglinux.org/x11-drivers/
[2]: http://sourceforge.net/apps/mediawiki/linuxwacom/



Re: [gentoo-user] Re: [O/T] RAID help - now won't boot

2013-10-20 Thread Michael Hampicke
Am 20.10.2013 11:54, schrieb Mick:
 Any ideas why the Ubuntu installation won't boot?
 

My guess would be, you cannot boot, because if you install grub in /dev/md0.

Upon boot the bios cannot find stage1 of the bootloader, which normally
lies in the MBR (which also houses the partition table).

Is a setup as you wish - sda and sdb as raid1, and partitions only on
md0 - bootable in general?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Samuli Suominen

On 20/10/13 13:47, Daniel Campbell wrote:
 On 10/20/2013 04:55 AM, Samuli Suominen wrote:
 On 20/10/13 12:24, Daniel Campbell wrote:
 On 10/20/2013 02:37 AM, Samuli Suominen wrote:
 On 20/10/13 09:34, Daniel Campbell wrote:
 On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
 Am 19.10.2013 17:02, schrieb Daniel Campbell:
 On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
 https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign

 Not sure if I read that just right... but since nobody is doing cgroup
 management besides systemd, in practice the cgroups implementation in
 Linux wasn't very consistent. So since systemd is doing it, their work
 is helping shape the kernel's cgroups api?

 Interesting...

 From my perspective it looks like systemd developers are trying to push
 their ideas into the kernel, almost like they intend to merge systemd
 *with* the kernel. 
 from what I read in the article cgroups are a mess and are cleaned up
 anyway. The only real user of cgroups at the moment is systemd.
 Others are welcome to make use of cgroups too. But in the current state
 nobody blames them for not jumping in.
 No complaints here in improving something, but consider the source is
 all I'm saying.

 If systemd is the only implementation of cgroups and
 their developers are working on cgroup support in the kernel, it spells
 calamity given their history of evangelism and zealotry.
 well, going over some old ml threads on fedora mailing lists all I could
 find was that Poettering and Sievers DID listen and DID make changes if
 the demand was high enough.

 Sure, I dislike systemd. Sure what happened with udev was a dick move.
 But their 'zealotry' is a lot less developed than the zealotry of those
 who exploded about using an 'init-thingy' in the future.

 I'd say their zealotry is less loud and more persistent. Their way is
 best, UNIX (and its philosophy) is outmoded, people are thinking 30
 years behind where we are, etc etc etc. Those who have separate /usr and
 blame systemd for pushing them to use an initramfs aren't seeing the
 real problem (upstreams not putting things where they belong, FHS no
 longer *really* being worked on, generally just the filesystem being
 played with like a toy)

 I truly wish I understood why a single userland program and its
 developers are being given the keys to an entire subsystem of the
 kernel. 
 they aren't.
 Of the people who have committed to the cgroup subsystem of the kernel,
 how many are not members of the systemd, GNOME, or Red Hat projects?
 I'll let that speak for itself.

 Their changes to udev have proven to be a headache for users,
 yes? which ones?
 Persistent NIC naming, for starters. The former maintainer's idea to
 merge with systemd (which was influenced by Mr. Poettering in the first
 place) when the two are completely separate pieces of software that do
 two completely different jobs, and various other troubles with udev 
 175 that one can Google for and find tons of results.
 I can't find anything that would be true. Can you point out some?
 A lot of FUD[1] and outright lies coming from people, who, for example,
 don't like systemd.

 [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

 I know for a fact udev-208 is a full replacement for udev-171 in terms
 that both work on same kernels, same libcs, and so forth. That's why
 171 is no longer in Portage, because it's completely useless from users
 (and developers) point of view.

 Adjusting some configs and enabling some kernel options that have been
 around for a long time is just part of normal maintenance process,
 that's what we have admins for.

 Do you know the design consequences of opt-in versus opt-out? I'll keep
 this short: When evolving a codebase, new behavior for core parts of the
 system should not be pushed or forced on users. If you must, keep the
 old behavior around as a default and allow users to try the new thing by
 explicitly opting in. The new naming in whichever udev started the mess
 did it the exact opposite (and wrong) way.

 It's not forced upon you. You received a news item that had instructions
 on howto assign names you want, like lan0, internet1, wireless3, and so
 forth.
 And it also described howto turn off udev from completely renaming the
 devices, to keep kernel assigned names.
 What they did was they dropped the *broken* feature called 'persistent
 rule_generator' which never worked correctly, and in
 race conditions still flipped eth0 - eth1 around -- that was a
 *security* flaw that *needed* to go.
 It would have gone even without providing the alternative of providing
 biosdevname -like new name optionality to the users.
 Kernel and kernel drivers are designed in a way it's not supported to
 flip in-place kernel names and udev tried to workaround that.

 https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html

 Like I mentioned in a prior e-mail, the change didn't affect me when 

Re: [gentoo-user] Re: [O/T] RAID help - now won't boot

2013-10-20 Thread Mick
On Sunday 20 Oct 2013 13:57:34 Michael Hampicke wrote:
 Am 20.10.2013 11:54, schrieb Mick:
  Any ideas why the Ubuntu installation won't boot?
 
 My guess would be, you cannot boot, because if you install grub in
 /dev/md0.
 
 Upon boot the bios cannot find stage1 of the bootloader, which normally
 lies in the MBR (which also houses the partition table).

I see ... so installing the MBR code in the /dev/md0 block device is further 
down the disk than where BIOS is looking for it and that's why it errors out?

Meanwhile, there is no MBR or partition table on /dev/sda or /dev/sdb for BIOS 
to jump to.  Hmm ...

It seems to me then that I *have* to create normal partitions on /dev/sda  
/dev/sdb, or I would need a different boot drive.  Is there another way to 
overcome this problem. 


 Is a setup as you wish - sda and sdb as raid1, and partitions only on
 md0 - bootable in general?

Yes, in this case.  It makes easy to set a faulty drive in failed state and 
remove it from RAID in a single step, rather than the alternative which would 
involve removing multiple /dev/mdX, one for each partition.  I could I guess 
install LVM on top of RAID, but this adds complexity for a functionality 
(increasing LV sizes) which will not be used in this implementation.

Any suggestions welcome.
-- 
Regards,
Mick


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


Re: [gentoo-user] Re: [O/T] RAID help - now won't boot

2013-10-20 Thread Michael Hampicke
Am 20.10.2013 15:13, schrieb Mick:
 On Sunday 20 Oct 2013 13:57:34 Michael Hampicke wrote:
 Am 20.10.2013 11:54, schrieb Mick:
 Any ideas why the Ubuntu installation won't boot?

 My guess would be, you cannot boot, because if you install grub in
 /dev/md0.

 Upon boot the bios cannot find stage1 of the bootloader, which normally
 lies in the MBR (which also houses the partition table).
 
 I see ... so installing the MBR code in the /dev/md0 block device is further 
 down the disk than where BIOS is looking for it and that's why it errors out?
 

That would be my guess. Maybe someone more knowledgeable on how mdadm
writes stuff on the disk can jump in and provide additional info. But
I'm pretty sure, if you install grub in md0, it's not in that place on
the disk where the bios is actually looking for.

 
 It seems to me then that I *have* to create normal partitions on /dev/sda  
 /dev/sdb, or I would need a different boot drive.  Is there another way to 
 overcome this problem. 

Maybe create two mds. md1 (sda1, sdb1) is a small boot partition which
contains stage2+, the kernel and the initramfs. And md2 (sda2, sdb2)
which acts as another block device with partition table, etc...
In this setup you could install grub in the mbr of sda and sdb
(grub-install /dev/sda...)

A quick google on this subject returned no usable results. But I am off
now until tomorrow.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Tanstaafl

On 2013-10-20 9:02 AM, Samuli Suominen ssuomi...@gentoo.org wrote:

On 20/10/13 13:47, Daniel Campbell wrote:

Like I mentioned in a prior e-mail, the change didn't affect me when it
was pushed, and doesn't affect me now. I did recently have to reinstall
Gentoo, however (note, going from testing to stable isn't fun ;p), and
noticed it when I found Gentoo ships with systemd-udev instead of eudev.



Yep, no plans on changing the default sys-fs/udev to anything else, no
reason to.


To be clear - you are saying that the new default init system for a new 
gentoo install is systemd?


When did this happen? I thought that OpenRC was still the default?


Perhaps the next time I need to install Gentoo, I'll find a way to get
eudev on there before even the first proper boot and avoid the problem
altogether.



It's true that sys-fs/eudev restored the *broken* rule_generator from
old sys-fs/udev, you can get it by USE=rule-generator.
But it's lot saner to keep using sys-fs/udev and just write custom rules
to rename interfaces based on MACs to like lan*, internet*
so all in all, currently, using sys-fs/eudev doesn't make sense unless
you are experimenting/developing for it.


The problem with this is, what happens if (or maybe *when*?) the systemd 
maintainers make a change that then breaks udev for anything but systemd?




Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Samuli Suominen

On 20/10/13 17:01, Tanstaafl wrote:
 On 2013-10-20 9:02 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 20/10/13 13:47, Daniel Campbell wrote:
 Like I mentioned in a prior e-mail, the change didn't affect me when it
 was pushed, and doesn't affect me now. I did recently have to reinstall
 Gentoo, however (note, going from testing to stable isn't fun ;p), and
 noticed it when I found Gentoo ships with systemd-udev instead of
 eudev.

 Yep, no plans on changing the default sys-fs/udev to anything else, no
 reason to.

 To be clear - you are saying that the new default init system for a
 new gentoo install is systemd?

No, I'm saying the default /dev manager in Gentoo has been sys-fs/udev
and will be sys-fs/udev


 When did this happen? I thought that OpenRC was still the default?

It is.


 Perhaps the next time I need to install Gentoo, I'll find a way to get
 eudev on there before even the first proper boot and avoid the problem
 altogether.

 It's true that sys-fs/eudev restored the *broken* rule_generator from
 old sys-fs/udev, you can get it by USE=rule-generator.
 But it's lot saner to keep using sys-fs/udev and just write custom rules
 to rename interfaces based on MACs to like lan*, internet*
 so all in all, currently, using sys-fs/eudev doesn't make sense unless
 you are experimenting/developing for it.

 The problem with this is, what happens if (or maybe *when*?) the
 systemd maintainers make a change that then breaks udev for anything
 but systemd?


That's a bridge we will cross when there is a bridge to be crossed, but
from top of my head:
We will maintain a minimal patchset that reverts the offending code.

As in, that's nothing to be worried about before it happens.



Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Samuli Suominen

On 20/10/13 17:01, Tanstaafl wrote:

 It's true that sys-fs/eudev restored the *broken* rule_generator from
 old sys-fs/udev, you can get it by USE=rule-generator.
 But it's lot saner to keep using sys-fs/udev and just write custom rules
 to rename interfaces based on MACs to like lan*, internet*
 so all in all, currently, using sys-fs/eudev doesn't make sense unless
 you are experimenting/developing for it.

 The problem with this is, what happens if (or maybe *when*?) the
 systemd maintainers make a change that then breaks udev for anything
 but systemd?


To continue my previous reply. That has already happened once. That's
why we implemented /dev tmpfiles.d support for OpenRC 0.12, that's why
=sys-apps/kmod-15
is now requiring =sys-apps/openrc-0.12.
So it's case-by-case basis.



[gentoo-user] Gentoo on ARM Tablets

2013-10-20 Thread James
Silvio Siefke siefke_listen at web.de writes:


 use someone a tablet with Gentoo or alternatives? I want me buy a tablets,
 but im not sure i can familiar use Android. Has someone a tablet with
 gentoo or other Distri running?

Tablets mostly use ARM processors... You have to do some research. I've
merely collected up some links that may be of interest to you.

Look here to see what vendors are developing together for Arm-Linux.

http://www.linaro.org

http://www.archos.com/

http://www.openaos.org/~kevin/archos_angstrom_docs/index.html

http://www.samygo.tv/ 

You could had a touch screen to this system:
http://www.ti.com/tool/omap5432-evm?DCMP=omap-5432evm-130521HQS=omap-5432evm-b-sw

Or this kit

http://www.phytec.com/products/system-on-modules/phycore/omap5430/#kits

The A15 is the smoking new Arm chip. Most cell phones and tablets use
and ARM SOC (system on a chip).

http://www.chromebook-linux.com/2011/11/gentoo-is-ready-for-chromebook.html

Post back what you do or find that is new.
Good hunting!
hth,
James




Re: [gentoo-user] Re: [O/T] RAID help - now won't boot

2013-10-20 Thread joost
Michael Hampicke m...@hadt.biz wrote:
Am 20.10.2013 15:13, schrieb Mick:
 On Sunday 20 Oct 2013 13:57:34 Michael Hampicke wrote:
 Am 20.10.2013 11:54, schrieb Mick:
 Any ideas why the Ubuntu installation won't boot?

 My guess would be, you cannot boot, because if you install grub in
 /dev/md0.

 Upon boot the bios cannot find stage1 of the bootloader, which
normally
 lies in the MBR (which also houses the partition table).
 
 I see ... so installing the MBR code in the /dev/md0 block device is
further 
 down the disk than where BIOS is looking for it and that's why it
errors out?
 

That would be my guess. Maybe someone more knowledgeable on how mdadm
writes stuff on the disk can jump in and provide additional info. But
I'm pretty sure, if you install grub in md0, it's not in that place on
the disk where the bios is actually looking for.

 
 It seems to me then that I *have* to create normal partitions on
/dev/sda  
 /dev/sdb, or I would need a different boot drive.  Is there another
way to 
 overcome this problem. 

Maybe create two mds. md1 (sda1, sdb1) is a small boot partition which
contains stage2+, the kernel and the initramfs. And md2 (sda2, sdb2)
which acts as another block device with partition table, etc...
In this setup you could install grub in the mbr of sda and sdb
(grub-install /dev/sda...)

A quick google on this subject returned no usable results. But I am off
now until tomorrow.

I would suggest trying it by usong the older metadata format.
Check the man pages, but I thinl it would be --metadata=0.90 (or similar) 
during creation.
That might put the metadata at the end, rather then at the front. (Or it's the 
other way round and new metadata does it at the end.)

--
Joost
Ps. I have never tried it this way (full disk raid for boot device) using linux 
software raid.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Tanstaafl

On 2013-10-20 6:52 AM, Daniel Campbell li...@sporkbox.us wrote:

So they spend a lot of money hiring developers. The more important
question is what is their agenda? What do they tell those developers to
*make*? You don't hire people without a business plan in mind.


Well, once I understood their (Redhat's) motivation, which was/is 
enterprise/cloud/vm oriented (which is why they were so concerned about 
parallelism for startup, etc) - I dropped the conspiracy theory aspect 
of it all... it actually does make sense in that context.


And as long as Linus is at the helm of kernel development, I'm not too 
worried about the systemd guys doing too much damage there - I just 
can't see him letting it happen.


If I were the type to worry just for the sake of worrying, I'd be 
wondering what may happen down the road, if Linus were to suddenly lose 
interest in kernel development (for whatever reason) and walk away from 
it - who/what would take over the reins? But that would be pointless...




[gentoo-user] grub2: need the output of vbeinfo to be able to read the output of vbeinfo

2013-10-20 Thread meino . cramer
Hi,

I just migrated to grub2 which works fine thanks to the good 
Gentoo docs! :)

But...

I need to increase the resolution of the boot screen to
see what is going on there.
The docs say, that with the command vbeinfo from the grub
console I can see the valid modes of my grpahics card.
Now...the current resolution of the grub console compbined
with the unfortunate sorting of the output of vbeinfo I am
currently only able to read the last entries of this realy
long list.
Therefore...I need the whole output of vbeinfo to set the
console resulotion that way, so I will be able to read the
output of vbeinfo

deadlock?

Nice things like 'less' or such are not available

What can I do?

Thank you very much in advance for any help!

Best regards,
mcc






Re: [gentoo-user] grub2: need the output of vbeinfo to be able to read the output of vbeinfo

2013-10-20 Thread Daniel Pielmeier
meino.cra...@gmx.de schrieb am 20.10.2013 19:17:
 Hi,
 
 I just migrated to grub2 which works fine thanks to the good 
 Gentoo docs! :)
 
 But...
 
 I need to increase the resolution of the boot screen to
 see what is going on there.
 The docs say, that with the command vbeinfo from the grub
 console I can see the valid modes of my grpahics card.
 Now...the current resolution of the grub console compbined
 with the unfortunate sorting of the output of vbeinfo I am
 currently only able to read the last entries of this realy
 long list.
 Therefore...I need the whole output of vbeinfo to set the
 console resulotion that way, so I will be able to read the
 output of vbeinfo
 
 deadlock?
 
 Nice things like 'less' or such are not available
 
 What can I do?


Try this:
set pager=1

http://www.gnu.org/software/grub/manual/grub.html#pager

-- 
Regards
Daniel Pielmeier



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] grub2: need the output of vbeinfo to be able to read the output of vbeinfo

2013-10-20 Thread meino . cramer
Daniel Pielmeier bil...@gentoo.org [13-10-20 19:32]:
 meino.cra...@gmx.de schrieb am 20.10.2013 19:17:
  Hi,
  
  I just migrated to grub2 which works fine thanks to the good 
  Gentoo docs! :)
  
  But...
  
  I need to increase the resolution of the boot screen to
  see what is going on there.
  The docs say, that with the command vbeinfo from the grub
  console I can see the valid modes of my grpahics card.
  Now...the current resolution of the grub console compbined
  with the unfortunate sorting of the output of vbeinfo I am
  currently only able to read the last entries of this realy
  long list.
  Therefore...I need the whole output of vbeinfo to set the
  console resulotion that way, so I will be able to read the
  output of vbeinfo
  
  deadlock?
  
  Nice things like 'less' or such are not available
  
  What can I do?
 
 
 Try this:
 set pager=1
 
 http://www.gnu.org/software/grub/manual/grub.html#pager
 
 -- 
 Regards
 Daniel Pielmeier
 

Hi Daniel!

LIFESAVER! Thanks a lot!
Didnt saw this...

Best regards,
mcc






[gentoo-user] openoffice-bin-4.0.1 - no menu text on top

2013-10-20 Thread Joseph

I have been hit by a bug that I don't know how to go about it.
First my login manager slim is not showing any username / password text upon 
log in; now Openoffice-bin has no menu text on top.

How to go about this bug?
I have four systems two x86 and two amd64 
one x86 and one amd64 are effected by this bug, two other system working normally :-/


--
Joseph



Re: [gentoo-user] Re: Console won't un-blank

2013-10-20 Thread Frank Steinmetzger
On Fri, Oct 18, 2013 at 10:40:32PM +0200, Holger Hoffstaette wrote:
 On Thu, 17 Oct 2013 21:02:13 -0400, Michael J. Barillier wrote:
 
  If I leave my laptop unattended (at a console, not X) and the screen
  blanks, pressing a key won't un-blank the terminal.  As a test, I ssh'ed
  into the laptop and ran:
  
# setterm -blank poke /dev/tty$N
 
 Very likely kernel or DRM subsystem. I have an T60 Thinkpad with old ATI
 graphics and since kernel ~3.7.1 (approx.) it won't unblank any more, just
 as you described. I tested some time ago with an early 3.10.x and it still
 did not work. Everything works correctly on a second machine without KMS
 (plain VESA) and a third system with newer Radeon card, so I always
 attributed it to the stone age hardware and bitrot. There were quite a lot
 of changes to the Radeon and DRM machinery over the last few kernel
 releases.

I have here a Samsung P30 (first Centrino generation) with a Radeon 9200
and radeon driver in KMS mode, Kernel 3.10.11. Unblanking works normal.
I [br]arely use that machine, only keep it up to date from time to time
in case I may need it in lieu of my normal laptop. So its setup is
fairly default stage3.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

Friends may come and go, but enemies accumulate.


signature.asc
Description: Digital signature


Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top

2013-10-20 Thread J. Roeleveld
Joseph syscon...@gmail.com wrote:
I have been hit by a bug that I don't know how to go about it.
First my login manager slim is not showing any username / password
text upon log in; now Openoffice-bin has no menu text on top.

How to go about this bug?
I have four systems two x86 and two amd64 
one x86 and one amd64 are effected by this bug, two other system
working normally :-/

-- 
Joseph

Sounds like a font issue.
You could try 'emerge -vae small package showing this problem'

I wouldn't try this with openoffice right away. 

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top

2013-10-20 Thread Frank Steinmetzger
On Sun, Oct 20, 2013 at 11:45:26AM -0600, Joseph wrote:

 I have been hit by a bug that I don't know how to go about it.
 First my login manager slim is not showing any username / password text 
 upon log in; now Openoffice-bin has no menu text on top.
 
 How to go about this bug?
 I have four systems two x86 and two amd64 
 one x86 and one amd64 are effected by this bug, two other system working 
 normally :-/

Is there any helpful output on the console if you start LO from there?
What about revdep-rebuild?
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

Automation is man’s attempt of shaping work so that women can do it.


signature.asc
Description: Digital signature


Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top

2013-10-20 Thread Joseph

On 10/20/13 20:09, J. Roeleveld wrote:

  Joseph syscon...@gmail.com wrote:

I have been hit by a bug that I don't know how to go about it.
First my login manager slim is not showing any username / password text upon l
og in; now Openoffice-bin has no menu text on top.
How to go about this bug?
I have four systems two x86 and two amd64
one x86 and one amd64 are effected by this bug, two other system working normall
y :-/

  Sounds like a font issue.
  You could try 'emerge -vae small package showing this problem'
  I wouldn't try this with openoffice right away.
  --
  Joost
  --
  Sent from my Android device with K-9 Mail. Please excuse my brevity.


Do you mean:
emerge -vae app-office/openoffice-bin
or 
emerge -vae slim


In both cases I get 306 packages needs rebuilding, this will be a log way to 
try to fix this problem :-/

--
Joseph



Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top

2013-10-20 Thread Joseph

On 10/20/13 20:09, J. Roeleveld wrote:

  Joseph syscon...@gmail.com wrote:

I have been hit by a bug that I don't know how to go about it.
First my login manager slim is not showing any username / password text upon l
og in; now Openoffice-bin has no menu text on top.
How to go about this bug?
I have four systems two x86 and two amd64
one x86 and one amd64 are effected by this bug, two other system working normall
y :-/

  Sounds like a font issue.
  You could try 'emerge -vae small package showing this problem'
  I wouldn't try this with openoffice right away.
  --
  Joost
  --
  Sent from my Android device with K-9 Mail. Please excuse my brevity.


In addition I have tried fc-list and try to compare font on the same systems, 
they are all the same.

system called atom - not effected
system called syscon2 - effected by not showing text the menu.

All fonts that are in atom are present in syscon2 so I don't think this is 
problem with the fonts.

--
Joseph



Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top

2013-10-20 Thread Joseph

On 10/20/13 20:42, Frank Steinmetzger wrote:

On Sun, Oct 20, 2013 at 11:45:26AM -0600, Joseph wrote:


I have been hit by a bug that I don't know how to go about it.
First my login manager slim is not showing any username / password text upon 
log in; now Openoffice-bin has no menu text on top.

How to go about this bug?
I have four systems two x86 and two amd64
one x86 and one amd64 are effected by this bug, two other system working 
normally :-/


Is there any helpful output on the console if you start LO from there?
What about revdep-rebuild?
--
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

Automation is man’s attempt of shaping work so that women can do it.


What is LO ?
I've tried to start the oowriter from the command line, there are no errors 
reported :-/


--
Joseph



[gentoo-user] Re: New mobo change

2013-10-20 Thread Dale
Dale wrote:
 Howdy,

 I ordered the new mobo as much as I needed to wait.  The mobo is the
 same brand but a different chipset and a couple other things are
 different.  I have already built a kernel for those changes.  I plan to
 put everything on the old mobo on the new mobo.  That includes the CPU. 
 I'm pretty sure this will not be needed but want to ask to be sure.  Do
 I need to do a emerge -e world or should it just work like it is? 
 Since the CPU is going to be the exact same CPU, I'm thinking it is not
 needed.  I do have march=native set in make.conf. 

 Thoughts?  Thanks.

 Dale

 :-)  :-) 

 P. S.  I think this is the most I have ever spent on a mobo.  $120.00
 with shipping.



Here is another update.  I currently have the new mobo in the puter. 
The only port that works is the 3.0 ports.  None of the other ports
work.  I mean nothing.  When I plug my cell phone in, it doesn't even
get power much less see it.  When I plug the mouse in, the light doesn't
come on.  It's just plain dead.  While in the BIOS, the mouse works in
any USB port.  So, I got the USB 3 ports working but something is
killing the other ports.  Nothing I plug into the USB 1/2 ports works
outside of BIOS. 

I still think this is a kernel issue.  I just don't know which part.  I
have tried switching stuff on/off and such but nothing works.  I'm
thinking about putting my sledge hammer to work.  :/ 

What do I need to post so someone can compare this to something that
works?  I'll post the whole kernel config if needed/requested.  If you
just need certain parts, just let me know what to grep for. 

Thanks.  I'll be beating on it until I hear some more ideas from y'all. 

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!




Re: [gentoo-user] Re: New mobo change

2013-10-20 Thread Edward M

On 10/20/2013 2:19 PM, Dale wrote:

I still think this is a kernel issue.  I just don't know which part.  I
have tried switching stuff on/off and such but nothing works.  I'm
thinking about putting my sledge hammer to work.  :/



   Hello,


Have you tried booting into a linux distro that offers a 
recent  live cd to see
if that distro  can properly detect and load the needed 
drivers?  And If they work, then you can find out which drivers were 
loaded.




Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top

2013-10-20 Thread Joseph

On 10/20/13 20:42, Frank Steinmetzger wrote:

On Sun, Oct 20, 2013 at 11:45:26AM -0600, Joseph wrote:


I have been hit by a bug that I don't know how to go about it.
First my login manager slim is not showing any username / password text upon 
log in; now Openoffice-bin has no menu text on top.

How to go about this bug?
I have four systems two x86 and two amd64
one x86 and one amd64 are effected by this bug, two other system working 
normally :-/


Is there any helpful output on the console if you start LO from there?
What about revdep-rebuild?
--
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

Automation is man’s attempt of shaping work so that women can do it.



Solved.
This is a problem with xorg-server-1.14.3
Downgrading to x11-base/xorg-server-1.13.4-r1 solved the problem.

--
Joseph



Re: [gentoo-user] Re: New mobo change

2013-10-20 Thread Dale
Edward M wrote:
 On 10/20/2013 2:19 PM, Dale wrote:
 I still think this is a kernel issue.  I just don't know which part.  I
 have tried switching stuff on/off and such but nothing works.  I'm
 thinking about putting my sledge hammer to work.  :/


Hello,


 Have you tried booting into a linux distro that offers a
 recent  live cd to see
 if that distro  can properly detect and load the needed
 drivers?  And If they work, then you can find out which drivers were
 loaded.



I did once before and it failed to boot with a error.  I didn't write it
down.  I may try that later on tho.  I have since updated sysrescue. 
While it is not like I want it, the mouse does move when I poke it.  lol 

Thanks for the reminder tho.  I'll post results when I try it. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!




Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Mark David Dumlao
On Oct 20, 2013 10:44 PM, Tanstaafl tansta...@libertytrek.org wrote:

 On 2013-10-20 6:52 AM, Daniel Campbell li...@sporkbox.us wrote:

 So they spend a lot of money hiring developers. The more important
 question is what is their agenda? What do they tell those developers to
 *make*? You don't hire people without a business plan in mind.


 Well, once I understood their (Redhat's) motivation, which was/is
enterprise/cloud/vm oriented (which is why they were so concerned about
parallelism for startup, etc) - I dropped the conspiracy theory aspect of
it all... it actually does make sense in that context.

 And as long as Linus is at the helm of kernel development, I'm not too
worried about the systemd guys doing too much damage there - I just can't
see him letting it happen.

 If I were the type to worry just for the sake of worrying, I'd be
wondering what may happen down the road, if Linus were to suddenly lose
interest in kernel development (for whatever reason) and walk away from it
- who/what would take over the reins? But that would be pointless...


Linus isnt actually actively developing the kernel nowadays. Mostly he just
merges commits from his trusted lieutenants in charge of various
subsystems. The notion of Linus as being at the helm is mostly just a
convenient fiction that corporate culture (and by extension, the media) -
which is used to strong leadership - uses to make sense of open source
development.

That's partly why he finds it funny when people take his flames too
seriously, as if they were Word of God.

If he took were cut down by a sith lord, most likely morton's tree would
seamlessly be the new upstream.


Re: [gentoo-user] Re: New mobo change

2013-10-20 Thread William Kenworthy
On 21/10/13 07:52, Dale wrote:
 Edward M wrote:
 On 10/20/2013 2:19 PM, Dale wrote:
 I still think this is a kernel issue.  I just don't know which part.  I
 have tried switching stuff on/off and such but nothing works.  I'm
 thinking about putting my sledge hammer to work.  :/

Hello,


 Have you tried booting into a linux distro that offers a
 recent  live cd to see
 if that distro  can properly detect and load the needed
 drivers?  And If they work, then you can find out which drivers were
 loaded.


 I did once before and it failed to boot with a error.  I didn't write it
 down.  I may try that later on tho.  I have since updated sysrescue. 
 While it is not like I want it, the mouse does move when I poke it.  lol 

 Thanks for the reminder tho.  I'll post results when I try it. 

 Dale

 :-)  :-) 


sysrescuecd is gentoo based ... try ubuntu or linuxmint to provide a
better spread of capabilities.

Have you checked the bios for usb parameters (i.e., defaults to off, or
wrong mode?) - whats on offer in the bios may not be the same as when
you exit it.

Billk




Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Walter Dnes
On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote

 That's a bridge we will cross when there is a bridge to be crossed, but
 from top of my head:
 We will maintain a minimal patchset that reverts the offending code.
 
 As in, that's nothing to be worried about before it happens.

  That's not always possible, e.g. GNOME 3.8.

-- 
Walter Dnes waltd...@waltdnes.org
I don't run desktop environments; I run useful applications



Re: [gentoo-user] Re: New mobo change

2013-10-20 Thread Dale
William Kenworthy wrote:
 On 21/10/13 07:52, Dale wrote:
 Edward M wrote:
 On 10/20/2013 2:19 PM, Dale wrote:
 I still think this is a kernel issue.  I just don't know which part.  I
 have tried switching stuff on/off and such but nothing works.  I'm
 thinking about putting my sledge hammer to work.  :/
Hello,


 Have you tried booting into a linux distro that offers a
 recent  live cd to see
 if that distro  can properly detect and load the needed
 drivers?  And If they work, then you can find out which drivers were
 loaded.


 I did once before and it failed to boot with a error.  I didn't write it
 down.  I may try that later on tho.  I have since updated sysrescue. 
 While it is not like I want it, the mouse does move when I poke it.  lol 

 Thanks for the reminder tho.  I'll post results when I try it. 

 Dale

 :-)  :-) 

 sysrescuecd is gentoo based ... try ubuntu or linuxmint to provide a
 better spread of capabilities.

 Have you checked the bios for usb parameters (i.e., defaults to off, or
 wrong mode?) - whats on offer in the bios may not be the same as when
 you exit it.

 Billk




I rebooted and the newest sysrescue still wouldn't boot up.  It says it
can't find /sysrcd.dat which I think is caused because it can't use the
USB port that the sysrescue stick is plugged into.  So, I booted Knoppix
instead from DVD.  Success.  I got a list of drivers from lspci and plan
to research them and see if I am missing something.  If not, I may just
start with a fresh config and see if that helps. 

At least the mobo is working tho.  That's a good thing.  It's a start at
least. 

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!




Re: [gentoo-user] Re: New mobo change

2013-10-20 Thread William Kenworthy
On 21/10/13 11:09, Dale wrote:
 William Kenworthy wrote:
 On 21/10/13 07:52, Dale wrote:
 Edward M wrote:
 On 10/20/2013 2:19 PM, Dale wrote:
 I still think this is a kernel issue.  I just don't know which part.  I
 have tried switching stuff on/off and such but nothing works.  I'm
 thinking about putting my sledge hammer to work.  :/
Hello,


 Have you tried booting into a linux distro that offers a
 recent  live cd to see
 if that distro  can properly detect and load the needed
 drivers?  And If they work, then you can find out which drivers were
 loaded.


 I did once before and it failed to boot with a error.  I didn't write it
 down.  I may try that later on tho.  I have since updated sysrescue. 
 While it is not like I want it, the mouse does move when I poke it.  lol 

 Thanks for the reminder tho.  I'll post results when I try it. 

 Dale

 :-)  :-) 

 sysrescuecd is gentoo based ... try ubuntu or linuxmint to provide a
 better spread of capabilities.

 Have you checked the bios for usb parameters (i.e., defaults to off, or
 wrong mode?) - whats on offer in the bios may not be the same as when
 you exit it.

 Billk



 I rebooted and the newest sysrescue still wouldn't boot up.  It says it
 can't find /sysrcd.dat which I think is caused because it can't use the
 USB port that the sysrescue stick is plugged into.  So, I booted Knoppix
 instead from DVD.  Success.  I got a list of drivers from lspci and plan
 to research them and see if I am missing something.  If not, I may just
 start with a fresh config and see if that helps. 

 At least the mobo is working tho.  That's a good thing.  It's a start at
 least. 

 Dale

 :-)  :-)


Ive found that with gentoo/sysrescuecd before - the other distros do a
better job of detection - I have a dell system here that wont work on
SRD for instance.  But after using ubuntu to find what was missing, its
running gentoo fine.

Billk





Re: [gentoo-user] Re: New mobo change

2013-10-20 Thread Dale
William Kenworthy wrote:
 On 21/10/13 11:09, Dale wrote:

 I rebooted and the newest sysrescue still wouldn't boot up.  It says it
 can't find /sysrcd.dat which I think is caused because it can't use the
 USB port that the sysrescue stick is plugged into.  So, I booted Knoppix
 instead from DVD.  Success.  I got a list of drivers from lspci and plan
 to research them and see if I am missing something.  If not, I may just
 start with a fresh config and see if that helps. 

 At least the mobo is working tho.  That's a good thing.  It's a start at
 least. 

 Dale

 :-)  :-)

 Ive found that with gentoo/sysrescuecd before - the other distros do a
 better job of detection - I have a dell system here that wont work on
 SRD for instance.  But after using ubuntu to find what was missing, its
 running gentoo fine.

 Billk





Well, I have enabled everything I could find from the Knoppix test and
it still does not work.  I'm likely going to just try to config a kernel
from scratch later on.  That or go back to the one from my old mobo and
just change the chipset.  See if that works. 

Thanks for the help.  I'll post updates when I can.  I may be pretty
busy for a few days.  Could be a bit. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!




Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top

2013-10-20 Thread J. Roeleveld
Joseph syscon...@gmail.com wrote:
On 10/20/13 20:42, Frank Steinmetzger wrote:
On Sun, Oct 20, 2013 at 11:45:26AM -0600, Joseph wrote:

 I have been hit by a bug that I don't know how to go about it.
 First my login manager slim is not showing any username / password
text upon log in; now Openoffice-bin has no menu text on top.

 How to go about this bug?
 I have four systems two x86 and two amd64
 one x86 and one amd64 are effected by this bug, two other system
working normally :-/

Is there any helpful output on the console if you start LO from there?
What about revdep-rebuild?
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook
service.

Automation is man’s attempt of shaping work so that women can do it.


Solved.
This is a problem with xorg-server-1.14.3
Downgrading to x11-base/xorg-server-1.13.4-r1 solved the problem.

-- 
Joseph

Glad to hear it.
I had similar issues in the past. Those were solved by a full rebuild.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Re: New mobo change

2013-10-20 Thread Dale
Dale wrote:
 William Kenworthy wrote:
 On 21/10/13 11:09, Dale wrote:
 I rebooted and the newest sysrescue still wouldn't boot up.  It says it
 can't find /sysrcd.dat which I think is caused because it can't use the
 USB port that the sysrescue stick is plugged into.  So, I booted Knoppix
 instead from DVD.  Success.  I got a list of drivers from lspci and plan
 to research them and see if I am missing something.  If not, I may just
 start with a fresh config and see if that helps. 

 At least the mobo is working tho.  That's a good thing.  It's a start at
 least. 

 Dale

 :-)  :-)

 Ive found that with gentoo/sysrescuecd before - the other distros do a
 better job of detection - I have a dell system here that wont work on
 SRD for instance.  But after using ubuntu to find what was missing, its
 running gentoo fine.

 Billk




 Well, I have enabled everything I could find from the Knoppix test and
 it still does not work.  I'm likely going to just try to config a kernel
 from scratch later on.  That or go back to the one from my old mobo and
 just change the chipset.  See if that works. 

 Thanks for the help.  I'll post updates when I can.  I may be pretty
 busy for a few days.  Could be a bit. 

 Dale

 :-)  :-) 


Update.  I did some googling and found out that I have to add 
iommu=pt to the kernel command line.  When I do that, it works fine. 
It seems that this mobo doesn't play well with 64 bit Linux.  Some even
said it appears to be a windoze only mobo.  So, my question is this.  I
just spent $120 on a mobo that it appears it doesn't work up to its full
value.  Should I swap this mobo for another board, brand to most likely,
and be done with it?  I like my last Gigabyte mobo but if this one isn't
going to support what I use, maybe I need to rethink this selection. 

What are the thoughts of some mobo gurus?   I bought it from newegg so
return shouldn't be to big of a issue if I get this started pretty
soon.  I'll check for BIOS updates but the posts I found said it didn't
help a bit.

Thoughts?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!




Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

2013-10-20 Thread Daniel Campbell
On 10/20/2013 09:34 PM, Walter Dnes wrote:
 On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote
 
 That's a bridge we will cross when there is a bridge to be crossed, but
 from top of my head:
 We will maintain a minimal patchset that reverts the offending code.

 As in, that's nothing to be worried about before it happens.
 
   That's not always possible, e.g. GNOME 3.8.
 
I think that's an exception to the rule. I mean, upstream deliberately
chose to depend on systemd/logind and whatnot. In such a situation
there's literally no way to fix it without a fork, and I doubt Gentoo as
an organization is interested in that.



Re: [gentoo-user] Re: [O/T] RAID help - now won't boot

2013-10-20 Thread Mick
On Sunday 20 Oct 2013 15:31:12 jo...@antarean.org wrote:

 I would suggest trying it by usong the older metadata format.
 Check the man pages, but I thinl it would be --metadata=0.90 (or similar)
 during creation. That might put the metadata at the end, rather then at
 the front. (Or it's the other way round and new metadata does it at the
 end.)
 
 --
 Joost
 Ps. I have never tried it this way (full disk raid for boot device) using
 linux software raid.

Ha!  Yes, this made a difference, thanks!  With metadata 0.90 I can see the 
same partitions I set up on /dev/md0, also on /dev/sda and /dev/sdb.  The only 
problem now is that the Ubuntu server CD wants to format /dev/sda2 as swap and 
fails at that stage.  :-/

Not sure how to by-pass this.

I may also try metadata=1.0 to see if this makes a difference, which also 
positions the RAID data superblock at the end of the device:

Sub-Version  Superblock Position on Device
---  -
0.9  At the end of the device
1.0  At the end of the device
1.1  At the beginning of the device
1.2  4K from the beginning of the device

-- 
Regards,
Mick


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


Re: [gentoo-user] Re: New mobo change

2013-10-20 Thread J. Roeleveld
Dale rdalek1...@gmail.com wrote:
Dale wrote:
 William Kenworthy wrote:
 On 21/10/13 11:09, Dale wrote:
 I rebooted and the newest sysrescue still wouldn't boot up.  It
says it
 can't find /sysrcd.dat which I think is caused because it can't use
the
 USB port that the sysrescue stick is plugged into.  So, I booted
Knoppix
 instead from DVD.  Success.  I got a list of drivers from lspci and
plan
 to research them and see if I am missing something.  If not, I may
just
 start with a fresh config and see if that helps. 

 At least the mobo is working tho.  That's a good thing.  It's a
start at
 least. 

 Dale

 :-)  :-)

 Ive found that with gentoo/sysrescuecd before - the other distros do
a
 better job of detection - I have a dell system here that wont work
on
 SRD for instance.  But after using ubuntu to find what was missing,
its
 running gentoo fine.

 Billk




 Well, I have enabled everything I could find from the Knoppix test
and
 it still does not work.  I'm likely going to just try to config a
kernel
 from scratch later on.  That or go back to the one from my old mobo
and
 just change the chipset.  See if that works. 

 Thanks for the help.  I'll post updates when I can.  I may be pretty
 busy for a few days.  Could be a bit. 

 Dale

 :-)  :-) 


Update.  I did some googling and found out that I have to add 
iommu=pt to the kernel command line.  When I do that, it works fine. 
It seems that this mobo doesn't play well with 64 bit Linux.  Some even
said it appears to be a windoze only mobo.  So, my question is this.  I
just spent $120 on a mobo that it appears it doesn't work up to its
full
value.  Should I swap this mobo for another board, brand to most
likely,
and be done with it?  I like my last Gigabyte mobo but if this one
isn't
going to support what I use, maybe I need to rethink this selection. 

What are the thoughts of some mobo gurus?   I bought it from newegg so
return shouldn't be to big of a issue if I get this started pretty
soon.  I'll check for BIOS updates but the posts I found said it didn't
help a bit.

Thoughts?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood
or how you interpreted my words!

Of the general consensus is that it is a ms windows only board. Then I would 
return it.

I have had good experiences with ASUS and Tyan boards. The latter are more 
expensive, but Tyan does officially support Linux. (The Linux driver section is 
as easy to find as the ms windows driver section.)

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.