Code: Select all
sudo rsync -avxS /media/rootfs /media/volume1
Code: Select all
Code: Select all
Yeah, that's what I'd do if I was doing this myself ISTR finding that 'kpartx' is a very useful tool for working with the loop device and multiple-partition images such as used here.Joe Schmoe wrote:You don't actually have to write it out to the SD card; you can just mount the image using the loop device and work off of the image.
A good test would be to delete the linux partition on the SD card.TonyH wrote:I was interested to try this so I have given it a go, followed the great instructions provided here and successfully booted with an SD card and also the (debian image flashed) usb drive plugged in.
This will seem like a silly question I know but how can I tell if it has worked, i.e that my Pi is not just running off the SD card as normal?
Haveyou tried swapping the USB sockets the drives are plugged into?canyon wrote:I'm quite proud of myself as I've managed to do this using the following steps on a Windows PC, following a modified version of the steps in the earlier posts:
1. Put the Debian image on to an SD card using Win32DiskImager.
2. Put the Debian image on to a USB stick using Win32DiskImager.
3. With the USB stick selected, use gparted to: Delete the FAT32 partition; enlarge the swap partition to 512M; move the swap partition to the end; enlarge the ext4 partition to fill the space.
4. Working with the FAT32 partition on the SD card in Windows: Download the latest kernel.img and replace the original: edit cmdline.txt to change the root to root=/dev/sda2.
I have one question though:
If I try to boot the Raspberry Pi with a second USB device plugged in when I power up the Raspberry Pi, then I can get a kernel panic, as the kernel reads the second drive as SDA and my rootfs USB stick as SDB and so can't find the root filing system. The workaround here is to only have the USB stick that contains rootfs plugged in when I power up the Raspberry Pi, but it doesn't lead to a 'secure' system.
Is there a different way of specifying the root in cmdline.text using, say, the drive's UUID to make sure the right one is mounted?
I really don't see the problem. So long as your USB drives stay plugged into the same sockets, they should get the same devname each time you boot. So what ever the devname of boot drive is, that's what you should use in the cmdline.txt. If, OTOH, You have a USB drive that is only used occasionally, then just wait until the system finishes booting before plugging it in.canyon wrote:lewmur - Thanks for the tip.
I've tried all combinations, and at present the 3rd port down on the left side seems to be the most "secure". But when I started, I seem to recall that one failed as well!
Although using the "root=/dev/sda2" format will work if you have no other USB storage devices plugged in at power-on, you can never rely on that.
In my opinion it is a fatal flaw in any PC that it can only find its root filesystem "by chance", so I hope there is a solution that can easily be implemented on the Raspberry Pi.
I've searched around and "root=/dev/disk/by-id/<my-id>" etc. should work, but it seems that they need initramfs in the kernal - This is beyond me .
Can someone who knows more about it thow some light on the issue:
Should "root=/dev/disk/by-id/<my-id>" etc. work or not in the current kernel (I'm using rpi-update, so I have the latest)?
If not, is there another solution and how do I do it?
This is interesting. For reference, here is that last post:AndrewS wrote:This is a problem I've seen before (but not needed to fix myself) - have a look at this discussion, especially the last post in the thread https://groups.google.com/group/bifferb ... 517d0aeda7
Ubuntu (on a PC) uses Grub, which is much more sophisticated than the bootloader used on the RaspberryPi...Lob0426 wrote:Ubuntu also lets you use the label, but I do not know if Debian does.