linux – 内核在哪里定义SD卡命名索引?

我正在运行一个从SDCard启动的嵌入式主板. rootfs的位置通过内核参数传递给内核:

Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10

我注意到更改为不同的内核版本会将索引更改为mmcblk1,从而导致设备无法启动.

内核是在没有initramfs的情况下构建的.

两个版本的udevadm输出:

mmcblk1

$udevadm info --name=/dev/mmcblk1 --attribute-walk
  looking at device '/devices/platform/soc/1c0f000.mmc/mmc_host/mmc1/mmc1:0001/block/mmcblk1':
    KERNEL=="mmcblk1"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{alignment_offset}=="0"
    ATTR{capability}=="50"
    ATTR{discard_alignment}=="0"
    ATTR{ext_range}=="256"
    ATTR{force_ro}=="0"
    ATTR{inflight}=="       0        0"
    ATTR{range}=="8"
    ATTR{removable}=="0"
    ATTR{ro}=="0"
    ATTR{size}=="7716864"
    ATTR{stat}=="    2203     1698   122077    22625      654      554    26088     8770        0    12855    31530"

  looking at parent device '/devices/platform/soc/1c0f000.mmc/mmc_host/mmc1/mmc1:0001':
    KERNELS=="mmc1:0001"
    SUBSYSTEMS=="mmc"
    DRIVERS=="mmcblk"
    ATTRS{cid}=="9f544930303030300000000201011a3b"
    ATTRS{csd}=="400e00325b5900001d6f7f800a4000a1"
    ATTRS{date}=="10/2017"
    ATTRS{dsr}=="0x404"
    ATTRS{erase_size}=="512"
    ATTRS{fwrev}=="0x0"
    ATTRS{hwrev}=="0x0"
    ATTRS{manfid}=="0x00009f"
    ATTRS{name}=="00000"
    ATTRS{ocr}=="00200000"
    ATTRS{oemid}=="0x5449"
    ATTRS{preferred_erase_size}=="4194304"
    ATTRS{scr}=="02b5800000000000"
    ATTRS{serial}=="0x00000201"
    ATTRS{ssr}=="000000000200000004049000080a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
    ATTRS{type}=="SD"

  looking at parent device '/devices/platform/soc/1c0f000.mmc/mmc_host/mmc1':
    KERNELS=="mmc1"
    SUBSYSTEMS=="mmc_host"
    DRIVERS==""

mmcblk0

~# udevadm info --name=/dev/mmcblk0 --attribute-walk
  looking at device '/devices/platform/soc/1c0f000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0':
    KERNEL=="mmcblk0"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{alignment_offset}=="0"
    ATTR{capability}=="50"
    ATTR{discard_alignment}=="0"
    ATTR{ext_range}=="256"
    ATTR{force_ro}=="0"
    ATTR{inflight}=="       0        0"
    ATTR{range}=="8"
    ATTR{removable}=="0"
    ATTR{ro}=="0"
    ATTR{size}=="7716864"
    ATTR{stat}=="    2156     1248   105313    35020       85      263      952     1530        0     8180    36530"

  looking at parent device '/devices/platform/soc/1c0f000.mmc/mmc_host/mmc0/mmc0:0001':
    KERNELS=="mmc0:0001"
    SUBSYSTEMS=="mmc"
    DRIVERS=="mmcblk"
    ATTRS{cid}=="9f5449303030303000000003ba011a5d"
    ATTRS{csd}=="400e00325b5900001d6f7f800a4000a1"
    ATTRS{date}=="10/2017"
    ATTRS{dsr}=="0x404"
    ATTRS{erase_size}=="512"
    ATTRS{fwrev}=="0x0"
    ATTRS{hwrev}=="0x0"
    ATTRS{manfid}=="0x00009f"
    ATTRS{name}=="00000"
    ATTRS{ocr}=="00200000"
    ATTRS{oemid}=="0x5449"
    ATTRS{preferred_erase_size}=="4194304"
    ATTRS{scr}=="02b5800000000000"
    ATTRS{serial}=="0x000003ba"
    ATTRS{ssr}=="000000000200000004049000080a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
    ATTRS{type}=="SD"

  looking at parent device '/devices/platform/soc/1c0f000.mmc/mmc_host/mmc0':
    KERNELS=="mmc0"
    SUBSYSTEMS=="mmc_host"
    DRIVERS==""

