This bug was fixed in the package mountall - 2.13
---
mountall (2.13) lucid; urgency=low
[ Scott James Remnant ]
* Once a mountpoint has been skipped, don't try and mount it again
(unless the udev device actually shows up). LP: #553290.
* Skipping a filesystem means we shou
Anyway, the good news seems to be that the fix for *this* bug can be
safely uploaded now - it's only the fix for bug #559761 that appears to
need more work.
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bugs/553290
You received this bug notification because you ar
fsck ran, then exited successfully.
Sorry, it seems the (current) problem may be with the
ply_boot_client_flush() call. Backtrace:
(gdb) thread apply all bt full
Thread 1 (Thread 0x7f20eb6aa700 (LWP 357)):
#0 0x7f20eac3c920 in __read_nocancel () from /lib/libpthread.so.0
No symbol table in
On Sat, 2010-04-17 at 06:57 +, Steve Langasek wrote:
> Similar results again, mountall waits forever for /home even though it's
> clearly available. New mountall debug log attached.
>
The log indicates that fsck is running? Is it?
Scott
--
Scott James Remnant
sc...@ubuntu.com
--
Loops o
On Sat, 2010-04-17 at 08:31 +, Steve Langasek wrote:
> I think there's a race condition in spawn() in mountall - AFAICS,
> there's nothing in the code that ensures spawn_child_handler is
> registered as a signal handler before calling execve(), so if fsck exits
> very fast, mountall may miss t
Scott,
I think there's a race condition in spawn() in mountall - AFAICS,
there's nothing in the code that ensures spawn_child_handler is
registered as a signal handler before calling execve(), so if fsck exits
very fast, mountall may miss the signal that the child process has
exited since it's pas
Similar results again, mountall waits forever for /home even though it's
clearly available. New mountall debug log attached.
FWIW, it seems that when I touch /forcefsck, this problem does *not*
happen.
** Attachment added: "mountall.log"
http://launchpadlibrarian.net/44552813/mountall.log
--
I've uploaded a new version of mountall (2.13~ppa1) to
https://launchpad.net/~scott/+archive/ppa
Please test and see whether it solves this problem
Thanks
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bugs/553290
You received this bug notification because you ar
Aha, I see the problem!
- if (mnt->tag != TAG_SKIPPED)
- all = FALSE;
should be:
- if (mnt->tag != TAG_SKIPPED)
- all = FALSE;
+
Steve: your log simply says that udev never issued an event for your
/home
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bugs/553290
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
Paul, that simply isn't true.
Note that plymouth is not the same as having a splash screen - server
installs use plymouth (for boot logging, and generally for multiplexing
of console I/O during boot), but they configure it not to display a
splash screen.
--
Loops on mount failure when Plymouth n
It's not a question of having /removed/ plymouth... server installs
don't get plymouth installed in the first place!
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bugs/553290
You received this bug notification because you are a member of Ubuntu
Bugs, which is subs
mountall --debug log attached.
** Attachment added: "mountall.log"
http://launchpadlibrarian.net/44420621/mountall.log
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bugs/553290
You received this bug notification because you are a member of Ubuntu
Bugs, which i
Oh, when plymouth is running is certainly not intended.
When plymouth isn't running - I'd expect it to not mount any filesystem
that took too long
Can you get --debug from the machines where you reproduced please
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bug
(reproduced on two separate machines - the simpler case had just a / and
a /home and still hit the problem)
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bugs/553290
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
It caused mountall to not mount any of my filesystems, particularly when
plymouth was running.
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bugs/553290
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Steve: to confirm, it caused mountall to never mount any of your
filesystems even if plymouth was running?
Or just when Plymouth isn't running?
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bugs/553290
You received this bug notification because you are a member o
Scott,
I've had to back out your proposed fix for this - in my testing, it
causes mountall to never mount *any* of my filesystems, except for the
rootfs and virtual filesystems. So something needs more investigation
here; in the meantime, I'm getting 2.12 uploaded with the i18n fixes.
** Changed
** Changed in: mountall (Ubuntu Lucid)
Status: Triaged => Fix Committed
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bugs/553290
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mai
** Changed in: mountall (Ubuntu)
Assignee: (unassigned) => Scott James Remnant (scott)
** Also affects: mountall (Ubuntu Lucid)
Importance: Medium
Assignee: Scott James Remnant (scott)
Status: Incomplete
** Changed in: mountall (Ubuntu Lucid)
Milestone: None => ubuntu-10.0
Mount all should not depend on Plymouth, but should detect if it is
running and us it if it is available.
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net/bugs/553290
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
I would desire so much to see Plymouth decoupled from mountall.
This Plymouth thing (together with usplash, rhgb and similar stuff) just
reminds me a Soviet joke, "let's draw the curtains over windows and swing the
train carriage from the outside so that passengers thought they are actually
roll
Yeah, it blocks consistently on boot, but the ctrl + alt + del
workaround works. Don't want to take this bug off on a tangent though,
so if you want to have this focused just on the looping behaviour that's
fine by me.
--
Loops on mount failure when Plymouth not running
https://bugs.launchpad.net
On Thu, 2010-04-01 at 18:03 +, Reuben Firmin wrote:
> I'm having trouble reproducing the looping behaviour, even after having
> restored the usbfs to my fstab. I have cleaned up some udev configs
> since then...any chance those were interacting with this line in fstab?
>
No, but it may have b
I'm having trouble reproducing the looping behaviour, even after having
restored the usbfs to my fstab. I have cleaned up some udev configs
since then...any chance those were interacting with this line in fstab?
On the boot being frozen: after filing this report, I discovered the
workaround in #54
Part of the bug here is that even after skipping a filesystem, mountall
will try and mount it again whenever it can - that's why you see the
loop - that was right at the time - but now it's just wrong - a skipped
filesystem should be ignored entirely.
But that still doesn't explain why it stops bo
26 matches
Mail list logo
