OtherInstalls v11 - generate grub2 boot entries

[gyrog]

The currrent release of OtherInstalls is version 11, viewtopic.php?p=45288#p45288.
It now writes to '/var/local/otherinstalls.d/boot-entries'.

With this version, converting an existing grub4dos boot entries is the preferred method for DebianDog/UbuntuDog frugal installs.

I've had a "bright" idea, perhaps OtherInstalls would be simpler if it focused on copying/translating existing working boot-entries into grub2 entries in '/etc/grub.d/40_custom'. If necessary from a working frugal install of a single OS on a usb stick.
viewtopic.php?p=27518#p27518

------------Original post------------
I have attached 'OtherInstalls-1.tar.gz', extract the 'other-installs' script with:

Code: Select all

tar xf OtherInstalls-1.tar.gz

This is a CLI utility that searches partitions for non-Puppy installs, and generates grub2 boot entries for them in '/etc/grub.d/40_custom'.
Since "FrugalPup->Boot" now processes all files in '/etc/grub.d/', the next time "FrugalPup->Boot" is used to replace 'grub.cfg', these entries will get included in the grub2 menu and when selected should boot the appropriate OS.
This represents an idea I had after being made aware of a possible need for FrugalPup to "work" with booting things other than Puppy frugal installs.

It currently works for Windows, both uefi and non-uefi.

It's coded for EasyOS, but I don't know if that works.
It would be helpful if someone who uses FrugalPup, (or at least grub2), and EasyOS could test this, please.

To use, run the following command in a console opened in the directory containing 'other-installs':

Code: Select all

./other-installs

You can append a "-h" parameter to see it's help.

To test the EasyOS stuff:
Ensure that there is no current '/etc/grub.d/40_custom' file, run 'other-installs', check that the contents of '/etc/grub.d/40_custom' look reasonable.
try using the entry in a real 'grub.cfg', either use "FrugalPup->Boot" v31 to replace the 'grub.cfg' or directly edit 'grub.cfg' and cut+paste the generated entry from '/etc/grub.d/40_custom' into it.

My plan is to either develop this as a standalone utility, or perhaps include it as an extra facility in FrugalPup.
I would like it to be capable of handling more OS's, particularly frugal installs.
But I don't want to go down the rabbit holes of becomming familiar with each of lot's of different OS's.
So, I'm looking for helpers to give me information about booting various OS's with grub2, how to recognise an installation, and to test booting those OS's.

Which OS's?
Well any that folk might want to multi-boot with Puppy, while using FrugalPup to manage boots.

If this come to fruition, I will remove the current support for Windows from FrugalPup.

OtherInstalls-1.tar.gz

(1.62 KiB) Downloaded 57 times

[mikeslr]

Hi gyrog,

Thanks for the application. I can confirm that frugalpup-31 generates a functional entry for Windows; and well be glad to test and report regarding 'OtherInstalls'. But when setting up this 'new-to-me' computer I reserved a partition for Linux Mint and have it on a USB-Key I haven't gotten around to installing it yet. ['Maybe someday I'll want it' decisions I make when formatting a hard-drive].
So while I doubt that being able to do so is likely to have any practical value, I wondered if OtherInstalls would generate a menu entry for a Linux distro on a USB-Key?

[gyrog]

@mikeslr ,
To generate a menu entry for a Linux distro, 'other-installs' needs to know how to recognise the particular distro, i.e. what are the signature files?
For Puppy it's the presence of the 'puppy...sfs' file. For EasyOS It looks for 'easy.sfs'.
And then it needs to know what a typical grub2 boot entry looks like for that OS.

So, If you could let me know both these pieces of information for Linux Mint, I'll give it a go.

I gather that you run EasyOS, if so, could you please test the EasyOS support in 'other-installs'?

[gyrog]

I have attached 'OtherInstalls-2.tar.gz', extract the 'other-installs' script with:

Code: Select all

tar xf OtherInstalls-2.tar.gz

This version adds support for 'plopkexec'.

OtherInstalls-2.tar.gz

(1.73 KiB) Downloaded 52 times

[mikeslr]

You haven't been abandoned. Real-life distractions. Will test and reply soon. But one thing. I take it that OtherInstalls is run from an OS and not located on the USB-Key whose grub.cfg is to be modified. Is that correct?

[gyrog]

