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.


You are receiving this mail because: