PiShrink
PiShrink copied to clipboard
Drewsif
Burned images not booting
I have images that I've put on a flash drive and then moved over to a Ubuntu machine that I then shrink them on (no errors). When I go to boot from cards burned from those images, I get nothing. There is a little bit of SD card activity for a second, but nothing on the screen, and I can't SSH to it (in case it was just that I wasn't getting video).
The images are of chilipie-kiosk, a version running on 3B+ that I've recently upgraded to Buster from Stretch. Ubuntu is running on its own machine at 20.04.3 LTS
I'm burning on Win10 with Win32DiskImager
Images work that are burned using the original images.
I'm going to say that it might be the Ubuntu machine. I just shrunk a card using gparted and now that card won't work. I'll come back after troubleshooting on another machine tomorrow.
Yeah, it wasn't the machine. A working build that I've used for over a year does the same thing. It happens with pishrink but also with gparted; if I shrink the image file I get a black screen, but if i get a working card and then shrink the partition with gparted it also gives me nothing.
Same problem here and it isn't the machine. The shrinked image (from 32GB to 11GB) is apparently (green light) a few times read, but then nothing else happens. I even let it be in place for about 30 minutes, hoping that it would be because much time was needed to expand the image again. Bit no effect, nothing happens. A pitty, since it's ideal to move a lot smaller image around!
I've been trying again, but unfortunately the problem remains the same: PiShrink works great in reducing the image size considerably, but when written to an SD card it's read a few times (green light) but that's it. So no working OS. I''ll put the output of the job below, maybe that helps since I'm out of clues and haven't been able to find something on the web to solve this (I'm not a Linux guy).
root Ma 14-3-2022 08:33 pishrink.sh: Creating log file /root/pishrink.log ... pishrink.sh v0.1.2 pishrink.sh: Copying /backup/Image-backup/RPI3-res.img to /backup/Image-backup/newpi.img... ... pishrink.sh: Gathering data ... Creating new /etc/rc.local pishrink.sh: Checking filesystem ... /dev/loop0: Inode 654089 extent tree (at level 1) could be shorter. IGNORED. /dev/loop0: 232307/1945888 files (0.3% non-contiguous), 2627075/7779968 blocks resize2fs 1.44.5 (15-Dec-2018) pishrink.sh: Shrinking filesystem ... resize2fs 1.44.5 (15-Dec-2018) Resizing the filesystem on /dev/loop0 to 2656006 (4k) blocks. Begin pass 2 (max = 1590243) Relocating blocks ----------------------------------------XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 3 (max = 238) Scanning inode table ----------------------------------------XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 4 (max = 23199) Updating inode references ----------------------------------------XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX The filesystem on /dev/loop0 is now 2656006 (4k) blocks long.
pishrink.sh: Shrinking image ... pishrink.sh: Using pigz on the shrunk image ... pishrink.sh: Shrunk /backup/Image-backup/newpi.img.gz from 30G to 4.1G ...
Same problem here and it isn't the machine. The shrinked image (from 32GB to 11GB) is apparently (green light) a few times read, but then nothing else happens.
What OS/build are you writing an image of?
I'm running Raspbian GNU/Linux 10 (buster) I'm burning it on W10 with balenaEtcher (also tried Win32DiskImager). The image that's being shinked is created by the following command: "sudo dd bs=4M if=/dev/mmcblk0 of=$BACKUPimg/$MACHINE-res.img conv=fsync" Then it's being shrinked by "sudo pishrink.sh -ad $BACKUPimg/$MACHINE-shrink.img"
The variables are used to distinguish the RPi's: the images are written via a W10 PC to my NAS.
@sborn @moi427 Same issue, did either one of you find a solution?
Sorry @DaveWhoHasARadarGun, if I had found something I would have mentioned it. Unfortunately not so, so I've to remain writing the very large 30Gb images to my backup system and commented the PiShrink runs since they only cost time but no usable result.
Thanks for your response - I just managed to get it to work, but I'm not sure if it's anything I did in particular or just a fluke. Here's my process, if it's of any use to anyone:
The first time that I used PiShrink, I did it on my Linux (Ubuntu20.04) laptop, and then used Raspberry Pi Imager to burn the shrunken .img file on that same laptop. The process to shrink the file was extremely fast, but the SD Card (16 GB) wouldn't boot. When I zipped the shrunken .img file, it went from 4.3 GB to 531MB.
The second time I tried, I used WSL2 (Windows Subsystem Linux ver 2, with Ubuntu 20.04) on my Windows machine, and used the Raspberry Pi Imager (on my Windows machine this time) to burn the shrunken .img file to a different 16 GB SD Card. The process to shrink the file was much slower this time, and the resulting .img file was the same size (4.3 GB). When I zipped the file this time though, it only went down to 1.7 GB. The SD Card booted without issue and all expected system functionality is working.
EDIT: To clarify, I only zipped the .img files because they are going to be uploaded to a server. I burned the shrunken .img files (unzipped) to the SD Cards.
That's curious anyway, I might try to burn a shrunken image (created on the RPi) that way. So if I interpret your text correct, you ran PiShrink as usual on the RPi (so created the shrunken image on the RPi), but the burning that succeeded was by WSL2 on the Windows machine. Or did you also ran PiShrink under WSL2, shrinking the original image created on the RPi?
The whole PiShrink process was successfully done on a Windows 10 laptop using WSL 2. There's a YouTube video from a channel called ViciousComputers that showed how to get WSL installed and working. I had to force it to default to ver 2, it tried to use ver 1 if I didn't specify. I burned the shrunken img using RPi imager on the same laptop, using the normal Windows version of the imager.
Here's the YouTube video I followed:
https://youtu.be/77vOeofG0Kg
Ok, thank you for confirming! What ran where wasn't entirely clear to me. I already have WSL2 installed, but running PiShrink on my Windows machines wouldn't help me: then I first still would need to transfer the "normal" image of 30Gb to that Windows machine and that is just what I'm trying to avoid since transfer of this RPi3 isn't fast at all. Very slow in fact...
Im pretty sure this is related to #255, the symptoms sound the same. So I'm going to close this as a duplicate until we confirm its not that
Well, unfortunately I never found a working solution using PiShrink. If it is like in the link in #255 that the partition UUID (PARTUUID) is changed, that then might be the cause but then still PiShrink still isn’t working is it? I never got it working anyway, that is it works perfect to make a small image, but that can’t be booted from. So the real usage then isn’t there. That’s a real pitty.
Van: Drew Bonasera @.> Verzonden: dinsdag 14 februari 2023 09:49 Aan: Drewsif/PiShrink @.> CC: moi427 @.>; Mention @.> Onderwerp: Re: [Drewsif/PiShrink] Burned images not booting (Issue #220)
Im pretty sure this is related to #255https://github.com/Drewsif/PiShrink/issues/255, the symptoms sound the same. So I'm going to close this as a duplicate until we confirm its not that
— Reply to this email directly, view it on GitHubhttps://github.com/Drewsif/PiShrink/issues/220#issuecomment-1429344146, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AW2SYDXNR7ZGMJOWGNNMSJ3WXNBGZANCNFSM5I6VPO7A. You are receiving this because you were mentioned.Message ID: @.@.>>
The problem is in usage of Parted not just PiShrink. The reported issue on stackexchange was related to using Parted and GParted, not even via PiShrink. Lots of people are still having success using PiShrink and Parted so I think it has to be version related.
You could try running on a different operating system. But if you wanted to go post in #255 what version of operating system you are using and what version of Parted you have that would be helpful in hunting hit down.