You haven't been abandoned. Real-life distractions. Will test and reply soon. But one thing. I take it that OtherInstalls is run from an OS and not located on the USB-Key whose grub.cfg is to be modified. Is that correct?

Yes, I also have a life apart from Puppy. Thanks for your time.

Yes,
at this time 'other-installs' is a separate utility, it is not part of, or installed by FrugalPup.
Place the 'other-installs' script on the Puppy you are using to run FrugalPup v31.
After running 'other-installs', if boot entries have been successfully generated in '/etc/grub.d/40_custom' on that Puppy, these should be included in any 'grub.cfg' that is created or replaced by "FrugalPup->Boot" v31 running on that Puppy.

[mikeslr]

Well this works, .

I ran OtherInstalls under Bionicpup64 which created this /etc/grub.d file:

etc_grub.d_40_custom.png (47.79 KiB) Viewed 7427 times

Then ran frugalpup>Boot Puppy which created these menu listings on a USB-Key

if [ $grub_platform = 'pc' ]; then
menuentry "Windows" {
insmod ntfs
search --no-floppy --fs-uuid --set=root 9CF4F638F4F613EC
ntldr /bootmgr
}
fi
menuentry "EasyOS from sda3" {
insmod ext2
search --no-floppy --fs-uuid --set=root 39ff128d-806e-45a0-9c0c-4013859ec05d
linux /EasyOSB/vmlinuz rw root=UUID=39ff128d-806e-45a0-9c0c-4013859ec05d rootfstype=ext3
initrd /EasyOSB/initrd
}

as well as the expected listings for various Puppys frugally located on sda3.

Rebooted with the above USB-Key and selected 'EasyOS from sda2'. Am posting from it now.

[gyrog]

Well this works, .
as well as the expected listings for various Puppys frugally located on sda3.
.......
Rebooted with the above USB-Key and selected 'EasyOS from sda2'. Am posting from it now.

Thanks for testing.
Great news that it's working as intended, and in particular the "hack" at an "EasyOS" boot entry, does at least boot the said "EasyOS".

There's just one thing, did you get duplicate "Windows" entries in the generated 'grub.cfg' on the USB-Key?
In the current environment it's quite possible for "FrugalPup->Boot" to generate a "Windows" entry and for the "other-installs" script to generate one as well.

[gyrog]

I have attached 'OtherInstalls_3.sfs.gz', gunzip to produce 'OtherInstalls_3.sfs'.

This is a GUI version of OtherInstalls which includes a couple of niceties:

A dialog that allows you to select which of the discovered partitions to search for non_Puppy installations.
A dialog that allows you to select which of the found installations to generate boot-entries for in '/etc/grub.d/40_custom'.

Both of these dialogs provide 3 buttons to click: "Cancel", "All", or "OK"
"OK" processes only the selected items, at least 1 must be selected.
"All" processes all the items without selecting any.
"Cancel" exits the application.

There is no change to the list of supported non-Puppy installations:
Windows
Plopkexec
EasyOS

The executable is now called 'otherinstalls'.

Simply add 'OtherInstalls_3.sfs' as an extra sfs using 'sfs_load'.
It should appear in the "Setup" menu beside "FrugalPup".

OtherInstalls_3.sfs.gz

gunzip to produce 'OtherInstalls_3.sfs'

(3.66 KiB) Downloaded 48 times

[mikeslr]

Thanks for the sfs. Good idea to package the application as such. And, yes, now that you mentioned it two 'windows' listings were generated on grub.cfg, the second below the EasyOS listing. I hadn't scrolled passed the EasyOS listing which came after the 1st 'windows' listing.

[gyrog]

Thanks @mikeslr, it seems to be working as I expect.

With the ability to select stuff in "OtherInstalls" GUI, you could avoid any duplication.
But as I said in the "FrugalPup" topic, the "Windows" code will be removed from "FrugalPup v32", it will depend on "OtherInstalls".

Edit: Actually I didn't say that, I said I might. Well, now I will.

[gyrog]

I have attached 'OtherInstalls_4.sfs.gz', gunzip to produce 'OtherInstalls_3.sfs'.

This is the second release of the GUI version of OtherInstalls, it contains a new dialog.
If the file '/etc/grub.d/40_custom' exists, a dialog asking to "Replace" or "Append" is shown.

