On the other front I thought it would be nice to have Ext4 support. After looking through the source code I think it should not be too hard.
First I could successfully compile the rEFInd using Tianocore/EDKII on Ubuntu 12.10. I already did a bit cleanup work in the filesystem directory and successfully ran the included ext2 driver on POSIX. This way it should be much easier to create/extend the driver to support ext4. Are there any plans how to implement the ext4 support? I'm willing to tackle this, but not sure if I'm going to have the time for it...
I would like to implement an ext4 driver, but I haven't had the time to do it. If you're familiar enough with ext4 internals to be willing to tackle the job, or if you'd like to learn, then any contributions you can make would be most welcome.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good news, I already successfully read a file from a Ext4 partition with Extents support enabled! As far as I can tell there are two main features we have to support, extents and flex_bg, these are also enabled by default when creating a new FS. To do the 64-Bit support right, I would need ajustments to the core of the FS driver....
Regards
Stefan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One thing I noticed while testing: Using the refind_linux.conf only works for Linux kernels inside the EFI partition, right? I could not boot my kernel from /boot when using a refind_linux.conf in /boot. Maybe you should point that out in your documentation.
Regards,
Stefan
Last edit: Roderick W. Smith 2012-12-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Excellent! I've just grabbed the code and have tested it. I successfully booted a machine in VirtualBox from ext4fs, too, so it's looking good at the moment. I'd love to hear anybody else's comments on this. If you're not comfortable grabbing source code with git and compiling it yourself, I've put 32-bit and 64-bit binaries here:
Be sure to use the binary for your architecture! I've not tested with this one, but with other drivers, loading a driver for the wrong architecture hangs some systems!
One concern: You say that you were unable to use a refind_linux.conf file, but I had no problem with that. Could you please elaborate on what didn't work? For instance, did the kernel not appear in the list? (You've got to uncomment the also_scan_dirs line and add boot to it in refind.conf to fix this.) Did the options in the file not appear in your options list? (Perhaps the file wasn't named correctly, or maybe there's a bug in the driver that's causing some files to not appear -- you could use a shell to look for the file to test this.)
A query: I noticed that your ext4fs driver picked up an ext2 filesystem I also had on my test system. Do you intend for this driver to be used exclusively for ext4fs, or could it be considered a replacement for the current ext2fs driver? (I'll probably distribute both of them initially, no matter what, but if it handles all the ext* filesystems I'll probably eventually retire the ext2fs driver.)
Assuming I don't run into problems in my tests over the next day or two, and assuming that nobody else reports problems, I'll include this driver in the next release of rEFInd.
(A minor point: Your link was broken because the forum's auto-formatting included the period at the end of your sentence in the URL. I took the liberty of correcting that problem for the benefit of others.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes the driver is fully backward compatible, I also tested that with ext2/ext3. The ext-Filesystems are all read backward compatible, they impose new features with flags. A driver can only look at those flags and decide weather he is capable reading that partitions filesystem disk layout.
The new ext4 drivers supports the options extents and flex_bg which are usually set when someone creates a new ext4 fs.
However, the driver does not support filesystem beyond 16TiB (2^32 blocks). This would need to alter all variables which address blocks inside the fsw driver (and those affect the other fs drivers). Ext4 supports by default 32 bit block addressing and when the option 64bit is turned on a maximum of 48 bit (The driver however refuses to read a filesystem with this option turned on).
There is another flag which changes the on disk layout: meta_bg. This option is needed for filesystems bigger than 256TiB. But it also distributes metadata accross the disk (which should improve seek times). Again, currently the driver refuses to read such a filesystem. Since its easy to implement I think I'm going to add full support for that option. This option can be set for ext2/ext3 filesystems too. As soon as the new driver knows this option, he will be capable to read more ext2/ext3 fs than the old one. So yes, I think we should retire the old ext2 driver once the new is mature.
Most of this stuff won't affect a common user, but might be interesting if it doesn't work somewhere.
Filesytem features can be listed using dumpe2fs
dumpe2fs /dev/sda2 | grep features
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the information. I've added the key points to the drivers.html file in the documentation. That will go live with the next release (tonight, I expect).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just pushed meta_bg support to my repository. This feature can be present in ext2/ext3 filesystems as well, its supported for all filesystems. I did some testing "on the desktop" (in posix mode). I successfully could read big bucks bunny through disk images with different feature combinations.
I think this is the last piece which can easily be done. However, I don't believe there is an use for the 64-Bit options for system partitions...
Thanks for your continued work on this. I've added your changes back to the main rEFInd git repository. I expect to make a 0.6.1 release soon -- possibly later today, or certainly this weekend.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the other front I thought it would be nice to have Ext4 support. After looking through the source code I think it should not be too hard.
First I could successfully compile the rEFInd using Tianocore/EDKII on Ubuntu 12.10. I already did a bit cleanup work in the filesystem directory and successfully ran the included ext2 driver on POSIX. This way it should be much easier to create/extend the driver to support ext4. Are there any plans how to implement the ext4 support? I'm willing to tackle this, but not sure if I'm going to have the time for it...
My repository:
https://github.com/falstaff84/rEFInd
Regards,
Stefan
I would like to implement an ext4 driver, but I haven't had the time to do it. If you're familiar enough with ext4 internals to be willing to tackle the job, or if you'd like to learn, then any contributions you can make would be most welcome.
Good news, I already successfully read a file from a Ext4 partition with Extents support enabled! As far as I can tell there are two main features we have to support, extents and flex_bg, these are also enabled by default when creating a new FS. To do the 64-Bit support right, I would need ajustments to the core of the FS driver....
Regards
Stefan
That's very impressive progress! I look forward to seeing your code when it's ready.
Hi,
Just bootet the first time using my Ubuntu root fs formatted with ext4! You can pull the code from https://github.com/falstaff84/rEFInd.
One thing I noticed while testing: Using the refind_linux.conf only works for Linux kernels inside the EFI partition, right? I could not boot my kernel from /boot when using a refind_linux.conf in /boot. Maybe you should point that out in your documentation.
Regards,
Stefan
Last edit: Roderick W. Smith 2012-12-16
Excellent! I've just grabbed the code and have tested it. I successfully booted a machine in VirtualBox from ext4fs, too, so it's looking good at the moment. I'd love to hear anybody else's comments on this. If you're not comfortable grabbing source code with git and compiling it yourself, I've put 32-bit and 64-bit binaries here:
http://www.rodsbooks.com/ext4_efi_driver.zip
Be sure to use the binary for your architecture! I've not tested with this one, but with other drivers, loading a driver for the wrong architecture hangs some systems!
One concern: You say that you were unable to use a
refind_linux.conffile, but I had no problem with that. Could you please elaborate on what didn't work? For instance, did the kernel not appear in the list? (You've got to uncomment thealso_scan_dirsline and addbootto it inrefind.confto fix this.) Did the options in the file not appear in your options list? (Perhaps the file wasn't named correctly, or maybe there's a bug in the driver that's causing some files to not appear -- you could use a shell to look for the file to test this.)A query: I noticed that your ext4fs driver picked up an ext2 filesystem I also had on my test system. Do you intend for this driver to be used exclusively for ext4fs, or could it be considered a replacement for the current ext2fs driver? (I'll probably distribute both of them initially, no matter what, but if it handles all the ext* filesystems I'll probably eventually retire the ext2fs driver.)
Assuming I don't run into problems in my tests over the next day or two, and assuming that nobody else reports problems, I'll include this driver in the next release of rEFInd.
(A minor point: Your link was broken because the forum's auto-formatting included the period at the end of your sentence in the URL. I took the liberty of correcting that problem for the benefit of others.)
Yes the driver is fully backward compatible, I also tested that with ext2/ext3. The ext-Filesystems are all read backward compatible, they impose new features with flags. A driver can only look at those flags and decide weather he is capable reading that partitions filesystem disk layout.
The new ext4 drivers supports the options extents and flex_bg which are usually set when someone creates a new ext4 fs.
However, the driver does not support filesystem beyond 16TiB (2^32 blocks). This would need to alter all variables which address blocks inside the fsw driver (and those affect the other fs drivers). Ext4 supports by default 32 bit block addressing and when the option 64bit is turned on a maximum of 48 bit (The driver however refuses to read a filesystem with this option turned on).
There is another flag which changes the on disk layout: meta_bg. This option is needed for filesystems bigger than 256TiB. But it also distributes metadata accross the disk (which should improve seek times). Again, currently the driver refuses to read such a filesystem. Since its easy to implement I think I'm going to add full support for that option. This option can be set for ext2/ext3 filesystems too. As soon as the new driver knows this option, he will be capable to read more ext2/ext3 fs than the old one. So yes, I think we should retire the old ext2 driver once the new is mature.
Most of this stuff won't affect a common user, but might be interesting if it doesn't work somewhere.
Filesytem features can be listed using dumpe2fs
dumpe2fs /dev/sda2 | grep features
Thanks for the information. I've added the key points to the
drivers.htmlfile in the documentation. That will go live with the next release (tonight, I expect).Just pushed meta_bg support to my repository. This feature can be present in ext2/ext3 filesystems as well, its supported for all filesystems. I did some testing "on the desktop" (in posix mode). I successfully could read big bucks bunny through disk images with different feature combinations.
I think this is the last piece which can easily be done. However, I don't believe there is an use for the 64-Bit options for system partitions...
https://github.com/falstaff84/rEFInd
And now, btrfs... ;-)
Thanks for your continued work on this. I've added your changes back to the main rEFInd git repository. I expect to make a 0.6.1 release soon -- possibly later today, or certainly this weekend.