Fatdog64-710 Final [4 Dec 2016]

[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 : -)

[quirkian2new]

First of all, thanks to the dev team for this great distro. I've been using Fatdog since version 630.

I have one second hand cheap PC with 4GB RAM. It used to dual boot win7 and Fatdog happily. Recently I boot into Fatdog and edited a sfs file with editsfs utility. At first it is successful, but when the size of sfs file grow to about 350 MB, editsfs failed without any error message.

After comparing the same operation in BarryK's SLAQ64, I suspect the failed editsfs(with 350MB file ) in Fatdog may be caused by insufficient memory. On observation, with physical RAM of 4GB, only 2GB seem to be available for editsfs in Fatdog. Running editsfs in Slaq64, it seem that about 4.2 GB can be used by editsfs.

Is this a limitation of Fatdog ? But Barryk seems to be too busy to maintain older version of Quirky/Slaq. Will future release of Fatdog taking this into consideration ?

Thanks again

[eowens2]

I seem to have to lost the 'bullseye' widget in the tray beneath the screen, clicking on which leads one thru the wi-fi setup (fortunately my wi-fi is still connected).

I can't find it! How can I get it back?

[smokey01]

I seem to have to lost the 'bullseye' widget in the tray beneath the screen, clicking on which leads one thru the wi-fi setup (fortunately my wi-fi is still connected).

I can't find it! How can I get it back?

click on wpa_gui or type it in a terminal should put it back in the tray.

[step]

@quirkian2new,
With what version of Fatdog64 did you run editsfs?
I'm not familiar with editsfs and I can't find it in the Fatfog64-710 base SFS. Is it an extra package or pet that I can install or download? Can you please provide links? Thank you.

[evereman]

Hi, all.
I can't praise version 710 enough, really. You guys are geniuses.

It must load at least twice as fast as 702. Lots of little bugs no longer occur.

Great jobs, guys!

The only bug I've found occurs after updating with Gslapt. Afterwards it is hard to get the Pmount/Unmount Drives program on the start menu to bring up the drive panel that shows the drives.

The notice that says it's reading the drives briefly pops up, then disappears. No panel showing the drives appears. This does not happen unless I update everything with Gslapt.

If I right click on the drive icon on the desktop, it will work sometimes and sometimes not. After perhaps three tries, it will usually work.

I haven't ever had it not work at all, just takes effort and patience, so not a critical concern.

Gslapt updates should be the same as everyone else's, since I boot from the original ISO on a DVD.

I then go to Gslapt, update everything, set up the sound, reinstall Chrome, and add my Bookmarks from a USB drive, basically a clean install every time. (I'm very fond of security and love the fact that Fatdog64 run only in memory. There is nothing else like it.)

[evereman]

I forgot to mention that this did not occur when I first used 710.

It has begun to happen over about the last couple of months only. Before that everything seemed to work perfectly.

Was the system changed so that updating it could cause this bug?

I would like to be able to update every time, as I used to, and start with all up to date programs.

[quirkian2new]

@step

I am running edit_sfs-2.16 on FD701 and FD702. But I "think" FD710 may also give the same result. With physical ram 4 GB, seems only 1.8gb or so can be used by edit_sfs. When the sfs file size is under 280MB, the operation is successful. While file of sfs file is approaching 350 MB, it failed without any error message.

I cant remember the actual download link. Attached is a copy (to remove the .gz at the end)

[eowens2]

Smoky01 says

eowens2 wrote:
I seem to have to lost the 'bullseye' widget in the tray beneath the screen, clicking on which leads one thru the wi-fi setup (fortunately my wi-fi is still connected).

I can't find it! How can I get it back?


click on wpa_gui or type it in a terminal should put it back in the tray.

That worked fine, but it does not survive terminal closure or a reboot.

Is there a 'startup file' somewhere that including 'wpa_gui' will initiate the widget with each bootup?

[smokey01]

@eowens2, Look in /etc/xdg/Startup

It will work in /root/Startup as well.

[step]

@quickian2new

I read in the edit-sfs OP here that the first time you run it you need to give it the path of a working dir, in a Linux volume, and optionally you can set a RAM disk. I take it to mean that you can also not run with a RAM disk at all. That makes sense, so edit-sfs should be able to handle very large SFS files entirely in the working dir, if there's enough free space.
As for only 1.8 GB RAM available out of 4 GB total, that seems about right. By default Fatdog64 sets /tmp as a RAM file system, which takes about 50% of available RAM. That leaves no more than 2 GB free for applications, including for when edit-sfs wants to create its RAM disk.