Fatdog64 710 Beta2 [CLOSED]

A home for all kinds of Puppy related projects
Message
Author
User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

#21 Post by Billtoo »

kirk wrote:
The computer shares the same 32" TV as the hp desktop but it has a
standard HDMI cable connected to a different HDMI port, still no sound
through the TV speakers so using external speakers.
Probably need to open the Control panel, click on the Sound tab and then click on Fatdog64 Set Default Sound Card. Then select your hdmi output. After that click on Alsa Mixer and make sure the output is not muted. It will show "mm" if it muted. Press the "m" key to toggle mute.

Also, If you just want VLC to send audio to hdmi, you can ignore all that typed above. Open VLC and click on the Audio Menu and the select Audio Device and select your hdmi output.
TV speakers are working now, thanks.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#22 Post by prehistoric »

Still have not been able to reproduce that strange aufs error on other machines. This got me thinking about what was different about that motherboard from day one. It is an ASUS M2NPV-VM, which has nVidia components doing all kinds of stuff. In particular I long ago went through problems with the nForce2 chips and the Forcedeth kernel module, which is usually thought of as strictly a high-speed ethernet interface. This greatly underrates what it does. It also handles audio, and there is embedded nVidia graphics.

What could be going on is a problem with DMA, which the gigabit ethernet requires. DMA is also in heavy use by the disk controller. It is possible this old system has never driven those interfaces at these speeds. I believe there have been reports of DMA memory mapping errors with Forcedeth.

Quite how this causes aufs to resurrect forgotten files I don't know, and will leave to the experts. If the problem is just one ancient buggy design, it isn't too bad. Other people need to see what happens when they do massive transfers on their machines.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#23 Post by prehistoric »

I have now completed the same massive transfer on the buggy machine using Fatdog 710b2. To do so I resurrected a standard practice of crufty old Unix people. You can find this described many places, here's the O'Reily version.

This forms a virtual tarball from the directory tree in the source directory, and sends it to a pipeline, the other end of the pipeline should be on the target disk. The reason for && is to make sure you don't clobber the source directory if the cd fails. I'll let someone else explain reblocking.

Code: Select all

# cd /mnt/sda6
# mkdir bckup
# cd /mnt/sda5/old
# tar cf - . | (cd /mnt/sda6/bckup && tar xBF -)
tar: ./Mail.old/Computers/625: time stamp 2028-02-27 02:26:41 is 357935476.331066128 s in the future
# 
Now my first observation is that this moved exactly the same directory tree as before, but without any I/O errors. Ideally it should be possible to issue a blizzard of cp operations without problems. This creates and destroys many processes, and doesn't always work, but Ken Thomson and Dennis Ritchie were well aware of possible hardware glitches when they were working on a PDP-7.

