[SOLVED] Reboot without properly unmounting after install
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
While playing with -Current, I noticed that after the install and when given the option to reboot, the system pretty much almost instantly reboots, which begs the question - does the newly formatted partitions even get properly unmounted? It seems not because when I boot into the new system, JFS runs fsck, and also the kernel complains that the vfat partition (EFI), is now dirty because it was not properly unmounted. So, has anyone else noticed this? Can anyone else duplicate this, and shouldn't the installer unmount the newly created partitions after the install? I thought at one point Slackware has already done this, but now I am not so sure.
Generally I see this error when I am using a dualboot system with Win10 and Win10 failed to "unmount" it's partitions correctly. This usually relates to either a forced shutdown of Windows or it's "fake shutdown" that it has enabled by default. Easiest solution here is to just not boot into Windows what-so-ever, so that's generally the route I take
In theory, any other OS which also had that partition mounted and failed to shut down correctly could cause such an issue as well.
This is not a dual boot, it is just a VM. I will also create another Slackware Current VM (Non EFI), just to see what happens, but I am fairly certain I am correct in that after the install and you say yes to reboot, it just restarts the system without any sort of delay which to me suggests the filesystem (whatever it may be, ext*, JFS, etc) are not properly unmounted - though thats my hypothesis, I plan to retry when I have more time to confirm this or debunk this; but again if anyone else wants to try that would be great, as another pair of eyes would be appreciated on this.
I noticed the same behavior on two new slackware-current installs. When you log in as root after the first reboot, just
'umount /dev/sda1' (usually the EFI partition), 'fsck /dev/sda1', 'mount /dev/sda1'. Thereafter, it will umount cleanly with the rest of the mounts during reboot or shutdown. The problem is that the "dirty bit" doesn't get cleaned after setup installs efibootmgr on the EFI partition. No data corruption, safe to ignore. Initrd will fsck it next reboot.
I haven't retried EFI, this time though using mostly ext4 (XFS for home still), and I am sure that this is proving my theory, it is still not unmounting all fileystems, particularly the / partition, I even tried umount -f prior to rebooting but it refuses (getting fs busy).
Back to EFI, sure you could boot into Windows to maybe repair the EFI partition, but I don't have Windows anymore (or just ignore the error if you don't have OCD), but I also tried fsck.vfat the EFI partition and just got a seek error. I am also having a sense of Déjà vu here as I feel I have made a post about this before, oh well. Still I am fairly confident in my findings; whether or not it warrants any response from BDFL though, who knows - it is just my observations.
it is still not unmounting all fileystems, particularly the / partition, I even tried umount -f prior to rebooting but it refuses (getting fs busy).
The / partition cannot be UNmounted (it is first mounted by the kernel itself, to get to the init process, not by any mount command) as shutdown itself is running FROM it.
On an installer that shouldn't matter as / is in a ram fs anyway and so after reboot will not be there anymore (the physical disks are NOT mounted on / then).
IN Slackware rc.6 does this:
The / partition cannot be UNmounted (it is first mounted by the kernel itself, to get to the init process, not by any mount command) as shutdown itself is running FROM it.
On an installer that shouldn't matter as / is in a ram fs anyway and so after reboot will not be there anymore (the physical disks are NOT mounted on / then).
IN Slackware rc.6 does this:
before halting or rebooting.
That suggests that Slackware never unmounted a filesystem post install, and issued the reboot command which I am not so sure. Plus AFAIK other distros have from what I have seen properly unmounted filesystems prior to reboot after install.
Under EFI, I tried syncing but still would not let me unmount although this time I was able to run fsck on the EFI partition and repair it. Still at this point I think I have proven that the installer does not unmount partitions post install prior to reboot - I take it there is no way to remedy this though?
Still at this point I think I have proven that the installer does not unmount partitions post install prior to reboot
No. All not yet unmounted filesystems but proc are unmounted by this command in /etc/inittab in the installer, executed just before rebooting or halting it:
Code:
::shutdown:/bin/umount -a -r >/dev/null 2>&1
Last edited by Didier Spaier; 01-13-2020 at 02:38 PM.
No. All not yet unmounted filesystems but proc are unmounted by this command in /etc/inittab in the installer, executed just before rebooting or halting it:
Code:
::shutdown:/bin/umount -a -r >/dev/null 2>&1
Well... that's how it used to work, but the behavior of busybox's "reboot" changed at some point. The first symptom was that reboot simply quit working. It was replaced with a shell script that added the -f option, and that led to a fast reboot without unmounting (possibly without syncing).
The last installer rebuild fixed all this, and it should be working now. Jeebizz got a thanks in source/installer/ChangeLog.txt for it.
Thanks again! If there's still a problem, let me know.
Well... that's how it used to work, but the behavior of busybox's "reboot" changed at some point. The first symptom was that reboot simply quit working. It was replaced with a shell script that added the -f option, and that led to a fast reboot without unmounting (possibly without syncing).
The last installer rebuild fixed all this, and it should be working now. Jeebizz got a thanks in source/installer/ChangeLog.txt for it.
Thanks again! If there's still a problem, let me know.
So it is ready to test? The installer source is updated but I don't see anything on the changelog itself (main changelog)
Also does it handle all conditions (that I can think of)
Selecting Yes to reboot on the Installer menu
Selecting No to reboot, being dropped in prompt and issuing reboot command
Selecting No to reboot, being dropped in prompt and issuing ctr+alt+del keystroke
Sun Jan 12 20:36:57 UTC 2020
/sbin/reboot: Attempt to kill running processes and sync/umount/sync
filesystems before rebooting. Thanks to Jeebizz.
+--------------------------+
Last edited by Didier Spaier; 01-15-2020 at 04:18 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.