On Monday 29 October 2012 06:41 PM, Dennis Leeuw wrote: >>> >> Where is the patch? I can't see it in the email. > > The patch is incorporated in the attached umountiscsi.sh script. See > the if statement under the : > > for BLOCK_FILE in $SESSION_DIR/target*/*\:*/block/*; do > > line.
No. Please send diffs of the file. Use the diff command on the original
and the modified file. It is easier to read.
>
>>
>>> Due to the fact that our system does not receive block devices from
>>> the iSCSI target, but it is logged in,
>>> this means the the BLOCK_FILE contains the search string,
>>> since/block/ does not exist. It then tries to umount
>>> everything, making the entire system read-only:(
>>>
>>> With the change I made in umountiscsi.sh this is not happening anymore.
>> I can't buy that statement. umountiscsi.sh does not do a remount in
>> read-only mode. Typically, the file system is re-mounted read-only,
>> only when it senses that the underneath block device is mis-behaving.
>>
>> What is your block device underneath the / file system? Is it a local
>> disk?
>
> umountscsi.sh sets BLOCK_DEV to * after the if-statement I added, so
> it does umount *, and due to the fact that we have set remount ro on
> errors, it gets remounted ro is what I expect.
No. Attempting to umount /, while it is mounted with errors=remount-ro,
does not trigger an event to remount it with flag 'ro'. You cannot
umount / because it will always be busy. You can re-mount it read-only
manually, but that is a different story.
20:10:46 root@debian-x64:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/mapper/debian--x64-root / ext3 errors=remount-ro
0 1
# /boot was on /dev/vda1 during installation
UUID=baf61a3c-6af3-40c4-9430-6f252f6042ac /boot ext2
defaults 0 2
/dev/mapper/debian--x64-swap_1 none swap sw
0 0
# /dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/cdrom /media/cdrom0 udf,iso9660 user,noauto 0 0
192.168.122.1:/var/tmp/nfs /var/tmp/nfs nfs
_netdev,auto,soft,intr 0 0
tmpfs /tmp tmpfs auto 0 0
20:10:51 root@debian-x64:~# umount /
umount: /: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
20:10:53 root@debian-x64:~# mount
/dev/mapper/debian--x64-root on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs
(rw,nosuid,size=5242880,mode=755,size=5242880,mode=755)
tmpfs on /run type tmpfs
(rw,noexec,nosuid,size=10%,mode=755,size=10%,mode=755)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=20%,mode=1777)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /run/shm type tmpfs
(rw,nosuid,nodev,size=20%,mode=1777,size=20%,mode=1777)
devpts on /dev/pts type devpts
(rw,noexec,nosuid,gid=5,mode=620,gid=5,mode=620)
/dev/vda1 on /boot type ext2 (rw)
192.168.122.1:/var/tmp/nfs on /var/tmp/nfs type nfs
(rw,soft,intr,addr=192.168.122.1)
configfs on /sys/kernel/config type configfs (rw)
20:10:59 root@debian-x64:~# touch /test
20:11:04 root@debian-x64:~# file /test
/test: empty
>
> To answer your question: the block device is indeed a local disk.
If your / goes read-only, it is your local block device at fault. Could
be a hardware problem, or else, a bug in the kernel. You should check
the kernel logs.
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
signature.asc
Description: OpenPGP digital signature
