Difference between revisions of "Talk:MojoDB Partition Resize"
Jump to navigation
Jump to search
(eep) |
m |
||
| Line 10: | Line 10: | ||
** possibly use umount /dev/mapper/store-media repeatedly? | ** possibly use umount /dev/mapper/store-media repeatedly? | ||
* When I did the initial resize, there was a warning about the boot sector not matching its backup, but the resize and dosfsck seemed to complete normally. | * When I did the initial resize, there was a warning about the boot sector not matching its backup, but the resize and dosfsck seemed to complete normally. | ||
| + | * I have a loopmount for my /opt on the cryptofs that I'd forgotten about. Not sure how the kernel deals with that. | ||
Lessons: | Lessons: | ||
Latest revision as of 01:44, 7 October 2012
Possible warnings
I did this procedure on my pre2, and I have corrupted my /media/internal.
After the resize, and lvreduce, and mount, it still said 13.8GB. I didn't do an ls in there, but after repeating the resize (identical argument) and looking that time, it was definitely broken. Still 13.8G in df -h, and now with lots of ?? and garbage looking files in /media/internal
Possible causes:
- I had an app with a jail mount open (wirc, trying to keep the screen on)
- This mount didn't get un-done by the umount /media/internal
- possibly use umount /dev/mapper/store-media repeatedly?
- When I did the initial resize, there was a warning about the boot sector not matching its backup, but the resize and dosfsck seemed to complete normally.
- I have a loopmount for my /opt on the cryptofs that I'd forgotten about. Not sure how the kernel deals with that.
Lessons:
- just backup the whole damned thing first next time. It's only 13gb
- don't be lazy. see above.
- stop and investigate further when something looks off.
- record exact fs sizes as trying to recover by re-extending and re-resizing involved some guesswork.
Dwc 00:33, 7 October 2012 (UTC)