Hi all!
Many of us are dreaming of having a real native desktop operating system on Galaxy Note 10.1 as a second system. Of course, the software there is not touch-optimized, but you can attach keyboard and mouse via USB-OTG and Bluetooth and imagine it's a netbook
exception13 showed us that it's possible and shared his work on in a forum and repo. X-Stranger could use it and shared compiled images of ArchLinux. But what if you want to do something more specific for your own needs and you are not such a great developer as both of them are?
My project is for all of you who want to have native GNU/Linux, who want to participate but don't know how yet. It's a guide how to build it from scratch. The problem is - I am not a superdev too and I couldn't do many things. Frankly speaking, all the remaining things seem to be small but I don't know how to overcome them. Maybe it's because I'm studying economics but not programming
Link to the guide.
I need help from anyone who knows how to overcome any of the problems on every step! Everything I managed to do by myself is already written there and currently I have a compiled kernel which is booting a partition on external SD but it freezes there.
If you have any ideas - you can just make a pull request out of Github's webinterface, if you don't know how to edit this html but know something about building Linux - you are welcome to open an issue or write it here and I will include it in the guide.
Let's make our Galaxy Note 10.1 better together!
,I just got my Note 101.1 earlier today. I'll look into the missing information and add to the webpage. Is there anything that you think I should look into first?
I actually had a question.
Looks like you have the section "Harder Way - how to prepare binaries" split into Ubuntu and Arch. Instructions for compiling the kernel are the same.
I guess my question is why the choice to show the arch kernel being compiled under arch?
Might be easier to read the guide with all the kernel compiling done in Ubuntu.
**Edit**
What I didn't originally mention is that i really like it. Hoping to help contribute as well.
darksabre_x said:
I actually had a question.
Looks like you have the section "Harder Way - how to prepare binaries" split into Ubuntu and Arch. Instructions for compiling the kernel are the same.
I guess my question is why the choice to show the arch kernel being compiled under arch?
Might be easier to read the guide with all the kernel compiling done in Ubuntu.
**Edit**
What I didn't originally mention is that i really like it. Hoping to help contribute as well.
Click to expand...
Click to collapse
Good question. The reason for that are that despite how close Arch Linux and Ubuntu are, the environments are different. Ubuntu usually has some sort of bash completion enabled by default whereas Arch Linux doesn't and of course each of them requires diferent packages installed to perform the same functions. I believe thermatk did each distro separately as to make things simpler for the end user. Pick a distro and go as each distro's guide can be tuned independent of the others.
Soul_Est said:
Good question. The reason for that are that despite how close Arch Linux and Ubuntu are, the environments are different. Ubuntu usually has some sort of bash completion enabled by default whereas Arch Linux doesn't and of course each of them requires diferent packages installed to perform the same functions. I believe thermatk did each distro separately as to make things simpler for the end user. Pick a distro and go as each distro's guide can be tuned independent of the others.
Click to expand...
Click to collapse
Doesn't really answer my question considering the end kernel will be the same regardless of the distro being used. I think you took my question as "Why are there 2 options for kernel compilation?", which wasn't what I was asking.
Looks like thermatk actually addressed the question with a page update.
It now gives separate options depending on which distro you want to end up with on your Note 10.1, in addition to separate kernel compilation options.
What I was referring to was when it was Ubuntu only instructions from kernel compilation all the way to deployment on the tablet and Arch only instructions. The kernel and linux image instructions weren't independent of each other, as they currently are.
Update
I'm really happy to hear that someone else wants to use it and contribute! :victory:
darksabre_x, you are right I separated the guide into parts yesterday because the system where you compile kernel doesn't really affect anything on the tablet.
Soul_Est, thank you for helping with questions in the thread :good:
Now I understand that tabs are not the best way to do it, will start this day from trying to rewrite this to a navbar constantly on top which lets you choose options from a dropdown.
Also yesterday got the guide to the point when one path through can get ypu to a bootable distro! You can compile kernel wherever you want, you should be on stock based rom and choose to install Arch on separate partition which probably will be a partition on SD. What you have to add at the end is
Code:
pacman -S lxde
and copy xorg.conf from X-Stranger's post. Once rebooted, you will be able to enter android:changeme and
Code:
sudo lxdm
and the gui will start if you don't have USB-OTG and keyboard you won't be able to enter password but you can poweroff from the interface's right corner :good: Attention: if gui says that it has no permissions to write logs do
Code:
sudo mount -n -o remount, rw /
and retry but do not forget to write here about it!
What are the current problems:
Why exception13 and X-Stranger both hardcoded the whole cmdline for kernel and forced it not to be changeable from bootloaders. It's easy to fix in the config but there should have been some idea or i'm paranoic?
What's wrong with LinuxDeploy, separate partitions and CyanogenMod? hiruna filed a bug but meefik seems to be away for a week. If anyone else with CM has an idea on how to overcome this maybe with some special unmount commands CM is thinking that ext4 partition is th extSdCard and mounts it so that LinuxDeploy can't install anything there (seems that it's the problem) while stock can't mount ext4 as extsdcard and is not touching the partition.
How do we make Debian/Ubuntu to boot? Both ways - for separate partition and img are stuck one the problem that not any mkinitramfs or abootimg or their combinations could get to a better state than initramfs shell. Separate partition should be easier so focus should be on it for the start.
Adapt X-Stranger's guide about booting Arch from *.img. It's there and should be tested, rewritten and easied and some whitespaces should be filled. I know there are some as i have spent many hours in Arch with little dirty hacks like
Code:
ln -s /proc/self/fd /dev/fd
that are needed but no one ever wrote that they are.
What's wrong with basic video? While we get bootable Arch if you add lxdm and xorg.conf it should work with lightdm and boot there without console commands. If you try to install lightdm you will get nothing but a black screen if you start it with
Code:
sudo lightdm
... and it should boot automatically without touching console.
Oh and why is kernel from exception13 not building at all? XD
Redesign #2
Anyone dislikes the new design idea with navbar selectors instead of tabs?
I hope it's better.
Will soon update the guide with last steps to have Arch with LXDE bootable from separate partition.
That's fun as I started this project to get Ubuntu working... :angel:
If anyone can understand what should be done with mkinitramfs to make debian/ubuntu rootfs bootable - please do it.
First success!
If you choose any pc distro, arch on sgn with lxde on a seaprate partition you will now get a fully working guide that will give you a native bootable GNU/Linux =)
That's first success for me but still i hope to get help as i don't know things I asked two posts ago and it's difficult to move forward.
XFCE problems
XFCE is booting (not in the guide yet) but for working with fingers in XFCE one should probably disable multitouch S-pen works fine.
http://lists.x.org/pipermail/xorg/2012-July/054626.html
http://xfce.10915.n7.nabble.com/Xfwm-window-borders-do-not-respond-to-touch-screen-td17348.html
Will find a way to enable onscreen keyboard on LightDM and update the guide with XFCE. Still I was hoping to make it my primary DE and they are not supporting fingers moving windows upstream :crying:
I was hoping to contribute this weekend but unfortunately my only machine is down after mucking up the /lib folder when heimdall. To add insult to injury, I have no backups. Installing Arch Linux or Debian and configuring everything to my liking again will take a few hours.
Sent from my GT-N8010 using Tapatalk 2
How to setup WiFi using wpa_supplicant.conf
How to setup WiFi using wpa_supplicant.conf
1. Copy the "wifi" folder to "/opt"
- You will need gedit to edit the nameservers.
- You also need two dependencies before installing gedit.
- The two dependencies are : gtksourceview3-3.6.1-1-armv7h.pkg.tar.xz and libpeas-1.6.1-1-armv7h.pkg.tar.xz
2. Download them and copy over to ArchLinux
3. Install the dependencies first then gedit:
Code:
sudo pacman -U gtksourceview3-3.6.1-1-armv7h.pkg.tar.xz
sudo pacman -U libpeas-1.6.1-1-armv7h.pkg.tar.xz
sudo pacman -U gedit-3.6.2-2-armv7h.pkg.tar.xz
4. insmod the drivers:
***NOTE*** " 3.0.31-gedcc915 " is my kernel name. Change it to your
kernel name if it is different.
Code:
sudo insmod /lib/modules/3.0.31-gedcc915/kernel/net/wireless/cfg80211.ko
sudo insmod /lib/modules/3.0.31-gedcc915/kernel/drivers/net/wireless/bcmdhd/dhd.ko op_mode=0 firmware_path=/opt/wifi/bcmdhd_sta.bin nvram_path=/opt/wifi/nvram_net.txt_murata
5. Enable the wlan0:
Code:
sudo ip link set wlan0 up
6. Setup wpa_supplicant and ip address:
Code:
sudo wpa_supplicant -B -i wlan0 -Dwext -c /etc/wpa_supplicant/wpa_supplicant.conf
sudo ip addr add 192.168.1.33/24 dev wlan0
sudo ip route add default via 192.168.1.1
7a. Add nameservers:
Code:
sudo gedit /etc/resolv.conf
7b. Go to the next available line and type:
Code:
nameserver 8.8.8.8
7c. Next line :
Code:
nameserver 8.8.4.4
7d. Save it
8. Go back to the terminal and edit the wpa_supplicant file:
Code:
sudo gedit /etc/wpa_supplicant/wpa_supplicant.conf
- wpa_supplicant.conf file should be like this:
Code:
ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
network={
ssid="NETWORKNAME"
scan_ssid=1
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
psk="NETWORKPASSWORD"
}
9. And finally, to connect to your network, run
Code:
sudo dhcpcd
Open up a web browser and enjoy!
:good: :good: :good:
WiFi
I am currently including WiFi in the main guide as it's something everyone needs :laugh:
Soul_Est said:
I was hoping to contribute this weekend but unfortunately my only machine is down after mucking up the /lib folder when heimdall. To add insult to injury, I have no backups. Installing Arch Linux or Debian and configuring everything to my liking again will take a few hours.
Sent from my GT-N8010 using Tapatalk 2
Click to expand...
Click to collapse
I will be happy if you join :good:
thermatk said:
I will be happy if you join :good:
Click to expand...
Click to collapse
I'll get right on the Arch Linux instructions once I get an Arch based OS installed. Hopefully that'll be tomorrow.
Written on my Galaxy Note 10.1
is this project dead ?
Equilibrio said:
is this project dead ?
Click to expand...
Click to collapse
Great job! This is awesome.
Anyone else having dependency conflicts with bluez and obexd-client?
cctoro said:
Great job! This is awesome.
Anyone else having dependency conflicts with bluez and obexd-client?
Click to expand...
Click to collapse
I did before but it really depends on what you have install at the time when you do the update.
Having a small issue
Ok, so I followed all the instructions and set the kernel up to boot from mmcblk1p2 (my ext4 partition on my sdcard I made for linux), and used dd to copy the prebuilt arch to the partition, and it boots and eveything seems to work but the wifi.... I repeated the process from the beginning all over and recompiled to make sure i didn't miss anything, but still no wifi... And since I'm using the prebuilt image copied to the sdcard for the distro, and everything works in it if i boot the .img from the internal storage and use the premade recovery, I'm assuming maybe there's something missing from compiling the kernel? In either case, if anyone has any ideas about this, please help, or if someone can make a properly compiled recovery.img that boots from mmcblk1p2, that would be super awesome.... I'm only mediocre in linux skill so any help would be appreciated!
K, so i was an idiot and forgot to copy the compiled kernel modules to /lib........ OOPS!
Arch linux distro booting from mmcblk1p2 with 1p3 as swap... all work awesome! Working on dri2 for the mali now.....
Sent from my GT-N8013 using xda app-developers app
Could you post a prepared .IMG, possibly? Thanks.
Sent from my GT-N8013 using xda app-developers app
Related
EDIT [02/14/2010]: Please see mjgdroids FINISHED PORT HERE.Make sure to thank him and/or donate to mjgdroid.
EDIT: MAKE SURE YOUR ROM SUPPORTS PARTITIONS ON YOUR SD! YOU CAN USUALLY FIND THIS INFO IN YOUR ROMS FAQ.
I'm currently looking for a work-around. Mounting EXT3 still works in the rooted terminal, but that doesn't help Android see your FAT partition.
Here it is folks, working instructions to get Debian Lenny running on your Droid Eris! I say that it's 90% complete because I do not yet have fully functioning MeeGo, I hope to resolve the issue sometime this weekend. Otherwise, all is well. I'm releasing the instructions so that others in the community can contribute.
Thanks to ban_dover for a lot of initial work. For author credit, other contributions, and the original thread leading up to my fix, see http://forum.xda-developers.com/showthread.php?t=748094. If there is ANYONE else who needs to be credited here, PLEASE pm me and I'll edit this post.
Also, if you're wondering "Why Debian Lenny?" it was readily available and already set up for ARMv5 and up. There are also available MeeGo binaries for Lenny. WOOHOO! Everybody's life is easier.
EDIT: I've released what I consider to be an unstable/incomplete RAW image. I will not link to unstable images in this post, you can download it on page 2 of thread. This image can be used to skip both step 1 and converting the image from QCOW to RAW.
1. Create ARM image containing Debian Lenny
In Linux command line
- Download Debian ARM Installer
wget http://ftp.de.debian.org/debian/dis...el/current/images/versatile/netboot/initrd.gz
wget http://ftp.de.debian.org/debian/dis.../versatile/netboot/vmlinuz-2.6.26-2-versatile
- Create disk image
qemu-img create -f qcow deb-arm.img 4G
- Run QEMU VM to run Debian ARM Installer
qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.26-2-versatile -hda deb-arm.img -initrd initrd.gz -append "root=/dev/ram" -m 256
- In Debian installer, follow prompts
I chose the following user access, root-pass:debian91, user:debian and pass:debian91
Install desired defaults. I initially went with desktop environment; core environment may be best for MeeGo
- Reboot VM ONCE to permit it to statisfy any changed dependencies
2. Create filesystem on phone and copy Lenny
In Linux SUPER-USER command line
- Backup SDCARD if necessary
- Enter superuser mode
"sudo sh" or "sudo bash"
- Partition SDCARD
Use partition editor of choice (I used GParted)
FAT must be first partition
Create second partition as ext3
- Mount EXT3 partition
mkdir sd
mount -t ext3 /dev/sdb2 sd
- Convert QCOW image to RAW image
qemu-img convert deb-arm.img -O raw deb-arm.raw
- Mount RAW image as loop
mkdir image
mount -t ext3 deb-arm.raw image -o loop,offset=32256
- Copy image contents to EXT3 partition on SDCARD
cp -r image/* sd
- Unmount both SDCARD and RAW image
- umount deb-arm.raw && umount /dev/sdb2
3. Bind necessary nodes and create chroot jail
In eiter ADB shell or in rooted phone command line (either method MUST BE SUPERUSER!!!)
- Enter superuser mode
"su" (make sure to accept and remember if asked on rooted phone; also not sure how to superuser in ADB shell)
(NOTE: The folowing commands should use "busybox" as a prefix if using ADB shell in terminal)
- Mount EXT3 partition (should be /dev/block/mmcblk0p2)
mkdir /data/local/debian
mount -t ext3 /dev/block/mmcblk0p2 /data/local/debian
- Bind the necessary nodes
mount --bind /dev/pts /data/local/debian/dev/pts
mount --bind /proc /data/local/debian/proc
mount --bind /sys /data/local/debian/sys
sysctl -w net.ipv4.ip_forward=1
- Enter into Debian system
chroot /data/local/debian /bin/bash
4. Installing MeeGo and opening an Xsession through VNC
- COMING SOON!! (like, over the weekend)
EDIT: MINOR SETBACK DUE TO FROYO NOT SUPPORTING PARTITIONED SDCARDS. WORKING WITH DEVS TO RESOLVE.
Connecting chroot to VNC
Running MeeGo environment
- Why Not Now
Finding the best way to get an xserver on Android... possibly without VNC
Seeing which is better, install MeeGo before copying to SDCARD, or after
- Possible future: adapting Lenny to favorite distro flavor
- This would take a lot more of my time, and those who want to convert it to ubuntu can google it more easily
Information Sources
This is a list of articles that I've gleaned my info from.
Debian Lenny ARM on Qemu
http://www.debian.org/releases/stable/installmanual
http://www.finalcog.com/howto-install-debian-lenny-arm-qemu-ubuntu-jaunty
http://kevin.deldycke.com/2007/04/how-to-grow-any-qemu-system-image/
Chrooting Troubleshooting
http://forum.xda-developers.com/showthread.php?t=748094
http://forums.dlink.com/index.php?topic=6073.0;wap2 (helpful in determining why nexus one and incredible images wouldn't chroot)
https://help.ubuntu.com/community/BasicChroot
http://forums.gentoo.org/viewtopic-t-470306-start-0.html
Inspiration
http://bayleshanks.com/wiki.pl?tips-computer-android-g1_debian_cyanogenMod
Most of the G1 development on XDA
http://androidforums.com/incredible-all-things-root/120622-how-run-ubuntu-droid-incredible.html
Very cool, good job.
very nice indeed!
Thanks guys.
I've always wanted to ask but thought it might offend someone. In any case, what will this enable us to do that we couldn't do already?
Sent from my FroyoEris using XDA App
xnatex21 said:
I've always wanted to ask but thought it might offend someone. In any case, what will this enable us to do that we couldn't do already?
Sent from my FroyoEris using XDA App
Click to expand...
Click to collapse
My thoughts exactly, I have no idea what's being said here.
Sweet! Nice work.
korben dallas said:
My thoughts exactly, I have no idea what's being said here.
Click to expand...
Click to collapse
Hmm... I sometimes fall on the answer that its obvious. Let me give a few reasons why I did it. Other than "it is fun for me."
1. Because we can, lol
2. It opens potentially the full gamut of available Linux software that wouldn't otherwise run (unless ported)
3. Broadened capability means wider choice
4. Unknown territory (at least for Eris users) provides new frontiers
I like these answers, three out of four also sum up why open source exists.
Very nice man. Got any screens?
Nikolai2.1 said:
Very nice man. Got any screens?
Click to expand...
Click to collapse
Right now, my camera is my eris. I'll get somebody to take either video or some pics this weekend so y'all can see it in action.
Could anybody create an image and upload it I just spent the last 4 hours waiting for debian to install inside qemu only for it to hang right before the end lol. Needless to say I just want to experiment with it but I don't really want to do that again or risk it hanging again.
Running X from Chroot
OK, so I was sitting around on break and it hit me that Debian Lenny has the Gnome Mobile desktop designed for touch interfaces in its repositories. The project is called Hildon and was the basis for Maemo before it became MeeGo. Voila, debian gui solved.
Then I remembered an article I'd read while in college on running X from within a chroot jail. I love google; I took a look around for it and found it: http://norman.walsh.name/2003/08/22/chroot. Bingo! We may not need VNC to get graphical output.
In short, my free time is going to consist of installing Hildon in Lenny and writing a script to bind the proper directories, descend into chroot and run X.
It's interesting to note a few things. I read on a few boards that android doesn't have it's own Xserver. Historically, chroot was used for testing purposes to ensure that a system could run on the existing kernel/hardware/etc. Well, in Debian Lenny we have an xserver and its dependencies compiled to run on ARMv5 and up. So technically if we can get X to run from chroot with the proper bindings, then we can get that SAME xserver to run directly on Android. Further, the ability to run Debian in chroot directly implies that the same software will run outside of chroot.
And one speculation: it would be an interesting experiment to see if these tools could be run side-by-side with the default Android rom. To any devs familiar with Android roms, does that sound overly ambitious?
AcidRoot said:
Could anybody create an image and upload it I just spent the last 4 hours waiting for debian to install inside qemu only for it to hang right before the end lol. Needless to say I just want to experiment with it but I don't really want to do that again or risk it hanging again.
Click to expand...
Click to collapse
Hey AcidRoot! I give no guarantees as I mentioned I'm still working out kinks, but I can upload my image. I'll compress it, upload it, and edit this post with a link to it.
My current image of Debian Lenny ARMv5 is available here. I'm not posting the link in the first post because this image does not constitute what I'd call stable and complete, just so you're forewarned.
composerdude said:
Hey AcidRoot! I give no guarantees as I mentioned I'm still working out kinks, but I can upload my image. I'll compress it, upload it, and edit this post with a link to it.
My current image of Debian Lenny ARMv5 is available here. I'm not posting the link in the first post because this image does not constitute what I'd call stable and complete, just so you're forewarned.
Click to expand...
Click to collapse
Thanks alot I know the risks I just want to experiment with it.
One of the kinks that would be immediately noticed is that paths to executable directories are not set. When chroot into /data/local/debian, make sure that one of the first things you do is change the path variable.
Code:
PATH=/usr:/bin/:usr/local/bin:.
oman def going to try this later on tonight... sounds GREAT
What is this exactly?
Awesome work man! I've been following this in ban_dovers thread. I just needed to comment here so it'll show up in my "participated" folder on my xda app.
I'll be lurking and waiting for something more stable and noob friendly. Keep up the great work.
Sent from my nonsensikal froyo using XDA App
@joshw0000: Thanks for the encouragement!
@EVERYBODY: I just discovered today after updating Tazz Froyo to the latest version that updates to CM6 have aparently broken support for partitioned SD cards. I am looking for a work-around before working out more kinks. My istructions still work, it's just that ANDROID sees a blank SD, even though partitions can still be mounted to run Debian. Anyone testing, check your FAQs to make sure partitions are supported. I'll keep you posted on my end.
[SCRIPT] A Handy Script to build CyanogenMod from source: "It does stuff" [v0.2]
I know everyone's probably like, hey, since CM is officially released, why do we need this? I'll tell you why. You know how all of the other phones get nightlies? I feel left out. That's why I've created this handy script to walk you through everything from getting source to building and eventually flashing. The script will be updated somewhat frequently as I add features and such. To start off, I'll walk you through how to use it. There are several switches that you can use, such as setup, init, clean, or dirty. Setup will do the initial setup for you, installing packages and repo and rebooting your computer. Init will initialize the CyanogenMod repository on your computer. Clean will build with a "make clean" to be sure everything is fresh. Dirty will, you guessed it, build what I consider a "dirty" build, with no make clean. Much faster, but more prone to glitches. Usage is simply cd'ing to where you saved the file, possibly chmod a+x'ing it (I'm not sure if mediafire retains the permissions set on a file locally), and then running ./buildscript.sh your_option_here. (Example:
Code:
./buildscript.sh clean
will clean your repositories and build from scratch.) Thats it! Have fun, and be safe.
*I am not responsible for any damages, emotional harm, dead puppies or goldfish caused by using this script.
Download: HERE
Come here to report issues, glitches, and/or enhancements.
https://github.com/ytt3r/buildscripts/issues
v0.3(Coming Soon)
Fixed running the radio script
A few minor changes
More aesthetic changes
v0.2
Added an option not to reboot on setup of repo
Aesthetic changes
Added copying of modules to the correct locations
Other stuff I can't remember (maybe, I'm too lazy to diff) lol
v0.1
Initial script: enables users to do several things very easily
You're just trying to make me boot into Linux more often, aren't you? I will definitely be taking advantage of this.
Sent from my CM7 powered captivate
Brilliant.
I still haven't synced the repo, I started to but it ate up so much bandwidth on my network.
This'll do it for you
Sent from my Captivate using XDA App
I am wondering if you can give the exact process we need to run this script in and what os it supports.
Currently trying to run it on an ubuntu install and having some problems. I run setup and it eventually asks to reboot and continue the script, i hit yes and it exits the script. nothing more. I reboot and then try to do the script with init but complains about missing directories.
found some errors when doing setup
E: Unable to locate package lib32z1-dev
E: Unable to locate package lib32ncurses5-dev
E: Unable to locate package lib32readline5-dev
./buildcaptivate.sh: line 22: curl: command not found
Click to expand...
Click to collapse
Are you on a 64 bit system?
Sent from my Captivate using XDA App
ytt3r said:
Are you on a 64 bit system?
Sent from my Captivate using XDA App
Click to expand...
Click to collapse
Its in vmware an very well could be 64-bit, or 32-bit.
looked it up and its 32-bit i guess.
Is the script for only 64-bit?
for the sake of learning something, could i get a laymans explanation of what this does?
or am i on the right track by...
it builds a captivate CM rom from (Android? not samsung) source?
ccdoggy said:
Its in vmware an very well could be 64-bit, or 32-bit.
looked it up and its 32-bit i guess.
Is the script for only 64-bit?
Click to expand...
Click to collapse
Only runs on a 64 bit system.
Trusselo said:
for the sake of learning something, could i get a laymans explanation of what this does?
or am i on the right track by...
it builds a captivate CM rom from (Android? not samsung) source?
Click to expand...
Click to collapse
You can run it every night by saying something like
Code:
./buildcaptivate.sh clean
which will build CyanogenMod clean for you, as an unofficial self-built nightly.
Do Not Run Current Version
This script makes some alarming system-wide changes:
Code:
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh
and that's just in the first few lines, I haven't even read through the rest of the way through the script yet.
y3ttr, you need to go through this script and find ways of doing this with less system wide impact, and you need to spell out in the OP exactly what system changes are still made (the new apt repositories, for instance, which is a system change you likely won't be able to get around, for instance). Also, I recommend having stuff like the source location and stuff to be a variable that can be changed (for instance, lots of people would prefer to keep source in /usr/src, etc).
Another option you could look into is using a chroot jail for a lot of the build process, so you don't impact the wider system. Also, add some if/else statements so that this can run on something other than Ubuntu 64bit. Shouldn't be that hard.
Edit: i've read through some more of the script, here are some more thoughts:
no need to reboot, use source ~/.bashrc. But even for that, you shouldn't be adding stuff to a users' PATH permanently. Just do it in the script leave it at that.
to make it i386 or x64 compatible, use a uname -p to determine the arch type and a switch statement
do not change the default shell. there should be no need.
too many hard coded paths. use some variables, $PWD, and which to figure out locations and paths.
to make this really cool, have an option to automatically copy it to /usr/local/bin and have it run from cron every night.
have an variable to set where the build root is located, and another one to set where the final builds will be dumped (for instance: build in /usr/src, but place the final builds in ~/cyanogenmod/).
DamnMersault said:
This script makes some alarming system-wide changes:
Code:
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh
and that's just in the first few lines, I haven't even read through the rest of the way through the script yet.
y3ttr, you need to go through this script and find ways of doing this with less system wide impact, and you need to spell out in the OP exactly what system changes are still made (the new apt repositories, for instance, which is a system change you likely won't be able to get around, for instance). Also, I recommend having stuff like the source location and stuff to be a variable that can be changed (for instance, lots of people would prefer to keep source in /usr/src, etc).
Another option you could look into is using a chroot jail for a lot of the build process, so you don't impact the wider system. Also, add some if/else statements so that this can run on something other than Ubuntu 64bit. Shouldn't be that hard.
Click to expand...
Click to collapse
This removal of sh is required as ubuntu defaults to using dash for some god-forsaken reason instead of bash. so the symlink must be placed in (most people won't even notice a difference for the remainder of their ubuntu lifespans) to guarantee that bash is used for all the building process (as it's required).
also, this isn't meant to truly be "configurable" as you're describing, it's merely meant to be simple/easy for people to build their own nightly (at their own risk)
Kaik541 said:
This removal of sh is required as ubuntu defaults to using dash for some god-forsaken reason instead of bash. so the symlink must be placed in (most people won't even notice a difference for the remainder of their ubuntu lifespans) to guarantee that bash is used for all the building process (as it's required).
also, this isn't meant to truly be "configurable" as you're describing, it's merely meant to be simple/easy for people to build their own nightly (at their own risk)
Click to expand...
Click to collapse
If the build process requires bash, then the build scripts should specify #!/bin/bash, not #!/bin/sh.
E: Unable to locate package lib32z1-dev
E: Unable to locate package lib32ncurses5-dev
E: Unable to locate package lib32readline5-dev
Click to expand...
Click to collapse
I believe are
lib64z1-dev
libncurses5-dev
libreadline5-dev
on a 32bit system. At least from what I gathered reading a CM forum post.
Hopefully that will save a little bit of time for anyone trying to build on 32bit, there are some extra steps once you start compiling, but I still haven't been able to to figure out why I'm getting fatal errors during the syncing/download process. So I have no idea if the workarounds for a 32bit system work for CM7 during the build process.
Here is the CM thread, post #21. Link.
ytt3r, regarding your script...
It does stuff !
Truly priceless quote.
Sent from my SAMSUNG-SGH-I897 using XDA App
Thank you for this! It seems to be working... I don't know if it's the repo or my ubuntu acting weird....
Kernel don't want to build (either manually or with this)
But I was able to do it 2 days ago with the same computer.! Will try again later.
For those of you with lower powered computers like me (My computer right now is 2gb RAM, Core 2 Duo) its a hassle every time you build ICS. For me it takes around 10 hours, and half the time the build crashes.
So since I wanted to just get my feet wet with the development going on here as far as the actual ROM, I decided I wanted to go the kernel route.
The actual compilation guides around the internet are just for compiling the kernel and then adding it into the ROM's build directory so that it gets build along with the ROM. The thing is though that if you don't compile the build kernel with the ROM, then it lacks the ramdisk and doesn't boot.
So thanks to the help of jcsullins, we now have a guide for building CM9 without the ROM building It is below. Many parts of this guide were taken from here: https://www.evernote.com/shard/s102...6dfbf53e0fe5/ba173394b43ed99ae6a90a4d1c51210f (by danabw) and from here: http://code.google.com/p/moboot/issues/detail?id=20
This guide assumes you havent build android before on your system. The build requires some extra programs which are explained in the steps below as well.
Where ever there is multiple lines of code, run the code lines one at a time. Also, I am not responsible for anything that happens as a result of this guide, though it works perfectly for me on Ubuntu 10.04 and the CM9 Nightlies.
Without further ado, here it is:
Prerequisites:
-Touchpad (d'oh)
-PC running Ubuntu 10.04 or higher (I recommend 10.04 for the best stability as far as android builds go including this one)
-Run these lines of code to install most of the prerequisites you need for building android (approx 103 mb)
sudo add-apt-repository ppa:ferramroberto/java
sudo apt-get update
sudo apt-get install sun-java6-bin
sudo apt-get install sun-java6-jdk
sudo apt-get install git-core gnupg flex bison gperf libsdl1.2-dev libesd0-dev libwxgtk2.6-dev squashfs-tools build-essential zip curl libncurses5-dev zlib1g-dev sun-java6-jdk pngcrush schedtool
Click to expand...
Click to collapse
1. Create the kernel build directory
mkdir -p ~/android/kernel/
Click to expand...
Click to collapse
2. Get the kernel source.
cd ~/android/kernel/
git clone git://github.com/CyanogenMod/hp-kernel-tenderloin.git -b ics
Click to expand...
Click to collapse
3. Download & install uboot-mkimage and set the PATH to it:
sudo apt-get install uboot-mkimage
PATH=${PATH}:~/usr/bin
Click to expand...
Click to collapse
4. Download & install CodeSourcery for the ARM Toolchain
Click on the link here: https://sourcery.mentor.com/sgpp/lite/arm/portal/release1802
Click "IA32 GNU/Linux Installer"
Let the package download
After done, go to terminal and navigate to your download directory (mine is /home/rohan/Download)
Type these commands:
chmod +x arm-2011.03-42-arm-none-eabi.bin
./arm-2011.03-42-arm-none-eabi.bin
Click to expand...
Click to collapse
Follow the directions it gives you. If it comes up with an error about reconfiguring dpkg, do what the message in the terminal says about turning off a settings. You can reenable this later if you want by doing the same command and choosing yes instead of no.
5. Configure the configuration file
Close out of that terminal and open a new one.
Navigate to the kernel's build folder (the one whose path ends in the folder hp-kernel-tenderloin)
Then type:
make ARCH=arm tenderloin_android_defconfig
Click to expand...
Click to collapse
6. Build the kernel
Type the following into terminal:
make ARCH=arm -j8 CROSS_COMPILE=~/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-eabi- uImage
Click to expand...
Click to collapse
Where it says "-j8" above, replace with the number of CPU/cores on your system. On a dual core system that should be -j8, but -j3 worked fine on my dual core system as well.
This took my system around 7 minutes.
7. Ready the uimage-extractor tool
Go up one directory in your terminal and then do the following commands:
git clone https://code.google.com/p/moboot
cd moboot/tools
gcc -lz uimage-extract.c -o uimage-extract
Click to expand...
Click to collapse
Now grab the uImage.CyanogenMod you have in your Touchpad's /boot folder (via a file manager with root access or adb) and put the uImage in the moboot/tools directory (where the terminal currently is in)
8. Decompile the existing uImage
Type the following:
./uimage-extract uImage.CyanogenMod
Click to expand...
Click to collapse
9. Grab the built uImage and put it in the extracted folder
Type the following:
cp <location to the hp-kernel-tenderloin folder here>/arch/arm/boot/uImage <location to the moboot/tools folder here>/uImage
Click to expand...
Click to collapse
10. Build the new kernel using the old ramdisk and your new built uImage
Type the following:
mkimage -A arm -O linux -T ramdisk -C none -a 0x60000000 -e 0x60000000 -n "Image" -d ramdisk.img uRamdisk
mkimage -A arm -O linux -T multi -a 0x40208000 -e 0x40208000 -C none -n "multi image" -d uImage:uRamdisk uImage.CyanogenMod.new
Click to expand...
Click to collapse
Thats it!
Your new kernel should now be in the moboot/tools directory under the name "uImage.CyanogenMod.new"
Transfer it to the /boot folder of your device and watch your hard work pay off
Again, HUGE thanks to jcsullins for all his work, along with the entire CM Team. It is truly awesome what they have put together!
Nice job man. While I haven't worked on the kernel side of things much, may have to give it more thought now.
Sent from my PG86100 using Tapatalk
Win7
OP,
Is there a similar guide for Win7 aside from Ubuntu? The above process looks manageable and TC in my experience is semi-unbrickable.
austin_dreq said:
OP,
Is there a similar guide for Win7 aside from Ubuntu? The above process looks manageable and TC in my experience is semi-unbrickable.
Click to expand...
Click to collapse
No. </10char>
For ubuntu users:
Instead of the CodeSourcery compilers you could also use the package gcc-arm-linux-gnueabi which has everything you need. Aside from not installing the CodeSourcery compilers the only thing in the guide that needs to be changed is the compile operation:
From
Code:
make ARCH=arm -j8 CROSS_COMPILE=~/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-eabi- uImage
To
Code:
make ARCH=arm -j8 CROSS_COMPILE=arm-linux-gnueabi- uImage
austin_dreq said:
OP,
Is there a similar guide for Win7 aside from Ubuntu? The above process looks manageable and TC in my experience is semi-unbrickable.
Click to expand...
Click to collapse
Over on RootzWiki there is a similar guide for building the kernel that is incorporated into the ROM, using Oracle VM on Win7. It is very clear and wish I would had this when I started building projects and kernels. I believe that is what Rohan was referring to in his OP. So you can follow those steps, including setting up the VM. The main difference then is the last few steps in terms of making the kernel with the ramdisk.
As an aside, my computer system is not very special, an older quad core amd with 8GB memory and I can typically build the ROM in a VM environment, depending on how many new commits there are, in ~30 minutes. But I do tend to build every day to keep up with the commits and thus keep my build time down. In terms of the kernel, as mentioned, I can usually build in only a few minutes. There are many fewer commits to the kernel, so that is pretty static unless you are doing a lot of development yourself.
O.a.T. said:
Over on RootzWiki there is a similar guide for building the kernel that is incorporated into the ROM, using Oracle VM on Win7. It is very clear and wish I would had this when I started building projects and kernels. I believe that is what Rohan was referring to in his OP. So you can follow those steps, including setting up the VM. The main difference then is the last few steps in terms of making the kernel with the ramdisk.
As an aside, my computer system is not very special, an older quad core amd with 8GB memory and I can typically build the ROM in a VM environment, depending on how many new commits there are, in ~30 minutes. But I do tend to build every day to keep up with the commits and thus keep my build time down. In terms of the kernel, as mentioned, I can usually build in only a few minutes. There are many fewer commits to the kernel, so that is pretty static unless you are doing a lot of development yourself.
Click to expand...
Click to collapse
Yeah I want to develop kernels mainly because I've never done it before for Android. I've developed for a Symbian device before since thats my current phone. The Touchpad is my first Android device, and I really hope to get a GNex soon as soon as it is brought to AT&T. If not, I'll probably either switch to VZ since AT&T is getting really annoying.
As for the non-installation of Code Sourcery, thanks! I never knew that package existed! Seems a lot less bloated than the Code Sourcery version.
And also for the developing on Windows, I'd just set up a VM for Ubuntu 10.04. Or you could install wubi, which is a dual boot solution to your Windows predicament. I'm currently running wubi since my only machine right now is old and aging. I need to migrate over to a full dual boot soon though.
This guide can be used on other phones?
sahibunlimited said:
This guide can be used on other phones?
Click to expand...
Click to collapse
If they use the same uImage format then yes. However, I'm not sure if other devices allow you to boot from the uImage, you may need to further compile a boot.img from this. The Touchpad allows this since it needs the uImage for moboot.
rohan32 said:
Yeah I want to develop kernels mainly because I've never done it before for Android. I've developed for a Symbian device before since thats my current phone. The Touchpad is my first Android device, and I really hope to get a GNex soon as soon as it is brought to AT&T. If not, I'll probably either switch to VZ since AT&T is getting really annoying.
Click to expand...
Click to collapse
HTC ONE X<Should have been the Nexus instead of Samsung version.
Guide to making a Raring Ubuntu-core image on a Linux PC/laptop (NOT a virtual machine (VM)) for the purpose of installing it on your TF101.
All credit goes to the time and consideration x3maniac took to assist me with doing this!
OP for Tubutnu by x3maniac
This guide allows you to create a CORE Ubuntu image on your Linux box and then install it using the Tubuntu application for Windows. ***Please note, a CORE image does not contain a GUI. The gnome-core guide in the next link will walk you through the steps of installing the gnome-core GUI after you have made your fresh Raring Ubuntu-Core image.***
http://forum.xda-developers.com/showthread.php?p=37803357
***Why do I want to do this when the OP by x3maniac already has a Raring image for download? This guide is helping you make your own UPDATED image. There are daily builds of Raring and the image in the OP by x3maniac is over 2 months old as of this last update to this post.***
Please note that I am using a stock Ubuntu 12.10 laptop. I believe any variant of Ubuntu on a laptop or PC should work with this guide just fine.
Download the files first and then open Terminal to input our commands.
Download: http://cdimage.ubuntu.com/ubuntu-core/daily/current/raring-core-armhf.tar.gz
(You may optionally choose any date time from the Ubuntu-core folders. Ensure you are using the armhf tar.gz file.
Download (Recommended): https://www.dropbox.com/s/dqn9aa94oeju9kf/modules.tar.gz
Alternate Download: http://goo.im/dev/x3maniac/mod_firm_ext.zip
Alternate Download: http://www.novaspirit.com/downloads/mod_firm_ext.zip
After the downloads are complete, open Terminal and let’s get the image built!
A side note, I did not know that using ~ represented the user folder so if you do great, if not it will help you understand that /home/thomas can be represented using ~. So any subfolders of /home/thomas are included using the ~. I will specify my full paths and you can substitute the directories you wish to use. (Linux is still new to me too, I know enough to be dangerous!)
1. mkdir /home/thomas/images/ubuntu-raring
2. cd /home/thomas/images/ubuntu-raring
3. sudo apt-get install qemu
4. sudo apt-get install qemu-user-static
5. Now type this command: qemu-img create raring.img 200M
a.The Ubuntu Raring core image is approximately 186MB. So you understand at 186MB you only have 14MB available of extra stuff you can put into the image. You can resize up later but never down. You may specify any MB size you wish to use for the image. Experiment later, for now just make it 200M.
6. fdisk raring.img (you will see an error about invalid flag, this is ok, step 7 below is w for write, do proceed to step 7)
7. Type w to quit
8. Determine the file system you want (I used ext4)
a. Now type: mkfs.ext4 raring.img (according to config file of Tubuntu app, the partition is set up as ext3, you can use that as well)
b. A warning that your image is not a block special device (when choosing ext4) hit Y to proceed.
c. From /Ubuntu-raring directory type: mkdir mount
9. Now type: sudo mount –o loop ./raring.img ./mount
10. Now type: cd mount
10a. Now type: ls (you are only listing the mount directory to verify you have the lost+found directory) Go up one directory to /home/thomas/images/ubuntu-raring
11. Now type: cp /home/thomas/Downloads/raring-core-armhf.tar.gz /home/thomas/images/ubuntu-raring
12. Now type: sudo tar xvvf raring-core-armhf.tar.gz –C ./mount (you should not be in the mount directory)
13. Now type: sudo tar xvvf modules.tar.gz -C ./mount (you should not be in the mount directory)
14. sudo cp /usr/bin/qemu-arm-static /home/thomas/images/ubuntu-raring/mount/usr/bin (enter)
15. Now type: sudo chroot mount (if successful you will see /#)
16. Now type: passwd and make a password and confirm it.
17. Now type: exit
18. Now type: sudo umount ./mount
19. You should now be in the /home/thomas/images/ubuntu-raring/ directory. From here use the ls command and see your raring.img file.
20. You will need to copy this file your Windows box and use the Tubuntu installation application OR wheelie and nvflash commands. (Wheelie and nvflash commands are for more advanced users).
21. Click on this link for the next guide: http://forum.xda-developers.com/showthread.php?p=37803357
Hi, I have no problems creating the image and mounting it. But when chrooted:
apt-get update
0% [Working]qemu: Unsupported syscall: 374
Err http://ports.ubuntu.com raring Release.gpg
Something wicked happened resolving 'ports.ubuntu.com:80' (-11 - System error)...
I am on Ubuntu 12.10 64-bit. What could it be? qemu & qemu-user-static installed, qemu-arm-static copied...
Thank you and sorry for my CZ-english
onmail said:
Hi, I have no problems creating the image and mounting it. But when chrooted:
apt-get update
0% [Working]qemu: Unsupported syscall: 374
Err http://ports.ubuntu.com raring Release.gpg
Something wicked happened resolving 'ports.ubuntu.com:80' (-11 - System error)...
I am on Ubuntu 12.10 64-bit. What could it be? qemu & qemu-user-static installed, qemu-arm-static copied...
Thank you and sorry for my CZ-english
Click to expand...
Click to collapse
I need to update my guide. After the image is created on your Linux box you then install it on your tablet using tubuntu application. From the tab is where you run apt get commands. Sorry about that.
Sent from my SGH-T999 using Tapatalk 2
TomTcom said:
I need to update my guide. After the image is created on your Linux box you then install it on your tablet using tubuntu application. From the tab is where you run apt get commands. Sorry about that.
Sent from my SGH-T999 using Tapatalk 2
Click to expand...
Click to collapse
Oh, I see, but I think I will not be able to install apt-utils wpasupplicant if the wlan0 adapter is not working (I mean when wpasupplicant is not installed in the image).
onmail said:
Oh, I see, but I think I will not be able to install apt-utils wpasupplicant if the wlan0 adapter is not working (I mean when wpasupplicant is not installed in the image).
Click to expand...
Click to collapse
Yes you will because the core image has everything you need except the supplicant. You can make your own supplicant or copy from your working dual booted prime image of android. Let me try and update the guide later tonight.
Sent from my SGH-T999 using Tapatalk 2
onmail said:
Oh, I see, but I think I will not be able to install apt-utils wpasupplicant if the wlan0 adapter is not working (I mean when wpasupplicant is not installed in the image).
Click to expand...
Click to collapse
Ok, made several changes to my guide. Here's a couple things to note in case you missed them.
1. This guide helps you make an image of Raring Ubuntu-Core. This means there is no GUI and an additional post I have linked to for installing Gnome-Core (your actual desktop environment) for Raring.
2. After the Raring.img is made, you need to start on the Raring Gnome-Core guide and follow those instructions. That installation takes about 2 hours to download and answer questions because it is such a core install.
3. About the wifi, you will be using x3maniac's Tubuntu Windows installation application and starting from fresh with Prime Android and your new Raring image and if you follow the second guide it will walk you through setting up your wifi (do make sure you boot into Prime Android and set up your wifi first before booting to Raring.
4. Please familiarize yourself with the OP I have linked to for the x3maniac Tubuntu application.
It's not as hard as it may seem. After you do it a few times it's rather quick. Installing gnome-core by yourself is kind of slow and a bit tedious but the purpose of doing this was to have complete control of your image.
Later on if you are brave you can also build your own kernel as well and make changes. See my guide in my xda signature.
Hope this helps, thanks for using my guide. Hit the thanks button a couple of times and I'll make sure you get up and running.
TomTcom said:
Ok, made several changes to my guide. Here's a couple things to note in case you missed them.
1. This guide helps you make an image of Raring Ubuntu-Core. This means there is no GUI and an additional post I have linked to for installing Gnome-Core (your actual desktop environment) for Raring.
2. After the Raring.img is made, you need to start on the Raring Gnome-Core guide and follow those instructions. That installation takes about 2 hours to download and answer questions because it is such a core install.
3. About the wifi, you will be using x3maniac's Tubuntu Windows installation application and starting from fresh with Prime Android and your new Raring image and if you follow the second guide it will walk you through setting up your wifi (do make sure you boot into Prime Android and set up your wifi first before booting to Raring.
4. Please familiarize yourself with the OP I have linked to for the x3maniac Tubuntu application.
It's not as hard as it may seem. After you do it a few times it's rather quick. Installing gnome-core by yourself is kind of slow and a bit tedious but the purpose of doing this was to have complete control of your image.
Later on if you are brave you can also build your own kernel as well and make changes. See my guide in my xda signature.
Hope this helps, thanks for using my guide. Hit the thanks button a couple of times and I'll make sure you get up and running.
Click to expand...
Click to collapse
OK, thanks a lot, I will try. I have been playing with Tubuntu for some weeks and now I just started playing with building the image (and thinking about kernel...). Just now I am on Lubuntu (with xfce4 which I prefer) with 2.6 kernel and I am trying on my son's TF101 Raring with Gnome and 3.1 kernel. I am just thinking about the possibility when one system is "fine tuned" if it would be possible to copy it from one TF to the other one (I mean just the Linux partition).
onmail said:
Hi, I have no problems creating the image and mounting it. But when chrooted:
apt-get update
0% [Working]qemu: Unsupported syscall: 374
Err http://ports.ubuntu.com raring Release.gpg
Something wicked happened resolving 'ports.ubuntu.com:80' (-11 - System error)...
I am on Ubuntu 12.10 64-bit. What could it be? qemu & qemu-user-static installed, qemu-arm-static copied...
Thank you and sorry for my CZ-english
Click to expand...
Click to collapse
Replying to my own post because I must say - sorry, I am ehm an idiot... Because the only problem was - I have not edited the /etc/resolv.conf in the mount/etc directory. So now I can easily apt-get anything in the chroot! So it seems I can easily "prepare" an image with everything inside
onmail said:
Replying to my own post because I must say - sorry, I am ehm an idiot... Because the only problem was - I have not edited the /etc/resolv.conf in the mount/etc directory. So now I can easily apt-get anything in the chroot! So it seems I can easily "prepare" an image with everything inside
Click to expand...
Click to collapse
Did it work? I couldn't not without finding a way to inject VI into the image for editing the file. You can mess with permissions but it ultimately doesn't work from the Linux box.
If you are able to do it without the tab, post the instructions and I'll add it to my OP and give you the credit.
Sent from my SGH-T999 using Tapatalk 2
TomTcom said:
Did it work? I couldn't not without finding a way to inject VI into the image for editing the file. You can mess with permissions but it ultimately doesn't work from the Linux box.
If you are able to do it without the tab, post the instructions and I'll add it to my OP and give you the credit.
Sent from my SGH-T999 using Tapatalk 2
Click to expand...
Click to collapse
It works I am just in the middle of installing xubuntu-desktop... I have made a quick & dirty bash script which will help to set hostname for the new TF101, root password, make a new user with password and add him to sudo group, automatically enable all the deb repos (universe etc.), set cpu freqs in rc.local and install some usefull utils (sudo cpufrequtils bash-completion wpasupplicant nano mc net-tools). And there is a second script you can run on the first run on TF101 which will resize the linux partition to its limit, copy the wpa_supplicant.conf from the android partition and starts wlan0 I will send this to you asap but will test this first. Hope my English is understandable
onmail said:
It works I am just in the middle of installing xubuntu-desktop... I have made a quick & dirty bash script which will help to set hostname for the new TF101, root password, make a new user with password and add him to sudo group, automatically enable all the deb repos (universe etc.), set cpu freqs in rc.local and install some usefull utils (sudo cpufrequtils bash-completion wpasupplicant nano mc net-tools). And there is a second script you can run on the first run on TF101 which will resize the linux partition to its limit, copy the wpa_supplicant.conf from the android partition and starts wlan0 I will send this to you asap but will test this first. Hope my English is understandable
Click to expand...
Click to collapse
Xubuntu on raring is working without any problems. Now I would like to get the nvidia accelerated drivers working. I have tried 2 or 3 3.1 kernels but still without success. Googling for some help on compiling 3.1 kernel.
onmail said:
Xubuntu on raring is working without any problems. Now I would like to get the nvidia accelerated drivers working. I have tried 2 or 3 3.1 kernels but still without success. Googling for some help on compiling 3.1 kernel.
Click to expand...
Click to collapse
Awesome! If you go to the op for x3maniac, you can view his github that has 3.1 kernel source. Take a look and see of it helps.
Sent from my SGH-T999 using Tapatalk 2
TomTcom said:
Awesome! If you go to the op for x3maniac, you can view his github that has 3.1 kernel source. Take a look and see of it helps.
Sent from my SGH-T999 using Tapatalk 2
Click to expand...
Click to collapse
By the way, I have instructions for compiling the 2.6.36 kernel in my xda signature if that helps you.
Sent from my SGH-T999 using Tapatalk 2
TomTcom said:
By the way, I have instructions for compiling the 2.6.36 kernel in my xda signature if that helps you.
Sent from my SGH-T999 using Tapatalk 2
Click to expand...
Click to collapse
Yes, I know, I have already checked that. The 2.6 kernel is ok but I would really like to see the nvidia drivers working...
Had an issue mounting raring.img in step 9, had to run sudo fsck.ext4 "path to file" afterwards it mounted smoothly, dont know why tho.
JoinTheRealms said:
Had an issue mounting raring.img in step 9, had to run sudo fsck.ext4 "path to file" afterwards it mounted smoothly, dont know why tho.
Click to expand...
Click to collapse
Hmmm...did step 8a work ok?
Sent from my SGH-T999 using Tapatalk 2
TomTcom said:
Hmmm...did step 8a work ok?
Sent from my SGH-T999 using Tapatalk 2
Click to expand...
Click to collapse
Afaik it did, gave me the mentioned prompt, and finished without error. Might have something to do with me running a x64 vm ? as i wasnt able to chroot either. Im trying to get this running on my tf300t, but its alot different to installing it on the trusty tf101
Cheers for the guide tho, help me understand the whole process :good:
JoinTheRealms said:
Afaik it did, gave me the mentioned prompt, and finished without error. Might have something to do with me running a x64 vm ? as i wasnt able to chroot either. Im trying to get this running on my tf300t, but its alot different to installing it on the trusty tf101
Cheers for the guide tho, help me understand the whole process :good:
Click to expand...
Click to collapse
I believe our dev x3 mentioned there were differences on a VM so it probably has to do with that.
Glad the guide is helpful. Welcome!
Sent from my SGH-T999 using Tapatalk 2
Nice guide ! I just crated a 13.04 raring img. ( Used VM Kubuntu 12.04 )
Need some updates but nice
And there is a problem with actual release, wpa supplicant is not pre installed and now I'm in the begining of your second guide and cant set up wifi.
I had to download package with chroot, then install with my tab same for nano
Anyway, it's just FYI I dont really need help
Kingzak34 said:
Nice guide ! I just crated a 13.04 raring img. ( Used VM Kubuntu 12.04 )
Need some updates but nice
And there is a problem with actual release, wpa supplicant is not pre installed and now I'm in the begining of your second guide and cant set up wifi.
I had to download package with chroot, then install with my tab, and now it doesnt find iwlan0
Anyway, it's just FYI I dont really need help
Click to expand...
Click to collapse
This guide wasn't designed to use wifi, only to correctly package it for flashing 13.04 directly to the tab. The next guide adds the gui and requires your Android to be set up to copy over the wpa_supplicant file before executing those commands.
Onmail was able to script more changes to the image from "chroot" but I didn't go that far, he was able to get the supplicant and other abilities such as adding to the package better than I did.
This is a guide about getting a Linux distribution up and running on your Nexus 9. The goal of this thread is to give a basic understanding about how to get a basic system running, but not working throughout all the kinks that come with doing so on tablet style hardware.
This guide will be non-destructive, and won't touch the data on your tablet. Unless of course you've yet to unlock your bootloader, which if that is the case then shame on you.
Some prerequisites before starting this project with your Nexus 9
A Linux distribution running on your computer. Either in a virtual machine or as your main OS.
A USB flash drive
USB OTG cable
Some things that are nice to have
USB hub
USB keyboard
USB mouse
USB network card
Headphone UART cable
A brief overview about what we are going to be doing here.
First we are going to be building an initramfs. This is a small filesystem with a bare minimum set of tools that can be loaded in to RAM space and use. We will be using this while we are initially getting our kernel up and running, to make sure we didn't mess anything up.
Next we will move on to building the actual kernel for the device. We will be running a Android kernel since Nvidia hasn't been the quickest on their attempt to upstreaming everything required to run this device on a upstream Linux kernel. So we'll be running a 3.10 kernel, which is a heck of a lot better than some 3.0 or 3.4 thing that older devices are on.
Third we will be building our rootfs that will run from an external USB storage device, so we don't affect any data actually on the tablet. I may also add to the guide how to partition your internal storage space so we can use that instead.
[Step 0/4]
We need to set up our build environment on our host Linux distribution before we begin anything. I'm going to assume that the host Linux system we are running is Debian/Ubuntu based, so we'll be using apt to grab our packages we need.
Code:
sudo apt-get install gcc g++ git gcc-4.9-aarch64-linux-gnu g++-4.9-aarch64-linux-gnu libncurses5-dev
This installs the host gcc and AArch64 cross compiler, along with git. We will need these tools to build everything required.
Things that don't work.
Rebooting
Touchscreen
Way more things that people care about
The first step that we will be doing is building our filesystem that we will load in to memory for testing.
This is typically called an initramfs, which tends to be a compressed filesystem that gets copied in to a kernel image once the kernel is built. We won't be using this image for long, as it is mostly to make sure we have everything working correctly before jumping to a full linux distribution.
This step is technically unnecessary, but it brings you up to speed with what initially needs to be done to get something running.
So starting off, we are going to need to pick a target for the filesystem. I've decided to go with buildroot since it is a project that is really easy to get built.
Steps Overview
Clone buildroot with git
Setup buildroot to cross compile
Set up basic options
Compile!
1)*Clone buildroot from github.
Code:
git clone https://github.com/buildroot/buildroot.git
cd buildroot
2)*Start configuring buildroot
Code:
make menuconfig
This will bring up a menu for determining how we want to build our buildroot. We have quite a few things to change.
These options enable building an AArch64 capable buildroot using the Linaro AArch64 toolchain, with it outputting a terminal to ttyFIQ0 which is the headphone UART terminal. Along with taking the filesystem and pushing it in to a cpio archive which later the linux kernel understands how to use.
Target options->Target Architecture->AArch64
Toolchain->Toolchain type->External toolchain
External toolchain automatically enables the Linaro AArch64 toolchain below it.
System configuration->getty options->TTY port->ttyFIQ0
Filesystem images->cpio the root filesystem
3)*Build the buildroot
Code:
make
This will go through downloading all the packages required to build an AArch64 buildroot. So go make a cup of tea, this should only take a few minutes depending on your internet speed and computer speed.
Once the system has gone through compiling everything, then you'll have a file available.
This file will end up in the `output/images/` folder as the file 'rootfs.cpio'. If that file isn't there then something terrible has happened.
If the file is there, then everything on this step is done! We built our temporary filesystem which we will be putting to use in the next step!
This is really the meat of the guide. Building the kernel correctly is half the battle with running a full Linux distribution on the device. We are going to be pulling our kernel from the official Android repository and changing the default configuration to suit our needs.
Steps Overview
Clone kernel with git
Configure environment for cross-compiling
Configure the kernel for building correctly
Test run kernel
1) Clone the kernel using git
This step will take quite a bit of time since it is fairly large.
Code:
git clone https://android.googlesource.com/kernel/tegra.git
cd tegra
2)*Checkout the correct branch
Code:
git checkout android-tegra-flounder-3.10-lollipop-release
3)*Set environment variables for cross-compiling the Linux kernel
Code:
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
4) Configure the kernel
Code:
make flounder_defconfig
make menuconfig
This will bring up a menu just like how the buildroot menu came up. We need to set a few options to make sure everything comes up correctly on the Nexus 9.
General setup->Cross-compiler tool prefix->aarch64-linux-gnu-
General setup->Initramfs source file(s)-><The cpio file that was built in the buildroot>
Mine was '/home/ryanh/work/N9_Kernel_Tutorial/buildroot/output/images/rootfs.cpio'
Device Drivers->Character devices->Virtual Terminal
Device Drivers->Generic Driver Options->Maintain a devtmpfs filesystem to mount at /dev
Device Drivers->Generic Driver Options->Automount devtmpfs at /dev...
Device Drivers->Network device support->Wireless LAN->Firmware path->/lib/firmware/fw_bcmdhd.bin
Device Drivers->Network device support->Wireless LAN->NVRAM path->/etc/wifi/bcmdhd.cal
Device Drivers->Character devices->Virtual terminal
Device Drivers->Watchdog Timer Support->Tegra watchdog (Disable it)
Device Drivers->Staging drivers->Android->Put the FIQ debugger into console mode by default
Device Drivers->Graphics support->Tegra Framebuffer driver
Device Drivers->Graphics support->Console display driver support->Framebuffer Console support
Device Drivers->Graphics support->Console display driver support->Map the console to the primary display device
Device Drivers->Graphics support->Console display driver support->Framebuffer Console Rotation
We've got to enable the tegra watchdog otherwise the device will reboot automatically every two minutes.
The few other things are needed for a sane Linux environment and also setting the initramfs file as our root filesystem.
5)*Compile the kernel
Code:
make -j5
If you're lucky it will build without error and you'll have a file in 'arch/arm64/boot/' named 'Image.gz-dtb' which is the final kernel file.
With this file we should be able to boot a kernel with a buildroot automatically mounted.
Test run the kernel!
This is where I recommend having your headphone UART cable, because this won't update the screen at all and it will seem like it has locked up. The cable is fairly easy to make with a little bit of know how about soldering and electronics, and will save you from tearing out your hair trying to figure out what went wrong.
Without the cable you won't be able to see any output, so either build the cable or skip this step.
To see output from the cable you need to connect to it with either gnu screen or minicom
Code:
sudo screen /dev/ttyUSB0 115200
To boot the kernel reboot in to the bootloader and then boot the kernel using fastboot
Code:
adb reboot bootloader
fastboot -c "console=ttyFIQ0,115200n8 rw" boot arch/arm64/boot/Image.gz-dtb
Once you do this, over the UART cable you'll see the Linux kernel booting and have a buildroot login terminal.
The default username is 'root' without any password.
Code:
Welcome to Buildroot
buildroot login: root
# uname -a
Linux buildroot 3.10.40-ga3846f1 #2 SMP PREEMPT Sat Dec 27 06:15:13 CST 2014 aarch64 GNU/Linux
This shows that the kernel is booting properly and jumping in to our buildroot correctly.
To go back in to Android from this area just type reboot in to the terminal instance.
The final step in getting a Linux distro is to build our root filesystem on a USB flash drive.
Steps Overview
Format flash drive as ext2/ext3/ext4
Dump Ubuntu rootfs on to the flash drive
Minor configuration
Rebuild Linux kernel with new options
The first thing we will want to be doing is formatting a flash drive to a Linux partition type. I am going to be using an ext3 partition on a 64GB USB 3.0 flash drive. I'd recommend at least an 8GB flash drive, anything smaller may have issues with fitting everything on to it.
Once you're done flashing your drive you'll need to download an Ubuntu Core image for AArch64/ARM64/ARMv8.
Download the Ubuntu Core 14.04.1 image*Here. Make sure to grab the 'arm64' tar.gz file, not the 'amd64' file.
Once you have the flash drive formatted and mounted, extract the ubuntu core image to the flash drive.
Code:
sudo tar zxf ubuntu-core-14.04.1-core-arm64.tar.gz -C Mount/
Configuring the Ubuntu Core image for the Nexus 9
Steps Overview
Terminal over UART configuration
DNS configuration
Firmware files
Add user
In order to properly get a terminal instance over the UART we have to add a package to the base Ubuntu core image.
This is a small package that all it does is open a new terminal instance over the configured getty instance. The package can be found*Here.
To install it to the root filesystem just unpack it to the root filesystem on the USB flash drive
Code:
sudo tar xf console.tar -C Mount/
We need to set up a DNS server so that the filesystem will be able to resolve addresses via DNS.
Let's just set it to Google's DNS.
Code:
sudo echo 'nameserver 8.8.8.8' >> Mount/etc/resolv.conf
We've got to grab the firmware files from the Nexus 9 in order for the device to stop spamming warnings at us in the console.
These are used for multiple things, so it is a good idea to grab them. You can grab these either from a factory image or directly from the Nexus 9. I chose to grab mine directly from the Nexus 9.
Code:
sudo mkdir Mount/lib/firmware
sudo mkdir Mount/etc/wifi
sudo adb pull /vendor/firmware Mount/lib/firmware/
sudo adb pull /system/etc/wifi/bcmdhd.cal Mount/etc/wifi/
We need to add a user to the root filesystem. This is a fairly annoying step because we actually need to chroot in to the filesystem.
There is a really nice guide to doing this on a ARMv7 filesystem*Here. This won't work for our system because we are working with ARMv8 instead.
So we are going to use that guide as a base but change it over to support what we need to do for AArch64.
First thing we've got to do is build qemu as a static binary for AArch64
This is fairly straight forward.
Code:
git clone git://git.qemu-project.org/qemu.git
cd qemu
sudo apt-get build-dep qemu
./configure --target-list=aarch64-linux-user *--static --disable-werror
make -j5
This will get us a binary in the aarch64-linux-user folder called 'qemu-aarch64'
We will need to rename this to 'qemu-arm64-static' and move it in to the '/usr/bin/' folder inside of our root partition
Once qemu is inside of the root partition, we will be able to chroot in to it and add our user.
So go in to the root directory of our filesystem we are generating, and run a few basic commands.
Set up some mounts inside of the chroot
Code:
for m in `echo 'sys dev proc'`; do sudo mount /$m ./$m -o bind; done
*Chroot in to the root filesystem
Code:
sudo LC_ALL=C chroot . /bin/bash
Now we are inside of the root filesystem, we can add the new user to it.
Let's just add a new user named 'ubuntu'. The first command will ask for a password for your user. The rest will add it to some default groups to make sure it can do things.
Code:
adduser ubuntu
addgroup ubuntu adm
addgroup ubuntu sudo
Once the user is added you can exit the root filesystem with a regular exit command, then we have to make sure to unmount all of the mounts we did prior to chrooting in to the filesystem.
Code:
for m in `echo 'sys dev proc'`; do sudo umount ./$m; done
Make sure to cleanly unmount the flash drive so everything is written to it.
Reconfigure the kernel to boot from flash drive instead of initramfs
1)*Go in to the kernel configuration
Code:
make menuconfig
Change the configuration to remove the initramfs
General Setup->Initial RAM filesystem and RAM disk (initramfs/initrd) support (Disable it)
Then exit the menu and rebuild the kernel
Code:
make -j5
Running the Ubuntu Core Image
So with the device sitting at the bootloader we will need to boot the new kernel
Code:
fastboot -c "fbcon=rotate:1 root=/dev/sda1 rootwait rw" boot arch/arm64/boot/Image.gz-dtb
This will boot the kernel and then it'll wait until you plug in the flash drive to continue booting.
So plug the USB hub in to the USB OTG cable. Then plug your USB flash drive and USB keyboard in to the USB hub.
After that plug the USB OTG cable in to the tablet and it will continue booting.
Give it roughly 20-60 seconds and it will show a login prompt on the devices screen.
You'll be able to login to the core image with the user you created earlier.
With some packages installed like the xubuntu-desktop environment you can have a full desktop available.
Reserved for QA - Additional Information - Misc
Information
Hardware acceleration
Potentially hardware acceleration should be possible using the Nouveau video driver. This is completely untested, and the Nouveau version included with Ubuntu 14.04 isn't new enough to have GK20a support. One would most likely need to build Nouveau from ToT to get support.
Known Issues
If something tries enabling the wifi chipset then the kernel will hardlock and cause the device to reboot. It may be best to disable the broadcom driver in the kernel until that is figured out.
Bluetooth doesn't seem to work. Not sure why not. Seems to show up as a device, but it can't be used.
Wow thanks for taking the time to post this tuturial.
Greatly apriciated.
Nice work, excellent writeup.
Cant wait to try!!
---------- Post added at 08:35 PM ---------- Previous post was at 08:31 PM ----------
Where did you get your headphone UART cable
Great work sonic, been waiting for this. Will try and report back.
I took some time to figure out how to fix the integrated wireless LAN in the tablet.
This requires grabbing an additional file from the tablet and configuring a few kernel options so they know where the new file locations are since previously they are configured to Android specific locations.
Seems to work fine on my 802.11n 2.4Ghz network.
Running into a snag while compiling the kernel. It always fails at this exact spot on Ubuntu 14.10. Any ideas? (first time compiling a kernel from source )
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
farmerbb said:
Running into a snag while compiling the kernel. It always fails at this exact spot on Ubuntu 14.10. Any ideas? (first time compiling a kernel from source )
Click to expand...
Click to collapse
Note: that does not tell me what failed
When the build failes can you do
Code:
make
Then give me the output
USBhost said:
Note: that does not tell me what failed
When the build failes can you do
Code:
make
Then give me the output
Click to expand...
Click to collapse
OK, here's what failed. Looks like an error in qcom_usb_modem_power.c:
Looks like it's having a fit in a required module that is enabled for the tegra platform.
Looks like a new warning that has cropped up in a newer version of GCC? My AArch64 gcc version that I'm running is 4.8.2. I can install 4.9.1 and test there but it will have to be later.
GCC is definitely right in this case though, Qualcomm managed to screw up a basic memset function call. The zero is supposed to be the middle argument, and GCC recognizes it as an warning now. Which gets upgraded to an error with some configuration.
If you know light C/C++ you can change those two lines that it is complaining about to be correct.
Should be
memset(modem->ftrace_cmd, 0, sizeof(modem->ftrace_cmd));
and
memset(modem->msr_info_list, 0, sizeof(modem->msr_info_list));
For those two lines at 1912 and 1915 respectively.
Looks like I'm going to have to start a patch set for this to work around Qualcomm failing.
sonicadvance1 said:
Looks like it's having a fit in a required module that is enabled for the tegra platform.
Looks like a new warning that has cropped up in a newer version of GCC? My AArch64 gcc version that I'm running is 4.8.2. I can install 4.9.1 and test there but it will have to be later.
GCC is definitely right in this case though, Qualcomm managed to screw up a basic memset function call. The zero is supposed to be the middle argument, and GCC recognizes it as an warning now. Which gets upgraded to an error with some configuration.
If you know light C/C++ you can change those two lines that it is complaining about to be correct.
Should be
memset(modem->ftrace_cmd, 0, sizeof(modem->ftrace_cmd));
and
memset(modem->msr_info_list, 0, sizeof(modem->msr_info_list));
For those two lines at 1912 and 1915 respectively.
Looks like I'm going to have to start a patch set for this to work around Qualcomm failing.
Click to expand...
Click to collapse
I made the changes to qcom_usb_modem_power.c as you listed, and got the kernel to compile okay.
Starting from a fresh Ubuntu 14.10 install (inside a VM), I ended up installing these additional packages in addition to the ones you list in step 0:
Code:
libncurses5-dev libc6:i386 libstdc++6:i386 zlib1g:i386 qemu binfmt-support qemu-user-static android-tools-adb android-tools-fastboot
To get the kernel to compile, I also needed to symlink aarch64-linux-gnu-gcc-4.9 to aarch64-linux-gnu-gcc in /usr/bin, for make to recognize the correct gcc program.
But anyway, I've gotten my N9 booted to the Ubuntu login prompt Now I just need to grab a USB keyboard so that I can actually login!
Thanks so much for the guide! Can't wait for MultiROM to be ported to our device, to make this easier to boot
farmerbb said:
I made the changes to qcom_usb_modem_power.c as you listed, and got the kernel to compile okay.
Starting from a fresh Ubuntu 14.10 install (inside a VM), I ended up installing these additional packages in addition to the ones you list in step 0:
Code:
libncurses5-dev libc6:i386 libstdc++6:i386 zlib1g:i386 qemu binfmt-support qemu-user-static android-tools-adb android-tools-fastboot
To get the kernel to compile, I also needed to symlink aarch64-linux-gnu-gcc-4.9 to aarch64-linux-gnu-gcc in /usr/bin, for make to recognize the correct gcc program.
But anyway, I've gotten my N9 booted to the Ubuntu login prompt Now I just need to grab a USB keyboard so that I can actually login!
Thanks so much for the guide! Can't wait for MultiROM to be ported to our device, to make this easier to boot
Click to expand...
Click to collapse
ii cant wait
Excellent guide. Thank you very much.
It appears the "*" in this configure command below may be a typo?
sonicadvance1 said:
Code:
git clone git://git.qemu-project.org/qemu.git
cd qemu
sudo apt-get build-dep qemu
./configure --target-list=aarch64-linux-user *--static --disable-werror
make -j5
Click to expand...
Click to collapse
Anyway, I am running into a more serious issue (Problem resolved. See bottom.) executing dynamically build aarch64 binaries. On my 14.10 x86 machine, I am able to execute statically build aarch64 binaries using my new qemu-aarch64 emulator. I am not able to execute dynamically build aarch64 binaries. For instance, when I try to execute bin/bash from the mounted root filesystem directly on the host, it will complain:
/lib/ld-linux-aarch64.so.1: No such file or directory
Now this is all right, because I don't have the required aarch64 shared libs on my x86 machine. So I copied qemu-aarch64 to /usr/bin/qemu-aarch64-static on the mounted root filesystem. However, when I run chroot (executing the same /bin/bash):
sonicadvance1 said:
Code:
sudo LC_ALL=C chroot . /bin/bash
Now we are inside of the root filesystem, we can add the new user to it.
Click to expand...
Click to collapse
...I am getting this:
chroot: failed to run command ‘/bin/bash’: No such file or directory
I think this is due to the same issue as above: that qemu is looking for aarch64 shared libs (/lib/ld-linux-aarch64.so.1 is needed to run bash) on my host machine. Should it not, due to chroot, look for them in the mounted root filesystem (where they actually are)?
Other than this... my ARM64 kernel is booting fine. The only problem is, that I cannot login to it yet, because I wasn't able to add a new user.
Edit: Interestingly, the following "works":
Code:
$ sudo chroot . usr/bin/qemu-aarch64-static /bin/bash
bash: /usr/bin/groups: No such file or directory
[email protected]:/#
Now inside the chroot running the aarch64 variant of /bin/bash, I am still unable to start any aarch64 executables. But tab-completion works and I am able to find and run /usr/bin/qemu-aarch64-static (the x86 binary). Could this be a problem with any binfmts mappings inside chroot? Odd.
Edit 2: Solved. Just tried from another machine (10.04) and here, everything is working perfectly. I probably have chroot hosed on my 1st machine. Excellent guide. One last note: if you don't have qemu installed on your host machine, you may need to run the following:
Code:
sudo apt-get install qemu binfmt-support qemu-user-static
t1mur said:
Excellent guide. Thank you very much.
It appears the "*" in this configure command below may be a typo?
Anyway, I am running into a more serious issue executing dynamically build aarch64 binaries. On my 14.10 x86 machine, I am able to execute statically build aarch64 binaries using my new qemu-aarch64 emulator. I am not able to execute dynamically build aarch64 binaries. For instance, when I try to execute bin/bash from the mounted root filesystem directly on the host, it will complain:
/lib/ld-linux-aarch64.so.1: No such file or directory
Now this is all right, because I don't have the required aarch64 shared libs on my x86 machine. So I copied qemu-aarch64 to /usr/bin/qemu-aarch64-static on the mounted root filesystem. However, when I run chroot (executing the same /bin/bash):
...I am getting this:
chroot: failed to run command ‘/bin/bash’: No such file or directory
I think this is due to the same issue as above: that qemu is looking for aarch64 shared libs (/lib/ld-linux-aarch64.so.1 is needed to run bash) on my host machine. Should it not, due to chroot, look for them in the mounted root filesystem (where they actually are)?
Other than this... my ARM64 kernel is booting fine. The only problem is, that I cannot login to it yet, because I wasn't able to add a new user.
Edit: Interestingly, the following "works":
Code:
$ sudo chroot . usr/bin/qemu-aarch64-static /bin/bash
bash: /usr/bin/groups: No such file or directory
[email protected]:/#
Now inside the chroot running the aarch64 variant of /bin/bash, I am still unable to start any aarch64 executables. But tab-completion works and I am able to find and run /usr/bin/qemu-aarch64-static (the x86 binary). Could this be a problem with any binfmts mappings inside chroot? Odd.
Click to expand...
Click to collapse
I ran into these exact issues as well, and was eventually able to get the chroot working properly
Make sure you have the qemu, binfmt-support, qemu-user-static packages installed, and run 'update-binfmts --display' to ensure that aarch64 support is registered properly. Also make sure you've named the 'qemu-aarch64' binary as 'qemu-arm64-static' (not 'qemu-aarch64-static') at usr/bin on the flash drive (the Ubuntu Core image recognizes its architecture as arm64, not aarch64)
farmerbb said:
I ran into these exact issues as well, and was eventually able to get the chroot working properly
Make sure you have the qemu, binfmt-support, qemu-user-static packages installed, and run 'update-binfmts --display' to ensure that aarch64 support is registered properly. Also make sure you've named the 'qemu-aarch64' binary as 'qemu-arm64-static' (not 'qemu-aarch64-static') at usr/bin on the flash drive (the Ubuntu Core image recognizes its architecture as arm64, not aarch64)
Click to expand...
Click to collapse
Ah... it's really good to know one isn't alone. Hehe. Well, it looks like 14.10 is better suited for compiling the arm kernel (gcc-4.9-aarch64 etc.), but doing the chroot is smoother on 14.04.
But how do I get wifi and/or USB ethernet up? And why do have to look at this?
unable to stat /etc/sudoers: no such file or directory
Did you get this too?
t1mur said:
Ah... it's really good to know one isn't alone. Hehe. Well, it looks like 14.10 is better suited for compiling the arm kernel (gcc-4.9-aarch64 etc.), but doing the chroot is smoother on 14.04.
But how do I get wifi and/or USB ethernet up? And why do have to look at this?
unable to stat /etc/sudoers: no such file or directory
Did you get this too?
Click to expand...
Click to collapse
I'm still working on getting networking and X.org running myself. It will recognize my ASIX USB adapter (in the dmesg log) but eth0 doesn't show up and 'ifconfig eth0 up' doesn't work. Haven't tried Wi-Fi yet. My low-level Linux knowledge isn't all that great However, I can still chroot back into the filesystem on my PC and update/install packages, etc. in the meantime.
No I don't see the /etc/sudoers error.