解决redhat echo $http_proxy无法找到文件地址的方法及redhat虚拟机终端按键哒哒哒声音的问题探讨
问题1:当echo的时候查找~/.bashrc文件,发现脚本会继续寻找bashrc.d目录下的proxy文件并进行运行,也就是启动bash的时候就会运行那个proxy.sh文件,而proxy.sh文件可能是之前旧的代理地址,只要删除里面的内容就好了。
问题2:redhat虚拟机终端按键哒哒哒的问题主要是虚拟机的问题,并不是自己键盘的问题,可以在搜索关键词进行寻找解决方案
加载过慢请开启缓存 浏览器默认开启
问题1:当echo的时候查找~/.bashrc文件,发现脚本会继续寻找bashrc.d目录下的proxy文件并进行运行,也就是启动bash的时候就会运行那个proxy.sh文件,而proxy.sh文件可能是之前旧的代理地址,只要删除里面的内容就好了。
问题2:redhat虚拟机终端按键哒哒哒的问题主要是虚拟机的问题,并不是自己键盘的问题,可以在搜索关键词进行寻找解决方案
今天对podman进行了更深入地学习,包括podman对pod的创建,然后使用映像文件将容器创建在pod里
还有创建网络,对pod的网络进行指定(只在创建时还是有点不方便的)
了解到一个pod迁移方式:
将现有 Pod 导出为 Compose 风格 YAML
你可以用 podman generate kube 从已有 Pod 自动导出配置文件,方便迁移或复用:
podman pod create --name mypod
podman run -dt --pod mypod --name web nginx:alpine
podman run -dt --pod mypod --name sidecar busybox sh -c “while true; do echo hello; sleep 10; done”
podman generate kube mypod > pod-compose.yaml
然后你可以用 pod-compose.yaml 作为配置模板修改后再部署:
podman play kube pod-compose.yaml
基础设施容器:
在Podman中,Pod创建时会自动生成一个名为“infra”的基础设施容器(也称Pause容器),它的核心作用是初始化并维护Pod的网络命名空间,使Pod内所有容器能共享同一个网络环境、IP地址,从而实现它们之间通过localhost互相通信。这个轻量级且对用户隐藏的容器几乎不占用资源,但其生命周期与Pod绑定,确保即使Pod内没有其他容器运行,网络环境也能保持存活,直到Pod被删除时一同销毁。这种设计简化了网络管理,提高了资源利用率,并提升了可维护性,其理念与Kubernetes中的Pause容器类似,都是为了解决多容器共享网络的问题。
问题:
podman run -d --pod myapp-pod --name mysql 00a697b8380c 无法运行
解决过程:
podman logs <容器ID> 查看问题,发现错误信息:2025-07-02 12:53:55+00:00 [ERROR] [Entrypoint]: Database is uninitialized and password option is not specified
你需要通过环境变量指定以下之一:
- MYSQL_ROOT_PASSWORD
- MYSQL_ALLOW_EMPTY_PASSWORD
- MYSQL_RANDOM_ROOT_PASSWORD
MYSQL_ROOT_PASSWORD 重新运行容器:podman run -d --pod myapp-pod --name mysql -e MYSQL_ROOT_PASSWORD=root1573 00a697b8380c
如何使用红帽订阅管理器将 RHEL 系统注册并订阅到红帽客户门户网站?
subscription-manager register
Username: 时,输入您的红帽客户门户网站用户名。Password: 时,输入您的密码。subscription-manager refresh
问题原因:
Windows 作为客户端挂载了虚拟机的 NFS 服务,但未正常卸载,导致网络连接或挂载点残留。
解决方案:
使用 net use 命令强制删除残留的挂载点。
net use X: /delete
说明:
X:需替换为实际的挂载盘符。- 该命令会断开指定盘符的网络连接,并删除挂载点。
像之前那样添加syscall,和$U/_sysinfotest
kernel/syscall.h
#define SYS_sysinfo 23
kernel/syscall.c
extern uint64 sys_sysinfo(void);
[SYS_sysinfo] sys_sysinfo
kernel/sysproc.c
#include "sysinfo.h"
int sys_sysinfo(void) {
struct sysinfo info;
uint64 addr;
struct proc *p = myproc();
if (argaddr(0, &addr) < 0)
return -1;
info.freemem = kfreemem();
info.nproc = nproc();
if (copyout(p->pagetable, addr, (char *)&info, sizeof(info)) < 0)
return -1;
return 0;
}
kernel/kalloc.c
void *
kalloc(void)
{
struct run *r;
acquire(&kmem.lock);
r = kmem.freelist;
if(r)
kmem.freelist = r->next;
release(&kmem.lock);
if(r)
memset((char*)r, 5, PGSIZE); // fill with junk
return (void*)r;
}
uint64
kfreemem(void)
{
struct run *r;
uint64 pages=0;
acquire(&kmem.lock);
for(r=kmem.freelist;r;r=r->next)
pages++;
release(&kmem.lock);
return pages*PGSIZE;
}
kernel/proc.c
int
nproc(void)
{
int count=0;
struct proc* p;
acquire(&pid_lock);
acquire(&wait_lock);
for(p=proc;p<&proc[NPROC];p++)
{
if(p->state!=UNUSED){
count++;
}
}
release(&wait_lock);
release(&pid_lock);
return count;
}
然后输入sysinfotest
ready to load at 0x10a000 ccccccccccload fail 0xc35a69a6 readyWait SELoadr ACK overtime Wait connect success flag (hisilicon) overtime.OHOS_Image.bin 文件。文档中可能提到选择两个文件,但实际应选择一个整合好的文件,这可能是文档的疏漏。好的,我们来通过一个具体的用户程序调用 write 系统调用的例子,串联起用户空间(user)和内核空间(kernel)的交互过程。假设我们有一个简单的用户程序 write_hello.c,它想向标准输出(文件描述符 1)写入 “Hello, xv6!” 字符串。
// write_hello.c
#include "types.h"
#include "user.h"
#define MSG "Hello, xv6!\n"
#define MSG_LEN 10 // "Hello, xv6!\n" 的长度
int main(void) {
write(1, MSG, MSG_LEN); // 调用 write 系统调用
exit(); // 退出程序
}
让我们编译并运行它(在 QEMU 模拟的 xv6 环境中):
$ cc write_hello.c
$ ./write_hello
Hello, xv6!
$
现在,我们一步步追踪这个 write(1, MSG, MSG_LEN) 调用:
write 函数:
write_hello.c 中,main 函数调用了 write 函数。write_hello.c 包含了 user.h (#include "user.h"),它看到的 write 函数原型定义在 user.h 中,通常看起来像这样:// user.h
int write(int fd, char *buf, int n);
write 函数是一个用户空间的库函数(在 xv6 中,这些库函数通常非常简单,直接调用系统调用)。syscall:
user.c 文件中实现了 write 函数。它会检查参数(如 fd 是否有效,buf 是否指向用户空间地址等),然后调用一个通用的系统调用接口函数,通常是 syscall。user.c 中的 write 函数实现大致如下:// user.c
#include "user.h"
#include "syscall.h" // 包含系统调用号定义
int write(int fd, char *buf, int n) {
// 参数检查 (简化)
if (fd < 0 || n < 0) {
return -1;
}
// 调用通用的系统调用函数
return syscall(SYS_write, fd, (int)(uint64)buf, n); // 注意 buf 的类型转换
}
syscall 函数也是 user.c 中定义的,它的作用是准备系统调用所需的参数,并触发一个软件中断(在 RISC-V 上通常是 ecall 指令)来进入内核模式。ecall 指令:
syscall 函数会将要调用的系统调用号(SYS_write,定义在 syscall.h 中)和参数(fd, buf 的地址, n)放到特定的寄存器中(例如 RISC-V 的 a7 存放系统调用号,a0, a1, a2 存放参数)。syscall 函数执行 ecall 指令。这会触发一个异常(Trap),将 CPU 从用户模式切换到内核模式,并跳转到内核中预先设置好的异常处理入口点(通常是 trap 处理程序)。trap 处理程序:
trap 处理程序(通常在 kernel/trap.c 中)被 ecall 指令触发。trap 处理程序首先保存当前的处理器状态(如寄存器值),以便稍后恢复用户程序。ecall 是一种同步异常,trap 处理程序会检查 a7 寄存器中的值(系统调用号)。a7 的值是 SYS_write,trap 处理程序就知道这是一个 write 系统调用请求。sys_write 函数:
trap 处理程序会调用内核中实现 write 系统调用的具体函数,通常是 sys_write(定义在 kernel/sysfile.c 中)。trap 处理程序会将用户传递的参数(从 a0, a1, a2 寄存器获取)传递给 sys_write。sys_write 函数实现实际的写入逻辑:
fd 查找对应的打开文件结构(struct file)。buf 是否指向有效的用户空间地址(防止内核访问非法内存)。fd 对应的是标准输出(通常是控制台),它会调用控制台驱动相关的函数(如 consolewrite)。consolewrite 函数负责将 n 个字节从内核缓冲区(sys_write 会先将用户空间的 buf 内容复制到内核空间的一个临时缓冲区)写入到控制台设备。这通常涉及将字符发送到串口或 VGA 内存。sys_write 函数执行完毕后,会将结果(写入的字节数,或出错时的错误码 -1)存储在一个内核和用户程序都能访问的特定位置,通常是 a0 寄存器。trap 处理程序恢复之前保存的处理器状态。trap 处理程序执行 ret(或类似的指令)返回到用户程序中被 ecall 指令中断的位置。syscall 函数的下一条指令。syscall 函数从 a0 寄存器获取内核返回的结果,并将其作为 write 函数的返回值返回给 main 函数。main 函数收到 write 的返回值(通常是 MSG_LEN),然后执行 exit() 系统调用,请求内核终止该进程。write_hello.c (用户程序) -> user.h (函数声明) -> user.c (write 函数实现) -> syscall (通用系统调用接口) -> ecall (触发内核) -> trap (内核异常处理) -> sys_write (内核系统调用实现) -> consolewrite (设备驱动) -> 控制台输出 -> 返回结果 -> user.c (syscall 返回) -> user.c (write 返回) -> write_hello.c (main 继续执行)。这个过程清晰地展示了用户程序如何通过系统调用接口请求内核服务,以及内核如何处理这些请求并返回结果。user.c, user.h, syscall.c (如果存在,或其逻辑在 user.c 中) 构成了用户空间的桥梁,而 trap.c, sysfile.c, console.c 等构成了内核空间的处理逻辑。如果你因为删除了某些分区导致注册表混乱,然后无法正确指向,那么你可以看一下这个链接,在你尝试了多种方法后都没有成功,因为他确实指出了注册表问题并且提出了解决方法。请仔细查看他们的恢复。
(Unable to Start Windows Search Service – “Error 3: The System Cannot Find the Path Specified”)[https://answers.microsoft.com/en-us/windows/forum/all/unable-to-start-windows-search-service-error-3-the/dc734fdc-8f9f-4ae9-b873-ea864f3663fc?page=4]
wsl ubuntu 22.04
拉取源码时的命令:repo init -u git@gitee.com:openharmony/manifest.git -b master -g ohos:mini --no-repo-verify
bash build/prebuilts_download.sh 命令之后会出现一些什么pls check 我的理解就是mini系统不需要,至少我编译成功helloword的时候我没有去管,如果后面需要再去解决。
还有windows和linux联合的时候vscode远程链接之后vscode打不开那个deveco device tool
在使用全量的时候也出现了子系统名称不对,忘了解决没有反正后面还有问题就不管了
忘了忘了
当时的文档是v5.0.3 Release
还有如果提示格式错误就检查有没有格式错误,没有删掉那个.build文件
static_library(“my_first_app”) {
sources = [
“hello_world.c”
]
include_dirs = [
“//utils/native/lite/include”
]
}
{
"component": "hello_world_app",
"description": "hello world samples.",
"optional": "true",
"dirs": [
"applications/sample/wifi-iot/app/my_first_app"
],
"targets": [
"//applications/sample/wifi-iot/app/my_first_app:my_first_app"
],
"rom": "",
"ram": "",
"output": [],
"adapted_kernel": [ "liteos_m" ],
"features": [],
"deps": {
"components": [],
"third_party": []
}
}
这里我没配置也通过了,下面连接他们说上面那个communication也可以不写,但是我会出错好像是报json的格式错误?去看那个文件也是错误的,那个文件是生成的所以应该找源头
# Copyright © 2020-2022 Huawei Device Co., Ltd.
# Licensed under the Apache License, Version 2.0 (the “License”);
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an “AS IS” BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
import(“//build/lite/config/component/lite_component.gni”)
lite_component(“app”) {
features = [ “startup”,“my_first_app” ]
}
static_library(“my_first_app”) {
sources = [
“hello_world.c”
]
include_dirs = [
“//utils/native/lite/include”
]
}
这些在那个文档都是有配置规则的,不过是在后面,为了写hello world去看也不太可能
为了写hello world,先是获取源码,买了块移动硬盘发现是qlc就退了,想了想其实100多GB空间还是够的,就强行把五个分区合并成两个了(不是不知道危害,就是突然不想管了就想着前进,五个分区要正常解决要处理太多了,能卸载的卸载,一些文件或工具之类的就直接剪切,想着也没有空间去存那些先移出来的数据(写到这里触发了既视感),最后一些电脑组件损坏了,索引服务启动不了搜索界面出现一大块东西,注册表乱成一团,还好慢慢地恢复到能使用的情况了),然后去寻找减少空间的方法,发现可以只下载mini。按照教程来出现的问题也很多,就又下载small,后来又下载全量,还是很多问题,还有出现不同的问题,最后还是下载mini了,毕竟刚开始小总是好的,确定的东西总是能根据不同的状态出现不同的问题。还有挺多问题已经记不起来了,抱歉。
轻量编译没必要完全按照,太精细反而不太好
json格式验证
Ubuntu22.04 搭建 OpenHarmony 命令行开发环境
[OpenHarmony5.0][环境][教程]OpenHarmony 5.0源码在WSL2 Ubuntu22.04 编译环境搭建教程细
一键配置Ubuntu的OpenHarmony基础编译环境23年的
关于在Ubuntu中搭建DevEco Device Tool环境出现报错Unable to locate package python-venv
如何向OpenHarmony中编译构建自己的子系统、部件和模块
这里也很多链接找不到了