Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 1 day ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 6 days, 13 hrs ago - more...
|
2014-01-02
, 19:56
|
|
Posts: 915 |
Thanked: 3,209 times |
Joined on Jan 2011
@ Germany
|
#3042
|
Originally Posted by elros34
The link did it. Thanks a lot!
You should recompile qobi-wmhint-fix for armhf or eventually try to symlink: ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3
I guess I'll do a proper recompile some time in the future anyways.
Originally Posted by marmistrz
Yes, it is.
Is /sbin in PATH?
 |
|
2014-01-02
, 22:27
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#3043
|
Originally Posted by sulu
Armel version also doesn't have GIMP problems? I wonder, what causes them in our "old" image, then. Also, it would be interesting to see if gparted and chromium problems are manifesting themselves, but I understand, that you wanted to have working keyboard, first
I tried to set up a new Wheezy/armhf image from scratch and I have good and bad news.
the good:
Gimp works without crashing when using the text tool.
the bad:
For some reason I'm unable to get keyboard support in lxde (via debbie it works fine in roxterm and gimp).
Just for reference, I also created an armel image and I have the same problems there, so I'm pretty sure it's not architecture-specific, but I'm missing some "magic".
Keep up that good work - again, things that you're trying now are (currently) far above my knowledge level, so if anyone reincarnate fully working ED, it would be you.
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
|
|
2014-01-02
, 23:14
|
|
Posts: 915 |
Thanked: 3,209 times |
Joined on Jan 2011
@ Germany
|
#3044
|
Originally Posted by Estel
Sorry, my formulation was very ambiguous.
Armel version also doesn't have GIMP problems?
In my new armel image gimp crashes too. It's only armhf where it works fine.
Originally Posted by Estel
gparted crashes in armhf too and chromium isn't even present in the non-x86 Debian repos anymore (my last attempt to compile it anyway failed due to missing make targets with which I didn't bother any more).
Also, it would be interesting to see if gparted and chromium problems are manifesting themselves
Not sure if that's an option for you but I found midori to be pretty useful in ED. xxxterm might also be worth a try, but I have no idea if that browser has a bright future in Debian (the project was renamed to xombrero ages ago but in Debian is still an outdated xxxterm version).
Originally Posted by Estel
Thanks, I'll try.
Keep up that good work
Originally Posted by Estel
If "fully working" for you means you want gparted then I think I'll have to disappoint you. I don't even know where to begin debugging.
so if anyone reincarnate fully working ED, it would be you.
But I intend to release a basic Wheezy/armhf image in the near future (pretty similar to my old Wheezy/armel image - but hopefully with fewer stupid bugs) that others can use to create more "end-user-friendly" images.
It always bothered me that I didn't actually understand the inner workings of qole-based images (all we have so far) and since I'd have to start over from scratch for an armhf transition anyway I thought this might be a good opportunity to dig deeper.
Oh, btw:
A good portion of that dissatifaction was due to (in my eyes) missing or hard-to-find documentation on how to create images from scratch.
So once I have an image up I intend to change that situation by putting all the necessary info into the wiki. Please feel free to needle me until everything is clear! Should I disappear (again), others should be able to continue right where I have stopped.
Last edited by sulu; 2014-01-02 at 23:17.
|
|
2014-01-03
, 20:59
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#3045
|
Originally Posted by sulu
By "fully working" I mean "without things that doesn't work for reasons that we can't pinpoint", like that glib things gparted complains about (remember, it's not about gparted version - so it may be sign of more serious problems with library in question, that can manifest itself in other cases. Although, it haven't done so yet, which buggs me...). Things like chromium or GIMP - which are, (now) clearly bugs in their code/build process, are of lesser importance, as effects are surely limited to those programs.
If "fully working" for you means you want gparted then I think I'll have to disappoint you. I don't even know where to begin debugging.
But I intend to release a basic Wheezy/armhf image in the near future (pretty similar to my old Wheezy/armel image - but hopefully with fewer stupid bugs) that others can use to create more "end-user-friendly" images.
It always bothered me that I didn't actually understand the inner workings of qole-based images (all we have so far) and since I'd have to start over from scratch for an armhf transition anyway I thought this might be a good opportunity to dig deeper.
I think that your work to understand inner working of those images + documenting their creation from scratch is exactly thing that contributes to understanding possible problems, too. Kudos for your work, again
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
| The Following User Says Thank You to Estel For This Useful Post: | ||
 |