~# udevadm info --query=property --name=/dev/mmcblk0
    DEVLINKS=/dev/disk/by-id/mmc-00000_0x000003ba /dev/disk/by-path/platform-1c0f000.mmc
    DEVNAME=/dev/mmcblk0
    DEVPATH=/devices/platform/soc/1c0f000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0
    DEVTYPE=disk
    ID_NAME=00000
    ID_PART_TABLE_TYPE=dos
    ID_PART_TABLE_UUID=27e953fe
    ID_PATH=platform-1c0f000.mmc
    ID_PATH_TAG=platform-1c0f000_mmc
    ID_SERIAL=0x000003ba
    MAJOR=179
    MINOR=0
    SUBSYSTEM=block
    TAGS=:systemd:
    USEC_INITIALIZED=4723799

看看/ etc / udev我发现没有明确的规则来解决mmcblk的命名问题.

# tree /etc/udev
/etc/udev
├── hwdb.bin
├── hwdb.d
├── rules.d
└── udev.conf

命名似乎与设备树有关.使用相同的zImage更改不同的设备树会产生不同的索引.

什么负责设置索引,是否有配置将其设置为不同的起始索引?

解决方法:

This似乎是负责理解root = / dev / mmcblk0p2的内核代码.

鉴于不存在initramfs,没有运行udev守护程序来命名设备,并且/ dev / mmcblk1在任何地方都不存在.

然后内核以某种方式将该名称转换为负责的驱动程序,函数dev_t name_to_dev_t(const char * name):

    ...
    if (strncmp(name, "/dev/", 5) != 0) {
        unsigned maj, min, offset;
        char dummy;

        if ((sscanf(name, "%u:%u%c", &maj, &min, &dummy) == 2) ||
            (sscanf(name, "%u:%u:%u:%c", &maj, &min, &offset, &dummy) == 3)) {
            res = MKDEV(maj, min);
            if (maj != MAJOR(res) || min != MINOR(res))
                goto fail;
        } else {
            res = new_decode_dev(simple_strtoul(name, &p, 16));
            if (*p)
                goto fail;
        }
        goto done;
    }

来自lkml discussion的引用指出,命名的变化可能是由设备树中的排序引起的:

Changes in device ordering can be provoked by the order in which
entries in the DT file appear, and hence the order in which the host
SD interfaces are probed by the kernel.

原文地址:https://codeday.me/bug/20190814/1654571.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