(If the machine you are working on can't run tar correctly, it has already crashed and you are in the middle of an unplanned recovery operation.)

Besides the absence of reported I/O errors, this method taught me that the timestamp on an old piece of email about computers came from way in the future. I was disappointed to find the message was spam describing old technology instead of a peek at the wonders of 2028. At some time in the past the system clock was way off, and I had never noticed this affected that file.

This method of copying/moving directory trees is so much more reliable that it might be made part of the standard GUI copy operation when there is a massive pile of files affected.

Sage
Posts: 5536
Joined: Tue 04 Oct 2005, 08:34
Location: GB

#24 Post by Sage »

As before - can't fault it!
Except, maybe we could have a 32bit version, half-the size. (For those not versed in perverse UK humour, that was a joke)

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

Fatdog64 710 Beta2

#25 Post by Billtoo »

One more:

I used the fatdog installer to a 32gb flash drive, computer is a
Gateway desktop:

Summary
Computer
Processor 8x Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Memory 16416MB (452MB used)
Machine Type Physical machine
Operating System Fatdog64 [710]
User Name root (root)
Date/Time Mon Oct 24 10:36:57 2016
Display
Resolution 3840x1080 pixels
OpenGL Renderer Gallium 0.4 on NVC8
X11 Vendor The X.Org Foundation
Audio Devices
Audio Adapter HDA-Intel - HDA Intel PCH
Audio Adapter HDA-Intel - HDA NVidia

SCSI Disks
ATA Hitachi HDS72302
ATAPI BD E DH12E3SH
Kingston DataTraveler 3.0

Display
Resolution 3840x1080 pixels
Vendor The X.Org Foundation
Version 1.18.3
Monitors
Monitor 0 1920x1080 pixels
Monitor 1 1920x1080 pixels

OpenGL
Vendor nouveau
Renderer Gallium 0.4 on NVC8
Version 3.0 Mesa 12.0.3
Direct Rendering Y_es

PCI Devices
Network controller Ralink corp. RT3090 Wireless 802.11n 1T/1R PCIe

BIOS
Date 04/19/2011
Vendor American Megatrends Inc. (www.ami.com)
Version P01-A3

It's working well so far,
Thanks

EDIT: I installed the proprietary Nvidia driver:
video-info-glx 1.5.3 Mon 24 Oct 2016 on Fatdog64 710 Linux 4.4.21 x86_64
0.0 VGA compatible controller: NVIDIA Corporation GF110 [GeForce GTX 560 Ti OEM] (rev a1)
oem: NVIDIA
product: GF110 Board - 12630002 Chip Rev

X Server: Xorg Driver: nvidia
X.Org version: 1.18.3
dimensions: 3840x1080 pixels (1204x343 millimeters)
depth of root window: 24 planes

direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 560 Ti/PCIe/SSE2
OpenGL core profile version string: 4.3.0 NVIDIA 375.10

One effect is that TAS (or any other app) can't get a proper screenshot
of a video playing with VLC, it just shows up as a green rectangle.
Attachments
Screenshot2.jpg
(36.03 KiB) Downloaded 633 times
Screenshot.jpg
(50.9 KiB) Downloaded 654 times

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

Fatdog64 710 Beta2

#26 Post by Billtoo »

New install to a macmini which is connected to my 32" TV.

Computer
Processor 4x Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
Memory 16338MB (398MB used)
Machine Type Physical machine
Operating System Fatdog64 [710]
User Name root (root)
Date/Time Tue Oct 25 13:00:50 2016

SCSI Disks
ATA APPLE HDD HTS545
HL-DT-ST DVDRW GX40N
Verbatim STORE N GO

OpenGL
Vendor Intel Open Source Technology Center
Renderer Mesa DRI Intel(R) Ivybridge Mobile
Version 3.0 Mesa 12.0.3
Direct Rendering Y_es

Sound is working through the TV speakers.

The macmini won't boot from a flash drive so I'm booting with the dvd and the savefile is a 64gb flash drive.

The intel graphics driver is working great on this pc and others that
I've tested it on.

Thanks.
Attachments
Screenshot.jpg
(101.33 KiB) Downloaded 544 times

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

Fatdog64 710 Beta2

#27 Post by Billtoo »

I couldn't get zarfy to work for an install that uses 2 monitors so I
googled for xrandr examples.
I found that "xrandr --output HDMI1 --auto --output VGA1 --auto
--right-of HDMI1" no quotes works for my setup so I saved it from geany as
2monitors.sh and put the file in /root/startup, then changed the
permissions to make it executable.
Attachments
Screenshot.jpg
(31.55 KiB) Downloaded 471 times

User avatar
ally
Posts: 1957
Joined: Sat 19 May 2012, 19:29
Location: lincoln, uk
Contact:

#28 Post by ally »

for info: booted beta 2 on a lenovo x201 with intel guts and an ssd drive

took a couple of minutes to boot, hard drive light thrashing continuously

when it actually starts to boot this happens briskly, unsure how to get you useful diagnostic info

:)

edit: non uefi

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#29 Post by jamesbond »

@ally - how did you boot it, did you use grub4dos, or boot from usb flash drive, or from DVD?

@All: For those who are concerned about Dirty COW bug, kernel 4.4.26 is available. You can update your Fatdog using fatdog updater (from Control Panel). Note: this can only be used for installed Fatdog.

@mavrothal: the loading of kernel and initrd is done by the bootloader (since you use Mac, that would be either rFINd or grub2.efi). As much as I'd like to show feedback, it is not under our control.

@billtoo: We'll try lxrandr. Also, screen capture showing green box means that the nvidia driver uses an ancient method to play video on your desktop ("overlay"). There is nothing much we can do in this case.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
ally
Posts: 1957
Joined: Sat 19 May 2012, 19:29
Location: lincoln, uk
Contact:

#30 Post by ally »

sorry, JB - booted grub4dos

Code: Select all

# menu.lst produced by grub4dosconfig-v1.9.2
color white/blue black/cyan white/black cyan/black
#splashimage=/splash.xpm
timeout 10
default 0

# Frugal installed Puppy

title Puppy tahr 6.0.5 (sda1/tahrpup6.0.4)
  uuid 88e38b9d-29b2-42bd-9e70-9ab62177d71d
  kernel /tahrpup6.0.4/vmlinuz   psubdir=tahrpup6.0.4 pmedia=atahd pfix=fsck
  initrd /tahrpup6.0.4/initrd.gz

