| Re: Re: [Announce] Kernel RHEL6 testing 042stab054.1 [message #45834 is a reply to message #45831] |
Fri, 06 April 2012 00:58   |
jjs - mainphrame
Messages: 44
Registered: January 2012
|
Member |
|
|
However I am seeing an issue with the disk size inside the simfs-based CT.
In the vz conf files, all 3 CTs have the same diskspace setting:
[root@mrmber ~]# grep -i diskspace /etc/vz/conf/77*conf
/etc/vz/conf/771.conf:DISKSPACE="20000000:24000000"
/etc/vz/conf/773.conf:DISKSPACE="20000000:24000000"
/etc/vz/conf/775.conf:DISKSPACE="20000000:24000000"
But in the actual CTs the one on simfs reports a significantly smaller disk
space than it did under previous kernels:
[root@mrmber ~]# for i in `vzlist -1`; do echo $i; vzctl exec $i df; done
771
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/ploop0p1 23621500 939240 21482340 5% /
none 262144 4 262140 1% /dev
773
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/simfs 6216340 739656 3918464 16% /
none 262144 4 262140 1% /dev
775
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/ploop1p1 23628616 727664 21700952 4% /
none 262144 4 262140 1% /dev
[root@mrmber ~]#
Looking in dmesg shows this:
[ 2864.563423] CT: 773: started
[ 2866.203628] device veth773.0 entered promiscuous mode
[ 2866.203719] br0: port 3(veth773.0) entering learning state
[ 2868.302300] ploop1:
[ 2868.329086] GPT:Primary header thinks Alt. header is not at the end of
the disk.
[ 2868.329099] GPT:47999999 != 48001023
[ 2868.329104] GPT:Alternate GPT header not at the end of the disk.
[ 2868.329111] GPT:47999999 != 48001023
[ 2868.329115] GPT: Use GNU Parted to correct GPT errors.
[ 2868.329128] p1
[ 2868.333608] ploop1:
[ 2868.337235] GPT:Primary header thinks Alt. header is not at the end of
the disk.
[ 2868.337247] GPT:47999999 != 48001023
[ 2868.337252] GPT:Alternate GPT header not at the end of the disk.
[ 2868.337258] GPT:47999999 != 48001023
[ 2868.337262] GPT: Use GNU Parted to correct GPT errors.
I'm assuming that this disk damage occurred under the buggy stab54.1
kernel. I could destroy the container and create a replacement but I'd like
to make believe, for the time being, that it's valuable. Just out of
curiosity, what tools exist to fix this sort of thing? The log entries
recommend gparted, but I suspect I may not have much luck from inside the
CT with that. If this were PVC, there would obviously be more choices. You
thoughts?
Joe
On Thu, Apr 5, 2012 at 3:17 PM, jjs - mainphrame <jjs@mainphrame.com> wrote:
> I'm happy to report that stab54.2 fixes the kernel panics I was seeing in
> stab54.1 -
>
> Thanks for the serial console reminder, I'll work on setting that up...
>
> Joe
>
> On Thu, Apr 5, 2012 at 3:47 AM, Kir Kolyshkin <kir@openvz.org> wrote:
>
>> On 04/05/2012 08:48 AM, jjs - mainphrame wrote:
>>
>>> Kernel stab53.5 was very stable for me under heavy load but with
>>> stab54.1 I'm seeing hard lockups - the Alt-Sysrq keys don't work, only the
>>> power or reset button will do the trick.
>>>
>>> I don't have a serial console set up so I'm not able to capture the
>>> kernel panic message and backtrace. I think I'll need to get that set up in
>>> order to go any further with this.
>>>
>>> 054.2 might fix the issue you are having. It is being uploaded at the
>> moment...
>>
>> Anyway, it's a good idea to have serial console set up. It greatly
>> improves chances to resolve kernel bugs. http://wiki.openvz.org/Remote_**
>> console_setup <http://wiki.openvz.org/Remote_console_setup> just in case.
>> ______________________________**_________________
>> Users mailing list
>> Users@openvz.org
>> https://openvz.org/mailman/**listinfo/users<https://openvz.org/mailman/listinfo/users>
>>
>
>
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