|
2014-01-03
, 21:33
|
|
Posts: 6,447 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#3046
|
Originally Posted by sulu
To be honest, I feel somewhat baffled by that. ARM is the future about as much as x86 is, if not more, and anyone silly enough to bury a popular package on that platform just because it does not build rather than getting their acts together and fixing it is IMO digging their own grave. That does not give me much confidence in the future of Debian as such.
gparted crashes in armhf too and chromium isn't even present in the non-x86 Debian repos anymore
| The Following User Says Thank You to pichlo For This Useful Post: | ||
|
|
2014-01-04
, 13:41
|
|
Posts: 915 |
Thanked: 3,209 times |
Joined on Jan 2011
@ Germany
|
#3047
|
Originally Posted by pichlo
Just to get that straight, gparted doesn't crash on armel/hf in general. It works fine on my Cubieboard2 (armhf) and it worked fine in my qemu-arm installation (armel).
To be honest, I feel somewhat baffled by that.
It only crashes in ED, no matter if armel or armhf.
For reference:
This is the error message which appears right after the GUI comes up, tries to scan available devices and crashes:
Code:
*** glib detected *** /usr/sbin/gpartedbin: free(): invalid pointer: 0x00285ae0 ***
As I said, I have no idea how to debug that, but then again I'm a very poor programmer (as in writing C(++) code). So if somebody else has any pointers (pun intended) I'd be happy to assist in tracking the problem down as good as I can.
Originally Posted by pichlo
Debian is around for more than 20 years now and it's the base for the vast majority of the distributions out there.
That does not give me much confidence in the future of Debian as such.
To my understanding, if Debian gets to the point where its future becomes questionable the whole FLOSS ecosystem is in big trouble.
|
|
2014-01-04
, 14:23
|
|
Posts: 915 |
Thanked: 3,209 times |
Joined on Jan 2011
@ Germany
|
#3048
|
[edit: Well, that was tricky! 
But I have the solution. More at the end of this post. ]
On a more serious note, I think I may be at the point of uploading an image, except for audio.
In general I try to avoid pulseaudio wherever I can. Here I can't and I don't know how to proceed.
steps in detail:
1. I recompiled pulseaudio with this patch [1] to account for Maemo's ancient PA version. (I did that for armel as well and the resulting packages work fine in my working armel image.)
2. I installed the following recompiled packages in my armhf image:
3. To have the same starting point as in my working armel image I also installed these packages from the Debian repo (although I believe they aren't necessary at that point):
4. I copied /etc/asound.conf from the armel image to the armhf image. It looks like this:
5. dus (and dbus-x11) were already installed in the armhf image and as far as I can tell they work fine. roxterm doesn't complain about missing dbus and ps shows this output:
6. According to [2] these mounts from the host system have to be present in the chroot:
#1 and #4 were already there because ED mounts them by default.
#2 was not mounted in my case but it was an identical copy of the host system's directory which works fine in my armel image. Mounting it from the host system didn't change anything.
#3 was a tmpfs mount in the image, which also works fine in the armel image. Mounting it from the host didn't get pA working.
7. Mentioned in [2], and stressed in [3] one has to make sure that the machine_id is the same in the chroot as on the host. Since /var/lib/dbus is a bind-mount this is the case:
The problem is, when I try to play an audio file from within the chroot via mplayer or moc I get this error:
The problem seems to be that the PA in the chroot can't connect to the one on the host (possibly due to some dbus-related issue?).
This is what I get when I manually start PA as user in the chroot:
This is as root:
The first one says something about module-udev-detect, the second about module-console-kit. consolekit, udev and libudev0 are installed in the chroot.
What puzzles me is this line, as, according to Google, it usually seems to indicate a machine_id mismatch, which I've already ruled out (see step 7):
edit/solution:
In a default Debian installation /var/run is a symlink to /run. But in ED /var/run needs to be a real directory because /run will be empty at the beginning, which means /var/run/dbus and /var/run/pulse will be missing.
On the other hand we can't simply make both of them real directories since we need Maemo's contents of these directories at the beginning.
So the solution is to reverse the order. Make /var/run a real directory and /run a symlink to /var/run.
[1] http://talk.maemo.org/showpost.php?p...6&postcount=34
[2] http://www.freedesktop.org/wiki/Soft...FAQ/#index36h3
[3] http://blog.einval.com/2010/11/12
Last edited by sulu; 2014-01-04 at 21:34.
But I have the solution. More at the end of this post. ]On a more serious note, I think I may be at the point of uploading an image, except for audio.
In general I try to avoid pulseaudio wherever I can. Here I can't and I don't know how to proceed.
steps in detail:
1. I recompiled pulseaudio with this patch [1] to account for Maemo's ancient PA version. (I did that for armel as well and the resulting packages work fine in my working armel image.)
2. I installed the following recompiled packages in my armhf image:
Code:
libpulse0 pulseaudio pulseaudio-utils
Code:
gstreamer0.10-pulseaudio xmms2-plugin-pulse
Code:
# PCM
# pcm.!default {
# type alsa_dsp
# playback_device_file ["/dev/dsptask/pcm3"]
# recording_device_file ["/dev/dsptask/pcm_rec1"]
# }
pcm.!default {
type pulse
}
# Mixer
ctl.!master {
type hw
card 0
}
ctl.!default {
type dsp_ctl
playback_devices ["/dev/dsptask/pcm3"]
recording_devices ["/dev/dsptask/pcm_rec1"]
}
# OSS emulation
pcm.dsp0 pcm.default
ctl.mixer0 mixer.default
Code:
$ ps ax | grep dbus 816 ? S<s 1:14 /usr/bin/dbus-daemon --system --nofork 1197 ? S 0:00 dbus-launch --exit-with-session 1202 ? S<s 0:08 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 1541 ? S<sl 0:01 /usr/bin/mafw-dbus-wrapper mafw-gst-renderer 1543 ? Ss 0:00 /usr/bin/mafw-dbus-wrapper mafw-iradio-source 1548 ? Ss 0:00 /usr/bin/mafw-dbus-wrapper mafw-upnp-source 1554 ? Ss 0:00 /usr/bin/mafw-dbus-wrapper mafw-tracker-source 21702 ? S 0:00 dbus-launch --sh-syntax --exit-with-session 21703 ? Ss 0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 21770 pts/1 S 0:00 dbus-launch --autolaunch b97b807cce17de74591ffb9000130353 --binary-syntax --close-stderr 21771 ? Ss 0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
Code:
/var/lib/dbus ~/.pulse /tmp /dev/shm
#2 was not mounted in my case but it was an identical copy of the host system's directory which works fine in my armel image. Mounting it from the host system didn't change anything.
#3 was a tmpfs mount in the image, which also works fine in the armel image. Mounting it from the host didn't get pA working.
7. Mentioned in [2], and stressed in [3] one has to make sure that the machine_id is the same in the chroot as on the host. Since /var/lib/dbus is a bind-mount this is the case:
Code:
# cat /var/lib/dbus/machine-id b97b807cce17de74591ffb9000130353 # cat /.debian/var/lib/dbus/machine-id b97b807cce17de74591ffb9000130353
Code:
$ mocp 10_-_Magic_Zone.ogg Running the server... Trying JACK... Trying ALSA... ALSA lib dlmisc.c:254:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/arm-linux-gnueabihf/alsa-lib/libasound_module_ctl_dsp_ctl.so ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused Trying OSS... FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited! $ $ $ $ mplayer 10_-_Magic_Zone.ogg MPlayer svn r34540 (Debian), built with gcc-4.6 (C) 2000-2012 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing 10_-_Magic_Zone.ogg. libavformat version 53.21.1 (external) Mismatching header version 53.19.0 libavformat file format detected. [lavf] stream 0: audio (vorbis), -aid 0, Magic Zone Load subtitles in ./ ========================================================================== Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders libavcodec version 53.35.0 (external) Mismatching header version 53.32.2 AUDIO: 44100 Hz, 2 ch, s16le, 256.0 kbit/18.14% (ratio: 32000->176400) Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis) ========================================================================== AO: [pulse] Init failed: Connection refused Failed to initialize audio driver 'pulse' [AO_ALSA] alsa-lib: pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused [AO_ALSA] Playback open error: Connection refused Failed to initialize audio driver 'alsa' [AO SDL] Samplerate: 44100Hz Channels: Stereo Format s16le [AO SDL] using aalib audio driver. [AO SDL] Unable to open audio: No available audio device Failed to initialize audio driver 'sdl:aalib' Could not open/initialize audio device -> no sound. Audio: no sound Video: no video Exiting... (End of file)
This is what I get when I manually start PA as user in the chroot:
Code:
$ pulseaudio E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused libudev: udev_monitor_enable_receiving: bind failed: Operation not permitted E: [pulseaudio] module-udev-detect.c: Failed to enable monitor: Operation not permitted E: [pulseaudio] module.c: Failed to load module "module-udev-detect" (argument: ""): initialization failed. E: [pulseaudio] main.c: Module load failed. E: [pulseaudio] main.c: Failed to initialize daemon.
Code:
# pulseaudio W: [pulseaudio] main.c: This program is not intended to be run as root (unless --system is specified). E: [pulseaudio] module-console-kit.c: Unable to contact D-Bus system bus: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused E: [pulseaudio] module.c: Failed to load module "module-console-kit" (argument: ""): initialization failed. E: [pulseaudio] main.c: Module load failed. E: [pulseaudio] main.c: Failed to initialize daemon.
What puzzles me is this line, as, according to Google, it usually seems to indicate a machine_id mismatch, which I've already ruled out (see step 7):
Code:
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
edit/solution:
In a default Debian installation /var/run is a symlink to /run. But in ED /var/run needs to be a real directory because /run will be empty at the beginning, which means /var/run/dbus and /var/run/pulse will be missing.
On the other hand we can't simply make both of them real directories since we need Maemo's contents of these directories at the beginning.
So the solution is to reverse the order. Make /var/run a real directory and /run a symlink to /var/run.
[1] http://talk.maemo.org/showpost.php?p...6&postcount=34
[2] http://www.freedesktop.org/wiki/Soft...FAQ/#index36h3
[3] http://blog.einval.com/2010/11/12
Last edited by sulu; 2014-01-04 at 21:34.
|
|
2014-01-05
, 01:50
|
|
Posts: 804 |
Thanked: 1,598 times |
Joined on Feb 2010
@ Gdynia, Poland
|
#3049
|
Originally Posted by sulu
Great work! Some ideas:
Just to get that straight, gparted doesn't crash on armel/hf in general. It works fine on my Cubieboard2 (armhf) and it worked fine in my qemu-arm installation (armel).
It only crashes in ED, no matter if armel or armhf.
For reference:
This is the error message which appears right after the GUI comes up, tries to scan available devices and crashes:strace doesn't reveal any further useful info (at least to my understanding) and google doesn't return any results.Code:*** glib detected *** /usr/sbin/gpartedbin: free(): invalid pointer: 0x00285ae0 ***
As I said, I have no idea how to debug that, but then again I'm a very poor programmer (as in writing C(++) code). So if somebody else has any pointers (pun intended) I'd be happy to assist in tracking the problem down as good as I can.
1. I suppose both Cubieboard2 and your pc with qemu-arm installation have newer kernels than 2.6.28? The reason I'm asking is I've seen in my past glibc crashes when specific combination of glibc version and kernel version, and quick googling returned some other case where a person with kernel 2.6.28 had "...gpartedbin: free(): invalid pointer..." error [1]. Are you able to install second kernel on your pc, preferably 2.6.28? Googling told me Cubieboard2 supports 3.something (3.4?) kernels only, so I guess downgrading that one is not possible.
2. Again very remote guess, but could you try running gparted from console with "LD_PRELOAD=/path/to/libstdc++.so" ? This is based again on some googling results, mostly one explanation of possible cause of "...free(): invalid pointer..." issues when some of the libraries are compiled with incorrect flags [2] and related ubuntu bug [3]. Maybe comparing "ldd /usr/sbin/gpartedbin" from Cubieboard2, from qemu-armel environment on pc and from n900 in both armel and armhf image would also show something suspicious or give any clues (it would be nice if you could also post them here for reference).
edit: 3. Posting strace would be nice, too (maybe it will provide some suspiciously looking data for some other community member, without the need to run the ED and gparted).
[1] http://ubuntuforums.org/archive/inde...t-1211516.html
[2] https://www.libavg.de/site/projects/...nvalid-pointer
[3] https://bugs.launchpad.net/ubuntu/+s...sa/+bug/259219
|
|
2014-01-05
, 10:13
|
|
Posts: 915 |
Thanked: 3,209 times |
Joined on Jan 2011
@ Germany
|
#3050
|
Originally Posted by misiak
Correct.
1. I suppose both Cubieboard2 and your pc with qemu-arm installation have newer kernels than 2.6.28?
My CB2 runs a custom 3.4.67+ made by the Cubian folks, my PC runs the 3.2.51 Debian kernel.
Originally Posted by misiak
I can try to do so in a VM. I remember having done something like that in the past with some troubles due to the age of the kernel, but I can't remember what exactly was the problem.
Are you able to install second kernel on your pc, preferably 2.6.28?
On the other hand my experience (with x86, arm and ppc) is, that when you get that close to the hardware level you can't simply abstract from one architecture to another. So I'm sceptic if x86-experiments are useful for arm.
Originally Posted by misiak
Quite frankly, installing custom kernels on the CB2 is above my skills since it involves a lot of special tricks.
Googling told me Cubieboard2 supports 3.something (3.4?) kernels only, so I guess downgrading that one is not possible.
Kernels always have "just worked" for me. I've tried some occasional recompiles just for fun but I'm far away from actually being able to do any troubleshooting.
Originally Posted by misiak
Here it is (wheezy/armhf image on the N900):
2. Again very remote guess, but could you try running gparted from console with "LD_PRELOAD=/path/to/libstdc++.so" ?
Code:
# ls -l /usr/lib/arm-linux-gnueabihf/libstdc++.so.6* lrwxrwxrwx 1 root root 19 Jan 8 2013 /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 -> libstdc++.so.6.0.17 -rw-r--r-- 1 root root 641216 Jan 8 2013 /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.17 # export LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libstdc++.so.6 # echo $LD_PRELOAD /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 # export LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libstdc++.so.6 # gparted ====================== libparted : 2.3 ====================== *** glibc detected *** /usr/sbin/gpartedbin: free(): invalid pointer: 0x00287210 *** Aborted
edit:
At first I had outputs that contained Locale warnings and therefore might be misleading (pointer address changes etc.). I've reuploaded outputs without these problems.
/edit
Originally Posted by misiak
You'll find outputs for the armel image, armhf image, CB2 and my PC (amd64) in the attached tar.gz archive.
Maybe comparing "ldd /usr/sbin/gpartedbin" from Cubieboard2, from qemu-armel environment on pc and from n900 in both armel and armhf image would also show something suspicious or give any clues (it would be nice if you could also post them here for reference).
My qemu machine doesn't exist anymore since I have the CB2.
Thanks for all the tips!
Last edited by sulu; 2014-01-05 at 10:31.
 |
| Tags |
| beta, debian, easy debian, extras-devel, fremantle, i <3 qole, squeeze |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 18:36.
If you want to support my work, you can donate by PayPal or Flattr
Projects no longer actively developed: here