a strange package problem .. bash @name exists but plist empty

[jggimi]

Originally Posted by daemonfowl

yes it does...

Sigh. You are silent on the results of steps 2,3,4.

[daemonfowl]

Sorry to say it, but I've messed it up .. then upgraded as a last-hope .. then after sysmerge I saw many warnings .. on reboot I couldn't login.
Errors:

SensordApr ........ su : daemon : unknown class
hotplugdApr
cronApr
...etc
login : (input)
failure to retrieve default class
unknown class

saving time , I bought a third sata disk .. installed a fresh OpenBSD current .. with a SATA IDE Cable I can access /dev/sd0h to retrieve data ..
It's more likely to be a lost case (thanks to my silliness of course) .. now what could be done i a similar situation ? dd my home partition ? will it somehow remedy the situation by copying clean config files fro the fresh system to the old one ?
If the old disk weren't far bigger (500g) than this new one (60g) , I would consider transferring home data and reinstall a fresh OpenBSD ..
Any suggestions are welcome .. Thanks.

[jggimi]

1. The error messages you posted here just now indicate a missing or damaged /etc/login.conf.
2. You must learn some new disciplines:

• Disaster recovery:

• Institute a backup schedule -- a cadence of full and incremental or differential backups, to recover from problems caused by hardware failures, software failures, or your own (or your users) errors.
• Develop and practice recovery procedures until you have a clear and repeatable process so that you are able to restore a complete system onto "bare metal" -- starting with a computer that has no software on it at all.

• Problem reporting:
  • Please read the following quote. I've linked you to it once or twice, but you haven't read it, or haven't understood it. Please, try again.

How to create a problem report

Always provide as much information as possible. Try to pin-point the exact problem. Give clear instructions on how to reproduce the problem. Try to describe the problem with as much accuracy and non-confusing terminology as possible, especially if it is not easy to reproduce. Describing problems like "it crashes" or "I get strange interrupt issues on this one box that I built", are of no use. Communicate with others (on the mailing lists, or any other forum where knowledgeable users congregate) to confirm that the problem is new and preferably repeatable. Please try to make sure it is not a local problem created by broken/unsupported hardware, or by using unsupported build options or software. Please don't start fixing problems that require significant work until you are sure you understand them, especially during our release periods when we must not change major sections of code. If you are going to write significant amounts of code, check various forums to make sure that someone else is not working on the problem (saving duplication of effort).
The following items should be contained in every bug report:

1. The exact sequence of steps from startup necessary to reproduce the problem. This should be self-contained; it is not enough to send in a bare command without the arguments and other data you supplied to it. If a bug requires a particular sequence of events, please list those. You are encouraged to minimize the size of your example, but this is not absolutely necessary. If the bug is reproducible, we'll find it either way.
2. The output you got. Please do not say that it "didn't work" or "failed". If there is an error message, show it, even if you don't understand it. If OpenBSD panics with a particular error, say which. If nothing at all happens, say so. Even if the result of your test case is a program crash or otherwise obvious it might not happen in our testing. The easiest thing is to copy the output from the terminal, if possible. Note: In case of fatal errors, the error message provided might not contain all the information available. In that case, also look at the output in the system log files, such as those stored in /var/log. Also, if you are dealing with an application that has its own log files, such as httpd, check for errors where it keeps its logs (in the case of httpd, this is /var/www/logs).
3. The OpenBSD kernel output. You can get this with the dmesg command, but it is possible that your dmesg output does not contain all the information that is captured in /var/run/dmesg.boot. If this is the case, include information from both. Please include this in all bug reports.
4. If you run third-party software which has to do with your bug, say so, including any subversion that software may have. If you are talking about a CVS or FTP snapshot, mention that, including its date and time.
5. A traceback from your kernel panic. If your kernel panic'ed, and you are at a ddb> prompt, then please provide the panic message, as well as the output of the trace and ps commands in your bug report as advised. If the machine hangs, try enabling sysctl ddb.console=1 prior to the hang and getting in DDB via Ctl+Alt+Esc on the keyboard (must be outside of X), or sending BREAK if using a serial console.
   If, for some reason, the panic message is not visible, you can get it again with the show panic command.
   This is essential whenever possible. Panic reports without panic message, traceback and ps output are useless.
   The output of show registers might be of interest as well. You might then want to reboot with boot dump so that a kernel image could be saved by savecore(8) for further post-mortem debugging as described in the crash(8) manpage.
