When posting a problem please give as much information about the problem as you can. At the very least some system specs would be nice. Perhaps putting your system specs in your signature would be a good idea. I saw in another thread that you are running an old system with a savage graphics card, but now you mention passing an efi parameter to the kernel, so I am confused as to what system you are talking about in this thread. Knowing at least the age of the machine can help a lot in trouble shooting. Right now I have very little insight to work with.
I am a little confused by what you say you pass to the kernel. Is it reboot=acpi or reboot=efi? You say that passing reboot=efi to the kernel allows you to "consistently" reboot. Does this not mean that your problem is resolved? Is there a problem with adding this to the porteus.cfg file in the boot folder and continuing to use Porteus?
I find your advice very cryptic ... I had thought you would have definite knowledge.
Nothing too cryptic about asking you to delete the directory. Simple and straight forward. The definitive answer is that you will be deleting the upper layer of a union file system branch that will give way to the underlying read only branch made up of the base Porteus modules which are know to be in good working order. This will allow you to boot your machine. Is there really any point in adding this technical knowledge to my reply?
Incomprehensibly, the thread was then marked as "SOLVED", even though Michele13 had just reported that Porteus wouldn't reboot and that she had found a solution (for herself) not requiring a different kernel.
The original poster clearly stated that her problem was solved. No point leaving an open thread if the OP will no longer participate because they no longer have the problem.
Fanthom's dismissive reply to the effect that Porteus' developers aren't responsible for problems with the kernel completely ignores the fact that the vast majority of users (i.e. end-users) have no idea what a kernel is and are completely reliant on the one developers chose -- as for the airy advice to try another, which?
If I know Fanthom, then his reply was the best he could offer at the time. If it was within his control I am certain he would have given MORE of his valuable free time, of which he volunteers without any return, to help resolve the issue. At the time of the release the Porteus kernel was known to work on the majority of hardware existing at the time. Newer computers emerge and the kernel no longer supports some hardware. In this case an update of the kernel is required.
We usually follow a slackware release schedule and as you may or may not know slackware has not released anything since the last porteus release. At present we (the Porteus community) are debating whether to move the base from slackware to a manjaro rolling release base.
Please reopen Michele13's bug thread from a year ago -- the bug that prevents Porteus from rebooting has not been resolved, nor is it restricted to x86 machines, nor can it be blamed solely on the kernel (since it can be resolved without changing the kernel).
Sorry, I'm not going to open an old closed thread that was clearly marked as solved based on the reply of the OP. You allude to that in the quote above when you say "since it can be resolved without changing the kernel". You have started a new thread (this one) where the problem can be investigated further if you so choose.
What is the point of all the work on an easy-to-use, GUI-based OS if its developers won't acknowledge so significant a bug or fix it?
Bug acknowledged. As I stated above, fixing it requires releasing a new porteus. We are at a crossroad at the moment so a new slackware based Porteus may be some time. I am not sure if you intended to be abrasive, but I find this comment rather gross and somewhat uninformed.
Where is this project going? Nemesis?
We already have a beta release of Nemesis
available which I suggest you try to see if the problem is in fact resolved with an updated kernel and packages.
What kernel do you expect to offer average users next?
4.4 LTS (as of today's date)
Is there a timetable for the next release?
At present I can't give a timetable. I am the sole developer of Porteus and until I decide which direction to take I don't want to put any dates out there. I am working hard everyday testing the beta version and also keeping the slackware version updated in the wings. All of this is done in my free time (read: 10pm-2am) so I would not expect a new release this month.
I cannot divine what I should do to get it to work on a new machine with no video other than to upgrade the kernel -- to something.
I suggest you try the nemesis release to see if the updated kernel and package base resolves your problem. If so then you can continue testing it and offering feedback until:
a) It matures and becomes our default
b) An updated slackware base is released.
Failing both of these options I would suggest finding a rolling release distro that can support your hardware and computing goals. If tinkering under the hood is not your thing then might I suggest Ubuntu?
MS has found the means to consistently reboot computers; I suggest that Porteus should too
Another somewhat abrasive comment. Well since you went there, that hasn't been my experience at all. Upgrading to Windows 10 for me was a prolonged and tortuous experience that resulted in a non-booting machine that now runs Porteus, which I have found to "consistently" reboot on 99% of our users' computers. You and Michele13 are the only users I know of that have had this problem. I would say those are pretty good odds. It's all relative.