How to fix Grub4DOS Error 13, wee 13>, due to 64-bit Ext4

[jd7654]

This How-To is to address an issue when trying to use Grub4DOS with newer systems with 64-bit Ext4 partitions, typically created when another newer Linux distro is installed.

This is an issue with older bootloaders like Grub4DOS (0.4.4), Grub Legacy (0.97) and Syslinux (6.03) not being compatible with this relatively new filesystem implementation of 64-bit Ext4. The current Grub2 (aka simply, Grub) is compatible with this newer filesystem. Installing Grub4DOS onto 64-bit Ext4 results in the Error 13 and bootloader failure.

Note that this has nothing to do with a 64-bit processor, or a 64-bit operating system. It is a separate issue with the filesystem itself being 64-bit, as opposed to 32-bit in previous versions. While Puppy booted live can read from a 64-bit Ext4 partition, the Grub4DOS bootloader itself cannot.

Wrote about it previously:
http://www.murga-linux.com/puppy/viewto ... 756#945756

This is a relatively new issue that came up within the last year, and Puppy may have to address it at some point. Has to do with 64-bit Ext4, which is different from 64-bit Linux. Started with 1.43 version of e2fsprogs, which came in with Ubuntu 16.10. Syslinux posted some info about it:
http://www.syslinux.org/wiki/index.php?title=Filesystem
Quoting part of the release notes of version 1.43 of e2fsprogs (May 17, 2016):
Mke2fs will now create file systems with the metadata_csum and 64bit features enabled by default.
Users should rather (manually) disable the 64bit feature in the mke2fs command when creating / formatting a boot volume with ext4; otherwise, the bootloader (as of version 6.03) will fail.

Technically, any distro released after May 2016 could have its installer creating 64-bit Ext4 partitions. Depends if their programs are all up to date.(check Distrowatch table) This will be more and more of a problem as new users try to install Puppy on top of newer distros with this feature enabled. Luckily was not in Ubuntu 16.04LTS which is so widespread, but appears to have gotten in with 16.10. I noticed it on an Arch derivative, but they are more up to date than others.

Depending on how you have Grub4DOS installed, you may see different errors.

If loaded to MBR, you will see a failure in the stage 1 of the bootloader as it cannot read the stage 2 on the 64-bit Ext4 partition:
wee 0> find --seek-root /grldr
(0x80,0)
wee 0> /grldr
wee 13>

If Grub4DOS is installed and working on another partition, you will see the error in stage 2 as it tries to boot Puppy/Linux on the 64-bit Ext4 partition:
Error 13: Invalid or unsupported exectuable format

To still use Grub4DOS with this partition, you will need to remove the 64-bit feature from the Ext4 filesystem.

Unfortunately, Puppy does not have the version of e2fsprogs 1.43 or greater that is required to fix the problem. But you can download and compile from source directly:
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git

EDIT: For a quick fix, here is a link to .pet packages for current Puppy 6 Slacko and Tahr.
(disclaimer: not all implications of using updated e2fsprogs has been tested, best to use only as a temporary fix for this issue)

Another easy way to get the right version is to download the Gparted Live CD ISO, version higher than 0.26 has e2fsprogs >=1.43:
http://gparted.org/download.php
And then you can use the e2fsprogs included on the disc.
Or you can boot a newer Linux distro/disc like the one which created the partition. Also see addendum below for rescue disc option.

From booted Gparted Live desktop, open a terminal and do the following:
(note: in Gparted Live examples below, all commands preceded by "sudo" prefix)

First, check partition for 64-bitness with tune2fs -l (partition) command::

Code: Select all

user@debian:~$ sudo tune2fs -l /dev/sda1
tune2fs 1.43.1 (08-Jun-2016)
Filesystem volume name:   <none>
...
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
...
Checksum:                 0x65dd14e3

Note the 64bit in Filesystem features list above.

In order to change this, you must have e2fsprogs version 1.43 or greater, where resize2fs will have "-s" option as below:

Code: Select all