title Puppy precise 5.7.1 (sda1/chloe)
  uuid 88e38b9d-29b2-42bd-9e70-9ab62177d71d
  kernel /chloe/vmlinuz   psubdir=chloe pmedia=atahd pfix=fsck
  initrd /chloe/initrd.gz

title Puppy slacko 5.7.0 (sda1/slacko5.7.pae)
  uuid 88e38b9d-29b2-42bd-9e70-9ab62177d71d
  kernel /slacko5.7.pae/vmlinuz   psubdir=slacko5.7.pae pmedia=atahd pfix=fsck
  initrd /slacko5.7.pae/initrd.gz

title Puppy slacko 6.9.6.3 (sda1/slacko)
  uuid 88e38b9d-29b2-42bd-9e70-9ab62177d71d
  kernel /slacko/vmlinuz   psubdir=slacko pmedia=atahd pfix=fsck
  initrd /slacko/initrd.gz

title Puppy tahr64 6.0.5 (sda1/tahr64)
  uuid 88e38b9d-29b2-42bd-9e70-9ab62177d71d
  kernel /tahr64/vmlinuz   psubdir=tahr64 pmedia=atahd pfix=fsck
  initrd /tahr64/initrd.gz

title Fatdog64 (sda1/fatdog64_710)
  uuid 88e38b9d-29b2-42bd-9e70-9ab62177d71d
  kernel /fatdog64_710/vmlinuz   psubdir=fatdog64_710 pmedia=atahd pfix=fsck
  initrd /fatdog64_710/initrd

# Windows
# this entry searches Windows on the HDD and boot it up
title Windows\nBoot up Windows if installed
  errorcheck off
  find --set-root --ignore-floppies --ignore-cd  /bootmgr
  chainloader /bootmgr
  find --set-root --ignore-floppies --ignore-cd  /ntldr
  chainloader /ntldr
  find --set-root --ignore-floppies --ignore-cd   /io.sys
  chainloader /io.sys
  errorcheck on

# Advanced Menu
title Advanced menu
  configfile /menu-advanced.lst
  commandline

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#31 Post by jamesbond »

@ally - okay, so that's grub4dos. How big is the partition that holds fatdog? What is the partition type (is it ext3 or ext4)? Also, I remember grub4dos shows the progress of the file being loaded; when you said that the disk was trashed, did the progress continue to count upwards?

Here is my guess: grub4dos, while it can load ext4 partition, it is not very efficient in doing so, especially if the partition is large. Things are fine the ext4 partition is not fragmented (ie loading the first few files you added to the partition), but if it is fragmented then grub4dos can slow down tremendously.

I you can test on an ext3 partition whose size is not too big, things will improve, a lot. In my BIOS laptop (which I don't have with me right now), I used to have grub4dos boots Fatdog from 300GB ext4 partition. It works, but it slows down over time, especially as I keep updating Fatdog (at the same time I'm adding other files to the partition, thus the space used to allocate Fatdog OS became fragmented over time). In the end, I created a dedicated 16GB ext3 partition solely for booting.

PS: "psubdir" and "pmedia" are not supported by Fatdog, although they do no harm either. They simply ignored. Both of them are replaced by the "savefile" parameter. "pfix=fsck" also don't work, what you want is "dofsck". The only "pfix" that works is "pfix=nox" and "pfix=xorgwizard".
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

#32 Post by Billtoo »

jamesbond wrote: @All: For those who are concerned about Dirty COW bug, kernel 4.4.26 is available. You can update your Fatdog using fatdog updater (from Control Panel). Note: this can only be used for installed Fatdog.
I updated the kernel, loaded the new kernel-source-4.4.26.sfs and
recompiled the proprietary nvidia driver:

video-info-glx 1.5.3 Thu 27 Oct 2016 on Fatdog64 710 Linux 4.4.26 x86_64
0.0 VGA compatible controller: NVIDIA Corporation GF110 [GeForce GTX 560 Ti OEM] (rev a1)
oem: NVIDIA
product: GF110 Board - 12630002 Chip Rev

X Server: Xorg Driver: nvidia
X.Org version: 1.18.3
dimensions: 3840x1080 pixels (1204x343 millimeters)
depth of root window: 24 planes

direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 560 Ti/PCIe/SSE2
OpenGL core profile version string: 4.3.0 NVIDIA 375.10

Thanks

