Correct. I know how it can be done in theory, but I presume that people who do this for a release version do not do it this way. And I would want to avoid small mistakes in calculation of the size of the elements involved, or forgetting something in the procedure.
I have tried the script posted here and after correcting some mistakes it works, but now the next step would be to loopmount the image and resize the FS and partition in it.
I have two images, for the Pi and for the Cubieboard2, but it should be possible to use the same script.
Yes. (And it seems fairly obvious now that whatisname isn't going to supply any script despite assuring us of how straightforward it is.)
Anyway, I agree that it would be doable, but would take a while to work through the ifs and buts of the steps that you described in an earlier post, and would be a waste of time if somebody's already done it. But since the arch maintainer has quit supplying an image for the Pi and just supplies a tarfile, I suspect that nobody's got around to it yet, and the Raspbian maintainers are still doing it manually.
By heck who fell out of the grumpy tree and hit every grumpy branch on the way down? Yes I could and no I wont. Simply because people never learn how do things if you post a script for them.
Post the ideas and let others put it together themselves. That way they learn how it works rather than blindly running somebody's script. They wont know how to fix it when it stops working that way. When they get stuck, let them post their attempt and advise them on that. It's the only way people ever learn.
So there is a Raspbian image mounted. You can play about copying to and fro. You could mount both partitions if you want.
At work we maintain a standard image of our default filesystem, make a working copy of that, mount it and rsync in the changes we need, unmount and use that new image. So the image is traceable from the standard image, new files and the script used. They're all kept in the SCM (P4 in this case). Typically the changes are customer files/changes. We could keep a raft of images but it's simpler to have one standard and adapt it before using/shipping to the customer. In our case it's not Pi stuff but a Linux filesystem for SoCs we design that get used in mobile phones/tablets/set-top boxes.
You need to be careful who mounts the image so that permissions etc. are correctly preserved across the file systems.
If you describe somebody's script as "lowering the river rather than raising the bridge" then expect a touch of pushback. :) It started off simple, then grew somewhat as I added safety catches, and does do what I want -- and Rob has now said it was of some help towards his issue.
As for what Rob is asking, he evidently already does know how to do it manually, and has described the steps needed to do it image-wise, and said that he already understood the general principles of manipulating an image. But his asking if somebody's already got a script is fair enough, since I would guess there's a day's work in it to account for all the ifs and buts, and *would* be a waste of time if somebody's already done it.
Maybe he should learn to use Google because I found a script specifically for loop mounting Raspbian when checking I had the right info and I'll put money on the fact there'll be scripts for maintain sync between filesystems that are mounted on different machines.
Or he could learn to use rsync. Hmm.. googling "rsync 2 filesystems" gives some useful wiki pages. One likely looking article starts
"This article is about using rsync to transfer a copy of your "/" tree, excluding a few select folders. This approach is considered to be better than disk cloning with dd since it allows for a different size, partition table and filesystem to be used, and better than copying with cp -a as well, because it allows greater control over file permissions, attributes, Access Control Lists (ACLs) and extended attributes."
As apparently nobody has done it this way and I am not prepared to go further along with discussions about "why do you want that" and "why don't you do what I like instead of what is required" as made by other "contributors" to the thread (as usual), I have gone forward and completed the script that does what I need.
It requires a Linux system with a losetup command that supports the -P flag. Sorry, no Debian Wheezy. It works OK on my OpenSUSE 13.1 system.
I still think that's the easy bit. I did have a think about it before deciding to go with tarfiles for my own use.
I figured you'd have to pad the end of the whole image file with dd, then loopmount the whole image with losetup, then increase the size of the ext4 partition with sfdisk. THEN do your mounting of the ext4 partition at the calculated offset, resize2fs it to the enlarged partition size, copy in the files, restore the first-boot configuration by tweaking some file with sed, and then resize2fs it back down to file usage plus some safety margin to be determined. Then loopmount the whole image again, sfdisk the ext4 partition size to match its filesystem. Then truncate the unused space off the end of the whole image. Something like that.
It is scriptable, but tiresome. Well, it would be for me, anyway.
The script I use generates a minimum sized image file from a running system using a combination of loopmount and rsync. No truncation or resize required.
OK, I've been following this discussion with a bit of interest, because I have a slightly similar need (discussed in another thread), but it seems to me you're missing a somewhat vital point here...
That image file you're mounting contains the exact blocks of a partition (or partitions), complete with filesystem structure. All of a fixed size. The point of building a custom image is that it's almost bound to be *bigger*. So it probably won't fit into that original minimum partition!
-- Pete --
--
============================================================================
The address in the header is a Spam Bucket -- replies will not be seen...
(If you do need to email, replace the account name with my true name.)
============================================================================
Furthermore, I am making the changes not to a master image but to a card used in the Pi, and when it is finished I copy it back to a diskfile to be copied to other cards.
I am not trying to modify Raspbian, I am setting up a ready made card to be used in a project where several systems are running the same configuration and only some details like hostname need to be changed.
The filesystem has been extended to full cardsize when it is used on the Pi, so it has to be shrunk back to the minimal size (as appropriate to include the installed programs) or else it cannot be written to a card even when the same number of GB is printed on it but actually it is slightly smaller. (and that happens!)
So what I need is nothing related to rsync, tar, or other file copying mechanisms, but a script that resizes partitions. So that is what I have written. I am not interested in the babble about why I would not want that.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.