Booting Android from GRUB2 bootloader and Thinkpad Infos
6,794 views
Skip to first unread message
RetroAndMore
Nov 5, 2012, 12:51:32 PM11/5/12
to andro...@googlegroups.com
I added the infos from another thread, only with the important things and a new title, that it could be better found.
This will be a guide to install Android to HD, and how to integrate it into another Linux GRUB2 bootloader. So an operating system using GRUB2 is neccessary. If you want to install Android to a hard drive, you'll need a EXT3 formatted partition, no matter if it's primary or logical. DON'T INSTALL GRUB from the Android installer, otherwise you can't boot only Android. Booting Android from hard drive from is much faster, but it has one disadvantage: It doesn't allow booting from another installation from an USB stick, because it always searches for the first Android folder, and this is always the one on the harddisk. But it is possible to install more than one Android installation on one partition, you just have to use other names for the Android root directory.
This will be a guide to install Android to HD, and how to integrate it into another Linux GRUB2 bootloader. So an operating system using GRUB2 is neccessary. If you want to install Android to a hard drive, you'll need a EXT3 formatted partition, no matter if it's primary or logical. DON'T INSTALL GRUB from the Android installer, otherwise you can't boot only Android. Booting Android from hard drive from is much faster, but it has one disadvantage: It doesn't allow booting from another installation from an USB stick, because it always searches for the first Android folder, and this is always the one on the harddisk. But it is possible to install more than one Android installation on one partition, you just have to use other names for the Android root directory.
RetroAndMore
Nov 5, 2012, 12:54:28 PM11/5/12
to andro...@googlegroups.com
Here are the infos from testing with my Thinkpad X61 Tablet:
- SXGA+ 1400x1050 pixel support
- Audio works
- Bluetooth should work
- Wacom pen works great
- auto-rotation
- Display brigtness
- sleep mode with fn key
- SD card reader
What's not working:
- reactivating after Display sleep
- lid closing
- battery status is not perfect (27 min @ 70% battery?)
- Settings crahes in memory options (I have 8 GB installed)
There is the sleep problem, you can't reactivate the system after the screen is locked. The system reacts on key presses, plays music and also restarts on Ctrl-Alt-Del, but no reaction. The sleep timeout should be disabled in the Display preferences immediately. If the lid is closed, the system works on as always.
These keys have special key functions:
On the display bezel:
Display rotation button: Same function like the second symbol in the bottom (home?)
Reset knob: long press asks for Shutdown
Lenovo Toolbox button: Unknown or no function
Escape button: Back button, like Escape on the keyboard
Cursor block left/right: Volume up/down
Cursor block up/down: Unknown or no function
Middle enter button: Douple press reacts like klicking on the 'Google' symbol in the upper left corner
Upper keyboard special keys:
Escape: Back button
Volume mute key: no function
Volume up/down: They do what they should
ThinkVantage key: Unknown or no function
Power: long press asks for Shutdown
Lower keyboard special keys:
fn key: sets the system without request in sleep mode (moon symbol lightened). Pressing fn again wakes up the system, it's working.
Browser left key (left to Cursor up): Back Button /Escape key
Browser right key (right to Cursor up): Unknown or no function
Ctrl/Alt/Del: resets the computer without request
Ctrl/Alt/AltGr/Windows alone: Nothing in the system, maybe in the onscreen-keyboard
There's an interesting behaviour: If you play in the OpenManager music from an SD-card and press the fn key, the song will played till its end, then the system will enter sleep mode.
- SXGA+ 1400x1050 pixel support
- Audio works
- Bluetooth should work
- Wacom pen works great
- auto-rotation
- Display brigtness
- sleep mode with fn key
- SD card reader
What's not working:
- reactivating after Display sleep
- lid closing
- battery status is not perfect (27 min @ 70% battery?)
- Settings crahes in memory options (I have 8 GB installed)
There is the sleep problem, you can't reactivate the system after the screen is locked. The system reacts on key presses, plays music and also restarts on Ctrl-Alt-Del, but no reaction. The sleep timeout should be disabled in the Display preferences immediately. If the lid is closed, the system works on as always.
These keys have special key functions:
On the display bezel:
Display rotation button: Same function like the second symbol in the bottom (home?)
Reset knob: long press asks for Shutdown
Lenovo Toolbox button: Unknown or no function
Escape button: Back button, like Escape on the keyboard
Cursor block left/right: Volume up/down
Cursor block up/down: Unknown or no function
Middle enter button: Douple press reacts like klicking on the 'Google' symbol in the upper left corner
Upper keyboard special keys:
Escape: Back button
Volume mute key: no function
Volume up/down: They do what they should
ThinkVantage key: Unknown or no function
Power: long press asks for Shutdown
Lower keyboard special keys:
fn key: sets the system without request in sleep mode (moon symbol lightened). Pressing fn again wakes up the system, it's working.
Browser left key (left to Cursor up): Back Button /Escape key
Browser right key (right to Cursor up): Unknown or no function
Ctrl/Alt/Del: resets the computer without request
Ctrl/Alt/AltGr/Windows alone: Nothing in the system, maybe in the onscreen-keyboard
There's an interesting behaviour: If you play in the OpenManager music from an SD-card and press the fn key, the song will played till its end, then the system will enter sleep mode.
Chih-Wei Huang
Nov 5, 2012, 1:31:29 PM11/5/12
to andro...@googlegroups.com
Thank you for the good document.
About unable to booting from another installation from an USB,
that's not quite correct. That's only true if both versions of
HD and USB are same. But you can workaround it by
specifying ROOT= in cmdline, or
rename the installed dir and change SRC.
For video= cmdline, if you are using i915 or radeon driver,
that's no effect and so unnecessary.
To change dpi, specify DPI=... not dpi=...
But 145 may not be a valid value, I think.
2012/11/6 RetroAndMore <retro....@gmail.com>:
About unable to booting from another installation from an USB,
that's not quite correct. That's only true if both versions of
HD and USB are same. But you can workaround it by
specifying ROOT= in cmdline, or
rename the installed dir and change SRC.
For video= cmdline, if you are using i915 or radeon driver,
that's no effect and so unnecessary.
To change dpi, specify DPI=... not dpi=...
But 145 may not be a valid value, I think.
2012/11/6 RetroAndMore <retro....@gmail.com>:
RetroAndMore
Nov 5, 2012, 2:05:28 PM11/5/12
to andro...@googlegroups.com
Well, I created the GRUB2 entry partitally from the Ubuntu entry, some values from the Android-x86 installation CD and some other sources. So ROOT is /dev/ram0 like usual. What alternative path could be used? Renaming folders would be no method, if you have your HD system installed by the original installer, and want to repair this system by a USB version of the same installer, it always would access the hard disk.
To display and dpi settings: The 1400x1050 SGXA+ display is not common, so it has no common dpi value. I serached the net and found something like 140 or 145 dpi. They could vary depending of the manufacurer. I don't know either if they have any effect. By the way, I don't think that GRUB is case-sensitive.
For the next versions of Android-x86, I would recommand a change completely to GRUB2, with some new options during the installation. The /boot/grub/ folder is always copied, but it should be asked if the bootloader should be installed on the MBR or on the partition only. The manual Ubuntu installation also has this selection, but it's very difficult to see. If MBR is selected, a second request should come, with the info that bootloaders using the MBR will be overwritten. If another Linux with a GRUB2 bootloader is detected, the Android entries should be integrated in it. There also should be a request if autodetection of the Android folder is enabled or that it is fixed to the installed partition. I'm not sure if this is possible.
And very important: integrate the Atheros 5000 WLAN driver in the Thinkpad version. Without internet is Android nearly useless.
To display and dpi settings: The 1400x1050 SGXA+ display is not common, so it has no common dpi value. I serached the net and found something like 140 or 145 dpi. They could vary depending of the manufacurer. I don't know either if they have any effect. By the way, I don't think that GRUB is case-sensitive.
For the next versions of Android-x86, I would recommand a change completely to GRUB2, with some new options during the installation. The /boot/grub/ folder is always copied, but it should be asked if the bootloader should be installed on the MBR or on the partition only. The manual Ubuntu installation also has this selection, but it's very difficult to see. If MBR is selected, a second request should come, with the info that bootloaders using the MBR will be overwritten. If another Linux with a GRUB2 bootloader is detected, the Android entries should be integrated in it. There also should be a request if autodetection of the Android folder is enabled or that it is fixed to the installed partition. I'm not sure if this is possible.
And very important: integrate the Atheros 5000 WLAN driver in the Thinkpad version. Without internet is Android nearly useless.
Chih-Wei Huang
Nov 5, 2012, 8:01:40 PM11/5/12
to andro...@googlegroups.com
I said ROOT, not root.
(It's always case-sensitive in the unix/linux/android world)
Setting ROOT to the partition (e.g., /dev/sdb1)
you installed can avoid auto searching the SRC dir.
2012/11/6 RetroAndMore <retro....@gmail.com>:
--
Chih-Wei
Android-x86 project
http://www.android-x86.org
(It's always case-sensitive in the unix/linux/android world)
Setting ROOT to the partition (e.g., /dev/sdb1)
you installed can avoid auto searching the SRC dir.
2012/11/6 RetroAndMore <retro....@gmail.com>:
Chih-Wei
Android-x86 project
http://www.android-x86.org
RetroAndMore
Nov 5, 2012, 9:24:15 PM11/5/12
to andro...@googlegroups.com
The important thing is not the bootloader, it's the file system, there's the place it's important if if is lowercase or not. I presume the most Unix filesystems are case-sensitive, but normally all paths are in lowercase. MacOS X has HFS+ in a case-sensitive and non-case-sensitive version, usually the non-case-sensitive version is used. The FAT12, FAT16, FAT32 aren't case-sensitive, I think NTFS has an option for this. Operating systems from the Amiga (OFS, FFS, SFS, PFS) are usually non-case-sensitive, but I think were optional case-sensitive versions. The filesystems from 8bit-Commodore computers (C64 and so on) were highly character-sensitive because you could even use graphical symbols or even pure ASCII-codes as filenames.
GRUB is not Linux or Unix, it's a system-independent bootloader, you can write the command text in lower or upper case that's not a problem. Standard is lowercase, the Ubuntu bootloader is also completely written in lower case. Only if you have to access an case-sensitive filesystem, then you have to use correct upper- and lowercase.
I have used the SRC= option in my GRUB2 entry for the kernel, I only haven't set the device, because the root partition is already difined with the root="(hd0,7)" option of GRUB2. At least it should be. Setting the root device on a hard disk installed Android wouldn't be neccessary anyway, except you would have multiple instances of the same installation on different partitions, which would be a rather unusual configuration. The important thing is that an external used USB installation has to use the one which is installed on the USB stick, not the one on hard disk. The root path for the kernel in the actual installation is /dev/ram0 like in the kernel options of the original legacy GRUB specified. I could only imagine that this method is used to run the Android root on a ram disk for a live system or to enhance the speed of slow USB devices. But a pure harddisk installation root should use the harddrive for everything. I added a new GRUB2 entry which should use the harddisk as root:
linux /android-4.0-RC2/kernel root=/android-4.0-RC2/ androidboot.hardware=thinkpad video=1400x1050 dpi=145 i915downclock=1 i915.powersave=1 usbcore.autosuspend=2 SRC=/android-4.0-RC2/
Everything seems normal. If I disable the ramdisk mounting with #initrd /android-4.0-RC2/initrd.img, the system crashes with a kernel panic. So I presume Android is still using the ramdisk, although a root path to the harddisk partition is specified.
Android was designed for tablets or smartphones, it don't think it was inteded to run on normal computers from harddisks, maybe even with multiple installations and additional USB boot systems. But on a desktop PC, TabletPC or Laptop/Netbook are other possibilites. You aren't fixed of one Android system, you could modify your installation from another Linux distro and using more installations on the same partition. And Android-x86 has to deal with that. Autodetecting an Android folder would be working with one installation - like on tablets - but not on normal PCs. Very important things would be EXT4 and GRUB2 integration, so Android could be installed on every Linux distro without using an own partition. Root shouldn't be a RAM disk anymore, it should be on the physical drive, like on all other operating systems. I don't know the internals of Android, but I couldn't imagine that Android on tablets (which have not too much RAM) creates an extra ram disk for running the OS. Correct mounting of FAT32 partitions of the harddisk should also be possible for data exchange.
GRUB is not Linux or Unix, it's a system-independent bootloader, you can write the command text in lower or upper case that's not a problem. Standard is lowercase, the Ubuntu bootloader is also completely written in lower case. Only if you have to access an case-sensitive filesystem, then you have to use correct upper- and lowercase.
I have used the SRC= option in my GRUB2 entry for the kernel, I only haven't set the device, because the root partition is already difined with the root="(hd0,7)" option of GRUB2. At least it should be. Setting the root device on a hard disk installed Android wouldn't be neccessary anyway, except you would have multiple instances of the same installation on different partitions, which would be a rather unusual configuration. The important thing is that an external used USB installation has to use the one which is installed on the USB stick, not the one on hard disk. The root path for the kernel in the actual installation is /dev/ram0 like in the kernel options of the original legacy GRUB specified. I could only imagine that this method is used to run the Android root on a ram disk for a live system or to enhance the speed of slow USB devices. But a pure harddisk installation root should use the harddrive for everything. I added a new GRUB2 entry which should use the harddisk as root:
linux /android-4.0-RC2/kernel root=/android-4.0-RC2/ androidboot.hardware=thinkpad video=1400x1050 dpi=145 i915downclock=1 i915.powersave=1 usbcore.autosuspend=2 SRC=/android-4.0-RC2/
Everything seems normal. If I disable the ramdisk mounting with #initrd /android-4.0-RC2/initrd.img, the system crashes with a kernel panic. So I presume Android is still using the ramdisk, although a root path to the harddisk partition is specified.
Android was designed for tablets or smartphones, it don't think it was inteded to run on normal computers from harddisks, maybe even with multiple installations and additional USB boot systems. But on a desktop PC, TabletPC or Laptop/Netbook are other possibilites. You aren't fixed of one Android system, you could modify your installation from another Linux distro and using more installations on the same partition. And Android-x86 has to deal with that. Autodetecting an Android folder would be working with one installation - like on tablets - but not on normal PCs. Very important things would be EXT4 and GRUB2 integration, so Android could be installed on every Linux distro without using an own partition. Root shouldn't be a RAM disk anymore, it should be on the physical drive, like on all other operating systems. I don't know the internals of Android, but I couldn't imagine that Android on tablets (which have not too much RAM) creates an extra ram disk for running the OS. Correct mounting of FAT32 partitions of the harddisk should also be possible for data exchange.
Chih-Wei Huang
Nov 5, 2012, 10:05:35 PM11/5/12
to andro...@googlegroups.com
You spent a lot of time to argue but
didn't give it a try.
Let me say again.
Use ROOT=/dev/sdX to specify the partition you installed.
If you think you know the init process (I wrote)
better than me, I have nothing to say.
2012/11/6 RetroAndMore <retro....@gmail.com>:
didn't give it a try.
Let me say again.
Use ROOT=/dev/sdX to specify the partition you installed.
If you think you know the init process (I wrote)
better than me, I have nothing to say.
2012/11/6 RetroAndMore <retro....@gmail.com>:
RetroAndMore
Nov 6, 2012, 8:04:59 AM11/6/12
to andro...@googlegroups.com
*sigh*
I now tested the kernel options
linux /android-4.0-RC2/kernel root=/dev/ram0 and linux /android-4.0-RC2/kernel ROOT=/dev/ram0
and both versions worked fine, like I expected. Then I replaced every occurrence of /android-4.0-RC2/ with /AnDrOiD-4.0-Rc2/ in the kernel options, and, like to expect, the kernal was not found because the file system ist case-sensitive.
I've checked now a bit, GRUB is case-sensitive, but most commands are lowercase and will not work in uppercase. Infos: https://wiki.archlinux.org/index.php/Kernel_parameters
Because it still booted as the option was called ROOT (in uppercase), I made more tests: I can even completely disable the root option. That means the Android bootsequence ignores some settings from the bootloader. This makes it perhaps easier for standard user with a test installation, but it's not good for experienced users who want to use more versions and/or to change options with the bootloader.
If you take a look in your Android-x86 installation CD, the file /isolinux/isolinux.cfg is completely written in lowercase as well as /grub/menu.lst/ in an actual Android installation. That's where you could see that your installation uses the old legacy GRUB, the GRUB2 config file is located in /boot/grub/grub.cfg, in every operating system. Legacy GRUB also has another script language format, so you could use my infos if you want to switch to GRUB2, which is highly recommended, because all Linux distros are using GRUB2.
I hope this Case-sensitive/insensitive topic is finished now. I definitively can say to you that it works on my system - you can test it yourself. The more important problem is, that the actual Android build can't accept a harddisk installed version and an USB boot version for rescue of testing modes, it only boots from the first available Android folder of the same version. You can easily see it when you boot from USB because of the message
Detecting Android-x86... booting from /dev/sda7
You can't used a fixed device for an USB stick, because it ist treated like a hard disk. If you boot from the CD, it works and the message is
Detecting Android-x86... booting from /dev/sr0
I presume because this is the live version, which is not read/writeable. This is a different folder/image or whatever as the installation on the hard drive. If I install a not read/writeable system to an USB stick, it boots again from /dev/sda7. So it's definetively a problem in the Android-x86 system bootsequence, not the GRUB bootloader entry. Nevertheless, if you have Android on a hard drive and a Linux distro installed, it is nearly unneccesary to use a second version from USB, because you can repair most parts of the Android installation much easier from the Linux distro. But it is a bug - or at least a strange behaviour - so you should take a look at this problem.
I now tested the kernel options
linux /android-4.0-RC2/kernel root=/dev/ram0 and linux /android-4.0-RC2/kernel ROOT=/dev/ram0
and both versions worked fine, like I expected. Then I replaced every occurrence of /android-4.0-RC2/ with /AnDrOiD-4.0-Rc2/ in the kernel options, and, like to expect, the kernal was not found because the file system ist case-sensitive.
I've checked now a bit, GRUB is case-sensitive, but most commands are lowercase and will not work in uppercase. Infos: https://wiki.archlinux.org/index.php/Kernel_parameters
Because it still booted as the option was called ROOT (in uppercase), I made more tests: I can even completely disable the root option. That means the Android bootsequence ignores some settings from the bootloader. This makes it perhaps easier for standard user with a test installation, but it's not good for experienced users who want to use more versions and/or to change options with the bootloader.
If you take a look in your Android-x86 installation CD, the file /isolinux/isolinux.cfg is completely written in lowercase as well as /grub/menu.lst/ in an actual Android installation. That's where you could see that your installation uses the old legacy GRUB, the GRUB2 config file is located in /boot/grub/grub.cfg, in every operating system. Legacy GRUB also has another script language format, so you could use my infos if you want to switch to GRUB2, which is highly recommended, because all Linux distros are using GRUB2.
I hope this Case-sensitive/insensitive topic is finished now. I definitively can say to you that it works on my system - you can test it yourself. The more important problem is, that the actual Android build can't accept a harddisk installed version and an USB boot version for rescue of testing modes, it only boots from the first available Android folder of the same version. You can easily see it when you boot from USB because of the message
Detecting Android-x86... booting from /dev/sda7
You can't used a fixed device for an USB stick, because it ist treated like a hard disk. If you boot from the CD, it works and the message is
Detecting Android-x86... booting from /dev/sr0
I presume because this is the live version, which is not read/writeable. This is a different folder/image or whatever as the installation on the hard drive. If I install a not read/writeable system to an USB stick, it boots again from /dev/sda7. So it's definetively a problem in the Android-x86 system bootsequence, not the GRUB bootloader entry. Nevertheless, if you have Android on a hard drive and a Linux distro installed, it is nearly unneccesary to use a second version from USB, because you can repair most parts of the Android installation much easier from the Linux distro. But it is a bug - or at least a strange behaviour - so you should take a look at this problem.
RetroAndMore
Nov 6, 2012, 8:25:44 AM11/6/12
to andro...@googlegroups.com
I tried something else: I installed again a read/writeable system on USB, and added a new boot entry on the bootloader in my harddisk. The GRUB2 entry to specify the first partition of the second harddisk (which is the USB stick) as root is called
set root="(hd1,1)"
You could see Android started botting from USB stick because the access LED from the stick was flickering. But after a while the well-known message appeared:
Detecting Android-x86... booting from /dev/sda7
I think now it should be clear that Andoid always boots from the first installation, which is /dev/sda7 (hd0,7 in GRUB) instead of /dev/sdb1 (hd1,1 in GRUB), although the system was booted from hd1,1.
By the way, you can't specify a fixed device name for an USB stick anyway, if you have another one in the system and put then the Android stick in it, this one would he hd2,1.
set root="(hd1,1)"
You could see Android started botting from USB stick because the access LED from the stick was flickering. But after a while the well-known message appeared:
Detecting Android-x86... booting from /dev/sda7
By the way, you can't specify a fixed device name for an USB stick anyway, if you have another one in the system and put then the Android stick in it, this one would he hd2,1.
Chih-Wei Huang
Nov 6, 2012, 9:31:21 AM11/6/12
to andro...@googlegroups.com
OOPS...
You are wasting your time in a wrong direction.
Maybe I didn't state it clearly enough.
root= and ROOT= are different options in
Android-x86 boot system.
The prior is parsed by kernel itself,
while the latter is used by the boot script
to determine the installed partition.
In your case, just set ROOT=/dev/sdb1
2012/11/6 RetroAndMore <retro....@gmail.com>:
You are wasting your time in a wrong direction.
Maybe I didn't state it clearly enough.
root= and ROOT= are different options in
Android-x86 boot system.
The prior is parsed by kernel itself,
while the latter is used by the boot script
to determine the installed partition.
In your case, just set ROOT=/dev/sdb1
2012/11/6 RetroAndMore <retro....@gmail.com>:
jpcw...@gmail.com
Nov 6, 2012, 8:36:48 AM11/6/12
to andro...@googlegroups.com
뭐가 그리 어렵니. 단계적으로 하면 별일도 아닌데
BlackBerry® 에서 보냈습니다.
From: RetroAndMore <retro....@gmail.com>
Sender: andro...@googlegroups.com
Date: Tue, 6 Nov 2012 05:25:44 -0800 (PST)
ReplyTo: andro...@googlegroups.com
Subject: Re: Booting Android from GRUB2 bootloader and Thinkpad Infos
--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-x86/-/Ujx-qXuG9j8J.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-x86...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-x86?hl=en.
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-x86/-/Ujx-qXuG9j8J.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-x86...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-x86?hl=en.
RetroAndMore
Nov 6, 2012, 12:54:36 PM11/6/12
to andro...@googlegroups.com
*sigh again*
Possibly you got something wrong. I was always talking about the bootloader (GRUB2 used in Linux and AROS or GRUB legacy used in your installation), I never changed a file in Android, to be exact in the /Android-4.0-RC2/ folder. I only modified SYS:boot/grub/grub.cfg on my AROS* partition, and the /grub/menu.lst on the USB Android istallation. That is also the only thing what's neccessary to get Android booting, and it works. The only problem is, that Android boots from the first system found on the computer, but that is no problem of GRUB2, it's a problem somewhere in the Android boot sequence. But I'm not changing it because I'm no developer. Here are GRUB command overviews, you'll never find an uppercase ROOT on both pages.
GRUB2: https://wiki.archlinux.org/index.php/GRUB
GRUB Legacy: https://wiki.archlinux.org/index.php/GRUB_Legacy
And to be exact, I added ROOT=/dev/sdb1 to the kernel options, and as to expect Android began to boot from USB, then it switched to /dev/hda7. I already mentioned that the option root and ROOT (in uppercase) of the kernel option in GRUB2 are ignored from Android.
Maybe there may something not correct because I'm new to Linux and everything I know about GRUB2, GRUB Legacy, Ubuntu and Android is 8 days old. But I'm doing internal stuff on various computer systems for more than 22 years and have worked with about 20-30 operating systems (including revisions, but no Linux in them). The stuff with GRUB what I learned in this short time was not for therory, I wanted to get Android booting from GRUB2, and I did it. Every problem I described is tested, you can only check it if you test it yourself. If you have some files, mail them to me and I'll test it.
* I'm using the AROS version of GRUB2 for the bootloader, but it also worked from Ubuntu's GRUB2. AROS is an x86 port of AmigaOS 3.1 using the SFS file system, which is not case-sensitive and has no user permissions, normally all files have r/w access. It boots very fast and because you don't have to deal with permissions it's very easy to modify the GRUB2 configuration. Root is called SYS: on AmigaOS or AROS. The partition on the harddisk is the second primary partition (hd0,2 in GRUB and /dev/sda2 in Linux), but the partition type/filesystem is named 'unknown' in all operation systems because they don't know the RDB (Rigid Disk Block) bootblock and partition table. AROS uses a multiboot entry in GRUB2 to boot its own system, it doesn't use the typical linux kernel options.
Possibly you got something wrong. I was always talking about the bootloader (GRUB2 used in Linux and AROS or GRUB legacy used in your installation), I never changed a file in Android, to be exact in the /Android-4.0-RC2/ folder. I only modified SYS:boot/grub/grub.cfg on my AROS* partition, and the /grub/menu.lst on the USB Android istallation. That is also the only thing what's neccessary to get Android booting, and it works. The only problem is, that Android boots from the first system found on the computer, but that is no problem of GRUB2, it's a problem somewhere in the Android boot sequence. But I'm not changing it because I'm no developer. Here are GRUB command overviews, you'll never find an uppercase ROOT on both pages.
GRUB2: https://wiki.archlinux.org/index.php/GRUB
GRUB Legacy: https://wiki.archlinux.org/index.php/GRUB_Legacy
And to be exact, I added ROOT=/dev/sdb1 to the kernel options, and as to expect Android began to boot from USB, then it switched to /dev/hda7. I already mentioned that the option root and ROOT (in uppercase) of the kernel option in GRUB2 are ignored from Android.
Maybe there may something not correct because I'm new to Linux and everything I know about GRUB2, GRUB Legacy, Ubuntu and Android is 8 days old. But I'm doing internal stuff on various computer systems for more than 22 years and have worked with about 20-30 operating systems (including revisions, but no Linux in them). The stuff with GRUB what I learned in this short time was not for therory, I wanted to get Android booting from GRUB2, and I did it. Every problem I described is tested, you can only check it if you test it yourself. If you have some files, mail them to me and I'll test it.
* I'm using the AROS version of GRUB2 for the bootloader, but it also worked from Ubuntu's GRUB2. AROS is an x86 port of AmigaOS 3.1 using the SFS file system, which is not case-sensitive and has no user permissions, normally all files have r/w access. It boots very fast and because you don't have to deal with permissions it's very easy to modify the GRUB2 configuration. Root is called SYS: on AmigaOS or AROS. The partition on the harddisk is the second primary partition (hd0,2 in GRUB and /dev/sda2 in Linux), but the partition type/filesystem is named 'unknown' in all operation systems because they don't know the RDB (Rigid Disk Block) bootblock and partition table. AROS uses a multiboot entry in GRUB2 to boot its own system, it doesn't use the typical linux kernel options.
Chih-Wei Huang
Nov 6, 2012, 8:48:46 PM11/6/12
to andro...@googlegroups.com
Hey, please be modest since you just learned it 8 days.
(do you have any idea who I am?)
ROOT is used to avoid auto searching partitions.
It's just the answer to your question.
It's nothing to do with what bootloader you use.
If you want to know how it works, read the code of
the boot script (I wrote) and try to understand it:
http://git.android-x86.org/?p=platform/bootable/newinstaller.git;a=blob;f=initrd/init;h=5d747c54ca6ec6d523c0ff7d966095e053718a62;hb=28f6af212cd0cbc879b7593de434f77bf34e87c0
To ensure your cmdline is set correctly,
after android-x86 boot complete, open a terminal and type
cat /proc/cmdline
Show us what it is exactly.
This is the last time I tried to help you.
If you still cannot get it work, that's your problem
since you refuse to learn how it works.
2012/11/7 RetroAndMore <retro....@gmail.com>:
(do you have any idea who I am?)
ROOT is used to avoid auto searching partitions.
It's just the answer to your question.
It's nothing to do with what bootloader you use.
If you want to know how it works, read the code of
the boot script (I wrote) and try to understand it:
http://git.android-x86.org/?p=platform/bootable/newinstaller.git;a=blob;f=initrd/init;h=5d747c54ca6ec6d523c0ff7d966095e053718a62;hb=28f6af212cd0cbc879b7593de434f77bf34e87c0
To ensure your cmdline is set correctly,
after android-x86 boot complete, open a terminal and type
cat /proc/cmdline
Show us what it is exactly.
This is the last time I tried to help you.
If you still cannot get it work, that's your problem
since you refuse to learn how it works.
2012/11/7 RetroAndMore <retro....@gmail.com>:
RetroAndMore
Nov 7, 2012, 1:39:53 AM11/7/12
to andro...@googlegroups.com
On Wednesday, November 7, 2012 2:49:00 AM UTC+1, Chih-Wei Huang wrote:
Hey, please be modest since you just learned it 8 days.
(do you have any idea who I am?)
No, but do you have an idea who I am? But it this important?
ROOT is used to avoid auto searching partitions.
It's just the answer to your question.
It's nothing to do with what bootloader you use.
If you want to know how it works, read the code of
the boot script (I wrote) and try to understand it:
http://git.android-x86.org/?p=platform/bootable/newinstaller.git;a=blob;f=initrd/init;h=5d747c54ca6ec6d523c0ff7d966095e053718a62;hb=28f6af212cd0cbc879b7593de434f77bf34e87c0
Yay, that's the thing I was always talking about: I was never mentioning a script inside Android, only the GRUB2 bootloader which is only selection. Now to the next thing. I booted Android from hard disk and opened the Terminal Emulation, after cat /proc/cmdline I got a permission error. So I used su cat /proc/cmdline, then I got superuser access. The text output is:
BOOT_IMAGE=/android-4.0-RC2/kernel /root=/dev/ram0 androidboot.hardware=thinkpad quiet video=1400x1050 dpi=145 i915downclock=1 i915.powersave=1 usbcore.autosuspend=2 SRC=/android-4.0-RC2/
That's exact the same line like in the GRUB2 bootloader, except the BOOT_IMAGE= option.
The occurrences of ROOT in your script remind me more on variables than on kernel options. They're always beginning with $ like in many other scripting languages and they're always used in comparisons:
if [ "${ROOT#*:/}" != "$ROOT" ]; then
# for NFS roots, use nolock to avoid dependency to portmapper
RW="nolock,$RW"
fi
$ROOT is an environment variable, like $rc contains the last error code of an AmigaDOS command. $result2 contains the error code of the last AmigaDOS error (file not found etc).
I found something about Unix variables here:
http://www.tutorialspoint.com/unix/unix-environment.htm
http://www.tutorialspoint.com/unix/unix-special-variables.htm
http://osr600doc.sco.com/en/manADM/idbuild.ADM.html
If Unix/Linux variables are case sensitive, then you have to write them in correct case. But this is something different that the GRUB2 bootloader, it has nothing to do with Unix/Linux and uses its own commands.
Chih-Wei Huang
Nov 7, 2012, 3:20:43 AM11/7/12
to andro...@googlegroups.com
2012/11/7 RetroAndMore <retro....@gmail.com>:
The bootloader won't touch the cmdline.
It will just pass to the kernel, and the kernel will
set that to the environment of init process.
You don't need to know the details (if you don't want to know),
just do what I told you to do.
> Now to the next thing. I booted Android from hard disk and opened the
> Terminal Emulation, after cat /proc/cmdline I got a permission error. So I
> used su cat /proc/cmdline, then I got superuser access. The text output is:
>
> BOOT_IMAGE=/android-4.0-RC2/kernel /root=/dev/ram0
> androidboot.hardware=thinkpad quiet video=1400x1050 dpi=145 i915downclock=1
> i915.powersave=1 usbcore.autosuspend=2 SRC=/android-4.0-RC2/
You still didn't do it.
Say again. Add ROOT=/dev/sdb1 to cmdline.
Let me see if show up in your /proc/cmdline
If you don't do it or don't want to do it but
try to argue more, you are wasting everybody's time!
> Yay, that's the thing I was always talking about: I was never mentioning a
> script inside Android, only the GRUB2 bootloader which is only selection.
Sigh...
> script inside Android, only the GRUB2 bootloader which is only selection.
The bootloader won't touch the cmdline.
It will just pass to the kernel, and the kernel will
set that to the environment of init process.
You don't need to know the details (if you don't want to know),
just do what I told you to do.
> Now to the next thing. I booted Android from hard disk and opened the
> Terminal Emulation, after cat /proc/cmdline I got a permission error. So I
> used su cat /proc/cmdline, then I got superuser access. The text output is:
>
> BOOT_IMAGE=/android-4.0-RC2/kernel /root=/dev/ram0
> androidboot.hardware=thinkpad quiet video=1400x1050 dpi=145 i915downclock=1
> i915.powersave=1 usbcore.autosuspend=2 SRC=/android-4.0-RC2/
Say again. Add ROOT=/dev/sdb1 to cmdline.
Let me see if show up in your /proc/cmdline
If you don't do it or don't want to do it but
try to argue more, you are wasting everybody's time!
RetroAndMore
Nov 7, 2012, 1:30:41 PM11/7/12
to andro...@googlegroups.com
Wow, you're a tough guy if you have an option. But me too ;)
I added ROOT=/dev/sdb1 to the GRUB2 kernel entry. The effect was, that it began booting from USB, but then it found no Android directory at all and hanged at Detecting Android.... Anyway, it would be useless to assign a fixed device entry to an USB device, if a second harddisk or a second USB stick is plugged into the system, this installation wouldn't work anymore.
And to complete it, I booted a fresh installation from USB, and it accessed it from /dev/sda7. The Android Terminal Emulation showed this output:
quiet /root=/dev/ram0 androidboot.hardware=thinkpad quiet video=1024x768 i915downclock=1 i915.powersave=1 usbcore.autosuspend=2 SRC=/android-4.0-RC2
The options are different because they are used from the original GRUB Legacy bootbloader used from the original installation, not my modified version of GRUB2.
You can look at it by yourself, I made some photos and some videos of the screen. http://www.mediafire.com/?30637btk17sn9gs
The archive is 16 MB in size and contains two avis and to jpgs. The video quality is not the best, the camera is rather old and wasn't designed for videos.
I also tried something different: I replaced BOOT=/dev/sdb1 with $BOOT=/dev/sdb1, because it is a variable and not a boot option in upper chars. The variable will be parsed to the system, with the result that it didn't hang at Detecting Android.... But it continued booting at /dev/sda7.
Like I said, I don't know about Unix shell scripting yet. You could solve the problem if the boot script searches for the Android directory only on the partition (/dev/sdx,y) from which the system is booted, not on all available devices on the whole computer system. Is this possible to find out in Unix scripts?
I added ROOT=/dev/sdb1 to the GRUB2 kernel entry. The effect was, that it began booting from USB, but then it found no Android directory at all and hanged at Detecting Android.... Anyway, it would be useless to assign a fixed device entry to an USB device, if a second harddisk or a second USB stick is plugged into the system, this installation wouldn't work anymore.
And to complete it, I booted a fresh installation from USB, and it accessed it from /dev/sda7. The Android Terminal Emulation showed this output:
quiet /root=/dev/ram0 androidboot.hardware=thinkpad quiet video=1024x768 i915downclock=1 i915.powersave=1 usbcore.autosuspend=2 SRC=/android-4.0-RC2
The options are different because they are used from the original GRUB Legacy bootbloader used from the original installation, not my modified version of GRUB2.
You can look at it by yourself, I made some photos and some videos of the screen. http://www.mediafire.com/?30637btk17sn9gs
The archive is 16 MB in size and contains two avis and to jpgs. The video quality is not the best, the camera is rather old and wasn't designed for videos.
I also tried something different: I replaced BOOT=/dev/sdb1 with $BOOT=/dev/sdb1, because it is a variable and not a boot option in upper chars. The variable will be parsed to the system, with the result that it didn't hang at Detecting Android.... But it continued booting at /dev/sda7.
Like I said, I don't know about Unix shell scripting yet. You could solve the problem if the boot script searches for the Android directory only on the partition (/dev/sdx,y) from which the system is booted, not on all available devices on the whole computer system. Is this possible to find out in Unix scripts?
RetroAndMore
Nov 7, 2012, 3:40:43 PM11/7/12
to andro...@googlegroups.com
Well, you told me to use the cat /proc/cmdline command, but you didn't told me what it did at all, it parses all kernel options to /proc/cmdline. So I noticed the the $ROOT= kernel option test is not really useful, it only parses the path behind it. Because I experimented a bit with how to set variables in Unix (it works different than in other scripting languages I know) I tried to use ROOT="/dev/sda7" and ROOT="/dev/sda7/Android-4.0-RC2" as kernel options. This resulted in a boot from the specified device (USB or HD), but an endless search for the Android folder, more and more dots appeared. But at least it was interesing because both boot sequences had identical behavior, and they didn't hang because the number of dots increased. Any ideas?
I noticed something else: If I boot any installation of Android and check the list of used variables in Terminal with set, the variable ROOT does not exist. It seems to be a local variable, is it neccessary in other scripts or in the system, so would it be useful to change it to a global variable?
How is it possible to extract and recreate the initrd.img file, I'd like to add some checks. I searched the Ubuntu software center but didn't found something useful, and the internet shows only stuff about .img CD images. You could mail me infos to my google mail adress if you don't want to post this it in the public.
I noticed something else: If I boot any installation of Android and check the list of used variables in Terminal with set, the variable ROOT does not exist. It seems to be a local variable, is it neccessary in other scripts or in the system, so would it be useful to change it to a global variable?
How is it possible to extract and recreate the initrd.img file, I'd like to add some checks. I searched the Ubuntu software center but didn't found something useful, and the internet shows only stuff about .img CD images. You could mail me infos to my google mail adress if you don't want to post this it in the public.
Chih-Wei Huang
Nov 7, 2012, 10:34:01 PM11/7/12
to andro...@googlegroups.com
2012/11/8 RetroAndMore <retro....@gmail.com>:
You specified ROOT correctly to cmdline and
it had effect -- that's why it stuck at Detecting stage.
Auto searching is disabled (by ROOT variable), but
/dev/sdb1 is not the correct partition of your USB installation.
So what you need to do now is just find the correct partition
(maybe you have more than one USB plugged? try /dev/sdc1, ...)
and set it to ROOT.
As said before, another way you can try is
rename the installed dir in USB
(say, /android-4.0-RC2 -> /android-4.0-RC2-usb)
and change SRC to /android-4.0-RC2-usb.
This can also avoid the conflict between HD and USB.
> And to complete it, I booted a fresh installation from USB, and it accessed
> it from /dev/sda7. The Android Terminal Emulation showed this output:
>
> quiet /root=/dev/ram0 androidboot.hardware=thinkpad quiet video=1024x768
> i915downclock=1 i915.powersave=1 usbcore.autosuspend=2 SRC=/android-4.0-RC2
>
> The options are different because they are used from the original GRUB
> Legacy bootbloader used from the original installation, not my modified
> version of GRUB2.
The test doesn't make sense since
you didn't specify ROOT or change SRC.
> You can look at it by yourself, I made some photos and some videos of the
> screen. http://www.mediafire.com/?30637btk17sn9gs
> The archive is 16 MB in size and contains two avis and to jpgs. The video
> quality is not the best, the camera is rather old and wasn't designed for
> videos.
>
> I also tried something different: I replaced BOOT=/dev/sdb1 with
> $BOOT=/dev/sdb1, because it is a variable and not a boot option in upper
> chars. The variable will be parsed to the system, with the result that it
> didn't hang at Detecting Android.... But it continued booting at /dev/sda7.
This doesn't make sense, either.
BOOT is not a variable that the boot script will use.
> Wow, you're a tough guy if you have an option. But me too ;)
>
> I added ROOT=/dev/sdb1 to the GRUB2 kernel entry. The effect was, that it
> began booting from USB, but then it found no Android directory at all and
> hanged at Detecting Android.... Anyway, it would be useless to assign a
> fixed device entry to an USB device, if a second harddisk or a second USB
> stick is plugged into the system, this installation wouldn't work anymore.
OK. Now you made some progress.
>
> I added ROOT=/dev/sdb1 to the GRUB2 kernel entry. The effect was, that it
> began booting from USB, but then it found no Android directory at all and
> hanged at Detecting Android.... Anyway, it would be useless to assign a
> fixed device entry to an USB device, if a second harddisk or a second USB
> stick is plugged into the system, this installation wouldn't work anymore.
You specified ROOT correctly to cmdline and
it had effect -- that's why it stuck at Detecting stage.
Auto searching is disabled (by ROOT variable), but
/dev/sdb1 is not the correct partition of your USB installation.
So what you need to do now is just find the correct partition
(maybe you have more than one USB plugged? try /dev/sdc1, ...)
and set it to ROOT.
As said before, another way you can try is
rename the installed dir in USB
(say, /android-4.0-RC2 -> /android-4.0-RC2-usb)
and change SRC to /android-4.0-RC2-usb.
This can also avoid the conflict between HD and USB.
> And to complete it, I booted a fresh installation from USB, and it accessed
> it from /dev/sda7. The Android Terminal Emulation showed this output:
>
> quiet /root=/dev/ram0 androidboot.hardware=thinkpad quiet video=1024x768
> i915downclock=1 i915.powersave=1 usbcore.autosuspend=2 SRC=/android-4.0-RC2
>
> The options are different because they are used from the original GRUB
> Legacy bootbloader used from the original installation, not my modified
> version of GRUB2.
you didn't specify ROOT or change SRC.
> You can look at it by yourself, I made some photos and some videos of the
> screen. http://www.mediafire.com/?30637btk17sn9gs
> The archive is 16 MB in size and contains two avis and to jpgs. The video
> quality is not the best, the camera is rather old and wasn't designed for
> videos.
>
> I also tried something different: I replaced BOOT=/dev/sdb1 with
> $BOOT=/dev/sdb1, because it is a variable and not a boot option in upper
> chars. The variable will be parsed to the system, with the result that it
> didn't hang at Detecting Android.... But it continued booting at /dev/sda7.
BOOT is not a variable that the boot script will use.
RetroAndMore
Nov 7, 2012, 11:01:34 PM11/7/12
to andro...@googlegroups.com
No, I've done enough. All these tests are showing that the problem is not depending on the GRUB2 bootloader entry, it's a problem in your Android startup script.
Android-x86 is your project, and if it shall be a good working installation then you have to fix these problems; it has to deal with these problems without any modifications, other users can't do this and other operating systems could handle hard disk installations and live boot sytems, too. I provided enough infomation; how to update to GRUB2, what is missing in the installation routine, infos and missing stuff of the Thinkpad version, and after all my testing you should have gotten enough ideas to look for bugs or what to change in your startup routine.
It is now to you, to use these information or leaving a known bug in Android.
Android-x86 is your project, and if it shall be a good working installation then you have to fix these problems; it has to deal with these problems without any modifications, other users can't do this and other operating systems could handle hard disk installations and live boot sytems, too. I provided enough infomation; how to update to GRUB2, what is missing in the installation routine, infos and missing stuff of the Thinkpad version, and after all my testing you should have gotten enough ideas to look for bugs or what to change in your startup routine.
It is now to you, to use these information or leaving a known bug in Android.
Chih-Wei Huang
Nov 8, 2012, 12:51:39 AM11/8/12
to andro...@googlegroups.com
First, Android-x86 has no problem to handle hard disk installations
and live system. By live system, we mean a USB disk created by
dd (dump) the iso image into it, or by unetbootin or similar tools.
Not the system you created by the installer -- that's an installed system.
If you just want to rescue your system, you don't need
two installations. Just use the "live USB", the one that
you use to install Android-x86.
I only agree with you that Android-x86 booting
cannot handle two installations of the same version
on different partitions. That's beyond the design.
This is not a normal use case.
But you can easily workaround the problem
by the instructions I told you (setting ROOT or SRC).
However, you just cannot get the point.
So this is your problem. If you want to solve it,
follow my instructions and you will be happy.
Otherwise nothing I can do for you.
Finally, this is an Android-x86 specific issue,
nothing to do with Android itself.
The booting of normal Android system is
entirely different than Android-x86.
(if you can't distinguish them, forget it)
2012/11/8 RetroAndMore <retro....@gmail.com>:
and live system. By live system, we mean a USB disk created by
dd (dump) the iso image into it, or by unetbootin or similar tools.
Not the system you created by the installer -- that's an installed system.
If you just want to rescue your system, you don't need
two installations. Just use the "live USB", the one that
you use to install Android-x86.
I only agree with you that Android-x86 booting
cannot handle two installations of the same version
on different partitions. That's beyond the design.
This is not a normal use case.
But you can easily workaround the problem
by the instructions I told you (setting ROOT or SRC).
However, you just cannot get the point.
So this is your problem. If you want to solve it,
follow my instructions and you will be happy.
Otherwise nothing I can do for you.
Finally, this is an Android-x86 specific issue,
nothing to do with Android itself.
The booting of normal Android system is
entirely different than Android-x86.
(if you can't distinguish them, forget it)
2012/11/8 RetroAndMore <retro....@gmail.com>:
RetroAndMore
Nov 8, 2012, 12:13:01 PM11/8/12
to andro...@googlegroups.com
I'm repairing the Android system using the Ubuntu installation on the same hard drive, so I didn't need a USB boot at all. But anyway, Android-x86 will be only interesting for me until there's a Thinkpad version with the Atheros 5000 series WLAN driver included. Without internet it is useless.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages