grub4dos and Ubuntu 18.04

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

#61 Post by cappyzeb »

bigpup wrote:Do not use a gpt partition table.
Nothing in Puppy is really 100% setup to use one.
It really gives you no feature you need.
msdos is best to use.
MBR is old, GPT is new. But the new is not always better than the old. There are still many vendors utilize that use the MBR technology since it is still predominantly used in the real world. GPT disks have advantages of partition size, number of partitions, and resilience.
Ok I think you're right.

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

#62 Post by bigpup »

Just an idea.

Look in the Ubuntu install and see exactly where the initrd and vmlinuz are located and what they are named.

See if the Grub4dos menu.lst entry shows that exact info for initrd and vmlinuz.
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)

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

#63 Post by foxpup »

cappyzeb wrote:
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
I've been reading about a possible bug in grub4dos, where it does not count the extended partition (here sda4) and has a -1 number for the logical partitions on the extended partition (here sda4 for sda5 ?)
Could you try if using the uuid in 'root= ...' makes a difference?

here for example
Last edited by foxpup on Sun 16 Dec 2018, 20:12, edited 2 times in total.

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

#64 Post by rcrsn51 »

cappyzeb wrote:I booted into puppy xenial, it has a 2013 legacy grub installer. I pushed the Select Quick Mode option. I get back an error message saying it can't save the grub files. So I'm not sure what's going on with that.
I just tested this with xenialpup-7.5-uefi.iso and it works.

It will NOT work with the 64bit version.

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

#65 Post by cappyzeb »

rcrsn51 wrote:
cappyzeb wrote:I booted into puppy xenial, it has a 2013 legacy grub installer. I pushed the Select Quick Mode option. I get back an error message saying it can't save the grub files. So I'm not sure what's going on with that.
I just tested this with xenialpup-7.5-uefi.iso and it works.

It will NOT work with the 64bit version.
The version I have installed on sda1 is from xenialpup64-7.5-uefi.iso

Let me try the 32bit verstion and see if that works

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

#66 Post by cappyzeb »

foxpup wrote:
cappyzeb wrote:
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
I've been reading about a possible bug in grub4dos, where it does not count the extended partition (here sda4) and has a -1 number for the logical partitions on the extended partition (here sda4 for sda5 ?)
Could you try if using the uuid in 'root= ...' makes a difference?

here for example
I reinstalled grub2 to the main mbr, then reinstalled grub4dos again over top of grub2. The latest menu.lst entry created by puppy wary is:

title Ubuntu 18.04.1 LTS (sda5)
find --set-root uuid () 02e098cf-29db-44b8-b51c-f96d466019de
kernel /vmlinuz root=UUID=02e098cf-29db-44b8-b51c-f96d466019de ro
# root=/dev/sda5
initrd /initrd.img


It looks like puppy wary is already using the uuid in root and I just checked it but unfortunately is still not working

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

#67 Post by cappyzeb »

foxpup wrote:Just had another idea.
foxpup wrote: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.
But maybe it did attempt to write mbr for grub2 on sda4, taking it for the start of the device with sda5 on it??
I've been giving this some thought and I think you are right. What comes to mind is that Ubuntu on sda5 has usurped boot privilege authority over the whole exteneded partition sda4. As you surmised, it probably is interpreting sda4 extended partition as the main mbr for the entire hard drive disk. Or in any case, it thinks sda4 is the main mbr. So it has taken over the whole sda4 extended partition. Now when any partition located on sda4 is presented with the grub4dos loader protocols, it doesn't recognize the grub4dos authority as it thinks grub2 from ubuntu on sda5 is in charge. And so it ignores grub4dos. Therefore grub4dos is unable to communicate with anything on sda4 so it doesn't see it. I tried reinstalling ununtu on sda5 grub2 to the main mbr and then back to grub4dos but nothing changes. Grub2 on sda5 won't release authority over to grub4dos, but continues to retain its' control over sda4. So I'm giving some thought on how to fix this.

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

#68 Post by cappyzeb »

cappyzeb wrote:
rcrsn51 wrote:
cappyzeb wrote:I booted into puppy xenial, it has a 2013 legacy grub installer. I pushed the Select Quick Mode option. I get back an error message saying it can't save the grub files. So I'm not sure what's going on with that.
I just tested this with xenialpup-7.5-uefi.iso and it works.

