Package: libnfsidmap2
Version: 0.24-1
Severity: critical
...because /usr is an NFS mount!
Please move everything under /usr/lib to /lib.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On July 7, 2011 05:41:57 PM Steinar H. Gunderson wrote:
> found 633019 0.2.0-2
> thanks
>
> On Thu, Jul 07, 2011 at 03:27:25PM -0600, Bruce Sass wrote:
> > Since the lib resides under /usr/lib, and /usr on this box is an NFS
> > mount, mount.nfs fails during boot up and
Package: libgssglue1
Version: 0.3-1
Severity: critical
Justification: breaks the whole system
Since the lib resides under /usr/lib, and /usr on this box is an NFS mount,
mount.nfs fails during boot up and I am left without a /usr partition.
I have worked around the problem by booting with a rescu
Package: libtirpc1
Version: 0.2.2-3
Severity: critical
Justification: breaks the whole system
Since the lib resides under /usr/lib, and /usr on this box is an NFS mount,
mount.nfs fails during boot up and I am left without a /usr partition.
I have worked around the problem by booting with a rescu
[maybe I'm just naive wrt how the initramfs works ]
(initramfs) mount -o remount,rw /root
mount: can't read '/proc/mounts': no such file or directory
So I changed the "ro" kernel arg to "rw", booted, then created the symlink.
- Bruce
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.d
Package: libssl0.9.8
Version: 0.9.8g-16
Severity: critical
Justification: breaks the whole system
/usr on my "unstable" box is an NFS import.
When networking is being brought up /sbin/dhclient fails because it can't
find libcrypto.so.0.9.8--which lives under /usr/lib--consequently eth0
doesn't ap
severity 490640 important
tag 490640 confirmed
On Sun July 13 2008 03:59:43 am Andrew Ruthven wrote:
> Package: hplip
> Version: 2.8.6-1
> Severity: grave
> Justification: renders package unusable
I have downgraded the reportfrom grave to important because only
scanning is affected, although sca
On Thu May 15 2008 01:52:40 pm you wrote:
> On Thu, May 15, 2008, Bruce Sass wrote:
> > IMO, something is horribly broken if a PID file can disappear yet
> > the daemon is left running-
>
> Yes, but please assume that this horribly broken thing only happened
> with older
On Wed May 14 2008 01:36:10 pm you wrote:
> On Wed, May 14, 2008, Bruce Sass wrote:
> > > This bug is now closed with the new dpkg; could you upgrade and
> > > confirm you still have the hal bug?
> >
> > I can confirm the hal package fails to configure (via
>
On Mon May 12 2008 01:00:52 pm Loïc Minier wrote:
> On Mon, May 12, 2008, Bruce Sass wrote:
> > The exim Maintainer called it a
> > "heisenbug", see #396944, he also filed #440657 shortly after but I
> > don't know if it is related
On Sat May 10 2008 03:54:33 pm Loïc Minier wrote:
> On Sat, May 10, 2008, Bruce Sass wrote:
> > Most likely we are being bitten by a start-stop-daemon bug and you
> > may want to see how the exim Maintainer worked around the problem.
>
> Yes; there are many bugs in ssd in
Package: hal
Version: 0.5.11-1
Severity: critical
Justification: breaks unrelated software
...which causes dpkg to err out, halting the upgrade process. Since
neither dpkg or upgrading explicitly depends on hal, its failure is
breaking unrelated software/processes.
Investigation reveals that /var
Hi,
I've been having the `start failed' problem and after snooping around I
noticed there was no pidfile yet hald was running. After manually
stopping and starting hald (/etc/init.d/hal stop or start) then
rerunning dselect (to clear up the failed-config status, which failed)
I noticed the pid
On Thu July 19 2007 03:58:58 am I wrote:
> On Thu July 19 2007 03:01:30 am you wrote:
> > or try the patch in #433386 against initscripts.
>
> I'll give it a try, and I expect it will work because so far the only
> success I've had is with this hack:
> -
> --- /etc/init.d/portmap.orig20
On Thu July 19 2007 03:01:30 am you wrote:
> > I can manually start rpc.statd, then mount the missing nfs imports,
> > but since /usr was missing during the boot there is bound to be
> > stuff which didn't start properly. Is there a way to ensure
> > everything is in order besides manually discover
> Try setting ASYNCMOUNTNFS=no in /etc/default/rcS. I'm currently
> talking to the initscripts maintainers to try to find a good solution;
> it seems like the fix in 1:1.1.0-10 introduced a race condition.
This doesn't work for me, it kinda makes things worse because now the
messages telling m
16 matches
Mail list logo
