From: Jan Engelhardt <jengelh-9+2X+4sQBs8@public.gmane.org>
To: initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: dracut: fails to copy udev rules to initramfs
Date: Sat, 9 Jan 2016 01:08:38 +0100 (CET) [thread overview]
Message-ID: <alpine.LSU.2.20.1601090036500.20214@nerf40.vanv.qr> (raw)
dracut 044 (and prior versions) only copy a handful of .rules files to
the initramfs, the exact list of which is in
/usr/lib/dracut/modules.d/95udev-rules/module-setup.sh. Copying only
half of the files leads to a problem with regard to object naming
in certain systems.
Suppose there is a deliberately-placed file
/etc/udev/rules.d/70-net.rules with:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="52:54:00:12:34:56", ATTR{type}=="1", KERNEL=="eth*",
NAME="ex7"
(52:.. substituted as appropriate per system)
In case of a Thinkpad system (happens to have dracut 037):
* the e1000e.ko module is not copied to the initramfs
* e1000e.ko gets loaded after switching to real root
* in the real root, 70-net.rules is available and processed.
=> ex7 name
In case of a QEMU system (with dracut 044):
* the virtio_net.ko module is copied to the initramfs
* virtio_net.ko gets loaded by initramfs udev
* no 70-net.rules inside initramfs, default net_id naming comes in.
=> ens3 name
Why is dracut copying virtio_net.ko? I have no idea, it does not tell by
default. Keeping in mind that there are also scenarios with root-on-NFS
and such, the presence of NIC modules inside initramfs has to be taken
into account, and with that, this leads me to lean in the direction that
dracut ought to copy all .rules files, in particular those from /etc.
Counterarguments?
next reply other threads:[~2016-01-09 0:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-09 0:08 Jan Engelhardt [this message]
[not found] ` <alpine.LSU.2.20.1601090036500.20214-Og55a6x16tXH9RFtKMg/Ng@public.gmane.org>
2016-01-11 10:11 ` dracut: fails to copy udev rules to initramfs Fabian Vogt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LSU.2.20.1601090036500.20214@nerf40.vanv.qr \
--to=jengelh-9+2x+4sqbs8@public.gmane.org \
--cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).