Description of problem: Where is the category for this bug? I guessed at anaconda. Attempting to install from an iso image fails repeatedly. Fedora-Everything-netinst-x86_64-Rawhide-20180312.n.0.iso message reads: DNF error: non-fatal POSTIN scriptlet failure in rpm package tex-fonts-hebrew I booted in recovery mode from this same iso image and did a "dnf reinstall tex-fonts-hebrew" (why hebrew when this systems language is english?) There were two prompts. The first one asked if it was ok to do the operation, the second one asked if it was ok to install a GPG key. Perhaps this is what causes the failure? There are other problems with this UI. 1) The advertisements at the bottom of the screen are truncated on the right, even in full screen mode. 2) White on yellow (or orange) messages during root password and user creation are VERY difficult to read, perhaps black on yellow (or orange) would resolve this? 3) I had trouble with push buttons on the far right during hdd configuration. During one attempt I had to scroll up/down left/right to see the buttons, even in full screen mode. I would suggest moving the buttons closer to where the user is typing. Version-Release number of selected component (if applicable): see above How reproducible: always Steps to Reproduce: 1.I selected customized hdd config 2.I selected KDE Plasma workstation and selected all pkgs available 3.All of this activity has worked on several older versions of this install methodology. Actual results: failed installation Expected results: successful/clean installation Additional info: Installation was done under several different versions of VirtualBox with the same results.
Hello, First problem is problem in RPM file and duplicate of bug 1398847. For the second part of this bug it is hard to create design which works for everyone but if you really want those changes please create a new bug for them, they are not related to the first issue at all. Jirka
This problem STILL exists with the latest iso image. It appears that NONE of the changes required for this install to succeed have been resolved. This was with the latest Fedora-Everything-netinst-x86_64-Rawhide-20180402.n.0.iso file which is the SAME file as reported by this bug. Here's the path to the iso image. https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/iso/
Reassigning to tex-fonts-hebrew to fix the scriptlet failure. Please, open a separate bug for the UI issues.
Vendula, Thanks for your help with these problems. I made a bug for the UI issues I found, it's at "https://bugzilla.redhat.com/show_bug.cgi?id=1557538" George...
This is a copy of my Comment 21 to RHBZ 1398847: I get the same fatal non-fatal POSTIN scriptlet errors on the following packages during an F28 kickstart installation: clamav-update-0.99.4-3.fc28 (also happened in F25) dpkg-1.18.24-6.fc28 starplot-gliese3-0.95-15.fc28 starplot-yale5-0.95-15.fc28 And the same thing in the past with these: mozplugger (during F26 kickstart installation) lirc-core (during F27 Kickstart installation) All of these are repeatable. Even if the packages themselves are faulty, anaconda and dnf need to settle their differences about whether this is fatal or non-fatal. (In any case, it would be nice if anaconda could wait until all packages are tried before croaking; as it is, one has to re-run the installation to get to the next fatality.) As others have reported, the package installations succeed when done in the running system (after excluding them from the kickstart installation). UPDATE: According to https://kb.vmware.com/s/article/2040939 : By default, the RPM installer unpacks a temporary JRE to the /tmp directory, which is used for the remainder of the installation process. The error Non-fatal POSTIN scriptlet failure is the result of an SElinux policy that prevents executables from running in the /tmp directory. Even though the directory and unpacked files may have execute permissions, the system prevents the executables from running. That article provides a workaround (setting an alternative TMPDIR).
Hello Bruce, We have already done that. Look on the bug 1565123 which is result of this decision. In short, these errors will be fatal when that patch will be applied.
I am trying to install F28 KDE from the network installation iso and have encountered this bug. Anaconda dies before it can complete the installation. iso=Fedora-Workstation-netinst-x86_64-28-1.1.iso From anaconda.log 17:35:45,287 DBG ui.common: Left spoke: UserSpoke 17:50:10,987 INF progress: Preparing transaction from installation source 22:16:19,147 WRN misc: /usr/lib64/python3.6/site-packages/gi/overrides/GObject.py:553: Warning: gsignal.c:2641: instance '0x55a2de81e630' has no handler with id '371704' return func(*args, **kwargs) 22:16:19,147 WRN misc: /usr/lib64/python3.6/site-packages/gi/overrides/GObject.py:553: Warning: gsignal.c:2641: instance '0x55a2de81e630' has no handler with id '371705' return func(*args, **kwargs) If it is relevant, I have a separate 10gig ext4 formatted partition for /var
Hi, This problem still exists in the .iso file from https://dl.fedoraproject.org/pub/fedora/linux/releases/28/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-28-1.1.iso. I thought we put a spike in this one but apparently(?) the problem still exists. Did the .iso get rebuilt after the fix hit the fan? Best regards, George...
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
Please add the following... Fatal Error: DNF error: Error in POSTIN scriptlet in rpm package container-selinux Trying to install a minimal Gnome F29 Developement, LibreOffice, Editors and Games.
Similar problem with Fedora 29 for the Testing that is to take place this week. container-selinux-2.71-1.git5721d74.fc29.noarch.rpm tex-fonts-hebrew-0.1-28.fc29.noarch.rpm 621805568 Sep 3 04:37 Fedora-Everything-netinst-x86_64-29-20180903.n.0.iso 1901068288 Sep 3 09:10 Fedora-Workstation-Live-x86_64-29-20180903.n.0.iso 621805568 Sep 3 04:30 Fedora-Workstation-netinst-x86_64-29-20180903.n.0.iso
I cannot run any of the betas (network or Everything-network installation. Obviously, cannot go live with F29 if we cannot complete an installation.
Needs to be addressed. The txtfonts issue is created when the user selects Gnome and Authoring tools from the Anaconda pick list. LATEX is the software that appears to need See 1621922 My guess Authoring tools, Latex Fedora 29 Beta-1-5
There is another bug(?) lurking around here. I try to install on a VM provided by VirtualBox and get strange errors. Anaconda just stops and abandons the installation. The last situation I looked at showed me an "out of memory" message. I had been installing on a 1G VM. I raised the memory to 2G and tried again. I was successful in the installation. I won't swear to it but I think the options I chose were the same as those for the failure to install. I'm not sure just how the above affects these other bugs that people are seeing. George...
This problem is for the GO GOLD decision for Fedora 29. tex-fonts-hebrew" Category is anaconda I tested today with the following ISOs. Fedora-Everything-netinst-aarch64-29-20181011.n.0.iso Fedora-Everything-netinst-x86_64-29-20181011.n.0.iso Fedora-Workstation-netinst-x86_64-29-20181011.n.0.iso I do not have a VM system, I install on hardware. Ergo, I cannot have the network install versions active while I write this bug report. But Choose Fedora Workspace as left index and **Programming and authoring** group. Note Initial entry and Comment 13.
This problem is for the GO GOLD decision for Fedora 29. tex-fonts-hebrew" Category is anaconda Fails with Fedora-Everything-netinst-aarch64-29-20181016.n.0.iso Fedora-Everything-netinst-x86_64-29-20181016.n.0.iso Fedora-Workstation-netinst-x86_64-29-20181016.n.0.iso The anaconda menu choice is: Authoring and Publishing I would like to test this group within Anaconda. Manually, when doing sudo dnf group install "Authoring and Publishing", the syntax error is presented, but partial installation takes place, skipping some item(s) or another.
These groups are loaded from the comps file. Anaconda only presents this file to a user. Similar is true for DNF. So if there is bad package set then the comps file needs to be changed.
Created attachment 1499426 [details] Anaconda abort Fedora 29 Anaconda crash, The go live and this bug that was reported initially in August, with reminders....
Created attachment 1499427 [details] Anaconda What caused the abort. The dnf group that is at the cause. F28 was working.
This problem is in the Fedora GOLD for Fedora 29.
I think package tex-fonts-hebrew should be excluded from group "Authoring and Publishing" because of missing updates and no response of the maintainer since Fedora 25. I reported bug 1421542 in early 2017, no responce. Excluding the package from the group would help new admins to not run into the same problem. Package tex-fonts-hebrew still contains the old, wrong scriptlets. When installing on Fedora 29, I get the following error: Running transaction Preparing : 1/1 Installed: tex-fonts-hebrew-0.1-28.fc29.noarch Installing : tex-fonts-hebrew-0.1-28.fc29.noarch 1/1 Running scriptlet: tex-fonts-hebrew-0.1-28.fc29.noarch 1/1 /usr/bin/texconfig-sys: line 33: exec: texconfig: not found Option cnffile requires an argument Try "updmap --help" for more information. warning: %post(tex-fonts-hebrew-0.1-28.fc29.noarch) scriptlet failed, exit status 255 Error in POSTIN scriptlet in rpm package tex-fonts-hebrew
Edgar, Good catch. FIY: There's also a ".iso" installation failure bug in Virtual Machines with 1G memory defined... Going up to 2G seems to resolve the problem. George...
(In reply to George R. Goffe from comment #22) > Edgar, > > Good catch. > > FIY: There's also a ".iso" installation failure bug in Virtual Machines with > 1G memory defined... Going up to 2G seems to resolve the problem. > > George... This sounds like RHBZ 1470909 -- not enough working space in anything listed in DOWNLOAD_MPOINTS in dnfpayload.py (which includes /tmp; being tmpfs, its size increases with more memory).
Reassigning to comps based on the comment 21.
If this doesn't work at all and the maintainer has disappeared, please follow https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers to have the package orphaned and announced for a new maintainer.
*** Bug 1644753 has been marked as a duplicate of this bug. ***
Note, it's not really possible to remove a package from comps for any released distro. The comps for the base repo are frozen; there's no way to send a comps 'update' that says 'tex-fonts-hebrew is no longer in this group', AFAIK. We should just fix the scriptlet, for still-supported releases.
*** Bug 1621922 has been marked as a duplicate of this bug. ***
(In reply to Adam Williamson from comment #27) > Note, it's not really possible to remove a package from comps for any > released distro. The comps for the base repo are frozen; there's no way to > send a comps 'update' that says 'tex-fonts-hebrew is no longer in this > group', AFAIK. We should just fix the scriptlet, for still-supported > releases. I know that comps are frozen for a released distro, but removal would be an option for the next release. Another, perhaps better way would be to fix the bug and get a working package again.
This actually appears to be a bug in texlive-tetex. tex-fonts-hebrew tries to do this: %post conffile="$(/usr/bin/texconfig-sys conf | /bin/grep updmap.cfg)" if [ "$1" = "1" ]; then /usr/bin/updmap-sys --quiet --nohash --cnffile ${conffile} --enable Map=culmus.map fi it has appropriate requirements for this in place: Requires(post): /usr/bin/texhash /usr/bin/updmap-sys /usr/bin/texconfig-sys However, it fails, because texconfig-sys fails: /usr/bin/texconfig-sys: line 33: exec: texconfig: not found This is because texlive-tetex is missing a dependency, seemingly. texconfig-sys is shipped in texlive-tetex, and - per that error message - clearly needs /usr/bin/texconfig to be present to work. But /usr/bin/texconfig is shipped in texlive-texconfig , and texlive-tetex does not require texlive-texconfig.
texlive-base-20180414-25.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3ebbeee8fc
texlive-base-20170520-42.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b9042e90eb
texlive-base-20170520-42.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b9042e90eb
texlive-base-20180414-25.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-3ebbeee8fc
(In reply to Edgar Hoch from comment #21) > I think package tex-fonts-hebrew should be excluded from group "Authoring > and Publishing" because of missing updates and no response of the maintainer > since Fedora 25. I reported bug 1421542 in early 2017, no responce. > Excluding the package from the group would help new admins to not run into > the same problem. > > Package tex-fonts-hebrew still contains the old, wrong scriptlets. When > installing on Fedora 29, I get the following error: > > Running transaction > Preparing : > 1/1 > Installed: tex-fonts-hebrew-0.1-28.fc29.noarch > Installing : tex-fonts-hebrew-0.1-28.fc29.noarch > 1/1 > Running scriptlet: tex-fonts-hebrew-0.1-28.fc29.noarch > 1/1 > /usr/bin/texconfig-sys: line 33: exec: texconfig: not found > Option cnffile requires an argument > Try "updmap --help" for more information. > warning: %post(tex-fonts-hebrew-0.1-28.fc29.noarch) scriptlet failed, exit > status 255 > > Error in POSTIN scriptlet in rpm package tex-fonts-hebrew It is also appearing in other groups. You would have to exclude them. (Other groups in KDE, Gnome and I suppose, in spins). With Fedora28 I ran distrosync, as some kind individual migrated the F27 version to F28. Can someone migrate the F28 distro-sync'd version to F29.
texlive-base-20180414-25.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
texlive-base-20180414-25.fc29 was in the fc29 release (in Everything); I presume you mean texlive-base-20180414-26.fc29.x86_64.rpm which just turned up on the mirrors. Anyway that package update hasn't solved this issue for me in kickstart; I suspect you meant to update the requires of texlive-tetex to include texlive-texconfig rather than modify textlive-base.
However I do see texlive-tetex-20180414-26.fc29.noarch.rpm has also been released which does have a requires of texlive-texconfig ... hmmm.
Of course kickstart only uses Everything; not the updates.... which is why I'm still seeing the issue. (texlive-tetex ... -24 is there)
Does your kickstart actually include the updates repository?
Not sure how to specify that for anaconda; the %post does a yum update but thats too late for anaconda. I'm trying adding textlive-texconfig earlier in the package list (before @authoring-and-publishing; it didn't work when added after...)
Oh, trying 'repo' now; overlooked that...
(In reply to Ian Donaldson from comment #42) > Not sure how to specify that for anaconda Just put these lines in your kickstart file: repo --name=fedora repo --name=updates
I added a repo line for updates and now it loads the latest version of these packages but still falls over at tex-fonts-hebrew with the same error. Anaconda has this on its screen: DNF error: Error in POSTIN scriptlet in rpm package text-fonts-hebrew and anaconda stalls with that package name at the bottom in the progress bar. Using a CTRL-ALT-F5 while anaconda is stuck and a chroot /mnt/sysimage I see that these are installed: [anaconda root@cc02 /]# rpm -q texlive-texconfig tex-fonts-hebrew texlive-texconfig-20180414-26.fc29.noarch tex-fonts-hebrew-0.1-28.fc29.noarch and anaconda's /tmp/packaging.log (outside the chroot) shows this: ---- 13:00:40,029 INF dnf.rpm: Installed: texlive-texconfig-7:20180414-26.fc29.noarch 13:00:40,030 INF packaging: Installed: texlive-texconfig-7:20180414-26.fc29.noarch 1541690087 2be16a3059a934a291be6e1cc5609e12a69a43167fa0bcd264d2c69a9a2a54a5 13:00:40,060 INF dnf.rpm: Installed: texlive-texconfig-7:20180414-26.fc29.noarch ---- .. ---- 13:15:38,007 INF dnf.rpm: Installed: texlive-kerkis-8:svn15878.0-21.fc29.noarch 13:15:38,041 INF dnf.rpm: Installed: tex-fonts-hebrew-0.1-28.fc29.noarch 13:15:38,042 INF packaging: Installed: tex-fonts-hebrew-0.1-28.fc29.noarch 1531661689 9e6abd1fd629e6ae04cf949e15169d7b35872f0a7f4d7389c72b6034e85627e3 13:15:38,281 INF packaging: Configuring (running scriptlet for): tex-fonts-hebrew-0.1-28.fc29.noarch 1531661689 9e6abd1fd629e6ae04cf949e15169d7b35872f0a7f4d7389c72b6034e85627e3 13:15:39,940 ERR dnf.rpm: Error in POSTIN scriptlet in rpm package tex-fonts-hebrew 13:15:39,942 INF dnf.rpm: Installed: tex-fonts-hebrew-0.1-28.fc29.noarch ---- and there are a bunch of packages installed after this according to the log (for another 4 mins), but Anaconda thinks things have stopped. this is the end of the log: ---- 13:19:13,201 INF dnf.rpm: Installed: atmel-firmware-1.3-19.fc29.noarch 13:19:13,289 INF dnf.rpm: Installed: atmel-firmware-1.3-19.fc29.noarch 13:25:23,481 Level 8 dnf: RPM transaction over. 13:26:30,560 Level 8 dnf: timer: verify transaction: 66912 ms 13:26:30,566 Level 8 dnf: timer: transaction: 2441367 ms 13:26:30,575 Level 8 dnf: Cleaning up. ---- Reinstalling tex-fonts-hebrew under the chroot shows no errors though, so clearly something changed between the first attempt by anaconda and now. ---- [anaconda root@cc02 ~]# chroot /mnt/sysimage [anaconda root@cc02 /]# dnf reinstall tex-fonts-hebrew Last metadata expiration check: 0:14:22 ago on Tue Nov 13 02:42:47 2018. Dependencies resolved. ================================================================================================================= Package Arch Version Repository Size ================================================================================================================= Reinstalling: tex-fonts-hebrew noarch 0.1-28.fc29 fedora 66 k Transaction Summary ================================================================================================================= Total download size: 66 k Installed size: 220 k Is this ok [y/N]: y Downloading Packages: tex-fonts-hebrew-0.1-28.fc29.noarch.rpm 494 kB/s | 66 kB 00:00 ----------------------------------------------------------------------------------------------------------------- Total 22 kB/s | 66 kB 00:03 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Reinstall: tex-fonts-hebrew-0.1-28.fc29.noarch Reinstalling : tex-fonts-hebrew-0.1-28.fc29.noarch 1/2 Running scriptlet: tex-fonts-hebrew-0.1-28.fc29.noarch 1/2 Reinstall: tex-fonts-hebrew-0.1-28.fc29.noarch Reinstalled: tex-fonts-hebrew-0.1-28.fc29.noarch Cleanup : tex-fonts-hebrew-0.1-28.fc29.noarch 2/2 Reinstalled: tex-fonts-hebrew-0.1-28.fc29.noarch Running scriptlet: tex-fonts-hebrew-0.1-28.fc29.noarch 2/2 Verifying : tex-fonts-hebrew-0.1-28.fc29.noarch 1/2 Verifying : tex-fonts-hebrew-0.1-28.fc29.noarch 2/2 Reinstalled: tex-fonts-hebrew-0.1-28.fc29.noarch Complete! I'll attach the complete packaging.log if thats of any use...
Created attachment 1505085 [details] packaging.log from anaconda as mentioned...
I've managed to reproduce some errors by installing tex-fonts-hebrew on another system running fc29 (distro-sync'd from fc28) I'm attaching the long from that install but the jist of it is that updmap is complaining a lot... updmap [ERROR]: The following map file(s) couldn't be found: updmap [ERROR]: Acorn.map (in /usr/share/texlive/texmf-config/web2c/updmap.cfg) updmap [ERROR]: Alegreya.map (in /usr/share/texlive/texmf-config/web2c/updmap.cfg) updmap [ERROR]: AnnSton.map (in /usr/share/texlive/texmf-config/web2c/updmap.cfg) updmap [ERROR]: AnonymousPro.map (in /usr/share/texlive/texmf-config/web2c/updmap.cfg) ... updmap [ERROR]: Did you run mktexlsr? You can disable non-existent map entries using the option --syncwithtrees. warning: %post(tex-fonts-hebrew-0.1-28.fc29.noarch) scriptlet failed, exit status 1 Error in POSTIN scriptlet in rpm package tex-fonts-hebrew Installed: tex-fonts-hebrew-0.1-28.fc29.noarch So this could be a clue...
Created attachment 1505099 [details] dnf install tex-fonts-hebrew output
https://lists.debian.org/debian-tex-maint/2013/06/msg00070.html seems to be suspiciously similar to this issue; however the fix there was to install texlive-lang-other (debian) but there is no fedora package of that name; perhaps its called something else?
https://bugzilla.redhat.com/show_bug.cgi?id=1595278 also seems related but I know very little about tex
IMHO the Status of this issue should not be CLOSED
I have still excluded package tex-fonts-hebrew, so I had no problem with it. So I thought I should test it now. I confirm that there are still scriptlet errors in package texlive-base-20180414-26.fc29.x86_64 The error differs from the one originally reported, because now there is no program missing, but a config file contains wrong values (missing map). May be we need to create a separate bug report for this. The errors are similar to comment #47, but it seams that it depends on the installed packages which map files could not found. My list on one test system is shorter: updmap [ERROR]: The following map file(s) couldn't be found: updmap [ERROR]: Coelacanth.map (in /usr/share/texlive/texmf-config/web2c/updmap.cfg) updmap [ERROR]: Did you run mktexlsr? You can disable non-existent map entries using the option --syncwithtrees. Warnung: %post(tex-fonts-hebrew-0.1-28.fc29.noarch) Scriptlet fehlgeschlagen, Beenden-Status 1 Error in POSTIN scriptlet in rpm package tex-fonts-hebrew
Is there a way to make Anaconda ignore packages with install errors and just keep going?
(In reply to Ian Donaldson from comment #53) > Is there a way to make Anaconda ignore packages with install errors and just > keep going? There is no way to make Anaconda ignore package scriptlet errors. This is by design as many scriptlets (such as those run by the kernel package) are critical and their failure will result in a broken system.
Please do file a new bug with details of the new failure, I'll try and help take a look at it if I get a chance. I just did a drive by on this one.
I'm just looking at way to avoid anaconda falling over with this... if I removed the @authoring-and-publishing from tha package list and replace that with a 'dnf -y installgroup 'Authoring and Publishing' in %post will that be equivalent? (presumably preceding that with a dnf install tex-something to avoid the missing dependency... need to know what something is but)
As best as I can tell, the new error seems to suggest a file in texlive-lib (/usr/share/texlive/texmf-config/web2c/updmap.cfg) has a reference to a font that isn't actually shipped in Fedora (Coelacanth). That's definitely a different bug, so it really should be filed separately. spot, any idea what's going on there?
texlive-base-20170520-42.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
.)stseuqer ofnideen lla raelc lliW( gub siht rof noitamrofni detseuqer eht gnidivorp ma I
Tom, I speak English and a little French so... I don't understand what you wrote above. Can you repeat in English please? Regards, George...
It's English in right-to-left. I'm guessing it's a joke because of this bug being about an RTL language.
Apologies. I was being flippant while cleaning out old needinfo requests. I believe this bug is resolved, but if not, please let me know.
Tom, Not a problem... cute. Now I stand under. :-) George...