A shit hole in xen-sources-2.6.29

It's a record for myself to memo.

In 2.6.29-r4, there is a different in net device 'Intel Corporation 82573V Gigabit Ethernet', which is used to stand by driver 'e1000', but right now it has changed to 'e1000e'. Moreover, it works and treats net device up, although crush down by "RTNETLINK answers: Cannot allocate memory".

After that, I've tried all day for finger out this issue, nevertheless, it doesn't meliorate. Well, I'm done and through buy it. In quick step is choose next version of kernel which is beta version, and then everything seems fine and no strange error msg.

There is one more tricky problem while compiling domU in beta kernel, which is specific option for CPU, which must enable "CONFIG_HOTPLUG_CPU" to keep proceeding.

Ref: claudineimatos.com

XEN wtihin x86_64

I Got the shit about sumversion.c 'PATH_MAX' undeclared

And then, there is a article shown how to fix it out.

Just simply add a content , #include <"limits.h">, to define it.

After that shit, I could keep go through compile the xen.


PS. In coding to unknow rules of Blogger,

it couldn't insert the word "limits.h" whithout double quotes.

Thus, please remove the double quotes while using it into code.


Ref: 编译内核 scripts/mod/sumversion.c PATH_MAX undeclared

XEN + LVM2

Recently, my company was set up a sys with xen and bound on LVM2.
However, I got the problem while I resizing the domU by resize2fs.
I could not see the extending size in domU by "df -h", and I even have resized the device of block on dom0.
I figure it out after trying plenty of times to reboot and fix the filesystem.
Okeydoke, The method to resolve resize is as below.

step1:
lvextend logical volume
step2:
resize -f /dev/volume_group/device_point
step3:
reboot domU
step4:
@domU doing " resize /dev/sda1"