grub4dos and Ubuntu 18.04

Using applications, configuring, problems
Message
Author
cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

#16 Post by cappyzeb »

foxpup wrote:The 2 lines that intrest us are the kernel (linux) line and the init line. They are at the end. A lot of the lines above are about the graphical interface, not important.
The kernel and init line should translate into this for menu.lst:

Code: Select all

title Ubuntu
find --set-root --ignore-floppies /boot/vmlinuz-4.15.0-43-generic
kernel /boot/vmlinuz-4.15.0-43-generic root=UUID=02e098cf-29db-44b8-b51c-f96d466019de ro
initrd /boot/initrd.img-4.15.0-43-generic 
You need to specify the full path from the root of the partition for the kernel and init.
First you have to find the partition, set the root.
I personally prefer searching a file, the kernel or the init, and not the UUID. In case it does not work, you could try it with the uuid anyway, like in the grub2 menuentry.

Code: Select all

title Ubuntu
uuid 02e098cf-29db-44b8-b51c-f96d466019de
kernel /boot/vmlinuz-4.15.0-43-generic root=UUID=02e098cf-29db-44b8-b51c-f96d466019de ro
initrd /boot/initrd.img-4.15.0-43-generic 
I also wonder whether the root=UUID=.... boot parameter on the kernel line is really necessary. That seems redundant. You could try leaving it out, out of curiosity.

I tried this : title Ubuntu 18.04 (sda5)
uuid 02e098cf-29db-44b8-b51c-f96d466019de
kernel /boot/vmlinuz-4.15.0-43-generic root=/dev/sda5 ro
initrd /boot/initrd.img-4.15.0-43-generic


but it does the same thing, it says error 13 I think, unsupported format or something like that

cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

#17 Post by cappyzeb »

fredx181 wrote:
cappyzeb wrote:
fredx181 wrote:Maybe This has to do with your problem.
Fred

This could be, i'm going to look into this
If the Ubuntu installer did format the partition, I'm almost sure that the problem is because of that "64-bit Ext4' issue, I've experienced that several times, all (most?) newest Linux OS have e2fsprogs version 1.43 which will format ext4 this way, resulting that grub4dos doesn't work.

EDIT: Hmm.. it's not clear to me if you used "Ubuntu installer", you said "upgrade" in first post, so it may be different situation then?

Fred
What happened is that I upgraded 16.04 to 18.04 last week. It was booting fine, although the upgrade to 18.04 caused many glitches. Such as gsku didn't' work, I couldn't copy the text output from the terminal anymore, and there were other issues too. But a few days ago I got a message from the automatic updater wanting to update the system. It said new updates were available among them, I noticed core base upgrade. So I clicked the upgrade button and let it upgrade the system. After that, it wanted to reboot, so I let it, and then after that the grub4dos doesnt' work anymore. So I'm thinking that there might be something going on with the 18.04 version. They seem to be messing with a lot of features we're used to in the previous versions, such as disabling gsku among many other things. So it wouldn't surprise me if they messed with the grub4dos too. It may be an issue with the 64 bit ext4. I am using 64 bit os. I'm looking into this. I'm trying to see if there is a way to reformat it without loosing the data. Or if this is the problem, a way to fix it.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#18 Post by rcrsn51 »

If your Ubuntu install still has its bootloader on the sda5 partition boot sector, then Grub4dos might be able to launch it with just

Code: Select all

title Ubuntu
rootnoverify (hd0,4)
chainloader +1
This might avoid having to fix the 64bit-ext4 problem.

cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

#19 Post by cappyzeb »

rcrsn51 wrote:If your Ubuntu install still has its bootloader on the sda5 partition boot sector, then Grub4dos might be able to launch it with just

Code: Select all

title Ubuntu
root (hd0,4)
chainloader +1
This might avoid having to fix the 64bit-ext4 problem.
I just tried this. I added
title Ubuntu
root (hd0,4)
chainloader +1

to the menu.lst.

I get the following message:
Filesystem type is ext2fs, partition type 0x83 chainloader +1
Error 13 invalid or unsupported executable format

This looks to me like an issue with the ubuntu 18.04 update reformatting the ex4 with e2fsprogs. If so, then this will explain why grub4dos won't boot. I'm still faced with the problem of how to fix it.

cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

Re: grub4dos and Ubuntu 18.04

#20 Post by cappyzeb »

foxpup wrote:
cappyzeb wrote:I wish it were that simple. The grub2 is set to bootload off it's own partition and not the main mbr.
I find this intriguing.
I don't know exactly where to begin my questions.
Is this old legacy with mbr or EFI?
Can you boot grub4dos AND grub2? How do you choose?
If EFI, how do you use grub4dos?
If Legacy with mbr, where is the second mbr?
???
:roll:
Humm.... I think what you mean is that originally ubuntu 16.04 used grub2 when I installed it. It used to be 14.04 or 13..04 when I installed it, but either way, it was originally grub2. Then I cloned and added partitions and moved to different computers and hard drives many times since around 10 years ago. Some where along the line, I added multiple boots, including my favorite puppy ditros almost always on every hard drive now. I use puppy for os maintenance among other things. But at some point, I started using grub4dos. When I started using puppy, it installed grub4dos for me. This relplaced grub2 on the mbr. So now the mbr uses grb4dos. However, grub2 can still be installed on the individual partitions. For example, I have grub2 installed on sda5 in this case. On sda1 is the boot sector flagged boot, and also have a full puppy and frugal installs on sda1 which also happens to be the main mbr. On this sda1 is installed grub4dos. However, I have ubuntu 16.04 installed on sda5 which I recently upgraded to 18.04. It gives the option to have the grub2 installed and upgraded on sda5. I allow it to do this on partition sda5 only. Whenever I upraded to 18.04 and started having problems with it not booting, I was able to boot into grub2 located on sda5. I did this with the entry in menu.lst :
title Find Grub2\nBoot up grub2 if installed
errorcheck off
find --set-root --ignore-floppies --ignore-cd /boot/grub/i386-pc/core.img
kernel /boot/grub/i386-pc/core.img
find --set-root --ignore-floppies --ignore-cd /boot/grub/core.img
kernel /boot/grub/core.img
errorcheck on

This allows me to boot into grub2 on sda5 by accessing the core.img located at /boot/grub/i386-pc/core.img

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#21 Post by bigpup »

Error 13 invalid or unsupported executable format
If Grub4dos gives you the error 13, that is about the ext4 64bit format.

If you can get Ubuntu to install and not change the format it should work.

Use Puppy's Gparted to make the format ext 4. It only does 32bit ext4.

Should be option in the Ubuntu install to not change the partition format. Look for something about not doing things automatically.
Usually that will let you manually select what does what.

Here is another way to maybe fix this issue.
http://murga-linux.com/puppy/viewtopic.php?t=111376
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#22 Post by fredx181 »

cappyzeb wrote:This looks to me like an issue with the ubuntu 18.04 update reformatting the ex4 with e2fsprogs. If so, then this will explain why grub4dos won't boot. I'm still faced with the problem of how to fix it.
Try to convert to 32bit. It's easy !! (if your problem is caused by this "ext4 64bit" issue, if not, no harm is done by converting to 32bit AFAIK)

I checked if it (still) works by using Upup Bionic (it has e2fsprogs 1.44, should be 1.43 or higher), see more here:
http://murga-linux.com/puppy/viewtopic. ... 51#1013051

Fred

foxpup
Posts: 1132
Joined: Fri 29 Jul 2016, 21:08

#23 Post by foxpup »

Hi cappyzeb

From the description you've given me, this is what I think.

It is legacy boot with mbr. The mbr is still grub4dos.
Almost always the mbr is not on a partition but just before any partition of the device. It is on sda and not on sda1 or sda5 or ....
Since it is the mbr of grub4dos it looks for grldr (the bootloader) and menu.lst (the configfile) from grub4dos, and since the boot flag is on sda1, it looks for them on sda1 and finds it there.

What has Ubuntu done? It probably placed a bootloader for grub2 (in core.img) and a configfile for grub2 on sda5. It did not rewrite the mbr.

Now grub4dos on sda1 can find grub2 on sda5 and can chainload it properly.
It seems like it is able to find the Ubuntu as well, but not to make a proper entry for it.
But the entry for ubuntu in the configfile of grub2 does work. (It should: Ubuntu put it there!)
Have you tried the 'translation' I suggested? It should be added in menu.lst on sda1.

cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

#24 Post by cappyzeb »

foxpup wrote:Hi cappyzeb

From the description you've given me, this is what I think.

It is legacy boot with mbr. The mbr is still grub4dos.
Almost always the mbr is not on a partition but just before any partition of the device. It is on sda and not on sda1 or sda5 or ....
Since it is the mbr of grub4dos it looks for grldr (the bootloader) and menu.lst (the configfile) from grub4dos, and since the boot flag is on sda1, it looks for them on sda1 and finds it there.

What has Ubuntu done? It probably placed a bootloader for grub2 (in core.img) and a configfile for grub2 on sda5. It did not rewrite the mbr.

Now grub4dos on sda1 can find grub2 on sda5 and can chainload it properly.
It seems like it is able to find the Ubuntu as well, but not to make a proper entry for it.
But the entry for ubuntu in the configfile of grub2 does work. (It should: Ubuntu put it there!)
Have you tried the 'translation' I suggested? It should be added in menu.lst on sda1.
I added your translation to the menu.lst but it doesn't' work. It says no such partition found. But I know the partition exists. What's going on is that the grub4dos can't read it for what ever reason. I'm thinking that the ubuntu 18.04 upgrade is messing with it. From what I can tell, until the grub4dos can see the partition, it's not going to work no matter what you put on the menu.lst

cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

#25 Post by cappyzeb »

bigpup wrote:
Error 13 invalid or unsupported executable format
If Grub4dos gives you the error 13, that is about the ext4 64bit format.

If you can get Ubuntu to install and not change the format it should work.

Use Puppy's Gparted to make the format ext 4. It only does 32bit ext4.

Should be option in the Ubuntu install to not change the partition format. Look for something about not doing things automatically.
Usually that will let you manually select what does what.

Here is another way to maybe fix this issue.
http://murga-linux.com/puppy/viewtopic.php?t=111376

I was thinking this too, but we were wrong. This is the output:

