Linux Linux Basics section
Miscellaneous section

See my "Moving to Linux" page
See my "Installing Linux" page
See my "Using Linux" page





Basics



Layers / variations:
Layers:
[Mostly from lowest to highest:] A bundle of choices of the last 4-5 items usually is called a "Desktop Environment" (DE): Xfce, LXDE, LXQt, Cinnamon, MATE, Plasma, etc.



Distributions (distros):
A distro is a set of choices of layers/parts/policies, all packaged together under one label.

Some major distros: Debian, Fedora, Red Hat, Ubuntu, Xubuntu, Linux Mint, openSUSE, etc.

Debian Family Tree (!)
Which turns out to be just part of a bigger GNU/Linux Distributions Timeline (!!)



Other pieces that usually vary by DE:



Other pieces that often vary by distro or distro-family:



Some other variations or modifications:




Newbie questions:



More-complicated things you can do:



See my "Moving to Linux" page










Miscellaneous



If you want to contribute to the Linux community:
You could pick an app or distro and:

Jason Evangelho's "8 Ways To Contribute To The Desktop Linux Community, Without Knowing A Single Line Of Code"
wikiHow's "How to Contribute to Open Source"
LTP - Linux Test Project
See "Reporting Bugs" section of my "Using Linux" page
Shubheksha's "How to find your first open source bug to fix"
Davide Coppola's "How to contribute to an open source project on GitHub"
Quora discussion "How do I start contributing in Open Source projects?"


For development, start with an app, DE, or distro you use:

First, become a very good user:
  • Use the software, explore the features, read the docs and Help.

  • Update to the latest version, or the beta version.

  • File bug reports, and read the open issues/bugs.

  • Join the user forum or group or reddit sub.


Development things to realize:
  • Probably you will be stepping into a project that has a 20-year history, an enormous base of scripts, code, docs, and issue-tracking, and a big somewhat-changing team of developers.

  • It will take time to learn the code and tools and style.

  • Flitting from one project to another may be difficult, if they all use different tools and languages etc.

  • People-issues and process will be very important; follow the rules, be humble, start very small.

  • If a project seems stalled (2 years since last release, bugs open for a long time, pull/merge requests outstanding for a long time), or going through a huge transition, or very undocumented, or broken in some way, maybe stay away (at least as a first project to join).



Big projects often have extensive guides for developers:

GNOME Wiki's "Building system components"
KDE Community Wiki's "Get Involved"
Linux Mint Developer Guide
Debian Developers' Manuals
What can I do for Mozilla

From someone on reddit:
Anyone suitably capable can become an Ubuntu developer! ...

You start by providing fixes for existing Ubuntu developers to sponsor. Once you have a track record of good work and your existing sponsors are willing to endorse you, you can apply to become an Ubuntu developer yourself. ...
Ubuntu Packaging and Development Guide


Check the plans/roadmap for the unit you have chosen, to see the priorities, and what other people may be working on:
linuxmint / Roadmap

Find out the developer communication channels (mailing list, forum, bug-tracker, IRC, whatever) for the unit you have chosen, and join those channels.

Kernel:

Konrad Zapalowicz's "Three Ways for Beginners to Contribute to the Linux Kernel"
Adam Zerella's "How to become a Linux kernel developer"
torvalds / linux "HOWTO do Linux kernel development"
Arch: KernelBuild
Tamir Suliman's "Beginner's Guide to Writing your First Linux patch"
Sayli Karnik's "A checklist for submitting your first Linux kernel patch"
Kosta Zertsekel's "Who should I sent Linux Kernel patch to?"

Ashish Vara's "Kernel Architecture Of Linux (Part 7/15)"
Wikipedia's "Linux kernel - Architecture"
linux-kernel-labs' "Overview of the Linux kernel"

The Linux Kernel documentation
torvalds / linux (Linux kernel source tree)
Plailect / linux-devel (kernel development using VSCode and libvirtd)

Hcamael's "How to Develop Linux Driver from Scratch"