The list of supported non-Puppy frugal installations is extended to include
the direct boot of iso files, if they are stored on a Linux partition.
Well it's a first try, just to satisfy my curiosity.
I'm not sure if anyone committed to booting iso's directly, would want do it via FrugalPup, but there it is anyway.

Simply add 'OtherInstalls_4.sfs' as an extra sfs using 'sfs_load'.
It should appear in the "Setup" menu beside "FrugalPup".

OtherInstalls_4.sfs.gz

gunzip to produce OtherInstalls.sfs

(3.96 KiB) Downloaded 23 times

[mikeslr]

Hi gyrog,

Thanks for the new version but:

One thing might be easy to solve.

otherinstalls-gui.png (35.05 KiB) Viewed 6961 times

In its current condition the GUI cuts off the last part of an ISO's name. You can scroll to it. But then you loose sight of the checkbox to select it.

I tried booting several ISOs: One of the debiandogs, LinuxMint and manjaro. Listings are created, but they won't boot. Some modification might be successful with the debiandogs and LinuxMint. The problem is that --consistent with Puppys-- the listings refer to initrd.gz and vmlinuz. The debiandogs, however, identify the 'equivalents' as initrd1.xz and vmlinuz1. This AFAIK true of all 'debiandogs', whether binary-compatible with Ubuntus or debians.

LinuxMint uses vmlinuz, but initrd.lz. I don't know what the hell manjaro does to boot an ISO. Couldn't find an initrd-anything, anywhere; and the only vmlinuz I found was named 'vmlinuz-x86_64'.

I've been exploring the debiandogs. I'll send you an email once I've made sense of the results.

But FWIW, for the reasons expressed here, viewtopic.php?p=25244#p25244 I still think that grub's listing generated for a Puppy should use the argument pmedia=ataflash rather than pmedia=atahd.

[gyrog]

@mikeslr,
Thanks for testing.

1. The width issue is easy, I wiil be releasing a new version with a "width=900" instead of "width=800" for that dialog.
Of course another solution would be to hide the UUID column, but I'll try the extra width first.
I'll probably add a "Cancel" button to the "Replace/Append" dialog.

2. Yes, the current code assumes that any .iso's are in fact Puppy iso's, these are not handled by "FrugalPup" because they are not "frugal" installs.
To distinguish other iso's might reuqire an extra complexity in the code, i.e. to mount each iso and look inside.
Currently the code only looks at the existence and filename of each .iso. I doubt that reliable distinction will be possible with just the filename of the .iso.
But that also impiles knowing about some distinguishing file within each iso handled.
So I look forward your email with information you have discovered about various distributions.
It might also enable non-iso-boot handling of some of these distributions.

3. For now we will have to disagree about pupmode=13 being a better default than pupmode=12.

[gyrog]

I have attached 'OtherInstalls_5.sfs.gz', gunzip to produce 'OtherInstalls_5.sfs'.

This is a cosmetic release:
Extra width to the "found installations" dialog.
"Cancel" button added to the "Append/Replace" dialog.
Added a "Searching..." message, since it sometimes takes a little while.

