Please note, if you don’t understand what’s going on here, it’s very easy to screw the source partition up, and lose your data! Be warned!
Obviously, boot into Jeltka first. Then, check the filesystem of the partition in question, in preparation for resizing the filesystem to it’s minimum size (please note, you may need to adjust device names accordingly):
e2fsck /dev/sda1
Then resize the filesystem to it’s smallest possible size using the -M flag of resize2fs:
resize2fs -M /dev/sda1
Mount the filesystem, check it’s size using df, and unmount it again (so fdisk can write the partition table successfully, later on):
mount /dev/sda1 /mnt df -h umount /dev/sda1
Now, we also need to reduce the size of the partition itself. This is so dd doesn’t copy more data than necessary (which could save you a lot of time). In the interests of safety, it’s always a good idea to make the partition at least 1GB bigger than the filesystem (fdisk and resize2fs, etc. calculate sizes in slightly different ways, the extra partition size ensures the partition is big enough to contain the filesystem). We also need to be careful because the version of fdisk included with Busybox uses the old 63 sector, default starting point for partitions, and your disk is probably partitioned with a 2048 sector starting point (this became the default in standard fdisk with the advent of GPT partitioning some years ago).
fdisk /dev/sda
To accommodate previous, we now change display units to sectors by pressing “u”. Press “p” to print the existing layout, to confirm the partition does indeed start at sector 2048. Then delete the existing partition – “d” followed by “1” (assuming the partition we’re concerned with is the first partition on the disk). Now we create a new partition with the same starting point – “n”, “p”, “1”, “2048”, “+14G” (where 14G is the size in gigabytes, you want the partition to be). Now type “p” again, and double check everything is as it should be, before hitting “w” to save the partition table and exit. Don’t worry too much if you’ve messed up here, as long as you can create a partition with the same starting point as the original, and enough size to accommodate the filesystem contained on it, you won’t lose any data. However, if you do something rash like create a new filesystem on an incorrectly sized/started partition, you will in fact be overwriting your nice data. In short, don’t do it!
Now we’re ready to do the actual copying using dd. I’m assuming here that you have a USB key/drive attached, and you’re going to output the partition image to a file on the USB key, with a view to dd’ing it onto a replacement HD/SSD, which you’ll physically put in your Chromebook subsequently. I’m assuming the USB key already has a compatible filesystem on it (ext4, FAT or NTFS, IIRC). Again, be careful to use the correct device name. First we’ll mount the USB stick somewhere suitable:
mount /dev/sdb1 /mnt
We should also backup the existing partition table and boot sector thusly:
dd bs=512 count=1 if=/dev/sda of=/mnt/bootsector.img
Then we’ll dd the partition to a file on the USB stick:
dd bs=1M if=/dev/sda1 of=/mnt/partition.img
If we had another console available, we could check on dd’s progress like so – find dd’s process number, and send a signal to it, to display progress every 60 seconds:
ps -e |grep dd watch -d -n 60 kill -SIGUSR1 1234
Where “1234” is dd’s PID (will undoubtedly be something else entirely).
Assuming you didn’t run out of space on your USB whatever, dd will have completely successfully (eventually), and you can now set about swapping your HD/SSD out for a nice, shiny, big one. :)
Back already? Okay, now we’re ready to copy the partition table/bootsector over, and create a new partition to take advantage of all that space! Make sure you’ve mounted the USB whatever again.
dd if=/mnt/bootsector.img of=/dev/sda
Then use fdisk to create a new partition, as we did previously, only this time don’t specify a size (it will default to the end of disk).
Then, copy the partition image to the new partition we just created, using dd:
dd bs=1M if=/mnt/partition.img of=/dev/sda1
When this has finished, check you can mount the filesystem! Assuming you can, we can now resize the filesystem to take advantage of all that juicy space you’ve just purchased:
e2fsck /dev/sda1 resize2fs /dev/sda2
Success?
My mileage varied. I’m close (I think / hope) but not there yet.
My JELTKA (installed with SeaBIOS 181214_15:29-johnlewis.ie) has no resize2fs command.
I found I had a USB stick with TAILS that occasionally boots. From there I was able to shrink the filesystem, shrink the partition, copy the bootsector and partition to a thumbdrive and verify that the system still booted (albeit with a warning I was completely out of space).
I popped out the old disk, and put in the new, which is identified as being in place now. And then, trouble.
I can get the partition.img onto the new disk and verify that it looks okay. But getting bootsector.img onto the disk seems to mess everything up. I’ve tried varying the order of instructions, and even gparted, but I either end up with something fdisk says it cannot see, or gparted complaining about “no valid fake msdos” or a corrupt GPT. gparted is now complaining that I “can’t have a partition outside of the disk!”
$ fdisk /dev/sda
fdisk: unable to seek on /dev/sda: Invalid argument
$ hdparm /dev/sda
/dev/sda:
multcount = 0 (off)
IO_support =1328623361 (???)
readonly = 0 (off)
readahead = 256 (on)
geometry = 30401/255/63, sectors = 488397168, start = 0
I’m wondering if the bootsector.img isn’t right, and what type of partition table should be on the SSD. And a bit more info:
$ hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: CT250BX100SSD1
Serial Number: 1503F001DCB1
Firmware Revision: MU01
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 488397168
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 238475 MBytes
device size with M = 1000*1000: 250059 MBytes (250 GB)
cache/buffer size = unknown
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 2 Current = 1
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* 64-bit World wide name
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Gen3 signaling speed (6.0Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* Phy event counters
* unknown 76[15]
* DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
unknown 78[8]
unknown 78[10]
* SMART Command Transport (SCT) feature set
* SCT LBA Segment Access (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
* DOWNLOAD MICROCODE DMA command
* WRITE BUFFER DMA command
* READ BUFFER DMA command
* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read ZEROs after TRIM
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
4min for SECURITY ERASE UNIT. 4min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 500a0751f001dcb1
NAA : 5
IEEE OUI : 00a075
Unique ID : 1f001dcb1
Checksum: correct
Thoughts?
The other way to approach it is to use a fresh partition table on the device, but you’ll need to install Grub to the mbr then, or it won’t boot.
I take it that bootsector.img is 512 bytes?
Yep. But in the meantime, I’m going down the same road as before: I’m using jeltka.sh to install ANY version of Linux and then wiping it out to install what I want. My hope is that, now that I have Linux installed again, I can erase the contents of the /dev/sda1 partition, and dd the previous partition.img into it…
I’ll know in a couple of minutes… ;-)
Aaand, we’re back! Thanks for all the help.
I opted for jeltka.sh (since I was already going down that road when your reply came). This time, Fedora, which had no problem partitioning before with the old disk, complained. But Debian, which couldn’t partition the previous disk, had no trouble with this one. Go figure. (It wasn’t network trouble either time, since both distros were able to download pieces for both hard disks. It was only when it got to partitioning, that the complaining started.)
Once Debian finished installing, “rm -rf /*” followed by the umount, dd, e2fsck and resize2fs put my old partition into the new machine, and all appears to be well.
There was a momentary Dropbox hiccup, as it was sensitive to the disk change, and Audacity tried to play a really weird playlist of random numbers, but then everything calmed down, and, as near as I can tell, I’m back to “normal”.
Glad you got there.
resize2fs is not a known command in Jeltka?
# resize2fs
-sh: not found
(I updated the firmware in case it was a new command, but no).
advice?
Are you sure you updated? – I don’t think extutils was in some older versions.