From someone on reddit:

> I want to take a stab at creating a couple of GUI Linux apps to improve
> the usability of some parts of the system that are locked to CLI.

Honestly, coding probably isn't going to be the lynchpin issue you'll run into.

Most projects are ruled like fiefdoms, some are more reasonable/practical than others and as a result allow for more broader contributions, but you still run into issues where maintainers/developers will not accept or consider certain features because it either violates their vision or ethos for what they think their creation should be, or they don't want to support features they aren't interested in (desktop icons disappearing from Gnome3 is a prime example), whatever the case it's not a coding issue, the biggest problems with OSs are people issues.



I'm looking to contribute:
I posted this:
I used to be a computer programmer; I have some dev skills. I'm retired; I have time and resources.

I'm using Mint, and I see lots of big issues in Linux, and some in Mint.

I'd like to contribute my efforts, but in a place where there's a lot of bang for the buck. More and more, to me, Mint seems out on a distant leaf of the Linux tree. For example, I could spend full time bug-fixing some Mint apps that have been forked from GNOME apps, but then the non-Mint part (98% ?) of the Linux desktop world gets no benefit from that.

I don't want to get into kernel or driver development (although I did a little of those, decades ago). My ideas seem to be somewhere around a new way of doing a Linux installer (making a pre-installer), or a new unified GUI on top of the Security mechanisms (iptables, AppArmor, Firejail, OpenSnitch, etc). Big ideas, maybe too big. But I would want to do them in a place where (if accepted) they would propagate out to a large share of the Linux desktop population.

I think I want to stay in the Debian tree. My ideas are mostly GUI ease-of-use things for newer users.

Maybe that means I should run and develop for Debian ? Or Ubuntu ? Does Debian tend to produce new system GUI apps ? Or does that kind of thing come from Ubuntu ? Does Mint just accept new apps that come from Debian or Ubuntu, or just go their own way ?

Maybe you experienced guys could outline a few strategies for devs who want to contribute. If someone wants to do kernel dev, use distro X and join project Y. If someone wants to do GUI DE dev, maybe see project Z. If someone wants to do system GUI app dev, maybe use Debian or Ubuntu and join project Q ?

From someone on reddit:
"'Debian unstable/sid', which, despite its name, is remarkably stable, has a rolling release and also has all advantages of Debian (huge repositories and community, stability)."
From someone else:
"Debian [is great, but] is a serious PITA when it comes to third-party drivers."



My very small start: Pix bug-fixing:
I decided to try fixing some of my own bug reports / feature requests in Pix, the image-processing app in Linux Mint. It's an app I use a fair amount, on a distro I use, written in a language (C) that I know.

