The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
I have a partial answer for you, but that can come in VERY handy, especially when it comes to installing from source.
This is my personal experience, and I had limited iterations with it (tried just a few times) but worked well.
Start with a standard debian SD image; Run this image using QEMU, on a regular (powerful) computer.
Before you start, make sure you have enough space on that image. Two GB can be too small. Four GB just right for the basics. I would recommend 16 GB, if the price is right for you. Keep in mind that later you will install this image on an ACTUAL SD card.
Instead of creating an image with 16 GB, create it with 15900 MB. It is the never ending discussion about 1024 vs 1000, and sometimes the actual available space on a storage device will not be the ACTUAL reported space on the label.
There are a few tricks you have to apply in order to get your ARM image to run on a qemu environment, but it works well. download, install and compile all you want on that image
I no longer have the links that I used to create my images, but here are the key points:
Note: I did it for Hydra. Not yet for Indigo, but it should work.
Cheers.
| | 2 | No.2 Revision |
I have a partial answer for you, but that can come in VERY handy, especially when it comes to installing from source.
This is my personal experience, and I had limited iterations with it (tried just a few times) but worked well.
Start with a standard debian SD image; Run this image using QEMU, on a regular (powerful) computer.
Before you start, make sure you have enough space on that image. Two GB can be too small. Four GB just right for the basics. I would recommend 16 GB, if the price is right for you. Keep in mind that later you will install this image on an ACTUAL SD card.
Instead of creating an image with 16 GB, create it with 15900 MB. It is the never ending discussion about 1024 vs 1000, and sometimes the actual available space on a storage device will not be the ACTUAL reported space on the label.
There are a few tricks you have to apply in order to get your ARM image to run on a qemu environment, but it works well. download, install and compile all you want on that image
I no longer have the links that I used to create my images, but here are the key points:
Note: I did it for Hydra. Not yet for Indigo, but it should work.
Cheers.
++++++++++++++++++++++++----------- LONG ADDITION -------------+++++
Well, would you look at that. I found some of my notes I meant to transform into a WIKI/HOWTO but never finished.
Before following or applying my steps, refer to the original links posted here. I recommend you understand the story rather than just repeating command lines.
WARNING ! THESE INSTRUCTIONS WERE TESTED AND WORK, BUT IN THE END, I FOUND EASIER WAYS AND DID NOT UPDATE THE DOCUMENT.
CONSIDER THIS A GUIDELINE AND NOT - I REPEAT NOT - A RECIPE FOR A SUCCESSFUL OPERATION.
SORRY FOR THIS. It was my best effort.
Well, like some people out there, I am taking my first steps in the ROS world, and my weapons of choice are a Raspberry PI (rev b, with 512 MB), an Ubuntu 12.04 running on VMWare Fusion, to be used as the "base station", and an idea in my head.
Anyone trying their luck with a RPI knows that installing ROS takes time. Some brave souls out there created images for SD card with ROS already installed, and that is a brilliant job they've done.
I had problems with those images, so I had to start my own tests.
Now, the very first obstacle was the processing power of the RPI, so, like many, I decided to go virtual, using QEMU to install and compile everything.
The other "little problem" I ran into was, the default Debian Wheezy image I was using was not even 4 GB, with very little space available.
Making a mistake on the ROS install, or messing up with the operation system could render an entire week of work useless.
Virtualizing would allow me to:
1) Take advantage of an i7 processor to install ROS 2) Make intermediated copies of the image, whenever I thought a " dangerous" step in the install was ahead. 3) Take the environment with me (notebook) wherever I was 4) Manage image space as required, instead of just using a big 16 GB SD card. This makes a lot of difference when creating images and buying test SD cards, not to mention time to record those images and test them on the RPI.
But, resizing the image proved to be trickier than I thought; There are many tutorials and howtos out there, but few have the goal of resizing an image, using it on a virtual environment, and next recording it to be used back on the actual thing.
My work here was based on these pages:
Resizing img file:
http://sirlagz.net/2012/06/20/how-to-resize-partitions-on-an-image-file/
QEMU RPI emulation:
http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/
Installing ROS:
http://wiki.ros.org/ROSberryPi/Setting%20up%20Hydro%20on%20RaspberryPi
What first ?
Do NOT boot your image. Do everything with exclusive access to the img file. Make a backup copy just in case.
I started with the latest Raspbian image, instead of NOOB. Should not make any difference for ROS or Linux, but might do for disk resizing. Be careful.
Now, just out of curiosity, running fdisk -l on my wheezy's image showed a FAT partition and an EXT4 partition. Contrary to many tutorials out there, a swap partition was not found and this is important, because you don't have to move that swap partition.
Now, a word of advice here: in one step you will DELETE you actual partition information. If you do it right, no data will be lost. Fear not, but make sure you know what you are doing.
These instructions offer no danger to your hard drive, for they do not use DD, but then again: your system, your responsibility.
--------------- Resize wheezy partition
You are on Ubuntu's terminal.
First, we have to create extra space on the image file. Do it easily with qemu-image, and replace the "1G" with the amount of space you want to ADD to the image.
In my case my image is called alpha1_wRh.img
qemu-img resize alpha1_wRh.img +1G
This is ready in a split second. Next, we mount the image as a loopback device in order to have some access to it.
losetup -f --show
And now enter gparted to make the important changes:
gparted alpha1_wRh.img
You will see the usual prompt on parted, and will use the "print" command, which will tell you more or less this:
(parted) print Model: (file) Disk alpha1_wRh.img: 3996MB Sector size (logical/physical): 512B/512B Partition Table: msdos
Number Start End Size Type File system Flags 1 4194kB 62.9MB 58.7MB primary fat16 lba 2 62.9MB 2962MB 2899MB primary ext4
Now comes the horrible part that is the nightmare of us all: delete that partition number 2.
rm 2
and next, create it again with
mkpart primary 62.9 3996
Now, where have I got the magic numbers from above? 62.9 is the start of the original partition, and 3996 is the "disk" size reported by parted, on the second line to the "print" command.
After this, enter "quit" to exit parted, committing the changes.
Now, we are getting there, but we have to use some more "magic" and the real voodoo is yet to come.
Run this command on you just altered file:
fdisk -l alpha1_wRh.img
Its output should look like this:
Disk alpha1_wRh.img: 2962 MB, 2962227200 bytes 255 heads, 63 sectors/track, 360 cylinders, total 5785600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000981cb
Device Boot Start End Blocks Id System
alpha1_wRh.img1 8192 122879 57344 c W95 FAT32 (LBA) alpha1_wRh.img2 122880 5785599 2831360 83 Linux
There are some very interesting points here:
a) The "sector size" is 512. Take note of this number. b) The "Start position" of you Linux partition is 122880. Take note of this too.
Multiply "sector size" by "start point" and use it in the next command. My result is 62914560.
losetup -f --show -o 62914560 alpha1_wRh.img
This will create a loop device on you system, referring to that PART (partition) on your img file, and will return which device name was issued. For me it was /dev/loop0
Next is the easy part:
We test the fie system, just in case:
e2fsck -f /dev/loop0
We resize the file system:
resize2fs /dev/loop0
We check it again, because we want to be safe:
e2fsck -f /dev/loop
And we no longer need the device, so we delete it.
losetup -d /dev/loop0
Done ! Now you are ready to boot your virtual RPI with your bigger disk !
===================================================== Notes for QEMU
qemu commands below are incomplete and must refer to your image file.
Preparing your image with bash
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda
Regular boot
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw " -hda
Note 2: remember to undo the preparation steps before transferring your image to the SD card.
| | 3 | No.3 Revision |
I have a partial answer for you, but that can come in VERY handy, especially when it comes to installing from source.
This is my personal experience, and I had limited iterations with it (tried just a few times) but worked well.
Start with a standard debian SD image; Run this image using QEMU, on a regular (powerful) computer.
Before you start, make sure you have enough space on that image. Two GB can be too small. Four GB just right for the basics. I would recommend 16 GB, if the price is right for you. Keep in mind that later you will install this image on an ACTUAL SD card.
Instead of creating an image with 16 GB, create it with 15900 MB. It is the never ending discussion about 1024 vs 1000, and sometimes the actual available space on a storage device will not be the ACTUAL reported space on the label.
There are a few tricks you have to apply in order to get your ARM image to run on a qemu environment, but it works well. download, install and compile all you want on that image
I no longer have the links that I used to create my images, but here are the key points:
Note: I did it for Hydra. Hydro. Not yet for Indigo, but it should work.
Cheers.
++++++++++++++++++++++++----------- LONG ADDITION -------------+++++
Well, would you look at that. I found some of my notes I meant to transform into a WIKI/HOWTO but never finished.
Before following or applying my steps, refer to the original links posted here. I recommend you understand the story rather than just repeating command lines.
WARNING ! THESE INSTRUCTIONS WERE TESTED AND WORK, BUT IN THE END, I FOUND EASIER WAYS AND DID NOT UPDATE THE DOCUMENT.
CONSIDER THIS A GUIDELINE AND NOT - I REPEAT NOT - A RECIPE FOR A SUCCESSFUL OPERATION.
SORRY FOR THIS. It was my best effort.
Well, like some people out there, I am taking my first steps in the ROS world, and my weapons of choice are a Raspberry PI (rev b, with 512 MB), an Ubuntu 12.04 running on VMWare Fusion, to be used as the "base station", and an idea in my head.
Anyone trying their luck with a RPI knows that installing ROS takes time. Some brave souls out there created images for SD card with ROS already installed, and that is a brilliant job they've done.
I had problems with those images, so I had to start my own tests.
Now, the very first obstacle was the processing power of the RPI, so, like many, I decided to go virtual, using QEMU to install and compile everything.
The other "little problem" I ran into was, the default Debian Wheezy image I was using was not even 4 GB, with very little space available.
Making a mistake on the ROS install, or messing up with the operation system could render an entire week of work useless.
Virtualizing would allow me to:
1) Take advantage of an i7 processor to install ROS 2) Make intermediated copies of the image, whenever I thought a " dangerous" step in the install was ahead. 3) Take the environment with me (notebook) wherever I was 4) Manage image space as required, instead of just using a big 16 GB SD card. This makes a lot of difference when creating images and buying test SD cards, not to mention time to record those images and test them on the RPI.
But, resizing the image proved to be trickier than I thought; There are many tutorials and howtos out there, but few have the goal of resizing an image, using it on a virtual environment, and next recording it to be used back on the actual thing.
My work here was based on these pages:
Resizing img file:
http://sirlagz.net/2012/06/20/how-to-resize-partitions-on-an-image-file/
QEMU RPI emulation:
http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/
Installing ROS:
http://wiki.ros.org/ROSberryPi/Setting%20up%20Hydro%20on%20RaspberryPi
What first ?
Do NOT boot your image. Do everything with exclusive access to the img file. Make a backup copy just in case.
I started with the latest Raspbian image, instead of NOOB. Should not make any difference for ROS or Linux, but might do for disk resizing. Be careful.
Now, just out of curiosity, running fdisk -l on my wheezy's image showed a FAT partition and an EXT4 partition. Contrary to many tutorials out there, a swap partition was not found and this is important, because you don't have to move that swap partition.
Now, a word of advice here: in one step you will DELETE you actual partition information. If you do it right, no data will be lost. Fear not, but make sure you know what you are doing.
These instructions offer no danger to your hard drive, for they do not use DD, but then again: your system, your responsibility.
--------------- Resize wheezy partition
You are on Ubuntu's terminal.
First, we have to create extra space on the image file. Do it easily with qemu-image, and replace the "1G" with the amount of space you want to ADD to the image.
In my case my image is called alpha1_wRh.img
qemu-img resize alpha1_wRh.img +1G
This is ready in a split second. Next, we mount the image as a loopback device in order to have some access to it.
losetup -f --show
And now enter gparted to make the important changes:
gparted alpha1_wRh.img
You will see the usual prompt on parted, and will use the "print" command, which will tell you more or less this:
(parted) print Model: (file) Disk alpha1_wRh.img: 3996MB Sector size (logical/physical): 512B/512B Partition Table: msdos
Number Start End Size Type File system Flags 1 4194kB 62.9MB 58.7MB primary fat16 lba 2 62.9MB 2962MB 2899MB primary ext4
Now comes the horrible part that is the nightmare of us all: delete that partition number 2.
rm 2
and next, create it again with
mkpart primary 62.9 3996
Now, where have I got the magic numbers from above? 62.9 is the start of the original partition, and 3996 is the "disk" size reported by parted, on the second line to the "print" command.
After this, enter "quit" to exit parted, committing the changes.
Now, we are getting there, but we have to use some more "magic" and the real voodoo is yet to come.
Run this command on you just altered file:
fdisk -l alpha1_wRh.img
Its output should look like this:
Disk alpha1_wRh.img: 2962 MB, 2962227200 bytes 255 heads, 63 sectors/track, 360 cylinders, total 5785600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000981cb
Device Boot Start End Blocks Id System
alpha1_wRh.img1 8192 122879 57344 c W95 FAT32 (LBA) alpha1_wRh.img2 122880 5785599 2831360 83 Linux
There are some very interesting points here:
a) The "sector size" is 512. Take note of this number. b) The "Start position" of you Linux partition is 122880. Take note of this too.
Multiply "sector size" by "start point" and use it in the next command. My result is 62914560.
losetup -f --show -o 62914560 alpha1_wRh.img
This will create a loop device on you system, referring to that PART (partition) on your img file, and will return which device name was issued. For me it was /dev/loop0
Next is the easy part:
We test the fie system, just in case:
e2fsck -f /dev/loop0
We resize the file system:
resize2fs /dev/loop0
We check it again, because we want to be safe:
e2fsck -f /dev/loop
And we no longer need the device, so we delete it.
losetup -d /dev/loop0
Done ! Now you are ready to boot your virtual RPI with your bigger disk !
===================================================== Notes for QEMU
qemu commands below are incomplete and must refer to your image file.
Preparing your image with bash
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda
Regular boot
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw " -hda
Note 2: remember to undo the preparation steps before transferring your image to the SD card.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.