1) I added 4 echo statements to each script in mountall.conf and can now say with no doubt that the main script runs once, and the post-stop script runs twice. I don't know how this can happen, but it does.
2) I added echo statements to both scripts in mountall-shell.conf too, also changing "console owner" to "console output" and commented out the su login. None of these were echoed - this is not running. (It was the only mountall restart I could find, so I was suspicious - I figured maybe the console grab failed and it skipped straight to the post-stop script. Anyway, it isn't happening). 3) My hunch was that maybe mountall or plymouth has trouble with a serial console. So, I carted my monitor, keyboard and mouse into the server room, and edited my kernel line on boot from quiet console=tty0 console=ttyS1,115200n8 to quiet console=ttyS1,115200n8 console=tty0 I also tried no console terms at all. The documentation I've read said that only the last console term is the one that is tied to /dev/console. I compared the boot messages on tty0 (captured by video camera) to those in /var/log/boot.log to those on serial console if applicable. This test was somewhat inconclusive. The serial console is now missing so many boot messages it's difficult to conclude anything from it. The tty0 console suffers a blank screen a fraction of a second into the boot, in which there probably is not time for a 2nd set of fscks to run. It then hung, in both cases, at the start of the dsm_sa_datamgr32d before going directly to pretty gnome screens. The hang was long enough that there might be time for it to run a 2nd set of fscks - maybe not - hard to say. Given that this is where it sometime starts the 2nd set over serial console, I don't think I can conclude much. /var/log/boot.log only contains the 2nd page of tty0 messages, up to the hang point. 4) I removed monitor, keyboard & mouse and booted again over serial console using my unedited kernel line.... and it worked!!!! Only one set of fscks. I've attached boot_worked to this post. I figure there were two unusual things about this boot: A) the last shutdown didn't have a serial console connected. B) this boot decided to force a test on /var, because it's count was up. I figure if it CAN work on serial console, that's a big clue. Though maybe that's only if it doesn't try to interact with it. I think this result also suggests timing is an issue. Note also the Starting dsm_sa_datamgr32d: Already started * lines in the boot log. At one point I thought this meant two /etc/init.d/rc jobs were competing. I think that may still be possible (with the 2nd doing nothing because it's going to the same runlevel as the first), but this message clearly proves nothing since it gets printed when mountall works. 5) Odd things happening to console messages at the dsm_sa_datamgr32d jobs is something I get on shutdown too. I think it may be a plymouth timeout issue. I'll post a separate bug report for that. Note that I don't think that's the cause of the double fsck problem : often that occurs and is done with before the boot ever gets to dsm_sa_datamgr32d. I think I'm giving up on this bug now. Over to you guys. ** Attachment added: "boot_worked" http://launchpadlibrarian.net/52048176/boot_worked -- mountall does everything twice https://bugs.launchpad.net/bugs/605687 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