User avatar
ally
Posts: 1957
Joined: Sat 19 May 2012, 19:29
Location: lincoln, uk
Contact:

#33 Post by ally »

it's a 20gb ext4 partition, no count on the current menu.1st, used fatdog to create a new menu.1st which shows the counter you described, it does not pick up other installations however

the 'thrashing' I'm seeing is the OS load, it's just slow, I had wrongly assumed it was hanging

I will reformat the partition and report back

:)

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#34 Post by prehistoric »

Now running kernel 4.4.26 with Fatdog 710 beta 2. No problems.

Also recommend people update Adobe Flash Player, just in case some program of theirs still uses this. The current Adobe vulnerability is a big one.

One piece of advice, based on my own mistake, is to be sure you know which version of Fatdog you are updating. I forgot I had two 710 beta versions, and only realized I had updated the wrong one when I checked system information afterward. Doesn't appear to have done any harm, but if I had not checked I would be running a kernel vulnerable to dirty cows.

User avatar
dr. Dan
Posts: 96
Joined: Mon 20 Apr 2015, 17:45
Location: Oregon, U.S.A.

Fatdog64 710b2

#35 Post by dr. Dan »

Hello, and thanks to the Fatdog64 developers. I've been enjoying it since early 2015, and, having tried quite a number of other GNU/Linux distributions on a few machines, keep coming back to Fatdog64. It works well, it works on most hardware, it is enjoyable and generally easy, mostly out of the box.

Dell D430, no HD, 16G flash drive with FD64 702 on partition 2, but currently booted to 710b2 from DVD:

-Computer-
Processor : 2x Intel(R) Core(TM)2 CPU U7600 @ 1.20GHz
Memory : 2040MB (180MB used)
Machine Type : Physical machine
Operating System : Fatdog64 [710]
User Name : root (root)
Date/Time : Fri Oct 28 22:40:57 2016
-Display-
Resolution : 1280x800 pixels
OpenGL Renderer : Mesa DRI Intel(R) 945GM
X11 Vendor : The X.Org Foundation
-Audio Devices-
Audio Adapter : HDA-Intel - HDA Intel
-Input Devices-
Lid Switch
Power Button
Sleep Button
Video Bus
AT Translated Set 2 keyboard
PC Speaker
HDA Intel Line
HDA Intel Headphone
AlpsPS/2 ALPS DualPoint Stick
AlpsPS/2 ALPS DualPoint TouchPad
Dell WMI hotkeys
-Printers-
No printers found
-SCSI Disks-
HL-DT-ST DVD+-RW GSA-T21N
General USB Flash Disk

Generally like the changes.

Dan

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

openSSL update for Fatdog64 Beta1/Beta2

#36 Post by belham2 »

Hi James (or anyone that can help),

Question: I am running the Fatdog64-710-Beta1, and am reluctant to do a fresh wipe and install of this new Beta2------Beta1 updates nicely to the new kernel (4.4.2.26) but I am wondering about how to update Beta1's openssl?

Beta1's openssl version is still 'OpenSSL 1.0.2h', which is two versions behind the important security-updated releases OpenSSL.org released over the past several months. The current up-to-date openSSL is 1.0.2j, if I understand the openSSL website correctly.

Is there anyway for us to get an an update for this? Or am I forced to have to jump to this new Beta2 release (assuming here that Beta2 has the latest openSSL version)?

As a note, I have tried to compile the openssl 1.0.2j for my Fatdog64 Beta1, and I just never have any luck compiling in Fatdog64, for any item (and the devx, and all esle, are installed). I even tried to download Slavvo's new "openssl.1.0.2j' he posted a few weeks ago, to see if it would install in Fatdog64, but after converting it to Fatdog package format, it too failed to install.

Is there any chance you (or someone) can upload a version of the latest 'openSSL' so that we still using the 1st Beta1 version don't have to immediately jump to the Beta2??

Thank you for any consideration in this matter.

quirkian2new
Posts: 152
Joined: Tue 06 Oct 2015, 14:10
Location: on the inter-planet train

#37 Post by quirkian2new »

downloaded fd710beta2, boot the iso directly from grub4dos. Although iso size is now 355mb, there seems no sacrifice in speed as compared with FD701/702. Very solid and impressive indeed.

Thanks kirk, james and all the dev team for such great distro.
Attachments
screen1.jpg
(75.22 KiB) Downloaded 777 times
fd710_beta2.jpg
(85.05 KiB) Downloaded 775 times

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

Re: openSSL update for Fatdog64 Beta1/Beta2

#38 Post by Billtoo »