I started the wrong way around, from the GitHub project for Pix (and filed bug report https://github.com/linuxmint/pix/issues/86). Had to wipe that out and start again.

Instead, start with Linux Mint Developer Guide. Install the tools:
apt update
apt install mint-dev-tools --install-recommends
apt install devhelp
"In general it’s a good idea to build mint-common and xapps first."
But I didn't do that.

Project is https://github.com/linuxmint/pix
Did:
cd ~/projects
git clone https://github.com/linuxmint/pix.git
cd pix
mint-build
# lots of:  warning: ‘gtk_*’ is deprecated [-Wdeprecated-declarations]
# some:    warning: remember to run 'libtool --finish /usr/lib/x86_64-linux-gnu/pix/extensions'
# succeeded, and created ELF binary ./pix/pix, and also a bunch
# of installer files in .. (above the project directory !)
Test via:
# replace standard with new one just built
sudo mv /usr/bin/pix /usr/bin/pix.sav
sudo cp pix/pix /usr/bin/pix

# run new one, see if it works
/usr/bin/pix

# restore back to standard version
sudo rm /usr/bin/pix
sudo mv /usr/bin/pix.sav /usr/bin/pix
Subsequent builds (after the first) can be done by:
cd ~/projects/pix
dpkg-buildpackage
I see that someone has had a Pix "pull request" (new code ready to merge into the master branch) outstanding for about 7 weeks now. Not a good sign.

gThumb:
In the README I see "Pix is based on gThumb 3.2.8.". Does this mean I should be bug-fixing in gThumb instead of in Pix, and the fixes will flow down to Pix ? gThumb is under active development. Looks like gThumb has a different build setup (meson + ninja) than Pix does (autoconf + make). Looks like Pix started from gThumb in 5/2016.

Installed gThumb. Turns out that Mint's Software Manager has the latest version that is compatible with this base version of Ubuntu. So installed from Software Manager.

Comparing Pix to gThumb (Pix is forked from gThumb), I like the Pix UI modifications done by the Mint team, and I found a setting that gets rid of one irritation I had with Pix. Also investigated and found a partial way to deal with another annoyance. Filed another small bug report against Pix.

Found this about building gThumb and other GNOME apps: GNOME Wiki's "Building system components"

And I see that someone has had a gThumb "merge request" (new code ready to merge into the master branch) outstanding for about 5 months now. Not a good sign. There has been lots of recent dev activity; maybe this request fell through the cracks.




Please don't create a new distro:
Please don't create a new distro. We have far too many already. GNU/Linux Distributions Timeline

If you want/need something, do it some other way. A configuration script that modifies an existing distro. A new DE or theme. A new kernel module. Whatever is appropriate for your need/idea.

Of course, if you have some great new world-beating idea that just can't be done in an existing distro, go for it ! But expect lots of work and little audience. Better if you could implement your idea in some major distro such as Ubuntu, and get it out to millions of users.



Linux is suffering from Fragmentation:
We should try to shift the culture toward some consolidation instead of everyone creating new distros and apps. Who needs 400 distros and 40 text editors ? How about 20 and 10 ?

The price we pay today for all the fragmentation is bugs and slow development. Have you run some of the standard GUI apps from CLI, and looked at the error messages that appear in the CLI window ? Assertion failures, broken pipes, use of insecure or deprecated APIs, more. The quality of many major apps on Linux is bad.

Installing / updating / package management is far too fragmented (see for example DistroWatch's "Package Management Cheatsheet"); we need a couple of standards, and push the various apps and services to use those.

It's not something one developer can do. We need to change (by persuasion) the culture, the attitudes, of the major devs and managers in the community.

...

People don't like to hear this. "HE'S SAYING NO ONE SHOULD DO ANYTHING NEW. HE WANTS TO STOP ME FROM DOING WHAT I WANT. HE WANTS LINUX TO BE LIKE MICROSOFT OR APPLE. HE'S EVIL, BURN HIM !"

Actually, what I'm saying is that the adults, the devs who do the big work and run the major distros, should think about ways to consolidate things a bit. For example, do Ubuntu, Lubuntu, Xubuntu, Kubuntu, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Cubuntu, Fluxbuntu, Ubuntu Mini Remix, UbuntuLite, Mint and many more (see Ubuntu wiki's "Derivatives") all need to be separate distros, or can they be one with various install and config options ? There would be a benefit to the community, in terms of mindshare and bug-fixing etc, if they could be one. Maybe there are technical reasons they can't be; I'm no expert. And I'm sure there are organizational/political/legal/strategy conflicts that would prevent some of this. But I'm putting forth the idea. Having 400 distros (see GNU/Linux Distributions Timeline) imposes costs and holds back Linux.

If all the *buntu's and Mint became one distro Ubuntu+, then when you fix a bug in that one distro, it's fixed in all the combinations. One set of release images. One repo. One set of tests.

...

With Windows or MacOS, a user or vendor has a very small and easy choice of what to use or support. Then they can customize on top of that.

With Linux, there are dozens of major distros and maybe 500 total distros. A new user or vendor is faced with an intimidating variety. Easier just to avoid Linux than to deal with that. Linux has somewhat-poor support for some graphics, Wi-Fi, and Bluetooth partly because of that, I think.

And suppose much of the effort put into tweaking and packaging and testing and delivering and supporting many of those distros was instead put into bug-fixing in the couple of dozen major distros ? Bugs would get fixed faster. New features would get created faster.

We need variety and choice, but a reasonable level of it. We never should prevent random person X from creating a new distro. But we need more focus among the majority, the core, of the community.

Tobias Bernard's "There is no 'Linux' Platform (Part 1)"



The CLI (terminal; Command-Line Interface):
From procabiak comment on Guide: Migrating to Linux in 2019:
Stop recommending the command line to beginners. Disclaimer/tl;dr: I like the command line, use it every day, but it's not the user-friendly tool you make it out to be. It's a tool for veterans, power users, tech-savvy folk. It's dangerous in the wrong hands.

This is a Linux/nix culture we need to move away from if Linux is to be successful mainstream. There's a reason many distros have a GUI for package management. If everything was indeed easier on a command line for every user demographic, why waste time implementing the GUI package manager, just tell everyone to use the terminal, right? Wrong! (IMO)

There're people who don't speak English or have difficulty with spelling even the simplest words, people with typing disabilities, older aged people, children ... Just to name a few, but all who just want to enjoy a game without needing to learn the complexities of Linux or us vets pushing that need onto them.

With a GUI package manager, you don't need to know anything beyond the ability to explore, click around to find stuff you need, etc. Often times you'll find other software you didn't think about wanting. The guide already states package managers are akin to app stores. These days everyone knows what an app store is (well, I make the assumption - there are people who have never owned smartphones before), so it's not as difficult a concept as it used to be, so we can use fewer words to explain it. The instructions are pretty simple: "open the package manager (app store) from the menu, search for steam and click install, enter your password and click OK". It's not faster than a command line, but it's simpler for many people. The instruction is nearly universal for all distros, even if the GUI looks or behaves slightly differently.

Contrast with apt, yum or pacman. You'd also need to learn to use grep to get anything remotely useful out of their list-package outputs. You can't explore - you just execute a command like sheep and hope you really just installed steam from Valve and not some other kind of steam. And when it comes to instructions, you need more words to explain the command line (that many people are omitting): "open the Terminal, type sudo apt-get install steam, type in your password (it shows up blank but your password is really there, keep typing), press enter, then type Y and press enter" ... Not only that, that command only works for Debian-based distros using apt. It will confuse Fedora and Manjaro novices using yum or pacman (they might even try to install apt, just to be able to run your command!).

You can also very easily mislead a novice to run dangerous "sudo rm -rf /"-like commands. I assume it's backwards to suggest to the user to understand the command before executing it when they are learning the command in the first place, so we can't assume the novice user will know what every command does. Therefore I can maliciously explain that line means "sudo = as a superuser, rm = remind me, -rf = to read from, / = root", for example. If I am their only reading material, I've just tricked a user to wipe their OS, imagine what else you can do to that novice by exploiting shortly-named commands?

The reality is command lines are simpler for the person offering help, but not necessarily for the person on the other end.

From grady_vuckovic comment on Guide: Migrating to Linux in 2019:
I have experience in converting people to Linux and that terminal is absolutely poison. When I show a typical Windows user an OS like Linux Mint, they are interested until they see the terminal, then groan and lose interest immediately.

Even if GUIs change, it is still waaaay easier for a new user to figure out a GUI with obviously labelled buttons, text boxes and tabs, than figure out how to use a terminal.

Try to put yourself in the mindset of a person who has only ever used a computer for homework, Facebook, job-hunting, Amazon, and who mainly uses a smartphone for all their computer needs. A terminal itself is a foreign concept and not a pleasant one.

On most decent software managers for Linux distros, the GUI is mostly pretty self-explanatory, with a simple search box for finding new software. That's pretty easy for a new user to figure out how to use.

But it is almost impossible for them to figure out what 'sudo apt-get steam' means at a glance, (and no, taking the time to explain it doesn't help, it will likely result in a 'wait wait I just want to install an app, why do I need to know all this rubbish?') or figure out where they need to go to type it, because if your user doesn't know where the software manager is, they certainly don't know where the terminal is or how to use it, so for all you know they could end up typing those commands into a search box somewhere. Not to mention it's difficult for them to even remember something like that.

And when I say "how to use it" regarding the terminal, I mean that literally. I've seen new users half type in commands, causing the terminal to enter a mode of waiting for the rest of the input of the command, then they can't figure out why it isn't working as they type in more and more commands, and other frustrations. It is truly a TERRIBLE user experience and one that should only be reserved for veteran Linux users.

Also keep in mind, users like to install and uninstall software, how on Earth is a user meant to figure out how to uninstall software which they installed with 'sudo apt-get'? There's no list of installed software they can look at, no buttons to click, no GUI to navigate, all they can do is hopelessly start Googling for help on how to use apt commands (that's an appallingly bad user experience for someone new to Linux) or (more likely) just get frustrated and decide "Linux is rubbish!" and switch back to whatever they were using before.

On top of that, it looks pathetically antiquated in 2019 to use a terminal to do such a simple basic OS operation as installing software or installing some drivers.

It may be easier for you to give instructions in terminal commands, and the terminal may be easier for you to use than a GUI, but it is scaring away possible Linux converts. For Ubuntu at least you should include instructions on how to navigate to the Software Manager.

I personally wouldn't offer any advice at all for Linux newbies that includes terminal commands unless you're trying to scare them away from Linux.

My thoughts:




Package formats and managers:
Format Distros Binary Managers
rpm Red Hat, Fedora, CentOS, SUSE, Mageia rpm, yum, dnf, zypper, YaST, urpmi, Drakrpm
deb Debian, Ubuntu, Mint dpkg, apt, apt-*, aptitude, Synaptic
tgz/txz Slackware, VectorLinux, Zenwalk pkgtools, slackpkg, slapt-get, Swaret, netpkg
pkg.tar.gz Arch pacman
tbz2 Gentoo, Sabayon emerge/Portage, entropy, equo
nix NixOS nix
xbps Void xbps
snap Ubuntu snap
Some front-end managers that work on top of multiple package formats: smart, PackageKit.

Devopedia's "Package Manager"
DistroWatch's "Package Management Cheatsheet"
The Hornery's "A Comparison of Popular Linux Package Managers"

From /u/Linux4ever_Leo on reddit:
Honestly, there really isn't anything stopping the Linux world from standardizing on one single package management system except for egos. Each distro line deems its own package management systems to be the "best". Red Hat derived distros use RPM packages; Debian derived distros use DEB packages, Slackware uses good ol' tarballs. Gentoo and Arch prefer sources based packages. Still other distros have developed their own proprietary ways of managing packages. In short, it's sort of a mess. ... Personally, I don't care what sort of package manager wins the game so long as SOMETHING is standardized which will help further the widespread adoption of software on Linux and make things easier for developers to port their software to the Linux platform.




Disk management and encryption:
Layers:
  1. Linux standard organization of files and directories in a system: /, /bin, /etc, /etc/passwd, /usr, and so on.
    Chris Hoffman's "The Linux Directory Structure, Explained"

  2. Linux OS API to a filesystem: inodes which represent files (some of which are directories), operations such as read/write/createfile/deletefile/makedir/rmdir.
    Wikipedia's "File system"

    Format on disk (of ext* filesystem):
    - Boot block ?
    - Superblock (maybe run "sudo dumpe2fs -h /dev/sda1 | more" to see info).
    - Inode (index node) table. (Each inode points to data blocks)
    - Dentries (translate between names and inode numbers, and maintain relationships between directories and files).
    - Data storage blocks (actual contents of files and directories).
    Diagram from Simone Demblon and Sebastian Spitzner's "Linux Internals - Filesystems"
    M. Tim Jones' "Anatomy of the Linux file system"
    Kernel.org's "ext4 Data Structures and Algorithms - High Level Design - Special inodes"

  3. Plaintext or individually encrypted files: e.g. normal files and directories; app-encrypted files such as password manager databases or encrypted SQL databases.

  4. Filesystem mounted instances: mount-point name, and type, and device name.
    E.g. "/" is the mount location of an ext4 filesystem stored on /dev/sda5.
    Run "df -h" to see the mounted filesystems.




  5. [I'm told layers 5 through 9 really can be mixed in any order, you can stack any block device on top of any other.]

  6. Upper filesystem formats: Veracrypt containers; eCryptfs; Windows' Encrypting File System (EFS).

    Wikipedia's "ECryptfs"
    Wikipedia's "Encrypting File System" (EFS)
    Wikipedia's "VeraCrypt"

  7. Base filesystem formats: format of data stored inside a partition. E.g. ext4, fat32, NTFS, btrfs, ZFS.
    Jim Salter's "Understanding Linux filesystems: ext4 and beyond"

  8. Manager: e.g. Linux's LVM (Logical Volume Manager), or some forms of RAID, or ZFS, or btrfs.

    Presents a "virtual partition" that the layer above can use, but that single "virtual partition" could be stored across multiple physical partitions and devices.

    Ubuntu Wiki's "LVM"
    Wikipedia's "Logical volume management"
    Wikipedia's "Logical Volume Manager (Linux)"
    Sarath Pillai's "The Advanced Guide to LVM"

  9. Device-mapper and full-volume/block-level encryption: e.g. dm-crypt (a LUKS-compliant implementation); Veracrypt "full-disk" (really, full-partition) encryption; BitLocker.

    Wikipedia's "dm-crypt"
    Wikipedia's "Linux Unified Key Setup" (LUKS)
    Wikipedia's "VeraCrypt"
    Wikipedia's "BitLocker"

  10. Physical partitions: e.g. /dev/sda5, /dev/sdb1. And a partition table (Master Boot Record (MBR) or GUID Partition Table (GPT)) to list the partitions.

    From someone on StackExchange:
    "Volume implies formatting and partition does not. A partition is just any continuous set of storage sectors listed in some table (e.g. MBR/GPT). A volume is a set of sectors belonging to the same filesystem, i.e. an implemented filesystem.".




  11. Disk hardware striping/mirroring (if any). E.g. some forms of RAID.
    Wikipedia's "RAID"

  12. Intermediate/bridge physical interfaces to media: e.g. USB, SCSI, RAID controller.
    Try doing "cat /proc/scsi/scsi" and "lsusb".

  13. Physical interfaces to media: e.g. IDE, SCSI, SATA.
    Wikipedia's "Hard disk drive interface"

  14. Disk controller, including hardware encryption (if any).

  15. Raw media: e.g. spinning hard disk, SSD, flash drive, CD-ROM, DVD-ROM, floppy disk.
    Appears as e.g. /dev/sda, /dev/sdb.
    Use GParted View/DeviceInformation to see info.




Example 1, my Linux Mint 19.2 system:
$ df -hT
Filesystem             Type      Size  Used Avail Use% Mounted on
/dev/sda5              ext4       33G   25G  7.0G  78% /
/dev/sda6              ext4      259G  182G   65G  74% /home
/dev/sda1              ext4      945M  175M  705M  20% /boot
/home/user1/.Private   ecryptfs  259G  182G   65G  74% /home/user1
  1. Standard Linux organization, except my personal files under /home.
  2. Standard Linux filesystem API.
  3. My password manager database file "KeePassDatabase.kdbx" is app-encrypted.
  4. It is under "/home/user1", which is the mount location of an eCryptfs filesystem stored on "/home/user1/.Private".
  5. "/home/user1/.Private" is using upper filesystem format eCryptfs.
  6. The base filesystem format of "/home" is ext4.
  7. Manager: none; not using LVM or RAID.
  8. Device-mapper and full-volume/block-level encryption: none ?
  9. Physical partitions: /home is on /dev/sda6.
    Partition table on /dev/sda is a Master Boot Record (MBR) table.
  10. Disk hardware striping/mirroring: none.
  11. Intermediate/bridge physical interfaces to media: SCSI.
  12. Physical interface to media: SATAII / Serial-ATA/300.
  13. Disk controller: whatever is on the circuit board attached to the disk (probably mainly some FPGA chip); no hardware encryption.
  14. Raw media: Western Digital model "ATA WDC WD3200BEVT-7" spinning hard disk, 298 GiB (320 GB), 5400 RPM 2.5" diameter, appears as /dev/sda.

Example 2, a Veracrypt container mounted in my Linux Mint 19.2 system:
$ df -ahT
Filesystem             Type             Size  Used Avail Use% Mounted on
/dev/sda6              ext4      259G  182G   65G  74% /home
/home/user1/.Private   ecryptfs  259G  182G   65G  74% /home/user1
/dev/mapper/veracrypt1 ext4             2.0G  1.1G  750M  60% /media/veracrypt1
  1. Standard Linux organization, except my personal files under /home.
  2. Standard Linux filesystem API.
  3. Plaintext file "MyBankInfo.txt" is in a 2.0GB Veracrypt container on /home/user1.
  4. It is under "/media/veracrypt1", which is the mount location of an ext4 filesystem stored on "/dev/mapper/veracrypt1".
  5. "/dev/mapper/veracrypt1" is using upper filesystem format ???.
    Both Veracrypt and ECryptfs are in here somewhere.
  6. The base filesystem format of "/dev/mapper/veracrypt1" is ext4 ?
  7. Manager: none; not using LVM or RAID.
  8. Device-mapper and full-volume/block-level encryption: none ?
  9. Physical partitions: /home is on /dev/sda6.
    Partition table on /dev/sda is a Master Boot Record (MBR) table.
  10. Disk hardware striping/mirroring: none.
  11. Intermediate/bridge physical interfaces to media: SCSI.
  12. Physical interface to media: SATAII / Serial-ATA/300.
  13. Disk controller: whatever is on the circuit board attached to the disk (probably mainly some FPGA chip); no hardware encryption.
  14. Raw media: Western Digital model "ATA WDC WD3200BEVT-7" spinning hard disk, 298 GiB (320 GB), 5400 RPM 2.5" diameter, appears as /dev/sda.



From someone on reddit:

My view on it is that there are no layers. There are just different combinations, abstractions, attachments, slices and mirrors of block devices. Upon which you can either build other block devices, or store raw data which could include filesystems.

...

The root of it is that the Linux block device is the base unit and since the other entities present block devices as their product, it gets confusing since the system is making block devices from other block devices and parts of block devices.

...

The first two items in #5 [Veracrypt containers; eCryptfs] are special types of filesystems, but the 3rd thing [Windows' Encrypting File System (EFS)] is referring to something that becomes a block device. Once it is a block device, then it can be used wherever a block device is used.

#6 is talking about filesystems and "partitions". But it's only a partition if it is referred to in a partition table (GPT, MBR, Sun, SGI, BSD). And even then, the OS only sees that data through the lens of a block device. See "man fdisk".

Trying to represent this as layers breaks pretty fast. For example with LVM, the LV is in a VG. And a VG encompasses one more more PVs. An LV can be spread across multiple PVs.

As I say, in the end actual data is on storage that shows up in Linux as a block device. http://www.haifux.org/lectures/86-sil/kernel-modules-drivers/node10.html

> [me trying to defend layers:]
> For example, can a Veracrypt container be below (contain) a LVM
> volume ? I don't think so, but maybe I'm wrong.

In Linux, Veracrypt can encrypt a file. That file can contain general data, a filesystem, or a partition table that divides up the file into partitions.

Also as a file, you can attach it to a loop device and then you can use that as an LVM PV (physical Volume) -- the first bullet here: https://www.veracrypt.fr/en/Home.html






Search my site: