Dennis Wicks wrote: > No, that is not what I have been doing! Systems are connected by 100 > Mbps network. > System "B" is the one that has the problems. System "A" is the one > that is fully functional. "B" root volume is defined as a Samba > share. It is the entire volume/disk. That share is mounted on system > "A" on the mount point /dgwicks/root.
SMB mounts do not have POSIX filesystem capabilities. It won't work.
File permissions can't be set properly. I don't think file locks work
either.
> ("dgwicks" is the system/network name of system "B".)
> On system "A" I did a
> chroot /dgwicks/root dpkg -i /fix-sys/??.deb
> and immediately got a segmentation fault.
If if you were using an actual disk mount you would get the same
segfault. Using the chroot is no different than running the command
on the system normally. Since the normal system is segfaulting then I
expect the chroot to segfault. There is no difference. It isn't
related to being a network mount (either SMB or otherwise) but simply
that the libc or whatever is broken and therefore everything that uses
it is going to be broken.
> When I tried dpkg root=/dgwicks/root -i /fix-sys/??.deb it failed
> because it couldn't write on the mounted "B" root partition/drive.
The dpkg --root was suggested because it does not use the libc and
other libraries from the root area. It uses the libc from the host
system and then manipulates files in the specified root directory.
That is why it had the potential to work successfully even if
libraries were corrupted in the system area. That is what made it a
good suggestion. (But that was before you told us you were using an
SMB network mount. Until then we thought it was a normal disk mount.
Using the SMB network mount changed everything.)
But the dpkg --root option I really don't think can work because of
the SMB mount since SMB mounts do not have the same concepts as Unix
filesystems and permissions cannot be set and files cannot be locked.
I wouldn't try that anymore since it can't work.
> >I often have the case off and disks just hanging off the side while
> >doing these types of repairs. It doesn't have to fit in the case. It
> >just has to be able to connected. After repairing then return to
> >normal.
>
> Yes, that is my problem. No more places to plug in drives. I can
> handle the power with a "Y" cable, but I don't think they make "Y"
> cables for IDE cables. Darn! ;-)
IDE supports two drives, one master and one slave, per cable.
Since the problem is very likely libc or something I would try one
last effort to find the munged library file. But I think in the end
you are going to need to reboot the system and use another to repair
it. I think it is probably past the point of being able to repair
itself.
> >>I'll probably wind up having to use a live CD of some flavor. Any
> >>preferences??
> >
> >I think the Debian CD#1 is a good disk to use. It has a recovery
> >option to give you a working system with your root directory mounted.
> >But a live-cd disk is also very helpful.
> >
> > http://live.debian.net/
Also note that all of the new images are also bootable as a USB
image. It doesn't need to be a physical spinning cdrom anymore.
These days you can copy the image to usb storage media and then boot
from the usb. That can sometimes be a lot easier.
Bob
signature.asc
Description: Digital signature
