[MOD][FEB 10] MultiROM v33

[Sparviero]

Hi everyone, if my primary rom is stock, how can I install the monthly ota update?
I can't find zips flashable with twrp.
Thank you!

---------- Post added at 09:47 AM ---------- Previous post was at 09:45 AM ----------

Hi everyone, if my primary rom is stock, how can I install the monthly ota update?
I can't find zips flashable with twrp.
Thank you!

 

[drewski_1]

Hi everyone, if my primary rom is stock, how can I install the monthly ota update?
I can't find zips flashable with twrp.
Thank you!

---------- Post added at 09:47 AM ---------- Previous post was at 09:45 AM ----------

Hi everyone, if my primary rom is stock, how can I install the monthly ota update?
I can't find zips flashable with twrp.
Thank you!

Bad Boyz is a flashable, rooted, stock. It's been getting updated with each monthly patch
http://forum.xda-developers.com/nexus-7-2013/development/rom-bad-boyz-nexus-7-stock-rooted-t3219148

 

[followmsi]

hi

I have made an Update.zip for secondary ROM myself .. based on latest stock rom boot.img and system.img only.
Used the following code ..

ui_print("boot.img");
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
ifelse(is_mounted("/system"), unmount("/system"));
format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system");
ui_print("system.img");
package_extract_file("system.img", "/dev/block/platform/msm_sdcc.1/by-name/system");
unmount("/system");
ui_print("Installation complete!");
ui_print("OK Done - Please reboot!");

The update.zip script above created the new secondary rom for multirom - no problems so far.

I did also simg2img system.stock.img system.new.img.
I can loop mount the system.new.img without problems.

But when I boot into this new secondary ROM it fails .. will post the log file later on.

I have checked the update.zip rom from multirom team and from bad boyz.
Both are using extracted system.img or do extract before.
And set permissions .. etc. via update.zip.
Not like me pushing the system.img directly.
package_extract_file("system.img", "/dev/block/platform/msm_sdcc.1/by-name/system");

For the boot.img it seems to be no problem .. but for system.img ?

Why does it not work like this for system.img ?


EDIT: The multirom_log.txt on sdcard has 0 bytes.


Thanks for some help !

 

[doniks]

Are you on the LTE model? It seems something is wrong with the images being held on Tassadar's server that supports the packages for deb. I got Ubuntu Touch working on mine just now by switching to the images for flo, the wifi-only model. I was able to do this by going into the MultiRom Manager options menu and tapping the version number until it gave me developer options, then changing the device name from deb to flo. There is also an option to change the server address.

I have that same problem on my nexus 7, deb, where the Ubuntu Touch installation seems to be stuck at the Google Logo. It had worked in the past.
I can't find how to turn on these developer options you speak of. Where is this "options menu"? I see two pages in the MultiRom Manager ap:

• "Install/update" which has the three sections: "Status", "Install/Update" and "Install Ubuntu Touch", and
• "Manage ROMs" which lists the primary&secondary roms that are installed.

I am using CyanogenMod 11 - the MultiROM Manager app is the latest from the Play Store : version 1.188.

It seems someone else has a more up to date server here - [system-image dot ubports dot com]. Sorry about syntax, I'm a newbie so it doesn't let me post link. MultiRom doesn't seem to support adding ROM archives manually, and this alternative server doesn't have a manifest.json like Tassadar's so this might be a dead end.

Not sure about the manifest.json you are looking for, but looking at the ubports server I see similar json files as on tassadars or canonicals servers:

• system-image.tasemnice.eu/channels.json
• https://system-image.ubports.com/channels.json
• https://system-image.ubuntu.com/channels.json

Does that help in any way?

I've also tried to replace Android completely and install Ubuntu Touch via ubuntu-device-flash as described here, but both tassadars server as well as ubports lead to an error “This phone needs restoring from a PC or service center.” like shown here.

 

[doniks]

Where is this "options menu"?

My bad, found it ... top right ...

Not sure about the manifest.json you are looking for

