[CLOSED] Fatdog64-720 Beta [1 Dec 2017]

[proebler]

Libinput that's included with 720 seems to support the c720's clickpad very well. I've uploaded a new c720 package to the repo (c720_720-120417-x86_64-1.txz). You might want to give that one a go with a clean savefolder. I've also updated the touchpad app in the control panel to work with the c720, that will be in final. The current one in 720beta will work too, but you have to restart X.

Marvelous, with the new package (c720_720-120417-x86_64-1.txz) all my needs for the touch pad on the Acer C720 now seem to be met.
Thank you very much kirk !

[don570]

I tested fatdog64-720 beta with a frugal install to a hard drive partition.

I tested mtpaint and gimp with my wacom tablet --> worked well

pschedule allowed an alarm with 'aplay'

Samba was easy to setup. I used instructions I found in /etc/samba/smb.conf

Code: Select all

# A private directory example, usable only by kirk. Note that kirk must be a valid Linux user and a 
# valid Samba user. To make this work open the control panel and click on the System tab. Then
# click on Fatdog64 User Manager. Click on the Add button and add a new user named "kirk". This will 
# add kirk as a new user and create a home directory for kirk at /home/kirk. This directory will be
# owned by kirk. If you choose some other folder for kirk to share, make sure kirk owns that folder.
# Then open a terminal and type smbpasswd -a kirk. You'll be prompted for a new password. After that
# un-comment the section below and restart Samba.  

[kirkdir]
   comment = Kirk's Service
      path = /home/kirk
   valid users = kirk
   public = no
   writable = yes
   printable = no
   

After making a new user I restarted with following command

Code: Select all

/etc/init.d/60-samba restart

________________________________________________

[don570]

If it is possible, could someone check why mypaint icons disappear
in fatdog 64? This is a problem in all versions including 720.

I filed a bug issue with git site
https://github.com/mypaint/mypaint/issues/855
but they pinned the blame (probably correct) on GTK,
but note that mypaint uses python3 so it may have something to do with that.

You can do a check by comparing two versions of mypaint...
Here is the most recent....
https://drive.google.com/open?id=1Zxc_M ... gCu48lsWip

....and here is a version where I modified the icons availabe to force them to appear
in fatdog64 . Apparently smaller sizes of icons will fit in space allocated in window??? So that is what I did.
https://drive.google.com/open?id=0B7JZA ... 0xsNFpENGM
_____________________________________________

[Terry H]

Frugal install to HDD on Desktop with AMD FX6100 went smoothly, boot with no issues and runs great.

With my Dell Latitude 3350 with Core i3-5005U with 8GB RAM, I appear to be afflicted with Belham's Curse, it takes 5 minutes plus to boot. I have frugal install to USB Flash Drive formatted ext4, using legacy grub to boot.

I tried bigpup's menu.lst setup and include the uuid for the flash drive, but reboot after set up was stalled at loading initrd for 5 minutes 40 seconds. This is the boot stanza I am currently trying:

Code: Select all

title Fatdog64 (Fatdog64-720b)
uuid 1d94e7d8-ed44-4488-81a6-8a14d65539be
kernel (hd0,0)/Fatdog64-720b/vmlinuz waitdev=5
initrd (hd0,0)/Fatdog64-720b/initrd

Any assistance in what boot parameters may assist greatly appreciated.


Edit: All tested applications working well. I tested Bluetooth, file transfer to and from Samsung Galaxy S5 working well.

[chiron²]

That MyPaint (with the forced icons) works great. FD720 just got elected the new(and only) OS for my X61 tablet.

If someone is interested, I put together a claws-mail 3.10.1 package from debian binaries, including all dependencies and NLS. Does not appear like I can upload to the forum ATM. Even with fake .pet extension. So if someone wants to host it, I'll send it by Mail, less than 6mb.

Regarding Kodi, there are two broken symlinks to libsmbclient.so.0 and .so.2.3 in the FD64.SFS inside initrd. They probably prevent the symlink to libsmbclient.so.0 in the Kodi SFS from working correctly.

