Max2Play Home › Forums › General Questions on Hardware and Max2Play Versions › What is in this unmounted partition and what is it used for?
Tagged: expand, filesystem
- This topic has 5 replies, 1 voice, and was last updated 1 year, 3 months ago by vegz78 premium.
-
10. August 2019 at 16:21 #46745
I have just cloned my M2P image to a new card which is larger so I went to expand the partition but there’s an unexpected partition (Partition 3) there. What’s it for? It’s not swap, mounted, not recognised as EXT and won’t mount when manually attempted.
# fdisk -l
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 93813 85622 41.8M c W95 FAT32 (LBA)
/dev/mmcblk0p2 94208 15123840 15029633 7.2G 83 Linux
/dev/mmcblk0p3 15123841 15523839 399999 195.3M 83 Linux# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 14.9G 0 disk
├─mmcblk0p1 179:1 0 41.8M 0 part /boot
├─mmcblk0p2 179:2 0 7.2G 0 part /
└─mmcblk0p3 179:3 0 195.3M 0 part# mount /dev/mmcblk0p3 /mnt/test/
mount: wrong fs type, bad option, bad superblock on /dev/mmcblk0p3,
missing codepage or helper program, or other errorIn some cases useful info is found in syslog – try
dmesg | tail or so.# fsck /dev/mmcblk0p3
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks…
fsck.ext2: Bad magic number in super-block while trying to open /dev/mmcblk0p3The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device># swapon -s
Filename Type Size Used Priority
/var/swap file 102396 0 -212. August 2019 at 15:07 #46758So I scanned the partition and every single byte was blank. I guess that’s to be expected on an unmounted partition…
So I deleted the partition and resized using the expand filesystem function from within M2P web UI which resized it AND created the mystery partition again. I wrote the image back to the card that I had saved, resized the partition using raspi-config and no extra partition.
So this seems to be something that you have implemented that is either by design or has a bug. If it’s by design can you please elaborate what it is for? If it’s a bug, that’s in V2.48 so feel free to squash for future releases 🙂15. August 2019 at 10:44 #46778Hi justinj,
Thanks for your detailed posts. I’ll go through it with our head developer.
8. Juni 2020 at 22:00 #48960I just hit the same issue. justinj’s post saved me!
I had copied my 32GB max2play sd-card onto a new 64GB sd-card using Win32DiskImager under Windows 10 by „reading“ it to my local disk and then „writing“ the „img“ file to the new SD card. After that max2play booted up using the larger sd-card, but hadn’t expanded its filesystem. The expand filesystem button said it was already expanded.
So I searched the web, and was about to give up when I found justinj’s post.
So I deleted the mmcblk0p3 partition and rebooted, and the Expand Filesystem command now completed successfully on my new 64GB sd-card.
After another reboot I saw that the mmcblk0p3 partition had been recreated after the expanded root partition. So I need to remember to do this again if I ever move my max2play image onto another bigger sd-card .
Cheers
Adrian -
You must be logged in to reply to this topic.