recovery

Android系统Recovery工作原理之使用update.zip升级过程分析（三）---Android系统的三种启动模式 以下的篇幅开始分析我们在上两个篇幅中生成的update.zip包在具体更新中所经过的过程，并根据源码分析每一部分的工作原理。 一、 系统更新update.zip包的两种方式 1. 通过上一个文档，我们知道了怎样制作一个update.zip升级包用于升级系统。Android在升级系统时获得update.zip包的方式有两种。一种是离线升级，即手动拷贝升级包到SD卡（或NAND）中，通过settings-->About phone-->System Update-->选择从SD卡升级。另一种是在线升级，即OTA Install(over the air)。用户通过在线下载升级包到本地，然后更新。这种方式下的update.zip包一般被下载到系统的/CACHE分区下。 2. 无论将升级包放在什么位置，在使用update.zip更新时都会重启并进入Recovery模式，然后启动recovery服务（/sbin/recovery）来安装我们的update.zip包。 3. 为此，我们必须了解Recovery模式的工作原理以及Android系统重启时怎样进入Recovery工作模式而不是其他模式（如正常模式）。 二、 Android系统中三种启动模式

问题说明 客户环境主库4节点RAC11.2.0.4，单实例DG环境，DG由于空间不足，导致同步中断，由于DG备库未应用的归档主库都再，本次恢复的方式，是开启dg mrp进程，自动同步追上主库。 以下遇到的问题，都在此过程中，遇到的报错。 一 dg环境遇到 ORA-00353 ORA-00334 如果主库还存在归档日志，则可以mv ,rm删除备库有问题的归档，让dg产生gap,主库会再次像备库传输归档日志另一种方法，就是如果主库无法自动像备库传输日志，可以从主库scp归档至备库dg，注册归档后，解决问题。 其次，本次通过主库，dg alert排除存在异常现象，也就是说再本次问题前，alert日志中并未出现日志块损坏现象！ORA-354 ORA-353 Corrupt Redo Log Block Header against online redolog using EMC/Cisco SANTap Service (Doc ID 779711.1)ORA-354 ORA-353 and ORA-312 on Redo Log Group members (Doc ID 332672.1) hu Nov 21 22:13:04 2019 Media Recovery Log /oradata/newora901dg/archivelog/NEWORA901DG/archivelog

关闭 OSX 10.11 SIP (System Integrity Protection) 功能 来源 https://cms.35g.tw/coding/%E9%97%9C%E9%96%89-osx-10-11-sip-system-integrity-protection-%E5%8A%9F%E8%83%BD/zh-hans/ Apple 从 10.9 开始导入kext需要签名认证后，在10.10全面启用此功能，每项置入/System/Library/Extersions/中的kext必需要经过签名认证系统才会启用此功能，然而在10.11时另外追加了System Integrity Protection (SIP)功能来保护系统档案及kext驱动避免被修改，即使是root权限也无法更改已经被系统设定的项目。 要了解被锁定的项目可以查询： cat /System/Library/Sandbox/rootless.conf 10.10只有少许的项目： /System * /System/Library/Caches booter /System/Library/CoreServices * /System/Library/Extensions /System/Library/Extensions/* UpdateSettings /System/Library

君子知夫不全不粹之不足以为美也， 故诵数以贯之， 思索以通之， 为其人以处之， 除其害者以持养之； 　　　　　　　　　　出自荀子《劝学篇》 终于OTA的升级过程的详解来了，之前的两篇文章 OTA升级详解（一） 与 OTA升级详解（二） 主要是铺垫， OTA升级的一些基础知识，那这边文章就开始揭开OTA-recovery模式升级过程的神秘面纱，需要说明的是 以下重点梳理了本人认为的关键、核心的流程，其他如ui部分、签名校验部分我并未花笔墨去描述，主要 还是讲 升级的核心， 其他都是枝枝叶叶。 Android 10 recovery 源码分析，代码来源路径： https://www.androidos.net.cn/android/10.0.0_r6/xref 本文所讲的流程代码路径为： bootable/recovery/ 首先从文件层面说下升级功能的调用流程，说明如下： recovery-main.cpp 升级的主入口 recovery.cpp 开始recovery升级的处理流程 install/install.cpp 执行升级的处理流程（调用updater） updater/updater.cpp 完成升级的核心流程 1 主入口代码为：recovery-main.cpp，main入口 1.1 日志相关的工作准备 1 // We don't have logcat yet

Ubuntu16.04 LTS用户忘记登录密码的解决办法 1.重启机器，进入GNU GRUB界面，高级选项进入(enter键)； 2.选择一个版本按e键进入recovery mode(注意不是enter键)； 3.进入可编辑(recovery mode)，删除"recovery nomodeset"，在行尾加"quiet splash rw init=/bin/bash"； 4.保存退出(F10,ctrl+x)后界面，命令行输入passwd+username进行用户密码重置，修改成功会提示"password updates successfully"； 来源： https://www.cnblogs.com/hechangchun/p/11857820.html

Ran out of diskspace and that screwed the elasticsearch shards. Three nodes are now in red, two got recovered and their state is yellow. ES is running 150% on CPU and high on memory, trying to recover them. But looks like there is some version match conflict. I cleared up the disk space and deleted the translog for a shard to stop loading from translog. But surprisingly the translog gets created again! Please share how can I stop this attempt to recover from translog and resume normal index operations. I do not want to delete the shard data. [2014-10-31 03:11:43,742][WARN ][cluster.action

The most common method for corrupting compressed files is to inadvertently do an ASCII-mode FTP transfer, which causes a many-to-one trashing of CR and/or LF characters. Obviously, there is information loss, and the best way to fix this problem is to transfer again, in FTP binary mode. However, if the original is lost, and it's important, how recoverable is the data? [Actually, I already know what I think is the best answer (it's very difficult but sometimes possible - I'll post more later), and the common non-answers (lots of off-the-shelf programs for repairing CRCs without repairing data),