[LateAdopter]

With my Dell Latitude 3350 with Core i3-5005U with 8GB RAM, I appear to be afflicted with Belham's Curse, it takes 5 minutes plus to boot. I have frugal install to USB Flash Drive formatted ext4, using legacy grub to boot.

Since "Belham's Curse" follows him wherever he goes, I wonder if his USB adapter is nonstandard in some way.
I use a Transcend RDF5 USB3 adapter which works well on USB2 even with my Xoro satellite receiver which is known to have problems recognising some USB3 devices
My setups are like this:
16GB Transcend SDcard with Fatdog on the original FAT32 partition. Savefile is ext4-no-journal.
Grub4dos on a separate small partition, in the space at the start of the disk, but second in the partition table. Started from the PBS
Standard mbr.bin
USB3 on Intel Braswell N3150
USB2 on AMD Athlon II X2 240
Both motherboards are ASRock with AMI BIOS

I have moved the fd64.sfs and kernel-modules.sfs out of the initrd for the split tests using the method in the blog, not using the script, because that needs too much space in a unix filesystem to work.

Code: Select all

title Fatdog64 SPLIT (USB hd0)
  rootnoverify (hd0,0)
  kernel /fd72s/vmlinuz  waitdev=3 savefile=direct:label:XORO:/fd72s/fd64save.ext4 extrasfs=direct:label:XORO:/fd72s/kernel-modules.sfs basesfs=direct:label:XORO:/fd72s/fd64.sfs
  initrd /fd72s/initrd
  
title Fatdog64 SPLIT RAM (USB hd0)
  rootnoverify (hd0,0)
  kernel /fd72s/vmlinuz  waitdev=3 savefile=direct:label:XORO:/fd72s/fd64save.ext4 extrasfs=direct:label:XORO:/fd72s/kernel-modules.sfs basesfs=ram:label:XORO:/fd72s/fd64.sfs
  initrd /fd72s/initrd
  
title Fatdog64 720 (USB hd0)
  rootnoverify (hd0,0)
  kernel /fd720/vmlinuz  waitdev=3 savefile=direct:label:XORO:/fd720/fd64save.ext4
  initrd /fd720/initrd

My boot times:
USB3 basic: 36sec, split direct: 20sec, split RAM, 23 sec
USB2 basic: 57sec, split direct: 28sec, split RAM, 31sec.

It seems that the fd64.sfs is completely read into RAM initially, even if direct is specified, since to extra time to load into RAM is only 3 seconds (from the cache?). I suppose this must be a requirement of the squashfs compression.

The main factor is that linux (and Windows) can read from USB about 2 1/2 times as fast as the BIOS can. But the BIOS only has a generic USB driver whereas linux may have a device specific one.

[kirk]

I have frugal install to USB Flash Drive formatted ext4, using legacy grub to boot.

That's not good. Grub legacy and grub4dos-0.4.4 are very slow loading from ext4. Use ext3. Ext4 is fine for your savefile/savefolder, but if you want to use grub Legacy or grub4dos-0.4.4 do not put the kernel and initrd on ext4. Splitting the base.sfs out of the initrd lets you work around this problem by giving grub_legacy/grub4dos less to load, but avoiding the problem is better. I've used grub legacy and grub4dos. When I do I usually make a small ext3 partition (~2Gb) to install grub and my kernel/initrd. Then boots are very fast. I have a Acer c720 setup this way and it boots in about 15 seconds.

The recommend ways of making a bootable flash drive are:

1)Use the Fatdog64 installer
2)dd the iso to the flash drive http://distro.ibiblio.org/fatdog/web/fa ... drive.html

[Terry H]

Thanks lateadopter and kirk for your replies. The USB Drive is an 8GB Kingston USB3 Data Traveller I have used for quite a while to do frugal installs to try on my Laptop or other PC's. I have on my desktop a manual frugal install which is fine.

As I have several frugal installs on the drive I won't be changing the formatting. I'll remove the fatdog sfs and zdrive from the initrd to try it that way. When the new release is final I'll look at different options for installation.

[belham2]

