The same bug exists in Virtuozzo, "ln -s /proc/self/fd /dev/fd" appears
to be the fix.
Reference: http://www.tektonic.net/forum/showthread.php?t=1936
Steve Hodges wrote:
On 14/08/2007 1:58 AM, Gregor Mosheh wrote:
Or perhaps your VE has maxed out the number of FDs it's allowed to
have? Check the /proc/user_beancounters and see if anything there is
happening to shed light on whether the failure is VE-related.
Here is what I see, including the beancounters immediately after
Executing 'mkisofs -C 106736,113120 -M /dev/fd/3 -R -J -pad
-graft-points /2007-08-14__12-07-50=/home/archive/image | builtin_dd
of=/dev/hdc obs=32k seek=7070'
genisoimage: No such file or directory. Cannot open '/dev/fd/3'.
Cannot open SCSI driver.
genisoimage: No such file or directory. Unable to open previous
session image '/dev/fd/3'.
:-( mkisofs has failed: 2
***image written
***error writing to DVD. You may need another DVD
[EMAIL PROTECTED]:/# cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit
failcnt
111: kmemsize 509969 691152 2752512
2936012 0
lockedpages 0 8905 30000
30000 0
privvmpages 1778 18792 100000
200000 0
shmpages 0 0 8192
8192 0
dummy 0 0 0
0 0
numproc 10 14 65
65 0
physpages 1112 9981 0
2147483647 0
vmguarpages 0 0 6144
2147483647 0
oomguarpages 1112 9981 6144
2147483647 0
numtcpsock 3 3 80
80 0
numflock 1 2 100
110 0
numpty 1 1 16
16 0
numsiginfo 0 2 256
256 0
tcpsndbuf 0 0 319488
524288 0
tcprcvbuf 0 0 319488
524288 0
othersockbuf 2220 2904 132096
336896 0
dgramrcvbuf 0 0 132096
132096 0
numothersock 2 4 120
120 0
dcachesize 0 0 1048576
1097728 0
numfile 237 317 2048
2048 0
dummy 0 0 0
0 0
dummy 0 0 0
0 0
dummy 0 0 0
0 0
numiptent 10 10 128
128 0
the lines flagged with *** come from my script.
the relevant lines of the script are:
# create a path on the dvd
writedate=$(date +%Y-%m-%d__%H-%M-%S)
# burn files to dvd (either new or append) in timestamped directory
# might be a good idea to log this fact too.
err=
case "$dvdstatus" in
blank)
growisofs -Z /dev/hdc -R -J -pad -graft-points
"/${writedate}=${image}" || err=Y
;;
appendable)
growisofs -M /dev/hdc -R -J -pad -graft-points
"/${writedate}=${image}" || err=Y
;;
*)
echo Internal error deciding how to write to dvd
exit 1
;;
esac
echo image written
# if error then send email and ask for new dvd (reporting error too)
if [[ "$err" == "Y" ]]; then
echo error writing to DVD. You may need another DVD
eject
exit 1
fi
(clearly the script isn't complete yet :-)
I also find that whilst I have made /dev/hdc available to my VE, I
can't mount the cdrom. It tells me
mount: unknown filesystem type 'udf'
mount: unknown filesystem type 'iso9660'
For a CDROM, iso9660 is usually appropriate. Are you sure that that
module is already loaded in the hardware node? A lot of distros leave
iso9660 as a module and VEs cannot load kernel modules.
Do a "modprobe iso9660" in the HN, to ensure that the module is
loaded. Then try mounting the CD in the VE.
modprobe iso9660 seems to work on the hardware node, however lsmod |
grep iso shown only
isofs 21348 0
(which my googling suggests may actually me the right thing to see.)
nevertheless, I can
mount -t iso9660 /dev/hdc /media/cdrom0
whereapon I get
mount: block device /dev/hdc is write-protected, mounting read-only
and df, in part, reports
/dev/hdc 458 458 0 100% /media/cdrom0
/etc/fstab on the HN contains:
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
I then umount /dev/hdc and go into the ve (which has access to hdc via
vzctl set $1 --devnodes hdc:rw --save)
it's /etc/fstab looks like this:
# UNCONFIGURED FSTAB FOR BASE SYSTEM
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
if I do this:
mount -t iso9660 /dev/hdc /media/cdrom0
I get this:
mount: unknown filesystem type 'iso9660'
_______________________________________________
Users mailing list
[email protected]
https://openvz.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://openvz.org/mailman/listinfo/users
