You can't add media using urpmi.addmedia to a clean chroot, with a different arch. 1. have a mageia1 i586 system 2. urpmi.addmedia --urpmi-root /chroot --distrib 'http://mirror/mageia/1/x86_64' unable to add media imho when urpmi-root is used, arch should be ignored. workaround: make manually the repositories
So you're trying to install a mageia x86_64 in a chroot, from an i586 machine ?
Status: NEW => RESOLVEDCC: (none) => boklmResolution: (none) => INVALID
Created attachment 890 [details] urpmi-6.40_ignore_arch_with_urpmi_root.patch patch for urpmi that allows adding media when other arch when using urpmi-root.
(In reply to comment #1) > So you're trying to install a mageia x86_64 in a chroot, from an i586 machine ? from a i586 system (when it's a 64bit capable CPU), but even so, maybe i could use it as NFS system later, so it should be possible in any case.
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
(In reply to comment #1) > So you're trying to install a mageia x86_64 in a chroot, from an i586 machine ? i hadn't yet noticed that you set it as invalid. if you have a 32bit machine that is a PXE and NFS server. and you have a 64bit machine you're wanting to boot using it, this is a perfectly valid way of doing it. you make a chroot using urpmi.addmedia and urpmi and then set up the PXE to it. not INVALID imho. in any case, patch is applied, and is locally tested, after this patch, it works for me.
Keywords: (none) => PATCHAssignee: bugsquad => thierry.vignaud
(In reply to comment #3) > (In reply to comment #1) > > So you're trying to install a mageia x86_64 in a chroot, from an i586 machine ? > > from a i586 system (when it's a 64bit capable CPU), but even so, maybe i could > use it as NFS system later, so it should be possible in any case. Creating an x86_64 chroot from an i586 machine should not be possible. If you're using an x86_64 kernel on an i586 install, just use linux64 to run the urpmi command, no need to patch urpmi for this.
"Creating an x86_64 chroot from an i586 machine should not be possible." Can I ask why this should not be possible? it's just installing things, it doesn't run any code from the packages itself (except in some cases). also, after testing it seems that linux64 doesn't actually help with urpmi. allthough it may help with regards to urpmi.addmedia (didn't test). Theoretically i see no reason why it should be impossible, it's no more than storing(installing) binary files.
(In reply to comment #6) > "Creating an x86_64 chroot from an i586 machine should not be possible." > > Can I ask why this should not be possible? it's just installing things, it > doesn't run any code from the packages itself (except in some cases). "except in some cases" > > also, after testing it seems that linux64 doesn't actually help with urpmi. > allthough it may help with regards to urpmi.addmedia (didn't test). > > Theoretically i see no reason why it should be impossible, it's no more than > storing(installing) binary files. And using the binaries installed to run post scripts. And using the rpm binary.
(In reply to comment #7) > (In reply to comment #6) > > "Creating an x86_64 chroot from an i586 machine should not be possible." > > > > Can I ask why this should not be possible? it's just installing things, it > > doesn't run any code from the packages itself (except in some cases). > > "except in some cases" yes, and if you're going down this route, you should know that some automagic in post scripts will not be executed (unless you do have a 64bit capable processor) allthough i don't know how it gets done with --urpmi-root? are the commands executed from the host system? afaik post scripts aren't executed in a chrooted environment when using --urpmi-root... > > > > also, after testing it seems that linux64 doesn't actually help with urpmi. > > allthough it may help with regards to urpmi.addmedia (didn't test). > > > > Theoretically i see no reason why it should be impossible, it's no more than > > storing(installing) binary files. > > And using the binaries installed to run post scripts. And using the rpm binary. the rpm binary from the chroot is actually used when _installing_ packages? imho, as long as you don't effectively "chroot" it and you're using --urpmi-root, then no code inside should be executed?
Obviously unsupported. %post scripts and the like will be broken
Status: REOPENED => RESOLVEDResolution: (none) => INVALIDSummary: can't adding media on clean chroot with different arch => can't adding 64bit media in clean chroot with different arch on 32bit install
afaik they will not be more broken then when using --urpmi-root for anything else. i mean, %post scripts need to have something installed to work, yes? and how else am i going to set up a PXE NFS boot for a different arch?
Summary: can't adding 64bit media in clean chroot with different arch on 32bit install => can't add 64bit media in clean chroot with different arch on 32bit install
(In reply to comment #10) > > and how else am i going to set up a PXE NFS boot for a different arch? Use an x86_64 server. Or generate the chroot on an other x86_64 machine.
and what about ARM? if this patch isn't ok, what about an --ignorearch option like urpmi has?
Is there something you don't understand in "this won't work because of %post scripts" ?
yes, actually, i would like an answer to my questions before: "the rpm binary from the chroot is actually used when _installing_ packages? imho, as long as you don't effectively "chroot" it and you're using --urpmi-root, then no code inside should be executed?" trying to reclarify: if i'm doing "urpmi --urpmi-root /path/chroot file.rpm", and that rpm has a %post script, it can't just "chroot /path/chroot $post_script" , so my guess is that %post is being executed on the host system?
The post scripts are of course executed in the chroot, it wouldn't make sense to execute them outside.
that's what i meant, it makes no sense to execute them outside; however, i did not see any chroot calls in the urmpi code, unless it happens in the rpm code? and otoh, even if post scripts are not executed, afaik, this does not result in a broken system. and even if they are unsupported, should we just forbid these kind of things? i didn't reopen, because imho it's maintainers choice, because (s)he has to maintain this code (even though it's so small...)
CC: boklm => (none)