Re: Some help with dd backing up into an iso
Hi,
GiaThnYgeia wrote:
> So each manufacturer may have a different internal system but the output
> is standardized. So we don't really know what goes on in there, right?
Yes. We programmers enjoy the simplified model of an array of consecutive
logical blocks. The physical blocks are a matter of disk manufacturer and
data rescue companies.
> > Encryption shall camouflage the true content.
> so part of the trick is filling in fake data so you can't tell
> the real ones,
It is not necessarily adding of fake data but rather exchanging
understandable or predictable bit patterns by other bit patterns which
we would consider random noise.
> > [shell piping and redirection]
> So it is like combining various processes and their inputs and outputs
> into one, which is the final product the user needs.
Yep. This is what makes the colorful GUIs look like fancy toys
- if not like handcuffs.
> $free
> ...
> Mem: 3884232 1596976 302428 ...
> Swap: 0 0 0
There is no swap space enabled. And your RAM is not really large.
You should look for advise about system startup and swap configuration.
> In other isos I've seen you can see the filesystem partition.
> So I started studying xorriso
Partitions inside an ISO 9660 filesystems are normally preparations for
booting from USB stick. Quite a variform topic:
https://dev.lovelyhq.com/libburnia/libisofs/blob/master/doc/boot_sectors.txt
> > If you tell me the path to the mount point of the data partition i will
> > modify my previous example to that address.
> depending on the position or how many sticks I have on it is usually
> dev/sdb or dev/sdc
That's the device path, not the mount point.
The mount point is a directory in the overall filesystem tree. With removable
media it is nowadays created underneath /media or /mnt. This directory then
represents the root directory of the mounted additional filesystem.
> Once you install a system like debian, does the information
> in the hidden part of the disk ever change,
Well, on the level of logical blocks there is no hidden part.
There may be space which is not claimed by partitions.
The unclaimed space before the first partition is usually inhabited by
a partition table and possibly by boot loader software.
Changes of partitioning or boot loader will happen there.
A GUID partition table (GPT) has a backup copy at the very end of the
storage medium, which is not part of any partition and changes in sync
with the main GPT table at the start of the medium.
> This systemd-udev is not within the filesystem partition, it is outside
> somewhere in the beggining of the disk [...] ?
No. systemd is (if ever) part of the operating system that gets started
by the boot loader. This start procedure starts a program (the kernel of
the operating system), gives it a minimal filesystem (initial RAM disk),
and tells it the disk partition which shall serve as root filesystem.
>From then on the started operating system is in charge.
At some stage of starting up it will start the systemd program which then
may be in charge of mounting other filesystems into the root filesystem
tree.
But here my knowledge gets thin. Maybe Michael Biebl can explain better
when and how systemd starts up and how it is related to mounting and
activating swap.
> What is the boot flag for and is it necessary on linux?
The Boot Flag is a bit in the partition table of an MBR.
It is simply a indicator for some boot loaders, from which partition
they shall load the program code for the next step of booting.
This does not apply to the two main boot loaders used with Linux on
BIOS firmware: SYSLINUX/ISOLINUX and GRUB. Those loaders know by other
means from where to load the info and programs for their next steps
of booting.
Some firmwares, especially brain damaged EFI implementations, insist
in seeing the boot flag at some MBR partition or else they will not
consider the whole device as bootable.
On the other hand the EFI System Partiton must not be marked by the
boot flag. So EFI from MBR partition table needs a second partition
to expose the boot flag to the poorly implemented EFIs.
> let's say swap is sdb1 and the filesystem is sdb2
For a backup or archiver program you need the mount point path, not the
partition path.
On conservatively mounting systems you may look up the mount point
address by searching for the partition name:
mount | grep sdb2
will reply something like
/dev/sdb2 on /tmp type ext4 (rw,relatime,data=ordered)
Here /tmp is the mount point.
Less conservative systems mount by partition UUID rather than by
partition path. So no "sdb2" will be to find in the output of command
"mount". Nevertheless, "mount" without "| grep sdb2" will tell you
all mount points. Maybe you can identify your partition in that list.
> [portable data disk] may help me from having to maintain two separate
> but parallel systems and just have one portable one and just use the hd
> for just data files of work that I do.
As long as the filesystem type (ext4, btrfs, ...) is supported by the
operating systems it should be no problem to read and (if applicable)
write data to it.
If there is system software in the filesystem it may be that this runs
as program only on the system by which it was installed in the filesystem.
But those program files can still be copied, overwritten, or renamed.
> Unless one studies filesystems it is hard to understand
> why this 9660 is important.
It is mountable by about all known operating systems. Further it is
to be mounted read-only. So it is a good candidate for archiving and backup.
There is a special boot sector format prescribed for PC-BIOS and EFI
when the boot medium is a CD, DVD, or Blu-ray disk. This format is named
El Torito (after the restaurants) and specified as add-on to ISO 9660
filesystems.
So about every bootable optical disc is equipped with an ISO 9660
filesystem (possibly augmented by UDF filesystem, or Joliet directory
trees).
> What I understood is its limitation to long and complex filenames.
> So if I was to back up something with huge filenames I suspect it
> may run into problems
The filenames of ISO 9660 are indeed not better than with MS-DOS.
But there is the Rock Ridge extension (named after the movie Blazing
Saddles) which records file names of up to 255 characters length and
distinguishes between upper case and lower case chracters. I.e. it
fulfills the demands of X/Open in respect to filesystem naming schemes
on a Unix-like system.
Reading Rock Ridge is a speciality of Unix-like operating systems.
On a non-Unix operating system, the file names may indeed appear
crippled to short length and all upper or all lower case.
Microsoft has its own add-on named "Joliet". Names up to 64 characters.
(xorriso command -joliet "on" activates its production.)
xoRRiso has Rock Ridge in its name and in its genes. So don't worry
about backup fidelity as long as you want to restore it on a Linux
system. (xorriso command -for_backup will also store ACLs and Extended
attributes, but only xorriso can recognize them in the ISO and restore
them by its extraction commands.)
> how often in a debian system do things
> in the boot sector change, if ever.
Normally the unclaimed regions of a storage medium are left unchanged.
But installing or updating a boot loader will change the start region.
Editing the partition table will too cause a change there.
> If the studio only uses some
> commercial expensive apple stuff it helps having a file-system with you
> to edit the files while on the run.
One may change the effective content of an ISO 9660 filesystem but
this is not as easy as with a read-write filesystem.
If you want read-write and maximum compatibility to operating systems,
the old FAT filesystem is the best choice. (Not for archiving, to be clear.)
That's the filesystem type which you normally find on newly purchased
USB sticks.
David Christensen wrote:
> AFAIK when using MBR partitioning, the partition table (blocks 0-62)
The MBR partition table resides in the first 512-bytes block.
It may be extended by a chain of partitions starting at the Extended
Partition of the MBR partition table.
The EBRs of the logical partitions are stored at the start of those
partitions. I.e. scattered over the storage medium.
A GPT partition table begins at the second 512-block and can stretch
over quite a large range of blocks, depending on the number of
allocated partition slots. 4 partition slots occupy one 512-block.
Have a nice day :)
Thomas
Reply to: