Hello,
We use Norton Ghost, running in a PXE booted DOS, to handle Windows XP images.
The images are stored on a samba share on our CentOS 6 server.
This has worked without any problems for years.
After kernel 2.6.32-279* it has stopped working.
The symptom is that if I boot in DOS, and do:
net use x: \myserver\ghostimages dir x:
I get an infinite loop where the first file name is listed again and again.
Going back to kernel-2.6.32-220.17.1 on the server fixes the problem.
The problem exist with kernel-2.6.32-279, kernel-2.6.32-279.2.1, and kernel-2.6.32-279.5.1.
Samba is version samba-3.5.10-125, the server is x86_64.
Where should I look for a solution to that problem on the newer kernels?
Mogens
On 08/15/2012 06:25 AM, Mogens Kjaer wrote:
Hello,
We use Norton Ghost, running in a PXE booted DOS, to handle Windows XP images.
The images are stored on a samba share on our CentOS 6 server.
This has worked without any problems for years.
After kernel 2.6.32-279* it has stopped working.
The symptom is that if I boot in DOS, and do:
net use x: \myserver\ghostimages dir x:
I get an infinite loop where the first file name is listed again and again.
Going back to kernel-2.6.32-220.17.1 on the server fixes the problem.
The problem exist with kernel-2.6.32-279, kernel-2.6.32-279.2.1, and kernel-2.6.32-279.5.1.
Samba is version samba-3.5.10-125, the server is x86_64.
Where should I look for a solution to that problem on the newer kernels?
Mogens
I would start in:
rpm -q --changelog kernel-2.6.32-279 | less
and look at everything smb or cifs between the last version that works and your version to see if you can tell what update might be causing the issue.
On 08/15/2012 06:25 AM, Mogens Kjaer wrote:
Hello,
We use Norton Ghost, running in a PXE booted DOS, to handle Windows XP images.
The images are stored on a samba share on our CentOS 6 server.
This has worked without any problems for years.
After kernel 2.6.32-279* it has stopped working.
The symptom is that if I boot in DOS, and do:
net use x: \myserver\ghostimages dir x:
I get an infinite loop where the first file name is listed again and again.
Going back to kernel-2.6.32-220.17.1 on the server fixes the problem.
The problem exist with kernel-2.6.32-279, kernel-2.6.32-279.2.1, and kernel-2.6.32-279.5.1.
Samba is version samba-3.5.10-125, the server is x86_64.
Where should I look for a solution to that problem on the newer kernels?
Mogens
I don't this would impact it, but if the underlying file system of the samba machine's file system is ext4 and if it is a 64-bit machine, it might.
http://joejulian.name/blog/glusterfs-bit-by-ext4-structure-change/
On 08/15/2012 10:08 PM, Johnny Hughes wrote:
I don't this would impact it, but if the underlying file system of the samba machine's file system is ext4 and if it is a 64-bit machine, it might.
http://joejulian.name/blog/glusterfs-bit-by-ext4-structure-change/
I guess this must be:
# rpm -q --changelog kernel-2.6.32-279.el6|fgrep hash|fgrep ext4 - [fs] ext4: return 32/64-bit dir name hash according to usage type (J. Bruce Fields) [813070]
Is the 813070 number a bugzilla entry? I get an access denied when trying to read it.
Is there an easy way to remove this patch to test it (in a test environment, the main server is back on the old kernel)?
In the Good Old Days redhat kernel SRPMS were a vanilla kernel plus 1.0e+117 patches, now it doesn't look so simple.
Mogens
On 08/16/2012 01:30 AM, Mogens Kjaer wrote:
On 08/15/2012 10:08 PM, Johnny Hughes wrote:
I don't this would impact it, but if the underlying file system of the samba machine's file system is ext4 and if it is a 64-bit machine, it might.
http://joejulian.name/blog/glusterfs-bit-by-ext4-structure-change/
I guess this must be:
# rpm -q --changelog kernel-2.6.32-279.el6|fgrep hash|fgrep ext4
- [fs] ext4: return 32/64-bit dir name hash according to usage type (J.
Bruce Fields) [813070]
Is the 813070 number a bugzilla entry? I get an access denied when trying to read it.
Is there an easy way to remove this patch to test it (in a test environment, the main server is back on the old kernel)?
In the Good Old Days redhat kernel SRPMS were a vanilla kernel plus 1.0e+117 patches, now it doesn't look so simple.
No easy way at all to do it.
The only way to do it is with RHN access and then you can look at individual commits to the version control system and try to back one out.
-
Johnny Hughes -
Mogens Kjaer