Got it ... this one: http://tasemnice.eu/multirom/manifest.json
That's indeed a very different file than the channel.json's I mentioned. Not sure how one would teach multirom an alternate channel.json. Mhm. After overwriting the device name to "flo", multirom offers various flo channels and images. Since none of these can be found on tassadars server (http://system-image.tasemnice.eu/ubuntu-touch/) it seems that the app is transparently switching between these two: system-image.tasemnice.eu/channels.json
https://system-image.ubuntu.com/channels.json

 

[langeveld024]

@knopancakes
I tried to install Ubuntu (stable and devel) as secondary using multirom manager on my flo.
(with cm13 and elementalX kernel as primary)
Stuck on Google splash.
So I changed flo to deb after I read your post, same story. It just won't boot.
But while installing in TWRP, the log shows some error "failed: kernel supports no swap" or something like that.
I'll try to upload the log as soon as possible.

Sent from my E6653 using XDA-Developers mobile app

 

[osm0sis]

Like I've said a few times by now.. rc-proposed/ubuntu is your best bet. I just let it auto-update from r397 to r428 and it all worked and boots fine.

 

[osm0sis]

While we wait for @Tasssadar to come back and pull the trigger on a new official build, luckily @nkk71 and @Captain_Throwback have agreed to make us some updated unofficial builds! I've tested them out for them so now we're ready for a more public release.

MultiROM v33a + MR-TWRP 3.0.2-0 (20160505-01):
https://basketbuild.com/devs/Captain_Throwback/Nexus 7 2013/MultiROM

All credit to them both for the new commits and the actual builds. Thanks guys! :good:

 

[followmsi]

While we wait for @Tasssadar to come back and pull the trigger on a new official build, luckily @nkk71 and @Captain_Throwback have agreed to make us some updated unofficial builds! I've tested them out for them so now we're ready for a more public release.

MultiROM v33a + MR-TWRP 3.0.2-0 (20160505-01):
https://basketbuild.com/devs/Captain_Throwback/Nexus 7 2013/MultiROM

All credit to them both for the new commits and the actual builds. Thanks guys! :good:

Thanks for the nice release .. just have updated !

But I do have the same problem installing secondary systems.

Update.zip with "package_extract_file("system.img", "/dev/block/platform/msm_sdcc.1/by-name/system");" are not booting as secondary.

More details here .. http://forum.xda-developers.com/showpost.php?p=66468858&postcount=1303

Why it's not booting as secondary ? .. the same Update.zip works on Flo hardware. ( for internal )

Here is the multirom-log.txt ..

2.806488] trampoline: Loading fstab "/fstab.flo"...
<6>[ 2.916961] EXT4-fs (mmcblk0p30): mounted filesystem with ordered data mode. Opts: barrier=1,data=ordered,nomblk_io_submit,errors=panic
<6>[ 2.924743] trampoline: Starting adbd
<3>[ 2.926727] trampoline: Running multirom
<3>[ 2.943267] multirom: Running MultiROM v33a
<6>[ 2.943603] multirom: Loading MultiROM status...
<3>[ 2.946594] multirom: Loading fstab "/fstab.flo"...
<6>[ 2.949645] multirom: Adding ROM Internal
<6>[ 2.951263] multirom: Adding ROM Update.ZIP_MOB30J_6.0.1_st
<6>[ 2.954406] multirom: Adding ROM Update.ZIP_MOB30J-flo
<6>[ 2.960937] multirom: Dumping multirom status:
<6>[ 2.961029] multirom: is_second_boot=1
<6>[ 2.961151] multirom: is_running_in_primary_rom=0
<6>[ 2.961242] multirom: current_rom=Update.ZIP_MOB30J-flo
<6>[ 2.961364] multirom: allow_nkk71_nokexec=0
<6>[ 2.961456] multirom: colors_v2=0
<6>[ 2.961517] multirom: brightness=40
<6>[ 2.961639] multirom: enable_adb=0
<6>[ 2.961730] multirom: enable_kmsg_logging=0
<6>[ 2.961791] multirom: rotation=0
<6>[ 2.961914] multirom: force_generic_fb=0
<6>[ 2.962036] multirom: anim_duration_coef=1.000000
<6>[ 2.962097] multirom: hide_internal=0
<6>[ 2.962219] multirom: int_display_name=NULL
<6>[ 2.962310] multirom: auto_boot_seconds=5
<6>[ 2.962371] multirom: auto_boot_rom=Internal
<6>[ 2.962524] multirom: auto_boot_type=0
<6>[ 2.962585] multirom: curr_rom_part=NULL
<6>[ 2.962707] multirom:
<6>[ 2.962799] multirom: ROM: Internal
<6>[ 2.962860] multirom: base_path: /realdata/media/0/multirom/roms/Internal
<6>[ 2.963012] multirom: icon_path: /realdata/media/0/multirom/icons/romic_default.png
<6>[ 2.963104] multirom: type: 0
<6>[ 2.963226] multirom: has_bootimg: 0
<6>[ 2.963287] multirom: ROM: Update.ZIP_MOB30J-flo
<6>[ 2.963378] multirom: base_path: /realdata/media/0/multirom/roms/Update.ZIP_MOB30J-flo
<6>[ 2.963500] multirom: icon_path: /realdata/media/0/multirom/icons/romic_default.png
<6>[ 2.963653] multirom: type: 1
<6>[ 2.963714] multirom: has_bootimg: 1
<6>[ 2.963836] multirom: ROM: Update.ZIP_MOB30J_6.0.1_st
<6>[ 2.963928] multirom: base_path: /realdata/media/0/multirom/roms/Update.ZIP_MOB30J_6.0.1_st
<6>[ 2.964080] multirom: icon_path: /realdata/media/0/multirom/icons/romic_default.png
<6>[ 2.964202] multirom: type: 1
<6>[ 2.964294] multirom: has_bootimg: 1
<6>[ 2.964385] multirom: nkk71: primary_boot.img location will be=/realdata/media/0/multirom/primary_boot.img
<6>[ 2.964538] multirom: nkk71: locating boot partition...
<6>[ 2.964599] multirom: nkk71: found boot at '/dev/block/mmcblk0p14'
<3>[ 2.964782] multirom: /proc/config.gz is not available!
<3>[ 2.964874] multirom: /proc/atags was not found!
<3>[ 2.965026] multirom: Skipping ROM selection, is_second_boot=1, auto_boot_type=0x0
<3>[ 2.965179] multirom: No run-on-boot scripts for ROM Update.ZIP_MOB30J-flo
<6>[ 3.017303] multirom: Using fstab ./fstab.flo from rc files
<3>[ 3.017456] multirom: Modifying fstab: ./fstab.flo
<3>[ 3.018615] multirom: Could not open /system/build.prop to read api level!
<6>[ 3.049407] multirom: Framebuffer implementation: Qualcomm ION overlay
<4>[ 3.078979] mipi_dsi_panel_power+, on=1
<4>[ 3.160797] mipi_dsi_panel_power-
<6>[ 3.166503] mipi_JDI_lcd_on+
<6>[ 3.166595] mipi_JDI_lcd_on-, booting
<6>[ 3.170623] mdp4_overlay_mdp_perf_upd mdp clk is changed [1] from 0 to 200000000


