Fatdog64-710 Final [4 Dec 2016]

[FanDog]

Yep.. same output! (I loaded through control panel, tell me if after reading this do you still want me to load from the command line)

except it was 12 here but it finds the aufs fine..

> masking /usr/bin/node and turning it into a non-executable file.

went to check permissions and I think I found the problem, not quite that but your guess were pretty close. It's still pointing to /opt/node-4.2.3/bin/node

(which wasn't working even before I uninstalled it from gslapt.. since I had to manually symlink)

so... should I just grind through the linking oooooor.. do u wanna try and find out why it hasn't uninstalled properly? (and I guess even installed in the 1st place)

[Gobbi]

... but sound does not work. I tried to go through the options of trying other Sound Cards.

Gigabyte F2A88XM-D3H should have an Realtek ALC887 sound card onboard . If you are using external speakers this card (analog sound ) should work .
Also your APU A8-7600 has one ( digital sound ) which could be used if you use an HDMI cable .For this to work , from my previous experience , one should use the Radeon module . I remember I also had to use radeon.audio=1 boot parameter . Using HDMI , to activate sound one should enter alsamixer and press 'm' key .

AMD has a driver set called Crimson, which has an install package with Ubuntu. RHEL,

Or it should work with AMD proprietary driver , but this it's hard to do in FD 710 . I think the Ubuntu, RHEL packages don't install well because FD 710 has a different stucture .

... SAMSUNG (2- AMD High Definition Audio Device)
Digital Audio (S/PDIF) (High Definition Audio Device) (2x)

The Samsung could be the optical output ...

It is important to select the corect sound card also in VLC settings , otherwise you won't hear anything in VLC .

[step]

> masking /usr/bin/node and turning it into a non-executable file.

went to check permissions and I think I found the problem, not quite that but your guess were pretty close. It's still pointing to /opt/node-4.2.3/bin/node

I'm glad you found the culprit.

(which wasn't working even before I uninstalled it from gslapt.. since I had to manually symlink)

so... should I just grind through the linking oooooor.. do u wanna try and find out why it hasn't uninstalled properly? (and I guess even installed in the 1st place)

You don't need to grind through the linking. Clean your savefile from any debris from your early experiments then start enjoying node7

I can guess what happened. The node4 package from an alien distro that you installed (with gslapt???) first, went into your savefile because a package - unlike an SFS file - goes into the savefile by definition. The link /usr/bin/node -> /opt/node-4.2.3/bin/node that you added manually also went into your savefile. When you uninstalled the node4 package, gslapt couldn't know about the /usr/bin/node link because it was done outside its control. Then you loaded the node7 SFS into the layered filesystem. SFS files are under the savefile by definition, which enables edit any file that's included in the base SFS.

At that point your layered filesystem looked like this:

Code: Select all

top layer (savefile):   /usr/bin/node -> /opt/node-4/usr/bin/node DANGLING

/aufs/pup_ro12 layer (node7 SFS): /usr/bin/node -> /opt/node-7/usr/bin/node  EXISTING, EXECUTABLE

The top layer /usr/bin/node masks off the pup_ro12 layer /usr/bin/node. The shell only sees the top layer, and finds a dangling link, which isn't executable by definition. The shell doesn't audit /usr/bin contents; it merely looks for valid executables in /usr/bin and in the other paths in your $PATH variable.

As a side note, expect gslapt to be able to fully remove only the packages that were installed from gslapt itself or by slapt-get, and that are packaged for Fatdog64. Packages from alien distros may not install/uninstall cleanly and, at any rate, YMMV (even for native Fatdog packages sometimes - we all make mistakes).

The installpkg/removepkg command pair also works well for Fatdog64 packages. However gslapt provides a host of package management features, so we recommend gslapt as the goto tool.

[FanDog]

@ step

> Clean your savefile from any debris from your early experiments then start enjoying node7

Cool! But how exactly. (more details below)

> I can guess what happened.

Aha, but we may have to dig deeper, because that seems to be the opposite of what happened.. I deleted the symlink before installing the sfs (and it loads every boot up), shouldn't it be able to add the proper link then?

> (with gslapt???)

I added as a source when I was wrestling with making firefox work (I described it best on the puppy linux thread I referenced on my 1st post here, before I was redirected from there basically, the sources was pointing to 702 repo, which seemed to work but didn't quite have everything). Also, from alien I tried node 6, which installed fine, but then a package there complained it needed GLIBCXX 3.4.20, and current Fatdog has 3.4.19 and I assume would be some infraestructure work (meaning it could potentially break many other stuff) to upgrade.. so I went back to (now proper ) gslapt souces, which have node 4. (I also describe this better at the puppy linux thread)

Your argument could still work tho.. provided this is also valid for apt installed links (et al), and your diagram does suggest it all goes to opt/node-x ... There IS an 'umbrella' link there pointing to the "current" version simply as /opt/node. : )

So, deleting that and reloading the sfs should be enough?

Regarding cleaning the savefile.. is removing the /opt/node-4 stuff enough? I always try to do everything through gslapt, I already removed from there.. in which case your comment doesn't give me much confidence removepkg would do anything beyond it.. or should I try it?


Edit: btw.. there isn't any node-7 inside opt/

[step]

@FanDog,
1. Boot without any node sfs loaded - you must boot without any node sfs loaded
2. Remove any node package you see installed - you can use gslapt for this
3. Inspect the file system carefully. Any /opt/node? Remove it from rox. Any dangling links to /opt/node from usr/lib and /usr/lib64 and underneath? Remove them. Any files/folders named *node* or *npm* (* is for wildcard expansion) in /usr/lib and /usr/lib64 and underneath? Remove them. Then remove /usr/bin/node if you still have one.
4. Shutdown and save your savefile.
5. Reboot without any node sfs loaded. If one is loaded go to step #1.
6. Load the node7 sfs I linked to. Open a terminal window, type

Code: Select all

losetup -a
ls -l /usr/bin/node /usr/lib/node_modules/npm 
node

post all output you got to this thread.
P.S. the node7 SFS doesn't load anything under /opt, that's right.

[FanDog]

@step

hi.. I think I've done everything right. Here's the output:

Code: Select all

spot$ su 
Password:  
spot$ losetup -a 
/dev/loop0: 0 /kernel-modules.sfs 
/dev/loop1: 0 /fd64.sfs 
/dev/loop2: 0 /aufs/devsave/[mysavefilename] 
/dev/loop10: 0 /aufs/devsave/32bit-fd64_710.sfs 
/dev/loop11: 0 /aufs/devsave/fd64-devx_710.sfs 
/dev/loop12: 0 /aufs/devsave/node-7.3.0-x86_64-1.sfs 

spot$ ls -l /usr/bin/node /usr/lib/node_modules/npm  
ls: cannot access /usr/bin/node: No such file or directory 

/usr/lib/node_modules/npm: 
total 293 

-rw-rw-r--  1 root root    933 Dec 20 15:00 appveyor.yml -rw-rw-r--  1 root root  16220 Dec 20 15:00 AUTHORS drwxrwxr-x  3 root root    107 Dec 20 16:34 bin -rw-rw-r--  1 root root 252999 Dec 20 15:00 CHANGELOG.md drwxrwxr-x  2 root root     59 Dec 20 16:34 changelogs -rwxrwxr-x  1 root root     48 Dec 20 15:00 cli.js -rwxrwxr-x  1 root root    521 Feb 16  2016 configure -rw-rw-r--  1 root root    503 May 26  2016 CONTRIBUTING.md drwxrwxr-x  5 root root     63 Dec 20 16:34 doc drwxrwxr-x  4 root root    117 Dec 20 16:34 html drwxrwxr-x  6 root root   1077 Dec 20 16:34 lib -rw-rw-r--  1 root root   9742 Oct 18  2016 LICENSE -rw-rw-r--  1 root root    156 May 26  2016 make.bat -rw-rw-r--  1 root root   4946 Dec 20 15:00 Makefile drwxrwxr-x  5 root root     51 Dec 20 16:34 man drwxrwxr-x 84 root root   1683 Dec 20 16:34 node_modules -rw-rw-r--  1 root root   5527 Dec 20 15:00 package.json -rw-rw-r--  1 root root   4673 Dec 20 15:00 README.md drwxrwxr-x  2 root root    276 Dec 20 16:34 scripts 

spot$ node 
sh: node: command not found 
spot$ npm 
sh: npm: command not found

[TechnoShaman]

VirtualBox 64bit with 64bit guest hosting capabilities on Fatdog64-710

[step]

@FanDog, why are you doing it as user spot instead of as user root? Did you login as spot? Can you try again without spot in the way?

Add one more command output, please:
find /aufs/pup* -name node -ls

- do it before loading the node sfs
- the after loading the node sfs

always without impersonating spot.

Thank you.

[FanDog]

@step
because, as you know, some applications do not work well under root
then, since was surfing there, how would I copy&paste between desktops? I thought "su" would be enough...

anyways, re-did the commands, the output looks the same to me.

here's the new one:

Code: Select all

# find /aufs/pup* -name node -ls 
# find /aufs/pup* -name node -ls 
     3 33657 -rwxrwxr-x   1 root     root     34464373 Dec 20 16:34 /aufs/pup_ro12/usr/bin/node
     6    0 drwxrwxr-x   4 root     root          764 Dec 20 16:34 /aufs/pup_ro12/usr/include/node
  3405    0 drwxrwxr-x   2 root     root           82 Dec 23 19:19 /aufs/pup_ro12/usr/share/doc/node
# node
sh: node: command not found

I did boot with sfs tho.. the 1st line is after unloading it, and the 2nd after reloading it. Let me know if boot time is important. (btw, a little "bug" in the SFS loader, it can't remember the subdir I tell it to, after apply).

thanks.

[jake29]

Can anyone suggest a solution to an issue with Chrome 59.0.3071.86 (64bit) not starting in Fatdog64-710. I've had no problems with previous versions.

Code: Select all

# google-chrome 
/usr/bin/google-chrome: error while loading shared libraries: libgtk-3.so.0: wrong ELF class: ELFCLASS32

Chrome (64bit) thread: http://www.murga-linux.com/puppy/viewto ... &start=135

[SFR]

Chrome 59.0.3071.86 (64bit) not starting in Fatdog64-710

Oh crap, they moved to GTK+3...
You need to install gtk3 (+ its deps) via Gslapt and this should make it working.

Code: Select all

/usr/bin/google-chrome: error while loading shared libraries: libgtk-3.so.0: wrong ELF class: ELFCLASS32

This means Chrome is trying to use 32bit version of GTK+3, which is included in 32bit-fd64_710.sfs. You need 64bit version.

Greetings!

[jake29]

Chrome 59.0.3071.86 (64bit) not starting in Fatdog64-710

Oh crap, they moved to GTK+3...
You need to install gtk3 (+ its deps) via Gslapt and this should make it working.

Code: Select all

/usr/bin/google-chrome: error while loading shared libraries: libgtk-3.so.0: wrong ELF class: ELFCLASS32

This means Chrome is trying to use 32bit version of GTK+3, which is included in 32bit-fd64_710.sfs. You need 64bit version.

Thanks SFR, that resolved the issue.

[step]

Recent developer builds of Opera, which is based on Chrome, have the same issue but unfortunately it can't be fixed by adding the gtk3 package. Apparently opera refuses to start when it finds both gtk2 and gtk3 installed.

[step]

@FanDog,

well, the node binary is there, so you can start it simply with /aufs/pup_ro12/usr/bin/node and see what happens. But honestly, I ran out of ideas. I don't know what makes /usr/bin/node disappear when you load the SFS. At one point /usr/bin/node was a broken link in your savefile but then you removed the broken link. So the node binary in the SFS should be found. For reference, this is what I get when I load the SFS dowloaded from the link I posted above:

Code: Select all

# find /aufs/pup_ro* -name node

# OK, no nodejs around. Now download the SFS, then:

# md5sum /root/Downloads/node-7.3.0-x86_64-1.sfs
bf623dc2d6c7ec467a100a1b02a6121f  /root/Downloads/node-7.3.0-x86_64-1.sfs
# load_sfs.sh --load /root/Downloads/node-7.3.0-x86_64-1.sfs
# find /aufs/pup_ro* -name node
/aufs/pup_ro16/usr/bin/node
/aufs/pup_ro16/usr/include/node
/aufs/pup_ro16/usr/share/doc/node
# node
>
> .exit
#
# load_sfs.sh --unload /root/Downloads/node-7.3.0-x86_64-1.sfs
# 

[tigersong]

Could someone post an example GRUB configuration file, please? I have FatDog on a partition but can't boot into it because it's not recognized by GRUB.

[prehistoric]

Could someone post an example GRUB configuration file, please? I have FatDog on a partition but can't boot into it because it's not recognized by GRUB.

Because you didn't specify GRUB2 I'm guessing you mean original GRUB. If you are using GRUB2 there are significant differences. Here's a simple menu.lst entry for my Fatdog710 test installation on the second partition of the first hard disk. N.B. the way GRUB numbers partitions depends on the version you are using, check carefully.

Code: Select all

# Linux bootable partition config begins
  title Fatdog Linux 710+ (on /dev/sda2)
  root (hd0,1)
  kernel /FD710+/vmlinuz savefile=direct:device:sda2:/FD710+/fd64save
  initrd /FD710+/initrd
# Linux bootable partition config ends

[smokey01]

@tigersong, if your HDD is > 2TB then GRUB won't see it.

[s243a]

The update flash script isn't working for me in the beta. I'm not sure if it works in the latest version of fatdog64.

[prehistoric]

@tigersong, what smokey01 says is true in simple terms, but that entry came from a 3 TB disk used with a work-around when the motherboard BIOS doesn't want to boot a GPT disk. There are ways around the limitation, but we don't need to get into them unless you tell us you are running such a configuration. Windows users can buy programs called disk partition managers for going beyond BIOS limitations on old machines. This is a complication you should not see on recent machines. Puppy will fit nicely into many places you can reach in the first 2 TB, so this is not much of a limitation. Windows systems may have to do tricks to use new disks on old machines. A brutal simplification is to put a MSDOS-style layout on a large disk, and only use the first 2 TB. This may actually have some small speed advantage.

Unless you say you are running UEFI firmware and/or GPT disk, we will assume you are running an old-fashioned BIOS and a disk with a MBR and MSDOS-style partition table.

[FanDog]

@ step

> I ran out of ideas.

yea.. the only thing I can think of is that was some debris laying around that 'panicked' the loader, 'cause when I went just now to set the links manually there was still a "/usr/include/node", "/usr/lib/node_modules", "usr/bin/npm" and a file from "share/systemtap" I just copied over.. (didn't bother with the docs)

I did not test rebooting after deleting them, being satisfied with the thing finally working.. even the glibcxx problem I was having disappeared. \o/

Thanks step. Really appreciate it : -)