Raspbian jessie image will not boot - could not expand filesystem

[MrBorg]

I have now wasted a lot of time trying (2 whole days) to download noobs and jessie images from the download page. I have tried with 2 different micro SD cards (8GB and 64Gb class 10 cards). I'm trying to boot up from my Raspberry PI 3 model B. But get the error saying "Could not expand filesystem, please try raspi-config or rc_gui. Boot and root partitions are on different devices". I have attached a picture of the boot sequence part (RPI3_jessie_boot_error.jpg).

I'm having all my troubles with image "2017-07-05-raspbian-jessie" - is this images even working? Are all my sd-cards corrupted? Is it only me who is wasting terrible lot of time installing news images for my Raspberry PI projects?

[RaTTuS]

viewtopic.php?f=28&t=58151

[fruitoftheloom]

I have now wasted a lot of time trying (2 whole days) to download noobs and jessie images from the download page. I have tried with 2 different micro SD cards (8GB and 64Gb class 10 cards). I'm trying to boot up from my Raspberry PI 3 model B. But get the error saying "Could not expand filesystem, please try raspi-config or rc_gui. Boot and root partitions are on different devices".

I'm having all my troubles with image "2017-07-05-raspbian-jessie" - is this images even working? Are all my sd-cards corrupted? Is it only me who is wasting terrible lot of time installing news images for my Raspberry PI projects?

Use Etcher to unpack / write the "Raspbian Jessie with Desktop OS".IMG to the SD Card, works for me

[Heater]

The 2017-07-05-raspbian-jessie works just fine. I have used a few times recently.

How are you writing it to SD card?

I have used etcher without problems. https://etcher.io/

[oscarv]

I had exactly the same problem. Using 4 different SD cards that worked well before, and on two different Pi's.

In my case, the problem turned out to be that I used win32diskimager.

Using Etcher, the problem was gone.

Very strange, since I've been using win32diskimager for years...

Regards,

Oscar.

[Milliways]

I had exactly the same problem. Using 4 different SD cards that worked well before, and on two different Pi's.

In my case, the problem turned out to be that I used win32diskimager.

Using Etcher, the problem was gone.

Very strange, since I've been using win32diskimager for years...

Regards,

Oscar.

The problem is probably due to the unusual image sizes.

As noted in viewtopic.php?f=66&t=188207#p1186371 the 2017-07-05 image isn't even an even number of bytes.

The 2017-08-16 image IS a multiple of 4096, but most imaging programs use larger block sizes (for efficiency) - typically 1M or 4M. 4M is probably the ideal, as this corresponds to the Erase Block Size.

Arguably the programs SHOULD copy incomplete blocks, but it would be far better if the Foundation produced images on 4M boundaries (or padded to 4M blocks) there would be no problems. SD Cards will ALWAYS have multiples of 4M storage, and as the images are compressed a few (million) zeros on the end would make no difference to the download size.

The comment by ShiftPlusOne seemed to suggest this would be done.

[hommar]

I'm having all my troubles with image "2017-07-05-raspbian-jessie" - is this images even working? Are all my sd-cards corrupted? Is it only me who is wasting terrible lot of time installing news images for my Raspberry PI projects?

Test this release

[oscarv]

>> Test this release

I have not tried that one just yet - but indeed, a slightly older version worked fine with win32diskimager. As does the last OSMC image. Just the last two Raspbian image files seem to cause this issue.

I agree - it's probably the same problem that dogged me when I used dd under Linux long ago for copying custom images - the block size problem.

Still, if this is the cause (win32diskimager not working with the newest images) that will cause headaches and lost hours for many people used to using win32diskimager. Before Etcher, it was the default tool for this purpose on Windows...

[codfangler]

Well, I was also having this problem and deduced that Win32 was the culprit. But no........ I get exactly the same problem with Etcher. I have tried two sd cards and two PCs and still get the same response. Has anybody got an alternative solution?

[B.Goode]

Well, I was also having this problem and deduced that Win32 was the culprit. But no........ I get exactly the same problem with Etcher. I have tried two sd cards and two PCs and still get the same response. Has anybody got an alternative solution?

Although you may have your own valid reasons for want to run a superceded release of the Operating System, have you tried - for the purposes of troubleshooting - downloading and installing the current 2017-09-07-raspbian-stretch image?

That might help show whether the issue lies with the downloaded image or with the way it is being flashed to a microSD card.

[tellytoo]

This was the exact problem I was having with the most recent Raspbian 2017-09-07 - followed the normal instructions to dd image to SD card and bam nothing. This seems to be a recent issue, it took me a while of googling to stumble on this post. Etcher mysteriously works.... but it still bothers me that dd doesn't seem to work anymore...

[thienan]