user@debian:~$ sudo resize2fs
resize2fs 1.43.1 (08-Jun-2016)
Usage: resize2fs [-d debug_flags] [-f] [-F] [-M] [-P] [-p] device [-b|-s|new_size] [-z undo_file]

Then to perform the fix, issue resize2fs -s (partition) command to remove 64-bit feature:

Code: Select all

user@debian:~$ sudo resize2fs -s /dev/sda1
resize2fs 1.43.1 (08-Jun-2016)
Converting the filesystem to 32-bit.
The filesystem on /dev/sda1 is now 2883328 (4k) blocks long.

You may get a warning to do e2fsck first, so do that and then issue resize2fs after that.

That's it! Grub4DOS should now be working on your updated 32-bit Ext4 partition. Only takes a few seconds and existing data is unaffected.


Addendum:

If you do not want to use Grub4DOS and want to revert to your Linux Grub2 bootloader, you can use a rescue disc to boot into your other Linux. One good one is Super Grub2 Disk. Very tiny download ISO file that you can burn to CD or write to USB. You don't have to modify/change anything, it just looks for and boots any OS it can find. Then you can repair OS from within itself.

Download Super Grub2 Disk, recommended download ISO:
http://www.supergrubdisk.org/category/d ... sk-stable/

Write to flash. For Windows, cannot use Rufus. Direct write with something like ImageUSB:
http://osforensics.com/tools/write-usb-images.html


EDIT: A newer Chinese fork of Grub4DOS by chenall has been modified to address 64-bit Ext4, but not yet fully integrated with latest Puppy.

[bigpup]

jd7654,

Thanks for this how to!!!

Could you please go to the Woof-CE on Github and submit a new pull request on this issue?
https://github.com/puppylinux-woof-CE/woof-CE
This needs to get some fix put into Puppy.
Woof-CE is the place to do it.
Making a pull request will get the people working on Woof-CE knowing about this issue.

You may be able to get involved in figuring out what needs to be done in Woof-CE.

Thanks!!

[mikeslr]

Ditto bigpup.

Thanks, jd7654, for taking the time to clear up what was going wrong and how to handle it.

One other thing for anyone who is ambitious, 'though I'm not sure a "one size fits all" is possible. Well, two sizes --one 32-bit, one 64-bit. Perhaps someone could create pets of e2fsprogs version 1.43 which could be installed into Puppies being booted from USB-Keys, eliminating the need to download gparted or resort to some other Distro.


mikesLr

[jd7654]

One other thing for anyone who is ambitious, 'though I'm not sure a "one size fits all" is possible. Well, two sizes --one 32-bit, one 64-bit. Perhaps someone could create pets of e2fsprogs version 1.43 which could be installed into Puppies being booted from USB-Keys, eliminating the need to download gparted or resort to some other Distro.

Yeah, that might be a good idea. I never even tried.(compile >=1.43 e2fsprogs on older Pups) Could make official release Tahr and Slacko even have the power to fix.
EDIT: Did a quick test and current e2fsprogs version 1.43.4 compiles fine in Puppy 6 official Slacko and Tahr.

Also note from syslinux link above:
- To manually disable the "64bit" feature when creating ext4 volumes, use -O ^64bit in the mke2fs (or equivalent) command. That is, an hyphen, immediately followed by an upper-case letter "O", a space character, the caret "^" symbol, followed by "64bit" (no hyphen).
In some cases, a backslash character before the caret might be needed: -O \^64bit
- In resize2fs, the -s parameter (that is, an hyphen followed by a lower-case letter "s") disables the "64bit" feature of an already-created filesystem volume, if its size allows it.

Not all newer Linux and not all Gparted may cause this issue. it all depends if they use that -O ^64bit or not in the mke2fs command, or like newest Dog Linux does, excludes that option from the list of Filesystem features. If Puppy were given the updated e2fsprogs, some other changes may be required as well to prevent issue popping up.

[jd7654]

Could you please go to the Woof-CE on Github and submit a new pull request on this issue?

