It occurs to me that essentially a copy of the contents of the two PI partitions would be enough, together with an install of Raspios,
followed by a copy back to the fresh SD, to clone a setup.
It seems too easy. What am I missing?
On 9/17/23 04:19, The Natural Philosopher wrote:
It occurs to me that essentially a copy of the contents of the two PI
partitions would be enough, together with an install of Raspios,
followed by a copy back to the fresh SD, to clone a setup.
It seems too easy. What am I missing?
Raspberry -> Accessories -> SD Card Copier
"The Natural Philosopher" <tnp@invalid.invalid> wrote
| > Raspberry -> Accessories -> SD Card Copier
| >
| What has a raspberry to do with this?
|
Start menu. The raspberry icon in lower left.
You didn't say which Pi you have, so you may not
have that icon or the copier software.
"The Natural Philosopher" <tnp@invalid.invalid> wrote
| > |
| > Start menu. The raspberry icon in lower left.
|
| ??? Icon? On a headless Pi Zero?
|
Ah. You might have said that in the first place. It
doesn't make much sense to ask for help and then
be difficult with people who try to help. I gather you
only posted to argue.
No. I am trying to establish whether one can, in essence, make a
bootable PI SD card by taking a raw card, creating the two partitions on
it and loading it up with files,
The Natural Philosopher <tnp@invalid.invalid> wrote:
No. I am trying to establish whether one can, in essence, make a
bootable PI SD card by taking a raw card, creating the two partitions on
it and loading it up with files,
Yes. In fact if you set the OS up from scratch you don't even need
two partitions, just one FAT32 parition with the boot files
required by the Pi.
I set up a Linux system to boot off the FAT32 parition then run in
a tmpfs. So instead of an image file there's just a ZIP archive
which needs to be unpacked to the root of a FAT32-formatted SD
card. No image writer tool required, and no worries about partition
sizes.
The Pi doesn't need anything like a boot sector. The firmware is
smart enough to find the boot files on the filesystem, provided
it's FAT32.
On 19/09/2023 03:15, Newyana2 wrote:
"The Natural Philosopher" <tnp@invalid.invalid> wroteNo. I am trying to establish whether one can, in essence, make a
| > |
| > Start menu. The raspberry icon in lower left. |
| ??? Icon? On a headless Pi Zero?
|
Ah. You might have said that in the first place. It
doesn't make much sense to ask for help and then be difficult with
people who try to help. I gather you only posted to argue.
bootable PI SD card by taking a raw card, creating the two partitions on
it and loading it up with files, or whether there is the equivalent of a
boot sector which would mandate the use of e.g. dd to create it
Naturally all the documentation assumes a windows numpty and shows you
how to stamp the SD card with an image.
You assumed I wanted to clone the card. I don't. I want to back one up without using DD because, as the concurrent thread has identified, the
PI expands the file system to the whole card and that makes for a big
image.
I'd rather back it up as files if possible.
If at some future date I need to recreate it, instead of dd-ing the
image, I would prefer to create the two partitions and populate them
from the tarball.
On 19/09/2023 10:11, Computer Nerd Kev wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:I suppose that needs to be the first partition?
No. I am trying to establish whether one can, in essence, make a
bootable PI SD card by taking a raw card, creating the two partitions
on it and loading it up with files,
Yes. In fact if you set the OS up from scratch you don't even need two
partitions, just one FAT32 parition with the boot files required by the
Pi.
I set up a Linux system to boot off the FAT32 parition then run in a
tmpfs. So instead of an image file there's just a ZIP archive which
needs to be unpacked to the root of a FAT32-formatted SD card. No image
writer tool required, and no worries about partition sizes.
The Pi doesn't need anything like a boot sector. The firmware is smart
enough to find the boot files on the filesystem, provided it's FAT32.
So putatively one might back up everything in / except /run, /proc &
/sys, including /boot, plonk a shiny new SD card in a host computer,
create a VFAT partition of say 256MB, and the rest as ext4, untar the
archive into the ext4 partition and move the entire contents of /boot
onto the VFAT, shove the card in a pi , apply power, and Robert should
be a relative?
On Tue, 19 Sep 2023 08:15:03 +0100, The Natural Philosopher wrote:
No. I am trying to establish whether one can, in essence, make a
bootable PI SD card by taking a raw card, creating the two partitions on
it and loading it up with files, or whether there is the equivalent of a
boot sector which would mandate the use of e.g. dd to create it
Take a look at 'rsync' - its my go-to tool for backing up complete Linux filing systems, specific partitions or lists of files and partitions to as
a named directory structure on a backup disk.
It is designed make the backup directory structure identical to the
current list of files and directories you ask it to back up, IOW, if you rerun the sa,me command a week later it will remove any files and
directories from the previous backup session, replace any files and directories that have been changed and add any new files and directories.
Consequently, subsequent runs will usually be much faster than the initial backup.
/sys, /proc, /run would seem to be created by the machine at boot time,
and shouldn't be created as subdirs of the root partition...or should
the directories be created, but empty?
So putatively one might back up everything in / except /run, /proc &
/sys, including /boot, plonk a shiny new SD card in a host computer,
create a VFAT partition of say 256MB, and the rest as ext4, untar the
archive into the ext4 partition and move the entire contents of /boot
onto the VFAT, shove the card in a pi , apply power, and Robert should
be a relative?
The vfat partition will get mounted on the (now empty) /boot mount
point, and everything else will be where it ought to be, and /run /sys
and /proc will get generated by the boot process?
What about /dev? Is that dynamically created or not?
On 19/09/2023 10:11, Computer Nerd Kev wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:
The Pi doesn't need anything like a boot sector. The firmware is
smart enough to find the boot files on the filesystem, provided
it's FAT32.
I suppose that needs to be the first partition?
The other question why always gets me on backups is how many of the directories in the root partition can safely be ignored?
/sys, /proc, /run would seem to be created by the machine at boot time,
and shouldn't be created as subdirs of the root partition...or should
the directories be created, but empty?
So putatively one might back up everything in / except /run, /proc &
/sys, including /boot, plonk a shiny new SD card in a host computer,
create a VFAT partition of say 256MB, and the rest as ext4, untar the
archive into the ext4 partition and move the entire contents of /boot
onto the VFAT, shove the card in a pi , apply power, and Robert should
be a relative?
The vfat partition will get mounted on the (now empty) /boot mount
point, and everything else will be where it ought to be, and /run /sys
and /proc will get generated by the boot process?
What about /dev? Is that dynamically created or not?
On Tue, 19 Sep 2023 10:35:23 +0100, The Natural Philosopher wrote:
On 19/09/2023 10:11, Computer Nerd Kev wrote:Nope: just whatever partition the RPi installer configured to be the boot partition.
The Natural Philosopher <tnp@invalid.invalid> wrote:I suppose that needs to be the first partition?
No. I am trying to establish whether one can, in essence, make a
bootable PI SD card by taking a raw card, creating the two partitions
on it and loading it up with files,
Yes. In fact if you set the OS up from scratch you don't even need two
partitions, just one FAT32 parition with the boot files required by the
Pi.
I set up a Linux system to boot off the FAT32 parition then run in a
tmpfs. So instead of an image file there's just a ZIP archive which
needs to be unpacked to the root of a FAT32-formatted SD card. No image
writer tool required, and no worries about partition sizes.
The Pi doesn't need anything like a boot sector. The firmware is smart
enough to find the boot files on the filesystem, provided it's FAT32.
So putatively one might back up everything in / except /run, /proc &Just tell dd to copy everything from the source SD card to the new one. If the latter card is bigger,use parted to extend the new ext4 partition and
/sys, including /boot, plonk a shiny new SD card in a host computer,
create a VFAT partition of say 256MB, and the rest as ext4, untar the
archive into the ext4 partition and move the entire contents of /boot
onto the VFAT, shove the card in a pi , apply power, and Robert should
be a relative?
to format the new sectors.
On Tue, 19 Sep 2023 08:15:03 +0100, The Natural Philosopher wrote:
On 19/09/2023 03:15, Newyana2 wrote:
"The Natural Philosopher" <tnp@invalid.invalid> wroteNo. I am trying to establish whether one can, in essence, make a
| > |
| > Start menu. The raspberry icon in lower left. |
| ??? Icon? On a headless Pi Zero?
|
Ah. You might have said that in the first place. It
doesn't make much sense to ask for help and then be difficult with
people who try to help. I gather you only posted to argue.
bootable PI SD card by taking a raw card, creating the two partitions on
it and loading it up with files, or whether there is the equivalent of a
boot sector which would mandate the use of e.g. dd to create it
Naturally all the documentation assumes a windows numpty and shows you
how to stamp the SD card with an image.
You assumed I wanted to clone the card. I don't. I want to back one up
without using DD because, as the concurrent thread has identified, the
PI expands the file system to the whole card and that makes for a big
image.
I'd rather back it up as files if possible.
If at some future date I need to recreate it, instead of dd-ing the
image, I would prefer to create the two partitions and populate them
from the tarball.
Take a look at 'rsync' - its my go-to tool for backing up complete Linux filing systems, specific partitions or lists of files and partitions to as
a named directory structure on a backup disk.
It is designed make the backup directory structure identical to the
current list of files and directories you ask it to back up, IOW, if you rerun the sa,me command a week later it will remove any files and
directories from the previous backup session, replace any files and directories that have been changed and add any new files and directories.
Consequently, subsequent runs will usually be much faster than the initial backup.
On 19/09/2023 20:05, Martin Gregorie wrote:
On Tue, 19 Sep 2023 08:15:03 +0100, The Natural Philosopher wrote:
No. I am trying to establish whether one can, in essence, make a
bootable PI SD card by taking a raw card, creating the two partitions on >>> it and loading it up with files, or whether there is the equivalent of a >>> boot sector which would mandate the use of e.g. dd to create it
Take a look at 'rsync' - its my go-to tool for backing up complete Linux
filing systems, specific partitions or lists of files and partitions
to as
a named directory structure on a backup disk.
It is designed make the backup directory structure identical to the
current list of files and directories you ask it to back up, IOW, if you
rerun the sa,me command a week later it will remove any files and
directories from the previous backup session, replace any files and
directories that have been changed and add any new files and directories.
Consequently, subsequent runs will usually be much faster than the
initial
backup.
Here's the rsync options I used to backup the partitions, firstly the
FAT partition which accounts for the lower resolution of timestamps
rsync -vax --stats --modify-window=2 --delete /boot/ <boot_backup_dir>
And the main partition with the exclusions to prevent pseudo filing
systems and temporary stuff being included when backing up live systems,
some of it shouldn't be necessary but turns out is needed
rsync -vaxHAX --stats --numeric-ids --delete --delete-excluded --exclude=/tmp/*
--exclude=/run/*
--include=/var/lock
--exclude=/var/run
--exclude=/var/swap
--exclude=/var/cache/*
--exclude=/var/tmp/*
--exclude=/var/lib/machines/*/var/cache/
--exclude=/var/lib/mlocate/*
--exclude=/var/lib/nginx/fastcgi/*
--exclude=/var/log/journal/*
--exclude=/var/log/Xorg.*
--exclude=/lost+found/*
--exclude=*/.cache
--exclude=*/__pycache__
--exclude=*/chromium/hyphen-data/
--exclude=*/.config/chromium/*Cache*/*
/ <root_backup_dir>
---druck
The Natural Philosopher <tnp@invalid.invalid> wrote:
/sys, /proc, /run would seem to be created by the machine at boot time,
and shouldn't be created as subdirs of the root partition...or should
the directories be created, but empty?
/sys, /proc and /dev are filesystems which are mounted at boot time. You need the empty directories to act as mount points, because Unix mounts filesystems on top of a directory that already exists, switching out
whatever is there.
It seems that some distros have /var/run and point a symlink from /run to
it, so it doesn't need a mount point created for them. They then mount a tmpfs at /var/run (so /var/run is an empty directory that needs to exist to be mounted on top of)
So putatively one might back up everything in / except /run, /proc &
/sys, including /boot, plonk a shiny new SD card in a host computer,
create a VFAT partition of say 256MB, and the rest as ext4, untar the
archive into the ext4 partition and move the entire contents of /boot
onto the VFAT, shove the card in a pi , apply power, and Robert should
be a relative?
I think that will probably work.
The vfat partition will get mounted on the (now empty) /boot mount
point, and everything else will be where it ought to be, and /run /sys
and /proc will get generated by the boot process?
One thing to watch that distros' /etc/fstab often mounts partitions based
on a UUID. So /boot on one SD will have a different UUID to another, and
the mount of /boot will fail. It'll still find the kernel from /boot, but any time later anything wants to load something from /boot it may fail because the mount failed. You could change the device name in /etc/fstab to be /dev/mmcblk0p1 or similar to be sure it's the same every time.
(the Pi has a single SD slot so no chance of mixing it up with another)
'blkid' will show your partition devices with their UUIDs.
What about /dev? Is that dynamically created or not?
A dynamic filesystem mounted to a static pre-existing mount point.
Theo
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 19/09/2023 10:11, Computer Nerd Kev wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:
The Pi doesn't need anything like a boot sector. The firmware is
smart enough to find the boot files on the filesystem, provided
it's FAT32.
I suppose that needs to be the first partition?
"It is no longer necessary for the first partition to be the FAT
partition, as the MSD boot will continue to search for a FAT
partition beyond the first one."
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#boot-sequence
The other question why always gets me on backups is how many of the
directories in the root partition can safely be ignored?
/sys, /proc, /run would seem to be created by the machine at boot time,
and shouldn't be created as subdirs of the root partition...or should
the directories be created, but empty?
/sys and /proc can be created empty, because they're mountpoints.
However I don't bother excluding them from backups personally.
So putatively one might back up everything in / except /run, /proc &
/sys, including /boot, plonk a shiny new SD card in a host computer,
create a VFAT partition of say 256MB, and the rest as ext4, untar the
archive into the ext4 partition and move the entire contents of /boot
onto the VFAT, shove the card in a pi , apply power, and Robert should
be a relative?
The vfat partition will get mounted on the (now empty) /boot mount
point, and everything else will be where it ought to be, and /run /sys
and /proc will get generated by the boot process?
Yes. Mounting the FAT32 partition at /boot is specific behaviour
for RPi OS / Debian. Linux itself doesn't care if that partition
gets mounted at all - by the time the kernel is loaded its job has
been done, but Debian probably expects it there for configuration
and upgrades.
What about /dev? Is that dynamically created or not?
The device files need backing up, or else something might have to
create them with mknod. It contains more mountpoints though, so
you can look at the list displayed by "mount" and exclude those sub-directories of /dev if you like. Again, I don't bother to do
that.
It occurs to me that essentially a copy of the contents of the two PI partitions would be enough, together with an install of Raspios,
followed by a copy back to the fresh SD, to clone a setup.
It seems too easy. What am I missing?
"The Natural Philosopher" <tnp@invalid.invalid> wrote
Start menu. The raspberry icon in lower left.
??? Icon? On a headless Pi Zero?
Ah. You might have said that in the first place.
It doesn't make much sense to ask for help and then
be difficult with people who try to help. I gather
you only posted to argue.
On 2023-09-19, Newyana2 <Newyana2@invalid.nospam> wrote:
"The Natural Philosopher" <tnp@invalid.invalid> wrote
Start menu. The raspberry icon in lower left.
??? Icon? On a headless Pi Zero?
Ah. You might have said that in the first place.
It doesn't make much sense to ask for help and then
be difficult with people who try to help. I gather
you only posted to argue.
This is totally off topic, but I'm curious: did you
once post under the name "Mayayana"? If so, I'd like
to thank you for the quote in my .sig below.
The other question why always gets me on backups is how many of the directories in the root partition can safely be ignored?
Here's the rsync options I used to backup the partitions, firstly the
FAT partition which accounts for the lower resolution of timestamps
rsync -vax --stats --modify-window=2 --delete /boot/ <boot_backup_dir>
And the main partition with the exclusions to prevent pseudo filing
systems and temporary stuff being included when backing up live systems,
some of it shouldn't be necessary but turns out is needed
rsync -vaxHAX --stats --numeric-ids --delete --delete-excluded --exclude=/tmp/*
--exclude=/run/*
--include=/var/lock
--exclude=/var/run
--exclude=/var/swap
--exclude=/var/cache/*
--exclude=/var/tmp/*
--exclude=/var/lib/machines/*/var/cache/
--exclude=/var/lib/mlocate/*
--exclude=/var/lib/nginx/fastcgi/*
--exclude=/var/log/journal/*
--exclude=/var/log/Xorg.*
--exclude=/lost+found/*
--exclude=*/.cache
--exclude=*/__pycache__
--exclude=*/chromium/hyphen-data/
--exclude=*/.config/chromium/*Cache*/*
/ <root_backup_dir>
On 2023-09-19, druck <news@druck.org.uk> wrote:
Here's the rsync options I used to backup the partitions, firstly the
FAT partition which accounts for the lower resolution of timestamps
rsync -vax --stats --modify-window=2 --delete /boot/ <boot_backup_dir>
And the main partition with the exclusions to prevent pseudo filing
systems and temporary stuff being included when backing up live systems,
some of it shouldn't be necessary but turns out is needed
rsync -vaxHAX --stats --numeric-ids --delete --delete-excluded
--exclude=/tmp/*
--exclude=/run/*
--include=/var/lock
--exclude=/var/run
--exclude=/var/swap
--exclude=/var/cache/*
--exclude=/var/tmp/*
--exclude=/var/lib/machines/*/var/cache/
--exclude=/var/lib/mlocate/*
--exclude=/var/lib/nginx/fastcgi/*
--exclude=/var/log/journal/*
--exclude=/var/log/Xorg.*
--exclude=/lost+found/*
--exclude=*/.cache
--exclude=*/__pycache__
--exclude=*/chromium/hyphen-data/
--exclude=*/.config/chromium/*Cache*/*
/ <root_backup_dir>
I use very similar options. I add -u and I add the --delete-after
option. Oh and --numeric-ids . I've been bitten by backing up to a
system where some of the system uids (<1000) were different and on backup
got mangled. At least with numeric-only they go back as they were.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 371 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 175:07:36 |
| Calls: | 7,915 |
| Files: | 12,983 |
| Messages: | 5,797,724 |