Ok I think you're right.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.
grub4dos and Ubuntu 18.04
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.
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
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
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 ?)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
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.
I just tested this with xenialpup-7.5-uefi.iso and it works.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.
It will NOT work with the 64bit version.
The version I have installed on sda1 is from xenialpup64-7.5-uefi.isorcrsn51 wrote:I just tested this with xenialpup-7.5-uefi.iso and it works.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.
It will NOT work with the 64bit version.
Let me try the 32bit verstion and see if that works
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:foxpup wrote: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 ?)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
Could you try if using the uuid in 'root= ...' makes a difference?
here for example
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
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.foxpup wrote:Just had another idea.But maybe it did attempt to write mbr for grub2 on sda4, taking it for the start of the device with sda5 on it??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.
cappyzeb wrote:The version I have installed on sda1 is from xenialpup64-7.5-uefi.isorcrsn51 wrote:I just tested this with xenialpup-7.5-uefi.iso and it works.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.
It will NOT work with the 64bit version.
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.
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?
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.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?
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.
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.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?
Well, as it is now, I use grub4dos for booting into anything other then what's on sda4.rcrsn51 wrote:Maybe the only solution is to boot everything out of GRUB2 as described by peterw on the first page.
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.
That doesn't look right. It's a mix of grub2 and grub4dos and ???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
Can you replace
withtitle 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
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
rcrsn51foxpup wrote:That doesn't look right. It's a mix of grub2 and grub4dos and ???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
Can you replacewithtitle 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?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
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.
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.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.