I'm not familiar with that, and not sure if a fix request in Woof-CE is needed?

I just did a quick check in vbox of the latest Slacko-700 RC3 (6.9.9.9) and although it does create the boot problem, it also has the ability to fix it.
So it could be fixed with documentation and awareness of the 64-bit Ext4 issue. And since Slacko 700 has e2fsprogs 1.43.1 included from Slackware 14.2, it can perform the fix above with the resize2fs -s command.(I verified)

But maybe it could fall in Woof-CE to modify the Grub4DOS config installer, to check for the existence of 64-bit Ext4, and pop up warning to offer fix to change to 32-bit otherwise boot will fail. I would imagine that wouldn't be too hard to do, but I never looked at the code. Or the big fix would be to change to offer Grub2 also, but that would be a big undertaking, or is it already in development? I don't know.

[fredx181]

To add to the excellent first post info:

I experimented by formatting my USB /dev/sdb2 to this "ext4 64-bit" format on purpose.
Then I checked:

Code: Select all

tune2fs -l /dev/sdb2

And got:

Code: Select all

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

Note the "64bit" above.
As expected, I got the error when trying to boot from sdb2 (with grub4dos MBR installed)

Code: Select all

 wee 0> find --seek-root /grldr
(0x80,0)
wee 0> /grldr
wee 13>

Ok, then I booted Upup Bionic (from another drive) (it has e2fsprogs 1.44, should be 1.43 or higher) and ran:

Code: Select all

resize2fs -s /dev/sdb2

Got a warning to do e2fsck , I checked again with tune2fs and nothing changed (still the 64bit in Filesystem features)

So... very important to do e2fsck

After I did that, I ran again:

Code: Select all

resize2fs -s /dev/sdb2

And got:

Code: Select all

Converting the filesystem to 32-bit.
The filesystem on /dev/sdb2 is now .... ....

Checked again:

Code: Select all

tune2fs -l /dev/sdb2

And shows without the 64bit:

Code: Select all

	Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

And booted my USB and grub4dos works again.

Fred

[Mike Walsh]

@ jd7654:-

Admittedly, this is a problem I don't personally have issues with. I run Puppy almost exclusively on the big old Compaq desktop, always from ext3, and always with a save-file.

The one 'alternate' Linux distro I do run on the Compaq, AntiX, was installed to a separate small SSD, allowed to install itself however it wanted, and allowed to install GRUB2 to the MBR of that drive.

Grub4DOS then chainloads across to GRUB2 on that drive. I did things this way because

a) I'd been hearing about this 'wee' issue with 64-bit ext4, and
b) I had a spare SSD kicking around from when I upgraded to a larger capacity model on the old Dell laptop. Chain-loading neatly 'side-steps' the whole problem.

My set-up works very well for me.

However; thanks for investigating this, because I know it's been bugging a fair number of folks in recent months. Well done!

Much appreciated. Cheers!


Mike.

[mikeslr]

Hi fred,

Great discovery. Thought I'd give it Post Title a Search-Engine might find. http://murga-linux.com/puppy/viewtopic. ... 51#1013051.

And Mike, nice work-around if one isn't compelled to place Puppies on the same drive as another Linux: post just above this.

[musher0]

Hello, bunch.

Not sure if this should be put here or in a Grub4Dos thread, but here goes:

-- I tried to compile the latest Grub4Dos from the chenall site (they published it
towards the middle of last month), but it keeps telling me that it needs an objcopy
utility from binutils, an objcopy that is "absolute" or something?

To comply with their message, I compiled the entire latest binutils (v.3.32), even if
the one in DPupBuster is an ok version for this compile. Installed objcopy from v.
3.32 and retried compiling the new Grub4Dos. Nope, nothing doing, same message.

So if ttuuxxx is reading this, with his long and witty experience in compiling: can
you get us out of this rut by compiling the latest Grub4Dos (v. 4.46a-something) ?

