| 00:33.04 | *** join/#maemo-ssu andre__ (~andre@216.38.130.161) |
| 00:33.04 | *** join/#maemo-ssu andre__ (~andre@wikimedia/aklapper) |
| 00:41.43 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 01:05.35 | *** join/#maemo-ssu jon_y (~enforcer@2002:7c0d:3e7c::7c0d:3e7c) |
| 02:44.21 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 05:05.32 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 05:49.02 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-119.residential.rdsnet.ro) |
| 06:33.24 | *** join/#maemo-ssu sixwheeledbeast (~paul@cl-1547.lon-02.gb.sixxs.net) |
| 07:01.42 | *** join/#maemo-ssu lartza_ (~lartza@IP-62-216-127-116.telemail.fi) |
| 07:24.42 | *** join/#maemo-ssu lartza_ (~lartza@IP-62-216-127-116.telemail.fi) |
| 07:33.57 | *** join/#maemo-ssu _rd (~rd@p57B4BA90.dip0.t-ipconnect.de) |
| 07:44.37 | *** join/#maemo-ssu lartza_ (~lartza@IP-62-216-127-116.telemail.fi) |
| 07:55.16 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 08:00.19 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 08:24.54 | *** join/#maemo-ssu kolp (~quassel@212.255.252.3) |
| 08:27.01 | *** join/#maemo-ssu fw190 (~fw190@c75-67.icpnet.pl) |
| 08:29.13 | chem|st | morning... |
| 08:29.21 | chem|st | so lads and ladies... |
| 08:29.23 | fw190 | morning |
| 08:31.25 | chem|st | I was thinking about... fuck freedom of choice... I will announce that properly, so noone can moan! if people want freedom of choice they need to code it themself, cssuS will get a minor upgrade with the pressing things and after that I will pull anything ~stable from testing |
| 08:32.23 | freemangordon | chem|st: hmm since when there is a freedom of choice in CSSU? :) |
| 08:32.43 | *** join/#maemo-ssu futpib (~futpib@89.106.197.60) |
| 08:32.48 | chem|st | freemangordon: I do not pull some stuff from testing to give a choice, like the camera |
| 08:33.57 | chem|st | merlin1991 is ok with it as I will get the shitstorm and me has to live with it! |
| 08:34.17 | freemangordon | aah, I see. well, fuck the freedom of choice then |
| 08:34.19 | freemangordon | :D |
| 08:35.11 | chem|st | well I did not like it in the first place but with nokia upgrades you don't have that freedom so why should I provide it |
| 08:35.12 | fw190 | chem|st: It wont be that bad - eventually everyone will go for thumb and all the shtstorm will go on freemangordon :P |
| 08:35.23 | freemangordon | chem|st: that way I can start pushing for merging -thumb with -T |
| 08:35.32 | chem|st | freemangordon: oh nope! |
| 08:35.35 | freemangordon | chem|st: exactly my point |
| 08:35.42 | freemangordon | (nokia) |
| 08:36.49 | freemangordon | chem|st: hmm? I'll try to have KSSU in the next -T, I see no reason why not have thumbified packages slowly moving to -T after that |
| 08:37.17 | chem|st | yeah slowly is the word I missed in the above |
| 08:37.46 | freemangordon | chem|st: -thumb is out in the wild for more than an year, benefits are clear, it is rock stable, etc |
| 08:37.59 | freemangordon | chem|st: comeon, have some trust in me :P |
| 08:38.19 | chem|st | freemangordon: sry bu rock stable is without hardcore testers... |
| 08:38.43 | chem|st | I know it is stable |
| 08:38.48 | freemangordon | chem|st: no better test than wild |
| 08:38.59 | freemangordon | and it is in the wild |
| 08:39.07 | freemangordon | however |
| 08:39.14 | freemangordon | that is for the future |
| 08:39.18 | *** join/#maemo-ssu _rd (~rd@p57B4BA90.dip0.t-ipconnect.de) |
| 08:39.48 | chem|st | are you using your thumb device as daily phone? |
| 08:39.52 | freemangordon | ofc |
| 08:40.04 | chem|st | ok |
| 08:40.30 | freemangordon | I never issue an update to -thumb before havein the new packages installed on my daily device for a week or so |
| 08:40.31 | freemangordon | *having |
| 08:40.35 | chem|st | my playtoy has testing and looses its battery without using it in a day |
| 08:40.49 | chem|st | idle with no simcard no wifi connected |
| 08:40.56 | freemangordon | that's bad |
| 08:41.04 | freemangordon | bad battery? |
| 08:41.23 | chem|st | nope my sister has the very same, just not so frequent |
| 08:41.32 | chem|st | something hangs I guess |
| 08:42.28 | chem|st | I cannot find anything odd so I guess something is keeping some hardware powered without the system being aware of... |
| 08:43.31 | chem|st | sometimes it seems like the charging logic keeps itself powered after disconnecting |
| 08:43.48 | chem|st | or somelike |
| 08:44.10 | freemangordon | chem|st: that's weird, my devel device lasts a 4-5 days in the drawer, with wifi on |
| 08:44.20 | chem|st | well I have to admit it is my playtoy and as soon as I roll over a bcakup it might be gone^^ |
| 08:45.40 | chem|st | but I didn't alter anything but turning off things... I could dismantle it and check if the screen stays powered |
| 08:46.02 | freemangordon | chem|st: do you have rd mode on? |
| 08:46.24 | chem|st | nope |
| 08:46.35 | freemangordon | hmm. checked with powertop? |
| 08:46.40 | chem|st | sure |
| 08:46.53 | chem|st | as I said it is nothing obvious |
| 08:47.12 | freemangordon | did you try with different battery? |
| 08:47.23 | chem|st | it might be some device that I turned off by hand... if the kernel does not control it anymore it might get fully powered |
| 08:47.29 | freemangordon | it might worth thr try |
| 08:47.32 | chem|st | had that with my wifi on my laptop |
| 08:52.07 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-119.residential.rdsnet.ro) |
| 08:55.59 | merlin1991 | heh I didn't say I'm ok with it, I said it isn't my call anymore :D |
| 08:56.40 | freemangordon | oh you... |
| 08:58.44 | *** join/#maemo-ssu _rd (~rd@p57B4BA90.dip0.t-ipconnect.de) |
| 09:03.29 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 09:05.10 | *** join/#maemo-ssu sixwheeledbeast (~paul@host-2-98-139-178.as13285.net) |
| 09:10.54 | *** join/#maemo-ssu NIN101 (~NIN@p57B9EDBA.dip0.t-ipconnect.de) |
| 09:10.57 | sixwheeledbeast | So should CSSU-S go thumb only in the future? I don't see why not myself. |
| 09:12.54 | kerio | well, it makes it really awkward for the user |
| 09:13.02 | kerio | because at that point you have to be careful about the kernel |
| 09:17.37 | *** join/#maemo-ssu _rd (~rd@p57B4BA90.dip0.t-ipconnect.de) |
| 09:23.06 | sixwheeledbeast | kerio: but KCSSU will be a dependency? |
| 09:29.41 | sixwheeledbeast | If there was an option of CSSU-S and CSSU-S+thumb. You would go with the benefits of thumb. |
| 09:29.55 | sixwheeledbeast | surely? |
| 09:30.28 | sixwheeledbeast | So it seems silly to work on both IMO |
| 09:39.22 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
| 10:34.16 | *** join/#maemo-ssu jon_y (~enforcer@2002:7c0d:3e7c::7c0d:3e7c) |
| 10:35.20 | *** join/#maemo-ssu sixwheeledbeast (~paul@host-78-150-226-198.as13285.net) |
| 11:03.03 | *** join/#maemo-ssu sixwheeledbeast (~paul@cl-1547.lon-02.gb.sixxs.net) |
| 11:12.10 | Drathir | chem|st: on power saving turn less bright of lcd, and auto device lock |
| 11:14.56 | Drathir | mine with using and wifi works few hours, but not used can be on 1day |
| 11:26.25 | *** join/#maemo-ssu sixwheeledbeast (~paul@cl-1547.lon-02.gb.sixxs.net) |
| 11:47.22 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 11:58.25 | *** join/#maemo-ssu lartza_ (~lartza@IP-62-216-127-116.telemail.fi) |
| 12:06.00 | *** join/#maemo-ssu NIN102 (~NIN@p5DD2A1D4.dip0.t-ipconnect.de) |
| 12:19.14 | *** join/#maemo-ssu _rd (~rd@p57B4BA90.dip0.t-ipconnect.de) |
| 12:21.18 | chem|st | Drathir: device is idle, screen off, flightmode... and still |
| 12:31.52 | Drathir | hmmm thats interesting... if on clean device is the same maybe is a hw issue? |
| 12:33.23 | Drathir | you also can check cpu usage usage with widget... |
| 12:37.10 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 12:38.58 | *** join/#maemo-ssu futpib (~futpib@89.106.197.79) |
| 13:09.40 | *** join/#maemo-ssu _rd (~rd@p57B4A8C5.dip0.t-ipconnect.de) |
| 13:17.30 | DocScrutinizer05 | sixwheeledbeast: IF thumb is such low effort and as compatible, then it's just about compiling everything with -thumb flag in builder set |
| 13:17.56 | DocScrutinizer05 | and then it's not silly to work on both but actually sensible to offer that alternative |
| 13:18.29 | DocScrutinizer05 | but requiring all cssu-s users to replace their kernel is sth we already discussed and found will give us problems |
| 13:20.08 | sixwheeledbeast | problems how? |
| 13:23.29 | kerio | for instance, you need to force people to replace their kernel |
| 13:24.06 | sixwheeledbeast | And that's an issue because? |
| 13:25.04 | DocScrutinizer05 | because they might not even be able to do so |
| 13:25.19 | DocScrutinizer05 | where's the uBoot with thumb kernel? |
| 13:25.44 | DocScrutinizer05 | where are the kernel.bz images that are thumb enabled? |
| 13:26.10 | DocScrutinizer05 | basically changing the thumb thingie starts a complete new distro, |
| 13:26.27 | DocScrutinizer05 | while CSSU is still an *update* to stock distro |
| 13:27.06 | DocScrutinizer05 | going thumb creates a system that's fundamentally incompatible to stock maemo |
| 13:27.43 | sixwheeledbeast | ah |
| 13:27.54 | DocScrutinizer05 | installing uBoot on your thumb system will fubar it |
| 13:28.14 | DocScrutinizer05 | installing multiboot on your thumb system will probably fubar it |
| 13:28.32 | DocScrutinizer05 | you dunno what else depends on stock kernel, or is based on stock kernel |
| 13:28.39 | sixwheeledbeast | I don't use multiboot :) |
| 13:29.22 | DocScrutinizer05 | that's irrelevant |
| 13:29.47 | DocScrutinizer05 | brainfuck-kernel is also incompatible to thumb I guess |
| 13:32.05 | DocScrutinizer05 | honestly unless you roll out a thumb (and nothing else but thumb) kernel via Nokia stock repo, as PR1.4, so *all* devices do the update, I don't see how CSSU which is meant to be the bugfix addon and continuation of what's in stock repo can ever go thumb per default |
| 13:32.10 | sixwheeledbeast | but hang on KP has boot variants why not KCSSU |
| 13:32.35 | DocScrutinizer05 | hmmm? |
| 13:33.29 | DocScrutinizer05 | what's the use of KCSSU boot variants when you installed brainfuck-scheduler-kernel which doesn't know shit about thimb? |
| 13:34.01 | kerio | DocScrutinizer05: fwiw, we can just upgrade everything together |
| 13:34.06 | kerio | and remove the braindead scheduler |
| 13:34.29 | DocScrutinizer05 | yes, that's what you call a new distro |
| 13:34.47 | kerio | naaaaah |
| 13:34.51 | kerio | the only problem is that we don't yet control the nokia repos |
| 13:38.02 | DocScrutinizer05 | yes, when we control Nokia repos, we can actually roll a PR1.4, and show uBoot and multiboot and brainfuck the finger, since then it's them to either stay on PR1.3 or patch their software to upgrade to PR1.4 |
| 13:38.26 | jon_y | whats wrong with uboot? |
| 13:38.40 | jon_y | how are you supposed to boot off SD? |
| 13:39.54 | DocScrutinizer05 | then every user out there is free to accept the system upgrade and know he can install whatever he likes form whatever repo and it will work, or he rejects the PR1.4 system upgrade and nails his system to PR1.3 and then the "old" kernel dependent stuff from PR1.3 repos will still work for him |
| 13:40.16 | DocScrutinizer05 | eh? |
| 13:40.58 | DocScrutinizer05 | what's wrong with uBoot? it's simply a bloated mess that tries to be a OS of its own. I dunno what else is wrong with it |
| 13:41.14 | *** join/#maemo-ssu _rd (~rd@p57B4A8C5.dip0.t-ipconnect.de) |
| 13:44.59 | DocScrutinizer05 | kerio: it's as plain simple as that: such a non-backward-compatible change in core sysem components creates a new OS major revision, like frooblux23.4 -> frooblux24.0 |
| 13:45.14 | kerio | pr 1.4 then! :D |
| 13:45.24 | DocScrutinizer05 | that's exactly what happens also on Maemo PR1.2 -> PR1.3 |
| 13:45.39 | DocScrutinizer05 | and yes, we need a PR1.4 then to enable thumb |
| 13:48.08 | DocScrutinizer05 | you are aware that _this_ Pr1.4 would obsolete CSSU-S? |
| 13:48.26 | DocScrutinizer05 | since it IS CSSU-S |
| 13:49.39 | kerio | cssu-1.4 |
| 13:49.43 | DocScrutinizer05 | >>It aims to deliver fixes which would be difficult to deliver through Extras (like core Maemo packages).<< It's not difficult at all to deliver those packages thru "Nokia" repos |
| 13:50.17 | DocScrutinizer05 | once we gain full control over those repos |
| 13:50.48 | DocScrutinizer05 | but I still don't see that happen |
| 13:52.03 | jon_y | DocScrutinizer05: I don't see other alternatives to uboot |
| 13:52.05 | DocScrutinizer05 | unless we nuke the original Nokia repos from user's apt list and replace them with cssu-core repos, on installation of CSSU-1.4 |
| 13:52.20 | DocScrutinizer05 | jon_y: me neither |
| 13:52.38 | DocScrutinizer05 | I neither see anything wrong with uBoot |
| 13:53.03 | jon_y | "it's simply a bloated mess that tries to be a OS of its own" << ? |
| 13:53.23 | jon_y | isn't it supposed to work that way? a bootloader? |
| 13:53.25 | DocScrutinizer05 | you asked "what's wrong with uBoot?" so I answered |
| 13:53.56 | jon_y | "and show uBoot and multiboot and brainfuck the finger" << I assumed you wanted to nuke uboot? |
| 13:54.14 | DocScrutinizer05 | WUT? nooo you got that wrong |
| 13:55.20 | DocScrutinizer05 | it's just that with an "official" PR1.4 it's the maintainers of those packages that have a problem to update their software to new kernel, not we (the cssu maintainers) |
| 13:55.33 | jon_y | ok |
| 13:58.11 | DocScrutinizer05 | it's just that PR1.3 depends on kernel "2.6.28-omap1 #1" and the uBoot and other packages depend on PR1.3 for the kernel compatibility |
| 13:58.15 | kerio | i'm not entirely sure why uboot ships with an embedded kernel, actually |
| 13:58.31 | DocScrutinizer05 | because it replaces original kernel |
| 13:58.52 | kerio | so? install a bootimg |
| 13:59.08 | DocScrutinizer05 | so it needs *some* kernel to ship with it, to boot the system after installing uBoot |
| 14:00.01 | DocScrutinizer05 | kerio: are you already awake? |
| 14:00.07 | kerio | i am |
| 14:00.14 | DocScrutinizer05 | kerio: where's that bootimg in FIASCO? |
| 14:00.26 | kerio | why fiasco? |
| 14:00.37 | kerio | it's not preinstalled, no |
| 14:00.41 | kerio | but neither is uboot |
| 14:00.42 | DocScrutinizer05 | no, you're not ;-P |
| 14:01.06 | kerio | you definetely need some kernel |
| 14:01.12 | kerio | i'm challenging "you need an attached kernel" |
| 14:01.46 | DocScrutinizer05 | you're changing default system architecture |
| 14:02.03 | DocScrutinizer05 | that's almost worse than the switch to thumb |
| 14:02.08 | DocScrutinizer05 | ;-P |
| 14:02.20 | kerio | you're just changing bootloaders |
| 14:02.27 | kerio | the new bootloader needs the kernel in a different place |
| 14:02.34 | kerio | it's like moving from lilo to grub |
| 14:02.45 | DocScrutinizer05 | well, yes |
| 14:02.55 | DocScrutinizer05 | and that neither is sth done lightly |
| 14:03.50 | *** join/#maemo-ssu sixwheeledbeast (~paul@host-78-145-85-166.as13285.net) |
| 14:04.02 | DocScrutinizer05 | again, where is your kernelimg in flasher-3.5 -rootfs-only -Ff anyrandomCOMBINED.bin ? |
| 14:04.24 | *** join/#maemo-ssu _rd (~rd@p57b4a8c5.dip0.t-ipconnect.de) |
| 14:04.34 | kerio | you never have to flash the kernel again, actually |
| 14:04.46 | kerio | you just put it on a uSD and boot from the console, in case of emergency |
| 14:05.01 | DocScrutinizer05 | sure you have to, with *every* flashing you do |
| 14:05.14 | DocScrutinizer05 | since... see above, just 2 lines above |
| 14:06.00 | DocScrutinizer05 | and you'd be surprised how many devices with broken uSD slot are out there |
| 14:06.54 | DocScrutinizer05 | and actually now you're not only not awake, you're actually having a bad dream. Make my device boot-fail when I swap uSD, are you NUTS?? |
| 14:07.18 | kerio | no, that's just in case of emergency |
| 14:07.20 | kerio | the kernel is on emmc |
| 14:07.51 | DocScrutinizer05 | think about that again please! |
| 14:08.24 | _rd | I am getting close to get a syslog from my n900 in the bootloop since the last CSSU.... |
| 14:08.39 | DocScrutinizer05 | what we actually could (and I already did) consider: placing kernel to initrd NAND partition |
| 14:08.46 | DocScrutinizer05 | mtd4 iirc |
| 14:12.10 | DocScrutinizer05 | afaik definitely nothing is using initrd mtd4 on N900 |
| 14:12.59 | DocScrutinizer05 | and it#s not swappable ;-P |
| 14:13.06 | DocScrutinizer05 | unlike uSD |
| 14:13.35 | DocScrutinizer05 | and shouldn't usually get nuked on flashing a new rootfs |
| 14:18.46 | kerio | i just don't get why you dislike my setup |
| 14:18.57 | kerio | the kernel isn't flashed, it's just written to the eMMC |
| 14:19.03 | kerio | i mean, it's a file in MyDocs |
| 14:22.20 | _rd | Hmm, it seems my X server is not coming up since my last CSSU update: http://bokomoko.de/~rd/syslog |
| 14:22.42 | _rd | As a side note: it is possible to install syslog with rescueOS....but painful. |
| 14:23.01 | _rd | Do you have any idea why that happens? |
| 14:24.35 | kerio | Jan 1 07:38:32 Nokia-N900 init: xomap post-start process (922) terminated with status 127 |
| 14:24.52 | kerio | Jan 1 07:38:32 Nokia-N900 DSME: Process '/usr/bin/Xorg -logfile /tmp/Xorg.0.log -logverbose 1 -nolisten tcp -noreset -s 0 -core' with pid 919 exited with r |
| 14:28.05 | _rd | just wondering if I could get the Xorg.0.log |
| 14:33.35 | _rd | did anything change related to X in CSSU? |
| 14:40.33 | *** join/#maemo-ssu futpib (~futpib@89.106.197.127) |
| 16:28.02 | DocScrutinizer05 | kernel in Mydocs?? |
| 16:29.03 | DocScrutinizer05 | that sounds incredibly great, particularly to umount MyDocs for exporting it via ass rage mode, and eventually completely cleaning the volume |
| 16:31.46 | *** join/#maemo-ssu iDont (~iDont@ip4da305b4.direct-adsl.nl) |
| 16:34.56 | DocScrutinizer05 | _rd: shouldn't |
| 16:35.15 | DocScrutinizer05 | _rd: replace your transitions.ini by the backup |
| 16:35.23 | DocScrutinizer05 | remove your SIM |
| 16:37.37 | DocScrutinizer05 | and maybe even mv /home/user /home/user-AWAY; mkdir /home/user |
| 16:38.08 | DocScrutinizer05 | also df -h / |
| 16:38.45 | DocScrutinizer05 | filled rootfs is the most usual reason for effects like yours |
| 16:39.10 | *** join/#maemo-ssu sixwheeledbeast (~paul@host-78-150-235-86.as13285.net) |
| 16:56.36 | _rd | DocScrutinizer05, rootfs looks good: |
| 16:56.40 | _rd | rootfs 233344 179628 49624 78% / |
| 16:57.33 | _rd | none of the fs is more filled than 90% |
| 17:01.22 | _rd | transitions.ini is in /usr/share/hildon-desktop, right? |
| 17:02.43 | sixwheeledbeast | ~transitions.ini |
| 17:02.43 | infobot | transitions.ini is, like, http://wiki.maemo.org/Community_SSU/Features/hildon-desktop |
| 17:03.03 | sixwheeledbeast | yep |
| 17:07.01 | _rd | I noticed that I have a transitions.ini.dpkg-dist from May 24th, 2013, transistions.ini is from 2011 |
| 17:07.55 | _rd | I wanted to rename /tmp/Xorg.0.log to /Xorg.0.log or /home/user/Xorg.0.log, that it does not get deleted at reboot, but that for some reason did not work. Does anybody know why? |
| 17:08.29 | DocScrutinizer05 | rename? how? |
| 17:09.06 | _rd | in /etc/event.d/xomap .... I wanted to see what is in the log file |
| 17:09.44 | _rd | checking new transitions.ini now |
| 17:09.51 | DocScrutinizer05 | if that's the line that uses dsmetool to start Xorg then it's the right location |
| 17:10.21 | DocScrutinizer05 | when your transition.ini is old, then it probably didn't change and thus not the culprit |
| 17:10.55 | _rd | yes it is the dsmetool line, but that for some reason did not work. |
| 17:11.14 | DocScrutinizer05 | how "doesn't work"? |
| 17:11.40 | _rd | I did not see the reboot cycles anymore, but it also did not come up. |
| 17:11.52 | _rd | and I never found an /Xorg.0.log |
| 17:12.06 | DocScrutinizer05 | editing that line to point to /home/user/Xorg.0.log should work |
| 17:12.37 | DocScrutinizer05 | probably Xorg runs as user, and user mustn't write to / |
| 17:12.41 | _rd | I tried that as well, but I had also no luck with that. |
| 17:12.50 | DocScrutinizer05 | and MyDocs might fail for other reasons |
| 17:13.52 | _rd | you recommend to boot without SIM, right? |
| 17:13.58 | DocScrutinizer05 | or you create a dir /mylogs; chmod a+rw /mylohgs; then point the line to there |
| 17:14.04 | DocScrutinizer05 | right |
| 17:14.10 | _rd | that is a good idea |
| 17:14.32 | _rd | does an unavailable SIM delay the boot cycle? |
| 17:14.41 | DocScrutinizer05 | it's been seen occasionally that a rogue or crippled SMS on SIM made the whole system go bonkers |
| 17:14.57 | DocScrutinizer05 | shouldn't delay |
| 17:15.22 | _rd | I do not see the reboots anymore, but also no boot progress. |
| 17:15.55 | _rd | let me boot in rescueOS again and create the /mylogs |
| 17:20.19 | *** join/#maemo-ssu rd_ (~rd@p57B48C55.dip0.t-ipconnect.de) |
| 17:28.00 | rd_ | Xorg.0.log is hidding.... |
| 17:28.36 | rd_ | ....with /mylogs I have the same behaviour as with /tmp but no Xorg.0.log is in there. |
| 17:29.54 | rd_ | can anybody check if on a regularly running device /tmp/Xorg.0.log exists? |
| 17:38.23 | DocScrutinizer05 | IroN900:/home/user# ll /tmp/Xorg* |
| 17:38.24 | DocScrutinizer05 | -rw-r--r-- 1 root root 4521 2013-06-13 15:09 /tmp/Xorg.0.log |
| 17:39.25 | DocScrutinizer05 | just for fun try Xorg logging to /dev/null |
| 17:39.32 | rd_ | The only scenario which makes sense for me is that the xomap crashes before it can start writting a log |
| 17:39.43 | rd_ | ok, I can do |
| 17:40.40 | DocScrutinizer05 | so you can tell apart if it doesn't log because it crashes, or it crashed because it can't log |
| 17:43.14 | rd_ | just for curiosity: does "exec cat /mylogs/Xorg.0.log >> /mylogs/Xorg.log" in the pre-start script section hurt? |
| 17:43.35 | rd_ | if I add this line, I do not get reboot loops anymore |
| 17:43.45 | rd_ | ....but the boot process seems also to hang. |
| 17:43.47 | DocScrutinizer05 | haha |
| 17:44.29 | DocScrutinizer05 | exec for sure is ... questionable here |
| 17:44.51 | DocScrutinizer05 | you're aware exec aborts the script, like exit |
| 17:44.58 | rd_ | ok, I tried before without...but no change |
| 17:45.23 | rd_ | trying with /dev/null now |
| 17:45.34 | rd_ | thanks for the explantion of exec |
| 17:45.42 | DocScrutinizer05 | afk bbl |
| 17:46.21 | rd_ | I also get reboot loops when using /dev/null |
| 17:46.40 | DocScrutinizer05 | exec *replaces* the current process with the new one |
| 17:47.17 | DocScrutinizer05 | (actually not the process, but that doesn't matter here) |
| 17:47.32 | DocScrutinizer05 | afk bbl |
| 17:47.43 | rd_ | and I assume it does not return there when it ends |
| 17:48.08 | rd_ | strange...now the n900 only rebooted once, now it seems to hang again. |
| 17:49.06 | rd_ | trying again |
| 18:05.30 | *** join/#maemo-ssu rd_ (~rd@p57B48C55.dip0.t-ipconnect.de) |
| 18:09.19 | rd_ | I start to run out of ideas. Maybe I should just save the remaining data away and re-flash.... and hope that the problem goes away after re-flashing, but it came with the reboot of the CSSU update, so it is at least likely. |
| 18:21.13 | *** join/#maemo-ssu arcean (~arcean@aacv164.neoplus.adsl.tpnet.pl) |
| 18:36.11 | DocScrutinizer05 | you most probably are missing files in ~user/.* now |
| 18:36.44 | DocScrutinizer05 | you could try |
| 18:37.14 | DocScrutinizer05 | echo "before Xorg" >>/mylogs/mylogs.txt |
| 18:37.29 | DocScrutinizer05 | before dmsetool Xorg |
| 18:37.31 | DocScrutinizer05 | and |
| 18:37.44 | DocScrutinizer05 | echo "after Xorg" >>/mylogs/mylogs.txt |
| 18:37.54 | DocScrutinizer05 | below it |
| 18:38.50 | DocScrutinizer05 | what you consider "hanging" might actually be fsck trying to do its thing |
| 18:39.06 | DocScrutinizer05 | which can take quiiiite a while |
| 18:42.34 | kerio | and it'll probably fail at it |
| 18:42.59 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
| 18:53.25 | rd_ | if it would be fsck, I would expect entries in /var/log/fsck_home.log |
| 18:53.29 | rd_ | but they end all with clean |
| 18:53.44 | DocScrutinizer05 | hmm |
| 18:53.46 | rd_ | what is the point of after? |
| 18:53.55 | rd_ | "after Xorg..." |
| 18:54.07 | rd_ | you said that exec will replace the current process (?) |
| 18:54.08 | DocScrutinizer05 | well, just in case |
| 18:54.14 | rd_ | ok |
| 18:54.35 | DocScrutinizer05 | after all dsmetool shouldn't block |
| 18:55.42 | rd_ | Hmm...would they be regenerated if I move /home/user away? |
| 19:00.07 | DocScrutinizer05 | should, afaik |
| 19:01.22 | DocScrutinizer05 | wait, is that "exec dsmetool -foo Xorg... "? |
| 19:03.45 | DocScrutinizer05 | indeed |
| 19:04.13 | rd_ | Is that explaining some of the "miracles"? |
| 19:05.08 | rd_ | moving /home/user away did not change anything. |
| 19:06.28 | DocScrutinizer05 | nope |
| 19:07.05 | DocScrutinizer05 | it's just making me wonder if i finally should learn a bit about upstart scripts and how they work |
| 19:07.51 | DocScrutinizer05 | well, it's pretty obvious that dsme finds Xorg aborting for -n=8 times and then -r-eboots the device |
| 19:08.08 | DocScrutinizer05 | so the problem is in Xorg itself |
| 19:08.34 | DocScrutinizer05 | you tried placing the logging elsewhere (/dev/null) and that didn't help |
| 19:08.56 | DocScrutinizer05 | so it's most probably not the logging that fails |
| 19:09.45 | DocScrutinizer05 | since it seems Xorg doesn't log *anything* nevertheless, i'd guess sth elementary is broken |
| 19:11.53 | DocScrutinizer05 | if the last test I suggested shows that you actually _can_ echo something >>/mylogs/foo.bar |
| 19:12.10 | DocScrutinizer05 | then we also can rule out filesystem mounted r/o or whatever |
| 19:12.22 | rd_ | yes, that works |
| 19:12.34 | rd_ | I see an entry from before. |
| 19:12.40 | rd_ | filesystem is definitely ok |
| 19:12.56 | DocScrutinizer05 | then I'm also out of ideas |
| 19:13.39 | DocScrutinizer05 | particularly since it seems Xorg doesn't log a single char |
| 19:13.55 | rd_ | 7f47cfbc6c9d0c87853be2229268fd9a /usr/bin/Xorg |
| 19:14.01 | rd_ | does that md5sum match yours |
| 19:14.47 | rd_ | -rwxr-xr-x 1 root root 1568060 Feb 16 2010 /usr/bin/Xorg |
| 19:14.54 | DocScrutinizer05 | af3220748175c52b2fea9f3045b68d08 /usr/bin/Xorg |
| 19:15.20 | DocScrutinizer05 | -rwxr-xr-x 1 root root 1525792 2010-02-16 14:15 /usr/bin/Xorg |
| 19:16.26 | *** join/#maemo-ssu futpib (~futpib@89.106.197.106) |
| 19:18.20 | rd_ | Hmm that is weired? |
| 19:18.33 | DocScrutinizer05 | yeah, a bit |
| 19:18.45 | rd_ | what is your version of xserver-xorg-core 2:1.6.99.1-0osso20090208.108+0m5 ? |
| 19:18.53 | rd_ | This contains Xorg |
| 19:19.42 | DocScrutinizer05 | xserver-xorg-core: |
| 19:19.44 | DocScrutinizer05 | <PROTECTED> |
| 19:20.55 | DocScrutinizer05 | virus? ;-P |
| 19:21.33 | DocScrutinizer05 | I'd rather suspect you might have installed the thumb binary |
| 19:21.49 | DocScrutinizer05 | wild guessing |
| 19:21.59 | rd_ | Hmm...not that I am aware of.... |
| 19:22.06 | rd_ | trying a "apt-get install --reinstall xserver-xorg-core" |
| 19:22.15 | rd_ | funny that the data is the same. |
| 19:22.17 | rd_ | date |
| 19:22.52 | rd_ | virus on the n900 would be really surprising. |
| 19:26.09 | DocScrutinizer05 | indeed |
| 19:26.15 | DocScrutinizer05 | hardly believable |
| 19:26.55 | DocScrutinizer05 | and yep, date is quite strange |
| 19:34.25 | rd_ | still reboot loops, but let's see if the Xorg.0.log is now created |
| 19:39.27 | DocScrutinizer05 | I'd rather be interested in size of your Xorg now |
| 19:40.04 | DocScrutinizer05 | quite possble that mine is a bit strange, not yours |
| 19:46.27 | rd_ | no, after the reinstall I got your md5sum |
| 19:46.38 | rd_ | ....but I saved the old away for inspection ;-) |
| 19:49.40 | rd_ | reinstallation also reinstalled /etc/event.d/xomap |
| 19:51.59 | rd_ | The LED becomes sometimes green, I do not remember that I saw that before the reboot loops. Do you know what that means? |
| 19:53.50 | DocScrutinizer05 | it means that bme and hald-addon-bme and mce and a few other systems decided that your device is on USB power and battery is completely charged |
| 19:55.29 | DocScrutinizer05 | actually that would be interesting (if only for academic purposes, though you never know) to see if your device also goes into bootloop when plugged to charger when powered down |
| 19:57.35 | rd_ | Hmm...the green LED comes when it is not on a charger, but it is not blinking either, just flashes once. |
| 19:57.56 | rd_ | Also after some reboot loops the n900 seems to hang. |
| 19:58.11 | DocScrutinizer05 | yeah, that's rather normal I think |
| 19:58.26 | DocScrutinizer05 | the green flashing |
| 19:58.33 | rd_ | ah, ok. |
| 19:59.11 | rd_ | actually it is not hanging, it powers off |
| 20:00.20 | Drathir | for mine obserwation blink grees is short between security and code pin but if battery have low power in this moment also can shutdown and boot again if im not wrong.... |
| 20:00.43 | DocScrutinizer05 | wait, what? you deleted /home? |
| 20:01.48 | DocScrutinizer05 | ls -l /opt errr |
| 20:01.54 | DocScrutinizer05 | you can't |
| 20:02.24 | rd_ | shortly before the xomap crashes I see |
| 20:02.27 | rd_ | Jan 1 01:16:25 Nokia-N900 ohmd[806]: GLIB ERROR ** default - module videoep failed to load but listed in require aborting... |
| 20:02.37 | rd_ | Did CSSU changes in glib? |
| 20:02.37 | DocScrutinizer05 | when you deleted /home, you're out of luck since that also nuked /home/opt/* |
| 20:02.58 | DocScrutinizer05 | no |
| 20:03.04 | DocScrutinizer05 | prolly not |
| 20:03.16 | rd_ | no I did not delete home, I temporaryly move home/user away, but I moved it back |
| 20:03.21 | DocScrutinizer05 | actually this isn't a cssu topic at all |
| 20:03.54 | DocScrutinizer05 | or rather, most likely not |
| 20:04.52 | rd_ | I agree, although it is strange, that I did the CSSU upgrade and the reboot required for the update ended in boot loops |
| 20:05.09 | rd_ | BTW, do you also see the GLIB ERROR in your syslog? |
| 20:05.39 | DocScrutinizer05 | yeah, that *might* be related to cssu T8 which had a fuxored fstab/fsck feature |
| 20:06.01 | DocScrutinizer05 | that might have resulted in rootfs getting messed up, or whatever |
| 20:06.25 | DocScrutinizer05 | but now the problem is not related to cssu anymore, it at best been caused by cssu |
| 20:06.47 | DocScrutinizer05 | the problem not seems more generic |
| 20:06.51 | DocScrutinizer05 | now* |
| 20:07.13 | rd_ | How can I find out which CSSU I have installed? |
| 20:07.14 | Drathir | rd_: can i ask where you move home/user ? |
| 20:07.24 | DocScrutinizer05 | hmm |
| 20:07.28 | rd_ | mv /home/user /home/user.bak |
| 20:07.32 | rd_ | mkdir /home/user |
| 20:07.39 | Drathir | ok |
| 20:07.41 | rd_ | chown user:users /home/user |
| 20:07.52 | rd_ | <tested> |
| 20:07.56 | rd_ | rm -rf /home/user |
| 20:08.03 | rd_ | mv /home/user.bak /home/user |
| 20:08.47 | Drathir | im not sure if user isnt ext partition if moved to fat loosing permission when back but in this case ok... |
| 20:09.22 | DocScrutinizer05 | nobody moved sth to vfat |
| 20:14.56 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 20:18.37 | DocScrutinizer05 | ponders starting another BM backup |
| 20:19.35 | DocScrutinizer05 | actually osso-backuo's inability to do automated backups is one of the most braindead things in maemo |
| 20:20.44 | rd_ | Do you save away entire disk images, such that in case of an emergency you can play back the entire installation? |
| 20:20.57 | rd_ | (or do a diff ;-) |
| 20:21.13 | DocScrutinizer05 | BM does logical full images |
| 20:21.25 | DocScrutinizer05 | not disk images |
| 20:21.51 | DocScrutinizer05 | actually disk images are problemantic at least on NAND/ubifs |
| 20:22.29 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-119.residential.rdsnet.ro) |
| 20:23.41 | rd_ | ok |
| 20:23.49 | Drathir | im not sure but backup menu could work in this case because it is before green light flash... or im wrong? |
| 20:23.52 | DocScrutinizer05 | which is why BM-rev1 got discontinued |
| 20:23.55 | rd_ | so thanks to rescueOS I at least did not loose data. |
| 20:24.03 | rd_ | I will copy away everything overnight. |
| 20:25.34 | DocScrutinizer05 | backup of MyDoc shouldn't take longer than 3h or so |
| 20:25.37 | DocScrutinizer05 | iirc |
| 20:27.56 | rd_ | yes, but in 3h I am sleeping :-) |
| 21:24.13 | *** join/#maemo-ssu kolp (~quassel@212.255.252.3) |
| 21:48.09 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 22:18.25 | *** join/#maemo-ssu discopig (~discopig@66.130.167.140) |
| 22:18.25 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 22:21.37 | *** join/#maemo-ssu kerio (~kerio@Maemo/community/contributor/kerio) |