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

[jamesbond]

@mories - thanks - fixed. The 3 copies of errors obviously because I cut and pasted - and pasted the wrong font name I was wondering why it didn't show up when I tested but I put it down to timing problem (which does happen on some machines).

@SFR - thanks for the report layout and the patch, I will try that too (may take some time, I already have a backlog for things to test on fd64 and fatdogarm).

@gcmartin - it is helpful if you can provide the link to your /etc/resolv.conf. Perhaps bundle it together in the the reports from bugreport in a convenient tarball for me to look.

Bugreport is command-line only, not in the menu (it's a good idea though - next release will have it on Control Panel -> Utilities). If you can't run it successfully, please edit /usr/bin/bugreport.sh and comment out the part that runs hardinfo, and just let it run the rest. I will need that info, otherwise we will be back and forth making posts guessing your hardware/network environment and progressing nowhere.

Oh, by default there is no firewall running, and MDM/LVM boot option has *no* any impact at all on MTP/USB

@step, @01micko - thanks for the info. I will see what I can do with that. I am not very familiar with MTP, the only android device that works (for me) is the Nexus7, which happens to be the "reference" platform and as such it will do MTP in the "correct way". I have other cheap non-branded android phones that does not support MTP and/or does not support it properly and will not talk to libmtp at all, so my testing is very limited. I will perhaps remove the wording for the udev rules, after some contemplation, I agree that although the message is probably right, most of the time it confuses rather than help.

@all - thanks for the lively discussion.

EDIT: I put up an experimental changelog, here: http://distro.ibiblio.org/fatdog/packag ... ngeLog.txt. This is experimental because I don't know whether I can sustain the extra effort to maintain this file. If I can't keep it updated I will remove it altogether.

[SFR]

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

Hmm, I don't have this warning...
Oh well, I'm afraid I have to admit my failure in your case, but maybe James will be able to help..?

Greetings!

[lugathe]

Hello, there is a bug when you try to write in japanese, you need to download the fcitx, fcitx-anthy and anthy, but there is no fcitx config-tool package....
and when i tried to install the config-tool and the anthy had errors, and I could not use...

Please update and let working all packages to write in japanese.

thank you

[L18L]

In Fatdog64-700 I could read Japanese IIRC.

[gcmartin]

Data requested to assist in diagnosing the DNS issue has been provided in the prior thread thru updates...HERE!

[gcmartin]

New issue unique to FD701 (booted from DVD) that surfaces when first save-session is done on shutdown/reboot.

Scenario
When system is initially booted, it is booted with options 3 (multisession) or (no save). The system progresses to desktop and settles with NO activity except a plain desktop. After several minute I get back to PC and begin to peruse the desktop using visible taskbar items to understand the system. Noticing time needs, I open Menu>Setup>Control Panel and manually step thru the localization tab items allowing the desktop to restart on each utility's request.

All is well (aside from the WAN issues reported) and LAN issues work as expected on the 2 DELL's I have tested.

Now, for the issue: I reboot,allowing the PCs to save their sessions. On reboot, I take boot option 3 (multisession) allowing the system to boot to its desktop. Upon arrival to desktop, each PC now takes me (the user) thru a chain of steps, separately, which mimic the EXACT SAME THINGS ANSWERED in the initial DVD session use. ... exact apps found in "localization tab" of the Control Panel. I can see that this intends to do, in a longer stepwise manner, the same things that @BarryK's FirstRUN does for initial system boots.

But, the behavior intended, I think was suppose to occur on the system very first boot from DVD VERSUS doing it, here, after the system has already, manually, been set when this was NOT offered at initial boot.

Might be something to rearrange to match what I think you want automation to provide to users initially starting FD701+ on its very first boot. Or use @BarryK's FirstRuN where he is currently considering Language implementation for initial use by users starting their desktops for the very first time.

[tomhewitt]

EDIT: I put up an experimental changelog, here: http://distro.ibiblio.org/fatdog/packag ... ngeLog.txt. This is experimental because I don't know whether I can sustain the extra effort to maintain this file. If I can't keep it updated I will remove it altogether.

Geeeeeeeez

If you don't have time to add a few lines of text to a log file then you don't have time for this project or fixing it.

If you or Kirk have any sense then you would both scrap the current fatdog and start again with the quirky 64 core so Barry's packages can be used and the forum is supporting it instead of this fragmented 2 man poke and hope approach when you have time too not have time.

let's be real about this.

[jamesbond]

@lugathe: I have uploaded fcitx-configtool. Please re-install fcitx, fcitx-anthy, and anthy itself. You will also need CJK font. font-wqy-microhei-ttf-0.2.0-noarch-1 should do fine, but you can use others as needed. You will need to logout/login again for the change to take effect.

@gcmartin: firstrun-wizard.
In Fatdog, firstrun-wizard will be run *after* the system has a savefile for the first time (thus, after the first session save). However, you are right that if you have already configured the settings before saving the session, the firstrun wizard should not offer to re-setup the same thing again. Fixed for next release.

@gcmartin: your network problem
Install "ldns" package from repo. Since your machine can't resolve the address, do it this way:
1. download this file http://distro.ibiblio.org/fatdog/packag ... 6_64-1.txz from a working machine, to an USB flash drive
2. bring that usb flash drive to the problem machine.
3. right-click, and choose install.
Then open terminal run "drill internet-address-that-you-can't-navigate" (e.g., drill www.google.com), then post please post the output here.

[gcmartin]

Done! Want to ask this question: Could the subnet mask be why FD700 is now exhibiting this behavior with internet browser use? Sure you already noticed this, right.

See results in the earlier post, here.

Thanks @JamesBond. The subnet was just an idea as I search for some clues to why this exist in just this distro. Please understand, that this is a NEW issue not seen by any prior distro on my LAN. My LAN is not new with has NO new equipment/devices that would/could affect this distro on this PC(s).

Any additional ideas, please share as I can test on these PCs this week with this distro.

[jamesbond]

@gcmartin: Could the subnet mask be why FD700 is now exhibiting this behavior?
Your subnet has no problem. You can ping - so your network essentially works. Whether it is working *well* or not is another problem.

@step: re: mtp-info.sh
simple-mtpfs updated. You may want to take a look. New mtp-browser.sh that uses a home-brewed simple-mtpfs-detect, taking your idea of mtp-info.sh into a binary that does not take mins to run. (I have a android phone here that claims to support MTP but simple hangs if I run mtp-detect on it).

[step]

simple-mtpfs updated. You may want to take a look. New mtp-browser.sh that uses a home-brewed simple-mtpfs-detect, taking your idea of mtp-info.sh into a binary that does not take mins to run. (I have a android phone here that claims to support MTP but simple hangs if I run mtp-detect on it).

New mtp-browser.sh and updated simple-mtpfs tested with my phone; it worked great.

25 April 2015
* load_sfs.sh will run autorun.sh if unload failed (thanks step)

This also worked great to stop a running service when unloading the SFS.

[L18L]

New mtp-browser.sh and updated simple-mtpfs tested with my phone; it worked great.

Not with my 2207:0011 Xiron_10.1 tablet.

But can8v's MTPconnect 0.9 with tempestuous' go-mtpfs-20130628-64bit.pet works for me.
Without those silly "Please report this VID/PID and the device model to the libmtp development team" messsage.

Download go-mtpfs-20130628-64bit.pet and MTPconnect_0.9.pet,
Right-click and Convert to New Package Format,
then right-click these and Install Package.

Fix script /root/Startup/MTPconnetct.sh

Code: Select all

sed -i 's/type fox/type rox/' /root/Startup/MTPconnetct.sh

and run by

Code: Select all

 /root/Startup/MTPconnect.sh

( not Fatdog's style but works for now)

[step]

New mtp-browser.sh and updated simple-mtpfs tested with my phone; it worked great.

Not with my 2207:0011 Xiron_10.1 tablet.

Yeah, I think we'll have to accept that YMMV with MTP for new phones and tablets. And even for old ones, especially the cheaper models. It's good that go-mtpfs works for your tablet, so at least you have a means to connect it.

Did the previous version of mtp.browser.sh fail in the same way as the new version does for your tablet?

Without those silly "Please report this VID/PID and the device model to the libmtp development team" messsage.

If you want to help the libmtp dev team collect data about new models, so they won't stay new in the next update, submit a bug report with the VID/PID of your model:
1. connect your tablet, open a terminal window and run "mtp-detect"; output should say VID/PID unknown... please submit to dev team.
2. cut and paste output into an "Unknown device" anonymous bug report at this page http://sourceforge.net/p/libmtp/bugs/

[jamesbond]

@L18L: Thank you for the info. However ...

New mtp-browser.sh and updated simple-mtpfs tested with my phone; it worked great.

Not with my 2207:0011 Xiron_10.1 tablet.

Yeah, I think we'll have to accept that YMMV with MTP for new phones and tablets. And even for old ones, especially the cheaper models. It's good that go-mtpfs works for your tablet, so at least you have a means to connect it.

+1.
I just built the latest go-mtpfs, I thought if it works with L18L's tablet, it may work with my Android phone with the broken MTP. Well, it doesn't (in my case: mtp-detect will hang, simple-mtpfs will hang, go-mtpfs says it has mounted the phone but there is actually nothing in the mountpoint). So yes, it is very finicky.

@step:

If you want to help the libmtp dev team collect data about new models, so they won't stay new in the next update, submit a bug report with the VID/PID of your model:
1. connect your tablet, open a terminal window and run "mtp-detect"; output should say VID/PID unknown... please submit to dev team.
2. cut and paste output into an "Unknown device" anonymous bug report at this page http://sourceforge.net/p/libmtp/bugs/

I just uploaded libmtp 1.1.9, and I think your device is now recognised (my broken android phone is now also recognised as Zopo in 1.1.9 )

Anyway, for now I will now step back from this MTP stuff to look at other stuff in my todo list. But feel free to contribute ideas and fixes as you find them.

[L18L]

New mtp-browser.sh and updated simple-mtpfs tested with my phone; it worked great.

Not with my 2207:0011 Xiron_10.1 tablet.

Yeah, I think we'll have to accept that YMMV with MTP for new phones and tablets.

So you think it is new?
No it is not new.

Did the previous version of mtp.browser.sh fail in the same way as the new version does for your tablet?

Yes.
I was recalling MTP working with that tablet in one of t he Puppies.

If you want to help the libmtp dev team collect data about new models, so they won't stay new in the next update, submit a bug report with the VID/PID of your model:
1. connect your tablet, open a terminal window and run "mtp-detect"; output should say VID/PID unknown... please submit to dev team.
2. cut and paste output into an "Unknown device" anonymous bug report at this page http://sourceforge.net/p/libmtp/bugs/

2207 is a vendor.
0011 is a product of this vendor.
lsusb displays them if plugged in.
Xiron 10.1 is just a string.

Why should I keep a database containing some (not all ) IDs of other tablets?

No, I don't want to support what I have been calling silly.

Hope I have made clear my varying mileage.

Just to be sure I have installed these packages on a new quirky:
It is just working without silly messages....

[L18L]

I just built the latest go-mtpfs, I thought if it works with L18L's tablet, it may work with my Android phone with the broken MTP. Well, it doesn't (in my case: mtp-detect will hang, simple-mtpfs will hang, go-mtpfs says it has mounted the phone but there is actually nothing in the mountpoint). So yes, it is very finicky.

Sure you had unlocked before or after plugging in?
http://www.murga-linux.com/puppy/viewto ... 617#803617

[step]

I just uploaded libmtp 1.1.9, and I think your device is now recognised (my broken android phone is now also recognised as Zopo in 1.1.9 )

I will test the new libmtp. I'm not surprised that your phone is recognized as Zopo. Several phones use HTC's chips and all report the same HTC PID/VID to simple-mtpfs (and maybe to go-mtpfs, but I don't know for sure because I don't use go-mtpfs). simple-mtpfs is simple also in the sense that it doesn't deep query the phone, it doesn't go deeper than the HTC chip level. To deep query your phone and find out the _real_ product and vendor names you need to run mtp-detect, which is accurate indeed, when it works, but it takes several seconds to interact with the phone.

[step]

Yeah, I think we'll have to accept that YMMV with MTP for new phones and tablets.

So you think it is new?
No it is not new.

No, I don't know if it's old or new. I wrote:

Yeah, I think we'll have to accept that YMMV with MTP for new phones and tablets. And even for old ones, especially the cheaper models.

So I specifically referred to both new and old models.

2207 is a vendor.
0011 is a product of this vendor.
lsusb displays them if plugged in.
Xiron 10.1 is just a string.

Why should I keep a database containing some (not all ) IDs of other tablets?

I don't understand to whom the "I" in your question refers to. To clarify my thinking: the libmtp team keeps the database.
Why do they keep a database and ask people to report unrecognized VID/PID? My speculation is that it has something to do with the layered access approach that I outlined in my reply to jamesbond above. But I don't know for sure, I haven't actually looked at their library code.

[jamesbond]

@L18L: yes, I read that post. As well as some contradictory posts (elsewhere, not in this forum) about how I am supposed to enable (or disable) USB debugging for it to work. It still does not. There is one thing I haven't tried. Some people said I need to take the MicroSD card off the device before connecting with the device. That's a bit silly. If I need to take the SD card (which, in my cheap phone, means I have to power if off, take the battery out before I can unplug the SD card), then why do I bother with MTP at all I am on Android 4.2 by the way and I am not alone: https://bugs.launchpad.net/ubuntu/+sour ... ug/1314556.

I have no real need for MTP on this device because it has the muchly superior USB storage mode, but I understand newer Android devices may not have this for various reasons.

@step/@L18L: every device implements MTP slightly differently. The database kept by the libmtp team is stored in a file called music-players.h; and in addition to the PID/VID and name, it also contains flags that tells libmtp how to handle some quirks for a given device. Having a device there simply means that someone has tested the device and found it to work with a given set of flags. Of course unconfirmed devices may work too, but it feels good to know that someone else has confirmed that. And since libmtp team can't possibly test all the MTP devices in the world, they are hoping that the users can help each other by submitting known good results. If the list is not complete it's because some people can't be bothered. Nothing else, I guess. (As a s note - smartmontools does exactly the same thing; collecting PID/VID for USB storage devices that needs some flags to access, etc).

As a side note of this go-mtpfs experiment, I have uploaded the "go" compiler to the SFS repo. To use it, you just need to load the SFS, then export PATH=/usr/local/go/bin:$PATH. That's it. Devx actually has go compiler too (gccgo - the GCC front-end to go), but:
a) it only complies to go version 1.1.2 (go is as fast moving target), and
b) is lacks the "go" command (which is apparently works like "make", "git pull", "wget" all combined together).

