This install is about 6 months old i think. On Wed, Mar 29, 2017 at 9:21 AM, John Paul Adrian Glaubitz < [email protected]> wrote:
> Was that system recently installed? > > If the installation is older, you don't have a merged /usr yet as this is > an option to debootstrap which is run during installation. > > Adrian > > On Mar 29, 2017, at 9:14 AM, Kevin Stabel <[email protected]> wrote: > > From my system: > root@Noise ~# which mount > /bin/mount > > > On Wed, Mar 29, 2017 at 8:59 AM, John Paul Adrian Glaubitz < > [email protected]> wrote: > >> His problem could be the separate /usr partition which is no longer >> supported on modern Linux distributions because of the usr-merge. See his >> attached fstab. >> >> I'm not sure whether the mount command has been moved to /usr/bin yet >> though. If yes, this could explain the problem. >> >> Adrian >> >> On Mar 29, 2017, at 8:52 AM, Kevin Stabel <[email protected]> wrote: >> >> Hi Jesse, >> >> Wrong fs type in fstab? Is it ext3? >> Wrong label in fstab? Try replacing the UUID=etc etc with /dev/sda1 >> >> On Wed, Mar 29, 2017 at 2:35 AM, Jesse Talavera-Greenberg < >> [email protected]> wrote: >> >>> >>> 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. >>> >> >> >
