Any official, up-to-date guide for manually configuring existing GRUB (multi-booting)?

[LSS]

Currently I installed Android-x86_64 to a GPT disk which also contains an existing Linux installation. As the ESP already contained GRUB which came with my Linux installation, I did not install GRUB here, so the Android-x86 boot entry was never added.

However, I found no up-to-date information (at most some outdated ones from Google) about how to manually add an Android-x86 boot entry to an existing GRUB so I can boot Android-x86 from there. Is there an official instruction on this? The official installation guide doesn't mention this, either.

Also, is there a guide on what boot parameters are available for the boot entry? Especially, I want to specify a different partition as /data, as I want to keep the user data stuffs separate from system (which resides in a much smaller partition). A long time ago (around Android 6/7) I did manage to achieve this by specifying the partition number for the /data partition (I think it was something like DATA=/dev/sda2), but I was not able to get it to properly accept a /data partition by its UUID at that time.

[Prajna Sariputra]

I'm not sure how the files are arranged if you used the installer, but with the RPM package Android-x86 is placed in a subfolder in the root drive, which contains the kernel, initrd.img, ramdisk.img and the data folder, and boot entries for GRUB does get created. Looking at it and GRUB's documentation it looks like it'll work just fine if you put the Android-x86 folder in any properly formatted partition (ext4 in my case), although I don't know if it's possible to separate the system and data in different partitions (if the goal is to allow easy factory reset then all you need to do in this case is to simply clear out the data folder). I have attached the boot entry file, just place it alongside grub.cfg and GRUB should pick it up when you reboot (make sure to update the folder names, and get rid of the Vulkan option there if you don't want it).

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/3a5bc2b7-87f8-43a0-af67-123989c5ae8ao%40googlegroups.com.

[LSS]

Thanks, I'll take a look. Unfortunately I could not take advantage of the RPM version as I'm using Manjaro (which is Arch-based). I'm yet to find a PKGBUILD that would produce a similar result to the RPM version...

I'm installing the system read/write so I could later on manage/adjust the system contents from the Linux side if wanted. I think this option's description is misleading. It actually means whether or not you want to unsquash the filesystem (which would take more space).

With only one partition, the unsquashed /system has to be mounted read/write or otherwise /data won't be writable (hence the option's description). With a separate user data partition (mimicking actual devices), it's still possible to keep the unsquashed /system read-only when the system is running, and I could modify things externally if needed (you can't modify a squashfs image, though this makes upgrading easier). A separate data partition could also prevent the system from being damaged should the user data got filled up later on (in the worst possible scenario)...

It seems this config should be able to get Android-x86 running, but I'll still need to look for a way to assign a different /data partition, as I allocated only 6GB for /system (it actually takes about 2.3GB when unsquashed), with the rest of the space meant for data on a different partition.

To unsubscribe from this group and stop receiving emails from it, send an email to andro...@googlegroups.com.

[Prajna Sariputra]

While the RPM package wouldn't work directly it's simple enough to replicate the effect, all it does is extract the folder inside to the root directory and drop the custom.cfg in the right place (which is embedded in the install script as opposed to being a file inside the archive). I use Arch myself, and it works fine just like that, although I didn't bother making an actual package for it.

[Chih-Wei Huang]

LSS <slythe...@gmail.com> 於 2020年8月6日 週四 下午2:32寫道：

>
> Thanks, I'll take a look. Unfortunately I could not take advantage of the RPM version as I'm using Manjaro (which is Arch-based). I'm yet to find a PKGBUILD that would produce a similar result to the RPM version...
>
> I'm installing the system read/write so I could later on manage/adjust the system contents from the Linux side if wanted. I think this option's description is misleading. It actually means whether or not you want to unsquash the filesystem (which would take more space).
>
> With only one partition, the unsquashed /system has to be mounted read/write or otherwise /data won't be writable (hence the option's description). With a separate user data partition (mimicking actual devices), it's still possible to keep the unsquashed /system read-only when the system is running, and I could modify things externally if needed (you can't modify a squashfs image, though this makes upgrading easier). A separate data partition could also prevent the system from being damaged should the user data got filled up later on (in the worst possible scenario)...
>
> It seems this config should be able to get Android-x86 running, but I'll still need to look for a way to assign a different /data partition, as I allocated only 6GB for /system (it actually takes about 2.3GB when unsquashed), with the rest of the space meant for data on a different partition.

I think you have already known it: add cmdline option
like DATA=sda3 (or DATA=/dev/sda3 if you prefer).

[LSS]

Yeah, that was the right cmdline option. However, back then I was not able to get it to accept a UUID. I prefer using a UUID since partition number may change.

Since you mentioned passing absolute device paths like /dev/sda3 would work, I think I may give /dev/by-uuid/<data partition UUID> a try.

[LSS]

Some feedback.

Unfortunately the /dev/disk/by-uuid/<data partition UUID> method still does not work for DATA. Has to use the old way (works for nvme also). However, there are some issues which prevented me from going further.

First is that I cannot normally complete the Setup Wizard because I can't see a mouse pointer. I prefer skipping the Setup Wizard, though. Not sure whether the problem might be the Corsair mouse I'm using (Dark Core SE RGB).

Although I could skip the setup wizard with a console settings command (settings put secure user_setup_complete 1), once it enters the desktop Android System keeps crashing until it ended up in a completely black screen.

I'm attaching one of the tombstones generated here. This is on android-x86_64 9.0-r2.