I can confirm same issue with win32diskmanager. (although I 've been using win32diskmanager for years)
It worked well with etcher. thanks!

[therival]

I still have this problem, and I've wasted a day and bricked all my SD cards.

I've downloaded the latest image twice (Raspbian Stretch). I've use Etcher.io on Ubuntu and Windows 10, I've used different SD cards (of different ages and manufacture) and I've used different card writers. Every attempt to write the image gives the boot images as above.

I only get to try the write once, at Etcher.io will not then allow me to use an SD card I've already tried, marking it as 'locked'. GParted will not delete the partitions as they are now read only.

[rpdom]

Which cards are you using and where did you get them from?

[davesteele]

I'm going to bet that your SD cards are not bricked, or even read-only for that matter. Once you've burned the card, when you next insert it into your computer, it will auto-mount anything it can. Partition managers won't modify mounted partitions.

Try the instructions at

https://www.raspberrypi.org/documentati ... s/linux.md

They address the mounting issue, and go into a fair amount of detail on the rest.

One thing, before you unmount, note the device path reported by 'df'. it will be something like /dev/sd<letter><number>. The next copy would be to /dev/sd<letter> in this case.

The only time I've had a filesystem expansion system, my root partition needed to be repaired with fsck. That shouldn't be the case for you - you're using fresh image and multiple SD cards.

The messages you quote and the screenshot suggest that there was something wrong in the write configuration. Try the process again, using 'dd'. Make sure you are writing to /dev/sd<letter> (no digit), and make sure the letter is right.

[KAK]

Dear MrBorg,
I had the same problem as you describe. I’ve just been able to solve it. I did as follows:
1) Install etcher.io (crashes during installation on one of my computers (Windows 7))
2) Download the zip-file of Jessie from https://www.raspberrypi.org/downloads/. Do NOT unzip the file with any software.
3) Install the zip-file as it is with Etcher to your SD-card.
Everything is well described here: https://www.raspberrypi.org/documentati ... /README.md but do NOT unzip the downloaded Jessie yourself, let Etcher do it.

[HuntX]

Having the exact same problem, but with the latest version of Stretch (2018-03-13). I've tried a thousand different ways (slight exaggeration) of wiping and formatting my SD card in order to use Etcher. I tried the suggested formatter "SD Card Formatter" as well as that in combination with "FAT32Format", and of course windows disk management and 'diskpart'. This is infuriating because I've flashed raspian images onto cards dozens of times before with Etcher and have never had an issue.

Additional notes I'm experiencing: Etcher states that the image was flashed successfully but that corruption was detected when attempting to validate. But everytime I still try popping the card into the pi just in case but of course it always fails. Not sure what to do at this point... considering popping open my 11 year old macbook pro and trying it from there, also considering trying older releases of raspbian as others have suggested because of the byte size issue. Let me know if anyone has any solutions what so ever.

P.s. - yes I tried both just the image with etcher and the zip. Didn't make a difference.

[rpdom]

Are you using an internal SD card slot, or a USB card reader? Sometimes an external reader will work where an internal slot fails. Even the cheap £1 readers work well.

There should be no need to format a card prior to using Etcher as it just overwrites the contents of the card, including the previous format.

[hu5566798]