I write "rut" and I mean "rut": a Puppy-ist formats his partitions in ext4 thinking it
is the thing to do (and it is, for stability, etc. !) and then recopies everything.

And poof! just like that, he can't access half the Pups in his grub4dos menu.lst
anymore. Not good for our ratings!

Or someone with similar compiling experience, of course. Many TIA.

Judging from what was said above, the people at chenall have solved this bug in
their latest Grub4Dos? Or I want it solved so much that I see it in my head!?
("Gee, musher0, you should get more sleep...")

BFN.

[jd7654]

Judging from what was said above, the people at chenall have solved this bug in
their latest Grub4Dos?

Yeah, chenall fixed it a long time ago, before date of first post. I've been running grub4dos 0.4.6a for over a year and it boots into 64-bit ext4 just fine. I didn't bother compiling, just downloaded the binary direct from chenall and dropped it in. But if you don't trust running some foreign Chinese binary (you probably shouldn't) by all means compile yourself.

Syslinux is also supposed to be fixed in 6.04 for 64-bit ext4, but that's still not released yet.

[musher0]

Hi jd7654.

Well, I'm not sorry that I've missed it: it's not my fault.

I browsed their site and I do not understand Chinese and that page has a lot of
empty rectangles on it. Plus the download link is not good:

Code: Select all

wget http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a-2019-03-25/
--2019-03-25 07:28:06--  http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a-2019-03-25/
Resolving grub4dos.chenall.net (grub4dos.chenall.net)... 119.28.207.122
Connecting to grub4dos.chenall.net (grub4dos.chenall.net)|119.28.207.122|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 18260 (18K) [text/html]
Saving to: ‘index.html’

index.html          100%[===================>]  17,83K  72,4KB/s    in 0,2s

2019-03-25 07:28:08 (72,4 KB/s) - ‘index.html’ saved [18260/18260]

I also tried:

Code: Select all

wget http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a-2019-03-25.7z
--2019-03-25 07:22:28--  http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a-2019-03-25.7z
Resolving grub4dos.chenall.net (grub4dos.chenall.net)... 119.28.207.122
Connecting to grub4dos.chenall.net (grub4dos.chenall.net)|119.28.207.122|:80...
connected.
HTTP request sent, awaiting response... 404 Not Found
2019-03-25 07:22:29 ERROR 404: Not Found.

On the site, the links give me the run-around in th old opera 12.16. Ah, on
palemoon it is http://dl.grub4dos.chenall.net/grub4dos ... 9-02-22.7z

Now to be clear, which one of the following files do I "drop-in" and where do I "drop
it in"? There are a lot of WhineDose files in there.

Code: Select all

lg -h
total 1,4M
drwxr-xr-x 2 4,0K fév 21 19:39 docs/
drwxr-xr-x 2 4,0K fév 21 19:39 sample/
-rw-r--r-- 1 336K fév 21 19:39 badgrub.exe
-rwxr-xr-x 1  43K fév 21 19:39 bootlace64.com*
-rwxr-xr-x 1  43K fév 21 19:39 bootlace.com*
-rw-r--r-- 1  18K fév 21 19:39 COPYING
-rw-r--r-- 1 1,7K fév 21 19:39 eltorito.sys
-rw-r--r-- 1  197 fév 21 19:39 Get_Source_of_This_Build.txt
-rw-r--r-- 1 320K fév 21 19:39 grldr
-rw-r--r-- 1  512 fév 21 19:39 grldr_cd.bin
-rw-r--r-- 1 8,0K fév 21 19:39 grldr.mbr
-rw-r--r-- 1 5,5K fév 21 19:39 grldr.pbr
-rw-r--r-- 1 338K fév 21 19:39 grub.exe
-rw-r--r-- 1  967 fév 21 19:39 grub.pif
-rw-r--r-- 1 1,9K fév 21 19:39 hmload.com
-rw-r--r-- 1 222K fév 21 19:40 ipxegrldr

Also, with which of the above files should shinobar's grub4dosconfig be repackaged?
Many thanks in advance.

[jd7654]