cheers!

[gcmartin]

I have a problem with the system as delivered and the utilities to allow update.

The system cannot

• get to the WAN for package management
• get to the WAN for Menu Utilities such as Get Flash
• get to the WAN thru browser URLs except with when using the remote's IP address

This system is pristine without ANY new or changed products within the system. The ONLY things which have been changed is the 1st tab of the control panel.

In the problem with the system that negates these utilities to operate over the WAN, what needs to be brought to bear to resurrect this problem.

It is NOT the distro as it has been downloaded several times.

The "drill" command has shown nothing more than what was already provided to request assistance. Yes, we already knew that there is some DNS resolution occurring as was shown by the ping command and use of the IP addresses in the browser to get to remote sites.

But, the ability of the system to manage URL names in its utilities is NOT working as has been expected in the generations of browser use....including in FD50x/FD6xx of the past.

This problem is unique to this family of FD7xx.

Any ideas about the changes that have been done in the system's LAN/WAN services would be a clue of why this is occurring. Something has changed!

Any ideas on this problem, as shown and updated in this post, below, would be helpful. And, if you don't have the answer, PLEASE, share that, too by letting know if there were changes that has cause the system to NOT do things it used to do in LAN/WAN, but, please also share what was changes so that those elements can be reviewed.

Again, I remember @Kirk involvement in some past resolutions.

I am left wondering what has caused this new round of problems in this area of the system not knowing what changes or why old practices were abandoned .

Information can be helpful, at least.