* absolute firmware path made relocatable in qemu 5.2.0
@ 2021-01-12 14:05 Dave
2021-01-12 14:48 ` Paolo Bonzini
0 siblings, 1 reply; 8+ messages in thread
From: Dave @ 2021-01-12 14:05 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
Hi,
Is seem that absolute firmwarepath compilation option is converted to
relocatable in 5.2.0 qemu.
# QEMU configure log Tue 12 Jan 14:46:41 GST 2021
# Configured with: '../configure' '--prefix=/usr'
'--sysconfdir=/etc/qemu' '--disable-bochs'
'*--firmwarepath=/usr/share/qemu:/usr/share/qemu-firmware*'
#
And trying to run the executable
bash-5.1# ./qemu-system-x86_64
qemu: could not load PC BIOS 'bios-256k.bin'
If i print out the resultant binary paths
bash-5.1# ./qemu-system-x86_64 -L help
/root/qemu/../share/qemu
/root/qemu/../share/qemu-firmware
So there is no way to have a absolute path for firmware /bios and all
qemu's that we test need to be at the right directory nesting to find
firmware, bios etc or else they all need their own duplicate firmware
files. Firmware path needs to honor the absolute paths i believe.
Comments ?
Dave
[-- Attachment #2: Type: text/html, Size: 1256 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: absolute firmware path made relocatable in qemu 5.2.0 2021-01-12 14:05 absolute firmware path made relocatable in qemu 5.2.0 Dave @ 2021-01-12 14:48 ` Paolo Bonzini 2021-01-12 16:46 ` Dave 0 siblings, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2021-01-12 14:48 UTC (permalink / raw) To: Dave, qemu-devel On 12/01/21 15:05, Dave wrote: > Is seem that absolute firmwarepath compilation option is converted to > relocatable in 5.2.0 qemu. > > # QEMU configure log Tue 12 Jan 14:46:41 GST 2021 > # Configured with: '../configure' '--prefix=/usr' > '--sysconfdir=/etc/qemu' '--disable-bochs' > '*--firmwarepath=/usr/share/qemu:/usr/share/qemu-firmware*' > # Yes, all paths within the prefix are relocated. The workaround is simply to configure the intended prefix with configure: ./configure --prefix=/root/qemu ... or if you don't know the prefix: ./configure --prefix=/nonexistent ... Because /usr/share/qemu and /usr/share/qemu-firmware are outside /usr, they will be treated as absolute just like /etc/qemu. Thanks, Paolo > And trying to run the executable > > bash-5.1# ./qemu-system-x86_64 > qemu: could not load PC BIOS 'bios-256k.bin' > > If i print out the resultant binary paths > > bash-5.1# ./qemu-system-x86_64 -L help > /root/qemu/../share/qemu > /root/qemu/../share/qemu-firmware > > So there is no way to have a absolute path for firmware /bios and all > qemu's that we test need to be at the right directory nesting to find > firmware, bios etc or else they all need their own duplicate firmware > files. Firmware path needs to honor the absolute paths i believe. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: absolute firmware path made relocatable in qemu 5.2.0 2021-01-12 14:48 ` Paolo Bonzini @ 2021-01-12 16:46 ` Dave 2021-01-12 16:53 ` Paolo Bonzini 0 siblings, 1 reply; 8+ messages in thread From: Dave @ 2021-01-12 16:46 UTC (permalink / raw) To: Paolo Bonzini, qemu-devel Hi Paolo, While this (option 2) partially works, it will still search for /nonexistent/libexec/qemu-bridge-helper for example so seems that some paths are still absolute and some relative. To explain, what we are expecting that we compile one binary with the relevant options, test that and then it goes into production. If we compile with --prefix=/usr (it's final resting place will be /usr/bin) then everything works as expected once it is in production (since /usr/share/qemu, /usr/libexec, /etc/qemu exists as expected). However when we are testing the binary in a directory /root/qemu/5.2.0 with --prefix=/usr it breaks since it converts the firmware and bios paths to /root/qemu/5.2.0/../share/qemu. This means we need to recompile twice with relevant prefixes since if i use --prefix=/nonexistent then we can't find the qemu-bridge-helper when the binary goes into production. It would be nicer with the relocatable binary took some fixed paths from /etc/qemu.conf for the bridge-helper, firmware, bios, qemu-ifup/down. thanks Dave On 12/01/2021 18:48, Paolo Bonzini wrote: > On 12/01/21 15:05, Dave wrote: >> Is seem that absolute firmwarepath compilation option is converted to >> relocatable in 5.2.0 qemu. >> >> # QEMU configure log Tue 12 Jan 14:46:41 GST 2021 >> # Configured with: '../configure' '--prefix=/usr' >> '--sysconfdir=/etc/qemu' '--disable-bochs' >> '*--firmwarepath=/usr/share/qemu:/usr/share/qemu-firmware*' >> # > > Yes, all paths within the prefix are relocated. The workaround is > simply to configure the intended prefix with configure: > > ./configure --prefix=/root/qemu ... > > or if you don't know the prefix: > > ./configure --prefix=/nonexistent ... > > Because /usr/share/qemu and /usr/share/qemu-firmware are outside /usr, > they will be treated as absolute just like /etc/qemu. > > Thanks, > > Paolo > >> And trying to run the executable >> >> bash-5.1# ./qemu-system-x86_64 >> qemu: could not load PC BIOS 'bios-256k.bin' >> >> If i print out the resultant binary paths >> >> bash-5.1# ./qemu-system-x86_64 -L help >> /root/qemu/../share/qemu >> /root/qemu/../share/qemu-firmware >> >> So there is no way to have a absolute path for firmware /bios and all >> qemu's that we test need to be at the right directory nesting to find >> firmware, bios etc or else they all need their own duplicate firmware >> files. Firmware path needs to honor the absolute paths i believe. >> > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: absolute firmware path made relocatable in qemu 5.2.0 2021-01-12 16:46 ` Dave @ 2021-01-12 16:53 ` Paolo Bonzini 2021-01-12 17:04 ` Dave 0 siblings, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2021-01-12 16:53 UTC (permalink / raw) To: Dave; +Cc: qemu-devel [-- Attachment #1: Type: text/plain, Size: 2717 bytes --] Il mar 12 gen 2021, 17:48 Dave <dave@0bits.com> ha scritto: > Hi Paolo, > > While this (option 2) partially works, it will still search for > /nonexistent/libexec/qemu-bridge-helper for example so seems that some > paths are still absolute and some relative. > Ok, that's a bug that can be fixed in 5.2.1. Are there other instances? > To explain, what we are expecting that we compile one binary with the > relevant options, test that and then it goes into production. If we > compile with --prefix=/usr (it's final resting place will be /usr/bin) > then everything works as expected once it is in production (since > /usr/share/qemu, /usr/libexec, /etc/qemu exists as expected). However > when we are testing the binary in a directory /root/qemu/5.2.0 with > --prefix=/usr it breaks since it converts the firmware and bios paths to > /root/qemu/5.2.0/../share/qemu. This means we need to recompile twice > with relevant prefixes since if i use --prefix=/nonexistent then we > can't find the qemu-bridge-helper when the binary goes into production. > > It would be nicer with the relocatable binary took some fixed paths from > /etc/qemu.conf for the bridge-helper, firmware, bios, qemu-ifup/down. > > thanks > Dave > > > On 12/01/2021 18:48, Paolo Bonzini wrote: > > On 12/01/21 15:05, Dave wrote: > >> Is seem that absolute firmwarepath compilation option is converted to > >> relocatable in 5.2.0 qemu. > >> > >> # QEMU configure log Tue 12 Jan 14:46:41 GST 2021 > >> # Configured with: '../configure' '--prefix=/usr' > >> '--sysconfdir=/etc/qemu' '--disable-bochs' > >> '*--firmwarepath=/usr/share/qemu:/usr/share/qemu-firmware*' > >> # > > > > Yes, all paths within the prefix are relocated. The workaround is > > simply to configure the intended prefix with configure: > > > > ./configure --prefix=/root/qemu ... > > > > or if you don't know the prefix: > > > > ./configure --prefix=/nonexistent ... > > > > Because /usr/share/qemu and /usr/share/qemu-firmware are outside /usr, > > they will be treated as absolute just like /etc/qemu. > > > > Thanks, > > > > Paolo > > > >> And trying to run the executable > >> > >> bash-5.1# ./qemu-system-x86_64 > >> qemu: could not load PC BIOS 'bios-256k.bin' > >> > >> If i print out the resultant binary paths > >> > >> bash-5.1# ./qemu-system-x86_64 -L help > >> /root/qemu/../share/qemu > >> /root/qemu/../share/qemu-firmware > >> > >> So there is no way to have a absolute path for firmware /bios and all > >> qemu's that we test need to be at the right directory nesting to find > >> firmware, bios etc or else they all need their own duplicate firmware > >> files. Firmware path needs to honor the absolute paths i believe. > >> > > > > [-- Attachment #2: Type: text/html, Size: 3789 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: absolute firmware path made relocatable in qemu 5.2.0 2021-01-12 16:53 ` Paolo Bonzini @ 2021-01-12 17:04 ` Dave 2021-01-12 19:53 ` Paolo Bonzini 0 siblings, 1 reply; 8+ messages in thread From: Dave @ 2021-01-12 17:04 UTC (permalink / raw) To: Paolo Bonzini; +Cc: qemu-devel Thanks Paola, We are still in testing and that's the only thing we've uncovered so far with the new 5.2.0. I will post if the ops guys find anything else. Dave On 12/01/2021 20:53, Paolo Bonzini wrote: > > > Il mar 12 gen 2021, 17:48 Dave <dave@0bits.com <mailto:dave@0bits.com>> > ha scritto: > > Hi Paolo, > > While this (option 2) partially works, it will still search for > /nonexistent/libexec/qemu-bridge-helper for example so seems that some > paths are still absolute and some relative. > > > Ok, that's a bug that can be fixed in 5.2.1. Are there other instances? > > > To explain, what we are expecting that we compile one binary with the > relevant options, test that and then it goes into production. If we > compile with --prefix=/usr (it's final resting place will be /usr/bin) > then everything works as expected once it is in production (since > /usr/share/qemu, /usr/libexec, /etc/qemu exists as expected). However > when we are testing the binary in a directory /root/qemu/5.2.0 with > --prefix=/usr it breaks since it converts the firmware and bios > paths to > /root/qemu/5.2.0/../share/qemu. This means we need to recompile twice > with relevant prefixes since if i use --prefix=/nonexistent then we > can't find the qemu-bridge-helper when the binary goes into production. > > It would be nicer with the relocatable binary took some fixed paths > from > /etc/qemu.conf for the bridge-helper, firmware, bios, qemu-ifup/down. > > thanks > Dave > > > On 12/01/2021 18:48, Paolo Bonzini wrote: > > On 12/01/21 15:05, Dave wrote: > >> Is seem that absolute firmwarepath compilation option is > converted to > >> relocatable in 5.2.0 qemu. > >> > >> # QEMU configure log Tue 12 Jan 14:46:41 GST 2021 > >> # Configured with: '../configure' '--prefix=/usr' > >> '--sysconfdir=/etc/qemu' '--disable-bochs' > >> '*--firmwarepath=/usr/share/qemu:/usr/share/qemu-firmware*' > >> # > > > > Yes, all paths within the prefix are relocated. The workaround is > > simply to configure the intended prefix with configure: > > > > ./configure --prefix=/root/qemu ... > > > > or if you don't know the prefix: > > > > ./configure --prefix=/nonexistent ... > > > > Because /usr/share/qemu and /usr/share/qemu-firmware are outside > /usr, > > they will be treated as absolute just like /etc/qemu. > > > > Thanks, > > > > Paolo > > > >> And trying to run the executable > >> > >> bash-5.1# ./qemu-system-x86_64 > >> qemu: could not load PC BIOS 'bios-256k.bin' > >> > >> If i print out the resultant binary paths > >> > >> bash-5.1# ./qemu-system-x86_64 -L help > >> /root/qemu/../share/qemu > >> /root/qemu/../share/qemu-firmware > >> > >> So there is no way to have a absolute path for firmware /bios > and all > >> qemu's that we test need to be at the right directory nesting to > find > >> firmware, bios etc or else they all need their own duplicate > firmware > >> files. Firmware path needs to honor the absolute paths i believe. > >> > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: absolute firmware path made relocatable in qemu 5.2.0 2021-01-12 17:04 ` Dave @ 2021-01-12 19:53 ` Paolo Bonzini 2021-01-13 7:51 ` Dave 0 siblings, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2021-01-12 19:53 UTC (permalink / raw) To: Dave; +Cc: qemu-devel On 12/01/21 18:04, Dave wrote: > Thanks Paola, > > We are still in testing and that's the only thing we've uncovered so far > with the new 5.2.0. I will post if the ops guys find anything else. Hmm, that's weird though. The path to the default bridge helper is relocated: net/tap.c: helper = default_helper = get_relocated_path(DEFAULT_BRIDGE_HELPER); Paolo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: absolute firmware path made relocatable in qemu 5.2.0 2021-01-12 19:53 ` Paolo Bonzini @ 2021-01-13 7:51 ` Dave 2021-01-13 8:29 ` Paolo Bonzini 0 siblings, 1 reply; 8+ messages in thread From: Dave @ 2021-01-13 7:51 UTC (permalink / raw) To: Paolo Bonzini; +Cc: qemu-devel This is my qemu binary compiled with --prefix=/nonexistent bash-5.1# ./qemu-system-x86_64 -L help /usr/share/qemu /usr/share/qemu-firmware /usr/src/sources/qemu-5.2.0/build/pc-bios bash-5.1# ./qemu-system-x86_64 --help|grep helper [,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off] use network helper 'helper' (default=/nonexistent/libexec/qemu-bridge-helper) to -netdev bridge,id=str[,br=bridge][,helper=helper] using the program 'helper (default=/nonexistent/libexec/qemu-bridge-helper) See that it will call /nonexistent/libexec/qemu-bridge-helper by default. Dave On 12/01/2021 23:53, Paolo Bonzini wrote: > On 12/01/21 18:04, Dave wrote: >> Thanks Paola, >> >> We are still in testing and that's the only thing we've uncovered so >> far with the new 5.2.0. I will post if the ops guys find anything else. > > Hmm, that's weird though. The path to the default bridge helper is > relocated: > > net/tap.c: helper = default_helper = > get_relocated_path(DEFAULT_BRIDGE_HELPER); > > Paolo > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: absolute firmware path made relocatable in qemu 5.2.0 2021-01-13 7:51 ` Dave @ 2021-01-13 8:29 ` Paolo Bonzini 0 siblings, 0 replies; 8+ messages in thread From: Paolo Bonzini @ 2021-01-13 8:29 UTC (permalink / raw) To: Dave; +Cc: qemu-devel On 13/01/21 08:51, Dave wrote: > > [,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off] > > use network helper 'helper' > (default=/nonexistent/libexec/qemu-bridge-helper) to > -netdev bridge,id=str[,br=bridge][,helper=helper] > using the program 'helper > (default=/nonexistent/libexec/qemu-bridge-helper) > > See that it will call /nonexistent/libexec/qemu-bridge-helper by default. Nice catch; fortunately, only the help is wrong. That's not easy to fix but I'll see what I can do. Paolo ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-01-13 8:30 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-12 14:05 absolute firmware path made relocatable in qemu 5.2.0 Dave 2021-01-12 14:48 ` Paolo Bonzini 2021-01-12 16:46 ` Dave 2021-01-12 16:53 ` Paolo Bonzini 2021-01-12 17:04 ` Dave 2021-01-12 19:53 ` Paolo Bonzini 2021-01-13 7:51 ` Dave 2021-01-13 8:29 ` Paolo Bonzini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.