TV speakers are working now, thanks.kirk wrote: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.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.
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.
Fatdog64 710 Beta2 [CLOSED]
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
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.
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.
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
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.
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.
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
#
(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.
Fatdog64 710 Beta2
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.
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
Fatdog64 710 Beta2
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.
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
Fatdog64 710 Beta2
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.
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
@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.
@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]
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
@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".
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]
I updated the kernel, loaded the new kernel-source-4.4.26.sfs andjamesbond 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.
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
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
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
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
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.
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.
Fatdog64 710b2
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
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
openSSL update for Fatdog64 Beta1/Beta2
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.
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.
-
- Posts: 152
- Joined: Tue 06 Oct 2015, 14:10
- Location: on the inter-planet train
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.
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
Re: openSSL update for Fatdog64 Beta1/Beta2
Hi,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?
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
Re: openSSL update for Fatdog64 Beta1/Beta2
Billtoo wrote:Hi,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?
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.
-
- Posts: 170
- Joined: Wed 06 Aug 2014, 07:12
So I have a question about a Command Compile at "UEFI ISO"
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)
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