Thanks

 

[osm0sis]

All your script does is extract the file system.img to your system mount.. so there's nothing there to boot, only the actual file system.img, i.e. "/system/system.img".

system.img isn't like boot.img, I don't believe you can flash it directly to a partition block in recovery and have it work, plus, with MultiROM it's not a real block device, so even if that could work, it likely wouldn't work for MultiROM.

 

[followmsi]

All your script does is extract the file system.img to your system mount.. so there's nothing there to boot, only the actual file system.img, i.e. "/system/system.img".

system.img isn't like boot.img, I don't believe you can flash it directly to a partition block in recovery and have it work, plus, with MultiROM it's not a real block device, so even if that could work, it likely wouldn't work for MultiROM.

It works on Flo Hardware .. for internal.
Like on other devices too.

If you look a few threads above there is the complete script.
Of course with boot.img too.

Formating works well .. just the extract of the system.img fails.

Where is the difference when you format the same "block" partition inside update.zip scripts ?

 

[osm0sis]

It works on Flo Hardware .. for internal.
Like on other devices too.

If you look a few threads above there is the complete script.
Of course with boot.img too.

Formating works well .. just the extract of the system.img fails.

Where is the difference when you format the same "block" partition inside update.zip scripts ?

Ah! Cool to know that works with a normal block partition device. Still though, MultiROM just redirects the /system mount/device to a directory in /data/media/0/MultiROM/roms/.../system, so since it's a directory not a true block device I'm guessing that's why it doesn't work.

Go in with adb shell into the directories I mention above after a flash attempt and you'll probably see the system.img as a whole single file in there.

 

[followmsi]

Ah! Cool to know that works with a normal block partition device. Still though, MultiROM just redirects the /system mount/device to a directory in /data/media/0/MultiROM/roms/.../system, so since it's a directory not a true block device I'm guessing that's why it doesn't work.

Go in with adb shell into the directories I mention above after a flash attempt and you'll probably see the system.img as a whole single file in there.

write_raw_image is normally used for "real" block device flashing.

extract_package_file is just extracting the .img file.
After simg2img the system.img is just ext4 filesystem anyway.

I will check the data folder as well ..

But where is the difference if you format the block device in Update.zip ?

Can this be fixed/changed in next multirom release ?

---------- Post added at 11:44 AM ---------- Previous post was at 11:30 AM ----------

Checked the */data/media/0/MultiROM/roms/.../system folder .. it's completely empty !
Not even the full system.img file.

Would be very cool if you guys can include "this" way of Update.zip too.

Thanks

 

[doniks]

I have that same problem on my nexus 7, deb, where the Ubuntu Touch installation seems to be stuck at the Google Logo.

Seems our friendly neighbours have figured it out! The following works for me:

Everyone who cant get Ubuntu-Touch to boot follow this (For multirom v33)
1) Change date to Feb !0 or earlier
2) Use the channels: Vivid-Proposed(lags a bit), Vivid, Utopic-Proposed, Utopic
3) let Multirom do the rest

Where, I'd say that should be Feb 10 and for deb, I'd say the sensible choice is vivid.

 

[nkk71]

Update.zip with "package_extract_file("system.img", "/dev/block/platform/msm_sdcc.1/by-name/system");" are not booting as secondary.

All your script does is extract the file system.img to your system mount.. so there's nothing there to boot, only the actual file system.img, i.e. "/system/system.img".

system.img isn't like boot.img, I don't believe you can flash it directly to a partition block in recovery and have it work, plus, with MultiROM it's not a real block device, so even if that could work, it likely wouldn't work for MultiROM.

that particular method was never supported, nor is it [really supported now], we thought about addressing it, including some other unconventional "scripts / deletes" as well
but since it seems that/those methods have become quite scarce we never bothered... this is MultiROM after all

 

[followmsi]

that particular method was never supported, nor is it [really supported now], we thought about addressing it, including some other unconventional "scripts / deletes" as well
but since it seems that/those methods have become quite scarce we never bothered... this is MultiROM after all

This is edify code.
I don't see this as unconventional and also not as a retired function.

This is a nice and still used way to install system.img quickly !
Without bothering about detailed file rights and symlinks inside System.img.

As I really like MultiROM I would be happy to use this way in the future too.
Do you see any chance for implementation from your side ?

Thanks

 

[nkk71]

This is edify code.
I don't see this as unconventional and also not as a retired function.

This is a nice and still used way to install system.img quickly !
Without bothering about detailed file rights and symlinks inside System.img.

As I really like MultiROM I would be happy to use this way in the future too.
Do you see any chance for implementation from your side ?

Thanks

Possible yes... is it going to be added, dunno, i'm not working on mrom for a while

there are several ways how this can be approached, and since i dont want to go into an elaborate discussion about it, here's a question:

• how big is your system partition
• how big is that system.img
• how big are the actual "files" within that system.img

example: the system.img was created using a TWRP backup / dd / etc., so it's the real full system partition size (let's say 2GB), the actual ROM (files) within it is only 200MB... result: 1.8GB of wasted space on internal storage
(if used as is)

guess, there are other methods to work around it, but not sure it's worth the implementation atm

 

[followmsi]

Possible yes... is it going to be added, dunno, i'm not working on mrom for a while

there are several ways how this can be approached, and since i dont want to go into an elaborate discussion about it, here's a question:

• how big is your system partition
• how big is that system.img
• how big are the actual "files" within that system.img

example: the system.img was created using a TWRP backup / dd / etc., so it's the real full system partition size (let's say 2GB), the actual ROM (files) within it is only 200MB... result: 1.8GB of wasted space on internal storage
(if used as is)

guess, there are other methods to work around it, but not sure it's worth the implementation atm

You can just make a resize2fs -M system.img and it's back to 200mb - the real size.
Do e2fsck -f system.img before and you are happy.

In my update.zip i am using resize2fs the other way around to enlarge file system to full partition size.

Works well ..

Here are we talking about Flo stock system.img anyway .. latest May Update.

Why is .img file size important ?
If you have enough space on /data left the MultiROM system.img could also be 2gb, even with 1.8gb empty space.

Thanks for your help !

 

[nkk71]

You can just make a resize2fs -M system.img and it's back to 200mb - the real size.
Do e2fsck -f system.img before and you are happy.

In my update.zip i am using resize2fs the other way around to enlarge file system to full partition size.

Works well ..

Here are we talking about Flo stock system.img anyway .. latest May Update.

Why is .img file size important ?
If you have enough space on /data left the MultiROM system.img could also be 2gb, even with 1.8gb empty space.

Thanks for your help !

i was just giving an example of system.img size... (eg, HTC M9 4GB, so i really wouldnt want 4GB img's hanging around when even the largest HTC Sense ROMs are well below that, and other ROMs, can be just a few hundred MBs)

whereas a normal partition would have a constant size, and the files within it can take as little or as much as they like, since the rest of the space is not [usually] used,
mrom on the other hand "prefers" (so to say), a "file" ordered system, not a "partition" system (well okay, the latter is done when flashing to non ext partitions, so yeah, to an extent we can even use a full system.img .... i guess)

my thoughts would be more along the lines, of mounting your system.img, then extracting the files to the mrom fake system folder..... kinda what the installer script is supposed to do

like i said, i can think of quite a few "methods"... dunno which would work best, etc

but, as i mentioned, i really didnt want to get into a long discussion about it

basically... is it feasible, yeah, i do think so;
how hard is it; what's the best method, etc? dunno... maybe just as simple as "copying" the the system.img file, and using it as such :cyclops:

 

[followmsi]

i was just giving an example of system.img size... (eg, HTC M9 4GB, so i really wouldnt want 4GB img's hanging around when even the largest HTC Sense ROMs are well below that, and other ROMs, can be just a few hundred MBs)

whereas a normal partition would have a constant size, and the files within it can take as little or as much as they like, since the rest of the space is not [usually] used,
mrom on the other hand "prefers" (so to say), a "file" ordered system, not a "partition" system (well okay, the latter is done when flashing to non ext partitions, so yeah, to an extent we can even use a full system.img .... i guess)

my thoughts would be more along the lines, of mounting your system.img, then extracting the files to the mrom fake system folder..... kinda what the installer script is supposed to do

like i said, i can think of quite a few "methods"... dunno which would work best, etc

but, as i mentioned, i really didnt want to get into a long discussion about it

basically... is it feasible, yeah, i do think so;
how hard is it; what's the best method, etc? dunno... maybe just as simple as "copying" the the system.img file, and using it as such :cyclops:

For example in Tassadar Update.zip he is using ..

format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");

It's even more radical
How do you "wrap" this block device format command into multirom ?
The same way it should work with package_extract_file("system.img", ......

The update script is taking care of deploying files .. but in another way expected.
As said before, on hardware for "internal" rom, it works fine.

Looking forward for next MultiROM version .. I am happy to test anything related to this topic

Thanks again for all your help !