It will NOT work with the 64bit version.
The version I have installed on sda1 is from xenialpup64-7.5-uefi.iso

Let me try the 32bit verstion and see if that works

I was able to install legacy grub with xenialpup-7.5-uefi

The results are that the bios can't read sda5:

Selected cylinder exceeds maximum supported by bios

But not because of error 13 as in grub4dos.
So most likely it would be able to read it if the disk size was smaller. At least I think legacy grub is limited in the disk size in can access to read.

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

#69 Post by rcrsn51 »

It sounds to me like the Ubuntu installer has corrupted the extended partition. Maybe because it assumes that everyone is now using GPT where extended partitions don't exist.

However, I would have thought that Gparted would identify such a problem, but it doesn't.

Run "fdisk -l". Does it find anything wrong?

I suspect that the grub4dos and legacy grub errors are indicating the same problem - that the partition table now points to a location on the hard drive that GRUB thinks doesn't exist.

Can you get the machine to boot DIRECTLY into Ubuntu? By installing GRUB2 on the MBR?

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

#70 Post by cappyzeb »

rcrsn51 wrote:It sounds to me like the Ubuntu installer has corrupted the extended partition. Maybe because it assumes that everyone is now using GPT where extended partitions don't exist.

However, I would have thought that Gparted would identify such a problem, but it doesn't.

Run "fdisk -l". Does it find anything wrong?

I suspect that the grub4dos and legacy grub errors are indicating the same problem - that the partition table now points to a location on the hard drive that GRUB thinks doesn't exist.

Can you get the machine to boot DIRECTLY into Ubuntu? By installing GRUB2 on the MBR?
Yes, sda5 boots fine when using grub2.

The following looks good to me, but I don't know that much about it:

# fdisk -l
Disk /dev/loop0: 89.5 MiB, 93818880 bytes, 183240 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes



Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xa22eb907

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 40962047 40960000 19.5G b W95 FAT32
/dev/sda2 40962048 1329649663 1288687616 614.5G 83 Linux
/dev/sda3 1329649664 1347028991 17379328 8.3G 82 Linux swap / Solaris
/dev/sda4 1347028992 3907028991 2560000000 1.2T 5 Extended
/dev/sda5 1347031040 2627028991 1279997952 610.4G 83 Linux
/dev/sda6 2627031040 2696151039 69120000 33G b W95 FAT32
/dev/sda7 2696153088 2759501823 63348736 30.2G 83 Linux
/dev/sda8 3788365824 3907028991 118663168 56.6G 7 HPFS/NTFS/exFAT
/dev/sda9 2759503872 2821236735 61732864 29.4G 83 Linux
/dev/sda10 2821238784 2881200127 59961344 28.6G 83 Linux

Partition table entries are not in disk order.

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

#71 Post by rcrsn51 »

It's a mystery. Is there any way to revert this system back to a state where the stuff in the extended partition works again?

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

#72 Post by cappyzeb »

rcrsn51 wrote:It's a mystery. Is there any way to revert this system back to a state where the stuff in the extended partition works again?
If you are right and it is a corrupted disk, then I don't think much can be done to repair the disk without wiping and losing the data on it. However, since I bought a new hard drive, I could partition it however I wanted and dd the individual partitions I would like to have on the new drive. I could dd the sda5, but if it clones the corrupted format, then I might be back where I started, and the partitions sda5 is large, so it will take a lot of time and work to clone it to the new drive. Or I could clone it to the new drive, wipe the extended partition and reformat it, then dd sda5 back onto the newly reformated extended partition. But if it clones the corrupted format it might end up being a waste of time.

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

#73 Post by rcrsn51 »

Maybe the only solution is to boot everything out of GRUB2 as described by peterw on the first page.

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

#74 Post by cappyzeb »

rcrsn51 wrote:Maybe the only solution is to boot everything out of GRUB2 as described by peterw on the first page.
Well, as it is now, I use grub4dos for booting into anything other then what's on sda4.

If I need to access anything on sda4 extended partition, then I have to use grub2. But I can boot into grub2 from grub4dos.

The following menu.lst entries work for me:

title Grub2
find --set-root /boot/grub/i386-pc/core.img
kernel /boot/grub/i386-pc/core.img
boot

title Grub2
root (hd0,1)
chainloader +1

title Grub2
rootnoverify (hd0,1)
chainloader +1


titleGrub2
root (hd0,1)
kernel /boot/grub/i386-pc/core.img

