Не существует простого метода . Но это выполнимо для файлов, которые являются частью RPM :
.
rpm -qf
для данного имени файла идентифицирует пакет rpm -qi
для данного пакета немного говорит о том, откуда взялась программа. Если это не в RPM, трудно найти источник, если вы не знаете, как файл туда попал. Для пакетов, отличных от -CentOS, упаковщик может идентифицировать исходное местоположение, возможно не .
Например, ваш примерhostname
может быть предоставлен coreutils , но RPM говорит, что это не:
$ rpm -qi `rpm -qf /usr/bin/hostname`
Name : hostname
Version : 3.13
Release : 3.el7
Architecture: x86_64
Install Date: Fri Jul 4 13:23:13 2014
Group : System Environment/Base
Size : 19449
License : GPLv2+
Signature : RSA/SHA256, Thu Jul 3 21:54:35 2014, Key ID 24c6a8a7f4a80eb5
Source RPM : hostname-3.13-3.el7.src.rpm
Build Date : Mon Jun 9 17:48:44 2014
Build Host : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager : CentOS BuildSystem
Vendor : CentOS
URL : http://packages.qa.debian.org/h/hostname.html
Summary : Utility to set/show the host name or domain name
Description :
This package provides commands which can be used to display the system's
DNS name, and to display or set its hostname or NIS domain name.
Поскольку поставщиком является CentOS
, вы можете найти исходный код на сайте CentOS. Или вы можете перейти по указанному URL-адресу (, что может потребовать некоторой работы ). В этом случае Debian предлагает ссылку для просмотра исходного кода , поскольку Debian поддерживает программу. В тех случаях, когда это не так, чаще всего лучше всего найти смоляной -шар.
1.)/sys
не является реальной файловой системой -диска :это представление и средство доступа к внутреннему состоянию ядра в виде виртуальной файловой системы. Он полностью основан на оперативной памяти -, и нет смысла хранить содержимое /sys
на диске.
В определенном смысле можно сказать, что /sys
создается заново каждый раз при загрузке ядра и обнаружении оборудования; в другом смысле вы могли бы сказать, что вещи в файловой системе /sys
на самом деле вообще не существуют постоянно, а генерируются только по запросу, всякий раз, когда вы пытаетесь получить к ним доступ, на основе фактического состояния ядра, в котором они должны находиться. представлять.
Пока вы находитесь в процессе установки Gentoo, новая установка еще не имеет своего собственного работающего ядра, поэтому новая установка не может иметь своего отдельного ядра /sys
. Но среда установщика имеет свою собственную /sys
, и выполнение монтирования привязки заставляет «систему в стадии разработки» заимствовать дерево файловой системы /sys
среды установки. Это делает некоторые задачи при установке точно такими же, как и при обновлении существующей системы, и поэтому одни и те же сценарии могут использоваться для обоих случаев :при обновлении, они используются так же, как -, но во время установки они просто нужно запустить chroot в /mnt/gentoo
.
2. )В соответствии с /sys
может быть или не быть debugfs
смонтированным как /sys/kernel/debug
, efivarfs
хранилище переменных UEFI псевдо -файловая система как /sys/firmware/efi/efivars
,и, возможно, несколько файловых систем на базе RAM -для управления различными контрольными группами в /sys/fs/cgroup/*
.
Под /dev
могут быть по крайней мере /dev/pts
, /dev/shm
, /dev/hugepages
и/или /dev/mqueue
, все различные специальные -целевые ОЗУ -на основе файловых систем.
Таким образом, использование rbind явно упростит ситуацию.