It should but I never tested it. I do not think the code has been changed in that part.666philb wrote:will this patch also work with grub4dos 1.9.2?
Try to patch it and if it does not fail, should be OK.
It should but I never tested it. I do not think the code has been changed in that part.666philb wrote:will this patch also work with grub4dos 1.9.2?
I don't have that problem, multi-booting from sd card with grub4dos no problems. My SD card is FAT formatted.starhawk wrote:grub4dos appears to have problems booting from SD cards, at least in an SD-to-IDE adapter. I have booted Puppy from that media successfully with extlinux/syslinux -- but grub4dos consistently fails.
This is in reference to this post and thread.
Code: Select all
title Puppy tahr 6.0.5.3 (sdc2/tahr)
uuid 2b4a3075-e41d-4ee4-ab92-7e7d73843a3a
kernel /tahr/vmlinuz psubdir=tahr pmedia=atahd pfix=fsck
initrd /tahr/initrd.gz
Code: Select all
title Puppy tahr 6.0.5.3 (sdc2/tahr)
uuid 2b4a3075-e41d-4ee4-ab92-7e7d73843a3a
kernel /tahr/vmlinuz pdrv=2b4a3075-e41d-4ee4-ab92-7e7d73843a3a psubdir=tahr pmedia=atahd pfix=fsck
initrd /tahr/initrd.gz
gyro wrote:Attached "grub4dosconfig_uuid-1.9.2.pet" contains a patched version of the "/usr/sbin/grub4dosconfig" file.
It now supports the recent "init" boot parameter support for specifying partitions with a uuid.
It does this by adding a "pdrv=<uuid>" boot param if the entry contains a "uuid <uuid>" line.
So instead of producing an entry like this:it produces an entry like this:Code: Select all
title Puppy tahr 6.0.5.3 (sdc2/tahr) uuid 2b4a3075-e41d-4ee4-ab92-7e7d73843a3a kernel /tahr/vmlinuz psubdir=tahr pmedia=atahd pfix=fsck initrd /tahr/initrd.gz
A "pdrv=" boot parameter is used because only recent "init"s that support uuid's also support "pdrv=".Code: Select all
title Puppy tahr 6.0.5.3 (sdc2/tahr) uuid 2b4a3075-e41d-4ee4-ab92-7e7d73843a3a kernel /tahr/vmlinuz pdrv=2b4a3075-e41d-4ee4-ab92-7e7d73843a3a psubdir=tahr pmedia=atahd pfix=fsck initrd /tahr/initrd.gz
Since we are specifying the partition to "grldr" why not provide the same curtesy to "init"?
Note: To use this pet, grub4dosconfig must already be installed.
gyro
The point is that the information in the "uuid" line is not passed on to "init", hence the "pdrv=" parameter so that "init" does get this information.belham2 wrote: Hi Gyro,
I've been using grub4dos for a few years, and I am wondering why anyone would want to add this ability with "pdrv=" parameter? Since you already have to enter the UUID once, what reason and/or attraction is there for doing it again? Are you saying these new init's that can recognize UUID for partitions are not going to boot if this pdrv is not on the kernel line? Sorry if this all sounds stupid, I am struggling hard here to see the or any benefit of this pdrv parameter. Doing things the simple, old way (the first entry method in your example) is not the init forced, as grub4dos goes through its motions, to be assigned to that partition? Why complicate things with a "pdrv=" entry that only repeats what init is actually forced to do as grub4dos boots? Or am I not correctly understanding how grub4dos works??? Thanks for any clarity and/or understanding on this.
gyro wrote:The point is that the information in the "uuid" line is not passed on to "init", hence the "pdrv=" parameter so that "init" does get this information.belham2 wrote: Hi Gyro,
I've been using grub4dos for a few years, and I am wondering why anyone would want to add this ability with "pdrv=" parameter? Since you already have to enter the UUID once, what reason and/or attraction is there for doing it again? Are you saying these new init's that can recognize UUID for partitions are not going to boot if this pdrv is not on the kernel line? Sorry if this all sounds stupid, I am struggling hard here to see the or any benefit of this pdrv parameter. Doing things the simple, old way (the first entry method in your example) is not the init forced, as grub4dos goes through its motions, to be assigned to that partition? Why complicate things with a "pdrv=" entry that only repeats what init is actually forced to do as grub4dos boots? Or am I not correctly understanding how grub4dos works??? Thanks for any clarity and/or understanding on this.
When "init" starts everything is in RAM, there is nothing to indicate where it booted from.
That's why the old "init" went searching through all partitions for the appropriate "vmlinuz'.
And why the new "init" will search through all partitios for the appropriate puppy...sfs.
Unless of course the boot partition is defined to puppy with a "pdev1=","pupsfs=", or "pdrv=" boot parameter.
gyro