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
