Fatdog64-700/701 [April 22 2015] [CLOSED]

[step]

Thanks for the 701 update.
mtp-probe.sh has some issues. When I connect my android phone and run mtp-probe.sh rox opens in the mount directory, but all phone sub-folders are empty - and often times the folder names in phone memory appear under the SD card. If I monitor /var/log/messages I can see that the phone disconnects (or is disconnected?) almost immediately after rox opens the mount point, so no wonder that all folders look empty and misplaced.
01micko's original script still works fine with my phone on FD-701. So I can't point my finger to mtp-probe.sh but it's a strong suspect.

Also, the message about the "need to edit 69-libmtp.rules" isn't very helpful, I'm not even sure that one needs to add a phone there for the phone to be recognized. From a short look at the rules it would appear that they are used to exempt some sensitive devices from being probed.

[gcmartin]

Thanks @L18L, that was a typo. It is "Control Panel>Updates>Update Flash Player" and the FD701 does NOT navigate via URLs. It will navigate in browser via IP addresses, but NOT via URLs as was reported in FD700 by others.

My system cannot indicate "up to date" as it cannot get to the internet to verify via the Update method provided.

Update 1: On my 4GB DELL, I am able to navigate. BUT, I CANNOT on the 1GB desktop PC????
Update 2:

Code: Select all

# echo "Dell 4GB AIO has a wireless LAN adapter built in"
Dell 4GB AIO has a wireless LAN adapter built in
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 5c:ff:dd:e7:17:9e brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.14/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5ef9:ddff:fee2:179e/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether f4:f7:e2:69:c9:a5 brd ff:ff:ff:ff:ff:ff
# 
# 
# echo "Dell 1GB desktop does NOT have a wireless"
Dell 1GB desktop does NOT have a wireless
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:26:ff:97:24:15 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.13/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:76ff:fe97:f415/64 scope link 
       valid_lft forever preferred_lft forever

Update 3: Requested /etc/resolv.conf. Same "resolv" used by ALL this LAN's PCs set via DHCP

Code: Select all

# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
nameserver 192.168.0.1
nameserver 0.0.0.0
# /etc/resolv.conf.tail can replace this line

Update 4: I rebooted, saving the session to DVD, the 4GB AIO only to find that after its arrival on desktop, it no longer is capable of browser routing via URLs. I've attached below, the files I believe you are after showing LAN's behavior. If expanded info is needed, I will provide. The following show that the system has ONLY partial success in pinging WAN locations:

Code: Select all

# ping -c 2 google.com
PING google.com (173.194.121.36): 56 data bytes
64 bytes from 173.194.121.36: icmp_seq=1 ttl=52 time=19.982 ms
--- google.com ping statistics ---
2 packets transmitted, 1 packets received, 50% packet loss
round-trip min/avg/max/stddev = 19.982/19.982/19.982/0.000 ms
# ping -c 4 google.com
PING google.com (173.194.121.6): 56 data bytes
64 bytes from 173.194.121.6: icmp_seq=1 ttl=50 time=21.142 ms
64 bytes from 173.194.121.6: icmp_seq=2 ttl=50 time=21.867 ms
64 bytes from 173.194.121.6: icmp_seq=3 ttl=50 time=21.837 ms
--- google.com ping statistics ---
4 packets transmitted, 3 packets received, 25% packet loss
round-trip min/avg/max/stddev = 21.142/21.615/21.867/0.335 ms
# ping -c 5 google.com
PING google.com (173.194.121.36): 56 data bytes
64 bytes from 173.194.121.36: icmp_seq=1 ttl=52 time=19.538 ms
64 bytes from 173.194.121.36: icmp_seq=2 ttl=52 time=20.432 ms
64 bytes from 173.194.121.36: icmp_seq=3 ttl=52 time=22.459 ms
64 bytes from 173.194.121.36: icmp_seq=4 ttl=52 time=19.296 ms
--- google.com ping statistics ---
5 packets transmitted, 4 packets received, 20% packet loss
round-trip min/avg/max/stddev = 19.296/20.431/22.459/1.245 ms
# ping -c 5 yahoo.com
PING yahoo.com (98.138.253.109): 56 data bytes
64 bytes from 98.138.253.109: icmp_seq=1 ttl=46 time=58.067 ms
64 bytes from 98.138.253.109: icmp_seq=2 ttl=46 time=57.643 ms
64 bytes from 98.138.253.109: icmp_seq=3 ttl=46 time=58.648 ms
64 bytes from 98.138.253.109: icmp_seq=4 ttl=46 time=58.972 ms
--- yahoo.com ping statistics ---
5 packets transmitted, 4 packets received, 20% packet loss
round-trip min/avg/max/stddev = 57.643/58.333/58.972/0.513 ms
# 

Update 5:Added utility and ran the drill command.

Code: Select all

# drill www.yahoo.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 26502
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; www.yahoo.com.	IN	A

;; ANSWER SECTION:
www.yahoo.com.	234	IN	CNAME	fd-fp3.wg1.b.yahoo.com.
fd-fp3.wg1.b.yahoo.com.	35	IN	A	98.139.180.149
fd-fp3.wg1.b.yahoo.com.	35	IN	A	98.139.183.24

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 30 msec
;; SERVER: 192.168.0.1
;; WHEN: Sat Apr 25 16:16:18 2015
;; MSG SIZE  rcvd: 90
#

2nd LAN adapter/services issue which exist
Also, although I know this does not work in FD7xx, if you would like a report from the PC which has 2 ethernets built into the motherboard, I can do a SysReport capture so that the FD team can add's @Kirk's FD5xx/FD6xx active wire discovery into this version of FD7xx. I think this was mistakenly striped out thinking that somehow it would impact boot time, which it didn't. Although, I am familiar in steps to activate, the automation that was in prior FATDOGs has been removed from this current distro version.

Again, for clarity, this is a DVD based FD7xx usage where once booted, it is rarely ever rebooted ... Same as was done in the past with FATDOG5s and FATDOG6s.

As I'm to understand, it appears that @Kirk's LAN methodology from FATDOG5+ has been redesigned which may be the reason for much of the differences seen over past months in LAN.

Hope this is clear. This problem is unique to only FD700s.

[Ted Dog]

really happy that it pairs so nice and easy, using it now, hope to figure out what I am doing wrong on my Android device since this Blue Tooth keyboard was for that.
At least I know its not defective ( does match my minimac so it may keep it ) wow time is really off must not have set up timezone info..

Thanks again for this and ARM Beta3.

[Ted Dog]

Having repeatable issues applying amd-catalyst-14.501.1003-x86_64-700.txz to 701 and not having it work. Did blacklist other and triple reboot but ati-config from menu throws error message.

[step]

Version 701 /usr/bin/x11vnc-helper script is broken. I think you can fix it by simply replacing line 3 with

Code: Select all

	exec x11vnc -gui tray=setpass -rfbport PROMPT -bg -o "%HOME/.x11vnc.log.%VNCDISPLAY"

