1

I'm running Ubuntu 14.04 Trusty Tahr in a Microsoft Hyper-V virtual machine on Windows Server 2012 R2. I've stopped the VM, replaced an EXT4-formatted virtual disk volume (/dev/sdb) with a new (unformatted) disk volume and restarted the VM. I see the following messages:

Filesystem check or mount failed. A maintenance shell will now be started. CONTROL-D will terminate this shell and continue booting after re-trying filesystems. Any further errors will be ignored Give root password for maintenance (or type Control-D to continue):

Upon typing the root password, I see:

Segmentation Fault

I would like to determine which process has caused the segmentation fault and why. I am reproducing a issue that was brought to my attention and would like to provide an explanation for the segmentation fault. Is it a bug in Ubuntu 14.04? If so, is there a work-around? If there is a work-around, I would like to see it documented here.

Improve this question
3
  • If you remove or change drives and udev doesn't have a persistent rule, then the drive location (/dev/sd?) may have changed. Commented Jul 23, 2014 at 17:26
  • The device path (/dev/sdb) remains the same. The device is now associated with a new Hyper-V virtual hard disk. Commented Jul 23, 2014 at 19:43
  • The best work-around I have found so far is to attach a live distro to the DVD drive device and reboot the VM into the live distro, create a partition table, create and format a partition. Commented Jul 23, 2014 at 19:50

1 Answer 1

Reset to default
1

OP and I worked through this; see comments & chat for details. First, to find the problem process and location, this line in /etc/init/mountall-shell.conf

/sbin/sulogin

was changed to

/usr/bin/ltrace -S -f -o /root/sulogin-ltrace.log /bin/sulogin

Excerpt from log:

837 crypt("password", "x") = nil
837 strcmp(nil, "x" <no return ...>
837 --- SIGSEGV (Segmentation fault)

The log indicates that the segfault occurs in the following code in sulogin, where crypt is returning NULL.

if ((p = getpasswd(pwd->pw_passwd)) == NULL) break;
if (pwd->pw_passwd[0] == 0 ||
    strcmp(crypt(p, pwd->pw_passwd), pwd->pw_passwd) == 0)
        sushell(pwd);

Next question is, what's causing crypt to return NULL?

OP confirmed that the encrypted password really was x; the shadow entry for root was root:x:16273:0:99999:7:::. In a stock Ubuntu 14.04, root's encrypted password is !; OP had changed it to x awhile ago and this is the first time since then that he's had to use single-user mode.

sulogin has its own interpretation of special encrypted passwords. If it sees * or !, it lets the user in with no password. Anything else, it does some validity checking, but x sails right through, yet crypt doesn't like it (salt not long enough?) and returns NULL.

OP is going to file a bug report for sysvinit-utils; sulogin ought to handle a NULL return from crypt more gracefully.

Improve this answer
11
  • The last system call before the SIGSEGV is write(1, "\n", 1) = 1. Commented Jul 23, 2014 at 22:39
  • Can you tell which executable? Sulogin or a shell? Commented Jul 23, 2014 at 23:07
  • It would also be useful to see which files were accessed just before it died. Maybe a PAM module can't open a file. Commented Jul 23, 2014 at 23:14
  • It's /sbin/sulogin. I wish I could paste the entire log here, but I'm limited to a few hundred characters and cannot insert newlines. The last two system calls were ioctl(0, ...) and write(1, ...). Commented Jul 24, 2014 at 16:07
  • I added an ltrace command to my answer. Can you try that? It will log the library calls. Commented Jul 24, 2014 at 16:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.