Should this question be closed as a duplicate of the question whose solution applies to it? I wrote the accepted answer there and I could write an answer to the newer question, whose situation is admittedly different, but I don't think my answer would address any differences.
Regarding that older question, is this answer really an attempt to answer the question that was asked there? The question is entirely about how recovery mode cannot be used. Normally I'd just flag such an answer NAA, but another answer there, which is much higher quality and which some people seem to have found helpful, has the same problem.
I wouldn't flag that better yet still (for the situation described) wrong answer NAA... so should I hold off on doing so on the shorter lower-quality one with the same fundamental problem?
@Kulfy yes I saw. But I think libreboot is a specific piece of software relating to Ubuntu. I don't think people would use the tag incorrectly. So I think it's a reasonable tag for us to have
Should this comment of mine be expanded into an answer? Do we have something for this situation? Considering how many answers unfortunately recommend that people run dist-upgrade as part of a normal upgrade process (some even recommend passing -y!), I'd expect this to have come up a number of times before.
@karel I've done some searching for existing content that might address what was being asked in How can I report a bug when ubuntu-bug crashes? Although I think we should have something about installing debug symbols and producing manual local stack traces for manual attachment on Launchpad (and we seem... not to have that?) I don't think that's really relevant there.
The command the OP was running suggests they were trying to report a non-crash bug in a package. The only thing I've found for doing that without Apport is its_me's answer to How do I report a bug?. In my opinion, it would be better to close it as a duplicate of that general bug-reporting question with a link to that answer than to keep it closed as OT with no clear rationale.
The other aspect of the issue, though, is that although the title is about Apport crashing, I fairly sure that what the OP observed is not actually a crash (ubuntu-bug is a Python script, and if crashed the interpreter would print a stack trace, unless the crash was in the interpreter or some binary library, in which case the shell would probably print a message indicating what signal had terminated it), and I'm not entirely convinced that it has anything to do with a bug in Apport itself.
@EliahKagan That's specific enough for me. I have cast the fifth vote to reopen this question. I will also track the question afterwards if it is VTC'd as a dupe of the relevant duplicate question which I agree would be a more useful reason to close this question.
quite wrong answer got accepted, probably because OP is new here. Running apt list packagename (in answer) instead of apt list --installed | grep packagename (already mentioned in question) defeats the purpose of finding/determining whether packagename is installed.
mchid's comment under the answer should be the correct answer
@karel That answer actually does propose something the OP didn't try: passing the name of the source-code file to the compiled executable. This is totally wrong and useless in general and absolutely could not solve the problem the OP described, but it's sort of an attempt to answer... something. I would support deleting that answer (and I have cast a delete vote) but it might not qualify as NAA.
I am hoping we might be able to close that question as a duplicate of something.
Since all of its answers are wrong, and I vaguely recall we have at least one other question about that problem.
When a native compiler produces a program on Ubuntu, it attempts to give it executable permissions (in accordance with the current umask). So when the problem the OP described happens, running chmod +x is extremely unlikely to fix the problem. Most of the time, the problem is that the filesystem doesn't support executable permissions or is mounted noexec.
I could post an answer but I have a feeling that maybe I have answered what is effectively that question. Unfortunately, so far I'm having trouble finding something by searching. If nobody else finds anything I'll look again, though.
(I hope you don't mind the pings. I know you've looked at it recently--at least to revie the new answer which we should delete--so I figured your opinion would be valuable.)
@Zanna Imaginable? Yes, the hypothetical display problem I mentioned in my comment could theoretically occur, though I don't think the situation described in the question is one where it is any more likely to occur than otherwise. It is possible graphics not to work in a live environment even though they were in an installed system.
I think a better reason to think I might be wrong in wanting to dupe that question is instead that there might be some way to make text display on the external monitor in recovery mode. I'm not sure how, though, and I suspect it would involve editing a GRUB line that doesn't appear on the external monitor, or editing BIOS/UEFI firmware settings an an interface that presumably wouldn't get drawn on the external monitor.
well an answer about that wouldn't be applicable to the target I think
so I think we should not close that question as it might receive an answer that is specific to this scenario
but it can still receive answers that would apply to the possible target as well
@EliahKagan I am not sure what should happen... but the better-but-still-wrong answer also gives a different solution (set init=/bin/bash in the GRUB editor) which I believe would work in this scenario. They have explained how to enter recovery mode at beginner level in helpful detail, but merely included a quote without commentary hinting at how to boot with init=/bin/bash that a beginner would probably have difficulty understanding...
... however, while the link to the article they have quoted from seems dead, there is a link to this article which explains that method (personally, my preferred method of fixing broken stuff when it can be used, because my laptop USB ports are a bit flakey)
The anonymous feedback shows that more people who landed on this page found that answer unhelpful than found it helpful
But, still, a significant number of anonymous low rep/unregistered users found it helpful
That makes me think that at least some of the users who upvoted the better-but-still-wrong answer did so not because using recovery mode helped them, but that something else in the post helped them
I propose deleting the low quality wrong answer, and editing the better but still wrong answer to expand the section about using init=/bin/bash
@EliahKagan I feel that the question is unclear as I can't come up with any likely-to-be-right explanation for their claim that the command works when they are root but when they are not root returns the error they've shown. Maybe that's just lack of knowledge on my part though. I am ok with the posted answer - maybe OP was mistaken about it working when they were root
@EliahKagan I can try to edit it if you prefer. If you want to edit it, possibly this answer of mine might have some material that is helpful
@Zanna I would be in favor of closing that question as unclear, and I've voted to do so. I can come up with a plausible explanation for their problem (see the stuff in my comment regarding secure_path) but it would still be a guess.
yeah... I just find it slightly far fetched that they would have another command with the same name in a different place. That's certainly possible, but it seems to me that them omitting something important or just making a mistake when writing the question is at least as likely
@Zanna Yes, I see what you mean. I've retracted my close vote from that question. I guess it should get an answer about resetting the password from a live environment.
@karel Okay, I've VTC'd that question and commented.
@EliahKagan In my opinion, it's not such a good example of a situation where secure_path is the reason for some surprising behaviour that I would be in favour of an answer being posted about that speculatively. But if someone wanted to post an answer like that there then I would retract my vote.
@Zanna My thinking is that it's probably just a different version of their own script. They may have made the script, copied to the destination, and then edited it but forgot to copy the new version, or something. They may even be running sudo ./resnet to run it as root, running the version in the current directory, but resnet to run it as the non-root user, running the earlier version with the typo. I don't know. I think an answer would involve too much guessing, until the OP edits.
@Zanna Yes, I agree. I don't plan to post such an answer based on the information currently provided.
@EliahKagan This question was an old question that I initially close voted as a duplicate of something else and then retracted because my duplicate target wasn't specific enough. When I read this new question about CPU-G I remembered this old question because I finally found a dupe target question that was specific enough.
I should answer it, but I'm not sure if/when I will. Also, if it's a duplicate, maybe my answer would be better on a different question. If you feel like looking, I think that could be helpful.
Also if you feel like answering (or something we dupe it to) then I wouldn't have to! :) Everything needed for an answer is in my comment... which, though it takes the form of a good comment, does heuristically suggest that I should've written an answer in the first place rather than posting a comment. That, and I couldn't resist writing "You shouldn't need to reinstall" which is answer-y.
@EliahKagan I would not like any of those questions to be closed. I wonder why nobody attempted to address the request in Where are the logs for apt-get for logs for Synaptic and the Ubuntu Software Center. Should those be removed from the question as they make it too broad?
@Zanna I don't think that question is too broad. All those logs are very related to one another. Even if it did only ask about some of those, an answer that covered the others would be reasonable.
@Zanna And there's also a separate Software app that is the sequel to USC, right? (I didn't use USC much even at its height and I do most of my package management from the command line, so I'm not sure.)
I don't know where those logs are. Maybe I once knew, I'm not sure. Do you want to add an answer?
@Zanna That's not unique to MATE, is it? Anyway, I think that's separate from the new Software app, which I seem to recall is from GNOME and uses appstream.
@Zanna I don't know. Maybe it would be best to search for similar questions, then ask a question on Ask Ubuntu Meta about what should be done to maintain them.
@karel I think the suggested dupe target on this question is wrong, because the answers there are almost all addressing the problem from the Windows side, but there is no Windows installed in the new question
your answer there might have the solution, but it's so thoroughly buried that I feel it would be much less confusing if you posted a version of that answer on the new question instead
but I feel that the new question is probably unclear...
@Zanna Yes. If the compiler can make the program it emits executable, it will. If it can't, running chmod +x won't. In theory, something like chmod 755 a.out or chmod a+x a.out or chmod u+x a.out could help, in case the problem is caused by a very bad umask that has a 1 (or 3, or 7) as the owner digit. In practice, though, I don't think that's ever what causes this problem for people.
Also, I'm talking about the process umask, whose default is set systemwide via PAM (in Ubuntu) and modifiable in a shell with the umask builtin. The umask mount option could cause this problem, is more likely to be edited (and thus incur typos), and no chmod command will overcome that.
But I am curious as to why the answers got mixed, rather than mostly negative, anonymous/low-rep feedback.
@Zanna Or different compilation problems? Maybe people who are looking for how to compile, what the program is called if the name is not specified as an operand to an -o option, or how to run their compiled program?
Although I think the tag is a reasonable one, and I don't really see any reason why it would be a problem on that question, I don't think it is particularly necessary on that question, which as far as I can see, could be answered with the word "Yes" if three character answers were allowed...
given that, I don't think this answer should have been deleted
although I myself would not have wanted to post such an answer since I am entirely unable to verify whether adding iomem=relaxed would fix the underlying problem, I think it would not be unreasonable to consider that beyond the scope of the question as written, so, should we vote to undelete that answer?
oh it was deleted by a mod. So we can't
but should we flag it?
^ screenshot of the answer I'm talking about - to this question
ek@Kip:~$ (set -C; >a; >A; >b; >B; umask -S; ls -l [aAbB]; chmod +x a; chmod u+x A; umask 0102; umask -S; chmod +x b; chmod u+x B; ls -l [aAbB])
u=rwx,g=rwx,o=rx
-rw-rw-r-- 1 ek ek 0 Jul 29 09:41 a
-rw-rw-r-- 1 ek ek 0 Jul 29 09:41 A
-rw-rw-r-- 1 ek ek 0 Jul 29 09:41 b
-rw-rw-r-- 1 ek ek 0 Jul 29 09:41 B
u=rw,g=rwx,o=rx
-rwxrwxr-x 1 ek ek 0 Jul 29 09:41 a
-rwxrw-r-- 1 ek ek 0 Jul 29 09:41 A
-rw-rwxr-x 1 ek ek 0 Jul 29 09:41 b
-rwxrw-r-- 1 ek ek 0 Jul 29 09:41 B
ek@Kip:~$ ./b
-bash: ./b: Permission denied
@Zanna Thanks. In general--not for that specific post--this is one of the reasons I wish people would downvote NAA posts. It makes them easier to delete, and thus potentially easier to delete wrongly -- but the way of deleting them that it facilitates requires at least three people to agree with the deletion and doesn't require any flags to undo if it was found to have been wrong.
Of course, as a 20k user, I would say that. :)
Except that there seem to be fewer people who downvote NAA posts with any regularity than there are 20k users!
It is in many ways psychologically easier to click "Delete" in review than to downvote a post. I find that clicking the post link and downvoting improves the reliability of my reviews, because if I feel uncomfortable downvoting a post, then I very very likely was wrong in my initial impression that I should delete it!
Also, 20k users get to delete posts directly from review when their scores are non-positive, so I think visiting posts, looking at them again, and either downvoting or satisfying oneself that it would be reasonable to downvote, are especially useful things or 20k users to do while reviewing.
I also don't much like the idea of downvotes communicating "This actual answer is so bad, it's worse than all the things that were never even intended as answers!" but that's what they mean if people don't even downvote NAA posts.
[edited] To be clear, some aspects of this apply only to posts that may exist for a while after the actions are taken. When a 20k user knows they're casting a third delete vote on a post, it doesn't really matter if they downvote... though on second thought, the point about how if a post doesn't feel right to downvote then maybe don't delete it especially applies in that situation! Anyway, when a moderator deletes a post, there's definitely no compelling reason for them to downvote it first.
Well please do carefully check the posts before voting to delete them in case I am mistaken. I do try hard only to tell Natty true things, though.
Btw, I don't think Natty requires privileges for the way I interact with it (nor that I have any). I recall Bhargav Rao having said that it accepts feedback from any account, unless the account has given feedback that was found to be wrong some set number of times, in which case that account is banned from Natty unless/until a developer unbans it.
Also, karel provides considerable feedback to Natty as well, and is -- I believe -- quite involved in SOBotics.
but it bothers me that someone interpreted the question as a rant and wrote a response to the rant instead of voting to close, or better yet addressing the specific content of the post
As for the answer... hmm. It's not currently written as an answer to the question. It does not tell the OP how to fix the problem. It has a comment that claims the answer says something it does not actually say anywhere, and the information in the answer isn't really sufficient to do what the comment recommends, which is possibly good, since what the comment recommends doesn't make sense, which is also why I haven't attempted to edit the answer. As for whether or not it's actually NAA...
@Zanna Doesn't the question not stating what the OP wants to know make it unclear? Or do you mean that it's possible to give an answer that encompasses everything they're likely to be confused about while being reasonably scoped? I've commented to suggest the OP edit the question. If someone wanted to attempt an answer based on the ideas there, I definitely wouldn't mind. :)
@EliahKagan I think what they wrote strongly implies that they are confused about the output they got and want Alice to work. I think your comment does somewhat answer the question
The upstream package, and thus description, for alice in Ubuntu on Launchpad, is incorrect.
I wonder if that or some other source misled the OP into installing what they installed when they meant to install another program entirely.
Is there something unstated here? I'm concerned maybe I edited some of their posts unhelpfully which were subsequently deleted so I can't find them now. It seems implausible that they think only two edits, separated by over five years, out of almost seven thousand total edits, constitute a "crusade." Or maybe I did not search thoroughly enough?
Is there a SEDE query for finding all of user A's edits on user B's posts. That wouldn't turn up deleted (at the time of the dump) posts but it might catch something I missed while searching. Or should I just ignore it?
This suggested edit is wrong. The trailing slash on a destination directory to mv works fine. Furthermore, the behavior of a trialing slash is almost the opposite of what the edit summary claims, in that when the destination is inadvertently not a directory (nor a symlink that resolves to one), the trailing slash prevents unintended replacement. I rejected it with a custom message but it needs one more review.
When I read the notification, I was confused about what had happened. It said there was a suggested edit and there was an explanation (an edit summary) saying "hide ugly link". I thought I had to go and hide my ugly link. I was worried about having done something wrong and eager to fix it instantly
But when I went to the post I saw that it had already been edited. I was relieved.
Ever since I started nearly always writing "copyedited" instead of those things, I haven't felt like my summaries were less useful or even less detailed in any important way, and the number of people who expressed frustration at having their English corrected dropped to zero. (Except the recent comment from that question where my edit didn't have anything to do with that. But that's still just one case, if counted.)
I think better examples that could be given in that box are "copyedited" (or "copy edited" if that's the preferred spelling, I don't actually know), "fixed code formatting," and "reworded for clarity."
@Zanna I don't think summaries like "corrected spelling" are actually rude. I'm having trouble expressing quite why I think sometimes people don't like that, even if they would otherwise not object to the edit it describes. I don't think they're just being unreasonable, though. Not always, anyway. "Corrected spelling" is a strange level of detail: enough to calls attention to a highly specific shortcoming of a post, but not enough to be useful or interesting.
I think it may be better to use less detail ("copyedited") or, where warranted, more detail ("fixed 'Ubuntu' misspellings throughout").
@Zanna The summary the system generates is usually better than nothing, and thus much better than a wrong edit summary. So that's not necessarily bad.
But I do recommend writing edit summaries except when you think the system-generated summary would be better than yours.
@EliahKagan I personally feel embarrassed when someone corrects me, especially when I'm trying to use a language other than my L1. Obviously I'm also grateful that they correct me, but being wrong hurts.
I do apparently write some such edit summaries of the sort I'm suggesting aren't usually good.
I think I have figured something out! (Maybe.)
The system bothers users about edits by notifying them. In some cases it creates the impression that they must do something, as you had described. The edits' summaries often say things like "corrected spelling" or "fixed grammar," and the effect is that it feels to the user that they were being told their spelling/grammar/whatever was bad.
I don't know the solution. I don't think the solution is fewer notifications. If anything, people aren't informed often enough of edits to their posts.
We have questions about installing Ubuntu that require, and receive, answers that address technical aspects of Windows, like temporarily disabling swap and paging, partitioning in the Disk Management MMC snap-in (diskmgmt.msc), ensuring volumes are "basic" disks, converting them to "basic" disks if they aren't... as well as more mundane things on Windows like how to burn a DVD or write to a USB stick and how to verify a hash.
I strongly agree with allowing all this -- after all, we support installing Ubuntu.
It bothers me that there seems to be so much less tolerance for questions where the OP who wants to run a supported release of Ubuntu is currently running an unsupported release of Ubuntu.
The controversial and very possibly wrong solution would be to get rid of the policy that EoL questions are off-topic, if a consensus would support that. A policy can't be misinterpreted if it doesn't exist.
That one policy has led to an extraordinary amount of complexity and confusion, more probably than any other policy of the site, and it was established more through the persistence of the people who wanted it than any strong consensus.
Just to be clear, I am not objecting to that persistence, nor am I claiming the consensus didn't exist, but there is no reasonable argument that the policy can't be revisited. It was revisited over and over again until eventually opinion shifted and EoL questions were disallowed.
I have never had any real opinion about what our policy should be on that and I still don't. However, I was involved in making the policy official and, given its sum total of its effects as I understand them, I somewhat regret ever doing anything that brought things to the point they are now, on that.
At minimum the policy should be changed to use ESM ("end of standard support") instead of EOL ("end of life"). EOL was correct when the policy was established but isn't now. I only became aware of this recently when @Kulfy explained it in connection with an actual practical confusion that resulted from it.
The thing is, I think that even to make that change we would need to vote on meta.
And while we're at it, we might as well consider other options.
I suspect that opposition to new questions about problems running EOL releases is as high as ever. But that's just a suspicion. Also, I've repeatedly heard people guess that the reason for the policy is that Canonical requires it, which is not so.
@EliahKagan on the last of the three meta posts you linked there, about which you said the community was 2-1 against supporting EoL questions, Jorge Castro's answer is now by far the highest voted
I interpreted that answer not expressing a strong position on what the policy should be, and the votes on it as expressing that it is not all that important what the policy is. In hindsight, though, that might be a wrong interpretation.
In January/February this year, some people argued that we should allow questions about other distros in some situations. I argued that we should retain our policy. I was actually distraught about it. I asked Seth to ban me from chat so I could get to sleep because it bothered me so much
@Zanna I don't feel quite right about asking you to elaborate about a topic you introduced by saying it made you distraught and that it was harmful for you to be chatting about... so I won't ask you to do that. However, I will say I'm not sure if there's a connection between that and the EOL policy. I might not be seeing what I'm supposed to be seeing.
Or is the connection that you don't want to post on meta about this because it could be similarly stressful?
I (also?) don't want to post on meta about it, at least not at the moment, because I don't want the commitment to engaging with the community about it.
@Zanna But it looks like you're right. This should get brought up--together with the terminology issue of EOL vs. ESS (which I had wrongly spelled "ESM" above, which stands for something else, sorry!)--on meta at some point.
@EliahKagan I feel many questions on the site has nothing to do with the version. I asked whether to remove version tag on one such question since I wasn't sure. But it got deleted before I could do anything.
I was reassuring myself that it's not just because I enjoy disruption hahaha
@Kulfy this is terdon's argument, but I don't really like that argument, because it's hard to tell what questions are and are not version-specific in some way without knowing in detail what changed between versions
@Zanna I see them as quite different policies with way fewer shared rationales than might at first appear. But one difference is that Ubuntu releases that no longer receive updates are still Ubuntu, so the conceptual burden of defining our scope to exclude them is greater than that of defining it to include them.
@Zanna True, but at least we can know about those details. In contrast, determining if something that was observed to occur only on another operating system is specific to that system is quite a bit more difficult.
But I think that that knowledge is a kind of knowledge that the community can be expected collectively to have and that is somewhat embodied on the site too. So the argument that we should allow all versions of Ubuntu is much better than the argument that we should allow all Linuxes because the differences between distros are not something we should be expected to know in detail
@EliahKagan yes yes exactly
@EliahKagan it seems this is really important. If we don't have a simple policy, the policy will be misinterpreted.
@Zanna But this can also be used to argue for the current "EOL" policy, right? We're in a pretty good position to know about changes in Ubuntu, so we have a good chance of discerning what questions really are "EOL"-specific, so we can allow "EOL"-nonspecific questions that arose on "EOL" releases.
So there's not too much harm associated with having "EOL" releases be off-topic. So the policy is a good one. That's how the argument would go, anyway.
In contrast, for other OSes, it's harder to identify cases where it really applies well enough to Ubuntu, and easy to feel like one has identified such a case. For example, when someone says they use Kali, and it seems like we can reproduce their problem on Ubuntu, but doing so requires uncommon actions like enabling root logins, and then we lecture them about how they shouldn't have gone out of their way to enable root logins on Kali, they have not been helped.
we don't close questions that are specific to EOL versions and that makes sense because we know what has changed between Ubuntu versions - that information is easily available, and somewhat embodied on the site
I created a new user with `adduser jusa`. I started `visudo`. How do I need to change the line
jusa ALL=(ALL:ALL) ALL
to make `jusa` only have access to a specific folder `/var/www/vhosts/folder`?
How do I make the folder `/var/www/vhosts/folder` the only one `jusa` can write in?
@EliahKagan yes. terdon made the same argument, that many questions are not distro-specific, but I feel that it is extremely difficult to know that. He claimed to know. Ok, he is an expert, but the policy has to treat everyone the same, we can't have a special policy just for experts
People would think they know something is not distro-specific and they would be wrong, and eventually the site would be full of confusing things
