i am using Zorin OS 16.3Core
Let's test:
sudo add-apt-repository ppa:tuxinvader/lts-mainline
sudo apt update && sudo apt install linux-generic-6.03
Reboot in order to boot into the later kernel.
Then use your computer normally and observe to see if there is a difference the next time you perform a shutdown.
Unfortunately there is no change
This bug was happen to me too, everyday for years now, since Zorin OS 16. And no solution still.
And I believe it's happen because secure boot is "on" on my laptop bios and I'm currently cannot change that option to "off". Or may be I'm wrong?
Do you get a complete shutdown after issuing sudo init 0?
Also, what make / model of machine are you using? There may be some quirks related that may point to an issue.
Safe boot is closed for me and the problem still exists
1 Like
No I didn't, my laptop model is HP ZBook 15 G2
edited adding quote
Hem... so may be Zorin OS 17 will fix this? or...
But, I don't have time to doing an upgrade, at least for next 4 months.
If you have plan to upgrade to 17, please ping me if this problem was fixed.
Can you specify what 'closed' means?
I updated to zorin os 17 and the problem still exists
1 Like
I mean I've turned it off before
1 Like
Assuming you use the power button or the menu buttons to initiate shutdown, what if you type shutdown in terminal? Does it reboot then?
If you use the physical power button, can you check what behavior is assigned to the power button in your settings window? I believe it's in power settings. Could be that it's set to sleep/hibernate, rather than shut down, so it would appear to reboot but really it's waking up?
Do you have something called "Fast Startup" enabled? Should be a BIOS option if so.
Note, "Fast Startup" is a Windows setting, wheras "Secure Boot" is a BIOS setting.
1 Like
This is true; there is a confusion wrinkle, however. There is a Fast Boot option included in many BIOS settings these days, as well.
2 Likes
I found the Fast Startup option in the BIOS, closed it, and tried again, but it didn't work
If you do a search here on the form using "could not resolve symbol", you will find several threads where this is reported, including:
Is this possible to solve the problem of restarting the device after shutting it down?
Apologies that your questions have not been answered yet, and, did not previously clarify in my poorly-worded question that I was referring to the BIOS option that some people do have (like myself).
Unfortunately, if that didn't work, perhaps investigate a copy/write problem, as alluded to, albeit very briefly, by another here on the forum.
In order of easiest and least-impactful check, to most difficult/impactful; below are some questions and suggestions you might consider:
- When this problem presented itself, and prior to your first attempted shutdown, did you happen to notice the machine go to sleep first?
- Did you find a black screen where you expected the login screen after power on?
- Were you in process of some large file operation or do you use a program that renders, converts or saves videos, or other media files, and saves them in a location you're not tracking closely? Such as a temp storage location, etc...?
- Did you try pressing the
Deletekey during your failed boots to display any other potential items of concern that may/may not be related to the errors you were seeing? If so, can you judiciously (code block or pastebin, etc.) post this information in reply for a leisurely weekend review by the big-brains here? This could really help pinpoint the problem. Another method is to just check your logs, but usingDeleteduring boot shows info/warn/fatal errors and other amplifying info real-time and you can see the kill-chain of processes before the fatal error. - Did you maybe re-map your power button key, or change the keystroke for reboot? Have you checked
dconf editorfor search terms related to key words such as "power", "reboot", or "hotkey"? Can you tell us what they are?
Recommend booting from Live CD and checking your disk space with Disks and/or GParted (recommend both). Look for your disk in question (likely the boot device) and see if it is out of space. Recommend doing this for each disk/partition that you can mount.
You could also use terminal with:
lsblk -e7 -o name,label,size,fstype,fsuse%,mountpoint. This just returns a tabular output showing the specified information for each block device (disk) on your system.
...and/or...
du <place_holder> -h 2>/dev/null | grep '^\s*[0-9\.]\+G' for an estimation of disk space usage for the specified disk, partition, directory or file in a human-readable format while any error messages are suppressed, and filtered output to show only lines representing sizes in gigabytes.
In the second command, you would need to replace <place_holder> with the actual mounting point of the disk you are investigating. e.g. /dev/sda... Or /dev/nvme....
But what about...
The reason I mention the space issues despite your post about starting Windows up just fine, is because Windows permissions may be set up correctly. Windows may require less space overhead in comparison to whichever process is causing ZOS to error-out.
-
- Okay... But what if you heard of space issues before and those issues were preventing the machine from even booting in the first place, let alone boot with a failed reboot. Consider that a reboot generally requires more memory than a shutdown.
During a reboot:
-
-
- The operating system needs to close and reopen system services and processes, which requires memory and some storage.
-
-
-
- Some system components may need to be reinitialized or loaded into memory again. Perhaps you have a system component which does not have write access?
-
-
-
- With kernels having been mentioned previously, it could be worth adding that the kernel may need to reload certain modules or drivers. Maybe yours cannot?
-
In contrast, during a shutdown:
-
-
- The operating system closes all processes and services gracefully, freeing up memory.
-
-
-
- System resources are released, and the system enters a powered-off state... Without rebooting!
-
During the shutdown and reboot process, the operating system would typically perform various tasks that involve writing to the disk, such as flushing file system buffers, updating system logs, or saving system state information. What if these operations fail because the OS cannot appropriately access disks, partitions, directories or files as needed?
In other words, reboots can use some storage to bring it back up to a login state, but reboots are meant to close files and shut down the system without leaving behind unnecessary data... if it works normally. If it doesn't, you may have an issue with unnecessary data having been detected upon reboot - such as corrupted data caused by incomplete or forced reboot or shutdown, or a temporary directory which is typically cleared up on reboot. But wasn't. If you or the root user do not have requisite permission to access and/or delete; then this could be the cause - because there was not enough storage to store or replace a file when reboot is initiated. Just a guess though...
An important distinction is that while your ZOS operating system's actual reboot process is running, storage is used. But, when the process is initiated by you, that doesn't necessarily mean that it would require storage; it would really only need an active CPU to follow through with the direction you gave it to reboot. Then it (the OS) tries to follow the directions (requiring storage), without success.
It would also be good to remember that while the idea regarding faulty permissions setup might be related to storage availability, they aren't mutually exclusive - and they can both cause various issues and happen separate from each other. They can also represent a small cascading fault where one of your issues (permissions) causes another (low storage). Just have to shift perspective a bit.
As some last hail Mary thoughts:
-
When your initial attempts at shutdown happened, are you long-pressing a physical power button for a hard shutdown, and subsequent cold reboot, with the same key? Is there a chance you did this (perhaps too quickly or during sleep or reboot) and interrupted a process as described further above, leaving data in an inconsistent state? If possible, then, are there any logs from the reboot that happened nearest the time you discovered the problem?
-
On a similar token, do you know if your logs are being rotated on a regular basis properly? If your computer never deletes or overwrites previous logs after a very long time, disk space fills up, especially so if you have many errors. If you have been trying to figure this out for an extended period of time and many reboots, and with the same, more, or even less errors (which will be in a log file most likely); your machine may never (or rarely) rotates its logs. Hint: see above in this post about logs updating during reboot.
-
Finally, in your troubleshooting, you may find that you don't have permissions set up properly and you/user don't have access to "Write" or "Copy" (which is basically another form of the "Write" function. Another key takeaway is that the "Overwrite" function is also, you guessed it, a form of the "Write" function. If such a condition exists, you may consider following that rabbit hole by searching for, or creating, another post related to your disk's write permissions. Think of it as running out of room on the last page of your legal pad and you're broke, and thus not able to obtain additional space to write your story. Imagine you can't erase it and/or write the continuation starting at the beginning - further perpetuating your "no space" (and broke) issue because now, you can't sell the story or continue where you left off. This is definitely a standing issue with some OSs and there are definitely ways to fix this, I know, as I've seen the posts myself - just can't remember where for the life of me and I'm also a bit tired and a bit inebriated to sewrch.
Anyway, hopefully looking in Disk (at the very least) allows you an opportunity for Root Cause Analysis and problem identification, whether it ends up being with storage, or not. The point here is that you'd be surprised about what happens in the background even while idle, so there's a small chance you didn't notice your drive filling up as quickly as it may have.
I sincerely hope this helps and we're cooking with fire again!
That's my fault for not paying attention to the verbiage with the "startup" vs. "boot". Apologies all for the confusion this caused ...