Fatdog64-630 & 631 Final (May 12 2014)

[Bindee]

Kirk , James

Have you modified or customised VLC and Firefox in any way that users should avoid updating them to the latest version ?

I vaguely seem to remember James saying Firefox has been modified and thats why it says nightly build.

Just wanted to check if it will break anything.

Thanks

[Pavan]

Anyone used or using a steelseries kana v2 mouse with fatdog ?

I wondered if all the buttons and wheel work ok.

[jamesbond]

@LateAdopter - that's an interesting experiments, yes. Never cross my mind to use kexec on x86_64 because the bootloaders are capable ones. But yes, I'm glad that it works; I assume you compile your own minimal kernel since Fatdog's one isn't compiled with kexec.

@Bindee, both VLC and Firefox are self-compiled and not the official binaries from the website. For example firefox is "nightly" (because we aren't allowed to use firefox brand). Thus both will not auto-update.

If you need an updated firefox, you can always delete the built-in one and download and install firefox from official binaries, it should work. VLC - I haven't tested, as VLC has a lot more dependencies.

@Pavan - not me. I use Logitech standard wheel mouse.

[LateAdopter]

Hello jamesbond

@LateAdopter - I assume you compile your own minimal kernel since Fatdog's one isn't compiled with kexec.

That's what Kexec-Loader provides. It's a kernel: 740kB and an initrd: 128kB, plus a collection of optional filesystem drivers and device drivers.

It only has FAT and Joliet filesystems built-in but you can add any of the others needed.

It means that you can boot from any device and filesystem supported by linux. You are not limited to what the BIOS and bootloader support.

[gcmartin]

Hello @LateAdopter. What you share is of great interest. And Thanks to both you and @JamesBond.

You share a bootloader approach which has cross-platform ability and cross-peripherals for boot identification and selection. This brings Linux universality to the bootmanager/bootloader arena.

[Bindee]

@Bindee, both VLC and Firefox are self-compiled and not the official binaries from the website. For example firefox is "nightly" (because we aren't allowed to use firefox brand). Thus both will not auto-update.

If you need an updated firefox, you can always delete the built-in one and download and install firefox from official binaries, it should work. VLC - I haven't tested, as VLC has a lot more dependencies.

I think it might be best if i just left them alone then.

Seeing as FireFox has regular security fixes and VLC has codec bug fixes couldn't you assign someone with good Linux knowledge to the fatdog team to keep these packages updated while still keeping it self-compiled how you want them?

[jamesbond]

I think it might be best if i just left them alone then.

Firefox isn't too difficult to update. Just delete /usr/lib64/firefox and /usr/lib64/firefox-27, get the tarball for 64-bit Linux from firefox website, expand it, and copy the resulting "firefox" directory to /usr/lib64.

Seeing as FireFox has regular security fixes and VLC has codec bug fixes couldn't you assign someone with good Linux knowledge to the fatdog team to keep these packages updated while still keeping it self-compiled how you want them?

I wish I could *assign* someone

But you do have a point. I'm sure some of Fatdog users will continue to stay with the 600 series (I've seen some sticking to 500 series) so it would be good if the community can form a support group around these older series, and I would encourage anyone with interest to do so.

In addition, Fatdog64 600 series has a public repository, accessible using Fossil SCM, here: http://www.ibiblio.org/fatdogscm/cgi-bi ... .cgi/index With this, you can rebuild Fatdog64, identical with the released versions. Anybody who is interested to maintain the 600 series can use that as the base and continue to release "unofficial" updates to Fatdog64 631 (it's "unofficial" because as far as the officer is concerned, the 600 series ends with 631).

Fatdog users tend to be the quiet types, though, so I don't really know how many of you are out there.

Now the most exciting news of all: Fatdog64 700 alpha1 is released today. Announcement here.

[Ted Dog]

I wouldn't mind helping keep 600 series alive. But I will see what happens with the new direction taken by 700. COMING SOON...

[Bindee]

Thanks James , I'll checkout 700

[JustGreg]

First, this not a bug. I need some help creating a pet for Fatdog 64

My employer has started using a new web page/java script for time keeping. I noticed that the page was not rendering correctly with Firefox Nightly 29.0 version of Fatdog64. However, on my work Computer with Firefox 31.0, the page renders correctly. I decide to try to make a pet of the official Mozilla Firefox 31.0 package.

I downloaded the 64 bit package for other Linux, Firefox-31.0.tar.bz2 file. The bz2 fiel was copied to a working test diectory. I used pupzip to expand the archive to the directory Firefox-31.0 under the test directory. Using the dir2tgz command, Firefox-31.0.tgz archive was created. I created a pet file using tgz2pet command.

Using the pet installer, the pet was installed. Here is where I found I missed a step or two. After the pet installer successfully finished, first I noticed it reported no menu entry for applications menu. What do I need to add to create a menu entry? Secondly, the installer placed the needed files back in the original test directory and not in the system files. How do I correct this?

The good news is the official Mozzila package worked correctly when I started it. However, the time sheet web page still did not render correctly. I do want to use the official released version and create a proper pet. Thank you in advance for any help.

[jamesbond]

JustGreg, download the official binaries and then do this work in terminal (assuming your /tmp is plenty of space, if not, do it elsewhere):

Code: Select all

cd /tmp
mkdir -p firefox-31-631/usr/lib64 # for example (change whatever name you'd like.
tar -xf /path/to/downloaded/firefox-tarball.tar.gz -C /tmp/firefox-31-631/usr/lib64
pushd /tmp/firefox-31-631/usr/lib64
mv firefox firefox-31
ln -sf firefox-31 firefox
popd
dir2pet firefox-31-631

I haven't tested this step by step but I remember this is how we actually package the firefox that goes into the basesfs. The point is that the pet must have firefox in /usr/lib64 and the original /usr/lib64/firefox symlink must be changed to point to the new one. All existing menu items etc will automatically point to the new one.

[JustGreg]

Thanks for the code. It does seem to work. I have run into a problem. When I tried to use the menu entry the older Nightly version 29 came up. I looked the defaultbrowser code and saw it ran firefox under run-as-spot. I tried to run the new version with the following code in urxvt:

Code: Select all

exec /usr/bin/run-as-spot /usr/lib64/firefox-31.0/firefox "$@"

, the older Nightly version 29 of firefox is executed. But, if I use

Code: Select all

exec  /usr/lib64/firefox-31.0/firefox 

or the symlink to the 31 version then the newer 31 version is started. I must be doing something wrong.

Thanks for showing me the popd and pushd commands. Nice to learn something new.

Disregard the above. I found the problem. I had to edit the file
/spot/.local/share/applications/usr-app-Nightly-1MCEAX.desktop to the following:

Code: Select all

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
#Exec=/usr/lib64/firefox-29.0/firefox %u
Exec=/usr/lib64/firefox-31.0/firefox %u
Name=Nightly
Comment=Custom definition for Nightly

I have read Fatdog-64 Alpha post and the future change ending the use of the Pets for the more common Slackware package management. So, I think this problem is ended. I will be waiting for the beta 700 version to try it out. Thanks again for the help.

[eowens2]

I would like to report that I have openvpn up and running on Fatdog64_630, and have uploaded the necessary files.

Smokey01 is kindly hosting openvpn-2.3.4-x86_64.pet and gadmin-openvpn-client-0.1.9-x86_64.pet, both with a date stamp of 4-Aug-2014.

Gadmin-openvpn-client is a GUI-facilitator for openvpn; while it works hand-in-glove with gadmin-openvpn-server, it also allows import of configuration files from commercial openvpn service providers and to connect to them (which is how I use it). The GUI has a handy switch, “Start at Boot

[eowens2]

Dumb question. How do I find the kernel header files for kernel 3.12.18? Are they part of the source?

[jamesbond]

Dumb question. How do I find the kernel header files for kernel 3.12.18? Are they part of the source?

Part of the kernel source, yes.

[eowens2]

jamesbond,

with the version of Fatdog64 that I downloaded, "uname -r" gives 3.12.18. But the SFS Manager lists only kernel-source-3.11.4 and kernel-source-3.8.7. The Package Manager lists only kernel-source 3.4.5.

On distro.ibiblio.org/fatdog/xxx I could find nothing about kernel 3.12.18.

I should mention that my running copy of Fatdog64-630/1 is the Fatdog64-631 for the Acer c720 Chromebook, so maybe it is in a mold a little different from other versions, and perhaps the source is not readily available.

Totally changing the subject: Does your Fatdog/ARM boot on Google's Nexus 7? There is apparently considerable support for devs out there, and there is already one flavor of Linux booting on it (Bodhi Linux).

I am not sure whether the Nexus 7 is 32- or 64-bit. I'll bet a puppy-like distro would really fly on that device.

Thank you for your support.

[jamesbond]

with the version of Fatdog64 that I downloaded, "uname -r" gives 3.12.18. But the SFS Manager lists only kernel-source-3.11.4 and kernel-source-3.8.7. The Package Manager lists only kernel-source 3.4.5

630 and 631 uses 3.12.9 - and the kernel source is on http://distro.ibiblio.org/fatdog/sfs/600 (I need to check why sfsmanager isn't showing that).

I should mention that my running copy of Fatdog64-630/1 is the Fatdog64-631 for the Acer c720 Chromebook, so maybe it is in a mold a little different from other versions, and perhaps the source is not readily available.

Indeed, 631-for-c720 uses a different kernel. It must have been an oversight on our part not to make this available. I'll check with kirk when he's back.

Totally changing the subject: Does your Fatdog/ARM boot on Google's Nexus 7? There is apparently considerable support for devs out there, and there is already one flavor of Linux booting on it (Bodhi Linux).

No, because I don't have Nexus 7. If I do - and as you said, there is considerable community around it with Bodhi Linux booting already - it should be straightforward (relatively speaking) to get it up and running there too. See: http://jamesbond3142.no-ip.org/wiki/wik ... gFatdogArm (that information is abit outdated - the recent version of FatdogArm is built on Odroid, no longer on Mele, but the idea remains the same).

I am not sure whether the Nexus 7 is 32- or 64-bit. I'll bet a puppy-like distro would really fly on that device.

All ARM CPUs except the very latest one (iPhone 5) are 32-bit. I haven't checked what's the SoC, but generally speaking you're right Puppy-like system will work nicely. I have an A13 tablet with 512MB RAM and FatdogArm works nicely on it - except that the touchscreen doesn't work (no open-source driver).

cheers!

[fixer1234]

I installed Fatdog64-631 on a thumb drive. Very nice package, by the way.

The problem is this: each time I go to shut down, I get the message that everything is in RAM, create a savefile. I create the file. The next time I boot up, it doesn't recognize that the file is there and I'm back to using a virgin install. It does actually create the file and I can see it if I re-mount the thumb drive after booting. However, I can't even get the savefile utilities to recognize it. I've tried both a regular save file and a multi-session with the same results (the regular was the first).

Can somebody point me to some detailed instructions or is there something obvious I can check?
Thanks.

[neerajkolte]

Hi @fixer1234,

Usb drives take some time to get ready.
Assuming you put your savefile at the root of your usbdrive and didn't rename it, then you probably need the waitdev Boot Option

Try adding waitdev=5 to your kernel line.

[fixer1234]

Hi @fixer1234,

Usb drives take some time to get ready.
Assuming you put your savefile at the root of your usbdrive and didn't rename it, then you probably need the waitdev Boot Option

Try adding waitdev=5 to your kernel line.

That was it. Now it works.

I had tried doing a search but it looks like the search feature only looks in posts and I never would have guessed to look in a faq on boot options (or known what I was looking at if I found it). Thanks.