I have two different 8GB Micro SD cards. One is non-branded, and the other is a SanDisk Ultra class 10. When I try to write the new Ubunutu MATE 16.04 Raspberry Pi image to either of the SD cards using Win32 Disk Imager, I get an error that there’s not enough space on the card. Specifically it says; “Not enough space on disk: Size: 15728640 sectors Available: 15523840 sectors Sector size: 512” Can the image be made a little smaller to accommodate variations in SD card sizes? The non-branded card has even less space; “Available: 15415296.”
Any help would be greatly appreciated. I sure don’t want to have to go out and buy a 16GB Micro SD card to fit an 8GB image…
same happened to me… had to go out and get a 16GB card, but it seems the image is bigger than the card for only a few sectors. I[m sure the MATE guys can figure out a way to get rid of a few packages and decrease the size of the image a little bit… That would be really useful, as I have several 8GB cards, meant to be used on my RPi’s…
As has been pointed out, there’s n allocation issue here.
To summarize: The download file is 1.07 Gb compressed, and over 7.5 Gb expanded, while Windows allows you 7.44 Gb of space on an 8 Gb card.
Going with the 16.04 beta 2 as a reference, there’s this to consider: That image was just over 4.5 Gb expanded, out of a 1.07ish compressed file.
The good folks who created the Pi port were kind enough to provide a two click solution for the need to expand the disk that was a manual operation in the prior release. It was two clicks because you had to click a button to reach the actual trigger.
My guess is that either they created the compressed file from an expanded image in error, or in an attempt to be helpful and eliminating the step, they inadvertently overlooked how Windows allocates reserved and user space on media.
The fact that that the compressed file is nearly the same size in the beta and release versions speaks to this theory. Empty space will compress to a couple of bytes. If there were additional packages, there would have been a noticeable size disparity between the two images.
Writing to a larger card will reveal the truth in the short term (I’ll be doing that tonight). In the long term, the best fix will be to withdraw the current compressed file and replace it with the unexpanded one like the beta was, or change the announcement to reflect needing a 16 Gb card for it.
Also, I just read about a Linux and Windows tool called etcher (check the DesignSpark Twitter feed). Since it’s a wrapper for the Unix dd command, the Windows port may work where the recommended Windows Disk Imager cannot…
For those of you who are willing to try out the method in windows, try using Cygwin’s fdisk.exe and truncate.exe . Cygwin is a large collection of GNU and Open Source tools which provide functionality similar to a Linux distribution on Windows. (If you’re experienced with that!) a faster and better alternative might be live dvd or a virtual machine
Well about uploading my image I might consider that … but be aware that I have a mere 20-30 kbps connection (ya I’m not kidding) so it will take quite a while before I complete the upload (maybe by tomorrow or the day after)
I guess someone with a Linux system and good connection might do it faster! Anyways I will stat to upload it soon
Do we know if the MATE team is aware of this issue, and has any plans to shrink the image and re-release it? Or are we likely stuck figuring out work-arounds?
Yes, I did run out and get a 32GB Samsung EVO Plus for this particular Pi, but I have 4 other Raspberry Pi’s that I would like to start running MATE on as well, and don’t want to have to purchase new micro SD cards for all of them.
Using the pishrink.sh script ( https://github.com/Drewsif/PiShrink ) running on my Raspbian Pi with the .img on a USB hard drive I was able to shrink the subject distribution image to 4.6 GB which Win32DiskImager was able to write to an 8 GB SD.
Because the Raspberry Pi MATE distribution is network blind at first boot (by design?) and since I haven’t suitable keyboard/mouse hardware I was only able to check the boot up via HDMI to my TV to the point where it’s first input is required but it looks good to that point. If anyone wants to test it further I’ve made it available here:
I don’t know if it resizes to the full SD size on boot as pishrink is supposed to set up so it may be necessary to do that manually. In addition I added the -y option to the e2fsck command of the pishrink.sh script in case voluminous interaction is needed to fix up the file system.
I have to say that the lack of motivation the developers show with regard to fixing this themselves (and the network blind boot design) make me doubt the seriousness of their effort.
After writing the Ubuntu MATE 16.04 "8+GB" image to my newly purchased 32GB micro SD, I configured everything the way I wanted, and then followed the instructions in the post linked by iamashwin99 to shrink the image down to actually fit on a 8GB micro SD. It worked! I booted my laptop with a linux live USB drive to handle the task. Very inconvenient, but doable.
Thanks for all the replies! If I ever get time; which I doubt I will (I'm always SOOO busy), I will take the unaltered Raspberry PI MATE 16.04 image and shrink it down to around 7.4GB.
costales@dev:/home/costales$ unxz ubuntu-mate-16.04-desktop-armhf-raspberry-pi.img.xz
costales@dev:/home/costales$ sudo ddrescue -D --force ubuntu-mate-16.04-desktop-armhf-raspberry-pi.img /dev/mmcblk0
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued: 7822 MB, errsize: 0 B, current rate: 1769 kB/s
ipos: 7822 MB, errors: 0, average rate: 4879 kB/s
opos: 7822 MB, run time: 26.71 m, successful read: 0 s ago
Copying non-tried blocks... Pass 1 (forwards)
ddrescue: Write error: No space left on device
costales@dev:/home/costales$
or with other method:
costales@dev:/home/costales$ xzcat ubuntu-mate-16.04-desktop-armhf-raspberry-pi.img.xz | sudo dd of=/dev/mmcblk0 bs=32M
[sudo] password for costales:
dd: error writing '/dev/mmcblk0': No space left on device
0+387017 records in
0+387016 records out
7822376960 bytes (7,8 GB, 7,3 GiB) copied, 1562,99 s, 5,0 MB/s
costales@dev:/home/costales$