One can do UnderDog without official Puppy Support

[s243a]

The idea of underdog is to have puppy exist as a layer on top of another version of linux. Typically, one might do this with a more mainstream version of linux. However, I recently tried doing this where 32bit dpup buster ran as seperate layers underneath a 64bit dpup buster.

I used it so I could get 32bit support for wine using the lastest files from the wine repos. I used pkg to download the packages. Some modifications are required to run pkg in a 32bit chroot system, while using a 64 bit host. See:

https://gitlab.com/sc0ttj/Pkg/issues/97

In this setup, you can use my psandbox script (thread, project) to create the chroot system. The chroot system is used to install packages for the underdog. To build the underdog, I didn't have any luck appending the chroot folder (although this approach may be possible) but I was able to build my underdog by individually appending the layers:

Code: Select all

busybox mount -t aufs -o remount,append:/initrd/mnt/dev_save/dpup_buster/32/PAE/8/UEFI/09022020/bustersave=rr /
busybox mount -t aufs -o remount,append:/mnt/r+32+PAE+8+UEFI+09022020+puppy_buster_8+0+0+sfs__de3a9=rr /
busybox mount -t aufs -o remount,append:/mnt/er+32+PAE+8+UEFI+09022020+zdrv_buster_8+0+0+sfs__fda9f=rr /
busybox mount -t aufs -o remount,udba=reval unionfs /

Eventually, I'll make scripts to better automate this.

[s243a]

I just remembered the following project by mistfire:

Sanderdog 1.5: load and use other linux distro in puppy

I should compare notes.

[mikeslr]

Hi s243a,

It's 6 AM here, normally 3 1/2 hours before I get up. And I haven't had my 2d cup of coffee. So, I may still be fuzzy-headed. But, your post suggested what may be an important project on its own.

To a significant extent 64-bit is the near future of Linux computing. Most usable Windows Programs are those created for 32-bit XP. WineHq warns that it doesn't provide malware protection. Wine in a Chroot environment seems like a proper response.

Wine in Chroot must be able to use Xp-portables, i.e. not installed to /drive_c/program files. Perhaps drive_x also within the chroot environment?

[rockedge]

I do this using FirstRib (WeeDog) on occasion using wiak's script, but the idea works. I go as far as setting up Xnest to run the chroot'ed system in sometimes

Code: Select all

# mount_chroot.sh
# Revision 0.0.7 with udev support. Date: 01 July 2019
# wiak 23 May 2019+; Licence MIT (aka X11 license)

# This script is provided purely as a convenience so you don't have to
# keep entering the following commands to chroot into firstrib_rootfs

# mount a directory to share between host system and firstrib_rootfs system.
# WARNING! I've commented this out because can be dangerous, though okay if
#   you know what your doing (I zapped my main OS because I used rm -rf whilst mounted...)
# Example (may need modified, or commented out, depending on set up of your system and
# what dir you want to share):
# mkdir -p firstrib_rootfs/mnt/home
# mount --bind /mnt/home firstrib_rootfs/mnt/home

# bind mount host virtual filesystes required for chroot into firstrib_rootfs to work on host system
mkdir -p firstrib_rootfs/run/udev
mount --bind /proc firstrib_rootfs/proc && mount --bind /sys firstrib_rootfs/sys && mount --bind /dev firstrib_rootfs/dev && mount -t devpts devpts firstrib_rootfs/dev/pts && mount --bind /tmp firstrib_rootfs/tmp && mount --bind /run/udev firstrib_rootfs/run/udev && cp /etc/resolv.conf firstrib_rootfs/etc/resolv.conf 

# chroot into firstrib rootfs and execute a /bin/sh process from that root filesystem
chroot firstrib_rootfs sh

# When finished working in the above chroot you need to enter exit in the chroot shell
# and then clean up the above mounts.
# As a convenience you can run the provided umount_chroot.sh script that contains
# the commands to clean up (umount) the bind mounts that were used.

\

[s243a]

Hi s243a,

It's 6 AM here, normally 3 1/2 hours before I get up. And I haven't had my 2d cup of coffee. So, I may still be fuzzy-headed. But, your post suggested what may be an important project on its own.

To a significant extent 64-bit is the near future of Linux computing. Most usable Windows Programs are those created for 32-bit XP. WineHq warns that it doesn't provide malware protection. Wine in a Chroot environment seems like a proper response.

Wine in Chroot must be able to use Xp-portables, i.e. not installed to /drive_c/program files. Perhaps drive_x also within the chroot environment?

Yes we could do this all in a chroot rather than having the underdog layers mounted on the host rootfs. This is an interesting idea. I just wanted to get Studio tax working which I appear to have done so using dpup buster 32 and using the latest debian staging wine repos.

[jrb]

I just wanted to get Studio tax working which I appear to have done so using dpup buster 32 and using the latest debian staging wine repos.

Full details, Please!

[mistfire]

-deleted-

[s243a]

I just wanted to get Studio tax working which I appear to have done so using dpup buster 32 and using the latest debian staging wine repos.

Full details, Please!

See thread, Insall Wine from Offical Repos Using "pkg"