[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /boot partition failing to mount


On 03/28/2017 05:30 AM, Jesse Talavera-Greenberg wrote:

However, the /boot partition (which uses ext3) is failing to mount

How does that manifest? What error message do you get? What are the contents
of your /etc/fstab?
Attached to this e-mail.  And the error's manifestation appeared in the logs I posted in my previous e-mail.  Specifically this part:
Mar 27 22:39:23 motherfscker systemd[1]: Mounting /boot...
Mar 27 22:39:23 motherfscker systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway.
Mar 27 22:39:23 motherfscker systemd[1]: Mounting /var...
Mar 27 22:39:23 motherfscker kernel: des_sparc64: sparc64 des opcodes not available.
Mar 27 22:39:23 motherfscker kernel: md5_sparc64: sparc64 md5 opcode not available.
Mar 27 22:39:23 motherfscker kernel: aes_sparc64: sparc64 aes opcodes not available.
Mar 27 22:39:23 motherfscker systemd[1]: boot.mount: Mount process exited, code=exited status=32
Mar 27 22:39:23 motherfscker systemd[1]: Failed to mount /boot.
Mar 27 22:39:23 motherfscker systemd[1]: Dependency failed for Local File Systems.
and I don't know why.  The weird thing is that I can mount it manually just fine,

How do you mount it manually? Have you compared it to what's in /etc/fstab?
I mount it through `mount /dev/sda1 /boot`.  That's about it.

though if I run systemctl default the console stops responding.

Did you actually read the manpage for systemctl to understand what "systemctl
default" does?

Quoting:

       default
           Enter default mode. This is mostly equivalent to isolate default.target.
and:
	"isolate" is only valid for start operations and causes all other units to
	be stopped when the specified unit is started. This mode is always used when
	the isolate command is used.

So, "systemctl default" on Debian effectively kills all units except for the ones
that are wanted by default.target. Don't run "systemctl default".

Probably the default.target should be reconfigured in Debian's systemd package
to avoid this problem.
I don't understand what this means, can you elaborate?  (I don't know very much about configuring Debian.)

That being said, after I manually mounted /boot I was able to SSH into the machine like nothing ever happened; it seems like the default Linux login prompt just wasn't showing up.  I think there's a boot parameter to that effect?  Now I'm confused.
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda4 during installation
UUID=d960869d-7b63-4268-9f8c-72c3dfc93195 /               ext4    errors=remount-ro 0       0
# /boot was on /dev/sda1 during installation
UUID=89462155-4731-47d7-a1f1-f8aeec62d8a5 /boot           ext3    defaults        0       0
# swap was on /dev/sda2 during installation
UUID=e8b3b596-9d7f-4586-9571-607d6b6e7376 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
UUID=807d518d-cd5d-46c5-b962-15708a32208c /usr ext4 defaults 0 0
UUID=f1a5980c-9e33-4926-9b77-377c540c2dd9 /var ext4 defaults 0 0
Reply to: