Building and installing
There are multiple installation methods for your Xiaomi Redmi Note 7. They all rely on flashing one or more partitions on your device.
All installation methods can lead to data loss.
Flashing a partition will erase everything on the partition. Additionally,
the common backups methods, e.g. TWRP, will not backup the
This will produce a folder with a flashing script, and the partition images for your Xiaomi Redmi Note 7.
$ nix-build --argstr device xiaomi-lavender -A build.android-fastboot-images
Alternatively, you can build a specific partition image:
$ nix-build --argstr device xiaomi-lavender -A build.android-bootimg $ nix-build --argstr device xiaomi-lavender -A build.rootfs
The device will need to be booted in its bootloader, or
The boot images can be installed using the following command, assuming the
android-fastboot-images output was used.
If you have a system image (
system.img) built, you can use
flash it to the device. Note that it might be too big to fit over the
partition. In such case, it can be flashed on the
$ fastboot flash userdata system.img
Using a flashable zip
An alternative installation method is to use a flashable zip. The flashable zip can be built for your Xiaomi Redmi Note 7 using one of the following commands:
$ nix-build --argstr device xiaomi-lavender -A build.android-flashable-bootimg $ nix-build --argstr device xiaomi-lavender -A build.android-flashable-system $ nix-build --argstr device xiaomi-lavender -A build.android-flashable-zip
The first two will flash only a specific partition. The last one contains the partitions of the two previous one.
The zip can either be copied to the device and selected in a compatible
Android recovery, or sent to the device through
$ adb sideload /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-flashable-xiaomi-lavender-boot.zip
By default it will flash to the
system partition. Some configurations may
change this to flash to the
userdata partition. In that case, no warning is
given before flashing.
fastboot oem getlog
This is the first device, and possibly the only device, known to ship with the
oem getlog fastboot command.
This is not a trivial command to use, but it is extremely useful as it allows side-stepping the need to boot in a known working system to use the ramoops console.
The output of the command is a jumble, but is still usable for figuring out early boot issues. It is much better than having to rely on a booted system to get the information, but still not as good as having a dedicated serial access.
Example usage follows.
$ fastboot oem getlog 2>&1 (bootloader) [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000 (bootloader) 000] Initializing cgroup subsys cpuset [ 0.000000] Initi (bootloader) alizing cgroup subsys cpu [ 0.000000] Initializing cgrou (bootloader) p subsys cpuacct [ 0.000000] Initializing cgroup subsys (bootloader) schedtune [ 0.000000] Linux version 4.4.153 (nixbld@loca (bootloader) lhost) (gcc version 4.9.4 (GCC) ) #2 SMP PREEMPT Sat Nov 23 (bootloader) 20:31:33 UTC 2019 [ 0.000000] Boot CPU: AArch64 Process (bootloader) or [51af8014] [...]
As the output of the command is on stderr, here’s how to output to a file.
$ fastboot oem getlog > log.txt 2>&1
It is unknown if there are ways to make the output better.