Thanks lateadopter and kirk for your replies. The USB Drive is an 8GB Kingston USB3 Data Traveller I have used for quite a while to do frugal installs to try on my Laptop or other PC's. I have on my desktop a manual frugal install which is fine.

As I have several frugal installs on the drive I won't be changing the formatting. I'll remove the fatdog sfs and zdrive from the initrd to try it that way. When the new release is final I'll look at different options for installation.

Hi Terry,

I'm like you.....have multiple frugal installs on many devices (USB-IDE External Drive, internal SSD, USB-SDCard and regular ole' USB). I've tried to point out to the Fatdog team about possibly having a small initrd version also released (in essence the .sfs stripped out), but it seems this request always falls on deaf ears and it is left up to the user to the initrd stripping.

I don't mind it, lol, that is once I remember to do it. And you'll get the boots down to 30-45 secs, and you can stick with Ext4 no problems, so FD is available with all other pups and DDogs on our frugal-installed devices.

I just cannot imagine, what a normal, unaware user (i.e. one, who say, saw the release the other day on Distrowatch), excitedly downloaded FD64-720, only to watch a horrific boot time occur (you were lucky with 5min, on one machine Fd64-720 took 17 flippin' minutes---it was an 8GB i3 Core Duo SSD laptop, if you can believe it, less than 5 yrs old-----anyway, this neophyte user trying FD64 for the first time is not going to accept boot wait silliness and will quickly move on.

I guess I'll keep repeating this 'small-initrd' idea in hopes James, Kirk and crew some day heed it: start making and releasing small initrd FD64-versions at the same time you release the same initrd monsters. That way there is choice. Simple idea, simple concept, proven to work time and time again . I am fearful they (FD team) don't realize how many people they could/might be turning off by not considering a small initrd release too.

You know, most people who post and frequent here (Murga) are NOT normal computer users; hell, we are not even normal Linux users. We expect & somewhat crave to have to keep tinkering with an OS to get it working. But, others, say people from the LinuxMint, Ubuntu, Debian, etc worlds? To broaden FD64's appeal, something imho should be done about this Fatdog megoliath-T-Rex-initrd that will cause an user to impale themselves from belly button to chin waiting for the darn thing to boot

[artsown]

@belham2

I agree that a small initrd default option should increase the popularity
of fd considerably ... not just among the ubuntu mind-set folks but among
some puppy lovers (like me) as well.

Art

[bigpup]

Frugal install on a USB3 external hard drive.
Grub4dos boot loader.

I put Fatdog64-720 on a ext 3 formatted partition.

Well, I would not think the format would have an affect on boot time, but it did, very much

It booted in around 20 seconds to desktop.
Only hung at the initrd load for around 4 seconds.


With Fatdog on a ext 4 formatted partition.
Boot time is around 3 to 4 minutes.
Hangs at the initrd load for most of that time.

Maybe this needs to be a warning or note in the Fatdog install info

[kirk]

Maybe this needs to be a warning or note in the Fatdog install info

Yes, thanks bigpup.

[don570]

I made an add-on to show 'Search inside'
with right click of folders.

pfindplus

https://drive.google.com/open?id=1HxTXv ... Q5ptxJkdtz
___________________________________________________

I noticed strange thing

I couldn't use pfind search twice. I had to relaunch it again.
Never saw this before.

_____________________________________________

[don570]

glxgears worked fine but OpenGl 2.1 is apparently not available.

When I tried to launch newest blender app I got in terminal

Code: Select all

# ./blender
AL lib: (EE) UpdateDeviceParams: Failed to set 44100hz, got 48000hz instead
Error! Blender requires OpenGL 2.1 to run. Try updating your drivers.
# 

Fatdog 710 will run newest blender without complaint.

I am using intel graphics chip in my IBM thinkcentre

______________________________________

[Wognath]

Since suspend now works perfectly on my computer, I usually boot once a day, so a longish bootup time is not an issue. Nevertheless, for old times' sake (my now-defunct netbook would not wake from suspend), I have been following the discussion of boot times. On that netbook, large/small initrd made very little difference. In case it is useful, here are some results from an HP laptop. The boot times are from grub menu to desktop complete with drive icons, booting from a SSD with ext4 format. Bootloader is lickgrub.
Large initrd: 45 seconds
Initrd with fd64.sfs pulled out: 34 s
Initrd from fatdog-split-initrd.sh 32 s
(during split process, depmod warns it could not open modules.order and modules.builtin--finished anyway)

I'm also interested in the speedup by using ext3, but I need to read more about whether ext3 is ok for SSD and whether I could add a partition to the SSD without losing data.

Little by little discovering the improvements in 720. Thanks, FD team!

We expect & somewhat crave to have to keep tinkering with an OS to get it working.

Ha ha, love it!!!

[jake29]

@Wognath - An alternative via terminal 'suspend method' that I personally use:

Code: Select all

echo mem > /sys/power/state

[jamesbond]

glxgears worked fine but OpenGl 2.1 is apparently not available.

When I tried to launch newest blender app I got in terminal

Code: Select all

# ./blender
AL lib: (EE) UpdateDeviceParams: Failed to set 44100hz, got 48000hz instead
Error! Blender requires OpenGL 2.1 to run. Try updating your drivers.
# 

Fatdog 710 will run newest blender without complaint.

I am using intel graphics chip in my IBM thinkcentre

______________________________________

That is due to Mesa update.

In their great wisdom and because you're not Chrome, Intel guys decided to drop OpenGL 2.1 from their "lesser" graphics card.

https://www.phoronix.com/scan.php?page= ... nGL-2-Drop
And
https://www.phoronix.com/scan.php?page= ... ow-Default

But all is not lost, at least for now. You can still force it to emulate OpenGL 2.1 with the following tricks:

OpenGL 2.1 with i915 driver

The update of mesa from version 13.x to 17 may break support for OpenGL 2.1 on third gen Intel GPUs (GMA3100, see here), as described in this article, reverting it back to OpenGL 1.4. However this could be restored manually by setting /etc/drirc or ~/.drirc options like :

/etc/drirc

<driconf>
...
<device driver="i915">
<application name="Default">
<option name="stub_occlusion_query" value="true" />
<option name="fragment_shader" value="true" />
</application>
</device>
...
</driconf>

https://wiki.archlinux.org/index.php/In ... 915_driver

[jamesbond]

As an aside, we did have a discussion about small vs huge initrd a couple of months back (pros/cons/trade-off/etc) and decided that for the time being, the huge initrd is still the best.

As an academic question!... Is it possible to make a small initrd that can load the fd64.sfs and the kernel-modules.sfs directly from the CPIO homogeneous initrd file?

Yes, of course. There are two ways of doing it:
1. Certain bootloaders (syslinux) are capable of loading multiple initrd and appending them together, before starting the system.
2. Have the small initrd find the huge initrd, and extract the *.sfs in it and then start Fatdog.

The downsides:
For (1), it doesn't really help. Firstly, only certain bootloaders support this. Secondly, the huge-initrd is still read by the bootloader using BIOS calls, so if BIOS or bootloader is slow, then it is still slow.

For (2), the problem isn't about loading that additional huge initrd; it's about FINDING it. Every now and them we see posts in this forum asking for help: "help! I've got a kernel panic!". In 9 of 10 cases of these, the problem is because Puppy's (small) initrd cannot find the base.sfs.
Putting the base.sfs in initrd:
a) removes the need to search for it (=makes it faster), and
b) making sure it is always available.

[LateAdopter]

hello jamesbond

Thanks for the reply. I was thinking that method 2 would allow one ISO to offer both large and small initrd boot methods, since only the small initrd part needs to be duplicated.

[don570]

That is due to Mesa update.

I can run Blender 2.79 in fatdog710 and newest pyro64 by barryK.
They must use an older mesa package???

I use the 'intel' driver. I will see if I can use 'i915' driver.

___________________________________________________

Another bug in both 720 and earlier versions --->
mhwaveedit can't show the font characters in a marker label. (see image)