《linux内核初始化和文件系统反删除》由会员分享，可在线阅读，更多相关《linux内核初始化和文件系统反删除（5页珍藏版）》请在金锄头文库上搜索。
1、Linux 内核初始化过程简要介绍全部引导过程是四步 1:boot PROM phase 2:boot Programs phase 3:kernel initialization phase 4:init phase system 初始化,检测内存和 cpu,检查设备和创建设备树, 设置 console kernel 初始化过程 kernel self -initialization 内核自检 loading of kernel modules 载入内核模块 reading of the kernel configuration file in /etc/system 读内核配置文件 sta
2、ring of the /sbin/init process 运行/sbin/init 进程 bootblk 是用于装载第二个引导程序 ufsboot 的主引导程序 bootblk 是被 PROM 的 boot 设备的引导扇区装载的 ufsboot 程序是用了装载两部分核心 genunix 和 unix 的 installboot 是用来在磁盘分区上安装 bootblk 的 genunix is the platform-independent generic kernel file ,while unix is the platform-specific kernel component.
3、整个的引导过程： PROM from the boot sector of the boot devicebookblkufsbootgenunix(是一个独立平台的普通内核文件) and unix(是一个特殊平台内核文件) 其它浅谈 Linux 文件系统反删除方法作为一个多用户、多任务的操作系统，Linux 下的文件一旦被删除，是难以恢复的。尽管删除命令只是在档节点中作删除标记，并不真正清除文件内容，但是其它用户和一些有写盘动作的进程会很快覆盖这些资料。不过，对于家庭单机使用的 Linux，或者误删档后及时补救，还是可以恢复的。1、Ext2 文件系统结构的简单介绍在 Linux 所用的 Ex
4、t2 文件系统中，文件是以块为单位存储的，默认情况下每个块的大小是 1K，不同的块以块号区分。每个档还有一个节点，节点中包含有档所有者，读写权限，文件类型等信息。对于一个小于 12 个块的档，在节点中直接存储档数据块的块号。如果档大于 12 个块，那么节点在 12 个块号之后存储一个间接块的块号，在这个间接块号所对应的块中，存储有 256 个档数据块的块号（Ext2fs 中每个块号占用 4 字节，这样一个块中所能存储的块号就是 1024/4=256）。如果有更大的档，那么还会在节点中出现二级间接块和三级间接块。2、恢复被误删档的方法 大多数 Linux 发行版都提供一个 debugfs 工具，
5、可以用来对 Ext2 文件系统进行编辑操作。不过在使用这个工具之前，还有一些工作要做。 首先以只读方式重新挂载被误删的档所在分区。使用如下命令：（假设文件在/usr 分区）mount ?Cr ?Cn ?Co remount /usr-r 表示只读方式挂载；-n 表示不写入/etc/mtab，如果是恢复/etc 上的档，就加上这个参数。如果系统说 xxx partion busy，可以用 fuser 命令查看一下是哪些进程使用这个分区上的?n：fuser ?Cv ?Cm /usr如果没有什么重要的进程，用以下命令停掉它们：fuser -k ?Cv ?Cm /usr 然后就可以重新挂载这些文件系统
6、了。 如果是把所有的档统一安装在一个大的/分区当中，可以在 boot 提示符下用 linux single 进入单用户模式，尽量减少系统进程向硬盘写入资料的机会，要不干脆把硬盘挂在别的机器上。另外，恢复出来的资料不要写到/上面，避免破坏那些有用的资料。如果机器上有 dos/windows，可以写到这些分区上面： mount ?Cr ?Cn /dev/hda1 /mnt/had然后就可以执行 debugfs：（假设 Linux 在 /dev/hda5）#debugfs /dev/hda5就会出现 debugfs 提示符 debugfs：使用 lsdel 命令可以列出很多被删除的文件的信息：deb
7、ugfs： lsdel debugfs: 2692 deleted inodes found. Inode Owner Mode Size Blocks Time deleted 164821 0 100600 8192 1/ 1 Sun May 13 19:22:46 2001 36137 0 100644 4 1/ 1 Tue Apr 24 10:11:15 2001 196829 0 100644 149500 38/ 38 Mon May 27 13:52:04 2001debugfs: 列出的档有很多（这里找到 2692 个），第一字段是档节点号，第二字段是档所有者，第三字段是读写权
8、限，接下来是档大小，占用块数，删除时间。然后就可以根据档大小和删除日期判断那些是我们需要的。比如我们要恢复节点是 196829 的文件： 可以先看看文件资料状态：debugfs： stat Inode: 196829 Type: regular Mode: 0644 Flags: 0x0 Version: 1 User: 0 Group: 0 Size: 149500 File ACL: 0 Directory ACL: 0 Links: 0 Blockcount: 38 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x31a9a574 - Mo
9、n May 27 13:52:04 2001 atime: 0x31a21dd1 - Tue May 21 20:47:29 2001 mtime: 0x313bf4d7 - Tue Mar 5 08:01:27 2001 dtime: 0x31a9a574 - Mon May 27 13:52:04 2001 BLOCKS: 594810 594811 594814 594815 594816 594817 . TOTAL: 38 然后就可以用 dump 指令恢复文件：debugfs： dump /mnt/hda/01.sav 这样就把档恢复出来了。退出 debugfs： debugfs：
10、quit另一种方法是手工编辑 inode：debugfs： mi Mode 0100644 User ID 0 Group ID 0 Size 149500 Creation time 0x31a9a574 Modification time 0x31a9a574 Access time 0x31a21dd1 Deletion time 0x31a9a574 0 Link count 0 1 Block count 38 File flags 0x0 Reserved1 0 File acl 0 Directory acl 0 Fragment address 0 Fragment number 0 Fragment size 0 Direct Block #0 594810 . Triple Indirect Block 0使用 mi 指令后每次显示一行信息以供编辑，其它行可以直接按回车表示确认，把deletion time 改成 0（未删除），Link count 改成 1。改好后退出 debugfs：debugfs： quit然后用 fsck 检查/dev/hda5fsck /dev/hda5程序会说找到丢失的数据块，放在 lost+found 里面。这个目录里的文件就是我们要的。