that is, insert x11vnc -gui tray=
(fix is untested because I'm typing from another box right now).

[L18L]

Thanks @L18L, that was a typo. It is "Control Panel>Updates>Update Flash Player" and the FD701 does NOT navigate via URLs. It will navigate in browser via IP addresses, but NOT via URLs as was reported in FD700 by others.

My system cannot indicate "up to date" as it cannot get to the internet to verify via the Update method provided.

Hm.... I did forget to report that I did not connect into internet.
The system did report "up to date" though.

Thus this seems to the basic issue: up-to-date-test without internet

[jamesbond]

@step: x11vnc-helper
Thanks, fixed. For others - re-install x11vnc from repo.

@step: mtp problem
please run mtp-browser.sh from terminal, in case there are error messages. Also run simple-mtpfs manually if you have problems so we can see what causes it.

That 69-libmtp.rules is both to stop autodetection, as well as adding devices that aren't supported by the auto-detect function, so it is accurate: if your device is not detected, then in most likelihood the auto-detect has failed and you need to add your own device id manually there.

@Ted Dog: amd catalyst problem
What is the error messages? Did you start from blank savefile?

@gcmartin: dns issue error
run bugreport.sh and copy over your /etc/resolv.conf on the problematic machine, pass them to me.

@L18L: DISTRO_SPECS:
fixed

@L18L: update-flash & rc.nls.gz
I will check

[mories]

Typo in rc.sysinit:
setfont LatGrkCyr-8x16

In the 3 lines used.

Also in FatdogArm Beta3.

[01micko]

Thanks for the 701 update.
mtp-probe.sh has some issues. When I connect my android phone and run mtp-probe.sh rox opens in the mount directory, but all phone sub-folders are empty - and often times the folder names in phone memory appear under the SD card. If I monitor /var/log/messages I can see that the phone disconnects (or is disconnected?) almost immediately after rox opens the mount point, so no wonder that all folders look empty and misplaced.
01micko's original script still works fine with my phone on FD-701. So I can't point my finger to mtp-probe.sh but it's a strong suspect.

Seems weird. On first run it failed for me, but I think once udev settled it worked.

Also, the message about the "need to edit 69-libmtp.rules" isn't very helpful, I'm not even sure that one needs to add a phone there for the phone to be recognized. From a short look at the rules it would appear that they are used to exempt some sensitive devices from being probed.

It's true at the start of 69-libmtp.rules there are some entries to avoid sensitive devices but the majority of that file is mostly compatible devices which the libmtp team constantly update. Looks to me like you don't need to touch that file as your device is recognised. I tend to agree that it it is not a really useful message, especially to the uninitiated who wouldn't have a clue how to edit or where to find such file.

Be aware that Linux MTP support is a bit dodgy (in my opinion, but improving) and this could be the cause of some of your unusual behaviour. Behaviour varies accross android versions too, so probably best to follow James' advice and run mtp-browser.sh in a terminal emulator to see if there is a scripting error, fuse error, libmtp error or simple-mtpfs error.

Cheers.

[L18L]

Typo in rc.sysinit:
setfont LatGrkCyr-8x16.

In the 3 lines used.

Yes, a typo!

Why 3 lines?

LatGrkCyr displays äöüÄÖÜß (de) very well.

@SFR, what about pl ?

(time to unfatten this dog a bit )

· After that I added letters to cover what I think are all the live
languages West of the Caucasus (I've added a couple of glyphs for
azeri using a latin alphabet, but there isn't space to include the
armenian or georgian alphabets, nor the many extra cyrillic letters
needed for the other languages of the Causcasus. So, if anyone
*does* need those, try my sigma-consolefonts. I don't expect
anyone will ever have console text in many of the 'supported'
languages, but if people can display them on a tty then it *might*
happen.

[L18L]

Code: Select all

      <br>
      <em class="cmd1">Alt-F3</em>&nbsp; ---&nbsp; Open application
      Find'N'Run.<br>

should be inserted
after line 48 of file:///usr/share/doc/faqs/keys.html

[terrapin231]

This is SMPlayer and SMTube for Fatdog64-700. They require mplayer-static from the Fatdog repository. libQtScript is the only Qt4 library needed by SMPlayer that is not already installed in Fatdog. That can be found in this same directory as SMPlayer.
https://drive.google.com/folderview?id= ... sp=sharing

If not already found, see: http://www.murga-linux.com/puppy/viewto ... 7&start=30

Thanks WillM. Working well - saves me the full Qt4 sfs load on my cobbled-together Smplayer/tube deb conversion install. I see there's a SFS available too:

Thank you! All four components packaged as a single SFS:
sfs: smplayer-1.4.9.0.6824-x86_64-sfs.sfs 12.7 MB https://mega.nz/#!nklGkazb!Vlh9KJnx_V1B ... A0OXEQbg0k
md5: smplayer-1.4.9.0.6824-x86_64-sfs.sfs-md5.txt 94 B https://mega.nz/#!C5VRwCCQ!dRWOcAeL7G3a ... _fAB7IHQA0

[SFR]

LatGrkCyr displays äöüÄÖÜß (de) very well.

@SFR, what about pl ?

Yup, this font is ok (see scrsht).
___________

I am the one who maintains hardinfo.

Not a high priority issue, but if you'll be particularly bored one day.
The "Sensors" has always been blank for me on Toshiba/coretemp (Acer/k10temp is fine, btw).

Here's my "layout":

Code: Select all

# sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +56.0°C  (high = +80.0°C, crit = +90.0°C)
Core 2:       +50.0°C  (high = +80.0°C, crit = +90.0°C)

# find /sys -name "temp*" -exec grep -H "" {} \; | sort
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp2_crit:90000
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp2_crit_alarm:0
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp2_input:56000
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp2_label:Core 0
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp2_max:80000
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp4_crit:90000
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp4_crit_alarm:0
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp4_input:50000
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp4_label:Core 2
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp4_max:80000
# 

Greetings!

[L18L]

The "Sensors" has always been blank for me on Toshiba/coretemp (Acer/k10temp is fine, btw).

For me blank on ASROCK AD2550-ITX too.

Code: Select all

#  sensors 
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +54.0°C  (crit = +100.0°C)
Core 1:       +58.0°C  (crit = +100.0°C)

# find /sys -name "temp*" -exec grep -H "" {} \; | sort 
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp2_crit:100000
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp2_crit_alarm:0
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp2_input:55000
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp2_label:Core 0
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp3_crit:100000
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp3_crit_alarm:0
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp3_input:58000
/sys/devices/platform/coretemp.0/hwmon/hwmon0/temp3_label:Core 1
#
# hardinfo
last: /var/log/wtmp kann nicht geöffnet werden: Datei oder Verzeichnis nicht gefunden

Hope that will make any sense.

[SFR]

Hmm, I think I found the cause - Hardinfo begins the search from temp1_input and if the file doesn't exist, it stops searching, so temp2_input (and subsequent) are not being taken into consideration at all.

This works for me, but note that I still don't know C, so most likely this could have been done somewhat better or differently:

Code: Select all

# diff -u hardinfo-fossil/modules/devices/sensors.c.org hardinfo-fossil/modules/devices/sensors.c
--- hardinfo-fossil/modules/devices/sensors.c.org	2015-02-21 03:58:36.000000000 +0100
+++ hardinfo-fossil/modules/devices/sensors.c	2015-04-23 21:20:54.575006808 +0200
@@ -246,7 +246,10 @@
 						DEBUG("should be reading from %s", path_sensor);
 						if (!g_file_get_contents(path_sensor, &tmp, NULL, NULL)) {
 							g_free(path_sensor);
-							break;
+							if (count >= 256)
+							  break;
+							else
+							  continue;
 						}
 
 						mon = g_strdup_printf(sensor->key_format, count);
# 

Care to test my "hack", L18L?

Greetings!

[step]

@jamesbond @01micko: solved. More info below, if you've got the time. The gist of it: some code to improve phone/mount-point naming beyond what you can get from running simple-mtpfs -l.

[...] on first run [mtp-probe.sh] failed for me, but I think once udev settled it worked.
[...]
It's true at the start of 69-libmtp.rules there are some entries to avoid sensitive devices but the majority of that file is mostly compatible devices which the libmtp team constantly update. Looks to me like you don't need to touch that file as your device is recognised.

Be aware that Linux MTP support is a bit dodgy [...] so probably best to follow James' advice and run mtp-browser.sh in a terminal emulator to see if there is a scripting error, fuse error, libmtp error or simple-mtpfs error.

So today mtp-probe.sh seems to work, go figures. I did run it in a terminal emulator. My device _is_ recognized but vendor & product ids are unknown to libmtp (I filed a "new device report" to the project team). Adding vendor & product ids to udev rules is useless in this case, as the device is already recognized, and udev rules have no effect on libmtp (anyway, I added my phone ids to udev rules, just in case).
Then there's simple-mtpfs, which reports the device as unknown_vendor unknown_product. My guess is that simple-mtpfs derives its knowledge of vendor/product from libmtp's (null) knowledge of my phone ids.
mtp-browser.sh mounts my phone in ~/unknown_vendor_unknown_product, which it gets from running simple-mtpfs -l. I guess I will have to live with that until a new version of libmtp comes around with my phone ids embedded.

However, I did script a round-about way to get more descriptive vendor/product labels for phones that libmtp doesn't know about.
mtp-info.sh

Code: Select all

max=`simple-mtpfs -l 2>/dev/null | wc -l`
[ ${max} -gt 1 ] && echo "This will take longer"
stdbuf -o0 mtp-detect 2>&1 | awk '
  /@ bus / {
    printf("VENDOR_PRODUCT_ID="%s";",$1)
    bus=$4; sub(/,$/,"",bus)
    printf("BUS_NO=%03d;DEVICE_NO=%03d\n",bus,$6)
    if(++c=='${max}') exit # early exit saves several seconds
  }' |
  while read line; do
    eval "${line}" &&
    pci_path=$(udevadm info --query=path --name=/dev/bus/usb/${BUS_NO}/${DEVICE_NO}) &&
    udevadm info --export --query=property --path="/sys${pci_path}"
  done

demo on my phone:

Code: Select all

# simple-mtpfs -l
Unable to open ~/.mtpz-data for reading, MTPZ disabled.
1: Unknown vendor Unknown product

# ./mtp-info.sh
BUSNUM='004'
DEVLINKS='/dev/libmtp-4-1.8'
DEVNAME='/dev/bus/usb/004/004'
DEVNUM='004'
DEVPATH='/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.8'
DEVTYPE='usb_device'
DRIVER='usb'
ID_BUS='usb'
ID_MEDIA_PLAYER='1'
ID_MODEL='Android_phone'
ID_MODEL_ENC='Android\x20phone'
ID_MODEL_ID='2008'
ID_MTP_DEVICE='1'
ID_REVISION='ffff'
ID_SERIAL='MediaTek_Android_phone_0123456789ABCDEF'
ID_SERIAL_SHORT='0123456789ABCDEF'
ID_USB_INTERFACES=':ffff00:'
ID_VENDOR='MediaTek'
ID_VENDOR_ENC='MediaTek'
ID_VENDOR_ID='0bb4'
MAJOR='189'
MINOR='387'
PRODUCT='bb4/2008/ffff'
SUBSYSTEM='usb'
TYPE='0/0/0'
USEC_INITIALIZED='106560022'
# 

There's plenty of variables there to build a title other than unknown_manufaturer_unknown_product. Note that when libmtp doesn't know the phone manufacturer's ID, the best we can get is the MTP chip vendor ID, By comparison, mtp-detect returns these ids after querying my phone, which takes about 3-4 extra seconds):

Code: Select all

(cut)
Configuration 0, interface 0, altsetting 0:
   Interface description contains the string "MTP"
   Device recognized as MTP, no further probing.
Device info:
   Manufacturer: ZOPO
   Model: ZP999
(cut)

So if there's interest in this approach I could flesh it out in more detailed code to be added to mtp-browser.sh. Something like:

Code: Select all

foreach line in simple-mtpfs
  if match("unknown", line) then
    use the above code to get the phone title
  else
    use line to get the phone title
  endif
endfor

[gcmartin]

First
The resolv.conf is in the earlier post on URL routing. It is important to note that manual changes to the resolv by changing or adding nameservers from the internet (such as OpenDNS or Google or ...) does NOT impact the problem. The PC will obtain the IP addr of the URL BUT will NOT route any browser traffic.

This is seen, as I can ping using a URL name, and will see its IP address show in the 1st message from the ping command. But, this is where FATDOG stops traffic after gaining the IP address.

Maybe that is a hint to something that FATDOG began doing in FD700 versus in past FATDOG versions.

Is there a default F/W that is started under the covers at boot time without user knowledge?

Next
Question: Does the boot menu option 4 MDM/LVM has any impact at all on MTP/USB device connection behavior? (Y/N)

Last
Question: Isn't BugReport a utility in the Control Panel or Menu? I seem to remember this, but cannot find it. (Yes, I know it can be run from the terminal) Will have to present a bug report later as running it has locked my FD701 on the nonWiFi PC while it was running Benchmarks. Tomorrow, I will reboot the PC and activate the SWAP partition before running the utility.

[L18L]

Care to test my "hack", L18L?

Tested.

Code: Select all

					for (count = sensor->begin_at;; count++) {
						path_sensor = g_strdup_printf(sensor->path_format, path_hwmon, count);
						DEBUG("should be reading from %s", path_sensor);
						if (!g_file_get_contents(path_sensor, &tmp, NULL, NULL)) {
							g_free(path_sensor);
							
							
				           if (count >= 256)
                              break;
                           else
                         continue;
			
							
						}

Sorry, no sensors.
Greetings

[SFR]

Sorry, no sensors.

Oh, that's disappointing.
Your layout is almost the same as mine, so I wonder what went wrong...
I did use this source pkg, btw: http://distro.ibiblio.org/fatdog/source ... 04.tar.bz2

Anyway, I attached precompiled devices.so module (goes to /usr/lib64/hardinfo/modules/) - only this single file seems to be affected by my patch; the rest of original Hardinfo files can be left alone.
Could you try again with it?

Greetings!

[L18L]

Anyway, I attached precompiled devices.so module (goes to /usr/lib64/hardinfo/modules/) - only this single file seems to be affected by my patch; the rest of original Hardinfo files can be left alone.
Could you try again with it?

Tried again, also with original Usr/bin/hardinfo.
No sensors, but what is this, just a warning, but....?

Code: Select all

# hardinfo

(hardinfo:13993): Gtk-WARNING **: Useless empty GtkIconSource