I also wasted 3days in this problem. when I bid the 16g 10class sd card from web store. firstly I have 8g sd card but I think too small for the raspberry Pi system. but when new big card receive, that problem came. I doubt why the 8g old card even I rewirt again and again, it still work. but the new big one fail. so I search on Google to find this post and found Etcher is raspberry recomand writing tool, yes, compare to win32DiskImager, Etcher will have the verification after it write. As I'm Chinese user I also can search user in China say that it was the sd card's defect, you just need to change new and stable sd card, that will gone. I firstly don't trust it. but after I try use the Etcher wirte images to my 2 card, result come out. big new one will have warming uncertain whether images is ok to write to card, you'd better change another one. then I think this card is defect and return card to seller and rebid the better one(Kingston 16G class10）， today i get new Kingston 16G, also use win32DiskImager write system. it is ok to get into system.

[HuntX]

Are you using an internal SD card slot, or a USB card reader? Sometimes an external reader will work where an internal slot fails. Even the cheap £1 readers work well.

There should be no need to format a card prior to using Etcher as it just overwrites the contents of the card, including the previous format.

I am actually using an external card reader. I honestly didn't realize that interal micro sd card readers were that common, sorry for not specifiying haha. But just for clarity, I'm using a SanDisc MicroMate SD card reader and a micro sd adapter that came with the micro sd card. It's possible that the card is the problem given that its a massive 256GB. However, I'm making sure its getting formatted in FAT32 per the following instructions (as a sanity check even though I've done this numerous times before without having to go through all this trouble):

https://www.raspberrypi.org/documentati ... ng-images/
https://www.raspberrypi.org/documentati ... n/noobs.md
https://www.raspberrypi.org/documentati ... matting.md

And yes, I realize many of those are instructions for noobs, but ignoring the noobs part is what i've been trying to follow ever since my first couple attempts the way I've always done it didn't work. Though, I'm tempted to just try noobs for the first time ever just to see if it works or not.

[fruitoftheloom]

Are you using an internal SD card slot, or a USB card reader? Sometimes an external reader will work where an internal slot fails. Even the cheap £1 readers work well.

There should be no need to format a card prior to using Etcher as it just overwrites the contents of the card, including the previous format.

I am actually using an external card reader. I honestly didn't realize that interal micro sd card readers were that common, sorry for not specifiying haha. But just for clarity, I'm using a SanDisc MicroMate SD card reader and a micro sd adapter that came with the micro sd card. It's possible that the card is the problem given that its a massive 256GB. However, I'm making sure its getting formatted in FAT32 per the following instructions (as a sanity check even though I've done this numerous times before without having to go through all this trouble):

https://www.raspberrypi.org/documentati ... ng-images/
https://www.raspberrypi.org/documentati ... n/noobs.md
https://www.raspberrypi.org/documentati ... matting.md

And yes, I realize many of those are instructions for noobs, but ignoring the noobs part is what i've been trying to follow ever since my first couple attempts the way I've always done it didn't work. Though, I'm tempted to just try noobs for the first time ever just to see if it works or not.

Etcher both unzips the Raspbian .zip and creates the SD Card in a SDHC compatible SD Card Reader, all in one solution.

Therefore no requirement to unzip or even format a SD Card.

Have you tested the 256GB SD Card is not a fake ??

[HuntX]

Etcher both unzips the Raspbian .zip and creates the SD Card in a SDHC compatible SD Card Reader, all in one solution.

Therefore no requirement to unzip or even format a SD Card.

Have you tested the 256GB SD Card is not a fake ??

Yes, I've used it to store other files and also it definitely holds the flashed image because its there when I plug it into another device. And I I know there's generally no need to format or even unzip, that's how I tried it first...

Anyway, I noticed something else kooky: I was putting the zip and image on a 32GB USB to take over to another computer when I got this strange error/notification from Windows: "Not enough free space: This file is too big for the filesystem." Which seemed really odd because its a completely clean USB and Windows even tells me that there's plenty of free space on it. So I tried just unzipping the zip (which fit on the USB) inside the USB with 7zip and well, got this (left side is the USB and the space attributes):

raspbian too big..PNG (26.83 KiB) Viewed 11827 times

This makes me think that something is off about the byte signature or something of the actual image but I'm not positive on any of that....

[HawaiianPi]

This makes me think that something is off about the byte signature or something of the actual image but I'm not positive on any of that....

Nope, your flash drive is just formatted with the FAT32 filesystem, which can't store files larger than 4GB, and the Raspbian image extracts to more than 4GB.

Also, just because your 256GB SD card can store a few files doesn't mean it's not fake. Test it with F3 or H2testw to be sure.

[ohdoh]

I got this error.

My first thought was a broken sd card. Didn't make any difference using a new sd card.

For me it seems to be due to the zip program in ubuntu file not completely extracting the image. I believe the image should be 5G, mine was less. When I extracted it straight from the zip I got a working

unzip -p 2018-04-18-raspbian-stretch.zip | sudo dd of=/dev/mmcblk0 bs=4M status=progress conv=fsync

as per instructions on raspberry pi site.

hope this helps someone.

[CorvusB]

Just had this issue. Posting because I found a fix (for me). This R-pi is a simple file server, print server, and bittorrent server.
Base issue: R-Pi won't boot into Raspbian as described by others - boot and root on different devices all that yada yada.
Likely cause: extended power outages this winter due to weather events. I have the R-pi on a UPS, but the outage(s) were repeated and extended.

What I did:
Pulled the SD card, and loaded it on my desktop (Xubuntu 16.04). Everything is readable. Ran fsck - it found something it didn't like on the boot partition. Fixed. Still same boot result. Backed up home and etc for config files. Should have gotten the config files for Transmission from var, also, but forgot. No big deal.
Then downloaded latest Stretch image (2018-11). Used the unzip | dd (unzip piped to dd) command found here: https://www.raspberrypi.org/documentati ... s/linux.md to install the image to the SD card. It took a LONG time - 20 minutes? Results look ok in file manager.
But the resulting SD card wouldn't finish booting on the R-pi. Booting starts - but fails before login, something about root not being available.
So I go back to reinstall the image to the SD card. This time I didn't use the "unzip-piped-to-dd". I unzipped the image file, and used the dd command alone to install.
This time the SD card installation boots properly.

I'll guess it was something about the unzip-piping-to-dd that my computer didn't do well with. Perhaps an off block size, as mentioned earlier in this thread. This was just the "Lite" image - and when dd wrote it the 2nd time - it was fast. Not more than a couple of minutes. Which is more like what I would have expected. Anyway, adding this as possibly useful to others in the future.

If the unzip-pipe-to-dd fails, try the straight dd. (As etcher isn't in my normal repositories, I avoided it.)