解决Ubuntu虚拟机启动modprobe vboxdrv问题（不禁用安全启动)

  我用的是Ubuntu 16.04系统，想使用virtualbox创建虚拟机时，报错无法创建一个虚拟机任务，理由是"vboxdrv"未加载，尝试重新加载问题如下所示:

参考解决办法

  谷歌之后，根据链接网页描述，发现是在升级内核版本之后，从内核版本4.4.0-20开始，强制要求 unsigned 内核模块在启用安全启动的情况下运行。因此我们无法加载一个未签署的模块"vboxdrv"。

解决方式有两种，一种是禁用安全启动，这种方法简单，但不推荐使用，需要在引导菜单禁用secure-boot。

第二种方法是签署这些模块。

具体步骤如下：

创建签名秘钥:

签署模块

确认模块已签名

运行该命令之后显示"匹配到二进制文件"

最后，将密钥注册到安全启动

以上步骤完成后，重新启动并按照说明注册MOK（机器所有者密钥）。网上好多方法到这之后就没有了，理论上可以解决问题。

但我在这里遇到了问题，重启系统之后没有 带图示例 中显示的蓝屏界面，参考这篇文章 ubuntu系统UEFI SecureBoot ，我安装了shim-signed包。在安装完之后，需要输两次密码，该密码是注册MOK要使用的密码。

安装需要的包

使用以下命令将现有密钥注册到填充程序

虽然问题解决了，但是我不明白的是这个注册MOK是上面那条命令起作用了还是最后安装的包起作用了。有没有明白的大佬给我科普一下。

参考(侵删)：

https://wiki.ubuntu.com/UEFI/SecureBoot

https://sourceware.org/systemtap/wiki/SecureBoot

https://chubuntu.com/questions/726/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04-and-i-want-to-keep-secur.html

思路：按照字节读取文件到缓冲，然后对文件内容进行处理。

代码如下：

public static void readFile() throws IOException{

    RandomAccessFile f = new RandomAccessFile("test.txt", "r")

    byte[] b = new byte[(int)f.length()]

    //将文件按照字节方式读入到字节缓存中

    f.read(b)

    //将字节转换为utf-8 格式的字符串

    String input = new String(b, "utf-8")

    //可以匹配到所有的数字

    Pattern pattern = Pattern.compile("\\d+(\\.\\d+)?")

    Matcher match = pattern.matcher(input)

    while(match.find()) {

        //match.group(0)即为你想获取的数据

        System.out.println(match.group(0))

    }

    f.close()

}

当一个iOS应用程序崩溃时，系统会创建一份crash日志保存在设备上。这份crash日志记录着应用程序崩溃时的信息，通常包含着每个执行线程的栈调用信息（低内存闪退日志例外），对于开发人员定位问题很有帮助。

如果设备就在身边，可以连接设备，打开Xcode - Window - Organizer，在左侧面板中选择Device Logs（可以选择具体设备的Device Logs或者Library下所有设备的Device Logs），然后根据时间排序查看设备上的crash日志。这是开发、测试阶段最经常采用的方式。

如果应用程序已经提交到App Store发布，用户已经安装使用了，那么开发者可以通过iTunes Connect（Manage Your Applications - View Details - Crash Reports）获取用户的crash日志。不过这并不是100%有效的，而且大多数开发者并不依赖于此，因为这需要用户设备同意上传相关信息，详情可参见iOS: Providing Apple with diagnostics and usage information摘要。

考虑到并不是所有iPhone用户都允许自动发送诊断报告（crash日志），而且对于部分提交到Apple得crash日志，开发者还需要手动去拉取，然后找到对应的符号文件进行解析——这是一件很繁琐的事情。所以实际项目开发中，通常接入现有的crash收集工具（参考1，参考2），或者自己编写一个进行自动化收集、解析和统计汇总。

二、如何解析crash日志

当获得一份crash日志时，我们需要将初始展示的十六进制地址等原始信息映射为源代码级别的方法名称和代码行数，使其对开发人员可读。这个过程称为符号化解析。要成功地符号化解析一份crash日志，我们需要有对应的应用程序二进制文件以及符号（.dSYM）文件。

如果处于开发调试阶段，通常Xcode都能匹配到crash日志对应的二进制文件和符号文件，所以能够帮我们自动解析。

如果处于测试阶段，测试人员已经安装了不同的版本（比如alpha、beta版本），那么需要保存好对应版本的二进制文件和符号文件，以便在应用程序崩溃时对crash日志进行解析。对于这种场景下产生的crash日志，只需要将.crash文件、.app文件和.dSYM文件三者放在同一个目录下，然后将.crash文件拖放到Xcode - Window - Organizer中左侧面板Library下的Device Logs中，即可进行解析。

如果要提交发布，那么我们通常会先执行Clean，再Build，最后通过Product - Archive来打包。这样，Xcode会将二进制文件和符号文件归档在一起，可以通过Organizer中的Archives进行浏览。

这里是一份关于如何解析crash日志的讨论：http://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports 。

三、如何分析crash日志

在分析一份crash日志之前，如果开发人员对于常见的错误类型有所了解，那定是极好的。

crash日志的产生来源于两种问题：违反iOS策略被干掉，以及自身的代码bug。

---