UnderDog - allows use of another installed Linux distro

[mikeslr]

"Underdog linux is a feature of puppy linux which allows user to use the other installed linux distro. It will mount the partition on the bottom layer of unionfs." mistfire, https://oldforum.puppylinux.com/viewtop ... 96#p916896.

See the above thread for implemention --the last may be by jist, not sure if misfire updated version on OP-- and for problems and limitations through 2017. I thought it worth bringing to the Kennel's attention for future exploration.
@ rockedge, feel free to move this thread where ever you think more appropriate.
@ All; obviously, you can't post to the old Forum. So continue here, where ever rockedge decides here should be.
At the moment the last informative posts were by DANgerd0g in October of 2020. DANgerd0g ran Bionicpup64 as the Underdog of BionicPup 32. viewtopic.php?p=7299#p7299 and made the useful discoveries that to 'turn-off' underdog:
"Go to where you saved your SFS file in the File Manager (/initrd/mnt/dev_save/bionicpup64_8.0.sfs or where ever, that's just where I stuck mine)
click on the sfs file.
click "Uninstall SFS" button
Boom
To open it back up go and repeat process (except it will say "Install" instead of "Uninstall"'

Edit: Not sure how much of Barry K's January 30, 2012 post regarding Underdog continues to be relevant, but you can read it here, https://bkhome.org/archive/blog2/201201 ... istro.html
Edit 2: Both mistfire's pet and jist's script require a pre-existing SaveFile/Folder. So, for me, this mechanism is of less value than a Chrooted Puppy. I prefer running without one.
Edit 3: Both GUIs only offer to mount a partition. Not sure if it would work, at all, using a frugal Puppy as Underdog. Another plus for a Chrooted Puppy.

[mikewalsh]

@mikeslr :-

Okay. I'll "bite". Now, explain this to me, if you will?

I understand how we can run 32-bit stuff inside a 64-bit Pup, because a 64-bit kernel will essentially support 32-bit binaries & other stuff ('cos 64-bit CPU registers are additions to, and built on top of, the original x86 architecture). BUT - and this is the bit I don't understand! - how the hell can you run 64-bit stuff under/on top of/inside/within/from a 32-bit one? Surely, the 32-bit "infrastructure" can't possibly support it; how can it?

This is one concept I can't get my head round, because it goes against every known principle of containerisation which I understand, i.e., that any 'guest' system is going to be constrained by whatever its 'host's' limitations are.

I known there's some odd hybrids out there (I believe one of the 32-bit SliTaZ rolling-releases utilises a 64-bit kernel, for some strange reason), but I really don't see that having any relevance to this.....

Can't figure this one out at all. I understand a VM. I understand a chroot. But.....this??

Mike.

[mikeslr]

I too wonder. I just reported what was posted. I would think, at a minimum, the computer has to be 64-bit and would expect the 32-bit Puppy to be using a 64-bit kernel. How, otherwise, could the 64-bit applications of the Underdog be run.
But jist suggests that the name Underdog is misleading "in current puppies (v5), the "underdog" partition is actually at the top layer, so it makes sense to call it "topdog".
Perhaps it works analogous to virtualware: Somehow what actually happens is that you switch between operating systems when you select which application to open/focus on. Or like using an application in a Chroot, passing data to it from an application in the MainOS because both share the same memory: copy from the latter, paste into the former.
[FWIW, you can't run a 64-bit Chroot under a 32-bit OS. Well, at least that was my experience trying to open Chrooted-Iron with its Xenialpup64 system from dpup-stretch with it 32-bit system. But, then I wasn't using a 64-bit Kernel for dpup-stretch].
Then, again, that 'Underdog' mounts a partition rather than a puppy_xxx_version.sfs also leads me to believe that DANgerd0g's Bionicpup64 was a Full-Install. So its kernel rather than that of Bionicpup-32's was active when Bionicpup64's applications were in use.
Frankly, keeping what's going on straight is giving me a head-ache. Another good reason for me not to continue this line of exploration.

[mistfire]

Well it turns out that underdog cause havoc on Puppy system. So I made an alternative solution called sanderdog, a chrooted underdog. It doesn't mount on the bottom layer of aufs. Instead it setup another aufs mountpoint, mount a linux distro as read-only, and run programs chrooted.

Just look on the puppy old forum.

[bigpup]

Give me a reason to not delete this topic.
Based on the last post by mistfire.
Sometimes old Puppy software, we should just let die.

I do wonder why mistfire did not post link to his working software

[rockedge]

how the hell can you run 64-bit stuff under/on top of/inside/within/from a 32-bit one?

with a virtual machine perhaps. the VM machine is an emulation and just maybe a 32 bit OS can virtually emulate a 64 bit CPU and bus.

Also when I Chroot a root file system like the one WeeDog build script can produce, I have in effect an entire operating system running within the Puppy Linux host on a terminal with the chroot'ed system taking on and using the host system's kernel directly. If I use Xnest and assign it as DISPLAY:1 I can start the Xserver of the chroot'ed OS within the Xnest instance. But that system while operating separately still uses the host system kernel.

So I can run Void Linux with a Puppy Linux kernel and have persistence working in Void Linux because changes are written to the mounted rootfs directly.

[mikewalsh]

Give me a reason to not delete this topic. Give ME a good reason why you SHOULD.
Based on the last post by mistfire.
Sometimes old Puppy software, we should just let die.

I do wonder why mistfire did not post link to his working software

Whooah..!! Hold you hard, hoss. That says it all, right there. You've just described yourself in detail to the community; "modern", "forward-looking", "bang-up-to-date", always "looking to the future". Nowt wrong wi' that, but aren't you kinda forgetting the whole "raison d'etre" for Puppy's existence in the first place..? Nostalgia is definitely not part of your mindset, mate.....and you sometimes exhibit the unfortunate habit of assuming every Puppy user shares your view-point.

(Trouble is, you're not alone. Too many geeks are of precisely the same mind-set; "if it isn't brand-new, it isn't safe..." Jeez.)

(*shakes head...*)

Why DO so many geeks immediately rush headlong into the "next big thing" (sic) the instant it appears on the horizon, hmm? I've never understood this. If anything, I'm at the other extreme; I didn't invest in optical technology until it had already been declared obsolete. I didn't buy my first CD player until 2003, when MP3 players were already "all the rage". I like "tech" to prove itself, y'know?

Yeah, I'm a dinosaur. Couldn't care less. And I really couldn't give a rat's ass what anybody else thinks of me, either....I'm SO far past the stage of caring about it, I've long since forgotten what that even looks like.

(*shrug...*)

Mike.

[mikewalsh]

@rockedge :-

Well, I guess if it boils down to the kernel, I could perhaps see how this could work. A host like SliTaZ 'rolling' - the 32-bit version of which DID use a 64-bit kernel at one time.....running on a 64-bit CPU.....and running a 64-bit 'guest' within a VM.

Just an educated guess, like, but.....sound feasible to you?

Mike.

[mistfire]

Give me a reason to not delete this topic.
Based on the last post by mistfire.
Sometimes old Puppy software, we should just let die.

I do wonder why mistfire did not post link to his working software

Well I will post the sanderdog on this new forum. I made a big changes on sanderdog which prevents messing around the host. As the time of this post the newly revised sanderdog works fine. I tried to deal with dbus calls in order to interact with the host but still chrooted.

[mistfire]

@bigpup
The alternative underdog: sanderdog 2.0 was released
http://forum.puppylinux.com/viewtopic.php?f=105&t=4024

[Clarity]

2 things I see here.

@mikewalsh correctly IDs a 'truth' where the "base" system is 32bit and therefore UnderDog MUST use that base. Underdog IS NOT an emulator even as chrooting allows an 'alternate isolated' mount.

@rockedge re-enforces that understanding.

Underdog is NOT an emulator and does NOT possess emulation qualities.

I do "think" that someone 'could' make a underdog that runs an emulator like a QEMU. In doing so, they 'could, then,' fire up and Underdog with QEMU operational running an emulated X86-64 (or even an ARM/PPC) in emulation. But the effort and benefit escapes me at the moment why one would do so on a 32bit OS.

Hope this is helpful