Hey on Centos 5 hfsplus.ko is part of the Kernel:
kernel-2.6.18-238.12.1.el5.x86_64 : The Linux kernel (the core of the Linux operating system) Repo : installed Matched from: Filename : /lib/modules/2.6.18-238.12.1.el5/kernel/fs/hfsplus/hfsplus.ko
doing a yum provides "*/hfsplus.ko" on CentOS 6 finds nothing.
What happened to hfsplus.ko on Centos 6?
Thanks,
Jerry
On 01/09/11 21:27, Jerry Geis wrote:
Hey on Centos 5 hfsplus.ko is part of the Kernel:
kernel-2.6.18-238.12.1.el5.x86_64 : The Linux kernel (the core of the Linux operating system) Repo : installed Matched from: Filename : /lib/modules/2.6.18-238.12.1.el5/kernel/fs/hfsplus/hfsplus.ko
doing a yum provides "*/hfsplus.ko" on CentOS 6 finds nothing.
What happened to hfsplus.ko on Centos 6?
Thanks,
Jerry
I don't know why Red Hat chose not to enable it in the kernel, but elrepo has it for you:
http://elrepo.org/linux/elrepo/el6/
Set up elrepo, and then do:
yum install kmod-hfsplus
On Thu, Sep 1, 2011 at 9:27 PM, Jerry Geis geisj@pagestation.com wrote:
Hey on Centos 5 hfsplus.ko is part of the Kernel:
kernel-2.6.18-238.12.1.el5.x86_64 : The Linux kernel (the core of the Linux operating system) Repo : installed Matched from: Filename : /lib/modules/2.6.18-238.12.1.el5/kernel/fs/hfsplus/hfsplus.ko
doing a yum provides "*/hfsplus.ko" on CentOS 6 finds nothing.
What happened to hfsplus.ko on Centos 6?
See if elrepo.org provide it.
I'm not all that excited about using another repo.
I changed the makefile to: obj-m += hfsplus.o
all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) bfind.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) bitmap.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) bnode.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) brec.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) btree.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) catalog.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) dir.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) extents.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) inode.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) ioctl.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) options.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) part_tbl.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) super.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) tables.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) unicode.o make -C /lib/modules/$(shell uname -r)/build M=$(PWD) wrapper.o
I extracted the source for 2.6.32.46 and found the fs/hfsplus directory. The above files are present. I changed the makefile to the above.
All the files compile - however I dont know how to make the hfsplus.ko What step does that take?
Thanks, ( I know most people just use the repo - but I can't do that).
jerry
On Thu, Sep 1, 2011 at 2:05 PM, Jerry Geis geisj@pagestation.com wrote:
I'm not all that excited about using another repo.
(snip)
I extracted the source for 2.6.32.46 and found the fs/hfsplus directory. The above files are present. I changed the makefile to the above.
All the files compile - however I dont know how to make the hfsplus.ko What step does that take?
You want to read through (and understand) this CentOS wiki article:
http://wiki.centos.org/HowTos/BuildingKernelModules
Thanks, ( I know most people just use the repo - but I can't do that).
I don't know why you "can't do that", but anyway, good luck building your own module.
Akemi
On 01/09/11 22:05, Jerry Geis wrote:
I'm not all that excited about using another repo.
I changed the makefile to: obj-m += hfsplus.o
<snip>
I extracted the source for 2.6.32.46 and found the fs/hfsplus directory. The above files are present. I changed the makefile to the above.
All the files compile - however I dont know how to make the hfsplus.ko What step does that take?
Thanks, ( I know most people just use the repo - but I can't do that).
The elrepo.org module uses the source code from the RHEL6 kernel and builds that rather than trying to backport a module from the upstream kernel. Remember, the source code is in the RHEL6 kernel, it's just not enabled by default.
Why don't you take a look at the elrepo SRPM and audit/rebuild it for your own use - a packaged solution is nearly always the correct solution (as KB pointed out recently elsewhere on this list), and by building a kABI-tracking kmod RPM package you will likely never need to update it again (otherwise you will need to recompile the module for every kernel update). Or you can use the SRPM as a template to create your own package using your kernel-2.6.32.46 source.
You should also consider filing a bug report upstream and make a case for hfsplus inclusion in the RHEL6 kernel. It's not unheard of for Red Hat to turn modules back on that they had previously disabled.
If you need any more specific help/assistance, pop over to the elrepo mailing lists and Akemi or I will be more than happy to assist you there.
Hope that helps.
On Friday, September 02, 2011 12:48:47 AM Ned Slider wrote:
You should also consider filing a bug report upstream and make a case for hfsplus inclusion in the RHEL6 kernel. It's not unheard of for Red Hat to turn modules back on that they had previously disabled.
There be dragons here.
Be very, very , careful with hfsplus on Linux. I have had more than one HFS+ non-journalled volume toasted by the Linux in-kernel driver.
There is a supported commerical solution for HFS+ for Linux made by Paragon. I've not put it under load yet (load being deleting a few hundred thousand files in a tree; that sort of operation on Fedora 12 (very similar kernel to RHEL6) was a 100% reproduceable, nonrecoverable, filesystem 'toast') but plan to soon enough.
While I haven't found the documentation for it due to the way kernel patches are now done, I suspect the data reliability problem is the reason upstream has disabled it. It works fine for read-only purposes, but I wouldn't use it for bidirectional data interchange. Or do all of your deletion of large trees of small files (like trees of source code) inside Mac OS.
Better for interchange is one of the two or three ext2/3/4 filesystem drivers for MacOS (I'm using the one from Paragon, and it works well, even with large ext4 volumes) or using NTFS and drivers for Mac OS for NTFS (again, I use the Paragon drivers which came with my Seagate 1TB external).
HFS+ is just barely supported under the in-kernel Linux driver last I looked, and may go away from kernel mainline at some point.
So, this is one case to be really careful.
On 06/09/11 16:34, Lamar Owen wrote:
On Friday, September 02, 2011 12:48:47 AM Ned Slider wrote:
You should also consider filing a bug report upstream and make a case for hfsplus inclusion in the RHEL6 kernel. It's not unheard of for Red Hat to turn modules back on that they had previously disabled.
There be dragons here.
Be very, very , careful with hfsplus on Linux. I have had more than one HFS+ non-journalled volume toasted by the Linux in-kernel driver.
There is a supported commerical solution for HFS+ for Linux made by Paragon. I've not put it under load yet (load being deleting a few hundred thousand files in a tree; that sort of operation on Fedora 12 (very similar kernel to RHEL6) was a 100% reproduceable, nonrecoverable, filesystem 'toast') but plan to soon enough.
While I haven't found the documentation for it due to the way kernel patches are now done, I suspect the data reliability problem is the reason upstream has disabled it. It works fine for read-only purposes, but I wouldn't use it for bidirectional data interchange. Or do all of your deletion of large trees of small files (like trees of source code) inside Mac OS.
Better for interchange is one of the two or three ext2/3/4 filesystem drivers for MacOS (I'm using the one from Paragon, and it works well, even with large ext4 volumes) or using NTFS and drivers for Mac OS for NTFS (again, I use the Paragon drivers which came with my Seagate 1TB external).
HFS+ is just barely supported under the in-kernel Linux driver last I looked, and may go away from kernel mainline at some point.
So, this is one case to be really careful.
Thanks for the heads up.
-
Akemi Yagi -
Jerry Geis -
Lamar Owen -
Lucian -
Ned Slider