DpupBuster CE 64 and 32 bit

[marcelo4768]

no detecta el mouse, touchpad del notebok.

[josejp2424]

no detecta el mouse, touchpad del notebok.

problemas de drivers? . no detecta.

[s243a]

The following "Synergy Package" (i.e. synergy-1.7.6-x86_64-1_SBo.tgz) was built for fatdog64 but works on dpup buster:

Here are some random packages:

mono-4.8.0.495-x86_64…Bo.tgz
avahi-0.6.31-x86_64-1_SBo.tgz
libgdiplus-4.2-x86_64-1…Bo.tgz
dulwich-0.9.0-x86_64-1…Bo.tgz
spawn-fcgi-1.6.4-x86_6…Bo.tgz
synergy-1.7.6-x86_64-1_SBo.tgz

I built these a while ago in fatdog710 beta. The extension looks right. Let me know if there any problems and I'll remove and or rebuild the file.

I didn't compile avachi with all it's options. The options I used are as follows

Code: Select all

./configure \
  --prefix=/usr \
  --libdir=/usr/lib${LIBDIRSUFFIX} \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --mandir=/usr/man \
  --docdir=/usr/doc/$PRGNAM-$VERSION \
  --enable-tests \
  --disable-static \
  --disable-monodoc \
  --disable-autoipd \
  --enable-python-dbus \
  --enable-pygtk\
  --enable-glib \
  --enable-dbus \
  --enable-python \
  --enable-gtk \
  --enable-gtk3 \
  --enable-qt4 \
  --disable-qt3 \
  --enable-core-docs \
  --enable-compat-howl \
  --enable-compat-libdns_sd \
  --with-dbus-sys=/etc/dbus-1/system.d \
  --with-avahi-user=avahi \
  --with-avahi-group=avahi \
  --with-avahi-priv-access-group=netdev \
  --with-distro=slackware \
  --program-prefix= \
  --program-suffix= \
  --build=$ARCH-slackware-linux \
  $MONO

Slackbuild file attached.

http://www.murga-linux.com/puppy/viewto ... 313#956313

To install download synergy, than:

Code: Select all

pkg --get libqt4-network
pkg --get libqtgui4
pkg -i synergy-1.7.6-x86_64-1_SBo.tgz #In the download directory

Mono might also be required...but probably not.

I may eventually try compiling these packages on buster. I tested this using synergy between dpup buster64 and the lastest fatdog64 (i.e. "Fatdog64-810 Beta (9 Dec 2019) ")

[Smithy]

Hi Joseph,
Any reason why the 32 bit version is 420mb? The 64 bit version is also 420mb.
I would have thought it might be nearer 210mb or so.
I tested the 64 bit version. (Latest version).
1. Changing cursors broken.
2.Theme changes. JWM broken in various places.
3. Frisbee persistent even when trying to change to SNS on taskbar.

Nice distro and pulse audio with pasytray implementation interesting!

[nilsonmorales]

Marcelo4768 escribió

no detecta el mouse, touchpad del notebok.

Adjunto archivo e instrucciones
https://my.pcloud.com/publink/show?code ... 9CBV8VKTty
1- Descomprimir el archivo fixtapflsynclient.tar
2- borrar los archivos ocultos /root/.flsynclient y /root/.flsynclient-tap-to-click
si lo hubiera
3- colocar el archivo .flsynclient-tap-to-click descomprimido en /root
4- Reemplazar el archivo flsynclient en /usr/bin
5- Reiniciar X ( cltrl+alt+backspace te lleva al prompt y escribes xwin para reiniciar X, servidor grafico, escritorio como se llame )
6- Abrir la terminal y escribir flsynclient
7- Ir a la pestaña tapping y configurar left finger one button

Ahora ya podras hacer click dando 1 toque al touchpad para configurar doble click creo que debes hacerlo desde las opciones de Rox.

[marcelo4768]

como todo eso sin mouse ?

[josejp2424]

[quote="marcelo4768"]como todo eso sin mouse ?[/quote

Es raro. No te habrá cargado el zdvr.
]

[s243a]

sandbox.sh doesn't work for me:

Code: Select all

[root@dpupbuster64 ~] $ sandbox.sh

mount-FULL: /mnt/sb/fakeroot: wrong fs type, bad option, bad superblock on aufs, missing codepage or helper program, or other error.
Unable to mount aufs br:/mnt/sb/sandbox=rw:Error:=ro:Expected=ro:at=ro:least=ro:6=ro:tokens=ro:for=ro:--checklist,=ro:have=ro:4.=ro:Use=ro:--help=ro:to=ro:list=ro:options.=ro
[root@dpupbuster64 ~] $ 

