W dniu 28.10.2009 06:53, Maxwell Smart pisze:
Nah, 32bit here.
For reference.
* rpm -qa | grep kernel*
kernel-2.6.18-128.7.1.el5 ne with a x86_64 toaster actually running a
newer kernel? Please chime in.
[...]
I have CentOS 5.4 and there is no problem to mount sandbox:
8--
[r...@srv ~]#
Eric Shubert wrote:
Wait a sec. I just noticed that this is x86_64. Doh!
The FUSE unionfs hasn't been tested on that arch yet.
That explains why fuse doesn't necessarily work.
Ben and CJ, are your problem toasters 64-bit as well??
Is anyone with a x86_64 toaster actually running a newer
W dniu 28.10.2009 08:01, Wim Godden pisze:
Regardless of the architecture, Grub should load the newer kernel,
right ?
If someone can tell me how to get that fixed, I can test the
toast-ability of x86_64 ;-)
GRUB loads what you want to load, default kernel shown in line:
default=
Eric Shubert wrote:
Wait a sec. I just noticed that this is x86_64. Doh!
The FUSE unionfs hasn't been tested on that arch yet.
That explains why fuse doesn't necessarily work.
Ben and CJ, are your problem toasters 64-bit as well??
Is anyone with a x86_64 toaster actually running a newer
Wim Godden wrote:
Eric Shubert wrote:
Wait a sec. I just noticed that this is x86_64. Doh!
The FUSE unionfs hasn't been tested on that arch yet.
That explains why fuse doesn't necessarily work.
Ben and CJ, are your problem toasters 64-bit as well??
Is anyone with a x86_64 toaster actually
Message-
From: news [mailto:n...@ger.gmane.org] On Behalf Of Eric Shubert
Sent: October-28-09 9:21 AM
To: qmailtoaster-list@qmailtoaster.com
Subject: [qmailtoaster] Re: qtp-newmodel fails on FUSE
Wim Godden wrote:
Eric Shubert wrote:
Wait a sec. I just noticed that this is x86_64. Doh!
The FUSE
Wim Godden wrote:
Jake Vickers wrote:
Make sure you do a full yum upgrade first, and then a reboot to
activate the new kernel. Then run qtp-newmodel again.
If that still doesn't work, post the output of these commands:
qtp-whatami
uname -a
rpm -qa | grep kernel
yum upgrade and reboot
Maxwell Smart wrote:
He and I are having the same issue. We are not booting to the latest
kernel, but our GRUB file is correct.
I don't recall seeing Ben's menu.lst file, so I wouldn't jump to this
conclusion.
It's also possible that a link to menu.lst isn't quite right. A 'normal'
Eric Shubert wrote:
Maxwell Smart wrote:
He and I are having the same issue. We are not booting to the latest
kernel, but our GRUB file is correct.
I don't recall seeing Ben's menu.lst file, so I wouldn't jump to this
conclusion.
Fair enough, but his symptoms are identical. Stuck on the
Maxwell Smart wrote:
Eric Shubert wrote:
Maxwell Smart wrote:
He and I are having the same issue. We are not booting to the latest
kernel, but our GRUB file is correct.
I don't recall seeing Ben's menu.lst file, so I wouldn't jump to this
conclusion.
Fair enough, but his symptoms are
The grub commands I posted earlier should fix up a broken MBR, but
that's risky to do on a production server.
Yeah, my feelings exactly and if it's working for the time being I'm not
arguing.
Sounds like replacement is a wise choice. I've really no idea how it
came to be in the state it's
Eric Shubert wrote:
Please post the output of
# df -h
# cat /etc/fstab
# cat /boot/grub/menu.lst
and we'll see if we can't get your menu.lst (aka grub.conf) fixed up.
/root df -h
FilesystemSize Used Avail Use% Mounted on
/dev/sda1 141G 5.8G 128G 5% /
tmpfs
Wim Godden wrote:
Jake Vickers wrote:
Make sure you do a full yum upgrade first, and then a reboot to
activate the new kernel. Then run qtp-newmodel again.
If that still doesn't work, post the output of these commands:
qtp-whatami
uname -a
rpm -qa | grep kernel
yum upgrade and reboot
Nah, 32bit here.
For reference.
* rpm -qa | grep kernel*
kernel-2.6.18-128.7.1.el5
kernel-devel-2.6.18-164.el5
kernel-2.6.18-92.1.13.el5
kernel-2.6.18-128.2.1.el5
kernel-2.6.18-128.4.1.el5
kernel-devel-2.6.18-128.4.1.el5
kernel-devel-2.6.18-128.7.1.el5
kernel-headers-2.6.18-164.el5
14 matches
Mail list logo