You can subscribe to this list here.
2006 |
Jan
|
Feb
(1) |
Mar
(39) |
Apr
(76) |
May
(63) |
Jun
(56) |
Jul
(45) |
Aug
(112) |
Sep
(65) |
Oct
(115) |
Nov
(114) |
Dec
(100) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(87) |
Feb
(114) |
Mar
(179) |
Apr
(218) |
May
(147) |
Jun
(246) |
Jul
(155) |
Aug
(133) |
Sep
(103) |
Oct
(61) |
Nov
(37) |
Dec
(12) |
2008 |
Jan
(20) |
Feb
(123) |
Mar
(106) |
Apr
(59) |
May
(51) |
Jun
(62) |
Jul
(24) |
Aug
(42) |
Sep
(12) |
Oct
(21) |
Nov
(6) |
Dec
(33) |
2009 |
Jan
(16) |
Feb
(17) |
Mar
(11) |
Apr
(2) |
May
(4) |
Jun
(18) |
Jul
(24) |
Aug
(22) |
Sep
(31) |
Oct
(4) |
Nov
(2) |
Dec
|
2010 |
Jan
(19) |
Feb
(3) |
Mar
(26) |
Apr
(37) |
May
(10) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(2) |
2011 |
Jan
(11) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(5) |
Nov
(8) |
Dec
|
From: Geoffrey <li...@se...> - 2010-04-21 16:30:32
|
Justin P. Mattock wrote: > On 04/21/2010 09:11 AM, Geoffrey wrote: >> Justin P. Mattock wrote: >>> On 04/21/2010 06:55 AM, Geoffrey wrote: >>>> So I rebuilt my kernel, insuring that I had ext3 support and I still >>>> get >>>> a panic, although it is a different message: >>>> >>>> Kernel panic - not syncing: VFS: Unable to mount root fs on >>>> unknown-block(0,0) >>>> >>>> >>> >>> check your /etc/fstab and make sure >>> that it's /dev/sda* instead of /dev/hda* >>> (if your using the older ati-piix it's should >>> be /dev/hda* but using the new ati-piix it's >>> /dev/sda*)but could be wrong). >> >> Actually it's using the LABEL nomenclature, do you think this could be >> my problem? >> >> LABEL=/ / ext3 defaults 1 1 >> >> > > could be.. > here's what I have: > cat /etc/fstab > > # file system mount-point type options dump fsck > # order > > /dev/sda3 / ext4 defaults,errors=remount-ro,user_xattr > 1 1 > /dev/sda4 swap swap pri=1 0 0 > /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 > 0 0 > proc /proc proc defaults 0 0 > sysfs /sys sysfs defaults 0 0 > devpts /dev/pts devpts gid=4,mode=620 0 0 > tmpfs /dev/shm tmpfs defaults 0 0 > #none /selinux selinuxfs defaults 0 0 > # End /etc/fstab > > does changing LABEL=/ to your device do anything? Just tried that, no difference. > > Justin P. Mattock > -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: Justin P. M. <jus...@gm...> - 2010-04-21 16:15:46
|
On 04/21/2010 09:11 AM, Geoffrey wrote: > Justin P. Mattock wrote: >> On 04/21/2010 06:55 AM, Geoffrey wrote: >>> So I rebuilt my kernel, insuring that I had ext3 support and I still get >>> a panic, although it is a different message: >>> >>> Kernel panic - not syncing: VFS: Unable to mount root fs on >>> unknown-block(0,0) >>> >>> >> >> check your /etc/fstab and make sure >> that it's /dev/sda* instead of /dev/hda* >> (if your using the older ati-piix it's should >> be /dev/hda* but using the new ati-piix it's >> /dev/sda*)but could be wrong). > > Actually it's using the LABEL nomenclature, do you think this could be > my problem? > > LABEL=/ / ext3 defaults 1 1 > > could be.. here's what I have: cat /etc/fstab # file system mount-point type options dump fsck # order /dev/sda3 / ext4 defaults,errors=remount-ro,user_xattr 1 1 /dev/sda4 swap swap pri=1 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 devpts /dev/pts devpts gid=4,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 #none /selinux selinuxfs defaults 0 0 # End /etc/fstab does changing LABEL=/ to your device do anything? Justin P. Mattock |
From: Geoffrey <li...@se...> - 2010-04-21 16:11:53
|
Justin P. Mattock wrote: > On 04/21/2010 06:55 AM, Geoffrey wrote: >> So I rebuilt my kernel, insuring that I had ext3 support and I still get >> a panic, although it is a different message: >> >> Kernel panic - not syncing: VFS: Unable to mount root fs on >> unknown-block(0,0) >> >> > > check your /etc/fstab and make sure > that it's /dev/sda* instead of /dev/hda* > (if your using the older ati-piix it's should > be /dev/hda* but using the new ati-piix it's > /dev/sda*)but could be wrong). Actually it's using the LABEL nomenclature, do you think this could be my problem? LABEL=/ / ext3 defaults 1 1 > > Justin P. Mattock > > ------------------------------------------------------------------------------ > _______________________________________________ > Mactel-linux-users mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactel-linux-users > -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: Justin P. M. <jus...@gm...> - 2010-04-21 15:36:10
|
On 04/21/2010 06:55 AM, Geoffrey wrote: > So I rebuilt my kernel, insuring that I had ext3 support and I still get > a panic, although it is a different message: > > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(0,0) > > check your /etc/fstab and make sure that it's /dev/sda* instead of /dev/hda* (if your using the older ati-piix it's should be /dev/hda* but using the new ati-piix it's /dev/sda*)but could be wrong). Justin P. Mattock |
From: Justin P. M. <jus...@gm...> - 2010-04-21 15:33:18
|
On 04/21/2010 07:27 AM, Geoffrey wrote: > Justin P. mattock wrote: >> On 04/16/2010 07:34 AM, Geoffrey Myers wrote: >>> I was attempting to upgrade my kernel and now when I boot, I get: >>> >>> grub >>> >>> >>> That's it. I don't understand this as I don't know what the kernel >>> update would do that would cause this to happen. My steps: >>> >>> 1. download kernel from kernel.org >>> 2. unpack >>> 3. configure >>> 4. make modules >>> 5. make >>> 6. make modules_install >>> 7. make install >>> 8. reboot >>> >>> Any suggestions would be greatly appreciated. >>> >>> -- >>> until later, Geof >>> >>> >> >> if you just get the grub screen and no movement >> likely tell's me you need to do and update-grub >> or if using lilo /sbin/lilo which updates the kernel's >> etc.. >> >> as for the building of the kernel >> you should >> make menuconfig >> make >> make modules(although you probably don't because its already done) >> make modules_install >> make install(if using lilo, the update automatically happens) >> grub you need to update-grub > > So when I run 'make install' I see this: > > WARNING: No module ehci-hcd found for kernel 2.6.33.2, continuing anyway > WARNING: No module ohci-hcd found for kernel 2.6.33.2, continuing anyway > WARNING: No module uhci-hcd found for kernel 2.6.33.2, continuing anyway > WARNING: No module ata_piix found for kernel 2.6.33.2, continuing anyway > WARNING: No module ata_piix found for kernel 2.6.33.2, continuing anyway > WARNING: No module ata_piix found for kernel 2.6.33.2, continuing anyway > > But in my kernel config I have: > > CONFIG_USB_ARCH_HAS_OHCI=y > CONFIG_USB_ARCH_HAS_EHCI=y > CONFIG_USB_UHCI_HCD=y > CONFIG_ATA_PIIX=y > > Is this an issue? > yeah it's just grub not realizing that the module is there it's just built-in the kernel. you should be o.k. Justin P. Mattock |
From: cyberdork33 <cyb...@gm...> - 2010-04-21 14:28:56
|
parted is capable of printing the GPT information fdisk cannot read the GPT, so will tell you what the MBR table contains. From your output, it seems you are indeed have a GPT. A utility called 'gptsync' may help you if your MBR table doesn't match. It comes with rEFIt, and I know that it is available as a package in Ubuntu, but I am unsure where to obtain it for RH. On Apr 21, 2010, at 9:20 AM, Geoffrey wrote: > cyberdork33 wrote: >> Are you sure that you Partition Label is "/" ? Maybe you can change >> your kernel line to have root=/dev/sdXX instead of using the label. > > I'll give that a go. > >> What does your Partition Table Look like? Are the GPT and MBR table >> out-of-sync? > > How would I know? > > Model: ATA Hitachi HTS72202 (scsi) > Disk /dev/sda: 200GB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > > Number Start End Size File system Name Flags > 1 20.5kB 210MB 210MB fat32 EFI System Partition boot > 2 210MB 98.9GB 98.7GB hfs+ Untitled > 4 99.0GB 109GB 10.3GB linux-swap > 3 109GB 109GB 105MB ext3 boot > 5 109GB 141GB 31.5GB ext3 > 6 141GB 162GB 21.0GB ext3 > 7 162GB 178GB 15.7GB ext3 > 8 178GB 193GB 15.7GB ext3 > 9 193GB 200GB 6712MB ext3 > >> On Apr 21, 2010, at 9:03 AM, Geoffrey wrote: >>> Geoffrey wrote: >>>> So I rebuilt my kernel, insuring that I had ext3 support and I >>>> still get a panic, although it is a different message: >>>> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) >>>> Here are my grub entries. The first is the new kernel, the >>>> second is my current working kernel. >>>> title Red Hat Enterprise Linux Client (2.6.33.2) root (hd0,2) kernel /vmlinuz-2.6.33.2 ro root=LABEL=/ irqpoll rhgb initrd >>>> /initrd-2.6.33.2.img title Red Hat Enterprise Linux Client >>>> (2.6.18-194.el5) root (hd0,2) kernel /vmlinuz-2.6.18-194.el5 ro >>>> root=LABEL=/ irqpoll rhgb quiet initrd /initrd-2.6.18-194.el5.img >>>> I still wonder if the fact that file returns different info about >>>> my current working kernel and this new kernel has anything to do >>>> with this issue? >>>> boot> file vmlinuz-2.6.33.2 vmlinuz-2.6.1 vmlinuz-2.6.33.2: >>>> Linux kernel x86 boot executable RO-rootFS, root_dev 0x808, >>>> swap_dev 0x3, Normal VGA vmlinuz-2.6.18-194.el5: ELF 64-bit LSB >>>> shared object, AMD x86-64, version 1, stripped >>> Googling this keeps pointing to the lack of file system support, >>> but I've got it in my config: >>> CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set # >>> CONFIG_EXT3_FS_SECURITY is not set >>> -- Until later, Geoffrey >>> "I predict future happiness for America if they can prevent the >>> government from wasting the labors of the people under the pretense >>> of taking care of them." - Thomas Jefferson >>> ------------------------------------------------------------------------------ >>> _______________________________________________ Mactel-linux-users >>> mailing list Mac...@li... https://lists.sourceforge.net/lists/listinfo/mactel-linux-users >> ------------------------------------------------------------------------------ >> _______________________________________________ Mactel-linux-users >> mailing list Mac...@li... https://lists.sourceforge.net/lists/listinfo/mactel-linux-users > > > -- > Until later, Geoffrey > > "I predict future happiness for America if they can prevent > the government from wasting the labors of the people under > the pretense of taking care of them." > - Thomas Jefferson |
From: Geoffrey <li...@se...> - 2010-04-21 14:28:22
|
cyberdork33 wrote: > Are you sure that you Partition Label is "/" ? Maybe you can change > your kernel line to have root=/dev/sdXX instead of using the label. That label works for my current working kernel. > > What does your Partition Table Look like? Are the GPT and MBR table > out-of-sync? > > On Apr 21, 2010, at 9:03 AM, Geoffrey wrote: > >> Geoffrey wrote: >>> So I rebuilt my kernel, insuring that I had ext3 support and I >>> still get a panic, although it is a different message: >>> >>> Kernel panic - not syncing: VFS: Unable to mount root fs on >>> unknown-block(0,0) >>> >>> Here are my grub entries. The first is the new kernel, the >>> second is my current working kernel. >>> >>> title Red Hat Enterprise Linux Client (2.6.33.2) root (hd0,2) >>> kernel /vmlinuz-2.6.33.2 ro root=LABEL=/ irqpoll rhgb initrd >>> /initrd-2.6.33.2.img title Red Hat Enterprise Linux Client >>> (2.6.18-194.el5) root (hd0,2) kernel /vmlinuz-2.6.18-194.el5 ro >>> root=LABEL=/ irqpoll rhgb quiet initrd /initrd-2.6.18-194.el5.img >>> >>> >>> I still wonder if the fact that file returns different info about >>> my current working kernel and this new kernel has anything to do >>> with this issue? >>> >>> boot> file vmlinuz-2.6.33.2 vmlinuz-2.6.1 vmlinuz-2.6.33.2: >>> Linux kernel x86 boot executable RO-rootFS, root_dev 0x808, >>> swap_dev 0x3, Normal VGA vmlinuz-2.6.18-194.el5: ELF 64-bit LSB >>> shared object, AMD x86-64, version 1, stripped >> Googling this keeps pointing to the lack of file system support, >> but I've got it in my config: >> >> CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set >> CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set # >> CONFIG_EXT3_FS_SECURITY is not set >> >> -- Until later, Geoffrey >> >> "I predict future happiness for America if they can prevent the >> government from wasting the labors of the people under the pretense >> of taking care of them." - Thomas Jefferson >> >> ------------------------------------------------------------------------------ >> _______________________________________________ Mactel-linux-users >> mailing list Mac...@li... >> https://lists.sourceforge.net/lists/listinfo/mactel-linux-users > > > ------------------------------------------------------------------------------ > _______________________________________________ Mactel-linux-users > mailing list Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactel-linux-users > -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: Geoffrey <li...@se...> - 2010-04-21 14:27:40
|
Justin P. mattock wrote: > On 04/16/2010 07:34 AM, Geoffrey Myers wrote: >> I was attempting to upgrade my kernel and now when I boot, I get: >> >> grub >> >> >> That's it. I don't understand this as I don't know what the kernel update would do that would cause this to happen. My steps: >> >> 1. download kernel from kernel.org >> 2. unpack >> 3. configure >> 4. make modules >> 5. make >> 6. make modules_install >> 7. make install >> 8. reboot >> >> Any suggestions would be greatly appreciated. >> >> -- >> until later, Geof >> >> > > if you just get the grub screen and no movement > likely tell's me you need to do and update-grub > or if using lilo /sbin/lilo which updates the kernel's > etc.. > > as for the building of the kernel > you should > make menuconfig > make > make modules(although you probably don't because its already done) > make modules_install > make install(if using lilo, the update automatically happens) > grub you need to update-grub So when I run 'make install' I see this: WARNING: No module ehci-hcd found for kernel 2.6.33.2, continuing anyway WARNING: No module ohci-hcd found for kernel 2.6.33.2, continuing anyway WARNING: No module uhci-hcd found for kernel 2.6.33.2, continuing anyway WARNING: No module ata_piix found for kernel 2.6.33.2, continuing anyway WARNING: No module ata_piix found for kernel 2.6.33.2, continuing anyway WARNING: No module ata_piix found for kernel 2.6.33.2, continuing anyway But in my kernel config I have: CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB_UHCI_HCD=y CONFIG_ATA_PIIX=y Is this an issue? > > hope this helps > > Justin P. Mattock > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mactel-linux-users mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactel-linux-users > -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: Geoffrey <li...@se...> - 2010-04-21 14:20:40
|
cyberdork33 wrote: > Are you sure that you Partition Label is "/" ? Maybe you can change > your kernel line to have root=/dev/sdXX instead of using the label. I'll give that a go. > > What does your Partition Table Look like? Are the GPT and MBR table > out-of-sync? How would I know? Model: ATA Hitachi HTS72202 (scsi) Disk /dev/sda: 200GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 20.5kB 210MB 210MB fat32 EFI System Partition boot 2 210MB 98.9GB 98.7GB hfs+ Untitled 4 99.0GB 109GB 10.3GB linux-swap 3 109GB 109GB 105MB ext3 boot 5 109GB 141GB 31.5GB ext3 6 141GB 162GB 21.0GB ext3 7 162GB 178GB 15.7GB ext3 8 178GB 193GB 15.7GB ext3 9 193GB 200GB 6712MB ext3 > > On Apr 21, 2010, at 9:03 AM, Geoffrey wrote: > >> Geoffrey wrote: >>> So I rebuilt my kernel, insuring that I had ext3 support and I >>> still get a panic, although it is a different message: >>> >>> Kernel panic - not syncing: VFS: Unable to mount root fs on >>> unknown-block(0,0) >>> >>> Here are my grub entries. The first is the new kernel, the >>> second is my current working kernel. >>> >>> title Red Hat Enterprise Linux Client (2.6.33.2) root (hd0,2) >>> kernel /vmlinuz-2.6.33.2 ro root=LABEL=/ irqpoll rhgb initrd >>> /initrd-2.6.33.2.img title Red Hat Enterprise Linux Client >>> (2.6.18-194.el5) root (hd0,2) kernel /vmlinuz-2.6.18-194.el5 ro >>> root=LABEL=/ irqpoll rhgb quiet initrd /initrd-2.6.18-194.el5.img >>> >>> >>> I still wonder if the fact that file returns different info about >>> my current working kernel and this new kernel has anything to do >>> with this issue? >>> >>> boot> file vmlinuz-2.6.33.2 vmlinuz-2.6.1 vmlinuz-2.6.33.2: >>> Linux kernel x86 boot executable RO-rootFS, root_dev 0x808, >>> swap_dev 0x3, Normal VGA vmlinuz-2.6.18-194.el5: ELF 64-bit LSB >>> shared object, AMD x86-64, version 1, stripped >> Googling this keeps pointing to the lack of file system support, >> but I've got it in my config: >> >> CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set >> CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set # >> CONFIG_EXT3_FS_SECURITY is not set >> >> -- Until later, Geoffrey >> >> "I predict future happiness for America if they can prevent the >> government from wasting the labors of the people under the pretense >> of taking care of them." - Thomas Jefferson >> >> ------------------------------------------------------------------------------ >> _______________________________________________ Mactel-linux-users >> mailing list Mac...@li... >> https://lists.sourceforge.net/lists/listinfo/mactel-linux-users > > > ------------------------------------------------------------------------------ > _______________________________________________ Mactel-linux-users > mailing list Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactel-linux-users > -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: cyberdork33 <cyb...@gm...> - 2010-04-21 14:08:08
|
Are you sure that you Partition Label is "/" ? Maybe you can change your kernel line to have root=/dev/sdXX instead of using the label. What does your Partition Table Look like? Are the GPT and MBR table out-of-sync? On Apr 21, 2010, at 9:03 AM, Geoffrey wrote: > Geoffrey wrote: >> So I rebuilt my kernel, insuring that I had ext3 support and I still get >> a panic, although it is a different message: >> >> Kernel panic - not syncing: VFS: Unable to mount root fs on >> unknown-block(0,0) >> >> Here are my grub entries. The first is the new kernel, the second is my >> current working kernel. >> >> title Red Hat Enterprise Linux Client (2.6.33.2) >> root (hd0,2) >> kernel /vmlinuz-2.6.33.2 ro root=LABEL=/ irqpoll rhgb >> initrd /initrd-2.6.33.2.img >> title Red Hat Enterprise Linux Client (2.6.18-194.el5) >> root (hd0,2) >> kernel /vmlinuz-2.6.18-194.el5 ro root=LABEL=/ irqpoll rhgb quiet >> initrd /initrd-2.6.18-194.el5.img >> >> I still wonder if the fact that file returns different info about my >> current working kernel and this new kernel has anything to do with this >> issue? >> >> boot> file vmlinuz-2.6.33.2 vmlinuz-2.6.1 >> vmlinuz-2.6.33.2: Linux kernel x86 boot executable RO-rootFS, >> root_dev 0x808, swap_dev 0x3, Normal VGA >> vmlinuz-2.6.18-194.el5: ELF 64-bit LSB shared object, AMD x86-64, >> version 1, stripped > > Googling this keeps pointing to the lack of file system support, but > I've got it in my config: > > CONFIG_EXT3_FS=y > # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set > CONFIG_EXT3_FS_XATTR=y > # CONFIG_EXT3_FS_POSIX_ACL is not set > # CONFIG_EXT3_FS_SECURITY is not set > > -- > Until later, Geoffrey > > "I predict future happiness for America if they can prevent > the government from wasting the labors of the people under > the pretense of taking care of them." > - Thomas Jefferson > > ------------------------------------------------------------------------------ > _______________________________________________ > Mactel-linux-users mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactel-linux-users |
From: Geoffrey <li...@se...> - 2010-04-21 14:04:00
|
Geoffrey wrote: > So I rebuilt my kernel, insuring that I had ext3 support and I still get > a panic, although it is a different message: > > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(0,0) > > Here are my grub entries. The first is the new kernel, the second is my > current working kernel. > > title Red Hat Enterprise Linux Client (2.6.33.2) > root (hd0,2) > kernel /vmlinuz-2.6.33.2 ro root=LABEL=/ irqpoll rhgb > initrd /initrd-2.6.33.2.img > title Red Hat Enterprise Linux Client (2.6.18-194.el5) > root (hd0,2) > kernel /vmlinuz-2.6.18-194.el5 ro root=LABEL=/ irqpoll rhgb quiet > initrd /initrd-2.6.18-194.el5.img > > I still wonder if the fact that file returns different info about my > current working kernel and this new kernel has anything to do with this > issue? > > boot> file vmlinuz-2.6.33.2 vmlinuz-2.6.1 > vmlinuz-2.6.33.2: Linux kernel x86 boot executable RO-rootFS, > root_dev 0x808, swap_dev 0x3, Normal VGA > vmlinuz-2.6.18-194.el5: ELF 64-bit LSB shared object, AMD x86-64, > version 1, stripped Googling this keeps pointing to the lack of file system support, but I've got it in my config: CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set # CONFIG_EXT3_FS_SECURITY is not set -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: Geoffrey <li...@se...> - 2010-04-21 13:55:47
|
So I rebuilt my kernel, insuring that I had ext3 support and I still get a panic, although it is a different message: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Here are my grub entries. The first is the new kernel, the second is my current working kernel. title Red Hat Enterprise Linux Client (2.6.33.2) root (hd0,2) kernel /vmlinuz-2.6.33.2 ro root=LABEL=/ irqpoll rhgb initrd /initrd-2.6.33.2.img title Red Hat Enterprise Linux Client (2.6.18-194.el5) root (hd0,2) kernel /vmlinuz-2.6.18-194.el5 ro root=LABEL=/ irqpoll rhgb quiet initrd /initrd-2.6.18-194.el5.img I still wonder if the fact that file returns different info about my current working kernel and this new kernel has anything to do with this issue? boot> file vmlinuz-2.6.33.2 vmlinuz-2.6.1 vmlinuz-2.6.33.2: Linux kernel x86 boot executable RO-rootFS, root_dev 0x808, swap_dev 0x3, Normal VGA vmlinuz-2.6.18-194.el5: ELF 64-bit LSB shared object, AMD x86-64, version 1, stripped -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: Justin P. m. <jus...@gm...> - 2010-04-16 16:16:23
|
On 04/16/2010 08:37 AM, Geoffrey wrote: > cyberdork33 wrote: >> It sounds like GRUB stage 1 lost track of where the stage 2 files >> are. >> >> http://www.gnu.org/software/grub/manual/html_node/Installing-GRUB-natively.html#Installing-GRUB-natively >> > > Okay, got grub reinstalled and booting to original kernel. Now I get > the following when I attempt to boot the new kernel: > > mount: could not find filesystem '/dev/root' > Setting up other filesystems. > Setting up new root fs > setuproot: moving /dev failed: No such file or directory > no fstab.sys, mounting internal defaults > setuproot: error mounting /proc: No such file or directory > setuproot: error mounting /sys: No such file or directory > Switching to new root and running init. > unmounting old /dev > unmounting old /proc > unmounting old /sys > switchroot: mount failed: No such file or directory > Kernel panic - not syncing: Attempted to kill init! > Pid: 1, comm: init Not tainted 2.6.33.2 #1 > Call Trace: > . > never have seen this before.. doing a quick google gave me this: http://www.linuxquestions.org/questions/fedora-installation-39/fc6-mount-could-not-find-filesystem-dev-root-497332/ looking through the thread it seems it's the uuid of the device(but could be wrong). check /boot/grub/* and /etc/fstab to make sure the device is set correctly, also check in your .config that ext2/3/4(whatever your filesystem is that you build the module in the kernel i.g. y" instead of "m". (but looking at the error that might not be the case). Justin P. Mattock |
From: Geoffrey <li...@se...> - 2010-04-16 15:37:11
|
cyberdork33 wrote: > It sounds like GRUB stage 1 lost track of where the stage 2 files > are. > > http://www.gnu.org/software/grub/manual/html_node/Installing-GRUB-natively.html#Installing-GRUB-natively > Okay, got grub reinstalled and booting to original kernel. Now I get the following when I attempt to boot the new kernel: mount: could not find filesystem '/dev/root' Setting up other filesystems. Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.33.2 #1 Call Trace: . . > > On Apr 16, 2010, at 9:34 AM, Geoffrey Myers wrote: > >> I was attempting to upgrade my kernel and now when I boot, I get: >> >> grub >> >> >> That's it. I don't understand this as I don't know what the kernel >> update would do that would cause this to happen. My steps: >> >> 1. download kernel from kernel.org 2. unpack 3. configure 4. make >> modules 5. make 6. make modules_install 7. make install 8. reboot >> >> Any suggestions would be greatly appreciated. >> >> -- until later, Geof >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval Try the new software >> tools for yourself. Speed compiling, find bugs proactively, and >> fine-tune applications for parallel performance. See why Intel >> Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ Mactel-linux-users >> mailing list Mac...@li... >> https://lists.sourceforge.net/lists/listinfo/mactel-linux-users > > -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: Justin P. m. <jus...@gm...> - 2010-04-16 14:48:28
|
On 04/16/2010 07:34 AM, Geoffrey Myers wrote: > I was attempting to upgrade my kernel and now when I boot, I get: > > grub > > > That's it. I don't understand this as I don't know what the kernel update would do that would cause this to happen. My steps: > > 1. download kernel from kernel.org > 2. unpack > 3. configure > 4. make modules > 5. make > 6. make modules_install > 7. make install > 8. reboot > > Any suggestions would be greatly appreciated. > > -- > until later, Geof > > if you just get the grub screen and no movement likely tell's me you need to do and update-grub or if using lilo /sbin/lilo which updates the kernel's etc.. as for the building of the kernel you should make menuconfig make make modules(although you probably don't because its already done) make modules_install make install(if using lilo, the update automatically happens) grub you need to update-grub hope this helps Justin P. Mattock |
From: Geoffrey M. <li...@se...> - 2010-04-16 14:34:40
|
I was attempting to upgrade my kernel and now when I boot, I get: grub That's it. I don't understand this as I don't know what the kernel update would do that would cause this to happen. My steps: 1. download kernel from kernel.org 2. unpack 3. configure 4. make modules 5. make 6. make modules_install 7. make install 8. reboot Any suggestions would be greatly appreciated. -- until later, Geof |
From: Justin P. m. <jus...@gm...> - 2010-04-14 16:29:14
|
On 04/14/2010 08:33 AM, Geoffrey wrote: > Justin P. mattock wrote: > >>> I do hope to do this in the future, just that I've always had a problem >>> getting the kernel to boot once I built it. Need some time to research >>> this issue. >>> >>>> >>>> Justin P. Mattock >>> >> >> >> right now the only issue I'm having with the current HEAD >> is an Oops during boot: >> https://bugzilla.kernel.org/show_bug.cgi?id= 15749 >> which is fixed with the patch on the bug. >> >> then an SELinux avc issue with nscd. other than that >> the system boots fine(need to check other >> stuff, but will do later on). >> >> as for the bisect, your situation does look bisectable >> keep in mind though this could already have been fixed >> especially if redhat is using an older kernel. >> (but could be wrong) > > kernel 2.6.18-194.el5 > shit man support for the macbook didn't really come until 2.6.20(super kernel sunday!!) but keep in mind they probably patch 2.6.18 so it probably is there. (if not then this could be why(2.6.18 - 2.6.34 a huge lot of changes)). Justin P. Mattock |
From: Geoffrey <li...@se...> - 2010-04-14 15:39:13
|
Justin P. mattock wrote: >> I do hope to do this in the future, just that I've always had a problem >> getting the kernel to boot once I built it. Need some time to research >> this issue. >> >>> >>> Justin P. Mattock >> > > > right now the only issue I'm having with the current HEAD > is an Oops during boot: > https://bugzilla.kernel.org/show_bug.cgi?id= 15749 > which is fixed with the patch on the bug. > > then an SELinux avc issue with nscd. other than that > the system boots fine(need to check other > stuff, but will do later on). > > as for the bisect, your situation does look bisectable > keep in mind though this could already have been fixed > especially if redhat is using an older kernel. > (but could be wrong) kernel 2.6.18-194.el5 -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: Justin P. m. <jus...@gm...> - 2010-04-14 15:19:59
|
On 04/14/2010 08:06 AM, Geoffrey wrote: > Justin P. mattock wrote: >> On 04/14/2010 06:49 AM, Geoffrey wrote: >>> Justin P. mattock wrote: >>>> On 04/13/2010 07:57 AM, Geoffrey wrote: >>>>> Geoffrey wrote: >>>>>> Anyone out there running 64 bit OS on a macbook pro 4,1. I upgraded >>>>>> from 32 bit Red Hat EL 5.4 to 64 bit RHEL 5.4, then again to 64 bit >>>>>> RHEL >>>>>> 5.5, which is actually still in beta. I don't know if I lost the core >>>>>> in the 64 bit 5.4 or not. I see the following from dmesg: >>>>>> >>>>>> SMP: Allowing 2 CPUs, 0 hotplug CPUs >>>>>> . >>>>>> . >>>>>> SMP alternatives: switching to UP code >>>>>> . >>>>>> . >>>>>> SMP motherboard not detected. >>>>>> . >>>>>> . >>>>>> SMP disabled >>>>> >>>>> Thought I'd update the list with a recent success: >>>>> >>>>> For whatever reason, I could not get the initial installation RHEL 5.4 >>>>> disk to even boot until I stumbled across a link that suggested the >>>>> following boot parms: >>>>> >>>>> acpi=force noapic irqpoll >> >> the acpi=force seems harmless, but the noapic scares me(you need this), >> In any case you should be able to bootup without any of these boot >> params which makes me wonder if this is a kernel issue and/or userspace > > I've played a bit more with this. Removed the acpi=force too. Booted > fine. Problem if I remove the irqpoll. System starts to boot, but panics > on smartd ???? Keyboard is still responsive, ie toggle shift key led > on/off, but no screen output and can not switch virtual terminals. > > Put it back in for now, seems it might have something to do with the > dvd/cdrom drive. > >> >>>>> >>>>> I don't know why they worked, but they did. Once installed, I found >>>>> that I had to add them to my grub.conf to get the install to boot, but >>>>> all was happy. After moving to 64bit, I lost one core of my two core >>>>> processor. After much discussion with RH, I revisited these parameters >>>>> and found that by removing the noapic, parm, my macbook would still >>>>> boot >>>>> and I got both cores. The weird thing is, I've tried every combination >>>>> of these parms before in order to remove them from my boot process in >>>>> the past, but my macbook would not boot. There must be something about >>>>> the latest RHEL 5.5 kernel that resolved that issue. >>>>> >>>>> The weird thing is, I did not have this issue on 32bit RHEL 5.4. That >>>>> is, I had both cores using all these parms. >>>>> >>>> >>>> this doesn't seem right.. >>>> you need apic etc... they must be >>>> doing something in there configs somewhere >>>> (COFNIG_SMP=y if set gives you both cores >>>> (but could be wrong)). >>> >>> No telling, all I know is I have a happy dual core system again with a >>> 64 bit OS. ;) >>> >> >> That's good news.. if you can, maybe try loading the latest kernel >> from git, then if the system can bootup without any of these boot params >> then you know there's a regression in the kernel somewhere(then if you >> have the time do a bisect, and report it to lkml, so there aware of >> the commit that causes this). > > I do hope to do this in the future, just that I've always had a problem > getting the kernel to boot once I built it. Need some time to research > this issue. > >> >> Justin P. Mattock >> >> > > right now the only issue I'm having with the current HEAD is an Oops during boot: https://bugzilla.kernel.org/show_bug.cgi?id= 15749 which is fixed with the patch on the bug. then an SELinux avc issue with nscd. other than that the system boots fine(need to check other stuff, but will do later on). as for the bisect, your situation does look bisectable keep in mind though this could already have been fixed especially if redhat is using an older kernel. (but could be wrong) Justin P. Mattock |
From: Geoffrey <li...@se...> - 2010-04-14 15:06:30
|
Justin P. mattock wrote: > On 04/14/2010 06:49 AM, Geoffrey wrote: >> Justin P. mattock wrote: >>> On 04/13/2010 07:57 AM, Geoffrey wrote: >>>> Geoffrey wrote: >>>>> Anyone out there running 64 bit OS on a macbook pro 4,1. I upgraded >>>>> from 32 bit Red Hat EL 5.4 to 64 bit RHEL 5.4, then again to 64 bit >>>>> RHEL >>>>> 5.5, which is actually still in beta. I don't know if I lost the core >>>>> in the 64 bit 5.4 or not. I see the following from dmesg: >>>>> >>>>> SMP: Allowing 2 CPUs, 0 hotplug CPUs >>>>> . >>>>> . >>>>> SMP alternatives: switching to UP code >>>>> . >>>>> . >>>>> SMP motherboard not detected. >>>>> . >>>>> . >>>>> SMP disabled >>>> >>>> Thought I'd update the list with a recent success: >>>> >>>> For whatever reason, I could not get the initial installation RHEL 5.4 >>>> disk to even boot until I stumbled across a link that suggested the >>>> following boot parms: >>>> >>>> acpi=force noapic irqpoll > > the acpi=force seems harmless, but the noapic scares me(you need this), > In any case you should be able to bootup without any of these boot > params which makes me wonder if this is a kernel issue and/or userspace I've played a bit more with this. Removed the acpi=force too. Booted fine. Problem if I remove the irqpoll. System starts to boot, but panics on smartd ???? Keyboard is still responsive, ie toggle shift key led on/off, but no screen output and can not switch virtual terminals. Put it back in for now, seems it might have something to do with the dvd/cdrom drive. > >>>> >>>> I don't know why they worked, but they did. Once installed, I found >>>> that I had to add them to my grub.conf to get the install to boot, but >>>> all was happy. After moving to 64bit, I lost one core of my two core >>>> processor. After much discussion with RH, I revisited these parameters >>>> and found that by removing the noapic, parm, my macbook would still >>>> boot >>>> and I got both cores. The weird thing is, I've tried every combination >>>> of these parms before in order to remove them from my boot process in >>>> the past, but my macbook would not boot. There must be something about >>>> the latest RHEL 5.5 kernel that resolved that issue. >>>> >>>> The weird thing is, I did not have this issue on 32bit RHEL 5.4. That >>>> is, I had both cores using all these parms. >>>> >>> >>> this doesn't seem right.. >>> you need apic etc... they must be >>> doing something in there configs somewhere >>> (COFNIG_SMP=y if set gives you both cores >>> (but could be wrong)). >> >> No telling, all I know is I have a happy dual core system again with a >> 64 bit OS. ;) >> > > That's good news.. if you can, maybe try loading the latest kernel from > git, then if the system can bootup without any of these boot params > then you know there's a regression in the kernel somewhere(then if you > have the time do a bisect, and report it to lkml, so there aware of the > commit that causes this). I do hope to do this in the future, just that I've always had a problem getting the kernel to boot once I built it. Need some time to research this issue. > > Justin P. Mattock > > -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: Justin P. m. <jus...@gm...> - 2010-04-14 14:37:18
|
On 04/14/2010 06:49 AM, Geoffrey wrote: > Justin P. mattock wrote: >> On 04/13/2010 07:57 AM, Geoffrey wrote: >>> Geoffrey wrote: >>>> Anyone out there running 64 bit OS on a macbook pro 4,1. I upgraded >>>> from 32 bit Red Hat EL 5.4 to 64 bit RHEL 5.4, then again to 64 bit >>>> RHEL >>>> 5.5, which is actually still in beta. I don't know if I lost the core >>>> in the 64 bit 5.4 or not. I see the following from dmesg: >>>> >>>> SMP: Allowing 2 CPUs, 0 hotplug CPUs >>>> . >>>> . >>>> SMP alternatives: switching to UP code >>>> . >>>> . >>>> SMP motherboard not detected. >>>> . >>>> . >>>> SMP disabled >>> >>> Thought I'd update the list with a recent success: >>> >>> For whatever reason, I could not get the initial installation RHEL 5.4 >>> disk to even boot until I stumbled across a link that suggested the >>> following boot parms: >>> >>> acpi=force noapic irqpoll the acpi=force seems harmless, but the noapic scares me(you need this), In any case you should be able to bootup without any of these boot params which makes me wonder if this is a kernel issue and/or userspace >>> >>> I don't know why they worked, but they did. Once installed, I found >>> that I had to add them to my grub.conf to get the install to boot, but >>> all was happy. After moving to 64bit, I lost one core of my two core >>> processor. After much discussion with RH, I revisited these parameters >>> and found that by removing the noapic, parm, my macbook would still boot >>> and I got both cores. The weird thing is, I've tried every combination >>> of these parms before in order to remove them from my boot process in >>> the past, but my macbook would not boot. There must be something about >>> the latest RHEL 5.5 kernel that resolved that issue. >>> >>> The weird thing is, I did not have this issue on 32bit RHEL 5.4. That >>> is, I had both cores using all these parms. >>> >> >> this doesn't seem right.. >> you need apic etc... they must be >> doing something in there configs somewhere >> (COFNIG_SMP=y if set gives you both cores >> (but could be wrong)). > > No telling, all I know is I have a happy dual core system again with a > 64 bit OS. ;) > That's good news.. if you can, maybe try loading the latest kernel from git, then if the system can bootup without any of these boot params then you know there's a regression in the kernel somewhere(then if you have the time do a bisect, and report it to lkml, so there aware of the commit that causes this). Justin P. Mattock |
From: Geoffrey <li...@se...> - 2010-04-14 13:49:59
|
Justin P. mattock wrote: > On 04/13/2010 07:57 AM, Geoffrey wrote: >> Geoffrey wrote: >>> Anyone out there running 64 bit OS on a macbook pro 4,1. I upgraded >>> from 32 bit Red Hat EL 5.4 to 64 bit RHEL 5.4, then again to 64 bit RHEL >>> 5.5, which is actually still in beta. I don't know if I lost the core >>> in the 64 bit 5.4 or not. I see the following from dmesg: >>> >>> SMP: Allowing 2 CPUs, 0 hotplug CPUs >>> . >>> . >>> SMP alternatives: switching to UP code >>> . >>> . >>> SMP motherboard not detected. >>> . >>> . >>> SMP disabled >> >> Thought I'd update the list with a recent success: >> >> For whatever reason, I could not get the initial installation RHEL 5.4 >> disk to even boot until I stumbled across a link that suggested the >> following boot parms: >> >> acpi=force noapic irqpoll >> >> I don't know why they worked, but they did. Once installed, I found >> that I had to add them to my grub.conf to get the install to boot, but >> all was happy. After moving to 64bit, I lost one core of my two core >> processor. After much discussion with RH, I revisited these parameters >> and found that by removing the noapic, parm, my macbook would still boot >> and I got both cores. The weird thing is, I've tried every combination >> of these parms before in order to remove them from my boot process in >> the past, but my macbook would not boot. There must be something about >> the latest RHEL 5.5 kernel that resolved that issue. >> >> The weird thing is, I did not have this issue on 32bit RHEL 5.4. That >> is, I had both cores using all these parms. >> > > this doesn't seem right.. > you need apic etc... they must be > doing something in there configs somewhere > (COFNIG_SMP=y if set gives you both cores > (but could be wrong)). No telling, all I know is I have a happy dual core system again with a 64 bit OS. ;) > > Justin P. Mattock > -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson |
From: Justin P. m. <jus...@gm...> - 2010-04-13 19:47:21
|
On 04/13/2010 12:37 PM, cyberdork33 wrote: > This was a bug in Ubuntu awhile ago, but only affected 5,2 and newer hardware... I am not sure if it was ever resolved or not. Similar sounding issues though. > hmm.. I wonder if this is bisectable!? Justin P. Mattock |
From: cyberdork33 <cyb...@gm...> - 2010-04-13 19:37:35
|
This was a bug in Ubuntu awhile ago, but only affected 5,2 and newer hardware... I am not sure if it was ever resolved or not. Similar sounding issues though. On Apr 13, 2010, at 1:24 PM, Justin P. mattock wrote: > On 04/13/2010 07:57 AM, Geoffrey wrote: >> Geoffrey wrote: >>> Anyone out there running 64 bit OS on a macbook pro 4,1. I upgraded >>> from 32 bit Red Hat EL 5.4 to 64 bit RHEL 5.4, then again to 64 bit RHEL >>> 5.5, which is actually still in beta. I don't know if I lost the core >>> in the 64 bit 5.4 or not. I see the following from dmesg: >>> >>> SMP: Allowing 2 CPUs, 0 hotplug CPUs >>> . >>> . >>> SMP alternatives: switching to UP code >>> . >>> . >>> SMP motherboard not detected. >>> . >>> . >>> SMP disabled >> >> Thought I'd update the list with a recent success: >> >> For whatever reason, I could not get the initial installation RHEL 5.4 >> disk to even boot until I stumbled across a link that suggested the >> following boot parms: >> >> acpi=force noapic irqpoll >> >> I don't know why they worked, but they did. Once installed, I found >> that I had to add them to my grub.conf to get the install to boot, but >> all was happy. After moving to 64bit, I lost one core of my two core >> processor. After much discussion with RH, I revisited these parameters >> and found that by removing the noapic, parm, my macbook would still boot >> and I got both cores. The weird thing is, I've tried every combination >> of these parms before in order to remove them from my boot process in >> the past, but my macbook would not boot. There must be something about >> the latest RHEL 5.5 kernel that resolved that issue. >> >> The weird thing is, I did not have this issue on 32bit RHEL 5.4. That >> is, I had both cores using all these parms. >> > > this doesn't seem right.. > you need apic etc... they must be > doing something in there configs somewhere > (COFNIG_SMP=y if set gives you both cores > (but could be wrong)). > > Justin P. Mattock > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mactel-linux-users mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactel-linux-users |
From: Justin P. m. <jus...@gm...> - 2010-04-13 18:23:18
|
On 04/13/2010 07:57 AM, Geoffrey wrote: > Geoffrey wrote: >> Anyone out there running 64 bit OS on a macbook pro 4,1. I upgraded >> from 32 bit Red Hat EL 5.4 to 64 bit RHEL 5.4, then again to 64 bit RHEL >> 5.5, which is actually still in beta. I don't know if I lost the core >> in the 64 bit 5.4 or not. I see the following from dmesg: >> >> SMP: Allowing 2 CPUs, 0 hotplug CPUs >> . >> . >> SMP alternatives: switching to UP code >> . >> . >> SMP motherboard not detected. >> . >> . >> SMP disabled > > Thought I'd update the list with a recent success: > > For whatever reason, I could not get the initial installation RHEL 5.4 > disk to even boot until I stumbled across a link that suggested the > following boot parms: > > acpi=force noapic irqpoll > > I don't know why they worked, but they did. Once installed, I found > that I had to add them to my grub.conf to get the install to boot, but > all was happy. After moving to 64bit, I lost one core of my two core > processor. After much discussion with RH, I revisited these parameters > and found that by removing the noapic, parm, my macbook would still boot > and I got both cores. The weird thing is, I've tried every combination > of these parms before in order to remove them from my boot process in > the past, but my macbook would not boot. There must be something about > the latest RHEL 5.5 kernel that resolved that issue. > > The weird thing is, I did not have this issue on 32bit RHEL 5.4. That > is, I had both cores using all these parms. > this doesn't seem right.. you need apic etc... they must be doing something in there configs somewhere (COFNIG_SMP=y if set gives you both cores (but could be wrong)). Justin P. Mattock |