[Users] /dev/fd/3
Steve Hodges
shodges at iinet.net.au
Tue Aug 14 10:40:44 EDT 2007
*thank you*
The really strange thing is that I'm damn sure I had this working at
least once before. I wonder if I managed to snag a different version of
the template when I rebuilt the server?
Anyway, that's fixed now :-)
It still won't mount the dvd, but that's not a huge issue at present.
Steve
On 14/08/2007 7:30 PM, Matt Ayres wrote:
> 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
>> root at backup:/# 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
>> Users at openvz.org
>> https://openvz.org/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://openvz.org/mailman/listinfo/users
>
>
More information about the Users
mailing list