Related
This is about booting Ubuntu natively on the DHD. (without chroot and without an Andriod running at the same time)
Based on the version for the HTC HD2
{
"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"
}
What works:
touchscreen (touchscreen works as touchpad) (thanks to Jhinta)
two finger scrolling (thanks to Jhinta)
Wifi
dragging windows (double click and holding second click)
right click (double two finger click) (thanks to dronf)
adb (thanks to torsrex)
incoming calls (thanks to liljom)
SMS (thanks to liljom)
What doesn't work:
sound
keys (hard and soft keys)
usb host
firefox (only as root)
Instructions:
Download ubuntu4dhd.zip
Download easy to use.zip
Put the linux folder from ubuntu4dhd.zip to the root of your sdcard
Put the easy to use folder to your windows PC
Bring your DHD into the bootloader
Connect DHD to the PC
Double click Start here.bat
Tip "fastboot boot boot.img"
(without ")
after restarting your old rom will start
Change log:
Working touchpad driver
two finger scrolling
Wifi working out of the box
Modifing the rootfs on your PC or virtualBox:
mkdir /ubuntuDHD
sudo mount -t ext2 -o loop /path/to/rootfs /ubuntuDHD
rootfs is now mounted under /ubuntuDHD and can be modifyed as root
umount /ubuntuDHD
Dual boot option:
Download two different cwm from Rom manager
Open the clockworkmod folder on you sdcard an open the download folder.
Search for the version number for the old recovery. You will find an image file, open the containing folder and copy the boot.img from the Ubuntu4DHD.rar into it.
Now, rename the boot.img file to the recovery image filename and deleted the old recovery.
Now, when you select the old recovery from Rom manager, it will flash the ubuntu boot image.
Booting into Recovery will now boot Ubuntu
When you want to go back to cwm, just select/flash the newer cwm version with Rom Manager.
Download:
Ubuntu4DHD.rar (reuploaded as rar)
MD5 of image: 79a9faa2d49725fb6bfdc30d4c5fb885
easy to use.zip
appendix:
easy to use.zip
with:
My boot.img
boot-usbhost.img (boot image with usb host support)
Tips:
Password: ubuntu
For porting to other devices
Chaosz-X said:
Hi,
I saw you got native Ubuntu up and running on the Desire HD, and I wanted to do the same with my Flyer. I know how to compile kernels and an Android build etc., but I can't figure out how to set the partitions, that the boot.img boots from a partition on the SD-card. So I was wondering if you could tell me, what modifications are made to your boot.img to make it boot from SD.
Thanks in advance!
Click to expand...
Click to collapse
Changes on the boot.img:
I guess you know how to extract a boot.img.
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
When you try split_bootimg with my boot.img you will find two things.
1) a special command line arguments
2) a complet other ramdisk image containing
2a) a busybox
2b) a init script
The commad line arguments refer to the init script in the ramdisk.
The init script mounts some partitions including the ubuntu "partition" (in this case a image file on the sd card".
For mounting the partitions the init script calls a other script called MAKEDEVS also based in the ramdisk image.
In this second script you need to change the major and minor numbers of the block devices to match your kernel/device.
Placing the ubuntu image on the sd card:
I use a image file on the sd card.
You could use following commands on a linux machine to edit the image.
mkdir /mnt/ubuntuimg
sudo mount -t ext2 -o loop,rw /pathToTheImage/rootfs.ext2 /mnt/ubuntuimg
Then you will see the content of the image in /mnt/ubuntuimg.
Don't forget to unmount.
umount /mnt/ubuntuimg
Edits on the kernel:
In the kernel the framebuffer must be activated to run ubuntu
make menuconfig
Device Driver->Character Devices-> Set Virtual Terminal
Device Driver->Graphics support->Console display driver support->Remove VGA Text console
Maybe same patches for the framebuffer are needed to use the framebuffer.
Some information can be found under:
http://forum.xda-developers.com/showthread.php?t=1008144&highlight=ubuntu
getting this working would be awesome, better than a working honeycomb possibly .
If this would be possible. DesireHD Can Dual boot. Thank-you
Sent from my Desire HD
If this ever works, is it possible to modify the normal Android system to allow a virtual environment within which you can run Ubuntu? That way you can have the benefits of both.
I think, I must not start my init script directly. Instead I shloud start it from within the init.rc.
But how?
raze599 said:
If this ever works, is it possible to modify the normal Android system to allow a virtual environment within which you can run Ubuntu? That way you can have the benefits of both.
Click to expand...
Click to collapse
See leedroids post on booting ubuntu through Android. A bit closer to what your looking for and working although a bit of experience would be needed.
But like another said. Dual boot Android and ubuntu should be possible if we can get this to boot.
Man if you do it, it will be exciting! Even better than working sense 3.0 Good luck!
twiztedvvv said:
See leedroids post on booting ubuntu through Android. A bit closer to what your looking for and working although a bit of experience would be needed.
But like another said. Dual boot Android and ubuntu should be possible if we can get this to boot.
Click to expand...
Click to collapse
Keep in mind this is native and not chroot !!!
1: Use the android init. It directly references init.rc
2: move your init script into init.rc
3: you have failed booting due to the system not knowing the executable paths;
you HAVE to export your paths. Either reference your binaries directly, for example:
/bin/mount, /bin/dosfsck
or
export PATH /bin:/sbin:/usr/bin:/usr/sbin
Furthermore, you need to diet your boot.img; 5Mb is not flashable on the DHD unless you move and resize the partition tables (risky). The stock max is 4Mb.
You can also force the kernel to execute the init script by referencing it in the kernel cmdline. Check this option in your kernel config and compile it with such support.
Good point. Got a bit lost in concentration
I would know about moving and resizing partitions :/ ended up reformatting completely.
MrYuiM said:
I would know about moving and resizing partitions :/ ended up reformatting completely.
Click to expand...
Click to collapse
I was writing about emmc partitions, not "sd".
1: Use the android init. It directly references init.rc
2: move your init script into init.rc
3: you have failed booting due to the system not knowing the executable paths;
you HAVE to export your paths. Either reference your binaries directly, for example:
/bin/mount, /bin/dosfsck
or
export PATH /bin:/sbin:/usr/bin:/usr/sbin
Furthermore, you need to diet your boot.img; 5Mb is not flashable on the DHD unless you move and resize the partition tables (risky). The stock max is 4Mb.
You can also force the kernel to execute the init script by referencing it in the kernel cmdline. Check this option in your kernel config and compile it with such support.
Click to expand...
Click to collapse
Thx
The init.rc script is a android specific script/script language, can i place a shell script into it?
adwinp said:
1: Use the android init. It directly references init.rc
2: move your init script into init.rc
3: you have failed booting due to the system not knowing the executable paths;
you HAVE to export your paths. Either reference your binaries directly, for example:
/bin/mount, /bin/dosfsck
or
export PATH /bin:/sbin:/usr/bin:/usr/sbin
Furthermore, you need to diet your boot.img; 5Mb is not flashable on the DHD unless you move and resize the partition tables (risky). The stock max is 4Mb.
You can also force the kernel to execute the init script by referencing it in the kernel cmdline. Check this option in your kernel config and compile it with such support.
Click to expand...
Click to collapse
1. kernel cmdline gets ignored rootdev will be NULL thats has to be fixed
2 moving init to int.rc no go as we want native ubuntu leaving init(android) will only boot android.
3 the reaseon it fails is that the kernel cant see mmcblk1 before cmdline ( why we have to find out )
So in sort kernel is oke but cmdline get igored, if we leave initrd enabled in kernel config its starts init ( android ) if not panic root not found here are partitions list of mmcblk0** root"NULL" not found <-- disableing initrd in kernel wel make root null because its wants to load initrd->init from ram witch is android binary elf init.
Step to take are making a initrd that will mount sdcard witch is mmcblk1 and mount it as rootdev if that works we can make a init.
So
1 we have to have a kernel thats has the correct cmdline as kernel config does not accept cmdline its will just be ignored.
2 have a initrd that that wil do a setup before starting init ( system setup mount pionts and so on)
3 build a init that will boot ubuntu and you done
1 we have to have a kernel thats has the correct cmdline as kernel config does not accept cmdline its will just be ignored.
Click to expand...
Click to collapse
Do you mean boot comandline parameters?
I makes a difference if I use
fastboot -c "init=/init rw consoleblank=0 fbcon=rotate:1" boot boot.img
or
fastboot -c "init=/init rw consoleblank=0" boot boot.img
bergfex said:
Do you mean boot comandline parameters?
I makes a difference if I use
fastboot -c "init=/init rw consoleblank=0 fbcon=rotate:1" boot boot.img
or
fastboot -c "init=/init rw consoleblank=0" boot boot.img
Click to expand...
Click to collapse
so finaly got a working system to test stuf .
first of all you got console of in the image that makes it hard for anyone els to see whats going on . AND the laste time ill say this kernel cmdline is skipt !!!!!!!!!! fastboot c = cmdline=kernel command line = kernel arguments bla bla bla.
its get skipt !!!! root= init= bla bla = will not work !!!!!
why we have to find out !!
enable console you have userspace on, there is nog log out so people cant see whats happening
My script in the initrd get started, but it has still an error in it.
Wait a moment, then i will upload the new boot.img
New boot.img starts the my script in the initrd
1) copy the linux folder from the hd2-ubuntu_0.3.zip in the root directory of your sdcard
2) fastboot boot boot.img
bergfex said:
New boot.img starts the my script in the initrd
1) copy the linux folder from the hd2-ubuntu_0.3.zip in the root directory of your sdcard
2) fastboot boot boot.img
Click to expand...
Click to collapse
this realy is working you got it almost ? what is your script maby i can help as far as ik can see sdcard doesnt gets mounted also can you get on htc-linux irc make typeing for me easyer takes long frome to even type this
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Difficulty: medium. No programming skills required, but not for noobs.
Ingredients
1 TF700T running a rooted stock-based ROM with busybox and a kernel with preinit support (hint: -that kernels work fine )
1 PC running Linux with a microSD card reader
1 fast microSD card with at least 4 GB
1 CyanogenMod 10.2 nightly ZIP (should also work for other ROMs - post your results)
1 seasoned chef
Time required: about 30 to 45 minutes.
Directions
Preheat oven to 220 degree celsius ... oops, wrong recipe.
If done right, the internal ROM and its data are perfectly safe. But I assume you have a backup nevertheless - don't blame me if anything goes wrong.
Prepare the microSD card
Insert microSD card into PC card reader. Using gparted, create and format 3 primary partitions:
p1: fat32, this will be your external sdcard as before.
p2: ext4, this will become /data
p3: ext4, this will become /system
Make sure to align the partitions to MiB, or even better multiples of 4 MiB. This may improve I/O performance.
In most cases you can simply shrink the existing FAT32 partition and then create the remaining ext4 partitions.
Partition 3 should be 700 to 800 MB - anything bigger is a waste of space, and anything smaller than 500 MB might cause problems.
Partition 2 will be your whole "internal storage" for the second operating system, so size it according to your storage needs for apps, app data and the emulated /sdcard.
I am using a Samsung 16 GB card with the following partition sizes:
p1: ~ 8 GB
p2: ~ 6 GB
p3: ~ 800 MB
Prepare the new ROM
Before installing the second ROM to the microSD card, the ZIP file must be slightly modified. I assume you know how to unpack and repack a ZIP file and how to use a text editor - if not, find a tutorial elsewhere. .
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
First, extract boot.blob and set it aside for later. Then carefully remove it from the ZIP. Second, find META-INF/com/google/android/updater-script and modify it:
Replace all occurrences of mmcblk0p1 with mmcblk1p3. I had 3 occurrences in CM's updater-script - make sure you modify all of them, otherwise your internal ROM might not survive the installation. This change will redirect the installation to the external microSD card. Finally, remove the line that says package_extract_file("boot.blob", ...) near the end - it would overwrite the kernel and we don't want that.
Now we need to add the WiFi modules. These are compiled directly into the CM kernel, but separate modules in the stock kernel.
Get the kernel modules from your running ROM - they are in /system/lib/modules (e.g. using adb pull /system/lib/modules), and copy at least these two into the ZIP into /system/lib/modules:
cfg80211.ko
bcmdhd.ko (note: for TF300, I think you need bcmdhd_29.ko instead)
Finally, repack the ZIP, mount the first partition of your microSD card and copy the ZIP file there.
Extract the ramdisk files
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
Here comes the tricky part. You need to extract the ramdisk from the boot.blob you saved from the ZIP file in the previous step.
To do that, you need tools that may not be in every household, but should be easy to find using your favorite search engine. In case you have trouble finding and/or compiling them, you can find the result of this step in post #2.
First we need to unpack the blob (https://github.com/AndroidRoot/BlobTools):
Code:
blobunpack boot.blob
This will create boob.blob.LNX. This is the boot image, from which we need to extract the ramdisk (https://github.com/huaixzk/unpackbootimg):
Code:
unpackbootimg -i boot.blob.LNX
This will create several files, we are interested in boot.blob.LNX-ramdisk.gz - copy this one to your tablet, e.g. into /sdcard. For example:
Code:
adb push boot.blob.LNX-ramdisk.gz /sdcard/
Prepare the preinit script and the ramdisk files
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
On the tablet, open a shell in a terminal app or use adb shell and become root (su). Run the following commands:
Code:
mount -o remount,rw /system
cd /system
mkdir boot
cd boot
mkdir rootfs_cm
cd rootfs_cm
gzip -d -c /sdcard/boot.blob.LNX-ramdisk.gz | cpio -i
The first line makes /system writable until the next reboot. The next few lines are self-explanatory. The last line uncompresses the ramdisk image we created in the previous step and extracts the contained files. We are doing this on the tablet itself to preserve the file permissions.
Now modify the file fstab.cardhu (one of the files just extracted).
Replace mmcblk0p1 with mmcblk1p3 and mmcblk0p8 with mmcblk1p2.
mmcblk0p2 can stay as it is, it's the /cache partition that is only used to communicate with the recovery.
Next we need to make sure the WiFi modules that we added are loaded at boot time. Edit init.cardhu.rc and find the "on boot" line. Add below (indentation is important):
Code:
insmod /system/lib/modules/cfg80211.ko
insmod /system/lib/modules/bcmdhd.ko
Near the end of init.cardhu.rc is another reference to mmcblk0p8 that needs to be modified to mmcblk1p2 - near "service setup_fs".
Finally create the file /system/boot/preinit with the following content:
Code:
#!/system/bin/sh
# preinit: only /sys and /system are mounted (ro), / is still rw
PATH=/sbin:/system/bin:/system/xbin
# auto-detect rom2sd
if [ -d /sys/block/mmcblk1/mmcblk1p3 ]; then
echo "\nsystem/boot/preinit: mmcblk1p3 detected, setting up for ROM2SD.\n"
cp -a /system/boot/rootfs_cm/* /
fi
Make sure to make it executable:
Code:
chmod 744 /system/boot/preinit
This script is run by the kernel before the real Android init. It. detects if a microSD card with 3 partitions is inserted, and if yes, it copies the files for the CM root filesystem into the ramdisk. The following Android boot procedure will then mount /system and /data to the partitions on the microSD card and the whole operating system will run from the microSD card. If no card is inserted, nothing is modified and the normal internal ROM is started.
Flashing the ROM
Insert your microSD card into the tablet, boot to TWRP and flash your modified ZIP as usual - but disable signature checking because we didn't sign the modified ZIP.
Recovery
The recovery doesn't know about the external ROM, so you can't use the recovery to backup or restore its system or data. I prefer using the PC for that anyway.
Booting
To boot from internal storage, make sure the microSD card is not inserted when you start the tablet (you can insert it as soon as the boot animation appears). To boot from the microSD card, make sure it is inserted before you turn the tablet on.
That's all. Add more microSD cards for triple-boot, quad-boot, etc.
Notes
My kernel currently has not enabled SELINUX in the config, but CM appears to work anyway.
Update: -that6 enables SELinux.
Shortcut
In case you don't want to extract the CM ramdisk from the blob yourself (or you have trouble finding/compiling the tools to do so), you can try using mine - from my unofficial build of cm-10.2-20131024: View attachment boot.blob.LNX-ramdisk.gz
Automated solution
See http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
(reserved for additions)
_that said:
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Difficulty: medium. No programming skills required, but not for noobs.
Ingredients
1 TF700T running a rooted stock-based ROM with busybox and a kernel with preinit support (hint: -that kernels work fine )
1 PC running Linux with a microSD card reader
1 fast microSD card with at least 4 GB
1 CyanogenMod 10.2 nightly ZIP (should also work for other ROMs - post your results)
1 seasoned chef
Time required: about 30 to 45 minutes.
Directions
Preheat oven to 220 degree celsius ... oops, wrong recipe.
If done right, the internal ROM and its data are perfectly safe. But I assume you have a backup nevertheless - don't blame me if anything goes wrong.
Prepare the microSD card
Insert microSD card into PC card reader. Using gparted, create and format 3 primary partitions:
p1: fat32, this will be your external sdcard as before.
p2: ext4, this will become /data
p3: ext4, this will become /system
Make sure to align the partitions to MiB, or even better multiples of 4 MiB. This may improve I/O performance.
In most cases you can simply shrink the existing FAT32 partition and then create the remaining ext4 partitions.
Partition 3 should be 700 to 800 MB - anything bigger is a waste of space, and anything smaller than 500 MB might cause problems.
Partition 2 will be your whole "internal storage" for the second operating system, so size it according to your storage needs for apps, app data and the emulated /sdcard.
I am using a Samsung 16 GB card with the following partition sizes:
p1: ~ 8 GB
p2: ~ 6 GB
p3: ~ 800 MB
Prepare the new ROM
Before installing the second ROM to the microSD card, the ZIP file must be slightly modified. I assume you know how to unpack and repack a ZIP file and how to use a text editor - if not, find a tutorial elsewhere. .
First, extract boot.blob and set it aside for later. Then carefully remove it from the ZIP. Second, find META-INF/com/google/android/updater-script and modify it:
Replace all occurrences of mmcblk0p1 with mmcblk1p3. I had 3 occurrences in CM's updater-script - make sure you modify all of them, otherwise your internal ROM might not survive the installation. This change will redirect the installation to the external microSD card. Finally, remove the line that says package_extract_file("boot.blob", ...) near the end - it would overwrite the kernel and we don't want that.
Now we need to add the WiFi modules. These are compiled directly into the CM kernel, but separate modules in the stock kernel.
Get the kernel modules from your running ROM - they are in /system/lib/modules (e.g. using adb pull /system/lib/modules), and copy at least these two into the ZIP into /system/lib/modules:
cfg80211.ko
bcmdhd.ko
Finally, repack the ZIP, mount the first partition of your microSD card and copy the ZIP file there.
Extract the ramdisk files
Here comes the tricky part. You need to extract the ramdisk from the boot.blob you saved from the ZIP file in the previous step.
To do that, you need tools that may not be in every household, but should be easy to find using your favorite search engine.
First we need to unpack the blob (https://github.com/AndroidRoot/BlobTools):
Code:
blobunpack boot.blob
This will create boob.blob.LNX. This is the boot image, from which we need to extract the ramdisk (https://github.com/huaixzk/unpackbootimg):
Code:
unpackbootimg -i boot.blob.LNX
This will create several files, we are interested in boot.blob.LNX-ramdisk.gz - copy this one to your tablet, e.g. into /sdcard. For example:
Code:
adb push boot.blob.LNX-ramdisk.gz /sdcard/
Prepare the preinit script and the ramdisk files
On the tablet, open a shell in a terminal app or use adb shell and become root (su). Run the following commands:
Code:
mount -o remount,rw /system
cd /system
mkdir boot
cd boot
mkdir rootfs_cm
cd rootfs_cm
gzip -d -c /sdcard/boot.blob.LNX-ramdisk.gz | cpio -i
The first line makes /system writable until the next reboot. The next few lines are self-explanatory. The last line uncompresses the ramdisk image we created in the previous step and extracts the contained files. We are doing this on the tablet itself to preserve the file permissions.
Now modify the file fstab.cardhu (one of the files just extracted).
Replace mmcblk0p1 with mmcblk1p3 and mmcblk0p8 with mmcblk1p2.
mmcblk0p2 can stay as it is, it's the /cache partition that is only used to communicate with the recovery.
Next we need to make sure the WiFi modules that we added are loaded at boot time. Edit init.cardhu.rc and find the "on boot" line. Add below (indentation is important):
Code:
insmod /system/lib/modules/cfg80211.ko
insmod /system/lib/modules/bcmdhd.ko
Near the end of init.cardhu.rc is another reference to mmcblk0p8 that needs to be modified to mmcblk1p2 - near "service setup_fs".
Finally create the file /system/boot/preinit with the following content:
Code:
#!/system/bin/sh
# preinit: only /sys and /system are mounted (ro), / is still rw
PATH=/sbin:/system/bin:/system/xbin
# auto-detect rom2sd
if [ -d /sys/block/mmcblk1/mmcblk1p3 ]; then
echo "\nsystem/boot/preinit: mmcblk1p3 detected, setting up for ROM2SD.\n"
cp -a /system/boot/rootfs_cm/* /
fi
Make sure to make it executable:
Code:
chmod 744 /system/boot/preinit
This script is run by the kernel before the real Android init. It. detects if a microSD card with 3 partitions is inserted, and if yes, it copies the files for the CM root filesystem into the ramdisk. The following Android boot procedure will then mount /system and /data to the partitions on the microSD card and the whole operating system will run from the microSD card. If no card is inserted, nothing is modified and the normal internal ROM is started.
Flashing the ROM
Insert your microSD card into the tablet, boot to TWRP and flash your modified ZIP as usual - but disable signature checking because we didn't sign the modified ZIP.
Recovery
The recovery doesn't know about the external ROM, so you can't use the recovery to backup or restore its system or data. I prefer using the PC for that anyway.
Booting
To boot from internal storage, make sure the microSD card is not inserted when you start the tablet (you can insert it as soon as the boot animation appears). To boot from the microSD card, make sure it is inserted before you turn the tablet on.
That's all. Add more microSD cards for triple-boot, quad-boot, etc.
Click to expand...
Click to collapse
It is a nice detail instruction for new users like me. I really like it a lot and I can use some information from your post for my system2sd... However, maybe I misread your post. I don't see any information about repack the blob when you are done modifying the fstab.cardhu. I know a little bit of ramdisk and can get around it but that information will help the first time users... Just my opinion and thanks for sharing a valuable information to us...
LetMeKnow said:
However, maybe I misread your post. I don't see any information about repack the blob when you are done modifying the fstab.cardhu.
Click to expand...
Click to collapse
That's because you don't need to repack the blob or reflash the kernel - I wanted to simplify the procedure, so I added preinit support to the kernel's ramdisk a few months ago. You just put some files in /system/boot and the kernel will run your preinit script that modifies the ramdisk at boot time.
Just remember that if you reflash your internal ROM, you have to recreate the /system/boot stuff.
_that said:
That's because you don't need to repack the blob or reflash the kernel - I wanted to simplify the procedure, so I added preinit support to the kernel's ramdisk a few months ago. You just put some files in /system/boot and the kernel will run your preinit script that modifies the ramdisk at boot time.
Just remember that if you reflash your internal ROM, you have to recreate the /system/boot stuff.
Click to expand...
Click to collapse
Oop, I forgot that you use it in your boot folder... It is my bad.. I will give it a try when I am done with my system2sd testing and will ask more questions on the way.. Thanks for the information...
Cheers,
LMK
_that said:
Notes
My kernel currently has not enabled SELINUX in the config, but CM appears to work anyway.
(reserved for additions)
Click to expand...
Click to collapse
You should be fine until I enforce SELINUX. But I haven't finished the policies yet. Still have some issues to iron out with that. Have about 90% of them done, I think.. lol
Just out of curiosity, will this only work with primary partitions?
johnlgalt said:
Just out of curiosity, will this only work with primary partitions?
Click to expand...
Click to collapse
It should also work with logical partitions if you modify the partition numbers accordingly. And please remove the full quote of my guide from your post, we should not emulate an Outlook-style mess in the forum.
Sent from my ASUS Transformer Pad TF700T using Tapatalk 4
_that said:
It should also work with logical partitions if you modify the partition numbers accordingly. And please remove the full quote of my guide from your post, we should not emulate an Outlook-style mess in the forum.
Sent from my ASUS Transformer Pad TF700T using Tapatalk 4
Click to expand...
Click to collapse
Yeah, I quoted it that way b/c I was asking specifically about that part - but it that part works I suppose the rest would too, huh? :silly:
Wow
Thx for this, easy cheesey, Great work, Love the dual boot!!!!
_that said:
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Click to expand...
Click to collapse
Is there any chance *someone with the required skills* could port bootmanager to our device?
BootManager
it would be the best, considering that your method uses the same load-from-sdcard thing.
Just curious thats all.
kali113 said:
Is there any chance *someone with the required skills* could port bootmanager to our device?
BootManager
it would be the best, considering that your method uses the same load-from-sdcard thing.
Just curious thats all.
Click to expand...
Click to collapse
Looks like commercial software, so ask the devs of that app.
Here is an experimental flashable zip file that redirects the TWRP recovery to the ROM2SD environment. It doesn't really install anything to storage, it just reconfigures the device nodes so that the recovery is tricked into accessing the system and data partitions on the microSD card instead of internal storage.
It works so well that after "installing" this, a following ROM install that unmounts and formats /system and installs itself to /system on mmcblk0p1 will actually be installed on the microSD card, so you don't need to replace the partition names in the updater-script any longer (but you still need to comment out the blob flashing line for now or reflash my kernel after the ROM).
It also works so well that after "installing" this, you don't see your internal /sdcard any longer, so put whatever you want to flash on the first partition of the external microSD card.
"Installing" the script again will undo its actions, so you can toggle back and forth between external and internal storage.
Warning: I tested this only once, and the script does not have any error handling - if the inserted microSD is not prepared for ROM2SD, behavior is undefined - most likely the recovery will complain that it can't mount system or data. Use this at your own risk and make sure you have backed up all valuable data and your ROM, just in case.
View attachment dev-rom2sd.zip
The script also contains a nice example how to output text from a shell script to the recovery console. It shows a list of device nodes so you can see what the script did (the device numbers of mmcblk0p1 and mmcblk1p3 are identical).
Can I follow this guide to have paranoid rom on internal and cromi-x rom on microsd?
vnphatbuddha said:
Can I follow this guide to have paranoid rom on internal and cromi-x rom on microsd?
Click to expand...
Click to collapse
I've never tried PA but it may work if you use my kernel and modify the preinit script accordingly (my kernel contains a stock-compatible ramdisk, so you need to copy the PA ramdisk to / if the microSD is *not* inserted).
_that said:
I've never tried PA but it may work if you use my kernel and modify the preinit script accordingly (my kernel contains a stock-compatible ramdisk, so you need to copy the PA ramdisk to / if the microSD is *not* inserted).
Click to expand...
Click to collapse
sorry for such a noob question but how do you compile the zips from the git links to an executable? Or does the bloobtool and unpackbootimg able to run from its extracted zips? slightly new to this...
vnphatbuddha said:
sorry for such a noob question but how do you compile the zips from the git links to an executable? Or does the bloobtool and unpackbootimg able to run from its extracted zips? slightly new to this...
Click to expand...
Click to collapse
You need to compile the blobtools on git. extract the .zip and run blobunpack on the .blob then abootimg -x on the boot.img.to repack: abootimg --create *new-bootimg* - k *zImage* -r *ramdisk*, then repack the .blob
and/or
follow this tutorial from the blob master himself http://forum.xda-developers.com/showpost.php?p=36925180
JoinTheRealms said:
You need to compile the blobtools on git. extract the .zip and run blobunpack on the .blob then abootimg -x on the boot.img.to repack: abootimg --create *new-bootimg* - k *zImage* -r *ramdisk*, then repack the .blob
and/or
follow this tutorial from the blob master himself http://forum.xda-developers.com/showpost.php?p=36925180
Click to expand...
Click to collapse
The problem I'm having is that I do not know how to use git to compile. What are the commands and do I input it in the top search bar of the site?
vnphatbuddha said:
The problem I'm having is that I do not know how to use git to compile. What are the commands and do I input it in the top search bar of the site?
Click to expand...
Click to collapse
You don't use git to compile, you use it to manage the source code.
To compile the source code, you need the appropriate development tools installed (I think it's called "build-essential" on Debian-like distributions) and run "make" in the directory with the extracted source code.
_that said:
You don't use git to compile, you use it to manage the source code.
To compile the source code, you need the appropriate development tools installed (I think it's called "build-essential" on Debian-like distributions) and run "make" in the directory with the extracted source code.
Click to expand...
Click to collapse
Wow this is too complicated to compile, having to setup and run debian on usb. Guess I can't try out rom2sd
Posting multiboot kernel with grub-style curses boot selection menu.
This is targeted towards linux users who have a multitude of distros on their tf300.
The kernel itself is Tailormoon's 2.2.9 version of Graiden kernel which included Rabits multiboot.
The difference is that I've modified the initrd to scan all drives at boot to look for linux root filesystems or .img files.
Just put all your .img files in the root of your sdcard (dock or internal), or in /data/media/linux, and boot up.
All detected filesystems will then be displayed in an an ncurses menu allowing you to select any one of them.
To install:
- Unpack the blob and install using fastboot:
> fastboot flash boot kernel.blob
- or install using your recovery
Notes:
- Press volume down button when rabits logo pops up to boot into android.
- As with Graiden/Tailormoon, unpack module.tar to your distro's module folder in order to modprobe etc.
- Also a reminder for linux rootfs, you need to mount or copy /data and /system from your android filesystem to get the wifi firmwares you need to fire up your wifi (this is true for any linux on tf300 AFAIK)
- The boot system does not use kexec so kexecboot users may already be satisfied with their current setup. I'm no fan of kexec and hence have not seen the need to include it.
TODO:
- No timer, boot menu sits there indefinitely until a choice is made
- Add android to boot menu so no need for volume down
- Add option for modifying kernel boot parameters, booting to single user etc
Thanks
Dave Driesen
Attaching source code for the boot menu as requested.
The menu is very simple. It just reads a config file provided by the initrd scripts, and outputs its own config file. Both are to be provided by command line parameter.
Makefile is included but you'll obviosuly need curses dev package to build.
Usage:
apt-get install ncurses-dev (or whatever the alternative is for your distro)
tar -xcf bootmenu-src.tar.gz && cd bootmenu-src && make
done!
The rest of the source (such as partition scanning code and OS boot code) consists of modification to Rabits' multiboot which are freely available inside the initrd. I will not post them here as I did not originally create them. If you're interested, I suggest unpacking the initrd and getting stuck in there.
Fyi, here's some scripts for unpacking/packing a kernel.blob.. I don't support these and you'll need to install the relevant tools (blobpack/abootimg/cpio) if you're keen. But this is what I use; may it help others in building blobs, or understanding the steps involved.:
unpack.sh:
Code:
#!/bin/bash
DIR=$(pwd)
# Stage 1 - unpack the blob
mkdir 1.kernel
cp $1 1.kernel/kernel.blob
cd 1.kernel
blobunpack kernel.blob
# Stage 2 - Extract boot image (compressed initrd)
mkdir ../2.LNX
cd ../2.LNX
abootimg -x ../1.kernel/kernel.blob.LNX
# Stage 3 - Decompress initrd
mkdir ../3.initrd.gz
cd ../3.initrd.gz
zcat ../2.LNX/initrd.img >initrd.cpio
# Stage 4 - Unpack initrd
mkdir ../4.initrd
cd ../4.initrd
cpio -id < ../3.initrd.gz/initrd.cpio
# This will leave fully uncompressed kernel in directory "4.initrd"
pack.sh:
Code:
#!/bin/bash
DIR=$(pwd)
# Stage 5 - Pack initrd
mkdir 5.initrd.cpio
cd 4.initrd
find . | cpio --create --format='newc' > ../5.initrd.cpio/initrd.cpio
# Stage 6 - gzip compress initrd
mkdir ../6.initrd.img
cd ../6.initrd.img
gzip ../5.initrd.cpio/initrd.cpio -c9 --stdout --best >initrd.img
# Stage 7 - Create Android boot image
mkdir ../7.LNX
cd ../7.LNX
mkdir content
cp ../2.LNX/* content
cp ../6.initrd.img/initrd.img content
abootimg --create kernel.LNX -f content/bootimg.cfg -k content/zImage -r content/initrd.img && rm -rf content
# Stage 8 - Sign the Android boot image.
# You'll need to do this or your device may reject the blob.
# I could never find a tool for this so just prepend the signature using echo.
mkdir ../8.kernel
cd ../8.kernel
blobpack kernel_unsigned.blob LNX ../7.LNX/kernel.LNX
echo -n -e "-SIGNED-BY-SIGNBLOB-\0\0\0\0\0\0\0\0" >kernel.blob
cat kernel_unsigned.blob >> kernel.blob
rm kernel_unsigned.blob
# Your finished kernel.blob is now in directory "8.kernel"
Awesome stuff!
Wow - this is very very nice! What a job thank you for sharing. I do have issues though - but they are related to my setup - i cant mount /root on /dev/loop (or something along those lines) so the boot process defaults to Android (which actually boots out the box from this (which is nice - had a ****load of issues with other kernels and the original rabits kernel thing) any ideas for the /dev/loop thing?
Again thanks man - so nice!
Nice work, but can you post the source code please? Thanks.
thanks for posting, wouldn't mind trying linux on here after all these years. is this kernel fine with android 5.1.1?
dkzeb said:
i cant mount /root on /dev/loop (or something along those lines) so the boot process defaults to Android
Click to expand...
Click to collapse
Is this an extfs? Usually when you get the mount failure, be it in original Rabits or this multiboot, I find that if I drop to a shell and try to mount by hand, the mount command throws an error either way. Most often this then turns out to be due FS settings ("Check filesystem after X mounts, or X days etc). Checking the FS or using tune2fs to disable periodic checking makes this go away.
You can drop to a busybox shell by pressing "s" when the rabits logo shows up.
Insane PPC said:
thanks for posting, wouldn't mind trying linux on here after all these years. is this kernel fine with android 5.1.1?
Click to expand...
Click to collapse
I'm not sure but doubt it.. Tbh I never got any Android version over Cromi-X 5.4 to run reliably on the TF300 :/ Interested to hear your opinion but for me they all turned out to be slow, unstable (crashes, reboots), drained the battery or just plain impossible to implement. Hence went back to Cromi-X 5.4 and probably staying there forever.
Linux on the TF300 is ok but has many challenges, some of which simply cannot be overcome. Biggest problem is that NVidia dropped support for Tegra3 about 5 minutes after launch. They are not releasing new drivers for contemporary ABIs, something you WILL need if you want to run any kind of recent Xorg using the device's Tegra3 hardware features. That includes touch pad and graphics accelleration.
So you're basically stuck with distro's from 2012 and must be very careful what packages you upgrade or your TF300 will lose OS support for some of its HW features.
Since so many people are asking, I figured I would write up a quick tutorial on how to modify a boot image. A boot image is a kernel, and an initrd packaged together along with some other information.
This will only concentrate on tearing one apart, modifying it, and putting it back together -- making your own kernel and packaging it is outside the scope.
So, the big thing going around right now is the fact that the lovely carriers have this process (rctd) that runs and chews up CPU. rctd stands for Root Check Toolkit Daemon -- and it does what it sounds like. It checks if you have root, it checks if the system partition has been modified, it checks if the kernel has been modified, etc...etc... Most importantly, it chews up a LOT of CPU and disk IO to do this.
For this to work, you need to have a Linux install, or WLS on Windows 10.
Ubuntu comes packaged with abootimg:
Code:
apt install abootimg
abootimg is used to extract / create / update the Android Boot Image, but first we need out boot image.
adb reboot recovery
adb pull /dev/block/bootdevice/by-name/boot boot.img
Now we extract it.
abootimg -x boot.img
This will give you 3 files:
bootimg.cfg // feel free to take a look if you want, but do not change anything in this file or your kernel probably won't boot.
zImage // This is the Linux kernel. If you grab the sources, and compile a kernel, this is what you get. Again, leave it alone.
initrd.img // This is the initrd (Initial Ramdisk). It is loaded by the kernel to give you a working environment before anything else is loaded. This is what we need to modify
Before we modify initrd, we have to extract it. It is a compressed cpio file. There are several ways to extract it, but this is the method I use:
Code:
mkdir initrd_temp
cd initrd_temp
zcat ../initrd.img | cpio -idv
zcat cats the file while decompressing it. cpio -idv ... -i means extract (yea, wtf), -d means create the directory tree, and -v just means verbose
So now we are in a directory (initrd_temp) with all the files that are in the initrd. The one we care about is init.lge.rc -- we need to edit this file.
If you open it up in an editor, search for this section:
Code:
# LG RCT(Rooting Check Tool)
service rctd /sbin/rctd
class late_start
user root
group root
seclabel u:r:rctd:s0
service ccmd /system/bin/ccmd
class core
user system
group system
socket ccmd stream 0660 root system
seclabel u:r:ccmd:s0
Delete all of that, or comment it out using # signs
Now we need to package everything back up.
Code:
find . | cpio --create --format='newc' | gzip -9 > ../newinitrd.img
cd ..
abootimg --create newboot.img -f bootimg.cfg -k zImage -r newinitrd.img
When you are done, you will have newboot.img, and you need to flash it.
Since we are still in recovery:
Code:
adb push newboot.img /sdcard
adb shell
cd /sdcard
dd if=newboot.img of=/dev/block/bootdevice/by-name/boot
Reboot and enjoy your new -- faster -- rctd and ccmd free kernel.
If doing it this manual way isn't for you, @Zacharee1 has created a script to automate the procedure. I wrote this for people that like to know exactly what is going on. Feel free to poke around in the other files that are in your initrd. You may find other things that you want to tweak. However, be careful, you could make a kernel that won't boot. If that happens, just get into recovery and flash one that does
-- Brian
Did anyone ever figure out what ccmd is?
I am 99% sure it allows remote command execution. Pull it, and take a hex editor to it...
It is nothing good, that is for sure.
It listens on a socket: socket ccmd stream 0660 root system
and
Code:
Unable to start CommandListener (%s)
No permission to run ccmd ccmode commands
Usage: ccmode enable
Usage: ccmode getflag
Usage: ccmode setflag <flag>
-- Brian
Im no good installing anything on windows ciao!!
It would be nice if someone with brains. Not me. Lol can figure out a new kernel for 10p h918 with no rctd and only kcal. ?
Sorry to hijack this thread, but I've made a Telegram thread for this subject https://t.me/joinchat/EkE57g6dCLopBy8xVQRT9w
With LG G5 h850 im not able to boot the image anymore. I always only get the fastboot screen. Maybe there is a difference?
@DMOEdetc If you pull your kernel and send me a link, I will take a look. As far as I know, the Android boot image hasn't changed since the first version.
The init that Android uses may not like files with CR/LF if you are editing it in Windows and not specifying LF only. init may think it is a corrupt file and therefore refuse to load it...
-- Brian
Code:
/*
*Disclaimer
*
* Your warranty is now void.
*
* We're not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
*/
Working :
Basic twrp features (boot, format data, etc, etc)
Decryption data up to android 13
Vibration
otg
Issues / Notes :
really messed fstab
/system is missing from wipeui, and i have no idea what happened (but flashing should works fine)
miui is partially support (due to using /cust as /system_ext)
Download : Link
Thanks :
aidan for sending me money to buy motherboard
Source :
device tree
kernel
reserved
Hey, thanks for sharing it.
I had some problems with installing custom ROM, because lack of appearing /system partition in format step and installed ROM went started to bootloop.
Fortunately I was able to pass this step by mounting system partition, entering into terminal and executing following command: " cd /system_root && rm -Rf * " -without quotes.
Please make sure to execute whole command at once or just ensure you will not delete files outside of proper system partition by executing part of command (for example when /system mounts in other location than /system_root). If you are not sure, execute "df" command and see last entry which should show you where system partition is mounted and adjust the command.
For some of you, who want to proceed with my advice. Please note, that I am not responsible for any problems you can cause on your device using my advice. It will surely not break your phone if done properly. if you don't understand what you do, please don't do it
Fiqusny said:
Hey, thanks for sharing it.
I had some problems with installing custom ROM, because lack of appearing /system partition in format step and installed ROM went started to bootloop.
Fortunately I was able to pass this step by mounting system partition, entering into terminal and executing following command: " cd /system_root && rm -Rf * " -without quotes.
Please make sure to execute whole command at once or just ensure you will not delete files outside of proper system partition by executing part of command (for example when /system mounts in other location than /system_root). If you are not sure, execute "df" command and see last entry which should show you where system partition is mounted and adjust the command.
For some of you, who want to proceed with my advice. Please note, that I am not responsible for any problems you can cause on your device using my advice. It will surely not break your phone if done properly. if you don't understand what you do, please don't do it
Click to expand...
Click to collapse
or fastboot erase system can help, if someone lack knowledge
i still finding the root cause for this, if i can fix it i'll release new one asap
loipuru said:
or fastboot erase system can help, if someone lack knowledge
i still finding the root cause for this, if i can fix it i'll release new one asap
Click to expand...
Click to collapse
I never would have thought about such obvious solution. Thanks
so, can i still use this to flash older MIUI versions like MIUI 12?
i should just use fastboot erase system after wiping via twrp. right?
bluviper said:
so, can i still use this to flash older MIUI versions like MIUI 12?
i should just use fastboot erase system after wiping via twrp. right?
Click to expand...
Click to collapse
yeah,
i don't have time to rebase tree yet. so it'll preferred method for now
yea. i just tried. and it worked.
did a full wipe and reinstalled miui-globe ROM.
thanks
new update out:
changelog: fix /system missing
loipuru said:
new update out:
changelog: fix /system missing
Click to expand...
Click to collapse
Flashed but upon rebooting into recovery it lost access to storage and sdcard directories.
tlxxxsracer said:
Flashed but upon rebooting into recovery it lost access to storage and sdcard directories.
Click to expand...
Click to collapse
known issues, but it only happened on some roms, no problem on sparks and los as i tried
it's source issues which is really tricky to fix