# e2fsck -f /dev/sda5
e2fsck 1.44.1 (24-Mar-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
trezam-2: 2409471/40001536 files (0.7% non-contiguous), 146626306/159999744 blocks
# resize2fs -s /dev/sda5
resize2fs 1.44.1 (24-Mar-2018)
The filesystem is already 32-bit.


===================

So based on the above, the file system is still 32 bit. So then the problem is not it being about a ext4 64bit format. Obviously the error 13 indicates that the partition cannot be seen by grub4dos. I guess it has something to do with the ubutnu 18.04 upgrade. Somehow for whatever reasons, it is causing the partition to not be seen by the grub4dos. So until I can solve the mystery, I guess I'm stuck using grub2 for the ubuntu 18.04 version.

cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

#26 Post by cappyzeb »

fredx181 wrote:
cappyzeb wrote:This looks to me like an issue with the ubuntu 18.04 update reformatting the ex4 with e2fsprogs. If so, then this will explain why grub4dos won't boot. I'm still faced with the problem of how to fix it.
Try to convert to 32bit. It's easy !! (if your problem is caused by this "ext4 64bit" issue, if not, no harm is done by converting to 32bit AFAIK)

I checked if it (still) works by using Upup Bionic (it has e2fsprogs 1.44, should be 1.43 or higher), see more here:
http://murga-linux.com/puppy/viewtopic. ... 51#1013051

Fred
Thanks for the info, I didn't even know about the Upup project. I downloaded upup and put it on a cd. I booted into upup and tried to install, but it wouldn't install. It said the path to the sf file was wrong. So there might be a glitch in the system. I copied and pasted the files on the cd to partition sda7, but because it is also ubuntu 18.04 it won't boot either. Or the grub4dos doesn't recognize it. The grub2 doesn't recognize it either, so I need to figure out how to manually add it to the custom40 file.

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#27 Post by fredx181 »

Hi cappyzeb
The filesystem is already 32-bit.
Ok, that's clear now that the error is not because sda5 is ext4 64bit.
But what about grldr and menu.lst ? On which partition they are and what filesystem type ?
(sorry if you said already and I didn't read well)

EDIT: Can't answer your question about installing Upup Bionic. I did it manually and added entry for grub4dos in menu.lst, but obviously grub4dos doesn't work for you.

Fred

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#28 Post by rcrsn51 »

Just out of curiosity, run Gparted. Does it see anything unusual about these partitions?

I'm guessing that sda5 is a logical volume inside an extended partition.

cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

#29 Post by cappyzeb »

fredx181 wrote:Hi cappyzeb
The filesystem is already 32-bit.
Ok, that's clear now that the error is not because sda5 is ext4 64bit.
But what about grldr and menu.lst ? On which partition they are and what filesystem type ?
(sorry if you said already and I didn't read well)

EDIT: Can't answer your question about installing Upup Bionic. I did it manually and added entry for grub4dos in menu.lst, but obviously grub4dos doesn't work for you.

Fred
The grldr and menu.lst are on sda1 with a ext4 file system.

I manually installed the Upupbb onsda7 by copying the files on the cd and pasting them on sda7. Then I added the entry to the grub2 custom_40 file

So it boots fine using grub2

cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

#30 Post by cappyzeb »

rcrsn51 wrote:Just out of curiosity, run Gparted. Does it see anything unusual about these partitions?

I'm guessing that sda5 is a logical volume inside an extended partition.
Actually I did. I ran gparted and did a check on all the partition on the extended partition sda4. Gparted didn't find anything wrong. I know that sometimes if there is a superblock or error on the partition with the file system, gparted will have a warning indicator. But gparted is showing everything is fine on sda5 and on all the partitions on the hard drive.

Yes, sda4 is a extended partition and sda5 is on this extended partition making it a logical partition.

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#31 Post by fredx181 »

cappyzeb wrote:The grldr and menu.lst are on sda1 with a ext4 file system.
Worthwhile checking if sda1 is "ext4 64bit" type filesystem:

Code: Select all

tune2fs -l /dev/sda1
I guess small chance it is, but better to count everything out to solve this mystery...

Fred

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#32 Post by bigpup »

When you checked the partitions with Gparted.
Does sda5 have any flags?
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

#33 Post by cappyzeb »

fredx181 wrote:
cappyzeb wrote:The grldr and menu.lst are on sda1 with a ext4 file system.
Worthwhile checking if sda1 is "ext4 64bit" type filesystem:

Code: Select all

tune2fs -l /dev/sda1
I guess small chance it is, but better to count everything out to solve this mystery...

Fred
I don't know what any of this means but it looks like sda1 is tune2fs 1.42.13 :


$ sudo tune2fs -l /dev/sda1

tune2fs 1.42.13 (17-May-2015)
Filesystem volume name: Suzam
Last mounted on: /mnt/sda1
Filesystem UUID: 6259bc92-e045-4ac6-a693-a1006f6a1a58
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 4060000
Block count: 20480000
Reserved block count: 1023157
Free blocks: 8878959
Free inodes: 3965365
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 1624
Inode blocks per group: 203
RAID stride: 4
RAID stripe width: 4
Flex block group size: 16
Filesystem created: Fri Nov 9 18:47:15 2018
Last mount time: Sat Dec 15 04:55:47 2018
Last write time: Sat Dec 15 04:55:47 2018
Mount count: 252
Maximum mount count: -1
Last checked: Fri Nov 9 18:49:57 2018
Check interval: 0 (<none>)
Lifetime writes: 37 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 7241ab47-85f6-4bff-9fe8-ca5d4225da8b
Journal backup: inode blocks

cappyzeb
Posts: 39
Joined: Tue 11 Dec 2018, 11:52

#34 Post by cappyzeb »

bigpup wrote:When you checked the partitions with Gparted.
Does sda5 have any flags?
There are no flags on sda5. The only flag on the hard drive is the boot flag on sda1

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#35 Post by fredx181 »

cappyzeb wrote:I don't know what any of this means but it looks like sda1 is tune2fs 1.42.13 :

$ sudo tune2fs -l /dev/sda1
....
....
The 1.42.13 is just the version, but your output for sda1 looks okay, no "64bit" in Filesystem features.
I was focused on that "ext4 64bit" issue, but it seems nothing to do with your problem, so, sorry, I'm out of ideas at the moment.
(maybe doing a web search for "grub error 13" brings you something ?)

Fred

Post Reply