If you could kindly make this binary available or provide a valid link to it?
Many thanks in advance.

Yeah, you gotta dig around a bit to find the actual download link.
Try this:
http://dl.grub4dos.chenall.net/grub4dos ... 9-03-25.7z

I have not tried this newer version. I'm running an older build from 2017. Use at your own risk.

[musher0]

Ok, guys,

this is how you do it.
"Mutatis mutandis", meaning: change the partition names and the directory names
to reflect your situation.

Code: Select all

mv /mnt/sda1/grldr /mnt/sda1/grldr-vx
cp /mnt/sdb1/Downloads/grub4dos-0.4.6a/grldr /mnt/sda1/

The good news: it is a drop-in replacement.

The bad news: it does not allow to boot into Sailor enceladus' Puduan-7. The "error 13"
message still appears, except with a chenall URL next to it.

It is said that grub2 does not use a bootloader. Would that be the way to go?

BFN.

[jd7654]

I haven't looked at this issue in a while.(over a year)

Yes, grldr binary is drop-in replacement for what's in /usr/lib/grub4dos folder, that gets installed onto partition by Puppy installer. But I think we still have an issue with wee, even though grub4dos itself is fixed. Haven't checked that scenario.(stage 1)

First post info is still valid. Grub2 bootloader is fully compatible with 64-bit Ext4.(I actually use a combination of Grub4Dos and Grub2 in my boot setups) And one proven workaround is to change 64-bit Ext4 to 32-bit Ext4. I think that's why I left the little chenall updated grub4dos as a single little sentence on the end. not tested.

[musher0]

Hmmm...

Code: Select all

]>resize2fs -s /dev/sda1
resize2fs 1.44.5 (15-Dec-2018)
The filesystem is already 32-bit.

What do I do now?

[jd7654]

Hmmm...

Code: Select all

]>resize2fs -s /dev/sda1
resize2fs 1.44.5 (15-Dec-2018)
The filesystem is already 32-bit.

What do I do now?

Not sure. This was a very narrow How-to for the error 13 due to 64-bit Ext4. So you don't have the 64-bit ext4, so these fixes do not apply.

You are getting the error 13 for some other reason. Could be the thing you are trying to boot (kernel?) is corrupted, encrypted or compressed in some other unsupported way for grub4dos.

[musher0]

Hi, jd7654.

Thanks for your reply.

Could it be because the hard drive it's on is an SSD?

The strange thing is that Puduan-7 boots ok from the DVD. Slow, but no error.

Maybe I'll do a general fsck of all the partitions and see what that does.

TWYL.

[SilverB]

I experienced all of these difficulties when I was trying to reformat two hard disks that I got given using gparted.

Eventually after having tried to use grub4dos to write a new boot record and getting an error saying that there was not enough room to write the grub4dos entries in the master boot record, I went back and created new Partition tables on both discs. I chose msdos rather than the default and that seemed to clear everything up. It didn't matter which version of gparted or whether I used ext3 or ext4, everything got cleared up using msdos as the partition table structure.

[musher0]

Thanks, SilverB

I'll give it a try.

BFN.

[jd7654]

I experienced all of these difficulties when I was trying to reformat two hard disks that I got given using gparted.

Eventually after having tried to use grub4dos to write a new boot record and getting an error saying that there was not enough room to write the grub4dos entries in the master boot record, I went back and created new Partition tables on both discs. I chose msdos rather than the default and that seemed to clear everything up. It didn't matter which version of gparted or whether I used ext3 or ext4, everything got cleared up using msdos as the partition table structure.

Yeah, grub4dos (0.4.4) doesn't work with GPT disks. I only use it on MBR disks on BIOS systems. On UEFI systems with GPT disks, I use Grub2 or combination of rEFInd and Grub2. The newer grub4dos 0.4.6a supposedly has a patch for gpt, but I have not tested it in full scenario.

Here is an explanation of why the error message about not fitting in MBR:
https://www.anchor.com.au/blog/2012/10/ ... with-grub/