It was supposedly fixed:

fix sandbox.sh

testing (#2)
@wdlkmpx
wdlkmpx committed on Mar 25, 2018 1 parent a31da76 commit e29f4217baea1c394a59ab0957678d2876f5fa5d

I want to learn about sandbox.sh to run a puppy in a chroot so I probably will need to modify it but first I wanted to see if it worked.

Here's some info on it:
http://distro.ibiblio.org/fatdog/web/faqs/sandbox.html

Edit: This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"

[jamesbond]

sandbox.sh
...
This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"

sandbox.sh used to work. I made the original commit and I made sure that it worked. It only did not work when running off the LiveCD without savefile, because /tmp was a symlink and not a real mounted filesystem, and that could easily be "fixed". When booting with a savefile/savedir, it worked. I had a few posts on this forum (can't find it now) that used sandbox.sh for testing.

Over the years changes to woof-CE apparently made it stops working, and a "fix" was committed in Jan 2018. Sadly the "fix" doesn't work, because it does not address the problem.

The root cause of this particular all the problem is because certain aufs mountpoints cannot be found in /proc/mounts.

See this for yourself. In terminal, type "cat /sys/fs/aufs/si_*/br0". You will see the mountpoint for the topmost layer (either pupsave or tmpfs).
Now "cat /proc/mounts" and see if that mountpoint is listed in there.
Experiment with pfix=ram and with savefile/savedir loaded, and you will see the same result.

This was __certainly__ not the case in the past, and something has been changed in puppy's initrd's init, probably in initrd-skeleton.

Now, demanding rollback to changes to puppy's initrd's init to accomodate one lowly app like sandbox is probably too much, so we just have to live with whatever it is and make sandbox.sh to work again.

The fix is NOT by doing this:

Code: Select all

items="$(echo "$items" | grep squashfs)" #only need SFS's

But it should by doing

Code: Select all

items="$(echo "$items" | grep -E "XXXX|YYYY")" 

where XXXX and YYYY represents the top-layer mountpoints when puppy runs with savefile and without savefile (on upup bionic, this would be /initrd/mnt/dev_save and /initrd/mnt/tmpfs/pup_rw).

So my suggestion is to revert that particular "fix" commit and then work out the proper fix.

Until this is done, sandbox functionality should be considered BROKEN and sandbox.sh should be renamed to sandbox-BROKEN.sh until it is fixed.

(NOTE: Though, I would argue, "proper fix" is to make sure that all branches of aufs layers are visible in the /proc/mounts; because with the fix I suggested above, the sandbox will lose its ability to use existing customisations done in the topmost layer (because the topmost layer is now inaccessible) - which reduces it functionality by much).

[s243a]

sandbox.sh
...
This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"

sandbox.sh used to work. I made the original commit and I made sure that it worked. It only did not work when running off the LiveCD without savefile, because /tmp was a symlink and not a real mounted filesystem, and that could easily be "fixed". When booting with a savefile/savedir, it worked. I had a few posts on this forum (can't find it now) that used sandbox.sh for testing.

Over the years changes to woof-CE apparently made it stops working, and a "fix" was committed in Jan 2018.

Was the original code committed before puppy started using save folders?

Code: Select all

items=$(
{ echo ==mount==; cat /proc/mounts; 
  echo ==losetup==; losetup-FULL -a; 
  echo ==branches==; ls -v /sys/fs/aufs/$AUFS_ROOT_ID/br[0-9]* | xargs sed 's/=.*//';
  echo "==finised so print=="; } | \

https://github.com/puppylinux-woof-CE/w ... -550190880

Sadly the "fix" doesn't work, because it does not address the problem.

The root cause of this particular all the problem is because certain aufs mountpoints cannot be found in /proc/mounts.

by "cannot be found", I presume that you mean, the script can't find them but they are there. Perhaps though, once upon a time the save folder was directly mounted but I don't think that is the case now. Instead, I think only the partition where the savefolder resides is mounted.

See this for yourself. In terminal, type "cat /sys/fs/aufs/si_*/br0". You will see the mountpoint for the topmost layer (either pupsave or tmpfs).

With my partial fixes:

Code: Select all

[root@dpupbuster64 ~] $ cat /sys/fs/aufs/si_*/br0
/initrd/mnt/dev_save/dpup_buster/1-07092019/dpupbuster64save=rw
/mnt/sb/sandbox=rw

Now "cat /proc/mounts" and see if that mountpoint is listed in there.

The top layer is sort of there. It shows up for me as:

Code: Select all

/dev/sda2 /initrd/mnt/dev_save ext4 rw,noatime 0 0

except that it's missing the path to the save folder, "/dpup_buster/1-07092019/dpupbuster64save" which I don't think is really a mount point (even though it is the top layer).

Experiment with pfix=ram and with savefile/savedir loaded, and you will see the same result.

Maybe later.

This was __certainly__ not the case in the past, and something has been changed in puppy's initrd's init, probably in initrd-skeleton.

You can get the topy layer via "cat /proc/mounts" by appending to dev_save the path found in "/etc/rc.d" to the save location. From /etc/rc.d/PUPSTATE

Code: Select all

PUPSAVE='sda2,ext4,/dpup_buster/1-07092019//dpupbuster64save'

Now, demanding rollback to changes to puppy's initrd's init to accomodate one lowly app like sandbox is probably too much, so we just have to live with whatever it is and make sandbox.sh to work again.

Agreed.

The fix is NOT by doing this:

Code: Select all

items="$(echo "$items" | grep squashfs)" #only need SFS's

It's a partial fix but wdlkmpx, didn't really do this correctly anyway, because when we loop through the loop devices, the mount type of "squashfs" gets replaced with the name of the squash file. That's why my improvment to wdlkmpx partial fix was to use the following grep statement:

Code: Select all

items="$(echo "$items" | grep "\(squashfs\|\.sfs\)")" #only need SFS's

but you're correct that we might also want to mount the save layer, so if we fix the awk code then we can get rid of this grep statement that was added by wdlkmpx.

But it should by doing

Code: Select all

items="$(echo "$items" | grep -E "XXXX|YYYY")" 

where XXXX and YYYY represents the top-layer mountpoints when puppy runs with savefile and without savefile (on upup bionic, this would be /initrd/mnt/dev_save and /initrd/mnt/tmpfs/pup_rw).

These are symlinks which would be a different way to get the top layer and after much head scratching, I see the issue. The issue is that the path to the save layer is different than the mount point but the mountpoint is used as the key when looking up the mounttype in the following statment:

Code: Select all

print $0, mounttypes[$0], "on"

/rootfs-skeleton/usr/bin/sandbox-rw.sh#L112

So when we try to lookup the mounttype using the path to the save file, then it returns nothing, which breaks the gui, because the gui expects three values but it only got two values. wdlkmpx's code changes suggest the viewpoint, that for a sandbox, we don't want the save location anyway. Otherwise it isn't really a sandbox. However, this isn't true if we mount the save-layer as readonly. That way it is still a sandbox. To fix the code we first check that mounttypes[$0] returns a value with a length greater than zero, otherwise maybe print some other value to indicate that it is not a mount point.

BTW, the comparison expression is wrong "else if (mode=4)" but it doesn't seem to matter (I think that this always returns true). For equality comparison it should be mode == 4.

]So my suggestion is to revert that particular "fix" commit and then work out the proper fix.

Until this is done, sandbox functionality should be considered BROKEN and sandbox.sh should be renamed to sandbox-BROKEN.sh until it is fixed.

I don't think the fix is that hard so no need to revert the previous so called fix or call it broken.

(NOTE: Though, I would argue, "proper fix" is to make sure that all branches of aufs layers are visible in the /proc/mounts; because with the fix I suggested above, the sandbox will lose its ability to use existing customisations done in the topmost layer (because the topmost layer is now inaccessible) - which reduces it functionality by much).

I don't think that this is actually a mount point if it is a save folder. I suppose we could separately mount the save folder but that would be redundant and might cause other issues (e.g. slowdown unmounting during shotwown.).

[jamesbond]

Was the original code committed before puppy started using save folders?

Yes

by "cannot be found", I presume that you mean, the script can't find them but they are there. Perhaps though, once upon a time the save folder was directly mounted but I don't think that is the case now. Instead, I think only the partition where the savefolder resides is mounted.

Correct.

except that it's missing the path to the save folder, "/dpup_buster/1-07092019/dpupbuster64save" which I don't think is really a mount point (even though it is the top layer).

Okay. I see you have a point here. I've checked more thouroughly, yes, for LiveCD and savedir, this is the case. For savefile, then br0 is a mountpoint.

These are symlinks which would be a different way to get the top layer and after much head scratching, I see the issue. The issue is that the path to the save layer is different than the mount point but the mountpoint is used as the key when looking up the mounttype in the following statment:

Correct.

So when we try to lookup the mounttype using the path to the save file, then it returns nothing, which breaks the gui, because the gui expects three values but it only got two values.

Correct.

wdlkmpx's code changes suggest the viewpoint, that for a sandbox, we don't want the save location anyway. Otherwise it isn't really a sandbox. However, this isn't true if we mount the save-layer as readonly. That way it is still a sandbox.

Most of the time we want to have a copy of the savelayer in the sandbox, otherwise you don't have /etc/resolv.conf (no network), etc etc. But that's why we have a dialog to enable the user to choose exactly which layer is to be included in the sandbox.

To fix the code we first check that mounttypes[$0] returns a value with a length greater than zero, otherwise maybe print some other value to indicate that it is not a mount point.

After thinking about it, here is my updated suggestion. The $items contains 3 fields:
- path
- description
- "on"

Out of this 3 lines, only the first one ("path") is actually used in the next processing.
Our problem is because the top-layer isn't listed in /proc/mounts, the "description" part (which, for SFS, will show the SFS name, and for save-layer would normally show filesystem type (ext3, etc)) is empty. But it is not actually necessary for the rest of the processing, so my suggestion is to modify the awk code so that if mounttypes[$0] is empty, then just output something, e.g file system, or even blank.

So,

Code: Select all

print $0, mounttypes[$0], "on" 

becomes

Code: Select all

if (mounttypes[$0])
    print $0, mounttypes[$0], "on"
else
    print $0, "filesystem", "on" 

With this changes I can display the layer selection dialog and start sandbox successfully, in LiveCD mode, in savefolder, and in savefile, if I also comment out this line:

Code: Select all

#items="$(echo "$items" | grep "\(squashfs\|\.sfs\)")

BTW, the comparison expression is wrong "else if (mode=4)" but it doesn't seem to matter (I think that this always returns true). For equality comparison it should be mode == 4.

There is nothing wrong with this code.

I don't think the fix is that hard so no need to revert the previous so called fix or call it broken.

I leave it to the maintainer or whoever is going to offer a patch to decide what to do - whether to revert and apply a new fix, or just apply a fix on to of the existing one.

I only suggest to rename it to -BROKEN so that people don't use it until it is fixed. If the fix can be given/applied in the next few hours then obviously no need to do so.

PS: If you offer a pull request, please make sure you fix sandbox-rw.sh too.

[s243a]

PS: If you offer a pull request, please make sure you fix sandbox-rw.sh too.

I created a pull request:

fix sandbox.sh & sandbox-rw.sh #1739

Both sandbox.sh and sandbox-rw.sh are broken because:

1. The old script incorrectly assumed a savefolder was a mount point:
2. wdlkmpx, tried to fix this by only allowing sfs files but used the wrong grep expression, which returns nothing.

This fix uses the base filename for the save folder and consequently mitigates the need for wdlkmpx prevoius attempted fix. See discussion:
http://murga-linux.com/puppy/viewtopic. ... 13#1047913

I so far only tested that we can successfully create the sandbox, when running puppy with a save folder. This is an improvement over the previous code but if people want we can do more testing prior to merging.

but for some reason, I don't see it on my github notifications page. Is this normal or am I on some kind of woof-CE naughty list?

[s243a]

I installed ssh-server on DpupBuster. The folder /run/sshd seems to get deleted upon reboot. I recreated this folder with the standard permissions...that you get by creating a new folder in the file manager. Not sure if these permissions are correct. For the ssh server /run/sshd is needed when using the privilege separation option on your ssh server. Privilege separation is the default behavior for the ssh server in openssh.

This is probably a woof-CE bug, so I also reported it on github:
https://github.com/puppylinux-woof-CE/w ... ssues/1755

[s243a]

Hello josejp2424 ,

someone is reporting that your wine pet isn't working correctly. I suspect they are wrong but I haven't tried it. See post:
http://murga-linux.com/puppy/viewtopic. ... 68#1051568

[01101001b]

here's a 32bit compatibility.sfs made from radky's busterpup32.

Is this the official link for this file?

https://sourceforge.net/projects/dpup/files/64bit/
there is the buster repo

Just a short story:

On March 01, I saw josejp2424 posted a new version of "32bit_compatibilty_dpupbuster64.sfs" (sic) in SourceForge so I downloaded it (I'm still using DpupBuster64 RC1. It works beautifully for me).

Some days later, trying to edit an image with MSPaint (yes, hands down the best app for minor editing on an image, like cropping or pointing out regions using coloured ellipses or lines. Maybe mtPaint is way more powerful, but it's counterintuitive and cumbersome for me) via Wine of course, the program showed an error message, explaining being unable to deal with jpeg/png formats.

WHAT?? What changed??

Only thing I could put my finger on was that update.

Not very convinced, I restored the previous version (I always do backups).

Problem solved Amazing.

Sharing this hoping it might be useful for somebody.

josejp2424, thank you so much for so much effort of yours. I really appreciate it (and enjoy it )

[mouldy]

Bionicpup on desktop was getting bit crashy, so did fresh install, this time of dpupbuster64.

Installed wine64-5.0-rc1_v5.0-rc6.pet and it actually went pretty smooth for a wine installation. I just couldnt get portable wine I had been using to work in dpupbuster64.

However my main reason to install wine is to run KindleForPC 1.17, last version Kindle that will work in WINE that I know of. It wont install. Oh everything else works and this maybe first WINE I've used that wine"ie_explorer" will actually surf. Wouldnt recommend using it, but still wasnt all crashy with errors galore like in past.

Anyway when trying to install KindleForPC117, I get this:

[root@dpupbuster64 ~/my-applications] $ wine /root/my-documents/KindleForPC117.exe
001b:err:module:load_so_dll failed to load .so lib "/usr/bin/../lib/i386-linux-gnu/wine/winebus.sys.so": libudev.so.1: wrong ELF class: ELFCLASS64
001b:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\WineBus": c0000142
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"WineBus" failed to start: 1114

The Kindle installer does try to run and little popup that its getting packages ready, then crashes before it opens. Mono and gecko installed though Kindle app doesnt need them. Usually this old Kindle is one of easier apps to install and run. I did find and install 32bit libudev.so.1 but didnt help.

Like say 32bit compatibility sfs installed. Other 32bit apps I use have no problems, even one ancient solitaire game called GoldenBird from win98 era that does have problems on some versions WINE.

[mouldy]

I would still be curious how to make it work. But its a mute point.

I finally used package manager to install PlayOnLinux. Found instructions to modify it so it will run in root. I let it download and install 32bit WINE 2.2 and KindleForPC117. Kindle now works though GoldenBird doesnt. But Kindle is the important app for me. Why they make it so hard to install 32bit WINE on 64bit system is beyond me. It should just come as part of the 64bit version cause most people use WINE to run older 32bit apps I think. Least I do.

UPDATE: Been playing more with PlayOnLinux. As annoying as it can be, it has some real virtues. I found I could choose to custom install a win app, but then choose version WINE I want to use. So I told it to use 32bit WINE 5.3. It downloaded and installed 5.3, I then directed it to my copy of windows programs and installed new instance of both Kindle 117 and GoldenBird. Both worked. I tried later version Kindle but it crashed during install. WINE still hasnt caught up enough to run newer versions.

PlayOnLinux takes lot getting used to if you are used to using WINE directly. You are adding a middleman. But there is NO easier way to install WINE, especially 32bit WINE on 64bit system, the version or versions of WINE you want. No idea how well it would work on other Puppies, but well worth trying. Works great on dpupbuster64.

[rockedge]

Why they make it so hard to install 32bit WINE on 64bit system is beyond me. It should just come as part of the 64bit version cause most people use WINE to run older 32bit apps I think. Least I do.

I agree! would make total sense

[jplt3]

Hi all ,

i'am about to be mad !

I want to install DpupBuster CE 64 : dpupbuster64-8.0.0-uefi-RC-2-28122019.iso

on an UEFI cheap machine :

Schneider SCL14
Processor : Intel Atom x5-Z8350
RAM : 2 Go
eMMC : 32 Go

it is a 64bit machine but the bios is a 32bit !!!

So i boot the machine via a usb key with dpupbuster64-8.0.0-uefi-RC-2-28122019 on it,
great it work quiet good .

But now how to install dpupbuster on this machine :

otherwise i have already an ubuntu 18.04 installed on it but it corrupted ! that's why i want a puppy on this machine

the harddrive :

Code: Select all

/dev/mmcblk0p1 - 512 Mo - boot,esp
/dev/mmcblk0p2 - 18 Go  -  ubuntu 18.04 
/dev/mmcblk0p3 - 10 Go  -  where i want to put my puppies

So in /dev/mmcblk0p1 i have :

Code: Select all

EFI/boot/bootia32.efi
			  bootia64.efi
efi.img
grub.cfg

Code: Select all

grub.cfg

menuentry "DpupBuster64 8.0.0" {
set root='(hd0,3)'
linux /vmlinuz  pmedia=ataflash pfix=fsck
initrd /initrd.gz
}

menuentry "Shutdown" {
	halt
}

menuentry "Reboot" {
	reboot
}

Sadly puppy_dpupbuster64_8.0.0.sfs is not found !

I really don't know what to do ?

Thanks for your help.

[mikeslr]

@ jplt3,

Thought your problem looked familiar. See this thread, http://www.murga-linux.com/puppy/viewto ... 43#1050343