linux开机出现attempted to kill init

Posted 2023-05-15

用的pubby linux，开机就这样了，然后键盘上那两个灯一直闪，这个是用光盘启动的，不是安装到硬盘上的

可能你电脑的配置，如CPU的主频可能与这款LINUX的内核不相兼容。如果你的电脑配置比较低，建议还是选择装一下内核版本低的linux，一般的P4的CPU装个2.4.0版本是没问题的 参考技术A 内核引导参数的 root=XXX没设好
或者是没加载必须的initrd
总而言之,内核没有找的init程序 参考技术B 你可以上 http://cn.bing.com/查查

Android5.0上运行SQLite数据库出现attempt to write a readonly database的解决方案

场景

Jni下编译SQLite源码作为数据库，在测试手机：型号（Redmi Note 2) Android版本（5.0.2 LRX22G)系统下使用，尝试写数据库的时候，返回错误信息：attempt to write a readonly database

解决

在sqlite.c文件中查找

ino_t ino; /* Inode number */

修改为

unsigned long long ino; /* Inode number */

错误说明

Store inodes in unsigned long long

In 32 bit ABIs, ino_t is a 32 bit type, while the st_ino field

in struct stat is 64 bits wide in both 32 and 64 bit processes.

This means that struct stat can expose inode numbers that are

truncated when stored in an ino_t.

The SDCard fuse daemon (/system/bin/sdcard) uses raw pointer

values as inode numbers, so on 64 bit devices, we‘re very likely

to observe inodes that need > 32 bits to represent.

The fileHasMoved function in sqlite compares the stored

inode value with a new one from stat, and when the stored

value is truncated, this check will falsely indicate that

the file has been moved. When the fileHasMoved function

triggers, other functions start returning errors indicating

that the database is in read-only mode.

NOTE: Bionic differs from glibc in that struct stat‘s st_ino

is *always* 64 bits wide, and not the same width as ino_t.

参考

http://www.jianshu.com/p/30139ef31230

解决过程：

1 怀疑是读写权限的问题，但是其他文件也有读写，明显不成立，并且已经提供了读写的权限：

<uses-permission android:name="android.permission.INTERNET" />

2 怀疑是使用MTP模式共享机身存储到电脑，导致两边同时编辑，通过关闭MTP媒体共享，不成立

Redmi Note 2手机请勿关闭MTP媒体设备，否则需要恢复出厂设置才能够重新共享到电脑。

3 拷贝test.db和test.db-journal文件到Windows系统，并且使用SQLite控制台进行修改，没有任何的

问题。当前使用的是相同的SQLite源码编译的控制台程序。进行数据的插入过程中，会自动删除journal归档文件，并没有提示只读。另外单独拷贝test.db，直接操作，也没有任何的问题。

4 尝试关闭Java层对数据库的读写访问，只是允许NDK层直接操作数据库，防止多线程访问数据库，还是出现同样的结果，当然不知道是否是sqlite3_open与sqlite3_open_v2的接口是否会产生不同的结果，目前采用第一种方法访问数据库。

5 尝试获取Android系统中SQLite的版本，调用getVersion返回1，没有实质上的帮助。

6 是否是其他的Java层获取数据库的连接，没有关闭导致问题的出现？SQliteOpenHelper内部只缓存一个数据库的连接，在多线程的使用过程中，不要频繁的调用close，而应该保存一个唯一的一个访问实例，但是对于多进程之间的访问，也带来问题http://blog.sina.com.cn/s/blog_5de73d0b0102w0g0.html

7 虽然NDK无法修改数据，但是可以读取数据，而Java层却可以轻松的完成数据库的修改操作。

8 尝试调用beginTransaction和endTransaction对数据库的操作进行事务加锁还是没有任何的效果

9 怀疑是Android目录的读取问题，NDK层的SQLite读取数据库文件，发现有问题，但是没有办法找到journal归档文件，因此认为是只读，也是合理的

总结：

    经过上述种种的研究分析，得到如下的猜测：NDK层的SQLite实例在系统开机启动之后，会检查是否存在journal档案。如果是通过程序自动删除该journal档案。但是如果程序无法自动删除，目前怀疑就是因为版本之间的不对称，导致无法删除journal,SQLite数据库因此数据库变成只读的状态。

折中方案：

    NDK层只是负责只读数据，如果有任何的修改，都需要调用Java的接口进行修改数据，虽然有SQLite的源码，但是NDK层不好调试。