Re: [gentoo-amd64] unsubscribe
Jüri-Kaur Schultz wrote: unsubscribe Send a mail to [EMAIL PROTECTED] to find out how to do this. -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] unsubscribe
Jüri-Kaur Schultz wrote: unsubscribe No. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] getaddrinfo(): Bad value for ai_flags
Hi,
whois (from net-misc/whois-4.7.19) gives me:
whois gentoo.org
getaddrinfo(whois.publicinterestregistry.net): Bad value for ai_flags
==
ldd `which whois`
libidn.so.11 = /usr/lib/libidn.so.11 (0x2af95ba6f000)
libc.so.6 = /lib/libc.so.6 (0x2af95bba1000)
/lib64/ld-linux-x86-64.so.2 (0x2af95b951000)
==
qfile libidn.so.11
net-dns/libidn (/usr/lib64/libidn.so.11)
app-emulation/emul-linux-x86-baselibs (/emul/linux/x86/usr/lib/libidn.so.11)
==
qfile libc.so.6
sys-libs/glibc (/lib64/libc.so.6)
sys-libs/glibc (/lib32/libc.so.6)
==
qfile ld-linux-x86-64.so.2
sys-libs/glibc (/lib64/ld-linux-x86-64.so.2)
==
So I did emerge -1 glibc emul-linux-x86-baselibs libidn whois but it
didn't solve the problem. Any ideas?
Additional info:
strace whois gentoo.org
execve(/usr/bin/whois, [whois, gentoo.org], [/* 44 vars */]) = 0
brk(0) = 0x50b000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b07d5ae5000
uname({sys=Linux, node=ilievnet.com, ...}) = 0
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=110932, ...}) = 0
mmap(NULL, 110932, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b07d5ae6000
close(3)= 0
open(/usr/lib/libidn.so.11, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\200/\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=205168, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b07d5b02000
mmap(NULL, 1251088, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2b07d5be6000
mprotect(0x2b07d5c16000, 1048576, PROT_NONE) = 0
mmap(0x2b07d5d16000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0x2b07d5d16000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0 \322\1\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1342384, ...}) = 0
mmap(NULL, 2359368, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2b07d5d18000
mprotect(0x2b07d5e4f000, 1048576, PROT_NONE) = 0
mmap(0x2b07d5f4f000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x137000) = 0x2b07d5f4f000
mmap(0x2b07d5f54000, 16456, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b07d5f54000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b07d5f59000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b07d5f5a000
arch_prctl(ARCH_SET_FS, 0x2b07d5f59ae0) = 0
mprotect(0x2b07d5f4f000, 12288, PROT_READ) = 0
mprotect(0x2b07d5be4000, 4096, PROT_READ) = 0
munmap(0x2b07d5ae6000, 110932) = 0
brk(0) = 0x50b000
brk(0x52c000) = 0x52c000
open(/usr/lib64/locale/locale-archive, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/usr/share/locale/locale.alias, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2586, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b07d5ae6000
read(3, # Locale name alias data base.\n#..., 4096) = 2586
read(3, , 4096) = 0
close(3)= 0
munmap(0x2b07d5ae6000, 4096)= 0
open(/usr/lib64/locale/bg_BG.UTF-8/LC_IDENTIFICATION, O_RDONLY) = -1
ENOENT (No such file or directory)
open(/usr/lib64/locale/bg_BG.utf8/LC_IDENTIFICATION, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=351, ...}) = 0
mmap(NULL, 351, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b07d5ae6000
close(3)= 0
open(/usr/lib64/gconv/gconv-modules.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=25406, ...}) = 0
mmap(NULL, 25406, PROT_READ, MAP_SHARED, 3, 0) = 0x2b07d5ae7000
close(3)= 0
open(/usr/lib64/locale/bg_BG.UTF-8/LC_MEASUREMENT, O_RDONLY) = -1
ENOENT (No such file or directory)
open(/usr/lib64/locale/bg_BG.utf8/LC_MEASUREMENT, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
mmap(NULL, 23, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b07d5aee000
close(3)= 0
open(/usr/lib64/locale/bg_BG.UTF-8/LC_TELEPHONE, O_RDONLY) = -1 ENOENT
(No such file or directory)
open(/usr/lib64/locale/bg_BG.utf8/LC_TELEPHONE, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=62, ...}) = 0
mmap(NULL, 62, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b07d5aef000
close(3)= 0
open(/usr/lib64/locale/bg_BG.UTF-8/LC_ADDRESS, O_RDONLY) = -1 ENOENT
(No such file or directory)
open(/usr/lib64/locale/bg_BG.utf8/LC_ADDRESS, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=163, ...}) = 0
mmap(NULL, 163, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b07d5af
close(3)= 0
open(/usr/lib64/locale/bg_BG.UTF-8/LC_NAME,
[gentoo-amd64] Re: problems emerging tclx
Michael George [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 27 Dec 2006 20:57:43 -0500: You are right, I didn't search the gentoo bugs, but I shall in the future. I didn't know that Google wouldn't grab them... It's not something one would expect, certainly, given that Google knows how to index and can often supply from cache as HTML everything from PDF to MS Word and Excel files. However, each bugzilla installation, certainly the big ones used by the various distributions and all the big projects, tends to be somewhat customized, so Google would need to customize it's bots for each one, and apparently the individual user segments interested in each one are small enough Google hasn't found it worth the trouble to do and maintain. So it's an understandable mis-assumption. Still, think about it. How many bugzilla results have you ever come across in your various Linux info searches? I've certainly not come across that many, if any. It's just that it doesn't occur to folks, since they are used to google indexing virtually /everything/ on the web. I knew I always used bugzilla for that type of searches, not google, but I didn't realize why, until someone happened to explain it in a post such as this one. So anyway, now you (and possibly others on the list) know. =8^) Google's good for a lot of stuff, but not for looking up bugs filed in bugzilla. Neat thing about newsgroups/mailing-lists that way. You ask a question, or read one someone else has asked, and often get answers to questions you didn't even know you had, in the process of getting the answer to the one. =8^) That's one reason I find them so much fun, as I never know what new and useful thing I'm going to learn when I load up the messages. =8^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: getaddrinfo(): Bad value for ai_flags
Daniel Iliev [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 28 Dec 2006 13:09:20 +0200: whois (from net-misc/whois-4.7.19) gives me: whois gentoo.org getaddrinfo(whois.publicinterestregistry.net): Bad value for ai_flags [snip] So I did emerge -1 glibc emul-linux-x86-baselibs libidn whois but it didn't solve the problem. Any ideas? I'm not a whois expert by far (anyone have a link to a decent tutorial handy?), but on I'm on ~amd64 here, so have whois-4.7.20 (which is keyworded ~amd64) merged, and that whois query returned what looked like valid data to me, here. One thing I can say, however, is that the emul-linux-x86-baselibs has nothing to do with it, since it's 32-bit and wouldn't even load in the process space of a 64-bit whois process. 32-bit and 64-bit processes and libraries simply don't mix, the whole reason the 32-bit emul-linux-x86-* and -bin packages are necessary in the first place. (A very few packages, including gcc/glibc/sandbox, compile separate code and normally separate files for each bitness, but they are special cases.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] unsubscribe
On Wed, Dec 27, 2006 at 10:46:25PM -0800, J?ri-Kaur Schultz wrote: unsubscribe Here's how to unsubscribe: First, ask your Internet Provider to mail you an Unsubscribing Kit. Then follow these directions. The kit will most likely be the standard no-fault type. Depending on requirements, System A and/or System B can be used. When operating System A, depress lever and a plastic dalkron unsubscriber will be dispensed through the slot immediately underneath. When you have fastened the adhesive lip, attach connection marked by the large X outlet hose. Twist the silver-coloured ring one inch below the connection point until you feel it lock. The kit is now ready for use. The Cin-Eliminator is activated by the small switch on the lip. When securing, twist the ring back to its initial condition, so that the two orange lines meet. Disconnect. Place the dalkron unsubscriber in the vacuum receptacle to the rear. Activate by pressing the blue button. The controls for System B are located on the opposite side. The red release switch places the Cin-Eliminator into position; it can be adjusted manually up or down by pressing the blue manual release button. The opening is self-adjusting. To secure after use, press the green button, which simultaneously activates the evaporator and returns the Cin-Eliminator to its storage position. You may log off if the green exit light is on over the evaporator. If the red light is illuminated, one of the Cin-Eliminator requirements has not been properly implemented. Press the List Guy call button on the right of the evaporator. He will secure all facilities from his control panel. To use the Auto-Unsub, first undress and place all your clothes in the clothes rack. Put on the velcro slippers located in the cabinet immediately below. Enter the shower, taking the entire kit with you. On the control panel to your upper right upon entering you will see a Shower seal button. Press to activate. A green light will then be illuminated immediately below. On the intensity knob, select the desired setting. Now depress the Auto-Unsub activation lever. Bathe normally. The Auto-Unsub will automatically go off after three minutes unless you activate the Manual off override switch by flipping it up. When you are ready to leave, press the blue Shower seal release button. The door will open and you may leave. Please remove the velcro slippers and place them in their container. If you prefer the ultrasonic log-off mode, press the indicated blue button. When the twin panels open, pull forward by rings A B. The knob to the left, just below the blue light, has three settings, low, medium or high. For normal use, the medium setting is suggested. After these settings have been made, you can activate the device by switching to the ON position the clearly marked red switch. If during the unsubscribing operation you wish to change the settings, place the manual off override switch in the OFF position. You may now make the change and repeat the cycle. When the green exit light goes on, you may log off and have lunch. Please close the door behind you. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Browsing speed problems - possibly flash related
Hi,
I'm noticing that what I think is a flash presentation in
firefox-bin on my 3GHz Gentoo AMD64 machine is *significantly* slower,
like 10x slower, than the same page coming up on my 1.6Ghz Athlon XP
machine running Win XP.
If I go to the following page
http://www.investools.com/
then what I see is a green arrow filling up for about 10 seconds while
this presentation loading. On the XP box it's essentially
instantaneous. I cleared cache and restarted the browser on both
machines to make the comparison.
Granted, I don't care about this stuff on the front page but there
is stuff inside the website that I need which is also 5-10x slower on
my Gentoo machine than on Win XP which makes using Gentoo pretty much
out of the question. I'm not sure the stuff inside is actually flash -
it's static charts, etc., some of which are done with Java I think.
Do any others see this same slow response on the front page?
I'm using a newish flash although I haven't sync'ed in a day or two
so maybe something else is out there.
[EMAIL PROTECTED] ~ $ eix -I flash
[I] net-www/netscape-flash
Available versions: 7.0.63 7.0.68 {M}(~)9.0.21.55 {M}(~)9.0.21.78
Installed versions: 9.0.21.78(04:34:22 PM 12/02/2006)
Homepage:http://www.adobe.com/
Description: Adobe Flash Player
[EMAIL PROTECTED] ~ $
Is this a firefox-bin thing? Maybe I should build firefox from source?
Thanks in advance,
Mark
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] unsubscribe
Jüri-Kaur Schultz wrote:
unsubscribe
#include subscribe.h;
unsubscribe ('gentoo-amd64@lists.gentoo.org') or die();
Send instant messages to your online friends http://uk.messenger.yahoo.com
--
gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] unsubscribe
unsubscribe -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Wine (with OpenGL) on AMD64
On Thursday 28 December 2006 1:45 am, Troy Curtis Jr wrote: Has anyone gotten wine compiled with opengl support on AMD64? My configure (using portage and several iterations of a manual configure) keeps warning me that no OpenGL libs were found but I DO have the non-free nvidia driver working and here is the output of all the relevant directories (that I know of): the nvidia-drivers package install both the 64bit and 32bit libraries when you are using a multilib profile on amd64 # equery f x11-drivers/nvidia-drivers |grep libGL.so$ /usr/lib32/opengl/nvidia/lib/libGL.so /usr/lib64/opengl/nvidia/lib/libGL.so Looking at the command that the 0.9.28 ebuild gives, it seems to expect all the necessary libraries in /usr/lib32, and I think the libGLU* may be the reason it is complaining. The question is, *should* I have those libraries in /usr/lib32? If so does anyone know how to go about getting them the right way? # equery b libGLU.so [ Searching for file(s) libGLU.so in *... ] app-emulation/emul-linux-x86-xlibs-7.0-r3 (/emul/linux/x86/usr/lib/libGLU.so - libGLU.so.1) media-libs/mesa-6.5.1-r1 (/usr/lib64/libGLU.so - libGLU.so.1) -- gentoo-amd64@gentoo.org mailing list
RE: [gentoo-amd64] unsubscribe
thick French accentBe gone! Or we shall taunt you a third time!/thick
French accent
;-)
-Original Message-
From: Michel Merinoff [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 28, 2006 10:43 AM
To: gentoo-amd64@lists.gentoo.org
Subject: Re: [gentoo-amd64] unsubscribe
Jüri-Kaur Schultz wrote:
unsubscribe
#include subscribe.h;
unsubscribe ('gentoo-amd64@lists.gentoo.org') or die();
Send instant messages to your online friends http://uk.messenger.yahoo.com
--
gentoo-amd64@gentoo.org mailing list
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.15.29/607 - Release Date: 12/28/2006
12:31 PM
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.15.29/607 - Release Date: 12/28/2006
12:31 PM
--
gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] SATA mdraid woes
A few weeks ago I had a hardware problem, and the upshot is that I now have a new motherboard, a SuperMicro H8DCE. I now can't boot my Gentoo system. This box has two IDE drives on the primary IDE channel (and two optical drives on the secondary), and I have two small ext2 partitions on /dev/hda1 to boot Linux. Windows lives in hda3, and I'm using it now to write Webmail. Grub lives in /dev/hda1, pointed to by BootMagic in the MBR. Hdb is mostly to keep backups of other things, being 200 GB. Gentoo lives on two SATA drives, which the BIOS shows me as ide3 master and ide4 master. I have a small boot partition on each of them, rarely used, then the rest is given over to several RAID-1 partitions. E.g. the root partition is on /dev/md2, which is assembled from /dev/sd[ab]5. When I first got the box back I tried booting with no changes. Blank screen and no keyboard as soon as I hit the default choice in the grub screen. That was ok as several hardware changes have occurred. So I compiled a new kernel to use the new graphics card (PCI Express instead of AGP) and motherboard chipset (nForce Pro 2200/2050 instead of VIA) and network card (forcedeth instead of tg3). Still the same, so I backed up all the data, deleted the md and sd partitions and recreated them all afresh, then restored all the backed-up data. Now I get a can't-find-root error. I've experimented with lots of kernel parameters, both when compiling and on the command line, but I can't get the system to boot. Here's a selection of diagnostics, which I hope I've transcribed aright: -- ACPI: PCI Interrupt Link [LTID] enabled at IRQ22 ata1: SATA max UDMA/133 cmd 0xC800 ctl 0xC402 bmdma 0xB800 irq22 ata1: SATA max UDMA/133 cmd 0xC800 ctl 0xBC02 bmdma 0xB800 irq22 [that's the ordinary IDE subsystem] ... scsi2: sata_nv [so the nForce SATA functionality is compiled in ok] ata1: SATA link up 1.5Gbps (SStatus 113 SControl 300) ata1.00: ATA-7, max UDMA/133, 398297088 sectors: LBA48 NCQ (depth 0/32) ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 scsi3: sata_nv ata2: SATA link up 1.5Gbps (SStatus 113 SControl 300) ata2.00: ATA-7, max UDMA/133, 398297088 sectors: LBA48 NCQ (depth 0/32) ata2.00: ata2: dev 0 multi count 16 ata2.00: configured for UDMA/133 scsi 2:0:0:0 Direct-Access ATA Maxtor 6L200M0 BANC PQ: ANSI: 5 scsi 3:0:0:0 Direct-Access ATA Maxtor 6L200M0 BANC PQ: ANSI: 5 [that's the two SATA drives] ACPI: PCI Interrupt Link [LTIE] enabled at IRQ 21 ACPI: PCI Interrupt :00:08.0[A] - Link [LTIE] - GSI 21 (level, low) - IRQ21 ... (ata3 to ata8 links down) ... md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 [so I've got mdraid compiled in] ... Activating mdev Detected real_root as a md device. Setting up the device node Determining root device... Mounting root... ... The root block device is unspecified or not detected. -- [end of transcript] Then I'm invited to specify another device, or enter a shell. I use the shell to say ls -l /dev/md2, which shows the block device I expect to see, but cat /dev/md2 returns an empty result. If I do that from the installation CD I get a dump of the contents of the md disk, so it seems that the node exists but it isn't connected to the array /dev/md2. All I can think of is that I've made an error in creating the RAID-1 arrays, but can anyone point me to what that might be? -- Rgds Peter. Message sent using UebiMiau 2.7.2 -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] SATA mdraid woes
On Thu, 2006-12-28 at 18:06 +, Peter Humphrey wrote: A few weeks ago I had a hardware problem, and the upshot is that I now have a new motherboard, a SuperMicro H8DCE. I now can't boot my Gentoo system. I had a similar problem resulting from a similar upgrade. It was because of the order of the drives, which was different in the BIOS (as seen by grub) and the Linux kernel. mdadm should not care and it should be able to re-assemble the array no matter what the partitions are named (sdc|d instead of sda|b in my case) Some of the arrays were out of sync (I had mounted one of the raid-1 partitions separately for making a backup, etc) - booting using knoppix (or using a simple recovery ramdisk) allowed me to re-assemble them. Reboot, done. It can be useful to keep a ~200MB partition to install something small like Slackware/Busybox for emergencies, this would allow you to boot on a single drive and see what the kernel and mdadm tools make of your array. Hope this helps! Antoine -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Wine (with OpenGL) on AMD64
ya i have lol, i am play WoW. But i would recomend heading over to Winehq.com, and checking out there database and support, because it would probably be more useful than thi. On 12/28/06, Kevin Koltzau [EMAIL PROTECTED] wrote: On Thursday 28 December 2006 1:45 am, Troy Curtis Jr wrote: Has anyone gotten wine compiled with opengl support on AMD64? My configure (using portage and several iterations of a manual configure) keeps warning me that no OpenGL libs were found but I DO have the non-free nvidia driver working and here is the output of all the relevant directories (that I know of): the nvidia-drivers package install both the 64bit and 32bit libraries when you are using a multilib profile on amd64 # equery f x11-drivers/nvidia-drivers |grep libGL.so$ /usr/lib32/opengl/nvidia/lib/libGL.so /usr/lib64/opengl/nvidia/lib/libGL.so Looking at the command that the 0.9.28 ebuild gives, it seems to expect all the necessary libraries in /usr/lib32, and I think the libGLU* may be the reason it is complaining. The question is, *should* I have those libraries in /usr/lib32? If so does anyone know how to go about getting them the right way? # equery b libGLU.so [ Searching for file(s) libGLU.so in *... ] app-emulation/emul-linux-x86-xlibs-7.0-r3 (/emul/linux/x86/usr/lib/libGLU.so - libGLU.so.1) media-libs/mesa-6.5.1-r1 (/usr/lib64/libGLU.so - libGLU.so.1) -- gentoo-amd64@gentoo.org mailing list -- Karma, It's Real! No penguins were harmed during the writing, just a bunch of broken windows to let them escape...-xtacocorex
[gentoo-amd64] Re: SATA mdraid woes
Peter Humphrey [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 28 Dec 2006 18:06:48 +: [snipped] md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 [so I've got mdraid compiled in] ... Activating mdev Detected real_root as a md device. Setting up the device node Determining root device... Mounting root... ... The root block device is unspecified or not detected. -- [end of transcript] Then I'm invited to specify another device, or enter a shell. I use the shell to say ls -l /dev/md2, which shows the block device I expect to see, but cat /dev/md2 returns an empty result. If I do that from the installation CD I get a dump of the contents of the md disk, so it seems that the node exists but it isn't connected to the array /dev/md2. All I can think of is that I've made an error in creating the RAID-1 arrays, but can anyone point me to what that might be? From what I've seen, there aren't a lot of folks on this list doing RAID, and some of the ones that are, are using the DM-RAID firmware-RAID stuff, rather than md-RAID. I'm doing RAID, but RAID-only, no non-RAID boot and no initramfs, so that aspect of it I'm unfamiliar with and that seems to be the problem, so I'll be of limited help. I'm /guessing/ the most likely list to have real RAID experts on it is going to be the gentoo-server list, which I've never subscribed to so I can't say for sure /what/ they call topical there. FWIW tho I don't see that it's going to help you presently, unless you decide to rework to do something similar, I'm setup using md RAID-0, -1, and -6 on four identically partitioned SATA drives. RAID-0 for /boot since GRUB can work with it. Partitioned RAID-6 for my main system, with root (including everything portage writes to, so much of /var and /usr, on root, keeping portage in sync with what's on the partition) and a backup root image on two of the RAID-6 partitions (I'd go with a second backup image if I redid it) and an LVM2 managed RAID-6 partition as well for data. The RAID-0 covers all the temp and redownloadable stuff such as the portage tree. Critically, my root and backup root partitions are directly on the partitioned RAID-6, not on LVM2, so I don't need an initramfs. md-RAID is built-in and can be configured on the kernel command line from GRUB, while LVM2 requires userspace configuration, thus an initramfs, which I can avoid by placing my root and backup directly on partitioned RAID-6 partitions. Thus, in the event of motherboard/SATA-chipset hardware failure, all that's needed to get going again is a new mobo and the ability to compile a kernel with the appropriate standard SATA drivers for the new chipset. The kernel is pointed at the correct root from its command line directly, no initramfs or the like needed, and lvm2 loads from the main root and only manages non-system data, so I have a fully working root complete with all the usual binaries to work with if I have lvm2 issues. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Browsing speed problems - possibly flash related
On Thursday 28 December 2006 10:01, Mark Knecht [EMAIL PROTECTED] wrote about '[gentoo-amd64] Browsing speed problems - possibly flash related': Is this a firefox-bin thing? Maybe I should build firefox from source? Good luck getting flash to work if you do that. :P -- If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. -- Gentoo Developer Ciaran McCreesh pgpBLnSHXsVuM.pgp Description: PGP signature
Re: [gentoo-amd64] Re: SATA mdraid woes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: Peter Humphrey [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 28 Dec 2006 18:06:48 +: [snipped] md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 [so I've got mdraid compiled in] ... Activating mdev Detected real_root as a md device. Setting up the device node Determining root device... Mounting root... ... The root block device is unspecified or not detected. -- [end of transcript] Then I'm invited to specify another device, or enter a shell. I use the shell to say ls -l /dev/md2, which shows the block device I expect to see, but cat /dev/md2 returns an empty result. If I do that from the installation CD I get a dump of the contents of the md disk, so it seems that the node exists but it isn't connected to the array /dev/md2. All I can think of is that I've made an error in creating the RAID-1 arrays, but can anyone point me to what that might be? From what I've seen, there aren't a lot of folks on this list doing RAID, and some of the ones that are, are using the DM-RAID firmware-RAID stuff, rather than md-RAID. damn ricers! here are the 2 most commonly overlooked items: the sdXY partitions must be type FD (linux raid) and you must use a persistent superblock. - -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Council Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRZSTt4BrouQZ9K4FAQJtJAQAzI6r4+AetIHB4pmFtmQFL7mCfm090u2V uS+96fSwweS46YMEoWJSNS/OB9PDJIgGpSCLUwcxl55+7T96yNQl0HVwba0C7IGV P7s7UAH43pRXTpb1S4XClUNnrK6whle5ohCH72imU2a5SaGEiDBedFwng1C3JRPD MyNwgw8aHuA= =fUn9 -END PGP SIGNATURE- -- gentoo-amd64@gentoo.org mailing list