6. If you're reporting a problem with the X Window System on an architecture that uses the X.Org server, please include the full /var/log/Xorg.0.log file in your report in addition to the dmesg.boot information.

Do not be afraid if your bug report becomes rather lengthy. That is a fact of life. It's better to report everything the first time than us having to squeeze the facts out of you. On the other hand, if your input files are huge, it is fair to ask first whether somebody is interested in looking into it.

[daemonfowl]

Thank you Jgimmi !
I read whatever you link to or abstract .. my problem is that I often fail to put what I read into effect to solve the issue as expected ..
would you like me to post /var/run/dmesg.boot ?
Is there a way to repair login.conf ? (by for instance substituting it with the fresh system's)

[jggimi]

If I seem to be a tape recording that loops over and over, telling you the same things again and again about your problems ... it is because I cannot tell from what you post here 1) which of your various computers you are posting about in any of your threads or if you just pick a thread at random to post to, 2) usually, I have no idea what you were attempting to do procedurally that may have caused or contributed to the problem, 3) what actual commands you used that first indicated a problem 4) what the output from the problem actually was, or 5) how much of my prior recommendations were followed, or not followed, or if they had anything to do with the particular problem of the moment you are posting about.

It is frustrating for me to try to help you. It must be much more frustrating for you to report an issue and get little or no help.

When you go to your browser to report a problem here, stop! Before typing anything, please, ask yourself:

1. Am I posting in the right thread?
2. What was I doing on this system just before I saw this problem?
3. Have I ever seen it before? If so, what was I doing then?
4. Do I have enough information to be able to describe the problem clearly?
5. Have I done any research to determine what might produce the error message or symptom I am seeing? If so, what did I find?
6. Which of my systems was it?
7. What do I need to tell forum readers about this problem, so that those who may not have read any of my other threads will understand this problem and perhaps be able to recreate it themselves?

After you type your post, BEFORE submitting it, ask yourself:

• If someone reads this who is unfamiliar with my systems, my forum threads, or me ... will they be able to help me?

If not, you have not provided enough information in your post, or you have posted in the wrong thread ... or both.
---


I have no idea why it appears that +CONTENTS files are being damaged, and now, /etc/login.conf. Well on login.conf, I have an idea. Just a guess. Again.

The few symptoms you have been able to describe, so far, do not indicate any sort of hardware problem could be the cause -- those data corruptions do not manifest like this.

You commented in one of your threads on file corruptions, that a restart of an upgrade, while running from the ramdisk kernel, could be a possible operational cause. I disagree. The script just unpacks tarballs with tar(1), and a restart would merely overlay the same files. The upgrade operation does not touch /var, and does not touch /etc at all.

Now you report a problem ... and I have no idea which of your systems it was, and it appears to be an entirely unrelated problem to the package database problem reported in this thread.

I'll guess once more. You mention sysmerge. Improper manual editing of login.conf from within sysmerge is probably the cause of your login.conf problem. I don't know this for sure, it, like most everything else I tell you about your problems, is either a wild or a slightly educated guess.

If this was caused by your edit of login.conf from within sysmerge ... to recover, all you needed was to boot the ramdisk kernel, which should have been already sitting on your boot disk, and restore /etc from the backup you should have made of it before running sysmerge. And, if you failed to take your own backup, you might still find it in the backup sysmerge made of it in /var/tmp.

You did not have to panic and purchase yet another disk drive. Extra disk drives are nice to have, but it was an unnecessary purchase.

[daemonfowl]

Hi jgimmi ! Thank you !
I'm terribly sorry for the methodological mess I make each time I report an issue ..
I'm not sure what else to say :-( ..
I have 3 disks :
0- kankushin (openbsd current+login problem and the old bash empty @name issue ) (500g)
1- volla (successfully upgraded openbsd current+ simple ratpoison line recurring when installing a package) (120g)
2- hangestu (fresh & clean OpenBSD current) (60g)
(I use three of them interchangeably on Acer Aspire 5610 - GENERIC.MP i386)

Improper manual editing of login.conf from within sysmerge

certainly yes .. when asked , I chose m then i .. and missed some (I don't recall how it happened) .. I then rebooted to face the mess .
I'll try restoring the backup from /var/tmp.
In all cases I don't regret having a 3rd disk .. in case I need it sometime .