LinuxSystemd服务(2021.07.09)目录LinuxSystemd服务(2021.07.09)一、概述二、配置文件2.1Unit2.2Service2.3Install三、开机启动四、启动服务五、查看状态六、停止服务七、重启服务一、概述本文将介绍通过systemd来实现服务的自启动。systemd是一套系统启动和管理的工具,字
opidrvabortingprocessM002ospid(3561)asaresultofORA-600ORA-27300:操作系统相关操作:semctl失败,状态为:22ORA-27301:操作系统故障消息:InvalidargumentORA-27302:错误发生在:sskgpwrm1ORA-27157:已删除了操作系统发送/等待功能ORA-27300:操作系统相关操作
安装好haproxy后,配置正确无法启动,看日志:Feb1309:32:50cluster-node2systemd:StartedHAProxyLoadBalancer.Feb1309:32:50cluster-node2haproxy-systemd-wrapper:[ALERT]043/093250(6538):Startingproxymysql-pxc-cluster:cannotbindsocket[192.168.22.3
Linux 系统与服务管理工具Systemd被曝存在3大漏洞,影响几乎所有Linux发行版。Systemd是Linux系统的基本构建块,它提供了对系统和服务的管理功能,以PID1运行并启动系统的其它部分。目前大部分Linux发行版都以Systemd取代了原有的SystemV。安全公司Qualys近日发
一、systemd查看日志文件有隐藏 systemctlstatusSERVICE-l-l选项显示完整选项 journalctl-uSERVICE使用journalct命令查看 二、写一个systemd的配置文件,让nginx服务可以开机启动[Unit]Description=nginx[Service]Type=forkingPIDFile=/varunginx.pidExec
不要在mp目录下保存文件,该目录会定期清理文件mp默认保存10天/varmp默认保存30天配置文件:/usr/libmpfiles.dmp.conf默认配置文件:#Thisfileispartofsystemd.##systemdisfreesoftware;youcanredistributeitand/ormodifyit#underthetermsofthe
Step1:查看系统默认运行级别[root@node-1html]#systemctlget-default    //图形界面graphical.target[root@node-1html]#systemctllist-units--type=target  //查看支持的运行级别Step2:更改运行级别为level3 [root@node-1html]#systemctlset-defaultm
1.安装蓝牙驱动管理#apt-getinstallblueman2.打开蓝牙驱动管理,关闭设备3.关闭蓝牙开机启动服务#systemctldisablebluetooth.service#/lib/systemd/systemd-sysv-installdisablebluetooth4.重启reboot 
dhcpcd项目地址:http://www.linuxfromscratch.org/blfs/view/stable-systemd/basicnet/dhcpcd.html1.下载dhcpcd包并校验md5wgethttp:/oy.marples.name/downloads/dhcpcd/dhcpcd-7.0.7.tar.xzmd5sum-cmd5sums2.解压并进入包目录tar-xvfdhcpcd-7.0.7.tar.xzcddhcp
1.背景首先,我们先看一下/etc/init.d/README内容:Youarelookingforthetraditionalinitscriptsin/etcc.d/init.d,andtheyaregone?Here'sanexplanationonwhat'sgoingon:Youarerunningasystemd-basedOSwheretraditionalinitscriptshavebe
早就发现了,Arch的systemd提供的那个rc-local.service貌似有问题,rc.local不会执行。因为没用rc.local,一直没管。解决方法源自这里,需要稍加改动:http://superuser.com/questions/278396/systemd-does-not-run-etc-rc-local建立文件/etc/systemd/systemclocal.service(我怕和系
转载:https://www.cnblogs.com/sparkdev/p/8521812.html我们运行linux服务器的主要目的是通过运行程序提供服务,比如mysql、webserver等。因此管理linux服务器主要工作就是配置并管理上面运行的各种服务程序。在linux系统中服务程序的管理主要由init系统负责。如同笔者在
系统:Ubuntu18.04.02K8s版本:1.13.4故障现象:安装KubeDNS后,Pod内无法ping通外网域名,访问外网IP、K8s内部域名或者IP均正常  原因分析:查看Pod中的resolv.conf:kubectlexecbusybox--cat/etcesolv.confnameserver10.96.0.10searchdefault.svc.cluster.localsvc.cl
1.journalctl :日志查看工具journalctl -n5 //查看最近3条日志journalctl -perr //查看错误日志journalctl -overbose //查看日志的详细参数journalctl --since //查看从什么时间开始的日志journalctl --until //查看到什么时间为止的日志
此案例是以一个主,三个node来部署的,当然node可以根据自己情况部署192.168.1.130master192.168.1.131node1192.168.1.132node2192.168.1.133node3合法的EnableNTPonmasterandallnodes:[root@k-master~]#yum-yinstallntp[root@k-master~]#systemctlstartntpd[r
常用安装包下载yuminstall-yepel-releaseyum-yinstallbash-completionyum-yinstallnet-toolsyum-yinstalliprouteyum-yinstallwgetvimyum-yinstalllrzsznmaptreedos2unixnctelnetyum-yinstallopenssl一、系统类型1.1sysvinit1.系统第一个进程(p
修改了/etc/systemd/system.conf以后,发现不生效?修改了/etc/systemd/system.conf以后,必须使用systemctldaemon-reexec命令才能生效,使用systemctldaemon-reload是没有用的。daemon-reload重新加载的是所有单元文件,而不是systemd本身的配置。一定要注意了。被坑了。#addin/
Manjaro启动项目及服务配置备忘===============系统服务GUI管理搜索 systemdgenie 并安装,类似Windows的服务管理。================系统启动项目的快捷方式放在如下2个地方:/etc/xdg/autostart/cd~/.config/autostart,比如:/homeom/.config/autostart/===============#net
*1、systemd查看日志文件有隐藏该如何处理?答:Centos7.x使用systemd提供的journalctl日志管理a.基本上,系统由systemd所管理,那所有经由systemd启动的服务()如果在启动或结束的过程中发生了一些问题或是正常的信息),就会将该信息由systemd-journald.service以二进制的方式记录下来,之后
环境:centos7 创建的开机启动的链接地址: /etc/systemd/system/multi-user.target.wants/ 如:[root@tiaobanjisystem]#ll/etc/systemd/system/multi-user.target.wantsotal0lrwxrwxrwx.1rootroot38Feb2812:18auditd.service->/usr/lib/systemd/system/audit