Note: The support for booting .iso files directly, still assumes that it is a Puppy .iso file.
It will most likely fail to generate a working boot-entry for a non-Puppy .iso file.
(Booting Puppy .iso files directly is not part of FrugalPup because they are not "frugal" installs.

Simply add 'OtherInstalls_5.sfs' as an extra sfs using 'sfs_load'.
It should appear in the "Setup" menu beside "FrugalPup".

OtherInstalls_5.sfs.gz

gunzip to produce OtherInstalls_5.sfs

(4.03 KiB) Downloaded 28 times

[gyrog]

OtherInstalls - generate grub2 boot entries

I have attached 'OtherInstalls_6.sfs.gz', gunzip to produce 'OtherInstalls_6.sfs'.

OtherInstalls now checks the contents of .iso files, and ignores any that don't contain a "puppy...sfs" file.
While I know that Puppy supports direct booting of .iso files, I don't know which others do.
And if they do, what boot parameter do they use to pass the name of the ".iso" file?

Simply add 'OtherInstalls_6.sfs' as an extra sfs using 'sfs_load'.
It should appear in the "Setup" menu beside "FrugalPup".

Later edit: Sorry, I've uploaded a new v6. The change is only cosmetic, added a "v6" to the dialog titles.

OtherInstalls_6.sfs.gz

gunzip to produce OtherInstalls_6.sfs

(4.25 KiB) Downloaded 24 times

[Clarity]

Hello @gyrog, nice. You may already be aware that "... what others do..." are Ubuntu, Debian, FATDOG, FossaDOG, DebianDOG, Rescatux, etc..

In addition to the modern PUPs, these are the ones I have in my /BOOTISOS folder that are presented at boot time via SG2D. Each boots when clicked on both my UEFI as well as my BIOS 64bit PCs.

I hope to test OtherInstalls v6 as soon as I can get free.

[gyrog]

@Clarity,
To support those "other" .iso files I need to know:

1. Looking in the content of the .iso, the presence of which file(s) can be used to identify a particular OS?
Or can some be reliably identified simply by the name of the .iso file?

2. What boot parameter needs to be defined to pass the name of the .iso file to the OS?

[Clarity]

Hi @gyrog.

Although I think you already know this, here's what I think you indicate.

All of the distros I mentioned have a loopback.cfg file in their boot partition folders.

The ISO files of those distros are kept in a /BOOTISOS folder on the SG2D USB that is booted. SG2D presents all ISO files in that folder that have the loopback.cfg in the ISO.

In use, I merely download PUPs/DOGs/Debian/Ubuntu to the /BOOTISOS folder. Upon SG2D start, I select which ISO and that ISO boots as it normally would. The booted ISO has ALL the properties we get in Frugal setup....without the need for a frugal setup.

And unlike other boot managers which allow selection, SG2D GRUB2 does NOT require any user to insure the ISO file exist as a continuous file on disk. This is one its benefits over GRUB4DOS use and may have been one of the considerations that the PUP developers considered when they added the loopback.cfg feature.

I will try to get to testing Otherinstalls, tomorrow. Its a busy time here as we come out of hiding from Covid. Everyone rushing to get things re-oriented.

This may not have answered what you raised, but it is an explanation of my use of PUPs/DOGs over the past year. Merely download to folder and boot directly.

[mikeslr]

@Clarity,
To support those "other" .iso files I need to know:

1. Looking in the content of the .iso, the presence of which file(s) can be used to identify a particular OS?
Or can some be reliably identified simply by the name of the .iso file?

2. What boot parameter needs to be defined to pass the name of the .iso file to the OS?

Perhaps the following would be helpful:

As you know 'debian dogs' are frugal operating systems designed to emulate Puppys: offer similar capabilities, advantages and methods of operation. There are two 'flavors', those which are binary compatible to a debian/devuan OS-version; and those to an Ubuntu OS-version. [IIRC, they are all constructed from 'netinstalls'].

I don't have any setup. But fredx181's post, viewtopic.php?p=2354#p2354, presents examples of all grub4dos menu.lst currently of use, or serve as guides if grub2 is the boot-loader. Such menu entries have to be manually created. There is no application to create them even from a running 'debiandog'*. This is unfortunate for several reasons: (1) emigres from 'Major' Distros are already familiar with apt-get and Synaptic. As these are the 'debiandog's' package managers exploration of frugal operating systems would involve less of a learning curve. (2) While 'debiandogs' are fine operating systems in their own right –I've used them-- they can serve as an way to ease migration to Puppys which I find both more polished and flexible. [(3) However, in all honesty, as someone who tries to advise Newbies, I sometimes wish for a way to get some stuck in a Major-distro-mindset to go elsewhere without having to face other obstacles].

At any rate, these are menu.lsting fred provided on the above post. [Tried to copy them here. But that 'broke the kernel lines' which might create confusion. Fred, later points out that the video argument wasn't necessary]. For convenience, I've attached that menu.lst. Remove the false '.gz'.

Grub4dos-debiandog-menu.lst.gz

(857 Bytes) Downloaded 16 times

You'll notice all use an initrd named initrd1.xz. The kernels are sometimes named vmlinuz1; other vmlinuz. Unlike Puppys, SaveFiles aren't available. 'debian' and 'ubuntu' dogs preserve changes in folders. The primary distinctions between them and between them and Puppies are:

vmlinuz, initrd1.xz, and the and the OS's system folder --always named either live or casper-- are physically located at the 3rd level:
Level 1=MEDIA-ROOT >
Level 2=NAMED-OS>.... top level folder
Level 3=live (for debian), casper (for Ubuntu) contains initrd1.xz, vmlinuz(.1) .
The SaveFolder which, IIRC, is always named Changes when booted from Linux formatted partitions. If the storage media is Fat32 or NTFS formatted the SaveFolder is named changes.dat (whose creation may? involve special formatting by the OS at shutdown: note, it is only on non-Linux partitions that vmlinuz rather than vmlinux1 is used. But here we are concerned only with creating menu entries).

IIRC, it isn't necessary to manually create the changes folder or changes.dat; but it must be provided for on the kernel line.

[A separate project would be the translation of frugalpup to deb format. That would overcome one of current challenges to Puppys becoming more popular: the absence of an easy way to deploy them by those running Ubuntu and debian systems
Currently, menu.lst/grub.cfg entries always have to be hand-written:
Debiandogs can install pets and I know there's a way to manually create 'deb' packages from a pet. IIRC, to do so information which Puppy's dir2pet's GUI walks you thru has to be manually written to a file. But that's a problem which fredx181 might undertake.]

Fred is always helpful. Many of the things he developed under debiandogs have been ported to Puppys, often by fred. Not the least of his creations is the portablization of web-browsers. If you have any questions regarding the 'debiandogs' don't hesitate to ask him.

-=-=-=-=-=-
* I've stricken out the erroneous misrepresentation. As I said, it's been a while since I've had a functioning DebianDog. In the interim, rcrsn51 has published deblive-multi-installer. It's discussed later in this thread.

[rcrsn51]

There is no application to create them even from a running 'debiandog'.

Not true. Since 2018, the Starter Kit project has included a GUI installer that makes GRUB menu entries.

[gyrog]

There is no application to create them even from a running 'debiandog'.

Not true. Since 2018, the Starter Kit project has included a GUI installer that makes GRUB menu entries.

Could this "Starter Kit" be used to populate boot entries into '/etc/grub.d/40_custom'?

[gyrog]

[ Level 1=MEDIA-ROOT >
Level 2=NAMED-OS>.... top level folder
Level 3=live (for debian), casper (for Ubuntu) contains initrd1.xz, vmlinuz(.1) .

So what's some examples of "NAMED-OS"?
Could this be extracted from the .iso to identify a "dog"?

I have downloaded the boot-entries file, but the difficulty is the identificatiion, creating a grub2 template from a grub4dos boot-entry should not be a big issue, once I know what OS I'm looking at.

[gyrog]

All of the distros I mentioned have a loopback.cfg file in their boot partition folders.

So, can this 'loopback.cfg' file be extracted from the ".iso"?

[gyrog]

I just did a quick review of a few ios, and I think the next part of this project is to try to develop a "lookup table" based on the filenames of the .iso' to identify what OS I'm dealing with.
First go will be to use up to the first "-" from the filename, as the key.
I could then store a boot entry template, and what information would need to be requested from the user, if any, for each entry.

Hmmm... If this works, it's all too obvious.

[mikeslr]

Hi rcrsn51. Glad you're providing some feed-back to gyrog.
I mentioned that I didn't have a functioning 'debiandog'. Actually, it's been awhile and I never got around to trying one of your build systems.
My old desktop died. In restructuring its replacement I didn't copy over the debiandog folders as I hadn't booted into them for a long while. On the subsequent occasions when a post about a debiandog stimulated "Well, that looks interesting. I'd like to try it" I was confronted with a 'how to get there' first step.

That appeared to me to be somewhere between Catch 22 and "You can't get there from here". See for example, "First-time users who need to build a bootable flash drive should read" viewtopic.php?p=4570#p4570". A quick scan of that reads as if I would have to do a manual build. Or "Recommended to run from a Debian based host system (to run from Puppy should be possible too, but needs to have debootstrap, "full" dpkg, xorriso (for creating ISO) installed)", viewtopic.php?p=14736#p14736

gyrog, my use of the phrase "NAMED-OS>" was confusing. Perhaps better would have been "USER-NAMED-OS".
To setup a frugal Puppy, you can UExtract the ISO, and copy a Puppy's system files (vmlinux, initrd, puppy_version_number.sfs, etc) into folder the user created and named, e.g. bionic1. You can setup a 2nd frugal install of the same Puppy version by repeating the above except for using a differently naming the folder, e.g. bionic2. Folder names are the user's choice: one could have just as easily been named 'my-cat'. Boot-managers will recognize two operating systems, although the user may have to manually edit grub.cfg listings, changing the Title of a duplicate Puppy to make the displayed-boot-Menu 'user-friendly'.

AFAIK, the same is true of debiandogs. Except that rather than copying system files into a named folder, you would copy the entire 'live' or 'casper' folder into the named folder. Initrd and vmlinuz are contained in the 'live' and 'casper' folders. See attached screenshot.

debiandog-jessie-ISO-deconstructed.png (153.74 KiB) Viewed 7261 times

The top-left shows top-level contents of an extracted debiandog-jessie iso. Within the 'live' folder shown on the left are its contents shown on the right. Consequently, unlike a frugally installed Puppy where initrd and vmlinuz are 2nd level-down files, under debiandogs they are 3rd level-down files: e.g. PartitionTop>USER-Name-Folder>live>initrd1.xz

Deconstruction may have revealed what to look for. As far as I know with two exceptions the names used with every 'debiandog' are identical with those names used with every other 'debiandog'; and names used with 'ubuntudogs' are the same as with every other 'ubuntudog'. The two exceptions are (1) the name of the ISO, itself; and perhaps more useful --but limited to UEFI capable OSes-- (2) each OS will contain a file similar to but specifically named as the 'jessie-X86-64.sgn' that appears in the screenshot.

[rcrsn51]

@mkeslr: You appear to have ignored this:

See the post below this one for the recommended installer tool.

-----------------------

A quick scan of that reads as if I would have to do a manual build.

No it doesn't. It is just a set of instructions for making a bootable flash drive - nothing more .

[mikeslr]

You're right, rcrsn51, I missed "See the post below this one for the recommended installer tool." Wouldn't have made any difference had I not. viewtopic.php?p=3615#p3615 has two links, "The original instructions here still apply (Post #938)" which talks about python and "This version has tools for installing the GRUB2 bootloader. Read here for details." The "here" is viewtopic.php?p=11320#p11320 "How to setup a GPT hard drive system with Grub2".
Does anyone really expect me, or a Newbie, to restructure a hard drive in order to try out an operating system?
Somewhere between Catch 22 and You can't get there from here.

And yes, "instructions for making a bootable flash drive". How do they compare to the instructions for using rufus under Windows? Download and install rufus and download an ISO. Plug in a USB-Key. Point rufus to the ISO and the Key. Click OK.

[gyrog]

@rcrsn51,
When a DebianDog or UbuntuDog is installed to a usb stick, does it produce a real frugal install on the usb stick?
(not dd'ing an iso to a usb stick).

I ask this question because if it's a real frugal install, then it would include a boot-entry for some boot looader that would be similar to a boot-entry that would be applicable to a DebianDog or UbuntuDog installed on a HD.

I've just realised that for non-Puppy frugal's, I don't need to generate a grub2 boot entry from scratch, but to copy/translate existing boot-entries as grub2 entries in '/etc/grub.d/40_custom'.
So if you are already using FrugalPup to manage your main 'grub.cfg' file, and you want to introduce a new non-Puppy frugal, you could install it to a usb stick, and then get OtherInstalls to copy/translate the working boot-entry on the usb stick.

It's even easier if you are not using FrugalPup but you want to, except that you have some non-Puppy frugal's.
You just point OtherInstalls at the current working boot-entries, and it will copy/translate the non-Puppy ones to '/etc/grub.d/40_custom'.
Then you point FrugalPup->Boot facility at your Puppy installs, to generate a 'grub.cfg' that contains them all.

Of course OtherInstalls has to be re-written to do this.

That only leaves the direct booting of .iso files. And that can probably be done via a "lookup" of the first part of the filename.
(If the filename doesn't exist in the database, I can always determine if it's a Puppy .iso by mounting it to see if it's got a 'puppy_...*.sfs' file inside.)

[gyrog]

And yes, "instructions for making a bootable flash drive". How do they compare to the instructions for using rufus under Windows? Download and install rufus and download an ISO. Plug in a USB-Key. Point rufus to the ISO and the Key. Click OK.

It might make a difference, depending on what gets written to the USB-key.
If the Linux is installed to the USB-key by dd'ing the .iso file to the USB-key, then the USB-key probably doesn't contain a boot-entry that would be suitable for use on a HD.
But if the install method produces a real frugal install on the USB-key then it will contain a boot-entry that could be used by a rewritten OtherInstalls. (See my post before this. You got in while I was composing.)

Note: FrugalPup and it's companion GUI's always produce a real frugal install, but only for Puppy.