Bug ID | 1153211 |
---|---|
Summary | (clarification) Weird interaction between chroot, libzypp and chroot |
Classification | openSUSE |
Product | openSUSE Tumbleweed |
Version | Current |
Hardware | Other |
OS | Other |
Status | NEW |
Severity | Normal |
Priority | P5 - None |
Component | libzypp |
Assignee | zypp-maintainers@suse.de |
Reporter | aplanas@suse.com |
QA Contact | qa-bugs@suse.de |
Found By | --- |
Blocker | --- |
While working on https://bugzilla.suse.com/show_bug.cgi?id=1153062 I discover a weird interaction between libzypp, chroot and dracut, that can be summarized in this case: * Wrong behavior # /mnt lives the partition where I want to install a new system zypper --root /mnt install -f kernel-default-base # There is a binary match in initrd grep -R iscsi /mnt/boot/initrd-* * Good behavior # /mnt lives the partition where I want to install a new system mount -t proc proc /mnt/proc zypper --root /mnt install -f kernel-default-base # There is NO binary match in initrd grep -R iscsi /mnt/boot/initrd-* Looks like that dracut is inspecting something in proc to decide what modules to include, and zypper do not mount proc inside the new root where external applications will be executed using chroot. This produces a broken initrd in the default case. I also noted that this also generate a more complete initrd. * Better behavior # /mnt lives the partition where I want to install a new system mount -t devtmpfs devtmpfs /mnt/dev mount -t proc proc /mnt/proc mount -t sysfs sysfs /mnt/sys zypper --root /mnt install -f kernel-default-base # There is NO binary match in initrd grep -R iscsi /mnt/boot/initrd-* I can see that for zypper can be tricky to have a naive chroot management, as maybe there is some missing binary in the bootstrapped chroot directory, but I would like to have a feedback about mounting devtmpfs, proc and sysfs before any external execution, as if this is not done some programs in the rpm scriptlets and in the postrans scripts will produce broken results.