fdisk -d fails #17

vrx · 2015-11-30T17:58:04Z

When using tool.py, fidsk -d command fails as -d option is not recognized (i can't find it on man page).

egradman · 2015-11-30T19:25:09Z

yeah, that’s probably an OSX only option. The intent is to determine the
offset of the partitions on the disk image so they can be loop mounted. If
your image is based on the latest Jessie build then you don’t even have to
run this step.

On Mon, Nov 30, 2015 at 9:58 AM, vrx [email protected] wrote:

When using tool.py, fidsk -d command fails as -d option is not recognized
(i can't find it on man page).

—
Reply to this email directly or view it on GitHub
#17.

Eric Gradman
CTO & Mad Inventor
P: 213-268-6253 | W: twobitcircus.com http://www.twobitcircus.com/
TW: @egradman http://www.twitter.com/egradman

TWO BIT CIRCUS
Engineering Entertainment

Inventors | Developers | Performers

vrx · 2015-11-30T20:30:25Z

that's right, thanks, -d is osx only !

and yes, my image is based on latest jessie but after some changes...

and actually i get a slightly different offset for the root offset
offset_boot: 4194304
offset_root: 67108864 (instead of 62914560)
is that important?

egradman · 2015-11-30T21:11:08Z

yikes!

either:

my script is broken, and isn’t yielding the correct offsets on different
computers or different image files
my assumption is wrong that the partition offsets are stable for all
descendents of the jessie image

in either case, you should try booting the system and mounting
/opt/raspberrypi/boot and root. If you get an error, replace the relevant
values in /etc/fstab with the ones you got from your script and try
mounting again. Let me know the result!

On Mon, Nov 30, 2015 at 12:30 PM, vrx [email protected] wrote:

that's right, thanks, -d is osx only !

and yes, my image is based on latest jessie but after some changes...

and actually i get a slightly different offset for the root offset
offset_boot: 4194304
offset_root: 67108864 (instead of 62914560)
is that important?

—
Reply to this email directly or view it on GitHub
#17 (comment)
.

Eric Gradman
CTO & Mad Inventor
P: 213-268-6253 | W: twobitcircus.com http://www.twobitcircus.com/
TW: @egradman http://www.twitter.com/egradman

TWO BIT CIRCUS
Engineering Entertainment

Inventors | Developers | Performers

vrx · 2015-12-01T21:34:19Z

i used virtualbox
config.vm.box = "ubuntu/trusty64"
config.vm.provider "virtualbox" do |prl|
#prl.update_guest_tools = true
end

but i try to mount boot
vagrant@vagrant-ubuntu-trusty-64:~$ sudo mount /opt/raspberrypi/boot/
/vagrant/rpi.img: Operation not permitted

/etc/fstab is
LABEL=cloudimg-rootfs / ext4 defaults 0 0
/vagrant/rpi.img /opt/raspberrypi/boot auto loop,offset=4194304,noauto 0 0

egradman · 2015-12-01T22:28:56Z

true for both values of offset? Both the one I provided, and the one you
derived?

Can you verify that /vagrant/rpi.img is present and readable?

On Tue, Dec 1, 2015 at 1:34 PM, vrx [email protected] wrote:

i used virtualbox
config.vm.box = "ubuntu/trusty64"
config.vm.provider "virtualbox" do |prl|
#prl.update_guest_tools = true
end

but i try to mount boot
vagrant@vagrant-ubuntu-trusty-64:~$ sudo mount /opt/raspberrypi/boot/
/vagrant/rpi.img: Operation not permitted

/etc/fstab is
LABEL=cloudimg-rootfs / ext4 defaults 0 0
/vagrant/rpi.img /opt/raspberrypi/boot auto loop,offset=4194304,noauto 0 0

—
Reply to this email directly or view it on GitHub
#17 (comment)
.

Eric Gradman
CTO & Mad Inventor
P: 213-268-6253 | W: twobitcircus.com http://www.twobitcircus.com/
TW: @egradman http://www.twitter.com/egradman

TWO BIT CIRCUS
Engineering Entertainment

Inventors | Developers | Performers

vrx · 2015-12-01T22:31:46Z

yes operation not permitted is issued for both values, and notice that there is no mention of root in /etc/fstab
-rw-r--r-- 1 vagrant vagrant 7.5G Nov 28 11:38 rpi.img

sorry i am probably missing something - first time i am trying this method...

egradman · 2015-12-01T23:34:19Z

yeah, there’s no mention of root in my fstab either. That’s OK. Can you
run fdisk on the rpi.img file from within the virtual machine? Perhaps
that’ll yield different values for the offsets?

I also notice that your image file is 7.5GB. Mine is 4.0GB. That
indicates that you probably expanded the filesystem on an 8GB SD card when
you booted the pi. It’s worth noting that I DID NOT do this on my SD
card. I don’t know how “expanding the filesystem” actually works, and it
might make the disk unbootable over a loop (I’m guessing here.)

Another thought: It would be nice to eliminate the possibility that the
problem comes from the way Virtualbox shares /vagrant. It’s a drag, but
you could do this by copying the rpi.img file into the virtual machine’s
virtual disk and pointing fstab at the copied file.

Also, this method is totally rough and I appreciate your patience and help
getting this bugs ironed out!

On Tue, Dec 1, 2015 at 2:31 PM, vrx [email protected] wrote:

yes operation not permitted is issued for both values, and notice that
there is no mention of root in /etc/fstab
-rw-r--r-- 1 vagrant vagrant 7.5G Nov 28 11:38 rpi.img

sorry i am probably missing something - first time i am trying this
method...

—
Reply to this email directly or view it on GitHub
#17 (comment)
.

Eric Gradman
CTO & Mad Inventor
P: 213-268-6253 | W: twobitcircus.com http://www.twobitcircus.com/
TW: @egradman http://www.twitter.com/egradman

TWO BIT CIRCUS
Engineering Entertainment

Inventors | Developers | Performers

vrx · 2015-12-06T09:47:38Z

I just tried with a fresh raspbian (jessie) image and it seems much better

I changed
offset_root to the value given by running tool.py (67108864 in this case) otherwise vagrant up does not work.

even if from vagrant provision i get this error message

FAILED COMMAND: tar xfkv $f

FATAL: all hosts have already failed -- aborting

PLAY RECAP ********************************************************************
           to retry, use: --limit @/Users/vrx/playbook.retry

default                    : ok=58   changed=2    unreachable=0    failed=1

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

I am still able to ssh to the system and see
vagrant@vagrant-ubuntu-trusty-64:/opt/raspberrypi/root/home/pi/

Now, I used a completely fresh image and was trying to download of90 directly from the virtual machine, but as a matter fact i quickly runs out a space on the device. I must admit that i don't really understand what's happening - can i permanently change the content of the .img file ?

rmast · 2016-08-13T15:06:34Z

As I am not running from OsX, but from Windows 10 I am only able to run the tool.py from within the Ubuntu 14.04 image. There the fdisk -d doesn't work, however sfdisk -d gives a slightly different output-format.

In answer to the question of Egradman: OsX - fdisk seems to give incorrect values for -d: https://github.com/adriangligor/osx-fdisk

By the way, I tried to add a readme for using a Windows 10-host, which immediately created a fork:

https://github.com/rmast/rpi-build-and-boot

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fdisk -d fails #17

fdisk -d fails #17

vrx commented Nov 30, 2015

egradman commented Nov 30, 2015

vrx commented Nov 30, 2015

egradman commented Nov 30, 2015

vrx commented Dec 1, 2015

egradman commented Dec 1, 2015

vrx commented Dec 1, 2015

egradman commented Dec 1, 2015

vrx commented Dec 6, 2015

rmast commented Aug 13, 2016 •

edited

Loading

fdisk -d fails #17

fdisk -d fails #17

Comments

vrx commented Nov 30, 2015

egradman commented Nov 30, 2015

vrx commented Nov 30, 2015

egradman commented Nov 30, 2015

vrx commented Dec 1, 2015

egradman commented Dec 1, 2015

vrx commented Dec 1, 2015

egradman commented Dec 1, 2015

vrx commented Dec 6, 2015

rmast commented Aug 13, 2016 • edited Loading

rmast commented Aug 13, 2016 •

edited

Loading