belham2 wrote:Hi James (or anyone that can help),

Question: I am running the Fatdog64-710-Beta1, and am reluctant to do a fresh wipe and install of this new Beta2------Beta1 updates nicely to the new kernel (4.4.2.26) but I am wondering about how to update Beta1's openssl?
Hi,

I'm running Beta2, I went to BLFS and downloaded the source code and followed the instructions to compile it, it seems to be working.

http://www.linuxfromscratch.org/blfs/vi ... enssl.html
Attachments
Openssl.jpg
(89.07 KiB) Downloaded 777 times

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

Re: openSSL update for Fatdog64 Beta1/Beta2

#39 Post by belham2 »

Billtoo wrote:
belham2 wrote:Hi James (or anyone that can help),

Question: I am running the Fatdog64-710-Beta1, and am reluctant to do a fresh wipe and install of this new Beta2------Beta1 updates nicely to the new kernel (4.4.2.26) but I am wondering about how to update Beta1's openssl?
Hi,

I'm running Beta2, I went to BLFS and downloaded the source code and followed the instructions to compile it, it seems to be working.

http://www.linuxfromscratch.org/blfs/vi ... enssl.html

Hi Bill,

Thanks for replying. I am hesitant to think that the compile from BLFS of openssl-1.0.2j installed correctly and did nothing other than install the identifying doc (that you see in CLI) and not the correct placement of the libraries and folders.

For example, that compile, installs four directories: /etc/ssl, /usr/include/openssl, /usr/lib/engines and /usr/share/doc/openssl-1.0.2j (the one the terminal is trying to say that "j" is installed). Fatdog64 does not have three of the files currently existing; the only one it has is "/etc/ssl".

Also, Fatdog64's installed libraries of libcrypto and libssl (inside /usr/lib64) have six different entries in total, not just two. the compile only installs two, but a user needs all six with all sym linked correctly. Also, there is the matter of the 'Certificate Authority Certificates Dependencies', and I am not sure if a new compile and attempt at install does not require the CACd(s) to be re-done.

What would really help, is if you could look in your /usr/lib64 and inspect each all libssl.* files and all libcrypto.* files & symlinks. When right-clicking on each of those files, it is my understanding they all need to show the exact date and time you did your compile. Otherwise, the terminal is just fooling you into thinking openssl-1.0.2j is being used. This 'fooling', from what I've seen on other pups, is unfortunately is a common problem with a few other pups that supposedly have done a 'openssl' update.

Let us know what you find on your inspection (also, you might want to get rid of the three new files the compile created---Fatdog64 does not see them, never will, and they'll only linger & possibly cause problems down the road).


As a side note, I do not understand why "openssl" updates are not something that is stayed on top of by all pup & pup-related creators. It is one of the key backbones of having a secure system (just think of the all the 'wget' that many of us do...that alone should cause immediate openssl updates to be released & uploaded to the OS's repositories...or think of the number of 'https' sites many of us frequent). But I know this is just my opinion...maybe the sacrifice of a bit of security is necessary to get pup & pup-related releases out the door. :?

Illutorium
Posts: 170
Joined: Wed 06 Aug 2014, 07:12

So I have a question about a Command Compile at "UEFI ISO"

#40 Post by Illutorium »

When if FatDog64 can be use at grub2.efi (efiboot.img|Grub 2.0) that's I will be try find to be compile at Boot with rEFInd for My Build (via http://murga-linux.com/puppy/viewtopic.php?t=108681)
Because someone puppies builds at Woof-CE uses at "isolinux only" instead and that's wouldn't have a "True UEFI Font".
and I will be try to be finding at UEFI compile for ISO then I recived at only Information at a "USB-from-only" but with a "Grub2 only" -> http://easy2boot.com/uefi-grub2-ptn2 (from a post -> http://www.murga-linux.com/puppy/viewto ... 876#903876)
When I finded at a FatDog64 UEFI binary for 32bit PAE anyway -> http://distro.ibiblio.org/fatdog/packag ... i686-1.txz
So that's will be compile at "GRUB2 frist" or a "rEFInd frist"? (with efibootmgr/efitools/syslinux-efi32)
Attachments
TahrPAE-NonUEFI-isolinux-grub-v0.97.png
(29.25 KiB) Downloaded 724 times
Slacko-FakeUEFI-isolinux-Grub-v0.97.png
(33.45 KiB) Downloaded 718 times
FatDog64-EfibootAtgrub2.efi-rEFInd-GRUB2.png
Version: 701
(22.04 KiB) Downloaded 722 times

Post Reply