API tools faq
paste
Advertisement
Guest User

Maemo Unification Proposal

a guest
Sep 4th, 2015
617
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 15.17 KB | None | 0 0
raw download clone embed print report
  1. Greetings to all!
  2.  
  3. This is my attempt at explaining an idea I've been rolling around in my head for a while. Thanks for taking the time to come here and listen. What I propose to do, over the next couple months, is get together maemo enthusiasts like myself, and put our heads together. For too long, this community has been horribly fragmented amongst different contingents. As far as I understand, the closest thing we have to "updated maemo" is CSSU. I myself, use the CSSU repo, but know little about what all those packages are (Common sense aside now...), I just "know" the "community who does a lot of hard work at making things better" uses it <--- Inherited trust therefore, so do I.
  4.  
  5. So, how can we do this you're asking? How do we keep things simple, straightforward and to the point, all the while, giving those who want a billion packages, while at the same time, giving those who want a minimalist approach what they want as well? We use the concept of a "base image" for the n900. This can be accomplished in somewhat the same way that I do things for my current "special version" of the n900. My version grew out of the PwnieExpress PwnPhone Version 2 concept. Where I believe the strength in that was, was that to "implement" the PwnPhone, users simply downloaded 1 file from sourceforge, they decompressed the tarball and then ran the installation script. Roughly an hour later, they had a PwnPhone, complete with all the trimmings.
  6.  
  7. So before I detail the proposed idea and recommended implementation, I have to bring up the one thing that irks me more than anything about the n900. "Optification". The n900, as I understand it has two harddrives. A 256MB NAND flash, and a 32GB drive which is split into two partitions. The 256MB NAND comprises /, and, if you start installing random debs, which are not "optified", you quickly fill up /. On the larger harddrive, you get 2GB for ext3 and the other 30GB is for vfat.... LAME. Luckily, someone did a lot of work and you can easily find "https://wiki.maemo.org/Repartitioning_the_flash" if you Google hard enough. That post is awesome and it gives a huge swath of solutions for increasing ext3, but... It still doesn't solve the 256MB / problem. Only having 256MB of / causes issues if users want to take a .deb compiled for armel and throw it on their n900. I know, I know, "you shouldn't just grab .debs from distro X and throw them on... It'll break stuff", blah, blah, I hear it all the time; well, if the .deb was compiled properly and all dependencies are met; there is no reason you shouldn't be able to; dpkg and apt are smart; if you're going to do something to overwrite a critical file, it WILL stop you, or at least STOP you and ask if you want to force it. Point being, we should give that freedom to the n900 user. As it is right now, if your .deb isn't optified, you're screwed.
  8.  
  9. So, how do we "fix" this? We hack a solution of course. Now, I must say, this solution is untested when it comes to upgrading certain packages; if, per se, there is a kernel upgrade, I've never simply apt-got it, I purely reflash to stock and go from there. With the help of some smart Maemo folks, I'm sure I could reverse my work temporarily, install the new kernel, and then redo the work ALL without flashing. So, what is it I've done you ask? Through the help of the PwnieExpress folks, I created a series of scripts that hack the operating system to be more FHS compliant. So, for the typical user, this is your filesystem usage:
  10. IroN900:~# (mount&& df -h)
  11. rootfs on / type rootfs (rw)
  12. ubi0:rootfs on / type ubifs (rw,bulk_read,no_chk_data_crc)
  13. proc on /proc type proc (rw)
  14. sysfs on /sys type sysfs (rw)
  15. tmpfs on /tmp type tmpfs (rw,noatime,size=1024k)
  16. tmpfs on /var/run type tmpfs (rw,nosuid,noatime,size=256k,mode=755)
  17. none on /dev type tmpfs (rw,noatime,size=10240k,mode=755)
  18. devpts on /dev/pts type devpts (rw,gid=5,mode=620)
  19. tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noatime,size=65536k)
  20. /dev/mmcblk0p2 on /home type ext3 (noatime,nodiratime,errors=continue,commit=1,data=writeback)
  21. /home/opt on /opt type none (bind)
  22. nodev on /sys/kernel/debug type debugfs (0)
  23. /opt/pymaemo/usr/lib/python2.5 on /usr/lib/python2.5 type bind (bind)
  24. /opt/pymaemo/usr/share/pyshared on /usr/share/pyshared type bind (bind)
  25. /opt/pymaemo/usr/lib/pyshared on /usr/lib/pyshared type bind (bind)
  26. /opt/pymaemo/usr/share/python-support on /usr/share/python-support type bind (bind)
  27. /opt/pymaemo/usr/lib/python-support on /usr/lib/python-support type bind (bind)
  28. /dev/mmcblk1p2 on /media/mmc1p2 type ext3 (rw,noatime,nodiratime,noauto,nodev,exec,nosuid,data=writeback)
  29. /dev/mmcblk1p1 on /media/mmc1 type vfat (rw,noatime,nodiratime,noauto,nodev,exec,nosuid,utf8,uid=29999,shortname=mixed,dmask=000,fmask=0000,rodir)
  30. /dev/mmcblk0p1 on /home/user/MyDocs type vfat (rw,noatime,nodiratime,noauto,nodev,exec,nosuid,utf8,uid=29999,shortname=mixed,dmask=000,fmask=0000,rodir)
  31.  
  32. All that /opt/pymaemo "junk" above is where my beef lies. Granted, the "optification" concept, it was a great workaround to Nokia's insane layout, but, it's incompatible with "normal" Linux usage. Now, for the typical user, this is your space consumption:
  33. Dateisystem Size Used Avail Use% Eingehängt auf
  34. rootfs 228M 182M 43M 82% /
  35. ubi0:rootfs 228M 182M 43M 82% /
  36. tmpfs 1,0M 104K 920K 11% /tmp
  37. tmpfs 256K 100K 156K 40% /var/run
  38. none 10M 84K 10M 1% /dev
  39. tmpfs 64M 4,0K 64M 1% /dev/shm
  40. /dev/mmcblk0p2 2,0G 980M 934M 52% /home
  41. /opt/pymaemo/usr/lib/python2.5 2,0G 980M 934M 52% /usr/lib/python2.5
  42. /opt/pymaemo/usr/share/pyshared 2,0G 980M 934M 52% /usr/share/pyshared
  43. /opt/pymaemo/usr/lib/pyshared 2,0G 980M 934M 52% /usr/lib/pyshared
  44. /opt/pymaemo/usr/share/python-support 2,0G 980M 934M 52% /usr/share/python-support
  45. /opt/pymaemo/usr/lib/python-support 2,0G 980M 934M 52% /usr/lib/python-support
  46. /dev/mmcblk1p2 845M 782M 20M 98% /media/mmc1p2
  47. /dev/mmcblk1p1 14G 14G 48M 100% /media/mmc1
  48. /dev/mmcblk0p1 28G 18G 9,5G 65% /home/user/MyDocs
  49.  
  50. 82% of / is taken! Ouch... Now, let's check out something a little more FHS friendly...:
  51. rootfs on / type rootfs (rw)
  52. ubi0:rootfs on / type ubifs (rw,bulk_read,no_chk_data_crc)
  53. proc on /proc type proc (rw)
  54. sysfs on /sys type sysfs (rw)
  55. tmpfs on /tmp type tmpfs (rw,noatime,size=1024k)
  56. tmpfs on /var/run type tmpfs (rw,nosuid,noatime,size=256k,mode=755)
  57. none on /dev type tmpfs (rw,noatime,size=10240k,mode=755)
  58. devpts on /dev/pts type devpts (rw,gid=5,mode=620)
  59. tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noatime,size=65536k)
  60. /dev/mmcblk0p2 on /home type ext3 (rw,noatime,errors=continue,commit=1,data=writeback)
  61. /home/opt on /opt type none (bind,rbind)
  62. cgroup on /dev/cgroup/cpu type cgroup (cpu,memory)
  63. nodev on /sys/kernel/debug type debugfs (0)
  64. /home/rootfs_bind/usr on /usr type bind (rbind,bind,make-rshared,make-rslave,make-rprivate,make-runbindable)
  65. /home/rootfs_bind/sbin on /sbin type bind (rbind,bind,make-rshared,make-rslave,make-rprivate,make-runbindable)
  66. /home/rootfs_bind/lib on /lib type bind (rbind,bind,make-rshared,make-rslave,make-rprivate,make-runbindable)
  67. /home/rootfs_bind/root on /root type bind (rbind,bind,make-rshared,make-rslave,make-rprivate,make-runbindable)
  68. /home/rootfs_bind/var/lib/dpkg on /var/lib/dpkg type bind (rbind,bind,make-rshared,make-rslave,make-rprivate,make-runbindable)
  69. /dev/mmcblk0p1 on /home/user/MyDocs type vfat (rw,noauto,nodev,exec,nosuid,noatime,nodiratime,utf8,uid=29999,shortname=mixed,dmask=000,fmask=0000,rodir)
  70.  
  71. Here is the space consumption when doing something more FHS friendly:
  72. Filesystem Size Used Available Use% Mounted on
  73. rootfs 227.8M 140.8M 82.8M 63% /
  74. ubi0:rootfs 227.8M 140.8M 82.8M 63% /
  75. tmpfs 1.0M 76.0K 948.0K 7% /tmp
  76. tmpfs 256.0K 72.0K 184.0K 28% /var/run
  77. none 10.0M 72.0K 9.9M 1% /dev
  78. tmpfs 64.0M 4.0K 64.0M 0% /dev/shm
  79. /dev/mmcblk0p2 9.6G 1.6G 7.5G 18% /home
  80. /home/opt 9.6G 1.6G 7.5G 18% /opt
  81. /home/rootfs_bind/usr 9.6G 1.6G 7.5G 18% /usr
  82. /home/rootfs_bind/sbin 9.6G 1.6G 7.5G 18% /sbin
  83. /home/rootfs_bind/lib 9.6G 1.6G 7.5G 18% /lib
  84. /home/rootfs_bind/root 9.6G 1.6G 7.5G 18% /root
  85. /home/rootfs_bind/var/lib/dpkg 9.6G 1.6G 7.5G 18% /var/lib/dpkg
  86. /dev/mmcblk0p1 19.3G 984.4M 18.3G 5% /home/user/MyDocs
  87.  
  88. So... How did I make my system like this? I did two things:
  89. - I took the info in: https://wiki.maemo.org/Repartitioning_the_flash#Solution_.235:_Edit_eMMC_image_.28works_on_PR1.2.2C_by_globalbus.29 and modified it to where I used sed instead. Same concept; different approach:
  90. - sed -e "s/2048/9984/" RX-51_2009SE_10.2010.13-2.VANILLA_PR_EMMC_MR0_ARM.bin > patched-VANILLA.bin
  91. - Originally I used the method listed here: https://wiki.maemo.org/Repartitioning_the_flash#Solution_.231:_swap_.2Fhome_and_MyDocs_partition
  92. - However I found there were camera issues, not fatal ones, just loading an image via the picture viewer required some button pushing, so I chose to only have 9.1GB for ext3 versus the full 30GB.
  93. - After much research, it seems no matter what, the camera issue remains... So, I propose back to the 30/2
  94. - We can script it to ask the user the chosen layout...
  95. - After giving myself some room for the ext3, I invoked the help of the PwnieExpress folks and we decided to mount and recursively bind some of the "common stuff gets installed here" directories to the nice ext3
  96. - I'm sure there are many other directories we could rbind mount, I'm just not savvy in terms of what is needed and how things truly work with things like rcS-late and such
  97. - Truth be told, I'd prefer to have everything but / on ext3, I dunno if this is possible, but definately worth mounting things like /etc if possible...
  98. - There are other steps I haven't listed, but hopefully you get the "gist" of where I'm going with this...
  99. - How'd I deal with dependencies for things like pymaemo?
  100. - I created my own empty pymaemo-optify deb and labeled it version 99. No true pymaemo, no nonsense optification....
  101. - i.e. pymaemo-optify_99-patch1_all.deb
  102. - There might be issues with future kernel upgrades and such, but hopefully that's where folks like Pali come to the rescue and can guide how it can be done, properly and safely with a hack like above...
  103.  
  104. Okay, so FHS has been covered, I got to do my rant and get it off my chest. The above is not "needed" per se, but I believe it's a VERY good step in the right direction towards making maemo, more appealing.
  105.  
  106. Alright, we've arrived at the end. Time to explain the proposal to the community...
  107. - Form a tarball of all needed files and .debs to allow a user to simply download ONE file, and perform their "Maemo Transformation" 100% offline. No more having to navigate to a website and hope your internet connection holds. Think of this much like an ISO, but with a Maemo flare to it.
  108. - This tarball will have preparation scripts that we run prior to installing our "starter" meta-package as listed below. These scripts will prep the phone environment for what is to come.
  109. - It will also contain EVERY single .deb needed for baseline installation
  110. - We'll do md5sums or whatever for verification ofc...
  111. - FHS aside, I propose we create meta-packages with 1 meta-package as the absolute must have bare-bones "This is how the community has chosen to go forth and do good things" .deb file. This "starter" meta-package will do the following:
  112. - Using the control file in the .deb it will "conflict" and have a higher priority than all other .debs, and thus allow us to effectively apt-get purge things we as a community find "not bare-bones" essential
  113. - Some ideas that I currently use are:
  114. - apt-get purge -y cherry mp-fremantle-generic-pr ovi-promotion-widget osso-backup* osso-tutorial* osso-rss-feed-reader* facebook-installer dtg-installer amazon-installer ap-installer foreca-installer tracker tracker-utils hildon-welcome-default-logo hildon-welcome osso-mahjong osso-sounds-game-mahjong osso-graphics-game-mahjong google-search-widget tutorial-home-applet hildon-startup-progress osso-startup-wizard
  115. - rm -rf /etc/X11/Xsession.d/30osso_startup_wizard
  116. rm -rf /etc/X11/Xsession.d/01xprogress
  117. rm -rf /etc/X11/Xsession.post/22xprogress-stop
  118. rm -rf /etc/X11/Xsession.d/10hildon_welcome
  119. rm -rf /etc/X11/Xsession.post/04hildon-welcome-wait
  120. rm -rf /home/user/.cache/tracker/*.db
  121. rm -rf /opt/usr/share/icons/hicolor/32x32/hildon/general_facebook.png
  122. rm -rf /opt/usr/share/icons/hicolor/16x16/hildon/general_facebook.png
  123. rm -rf /opt/usr/share/icons/hicolor/48x48/hildon/general_facebook.png
  124. rm -rf /opt/usr/share/icons/hicolor/64x64/hildon/general_facebook.png
  125. rm -rf /opt/usr/share/icons/hicolor/24x24/hildon/general_facebook.png
  126. rm -rf /opt/usr/share/icons/hicolor/64x64/hildon/tasklaunch_get_started.png
  127. rm -rf /opt/usr/share/icons/hicolor/64x64/hildon/tasklaunch_user_guide.png
  128. rm -rf /usr/share/applications/hildon/user-guide.desktop
  129. rm -rf /usr/share/applications/hildon/ovi.desktop
  130. rm -rf /var/lib/osso-startup-wizard/
  131. - etc... etc.. etc....
  132. - The basic idea is that we put our heads together, agree on what to purge, and then use that as our base guidance.
  133. - Using that same "starter" meta-package, we would then create our own sources.list file to point people towards a good and proper set of repos, NO MORE GUESSING or going off "he said, she said"
  134. - Truth be told, I'm .deb smart, but not extremely savvy with it, so we might have to script some stuff, run the script and then dpkg -i that .deb versus letting the .deb do it all, but nonetheless, it can be "automated"
  135. - So, after this "starter" meta is installed, if any "needed system baseline" updates are created and put in the repo, we simply pop that new .deb in the Depends: line of the "starter" meta, and BOOM, we can push it to the users! No more guessing. One .deb to rule them all.
  136. - Now... "starter" has been covered. It will ONLY be for "needed essentials", no bloat. What if a user wants the bloat? I do mommy!
  137. - This is where other metas come in at. Want the pentest stuff I play with? Simply consult the official website at maemo, click on the "OFFICAL NEW WAY TO DO STUFF LINK", read the list of availabe metas, pick yours, apt-get install and go! Same concept as before, if a new pentest .deb is uploaded to the repo, the pentest meta will push it to users. Much the same way kali-linux does their "pushing", we can too. It's not just limited to pentest. We can have navigation, media, music, etc, etc, etc. Skies the limit here folks. The main thing is that "we" all, agree....
  138.  
  139. Okay, so that's it. That's my proposal. I look forward to receiving any feedback I can! Thanks for reading!
  140.  
  141. -- stryngs
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!