← Back to team overview

ubuntu-phone team mailing list archive

console argument at boot cmdline

 

   - "The device is in a bootloop or hangs on boot not showing up with adb
   shell: boot into recovery mode and adb pull /proc/last_kmsg to check the
   previous dmesg. Do not power off the device between the hang and booting
   into recovery as that likely leads to losing the ramconsole contents . Make
   sure you have proper permissions in the ramdisk and /init can start. Make
   sure you have a valid console=... argument on the kernel command line."


"Booting by default into the Ubuntu rootfs

To run Android in a container Ubuntu needs to become the default system we
are booting to. This is achieved by using a generic Ubuntu initramfs in the
phones boot.img instead of the Android supplied one.

The initramfs script that manages the booting lives in the
*initramfs-tools-ubuntu-touch* package. To get a binary initrd.img the
*ubuntu-touch-generic-initrd* package exists, this will always contain
the latest
binary initrd.img based n the last *initramfs-tools-ubuntu-touch* package
in the Ubuntu archive.

People that are porting their devices to the Ubuntu Touch container model
should take into account that Ubuntus upstart is used as init system.
Upstart likes to have an actually existing device as /dev/console. Many
Android kernels do not provide this as default or even have something
like console=none
or console=ram hardcoded in their boot commandline arguments. Such
drawbacks in the kernel or commandline need to be fixed to be able to use
this model properly (here <http://paste.ubuntu.com/5939625/> is for example
a kernel patch used on the i9100 image to change the behavior of
CONFIG_CMDLINE_EXTEND ... now using this option appends the kernel cmdline
to the bootloader one instead of pre-pending, this way console=tty1 can be
handed over as the last cmdline argument and withCONFIG_VT_CONSOLE and
CONFIG_HW_CONSOLE set in the kernel config upstart is now happy)"


So I'm getting a stuck on boot (splash screen, more specificly), and adb
didn't detect my device. I've installed google android drivers and my
device's drivers. Is it relevant with the first quote?
If yes then does "valid console=... argument" means something like
"console=ttySAC3" (this is the default on my device's kernel cmdline),
"console=tty1" (this is the one written in the container article)
"console=" (empty) or just no "console" argument?
I have tried the kernel patch example and enabled CONFIG_CMDLINE_EXTEND,
and the /proc/cmdline now has two console arguments, the first one is
"console=ttySAC3,115200n8", and the last one is "console=tty1,115200n8" But
it still doesn't boot.
And what does it mean by proper permissions in the ramdisk?

Thanks,

Rizqi