Page 1 of 2
Grub4dos problem
Posted: Mon 18 Mar 2019, 19:43
by WoodLark
I installed xenialpup64-7.5 on a machine that already had MX-17 installed on another drive/partition. Puppy boots just fine, but if I try to boot MX-17, I get the following error message:
"Error 22: No such partition found"
Here is the menu.lst file that xenialpup generated:
Code: Select all
# menu.lst produced by grub4dosconfig-v1.9.2
color white/blue black/cyan white/black cyan/black
#splashimage=/splash.xpm
timeout 10
default 0
# Frugal installed Puppy
title Puppy xenialpup64 7.5 (sdb1/xenialpup647.5frugal)
uuid acc8ebc4-d8fa-47aa-badc-b8b65d66197c
kernel /xenialpup647.5frugal/vmlinuz psubdir=xenialpup647.5frugal pmedia=atahd pfix=fsck
initrd /xenialpup647.5frugal/initrd.gz
# Full installed Linux
title MX 17 Horizon (sda11/boot)
uuid 7f7ce203-070f-4ea5-a001-66fa8e547287
kernel /boot/vmlinuz-4.15.0-1-amd64 root=/dev/sda11 ro
initrd /boot/initrd.img-4.15.0-1-amd64
# Windows
# this entry searches Windows on the HDD and boot it up
title Windows\nBoot up Windows if installed
map (hd1) (hd0)
map (hd0) (hd1)
map --hook
errorcheck off
find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /bootmgr
find --set-root --ignore-floppies --ignore-cd /ntldr
chainloader /ntldr
find --set-root --ignore-floppies --ignore-cd /io.sys
chainloader /io.sys
errorcheck on
# Advanced Menu
title Advanced menu
configfile /menu-advanced.lst
commandline
Can anyone familiar with grub4dos steer me in the right direction to fix this? (The uuid for /dev/sda11 is correct.)
Posted: Mon 18 Mar 2019, 20:45
by Keef
Not entirely sure, but maybe lose the 'root=/dev/sda11' bit, and try 'bdev=sda11' instead.
Posted: Mon 18 Mar 2019, 21:09
by WoodLark
Keef wrote:Not entirely sure, but maybe lose the 'root=/dev/sda11' bit, and try 'bdev=sda11' instead.
Thanks for trying to help! Unfortunately, it made no difference.
Posted: Mon 18 Mar 2019, 21:37
by Keef
Only other things I can think of is to try 'rootnoverify (hd0,10)' instead of the blkid, and I found that antiX uses 'buuid' instead of just 'uuid'. The root=/dev/sda11 looks to be right, so maybe it is down to the first line.
It's been a while since I tried MX so this is guesswork.
Fredx181 or another of the DebianDoggers will probably be able to help.
Re: Grub4dos problem
Posted: Tue 19 Mar 2019, 01:39
by MrDuckGuy
WoodLark wrote:... trying to help! Unfortunately, ...
--- E D I T ---
OK, I did a little digging, and in another computer I have
a combination setup with several "full" installations
combined with several "frugal" installations. I had an
issue with some of the installs disappearing, as you
are now having. The issue no longer occurs, I added
a few commands that might have fixed it.
Here is a line of code that I would suggest you try:
#root (hd0,0) <-- GRUB legacy, ex: (hd1,0)
I found this in another discussion on this topic:
Full installs not booting with Grub4dos
generated menu entry. Here is coded
example from the thread:
Code: Select all
title Puppy Linux working - xenialpup64 7.5 full install in sdc5
#root (hd0,0) <-- GRUB legacy, ex: (hd1,0)
uuid 19b0847a-549d-49c9-8c98-25af56f1d0ee
kernel /boot/vmlinuz fullinstall root=UUID=19b0847a-549d-49c9-8c98-25af56f1d0ee pmedia=atahd
# root=/dev/sdc5
initrd /boot/initrd.gz
Let's crack this problem! Hopefully you're on your
way to doing just that. Good luck with it! B'H.
==============================
I hope this is of some help. I have several frugal OSs
installed on a flash drive, with three partitions.
I recently had to edit menu.lst because I transfered the
frugal folders from one partition to another. So I had
to replace every instance of "SD1" with "SD2."
Then when I was ready to transfer the folders back
to the original SD1 partition, when I re-edited menu.lst
I made a mistake when saving it, and saved it to the
backup file.
The menu came up with the incorrect path for every
frugal folder. They all still booted, with the pathway
information pointing to an empty partition.
So, I don't know if your uuid makes all that much
difference, I think there's another command you put
to tell Grub4DOS to find your install.
I'll try to look it up and update this post.
Hope this helped. Kelikaku B'H.
Posted: Tue 19 Mar 2019, 14:29
by WoodLark
I tried the suggestions in the previous post, and they had no effect.
However, it got me thinking; I realized I had overlooked what may be the root cause of the problem:
/dev/sdb (which is where grub4dos is located) is a 1TB drive with MBR partition table and boot sector.
/dev/sda (where MX-17 is located) is a 4TB drive and has a GPT partition table.
Could it be that grub4dos simply can not find the partition containing MX-17? Again, if this is the case, I haven't got a clue how to fix it (or if it can be fixed).
Posted: Tue 19 Mar 2019, 14:55
by linuxcbon
Check if UUID is correct :
# blkid /dev/sda11
it shoud give the correct UUID
You can try these 2 solutions to see which one works ?
title MX 17 Horizon (sda11/boot)
kernel /boot/vmlinuz-4.15.0-1-amd64 root=/dev/sda11
initrd /boot/initrd.img-4.15.0-1-amd64
title MX 17 Horizon (sda11/boot)
uuid .....correct UUID here...
kernel /boot/vmlinuz fullinstall root=UUID=.....correct UUID here...
initrd /boot/initrd.img-4.15.0-1-amd64
Posted: Tue 19 Mar 2019, 19:00
by Keef
Maybe 'root (hd1,10)' on the first line, as the drive is a secondary one?
Posted: Wed 20 Mar 2019, 12:55
by WoodLark
It looks like I owe everyone an apology. I have another computer which has exactly the same setup, including the same menu.lst. The full install boots perfectly on that computer, so I can only conclude that the boot sector on /dev/sda has become damaged somehow. Unless I can repair that, nothing I change in menu.lst is going to make any difference.
Posted: Wed 20 Mar 2019, 20:13
by foxpup
WoodLark wrote: I have another computer which has exactly the same setup, including the same menu.lst.
You did change the uuid, didn't you?
They will be different on different machines, even when the setup is the same.
The full install boots perfectly on that computer, so I can only conclude that the boot sector on /dev/sda has become damaged somehow.
I don't think so.
There is no boot sector on gpt; gpt uses boot partitions.
I don't think you boot from sda anyway, you boot from sdb with grub4dos.
What filesystem is sda11? Could it be ext4 64bit?
Posted: Wed 20 Mar 2019, 20:45
by foxpup
Try using the uuid instead of /dev/sda11:
Code: Select all
title MX 17 Horizon (sda11/boot)
uuid 7f7ce203-070f-4ea5-a001-66fa8e547287
kernel /boot/vmlinuz-4.15.0-1-amd64 root=UUID=7f7ce203-070f-4ea5-a001-66fa8e547287 ro
initrd /boot/initrd.img-4.15.0-1-amd64
Posted: Wed 20 Mar 2019, 22:27
by rufwoof
uuid's can change. Perhaps use something like ...
find --set-root /boot/vmlinuz-4.15.0-1-amd64
kernel /boot/vmlinuz-4.15.0-1-amd64
initrd /boot/initrd.img-4.15.0-1-amd64
Posted: Thu 21 Mar 2019, 19:09
by WoodLark
foxpup,
I had already tried what you suggested. No luck!
rufwoof,
I tried your method. It failed too, but with a "file not found" message.
So far, the only way I have been able to get MX to boot is to change the boot order in the bios so that it boots off /dev/sda.
Posted: Fri 22 Mar 2019, 12:29
by foxpup
What bootloader is on sda? Grub2?
You can look for grub.cfg for inspiration.
But again this little question:
What filesystem is sda11? Could it be ext4 64bit?
Grub2 can handle ext4 64bit, but grub4dos cannot.
Recent linuxes may create this ext4 64bit partition to install on.
Posted: Fri 22 Mar 2019, 15:57
by fredx181
foxpup wrote:Grub2 can handle ext4 64bit, but grub4dos cannot.
Recent linuxes may create this ext4 64bit partition to install on.
Sure, if you chose to format the partition during install.
@WoodLark See here for more info and solution:
http://murga-linux.com/puppy/viewtopic.php?t=111376
Fred
Posted: Fri 22 Mar 2019, 22:14
by WoodLark
foxpup is right /dev/sda11 is formatted ext4, 64 bit.
fredx181, I will take a look at the link you posted.
Posted: Sat 23 Mar 2019, 10:37
by foxpup
fredx181 wrote:Sure, if you chose to format the partition during install.
Do these linuxes give you a choice?
Posted: Sat 23 Mar 2019, 11:35
by fredx181
foxpup wrote:fredx181 wrote:Sure, if you chose to format the partition during install.
Do these linuxes give you a choice?
Yes, they do AFAIK (well, maybe some exceptions) if you choose "manual" partition option during install, you can choose yes or no to format the partition.
So, if you plan to install such a new Linux distro and want to boot it using grub4dos, better prepare first by formatting the partition from Puppy or from older Linux.
Fred
Posted: Sat 23 Mar 2019, 14:06
by mikeslr
foxpup wrote:fredx181 wrote:Sure, if you chose to format the partition during install.
Do these linuxes give you a choice?
I have Mx17 on my laptop. IIRC, I chose "Custom Install". Then when I had the opportunity, I had Mx17 format the partition on which it was to be install as Linux Ext
3. Grub4dos doesn't have a problem with that format.
Posted: Sat 23 Mar 2019, 16:49
by foxpup
@WoodLark
If you do not want to remove the 64bit capability of the MX partition, suggestion from fredx181, you can try some other things to boot MX from grub4dos:
- You can try if the grub2 efi binary on sda can be chainloaded from grub4dos. My guess is that this will not work, but I am not sure.
- You can copy kernel en initrd from MX to another partition that is not ext4 64bit.
If the uuid of this partition is blablabla en you copy /boot/ on sda11 with kernel en initrd to that partition,
the entry in menu.lst would be something like this:
Code: Select all
title MX 17 Horizon (blablabla/boot sda11)
uuid blablabla
kernel /boot/vmlinuz-4.15.0-1-amd64 root=UUID=7f7ce203-070f-4ea5-a001-66fa8e547287 ro
initrd /boot/initrd.img-4.15.0-1-amd64
- You translate and transfer your menu.lst to grub.cfg on the boot partition for MX and use EFI boot from grub2 all the time.
- You could also use rEFInd. It is EFI boot, but I think it will also look for and handle legacy boot.
However, I would prefer the solution that fredx181 referenced. Fastest and (most) sure to work.