title Grub2
find --set-root /boot/grub/i386-pc/core.img
kernel /boot/grub/i386-pc/core.img
boot

But the point is that I shouldn't have to.
I am just going to be really mad if I find out something sinister is going on to mess with the simple things in life, like grub4dos to and puppy ditros.

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

#75 Post by foxpup »

cappyzeb wrote:I reinstalled grub2 to the main mbr, then reinstalled grub4dos again over top of grub2. The latest menu.lst entry created by puppy wary is:

title Ubuntu 18.04.1 LTS (sda5)
find --set-root uuid () 02e098cf-29db-44b8-b51c-f96d466019de
kernel /vmlinuz root=UUID=02e098cf-29db-44b8-b51c-f96d466019de ro
# root=/dev/sda5
initrd /initrd.img


It looks like puppy wary is already using the uuid in root and I just checked it but unfortunately is still not working
That doesn't look right. It's a mix of grub2 and grub4dos and ???
Can you replace
title Ubuntu 18.04.1 LTS (sda5)
find --set-root uuid () 02e098cf-29db-44b8-b51c-f96d466019de
kernel /vmlinuz root=UUID=02e098cf-29db-44b8-b51c-f96d466019de ro
# root=/dev/sda5
initrd /initrd.img
with

Code: Select all

title Ubuntu 18.04.1 LTS (sda5)
  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
?

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

#76 Post by cappyzeb »

foxpup wrote:
cappyzeb wrote:I reinstalled grub2 to the main mbr, then reinstalled grub4dos again over top of grub2. The latest menu.lst entry created by puppy wary is:

title Ubuntu 18.04.1 LTS (sda5)
find --set-root uuid () 02e098cf-29db-44b8-b51c-f96d466019de
kernel /vmlinuz root=UUID=02e098cf-29db-44b8-b51c-f96d466019de ro
# root=/dev/sda5
initrd /initrd.img


It looks like puppy wary is already using the uuid in root and I just checked it but unfortunately is still not working
That doesn't look right. It's a mix of grub2 and grub4dos and ???
Can you replace
title Ubuntu 18.04.1 LTS (sda5)
find --set-root uuid () 02e098cf-29db-44b8-b51c-f96d466019de
kernel /vmlinuz root=UUID=02e098cf-29db-44b8-b51c-f96d466019de ro
# root=/dev/sda5
initrd /initrd.img
with

Code: Select all

title Ubuntu 18.04.1 LTS (sda5)
  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
?
rcrsn51
I tried it that way too but it didn't' work. As it turns out, rcrsn51 was right. Went allowed the ubuntu 18.04 software updater to upgrade and update , the Ubuntu installer has corrupted the extended partition. I formatted my new hard drive, added and extended partition, and cloned sda5 to the new extended partition on the new drive, and its boots just fine with grub4dos. So this confirms it is a corrupted file system on extended partition sda4. What I'm goin todo now is delete sda4 and create a new extended partition replacing the old sda4. This should take care of the problem. What is interesting and maybe good to know info, is that it was caused by the ubuntu 18.04 software update. Something in the kernel or upgrade package caused the installer program to corrupt the extended partition. And this happened during the kernel 4.15.0-43 upgrade only. I tested it twice and it did cause damage to the extended partition. It may work fine for others, all I know is what it did to me and my and my systems.

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

#77 Post by rcrsn51 »

I wonder what would happen if you deleted the sda5 partition, then made a new one.

Maybe that would heal the extended partition.

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

#78 Post by cappyzeb »

rcrsn51 wrote:I wonder what would happen if you deleted the sda5 partition, then made a new one.

Maybe that would heal the extended partition.
I tried that already. The first thing I did was clone sda5 to an extended partition on my new hard drive. Then I tested it to see if grub4dos would work, and it did. Then I deleted sda5 on the old disk to see what would happen, and grub4dos still could not detect extended partition sda4. So I deleted sda4 and created a new extended partition with the same name sda4 and after this grub4dos was able to detect and boot the new sda4 just fine. So in conclusion, you were right about the whole sda4 extended partition being corrupted.

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

#79 Post by foxpup »

nice testing
looks conclusive

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

#80 Post by fredx181 »

@cappyzeb
Congrats for fixing it and my compliments for keeping up on the issue and good communication.
Not often you see a thread like this, it's how it should be IMO !

Fred

Post Reply