[SOLVED] Downsizing the micro-SD card, kernel panics, no rootfs found

Started by Nate, March 26, 2020, 05:16:24 am

Previous topic - Next topic

Nate

March 26, 2020, 05:16:24 am Last Edit: March 27, 2020, 12:51:41 am by Nate Reason: Add additional info per the request of Klaus below
I have a LIME2 based Freedombox Pioneer that I have connected an external SATA drive to keep most of the frequently written areas of the root file system off the micro-Sd card.  The card in question is a 32 GB but less than 2 GB is used in total between both partitions.  I have a 4 GB card that I would like to use in place of the 32 GB which I can use for something else.

I used dd to copy the 32 GB image to my laptop running Debian Testing and followed some instructions to access it via the loopback interface.  I found that gparted apparently cannot resize a btrfs partition.  The next solution was to truncate the image file (after making a backup of the files in the p2 partition) to less than 4 GB, without a second partition, write the resulting image to the 4 GB card, create a new btrfs partition on the remainder of the card, and finally copy the files back with rsync.  So far so good.

I edited the /etc/fstab on the 4 GB card with the new UUID and also labeled the second partition as "root" which matches the label of the same partition on the 32 GB card.  I found that /conf/conf.d/default_root in the initrd image contains the line:

ROOT="/dev/disk/by-uuid/ea375ed2-d6e7-49d4-9b19-a624ba09b96c"
which I updated to the new UUID.  Of course I had to extract the initrd image, edit the file, and then recreate the initrd, but perhaps I missed a step as the kernel panics with a message of not being able to find the rootfs.  In this case I don't know if it is unable to locate the initrd image or the actual root partition.

The easiest would be to be able to make a new copy of the 32 GB card and then resize the second partition to a size that would fit on the 4 GB card, but I'm still faced with figuring out how to get the system to boot.

I'm open to ideas.

EDIT:

Per request of Klaus the outputs of the 32 GB card supplied by Olimex with the Freedombox Pioneer HSK:

$ sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 29.74 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6638a753

Device        Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk0p1 *      2048  264192  262145  128M 83 Linux
/dev/mmcblk0p2      266240 62333951 62067712 29.6G 83 Linux

$ sudo blkid /dev/mmcblk0*
/dev/mmcblk0: PTUUID="6638a753" PTTYPE="dos"
/dev/mmcblk0p1: UUID="28a82688-57a8-4580-9917-f1721c27abf5" TYPE="ext2" PARTUUID="6638a753-01"
/dev/mmcblk0p2: LABEL="root" UUID="ea375ed2-d6e7-49d4-9b19-a624ba09b96c" UUID_SUB="64e47447-c8c6-4549-9451-60f3271e4bd9" TYPE="btrfs" PARTUUID="6638a753-02"

In addition, here are the same outputs for the 4 GB card where I created a new p2 partition and copied the files over:

$ sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 3.71 GiB, 3965190144 bytes, 7744512 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6638a753

Device        Boot  Start    End Sectors  Size Id Type
/dev/mmcblk0p1 *      2048  264192  262145  128M 83 Linux
/dev/mmcblk0p2      266240 7743487 7477248  3.6G 83 Linux

$ sudo blkid /dev/mmcblk0*
/dev/mmcblk0: PTUUID="6638a753" PTTYPE="dos"
/dev/mmcblk0p1: UUID="28a82688-57a8-4580-9917-f1721c27abf5" TYPE="ext2" PARTUUID="6638a753-01"
/dev/mmcblk0p2: LABEL="root" UUID="1453ab42-43ed-4390-9518-9d1d84be73b6" UUID_SUB="6dfaf09f-aad2-4b7b-a833-a3367711804c" TYPE="btrfs" PARTUUID="6638a753-02"

LubOlimex

We are not very familiar with the FreedomBox Linux, if some user knows it would be great, but it might be a generally good idea to post in the FreedomBox community forum (if you haven't already). People there might give you better advice on how to do the copy-paste (or maybe export).
Technical support and documentation manager at Olimex

Nate

I doubt this is anything unique to the Freedombox applications.  I'm trying to figure out where and how u-boot passes the rootfs UUID, label, dev name, or whatever to the kernel.  It doesn't seem to be found in an easy to edit configuration file.


JohnS


Klaus

Nate,
 can you pls. insert the 32GB Card into a PC/Laptop and amend the output of
sudo fdisk -l /dev/'device of 32GB-Card'
sudo blkid /dev/'device of 32GB-Card'*  <- don't forget the asterisk!!
to your initial posting.

Rgds.,
Klaus

Nate


Klaus

Nate,
 hope you still have the 32GB image on your laptop.
Insert the 4GB SD-Card into your laptop and copy the first part of your image onto the SD-Card
sudo dd if=/path/to/image of=/dev/mmcblk0 bs=1M count=129After that,
- edit the partition table of the SD-Card and delete the second partition.
- create a new second partition using the remaining space of the SD-Card.
- format the second partition with the btrfs filesystem.
- change the UUID of the new partition with the following command:
sudo btrfstune -u ea375ed2-d6e7-49d4-9b19-a624ba09b96c /dev/mmcblk0p2- create two directories
sudo mkdir /tmp/image
sudo mkdir /tmp/sdcard
mount the appropriate partitions to the directories
sudo mount -o loop,offset=$((129*1024*2)) /path/to/image /tmp/image
sudo mount /dev/mmcblk0p2 /tmp/sdcard
Now copy the content of /tmp/image to /tmp/sdcard and unmount the mounts.
You should now have a 4GB SD-Card with the same UUIDs as you have on the 32GB SD-Card and therefore the 4GB-Card should boot.

Rgds.,
Klaus




Nate

Thanks, Klaus!

That worked though the order of the steps I had to take changed due to the system on my laptop not being able to deal with mounting two devices with the same UUID.  So I set the p2 UUID on the card back to what it was, used rsync to update the files from the 32 GB image to the card, get everything unmounted, then change the p2 UUID on the card.

The current version of btrfstune on the laptop running Debian Testing required the -U option instead of -u.  Otherwise, you were spot on.

I can now say this is resolved.