在 Windows 中，每个驱动器都有一个字母，文件路径以驱动器号开头。所以我的主目录在里面C:\Users。
在 Linux 中，操作系统安装在主分区中，也就是/dev/sda1在根目录内。那么/home在里面吗/dev/sda1？
另外，root 必须位于 sda1 内，这是安装操作系统的驱动器，它是一个循环，那么它如何工作呢？
答案1
我提供这个与问题相称的简单答案，希望 OP 能够理解。其他答案都很好，但有点复杂。
首先，存在一些术语冲突。
您的系统有一个“根分区”，用于存储操作系统文件。/但是，该分区/实际上并不存在。系统关闭时，它实际上并不“存在”。启动时，它/从虚无中诞生。
/是用于 Linux 系统可以寻址的存储层次结构中最基本的级别的抽象。安装在该系统上的所有存储都将安装到某个位置/。
因此，当系统启动时，它会建立/安装存储的想法。它安装的最重要的存储是存储操作系统的卷，通常称为“根分区”，我相信这是您感到困惑的根源。“根分区”安装在，/所以这个名字从正常角度来看是有意义的，但会使像您这样的问题变得尴尬。这也是为什么没有您所说的“循环”。根分区只包含应该安装的文件/，而不是/它本身。
概念化差异的一种方法是，假设我取出包含 Ubuntu 笔记本电脑“根分区”的驱动器，并将其安装在我的 Debian PC 上，以便修复数据损坏问题。我选择将其安装到/mnt/laptop-drive/。分区/在我的笔记本电脑上并不意味着它/在我的 PC 上。我的 PC 上已经有了，/并且上面有 Debian。因此，“根分区”只是一个像其他分区一样的分区。如果它“包含”，/那么我就无法将其安装到另一个系统上的任意路径，但它只包含“应该在/”中的文件。发现区别了吗？
部分混淆来自与 Windows 的比较。Windows 将每个安装的驱动器显示为独立的东西。试着这样想：它不是拥有一组独立的安装磁盘，而是更像 c 和 d 以及安装到操作系统的其他驱动器，因此它\更像\c:\、\d:\、... ，\n:\因此它的工作方式与 Linux 相同。存储层次结构中有一个最基本的级别，其中包含由操作系统安装的磁盘。
希望有所帮助。
答案2
linux 文件系统中的根目录到底在哪里？
在典型的 Linux 安装中，计算机具有存储设备（例如硬盘驱动器或固态驱动器），根文件系统将驻留在该存储设备的分区上。
Linux 系统的整个目录树可以位于单个分区上。
可选地，一些目录可以位于单独的分区上。在这种情况下，首先安装根文件系统，然后将这些分区安装在其上。
例如，特定的 Linux 安装可能要求/home目录位于单独的分区上。在这种情况下，存储设备可以设置为包含两个分区，Linux 内核可以将其识别为/dev/sda1和/dev/sda2。在启动过程中，/dev/sda1将被挂载为/，然后/dev/sda2将 挂载为/home。
目录的分区/home可以位于单独的存储设备上，比如说位于附加硬盘的第二个分区上 - /dev/sdb2。
在更复杂的 Linux 安装中，根目录可以完全存在于 RAM 中。例如，根目录可以打包到壁球映像，它是在启动过程中从远程网络位置复制并以只读模式安装为/。
或者，SquashFS 映像可以驻留在 USB 驱动器上并/从那里挂载。在这种情况下，根文件系统存在于所述 USB 驱动器上。
根文件系统可以作为网络文件系统mount，在这种情况下文件系统存在于单独的机器上，并且 Linux 内核在启动过程中将其挂载。
执行不带参数的命令mount应列出所有当前挂载的文件系统。此外，此列表存在于文件中/proc/mounts。在条目中应该有一个用于根文件系统的条目 -/其挂载点为，例如：
/dev/sda3 on / type ext4 (rw,relatime)
通过这种方式，我们就可以看到这个特定系统的根文件系统在哪里。
编辑：
另外，root 必须位于 sda1 内，这是安装操作系统的驱动器，它是一个循环，那么它如何工作呢？
如果我们假设操作系统根文件系统位于/dev/sda1分区上，那么条目sda1位于目录中这一事实/dev并不会创建先有鸡还是先有蛋的依赖关系。
目录中的所有条目都不/dev是常规文件，也不存储在存储设备上，而只是简单地列在那里。此目录用作 Linux 系统为各种设备提供条目的位置，以便在其他上下文中使用时可以引用它们。
在 Windows 世界中，对这个“循环”问题的一个粗略类比是思考：“为什么驱动器C:\在设备管理器中列出，而设备管理器本身却必须从驱动器加载C:\？”这是一个非常粗略的类比，但它应该表明，设备管理器是 Windows 系统中显示设备的地方。在这个比较的背景下，可以说（非常不精确的术语）/devLinux 系统中的目录是 Windows 中设备管理器的对应物。
答案3
欢迎来到系统启动101。
UEFI bios 查看固件变量，发现它显示“运行 WDC100037/EFI/debian/grubx64.efi”，其中 WDC100037 是您的硬盘序列号。grubx64.efi然后从同一目录读取 grub.cfg，告诉它如何找到/boot。在大多数情况下，这将是一个 fs UUID；因此它只检查所有硬盘上的所有分区，以查看哪个分区包含 /boot 以及从该文件系统的根目录（每个文件系统都有一个根目录）到的路径，然后grub.cfg将其读入。
grub.cfg这是“用这个 initramfs 和这个命令行加载这个内核”并跳转到它的荒谬的过度设计方式。在几乎所有情况下，内核都位于 /boot 下，并且从那里读取。内核头有用于设备主编号和次编号的空闲插槽。grub 可以并且会使用这些；但是大多数时候它宁愿做其他事情。
最常见的方式是 initramfs 包含 udev 和 mount_root。内核启动时会突然创建一个新的 ramdrive，并将 initramfs 解压到其中（逻辑上等同于 gunzip | cpio -i）。然后/init执行，启动 udev 并解析内核命令行以查找root=，等待该设备创建，然后将其挂载到 /root 上，最后执行exec chroot /root /sbin/init。
如果没有 initrd，内核会尝试自行解析其命令行并识别 root= 参数。如果参数足够简单，它就会挂载该设备。这里的解析模式非常简单。它识别 /dev/sd[af][1-16] 之类的东西，并将它们转换为主编号和次编号，然后挂载它。此转换可能与 /dev 中的内容不一致；内核无法检查。如果失败，它只会查看其标头中的主编号和次编号，然后挂载它。如果该编号仍为 0 或挂载失败，它会崩溃。
如果您使用十六进制编辑器查看磁盘设备上的 /dev/sda 条目，您会发现它占用了零字节。它是一个块设备节点，rdev 字段告诉内核是哪一个。在大多数系统上，/dev 是某种 ramdisk；但是物理 /dev 是可能的。我曾经将它填充在我的 / 上，直到由于动态设备检测而变得太不稳定。
设备节点的概念至关重要。事实上，它是如此重要，甚至连 Windows 都拥有它。 \.\PHYSICALDRIVE0 是您的硬盘。不，您不能说 \.\PHYSICALDRIVE0\C:\Users 之类的东西；这不是它的工作原理。设备节点是作为单个文件而不是作为已安装文件系统的磁盘设备。Windows 可以在路径上安装文件系统；只是很少这样做，您不习惯看到它。
答案4
在 Linux 中，/dev 文件夹包含分区和整个磁盘的“文件”：
- sda - 这是第一个整个磁盘的文件
- sda1-这是磁盘上标有“sda”的一个分区
- sdb-这是第二个完整磁盘
这些不是真正的文件，但读取它们可以让您从头到尾读取原始磁盘。这就是为什么这些设备文件也可用于克隆原始磁盘。
Windows 也有这个但它是隐藏的。
- \Device\HarddiskVolume1 - 这是 Windows 中的设备分区。
这些还允许您读取原始磁盘，但不能从命令行读取，您需要实际的编程语言才能访问这些设备。
操作系统的作用：操作系统将这些设备挂载到特定位置。默认的启动分区挂载位置：
- 视窗：
C:\ - Linux、MacOS、Android 和 iOS：
\ - MacOS 还有：\Volumes\VolumeName
其他分区可以选择安装在自定义位置：
- Windows：C:\SomeNTFSMountPoint
- Linux：\mnt\CustomMountPoint
- MacOS：\Volumes\CustomMountPoint
您的问题的答案：
/home 在 /dev/sda1 里面吗？
是的，/home 位于 /dev/sda1 内，但并非您通常可以在文件资源管理器中查看的文件或文件夹的形式。/dev/sda1 内的 /home 是 /home 最原始的形式，即二进制。构成 /home 的 1 和 0（在主文件表中）存储在 sda1 中。
如果根目录位于 /dev/sda1 内部，那么 /dev/sda1 又怎么可能位于根目录内部呢？
乍一看这似乎很奇怪，但其实是有道理的。Linux 有假文件。这些文件实际上并不存在，但它们看起来像文件，以便于从终端访问它们，这在 Linux 中非常常见。这意味着它/dev/sda1被挂载到/，但创建了一个指向原始分区的“快捷方式”，/dev/因此看起来分区在其内部，但事实并非如此，因为 sda1 不是文件，它是一个假装是文件的假快捷方式。对这个假文件执行的读写操作将转发到您的原始分区。