Re: mounting Mac OS .dmg files?
Hi! On Mon, 24 de Noviembre de 2008, 12:19 am, Jiawei Ye wrote: On Mon, Nov 24, 2008 at 1:21 PM, Mike Meyer [EMAIL PROTECTED] wrote: --snip-- So while a Darwin (the OS underneath OSX) ABI would be possible - though it's not clear how painful because it's not clear how visible the MACH APIs are - it's not clear how useful it would be by itself. You could run OSX applications that used X11 for the GUI after building the appropriate libraries (just like Linux), but those apps are probably available native anyway. You couldn't run applications that use the various and sundry Mac-specific graphics (among other things) frameworks, not without providing code to simulate all the calls provided by those frameworks - which are proprietary, and not part of Darwin. Which means this project now resembles WINE more than the Linux ABI layer. mike One open-source project at least try to replicate the frameworks on top of Windows: http://www.cocotron.org/ As Mike mentioned this is not a trivial port and requires tweaks to the target application source as well. So even if one is diligent enough to get cocotron running on FreeBSD/Linux, the app itself will have to be modified to run there. Thank you for your answers. This list is always very educative. It seems like it could take years to program a Mac ABI layer. Best regards, B. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
Hi, On 22 Nov 2008, at 11:00, Christoph Kukulies wrote: Since the underlying OS of Mac OS is FreeBSD I'm wondering whether itr is possible to mount a .dmg file as it is used in Apple software distribution for the Mac OS. I would like to install an Apple iPhone configuration utility on my FreeBSD box (iPhoneConfigurationUtility.dmg). It consists of a web application that is supposedly capable of doing updates of Apple iPhones through a web service. (good for company wide distribution of address book information and other data that iPhones can hold). If you want to see what the package contains, try building dmg2img from here: http://vu1tur.eu.org/tools/ Use that to extract the HFS image from the package, then examine it one of the HFS tools from ports/emulators, But as others have mentioned, you may not be able to do much with the contents. -- Bob Bishop [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
On Sat, 22 Nov 2008, Erik Trulsson wrote: Which version of FreeBSD was used in OSX will almost certainly depend on which version of MacOS X you look at. It is quite possible that the latest version of OSX uses code from FreeBSD 5.x, but I guarantee that the first release of OSX did not. (This is easily seen from the fact the MacOS X 10.0 was first released in March 2001. The latest FreeBSD release at that time was 4.2 (released in November 2000.) FreeBSD 5.0 was not released until January 2003.) It would be accurate to describe Apple's approach to adopting FreeBSD changes as cherry-picking - their source code base is sufficiently diverged from ours that they basicaly pull our change on an as-needed basis rather than remaining strictly sync'd to a particular version. Many of you will have noticed that articles describing the recent SnowLeopard seed include mention of pulling the most recent OpenBSM and OpenPAM drops from FreeBSD into Mac OS X, as examples of recently integrated technologies from recent FreeBSD versions. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
On Sun, 23 de Noviembre de 2008, 5:22 am, Bob Bishop wrote: On 22 Nov 2008, at 11:00, Christoph Kukulies wrote: Since the underlying OS of Mac OS is FreeBSD I'm wondering whether itr is possible to mount a .dmg file as it is used in Apple software distribution for the Mac OS. I would like to install an Apple iPhone configuration utility on my FreeBSD box (iPhoneConfigurationUtility.dmg). It consists of a web application that is supposedly capable of doing updates of Apple iPhones through a web service. (good for company wide distribution of address book information and other data that iPhones can hold). ... But as others have mentioned, you may not be able to do much with the contents. I have an innocent question. I have read on the handbook and the thesis about the Linux ABI technical explanations that lead me to think that it could be possible to run Mac OS binaries on FreeBSD. I think that if the correct loader was implemented in execve and the Mac OS system calls were also implemented it would be possible to run Mac OS binaries. Am I right? (I am not asking anyone to support this feature, I just would like an hypothetic answer in order to improve my knowledge.) Of course, I suppose there would be technical challenges to solve as there are still for Linux. In fact, I would like to ask further: could this be possible for any operating system (without thinking about if it would worth it)? Best regards, Braulio Solano ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
On Sun, 23 Nov 2008 19:15:54 -0600 (CST) Braulio José Solano Rojas [EMAIL PROTECTED] wrote: I have an innocent question. I have read on the handbook and the thesis about the Linux ABI technical explanations that lead me to think that it could be possible to run Mac OS binaries on FreeBSD. I think that if the correct loader was implemented in execve and the Mac OS system calls were also implemented it would be possible to run Mac OS binaries. Am I right? (I am not asking anyone to support this feature, I just would like an hypothetic answer in order to improve my knowledge.) Of course, I suppose there would be technical challenges to solve as there are still for Linux. In fact, I would like to ask further: could this be possible for any operating system (without thinking about if it would worth it)? In theory, you can provide an ABI for any OS that you care to emulate the necessary calls for. In essence, that's what the WINE project is: emulation of all the Windows API's required to run Windows applications on a Unix/X11 platform. The thing is, an OS these days is more than just a set of system calls - it's a collection of shared libraries providing a complete user interface. That's why you have to install large chunks of a Linux system to run Linux binaries on FreeBSD - getting all the libraries down to the system call level needed by those binaries (and in some cases, you want GNU/Linux executable also, because the binaries expect to invoke executables from Linux, not BSD, and they are different enough to matter). Even then, the reason it works reasonably well for GNU/Linux with X is because the X server/client API use IPC mechanisms so you can get away with running a FreeBSD X11 server, letting the Linux applications use Linux client-side libraries, and just make sure the IPC calls are simulated properly (module hi-end graphics tools and other late additions). Other OSs don't have as clean a division between applications and the graphics subsystem, so you have to provide all the services the OS provides for talking to the graphics device as well. Linux gets another win here in that all the relevant libraries are open source; for proprietary systems, even if you could find a clean layer to switch platforms, you'd have to rewrite all those libraries above that layer from scratch anyway. Which is why WINE has to simulate all the Windows GUI calls using X11 code. So while a Darwin (the OS underneath OSX) ABI would be possible - though it's not clear how painful because it's not clear how visible the MACH APIs are - it's not clear how useful it would be by itself. You could run OSX applications that used X11 for the GUI after building the appropriate libraries (just like Linux), but those apps are probably available native anyway. You couldn't run applications that use the various and sundry Mac-specific graphics (among other things) frameworks, not without providing code to simulate all the calls provided by those frameworks - which are proprietary, and not part of Darwin. Which means this project now resembles WINE more than the Linux ABI layer. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
On Mon, Nov 24, 2008 at 1:21 PM, Mike Meyer [EMAIL PROTECTED] wrote: --snip-- So while a Darwin (the OS underneath OSX) ABI would be possible - though it's not clear how painful because it's not clear how visible the MACH APIs are - it's not clear how useful it would be by itself. You could run OSX applications that used X11 for the GUI after building the appropriate libraries (just like Linux), but those apps are probably available native anyway. You couldn't run applications that use the various and sundry Mac-specific graphics (among other things) frameworks, not without providing code to simulate all the calls provided by those frameworks - which are proprietary, and not part of Darwin. Which means this project now resembles WINE more than the Linux ABI layer. mike One open-source project at least try to replicate the frameworks on top of Windows: http://www.cocotron.org/ As Mike mentioned this is not a trivial port and requires tweaks to the target application source as well. So even if one is diligent enough to get cocotron running on FreeBSD/Linux, the app itself will have to be modified to run there. Cheers, Jiawei -- If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
On 11/22/08, Christoph Kukulies [EMAIL PROTECTED] wrote: Since the underlying OS of Mac OS is FreeBSD Wrong. I'm wondering whether itr is possible to mount a .dmg file as it is used in Apple software distribution for the Mac OS. I would like to install an Apple iPhone configuration utility on my FreeBSD box (iPhoneConfigurationUtility.dmg). It consists of a web application that is supposedly capable of doing updates of Apple iPhones through a web service. (good for company wide distribution of address book information and other data that iPhones can hold). Currently not always possible - depends which actual fs is stored in .dmg file. Some time ago there was utility in development which allowed mounting of hfs+ on FreeBSD. There is dmg2iso (but it is not in ports ) -- Paul ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
Christoph Kukulies [EMAIL PROTECTED] writes: Since the underlying OS of Mac OS is FreeBSD It isn't, as someone else pointed out, and hence... I'm wondering whether itr is possible to mount a .dmg file as it is used in Apple software distribution for the Mac OS. I would like to install an Apple iPhone configuration utility on my FreeBSD box (iPhoneConfigurationUtility.dmg). ...Mac OS applications won't run on FreeBSD, so there's no point in even trying. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
Dag-Erling Smørgrav schrieb: Christoph Kukulies [EMAIL PROTECTED] writes: Since the underlying OS of Mac OS is FreeBSD It isn't, as someone else pointed out, and hence... Always thought that at some point in time it was derived from an earlier version of FreeBSD (4.x) I'm wondering whether itr is possible to mount a .dmg file as it is used in Apple software distribution for the Mac OS. I would like to install an Apple iPhone configuration utility on my FreeBSD box (iPhoneConfigurationUtility.dmg). ...Mac OS applications won't run on FreeBSD, so there's no point in even trying. It may be some java stuff. I'm not sure though since I didn't peek into the dmg-file yet. DES Thanks anyway, Christoph ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
On Sat, Nov 22, 2008 at 03:01:44PM +0100, Christoph Kukulies wrote: Dag-Erling Smørgrav schrieb: Christoph Kukulies [EMAIL PROTECTED] writes: Since the underlying OS of Mac OS is FreeBSD It isn't, as someone else pointed out, and hence... Always thought that at some point in time it was derived from an earlier version of FreeBSD (4.x) Parts of it was derived from FreeBSD (mainly userland stuff.) Other parts of MacOS X (including the kernel) was mainly derived from Mach, and some parts were of course written by Apple themselves (or taken from other places.) So, even though it is in part derived from FreeBSD, you should not expect any sort of binary compatibility between them. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
Am 22.11.2008 um 15:01 schrieb Christoph Kukulies: I would like to install an Apple iPhone configuration utility on my FreeBSD box (iPhoneConfigurationUtility.dmg). ...Mac OS applications won't run on FreeBSD, so there's no point in even trying. It may be some java stuff. It is not. It's a Cocoa application. I'm not sure I am. Achim
Re: mounting Mac OS .dmg files?
Erik Trulsson [EMAIL PROTECTED] writes: Parts of it was derived from FreeBSD (mainly userland stuff.) Other parts of MacOS X (including the kernel) was mainly derived from Mach, and some parts were of course written by Apple themselves (or taken from other places.) You got it almost entirely wrong... There are significant amounts of FreeBSD code in the Mac OS X kernel (the network stack, the VFS layer, several file systems, access control, security auditing and more). Mach provides only IPC, scheduling and virtual memory, IIRC. The rest of the kernel (including all device drivers) is proprietary Apple code. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
On Sat, Nov 22, 2008 at 3:00 AM, Christoph Kukulies [EMAIL PROTECTED] wrote: Since the underlying OS of Mac OS is FreeBSD I'm wondering whether itr is possible to mount a .dmg file as it is used in Apple software distribution for the Mac OS. I would like to install an Apple iPhone configuration utility on my FreeBSD box (iPhoneConfigurationUtility.dmg). It consists of a web application that is supposedly capable of doing updates of Apple iPhones through a web service. (good for company wide distribution of address book information and other data that iPhones can hold). -- Christoph Kukulies As everyone else has pointed out, FreeBSD != OSX. I think that was the whole point of the Darwin logo (a platypus with Beastie's horns on it: http://docs.huihoo.com/darwin/images/hexley-2.png). If you watch the BSD is Dying presentation, you'll laugh when you see the reference to OSX as well: http://video.google.com/videoplay?docid=7833143728685685343 :). You have two choices: 1. Buy an Xserve loaded with OSX: http://shop.apple.com/ . 2. Compile and maintain your own copy of Apple's version of Darwin: http://opensource.apple.com/ . FYI, according to the Apple folks OSX is based off FreeBSD 5 (not sure which minor version): [Quote -- http://opensource.apple.com]: This fully-conformant UNIX operating system—built on Mach 3.0 and FreeBSD 5—bundles over a hundred of the most popular Open Source products. [/Quote] Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting Mac OS .dmg files?
On Sat, Nov 22, 2008 at 02:06:39PM -0800, Garrett Cooper wrote: On Sat, Nov 22, 2008 at 3:00 AM, Christoph Kukulies [EMAIL PROTECTED] wrote: Since the underlying OS of Mac OS is FreeBSD I'm wondering whether itr is possible to mount a .dmg file as it is used in Apple software distribution for the Mac OS. I would like to install an Apple iPhone configuration utility on my FreeBSD box (iPhoneConfigurationUtility.dmg). It consists of a web application that is supposedly capable of doing updates of Apple iPhones through a web service. (good for company wide distribution of address book information and other data that iPhones can hold). -- Christoph Kukulies As everyone else has pointed out, FreeBSD != OSX. I think that was the whole point of the Darwin logo (a platypus with Beastie's horns on it: http://docs.huihoo.com/darwin/images/hexley-2.png). If you watch the BSD is Dying presentation, you'll laugh when you see the reference to OSX as well: http://video.google.com/videoplay?docid=7833143728685685343 :). You have two choices: 1. Buy an Xserve loaded with OSX: http://shop.apple.com/ . 2. Compile and maintain your own copy of Apple's version of Darwin: http://opensource.apple.com/ . FYI, according to the Apple folks OSX is based off FreeBSD 5 (not sure which minor version): [Quote -- http://opensource.apple.com]: This fully-conformant UNIX operating system?built on Mach 3.0 and FreeBSD 5?bundles over a hundred of the most popular Open Source products. [/Quote] Which version of FreeBSD was used in OSX will almost certainly depend on which version of MacOS X you look at. It is quite possible that the latest version of OSX uses code from FreeBSD 5.x, but I guarantee that the first release of OSX did not. (This is easily seen from the fact the MacOS X 10.0 was first released in March 2001. The latest FreeBSD release at that time was 4.2 (released in November 2000.) FreeBSD 5.0 was not released until January 2003.) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting uzip image: Invalid argument
Kris Kennaway wrote: On Mon, Dec 25, 2006 at 11:17:21PM +0200, Erik Udo wrote: I'm making a live cd and i just hit a wall with uzip. I started by creating a null 1GB file, which i filled with FreeBSD. After that i compressed the file with mkuzip. Any attempts to mount this compressed image has failed, here is the output of truss when using mount_cd9660 to mount the image: koti# truss mount_cd9660 /dev/md0.uzip testi lstat(/stor/livecd/testi,0xbfbfe390) = 0 (0x0) stat(/stor/livecd/testi,0xbfbfe420)= 0 (0x0) open(/dev/md0.uzip,0x0,00) = 3 (0x3) ioctl(3,CHIOGPICKER,0xbfbfe15c) ERR#25 'Inappropriate ioctl for device' Looks like you don't have geom_uzip configured, per the manpage. Kris geom_uzip configured? I have it loaded in the kernel. Anyway, i solved it by mount -o to /dev/md0.uzip testi, i didn't need to mount it with mount_cd9660. Perhaps the man page is wrong? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mounting uzip image: Invalid argument
On Mon, Dec 25, 2006 at 11:17:21PM +0200, Erik Udo wrote: I'm making a live cd and i just hit a wall with uzip. I started by creating a null 1GB file, which i filled with FreeBSD. After that i compressed the file with mkuzip. Any attempts to mount this compressed image has failed, here is the output of truss when using mount_cd9660 to mount the image: koti# truss mount_cd9660 /dev/md0.uzip testi lstat(/stor/livecd/testi,0xbfbfe390) = 0 (0x0) stat(/stor/livecd/testi,0xbfbfe420)= 0 (0x0) open(/dev/md0.uzip,0x0,00) = 3 (0x3) ioctl(3,CHIOGPICKER,0xbfbfe15c) ERR#25 'Inappropriate ioctl for device' Looks like you don't have geom_uzip configured, per the manpage. Kris pgp9wrUZO9lz4.pgp Description: PGP signature
RE: Mounting Paritions in FBSD 5.1
hey, Thanks for the info. will keep it in mind. Also I did go through the handbook but (I think) didnt find anything on mounting(may be wrong) though. cheers, --- slick [EMAIL PROTECTED] wrote: first of all if your a newbie i would suggest using freebsd-stable cause 5.X is still development. second mounting is pretty obvious and also documented in mount man page. third kernel as to be compiled with filesystems you want to use, or you need to load appropriate modules. finally you should look at http://www.freebsd.org/handbook and http://www.freebsd.org/cgi/man.cgi -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of tee_aiche Sent: Sunday, February 08, 2004 8:24 AM To: [EMAIL PROTECTED] Subject: Mounting Paritions in FBSD 5.1 Hello All, FreeBSD 5.1 newb here, who managed to install it a month ago but hasnt used it much cause of the mounting problems. Can anyone tell me how to mount my Primary master (hda1-vfat partition) in FreeBSD. will mount -t vfat /dev/sd01 work as in linux? or should I change anything. Also I have a linux partition which I would like to access through FBSD. help needed. PS: Google didnt help much tho, got a few pages that said I would need to recompile my kernel to enable vfat support.I used www.google.com/bsd . thanks in advance, Toufeeq = 70uf33q ring me @ 98410-96690 mail me @ [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] = 70uf33q ring me @ 98410-96690 mail me @ [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mounting
# [EMAIL PROTECTED] / 2003-06-23 11:45:37 -0400: On Mon, 23 Jun 2003, Socketd wrote: Would it be possible to have this configuration and not having the system fail (because of lacking rights or something): /var/mail noexec nosuid would be fine here also. # [EMAIL PROTECTED] / 2003-06-24 16:31:33 +0100: On Mon, 23 Jun 2003, Socketd wrote: /tmp and /var/tmp noexec (I know /tmp has to be execuable to make world) nosymfollow. I've not found anything that this breaks (except a gazillion symlink race exploits). This questions will be probably extremely stupid: why aren't these defaults? -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mounting
On Mon, 23 Jun 2003, Robert Watson wrote:
RW Can nodev also be added to all above + /usr?
RW
RW nodev prevents opening specfs character devices, but doesn't prevent
RW opening fifos or UNIX domain sockets, so is generally fine for all file
RW systems except /dev. The common exceptions I bump into are:
RW
RW (1) If you have per-user chroots, make sure wherever their custom /dev is
RW isn't nodev.
Maybe my experience would be useful for the community:
I've successfully use mfs under 4.x for chroot/jailed environment, created via
JDEV=/ar/J/j224/dev
mount_mfs -s 256 -i 768 -o nosuid /dev/ad0s1b ${JDEV} /dev/null 21
cd ${JDEV}
sh /dev/MAKEDEV std pty0
rm mem kmem pci io klog console
ln -sf null mem
ln -sf null kmem
ln -sf null console
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mounting
On Mon, 23 Jun 2003, Socketd wrote: Hi again Would it be possible to have this configuration and not having the system fail (because of lacking rights or something): /tmp and /var/tmp noexec (I know /tmp has to be execuable to make world) nosymfollow. I've not found anything that this breaks (except a gazillion symlink race exploits). -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ Goedel would be proud - I'm both inconsistent _and_ incomplete. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mounting
On Tue, 24 Jun 2003 16:31:33 +0100 (BST) Jan Grant [EMAIL PROTECTED] wrote: /tmp and /var/tmp noexec (I know /tmp has to be execuable to make world) nosymfollow. I've not found anything that this breaks (except a gazillion symlink race exploits). Great! Thanks :-) br socketd ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mounting
On Mon, 23 Jun 2003 11:45:37 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: /var/mail noexec nosuid would be fine here also. And noexec too I guess? nodev prevents opening specfs character devices, but doesn't prevent opening fifos or UNIX domain sockets, so is generally fine for all file systems except /dev. The common exceptions I bump into are: (1) If you have per-user chroots, make sure wherever their custom /dev is isn't nodev. (2) The linux port used to (may still) install with a null device under /usr in the compat tree. Mounting this with nodev will break opening/dev/null for Linux apps. I'm not sure why the null entry exists there, and in fact we know it needs to go away since it will break when we GC major device numbers. Ah ok, again thank you for your help :-D br socketd ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FWD: Re: mounting a pen drive
In a nutshell, I have a usb pen drive that I can't mount. 4.7 seems to recognize it just fine. So, it must be some silly little thing I need to do. Ideally, I would love to put a ufs filesystem on this thing as well. Any pointers would be greatly appreciated. TIA! Craig - Forwarded message from Daniel O'Connor [EMAIL PROTECTED] - Date: 06 Feb 2003 14:27:53 +1030 From: Daniel O'Connor [EMAIL PROTECTED] To: Craig Sebenik [EMAIL PROTECTED] Cc: USB BSD List [EMAIL PROTECTED] Subject: Re: mounting a pen drive Content-Type: text/plain Organization: X-Mailer: Ximian Evolution 1.2.0 On Thu, 2003-02-06 at 13:08, Craig Sebenik wrote: I have looked briefly at the FAQ and at some of the other web pages and I can't find an explanation for how to simply mount a pen drive. usbdevs addr 1: UHCI root hub, Intel addr 2: product 0x2001, vendor 0x121e I tried mounting the drive with: mount_msdos /dev/da0c /tmp/pen mount_msdos: /dev/da0c: Invalid argument dmesg | grep umass umass0: vendor 0x121e product 0x2001, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 (da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10. Probably worth asking on a list like freebsd-stable or -hackers. A lot of these devices need a quirk to function (ie they don't understand certain commands and will hang) If you get the quirk stuff sorted out, it should Just Work as a normal disk. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mounting FAT16 on USB connected Rio 600
As said below, modify usbdevs/umass.c to recognise your device and then see whether it behaves. If not, try adding the quirks to scsi_da.c (no READS_6 and no cache sync) and see whether that improves things. If it is an ATAPI based device it might be more work to get this device working. Nick On Thu, 23 Aug 2001, Jim Bryant wrote: Matthew Emmerton wrote: Hackers, The overwhelming lack of response on -questions suggests I might do better here. I though this would be an easy one. In short, I simply want to know what device to mount and what to do get that device configured. # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), Intel(0x), rev 0x0100 port 1 powered port 2 addr 2: self powered, config 1, Diamond Multimedia Digital Audio Player(0x5001), Diamond Multimedia(0x045a), rev 0x0100 /kernel: ugen0: at uhub0 port 2 (addr 2) disconnected /kernel: ugen0: detached /kernel: ugen0: Diamond Multimedia Diamond Multimedia Digital Audio Player, rev 1.00/1.00, addr 2 Since this device is recognized by the kernel as 'ugen0', it doesn't know that it's a storage unit, and explains why you can't mount it. In order to use this device, you'll have to update the USB subsystem to recognize this device as a storage unit, and perhaps do some other code hacking before you can access it as a SCSI disk. Hopefully someone else on the list can provide you with more details (as in, how do I do what I need to do to get this thing working!) For an example of how to do this, please see the changes to: /usr/src/sys/dev/usb/umass.c /usr/src/sys/dev/usb/usbdevs /usr/src/sys/dev/usb/usbdevs.h /usr/src/sys/dev/usb/usbdevs_data.h /usr/src/sys/cam/scsi/scsi_da.c These changes were just committed to solve the exact problem you are having, instead it was for the MicroTech CameraMate CompactFlash/SmardCard reader. grep -i microtech on those files and look in the vicinity of the hits for the changes. The two .h files don't have to be changed, just run the makefile in that directory after changing usbdevs. Since I don't have a Diamond MP3 player, I can't do this. Although I didn't write the changes for the MicroTech CameraMate, I did learn a bit from the experience testing them, and it really doesn't look that hard once you figure out what is going on. Oh yeah, once you have it working, come back here, and post the patches asking that they be further tested and committed! It can take a little while, but it'll be worth it for the next guy. You may also want to search the archives and see if anyone else has announced patches being available for testing, that's how I came across the CameraMate patches that were just committed as a result of my testing [and asking for them to be committed until a committer noticed I was asking]. I searched the archives, found that someone had done some patches, and advertised the fact asking for others to test them, this was from back in April. A few weeks ago, I wrote him, and asked for a copy, although they didn't go in straight from patch, they were easy enough to put in by hand, and generate -current patches. After testing them out and finding they work, it was just a matter of asking for them to be committed. Welcome to open-source, community-supported operating systems! Should you choose to take this assignment, Matt, the secretary will disavow your actions if you are caught. Good luck! ;^) jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mounting FAT16 on USB connected Rio 600
Nick, As said below, modify usbdevs/umass.c to recognise your device and then see whether it behaves. If not, try adding the quirks to scsi_da.c (no READS_6 and no cache sync) and see whether that improves things. Since I started this, I ought to say that while I enjoy new challenges I don't think my non-existent coding skills are up to this. Given this and the fact that I am getting fed up looking at my Rio and thinking how nice it would be if I could use it thanks to some kind and talented coder who could whip up some support, I wonder if any of you fine folks would like me to send you the device to test and enjoy for a while. Would any takers please let me know if you're interested so we can work out something. -Andrew- -- __ | -Andrew J. Caines- Unix Systems Engineer [EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mounting FAT16 on USB connected Rio 600
* Andrew J Caines [EMAIL PROTECTED] [010902 22:12] wrote: Nick, As said below, modify usbdevs/umass.c to recognise your device and then see whether it behaves. If not, try adding the quirks to scsi_da.c (no READS_6 and no cache sync) and see whether that improves things. Since I started this, I ought to say that while I enjoy new challenges I don't think my non-existent coding skills are up to this. Given this and the fact that I am getting fed up looking at my Rio and thinking how nice it would be if I could use it thanks to some kind and talented coder who could whip up some support, I wonder if any of you fine folks would like me to send you the device to test and enjoy for a while. Would any takers please let me know if you're interested so we can work out something. I can do it if you include enough packaging such that I can mail it back to you with minimal effort. I'm in the SF Bay Area. If you haven't made arrangements yet mail me priavtely and I'll give you my address. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mounting FAT16 on USB connected Rio 600
Hackers, The overwhelming lack of response on -questions suggests I might do better here. I though this would be an easy one. In short, I simply want to know what device to mount and what to do get that device configured. # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), Intel(0x), rev 0x0100 port 1 powered port 2 addr 2: self powered, config 1, Diamond Multimedia Digital Audio Player(0x5001), Diamond Multimedia(0x045a), rev 0x0100 /kernel: ugen0: at uhub0 port 2 (addr 2) disconnected /kernel: ugen0: detached /kernel: ugen0: Diamond Multimedia Diamond Multimedia Digital Audio Player, rev 1.00/1.00, addr 2 Since this device is recognized by the kernel as 'ugen0', it doesn't know that it's a storage unit, and explains why you can't mount it. In order to use this device, you'll have to update the USB subsystem to recognize this device as a storage unit, and perhaps do some other code hacking before you can access it as a SCSI disk. Hopefully someone else on the list can provide you with more details (as in, how do I do what I need to do to get this thing working!) -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mounting FAT16 on USB connected Rio 600
Matthew Emmerton wrote: Hackers, The overwhelming lack of response on -questions suggests I might do better here. I though this would be an easy one. In short, I simply want to know what device to mount and what to do get that device configured. # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), Intel(0x), rev 0x0100 port 1 powered port 2 addr 2: self powered, config 1, Diamond Multimedia Digital Audio Player(0x5001), Diamond Multimedia(0x045a), rev 0x0100 /kernel: ugen0: at uhub0 port 2 (addr 2) disconnected /kernel: ugen0: detached /kernel: ugen0: Diamond Multimedia Diamond Multimedia Digital Audio Player, rev 1.00/1.00, addr 2 Since this device is recognized by the kernel as 'ugen0', it doesn't know that it's a storage unit, and explains why you can't mount it. In order to use this device, you'll have to update the USB subsystem to recognize this device as a storage unit, and perhaps do some other code hacking before you can access it as a SCSI disk. Hopefully someone else on the list can provide you with more details (as in, how do I do what I need to do to get this thing working!) For an example of how to do this, please see the changes to: /usr/src/sys/dev/usb/umass.c /usr/src/sys/dev/usb/usbdevs /usr/src/sys/dev/usb/usbdevs.h /usr/src/sys/dev/usb/usbdevs_data.h /usr/src/sys/cam/scsi/scsi_da.c These changes were just committed to solve the exact problem you are having, instead it was for the MicroTech CameraMate CompactFlash/SmardCard reader. grep -i microtech on those files and look in the vicinity of the hits for the changes. The two .h files don't have to be changed, just run the makefile in that directory after changing usbdevs. Since I don't have a Diamond MP3 player, I can't do this. Although I didn't write the changes for the MicroTech CameraMate, I did learn a bit from the experience testing them, and it really doesn't look that hard once you figure out what is going on. Oh yeah, once you have it working, come back here, and post the patches asking that they be further tested and committed! It can take a little while, but it'll be worth it for the next guy. You may also want to search the archives and see if anyone else has announced patches being available for testing, that's how I came across the CameraMate patches that were just committed as a result of my testing [and asking for them to be committed until a committer noticed I was asking]. I searched the archives, found that someone had done some patches, and advertised the fact asking for others to test them, this was from back in April. A few weeks ago, I wrote him, and asked for a copy, although they didn't go in straight from patch, they were easy enough to put in by hand, and generate -current patches. After testing them out and finding they work, it was just a matter of asking for them to be committed. Welcome to open-source, community-supported operating systems! Should you choose to take this assignment, Matt, the secretary will disavow your actions if you are caught. Good luck! ;^) jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mounting Linux Partitions in Extended Partitions
On Sun, Apr 15, 2001 at 09:56:45PM -0400, Will Mitayai Keeso Rowe wrote: Hello! I have a machine here that has a SCSI disk that used to have Linux installed on it. When i check fdisk, it appears that there are two partitions, 1 with 23M that seems to have the boot stuff and kernel, and then one with several Gigs with the actual data (i booted into Linux to make sure, everything looks fine). In FreeBSD, when i look at fdisk, the first partition is labelled as ext2fs and the second partition is labelled as DOS extended. I can mount the first one fine with mount_ext2fs, but i can't figure out if, or how, i can mount the larger one. Does anyone have any insight? Use the slice number equal to the partition number in linux. For instace, if Linux saw the disk as sdb6, use da1s6 in FreeBSD. This will work just fine. -- Andrew Hesford [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting partitions with RO flag
On Sun, 8 Apr 2001, Attila Nagy wrote: With the appearing of the jail() in 4.0 I think it would be very good to have the functionality of mounting already mounted (RW) filesystems read only to another directory. Many people agree with you -- this is one reason why the fixing of nullfs in -CURRENT was so desirable. However, most consumers of jail are actually looking to replicate only a portion of their jails--usually the /usr tree, as it's the most sizable chunk, and then symlink bin and sbin into it. This preserves /, /var, /etc, and /tmp as running inside the jail. Jail is really intended to virtualize whole environments, rather than particular daemons, however (doesn't mean you can't, but that was the thrust). For example there are several daemons which can run on a read only filesystem, like an anonymous FTP daemon for extra security in a jail. nullfs and unionfs would be suitable for these tasks but they have problems in at least -STABLE, so there are only hacks for doing this, like NFS mounted filesystems and partition "magic" (defining a lot of partitions onto the same physical space). So I am wondering, why the unices block mounting an already mounted partition read only again. Well, you certainly don't want to mount the same partition writable and read-only at the same time. It's an arbitrary design choice to prevent simultaneous mounting of read-only file systems on one vnode, and one that I think Poul-Henning was going to look at removing as part of his device layer restructuring. Would it be possible to solve this under FreeBSD? It seems like there are a number of solutions to the problem that have been considered: nullfs fixed in 5.0-CURRENT nfs loopbackworks multiple mounting not implemented nullfs is probably the best choice, as it prevents redundant caching in the vm/buffer cache. nfs loopback introduces a substantial performance overhead, but at least works. And multiple mounting won't provide the RW/RO behavior you want, only multiple RO mounts, although it should be straight-forward to implement it. You could hack that in now by futzing with the vfs_mountedon() behavior, it's just not clear it provides what you actually want. The best bet may be to backport the nullfs fixes to 4.x, or to wait for 5.x. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting partitions with RO flag
On Sun, 8 Apr 2001, Alex Zepeda wrote: On Sun, Apr 08, 2001 at 09:13:15PM +0200, Attila Nagy wrote: So I am wondering, why the unices block mounting an already mounted partition read only again. Have you considered using ACLs perhaps? Sure it's not in -STABLE, but it's a thought.. ACLs are a form of discretionary access control, and as such can't impose mandatory read-only behavior for processes in a jail. For that, you want mandatory access control, a feature still under development as part of TrustedBSD. However, mandatory file labeling substantially complicates file system management, and jail provides a simple substitute by using chroot, a choice that seems wise to me :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting partitions with RO flag
Hello, So I am wondering, why the unices block mounting an already mounted partition read only again. Have you considered using ACLs perhaps? Sure it's not in -STABLE, but it's a thought.. It's a good thing, but I need to solve this problem on -STABLE, not on -CURRENT :( I think running -CURRENT on a production machine is not a good idea... Thanks, -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Mounting partitions with RO flag
On 08-Apr-01 Attila Nagy wrote: So I am wondering, why the unices block mounting an already mounted partition read only again. Would it be possible to solve this under FreeBSD? Loopback NFS mount, maybe ? -- E-Mail: Kenneth P. Stox [EMAIL PROTECTED] Date: 09-Apr-01 Time: 22:15:31 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting partitions with RO flag
Attila Nagy writes: I have a really stupid question, so please forgive me if the answer is trivial for you... With the appearing of the jail() in 4.0 I think it would be very good to have the functionality of mounting already mounted (RW) filesystems read only to another directory. For example there are several daemons which can run on a read only filesystem, like an anonymous FTP daemon for extra security in a jail. nullfs and unionfs would be suitable for these tasks but they have problems in at least -STABLE, so there are only hacks for doing this, like NFS mounted filesystems and partition "magic" (defining a lot of partitions onto the same physical space). So I am wondering, why the unices block mounting an already mounted partition read only again. Would it be possible to solve this under FreeBSD? I am second for it. I am using some partition "magic" and know dark side of it. -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting partitions with RO flag
Hello, Would it be possible to solve this under FreeBSD? I am second for it. I hope somebody will enlighten my dark mind, because I am really curious about this :) I am using some partition "magic" and know dark side of it. What the problem is with it besides the ugly hacking and the small number of possible partitions? -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting partitions with RO flag
Attila Nagy writes: Would it be possible to solve this under FreeBSD? I am second for it. I hope somebody will enlighten my dark mind, because I am really curious about this :) I am using some partition "magic" and know dark side of it. What the problem is with it besides the ugly hacking and the small number of possible partitions? How much partitions do you want? adNs[0..30][a..h] 31*8= 248 if it is low enough, just use vn[0..]s[0..30][a..h] ... with some more dark sides, of cause About dark side: 0garkin~(4)#df Filesystem 1K-blocks UsedAvail Capacity Mounted on ... /dev/ad0s2h7993324 461995 6891864 6%/usr /dev/ad0s3a7993324 441159 6912700 6%/jail/pent/usr There is physically the same fs marked as /dev/ad0s2h and /dev/ad0s3a in this example. The /usr is rw mounted and /jail/pent/usr is ro mounted. Do you see a difference? You can really stuck VM system with ro mount that is really rw mount in another mount. Instances of shared fs do not share buffers - which IS a real point - just allow second mount does not solve a problem IMHO The only way of use this method of fs sharing in production is ro mount of any instance and do not upgrade without all jails stopped. And a lot of memory for files buffers :-( -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting partitions with RO flag
On Sun, Apr 08, 2001 at 09:13:15PM +0200, Attila Nagy wrote: So I am wondering, why the unices block mounting an already mounted partition read only again. Have you considered using ACLs perhaps? Sure it's not in -STABLE, but it's a thought.. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a CDROM in freeBSD 4.2
mouss wrote: and you must make sure your kernel is compiled with options CD9660 Err... no. The kld gets autoloaded if the kernel doesn't have cd9660 compiled-in. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "There is no spoon." -- Kiki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a CDROM in freeBSD 4.2
In message [EMAIL PROTECTED], "Daniel C. Sobral" writes: and you must make sure your kernel is compiled with options CD9660 Err... no. The kld gets autoloaded if the kernel doesn't have cd9660 compiled-in. The error message that is printed is misleading though, and gives the impression that cd9660 filesystem support is missing: cd9660: No such file or directory When mount(8) runs mount_cd9660, it gives it an argv[0] of the fileystem type i.e. 'cd9660'. That's where the cd9660 in the error message comes from. Maybe mount_cd9660 (and other mount_* programs) should provide a bit more information in the error message? Ian Index: mount_cd9660.c === RCS file: /home/iedowse/CVS/src/sbin/mount_cd9660/mount_cd9660.c,v retrieving revision 1.15 diff -u -r1.15 mount_cd9660.c --- mount_cd9660.c 1999/10/09 11:54:08 1.15 +++ mount_cd9660.c 2001/01/17 12:34:23 @@ -176,7 +176,7 @@ errx(1, "cd9660 filesystem is not available"); if (mount(vfc.vfc_name, mntpath, mntflags, args) 0) - err(1, NULL); + err(1, "%s on %s: mount", mntpath, dev); exit(0); } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a CDROM in freeBSD 4.2
In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes: Please send the response directly back to me, in addition to sending it to hackers , as the volume of mail to hackers is so great that I could very easily miss the response if it were only sent there. I just installed freeBSD 4.2 and found that I couldn't mount a CDROM even though I copied the command-lines from (the top of) page 236 of Greg Lehey's book (ISBN 1-57176-246-9). When I was running freeBSD 3.3 , I was able to mount a CDROM , and I believe I did it just as described in Greg's book. The error message that I get is 'cd9660: Device not configured'. I was able to mount and read an MSDOS floppy. The naming of the cdrom has changed from 3.x to 4.x. I do not remember the old name but the new name is /dev/acd0c for an ATAPI cdrom. So you must have in /etc/fstab something like... /dev/acd0c /cdrom cd9660 ro,noauto 0 0 Maybe you encounter this kind of trouble. Regards, Phil. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a CDROM in freeBSD 4.2
and you must make sure your kernel is compiled with options CD9660 At 18:08 16/01/01 +0100, Philippe CASIDY wrote: The naming of the cdrom has changed from 3.x to 4.x. I do not remember the old name but the new name is /dev/acd0c for an ATAPI cdrom. So you must have in /etc/fstab something like... /dev/acd0c /cdrom cd9660 ro,noauto 0 0 Maybe you encounter this kind of trouble. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a CDROM in freeBSD 4.2
I'd like to thank every one who responded, and all those who were willing to respond but saw that they would be repeating information already sent. It turns out that the designation of the CDROM drive changed between versions 3.3 and 4.2 , and the only one I knew was the designation of the CDROM drive for version 3.3 . I did a grep -i cdrom *.TXT on the files ABOUT.TXT INSTALL.TXT README.TXTTROUBLE.TXT ERRATA.TXTLAYOUT.TXTRELNOTES.TXT UPGRADE.TXT and found no mention of the designation of the CDROM drive, so I am glad that a couple of responders sent it to me. I would like to know how they found out this tidbit of information so I'll know where to look for it in the future. I would suggest that there be a man page listing all the drive designations ( CDROM , A , B [if one has it] , IDE [or other] drive D , etc. , SCSI drives ) and this man page should be referenced as a "SEE ALSO" in all the mount man pages . Possibly it could be like Greg Lehey's table 13.5 except that it should be more complete. _ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a CDROM in freeBSD 4.2
It seems gerald stoller wrote: Please send the response directly back to me, in addition to sending it to hackers , as the volume of mail to hackers is so great that I could very easily miss the response if it were only sent there. I just installed freeBSD 4.2 and found that I couldn't mount a CDROM even though I copied the command-lines from (the top of) page 236 of Greg Lehey's book (ISBN 1-57176-246-9). When I was running freeBSD 3.3 , I was able to mount a CDROM , and I believe I did it just as described in Greg's book. The error message that I get is 'cd9660: Device not configured'. I was able to mount and read an MSDOS floppy. You dont give us any information to go on at all, what was the exact command you issue'd ? -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a CDROM in freeBSD 4.2
From: Soren Schmidt [EMAIL PROTECTED] To: [EMAIL PROTECTED] (gerald stoller) CC: [EMAIL PROTECTED] Subject: Re: Mounting a CDROM in freeBSD 4.2 Date: Mon, 15 Jan 2001 19:50:59 +0100 (CET) It seems gerald stoller wrote: Please send the response directly back to me, in addition to sending it to hackers , as the volume of mail to hackers is so great that I could very easily miss the response if it were only sent there. I just installed freeBSD 4.2 and found that I couldn't mount a CDROM even though I copied the command-lines from (the top of) page 236 of Greg Lehey's book (ISBN 1-57176-246-9). When I was running freeBSD 3.3 , I was able to mount a CDROM , and I believe I did it just as described in Greg's book. The error message that I get is 'cd9660: Device not configured'. I was able to mount and read an MSDOS floppy. You dont give us any information to go on at all, what was the exact command you issue'd ? -Søren The exact command (issued as root ) was mount -t cd9660 -o ro /dev/cd1a /cdrom after I had previously donemkdir /cdrom . I also read the man pages for the mount's . _ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a md as a root filesystem.
Josef Karthauser [EMAIL PROTECTED] writes: # load -t md /filesystemfile Shouldn't that be 'load -t md_root'? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a md as a root filesystem.
On 7 Nov 2000, Dag-Erling Smorgrav wrote: Josef Karthauser [EMAIL PROTECTED] writes: # load -t md /filesystemfile Shouldn't that be 'load -t md_root'? Actually, it's md_image or mfs_root (see /sys/dev/md/md.c:446). Both of these are mentioned in md(4). Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting openbsd disks
On Fri, 4 Feb 2000, Warner Losh wrote: I have a need to mount a disk that was partitioned and labeled on OpenBSD. I'm getting the following errors when I try: # disklabel ad2 disklabel: ioctl DIOCGDINFO: Invalid argument root@earth:~# disklabel ad1 disklabel: ioctl DIOCGDINFO: Invalid argument root@earth:~# disklabel /dev/ad1s4 *snip* 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 52409704.2BSD 1024 819216 # (Cyl.0 - 519*) b: 1048320 524097 swap# (Cyl. 519*- 1559) c: 164504970unused0 0 # (Cyl.0 - 16319*) e: 262080 15724174.2BSD 1024 819216 # (Cyl. 1559*- 1819) f: 4194288 18344974.2BSD 1024 819216 # (Cyl. 1819*- 5980) root@earth:~# mount /dev/ad1s4a /mnt root@earth:~# ls /mnt .cshrc bootemulroottmp .profilebsd etc sbinusr altroot bsd.old homestand var bin dev mnt sys root@earth:~# - Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting openbsd disks
In message [EMAIL PROTECTED] "Chris D. Faulhaber" writes: : root@earth:~# disklabel ad1 : disklabel: ioctl DIOCGDINFO: Invalid argument : root@earth:~# disklabel /dev/ad1s4 disklabel /dev/ad2s2 (which is the OpenBSD partition) fails with the same error. Mounting claims a bad magic number. This is an OpenBSD/arc disk which has a slightly different disklabel I think (since when I say disklabel on the OpenBSD/arc machine I get 16 partitions. Changing the id of the slice doesn't help either. :-( Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
On Mon, 13 Sep 1999, Tony Finch wrote: Well, in the absence of any comments I hacked around a bit and ended up with the following patch (against 3.3-RC), which permits the same block device to be mounted read-only more than once. The motivation for this is to permit multiple chrooted environments to share the same /usr partition. Wouldn't it be much cleaner to use nullfs? This application is what it's good at. Take care, Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
:Tony Finch [EMAIL PROTECTED] wrote: : :Well, in the absence of any comments I hacked around a bit and ended :up with the following patch (against 3.3-RC), which permits the same :block device to be mounted read-only more than once. The motivation :for this is to permit multiple chrooted environments to share the same :/usr partition. : :Some things I wonder about this change is whether the mounts will share :the same pages in the buffer cache, and whether the resource :accounting is still right. I've subtly funted the meaning of :v_specmountpoint when multiple mounts happen; does this matter? : :Tony. :-- :f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix Hmm... well, there is a problem here. I believe this will allow you to open the underlying block device read-only as well as mount the filesystem read-only. This will confuse the buffer cache badly. Also, this may not be the best place to put the code. It make sense to be able to mount a block device multiple times in a read-only fashion, but the code should be in the open for the block device rather then in UFS/FFS, so it can be used with other filesystems and for other purposes. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
:Matthew Dillon [EMAIL PROTECTED] wrote: : :Tony Finch [EMAIL PROTECTED] wrote: :... : : Hmm... well, there is a problem here. I believe this will allow : you to open the underlying block device read-only as well as mount : the filesystem read-only. This will confuse the buffer cache badly. : :I don't think so -- spec_open checks whether the block device has been :mounted in order to prevent this, and I made sure that that check :remains in force except when spec_open is called by ffs_mountfs (by :adding the FMOUNTING flag). I assumed that the buffer cache will :handle multiple read-only mounts because it handles multiple userland :reading file descriptors. Ah, I see it now! : Also, this may not be the best place to put the code. It make sense : to be able to mount a block device multiple times in a read-only : fashion, but the code should be in the open for the block device : rather then in UFS/FFS, so it can be used with other filesystems : and for other purposes. : :Yes, it's evident that this is true because I had to hack around :essentially the same test in both spec_open and ffs_mountfs; removing :the checks down from ffs_mountfs so it relies on spec_mount to DTRT :would be neater, I think. : :Tony. :-- :f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix Yes. I think this is the right track to take. The result will be more useful to the system and probably a cleaner patch as well. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
:Tony Finch f...@demon.net wrote: : :Well, in the absence of any comments I hacked around a bit and ended :up with the following patch (against 3.3-RC), which permits the same :block device to be mounted read-only more than once. The motivation :for this is to permit multiple chrooted environments to share the same :/usr partition. : :Some things I wonder about this change is whether the mounts will share :the same pages in the buffer cache, and whether the resource :accounting is still right. I've subtly funted the meaning of :v_specmountpoint when multiple mounts happen; does this matter? : :Tony. :-- :f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix Hmm... well, there is a problem here. I believe this will allow you to open the underlying block device read-only as well as mount the filesystem read-only. This will confuse the buffer cache badly. Also, this may not be the best place to put the code. It make sense to be able to mount a block device multiple times in a read-only fashion, but the code should be in the open for the block device rather then in UFS/FFS, so it can be used with other filesystems and for other purposes. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mounting a partition more than once
:Matthew Dillon dil...@apollo.backplane.com wrote: : :Tony Finch f...@demon.net wrote: :... : : Hmm... well, there is a problem here. I believe this will allow : you to open the underlying block device read-only as well as mount : the filesystem read-only. This will confuse the buffer cache badly. : :I don't think so -- spec_open checks whether the block device has been :mounted in order to prevent this, and I made sure that that check :remains in force except when spec_open is called by ffs_mountfs (by :adding the FMOUNTING flag). I assumed that the buffer cache will :handle multiple read-only mounts because it handles multiple userland :reading file descriptors. Ah, I see it now! : Also, this may not be the best place to put the code. It make sense : to be able to mount a block device multiple times in a read-only : fashion, but the code should be in the open for the block device : rather then in UFS/FFS, so it can be used with other filesystems : and for other purposes. : :Yes, it's evident that this is true because I had to hack around :essentially the same test in both spec_open and ffs_mountfs; removing :the checks down from ffs_mountfs so it relies on spec_mount to DTRT :would be neater, I think. : :Tony. :-- :f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix Yes. I think this is the right track to take. The result will be more useful to the system and probably a cleaner patch as well. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mounting a partition more than once
Matthew Dillon [EMAIL PROTECTED] wrote: Tony Finch [EMAIL PROTECTED] wrote: :Matthew Dillon [EMAIL PROTECTED] wrote: : : Also, this may not be the best place to put the code. It make sense : to be able to mount a block device multiple times in a read-only : fashion, but the code should be in the open for the block device : rather then in UFS/FFS, so it can be used with other filesystems : and for other purposes. : :Yes, it's evident that this is true because I had to hack around :essentially the same test in both spec_open and ffs_mountfs; removing :the checks down from ffs_mountfs so it relies on spec_mount to DTRT :would be neater, I think. Yes. I think this is the right track to take. The result will be more useful to the system and probably a cleaner patch as well. I found some problems with the patch last night (after some suggestions from a colleague). There needs to be some additional checking at the level of the syscall code, I think, to prevent mounting the same partition at the same point more than once -- this causes a "lockmgr: locking against myself" panic when unmounting. I also missed out some checks from the remount code... Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
Matthew Dillon dil...@apollo.backplane.com wrote: Tony Finch f...@demon.net wrote: :Matthew Dillon dil...@apollo.backplane.com wrote: : : Also, this may not be the best place to put the code. It make sense : to be able to mount a block device multiple times in a read-only : fashion, but the code should be in the open for the block device : rather then in UFS/FFS, so it can be used with other filesystems : and for other purposes. : :Yes, it's evident that this is true because I had to hack around :essentially the same test in both spec_open and ffs_mountfs; removing :the checks down from ffs_mountfs so it relies on spec_mount to DTRT :would be neater, I think. Yes. I think this is the right track to take. The result will be more useful to the system and probably a cleaner patch as well. I found some problems with the patch last night (after some suggestions from a colleague). There needs to be some additional checking at the level of the syscall code, I think, to prevent mounting the same partition at the same point more than once -- this causes a lockmgr: locking against myself panic when unmounting. I also missed out some checks from the remount code... Tony. -- f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mounting a partition more than once
Tony Finch [EMAIL PROTECTED] wrote:
Is there a reason for disallowing concurrent read-only mounts of the
same disk device? i.e. would things go pear-shaped if I added this
capability?
Well, in the absence of any comments I hacked around a bit and ended
up with the following patch (against 3.3-RC), which permits the same
block device to be mounted read-only more than once. The motivation
for this is to permit multiple chrooted environments to share the same
/usr partition.
Some things I wonder about this change is whether the mounts will share
the same pages in the buffer cache, and whether the resource
accounting is still right. I've subtly funted the meaning of
v_specmountpoint when multiple mounts happen; does this matter?
Tony.
--
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix
--- /usr/src/sys/sys/fcntl.h.orig Mon Sep 13 15:21:29 1999
+++ /usr/src/sys/sys/fcntl.hMon Sep 13 17:04:46 1999
@@ -93,6 +93,7 @@
#defineFMARK 0x1000 /* mark during gc() */
#defineFDEFER 0x2000 /* defer for next gc pass */
#defineFHASLOCK0x4000 /* descriptor holds advisory lock */
+#defineFMOUNTING 0x8000 /* a block device is being mounted */
#endif
/* Defined by POSIX 1003.1; BSD default, but must be distinct from O_RDONLY. */
--- /usr/src/sys/miscfs/specfs/spec_vnops.c.origMon Sep 13 17:11:17 1999
+++ /usr/src/sys/miscfs/specfs/spec_vnops.c Mon Sep 13 15:37:22 1999
@@ -229,7 +229,7 @@
* Do not allow opens of block devices that are
* currently mounted.
*/
- error = vfs_mountedon(vp);
+ error = (ap-a_mode FMOUNTING) ? 0 : vfs_mountedon(vp);
if (error)
return (error);
return ((*bdevsw[maj]-d_open)(dev, ap-a_mode, S_IFBLK, p));
--- /usr/src/sys/kern/vfs_subr.c.orig Mon Sep 13 11:44:59 1999
+++ /usr/src/sys/kern/vfs_subr.cMon Sep 13 11:55:06 1999
@@ -1886,6 +1886,39 @@
simple_unlock(spechash_slock);
return (count);
}
+
+/*
+ * Calculate the total number of writers on a special device.
+ */
+int
+vwritecount(vp)
+ register struct vnode *vp;
+{
+ struct vnode *vq, *vnext;
+ int count;
+
+loop:
+ if ((vp-v_flag VALIASED) == 0)
+ return (vp-v_writecount);
+ simple_lock(spechash_slock);
+ for (count = 0, vq = *vp-v_hashchain; vq; vq = vnext) {
+ vnext = vq-v_specnext;
+ if (vq-v_rdev != vp-v_rdev || vq-v_type != vp-v_type)
+ continue;
+ /*
+* Alias, but not in use, so flush it out.
+*/
+ if (vq-v_writecount == 0 vq != vp) {
+ simple_unlock(spechash_slock);
+ vgone(vq);
+ goto loop;
+ }
+ count += vq-v_writecount;
+ }
+ simple_unlock(spechash_slock);
+ return (count);
+}
+
/*
* Print out a description of a vnode.
*/
--- /usr/src/sys/ufs/ffs/ffs_vfsops.c.orig Mon Sep 13 11:21:07 1999
+++ /usr/src/sys/ufs/ffs/ffs_vfsops.c Mon Sep 13 17:08:23 1999
@@ -586,28 +586,33 @@
struct ucred *cred;
u_int64_t maxfilesize; /* XXX */
size_t strsize;
- int ncount;
+ int ncount, nwritecount;
dev = devvp-v_rdev;
cred = p ? p-p_ucred : NOCRED;
+ ronly = (mp-mnt_flag MNT_RDONLY) != 0;
/*
-* Disallow multiple mounts of the same device.
+* Only allow multiple read-only mounts of the same device.
* Disallow mounting of a device that is currently in use
* (except for root, which might share swap device for miniroot).
* Flush out any old buffers remaining from a previous use.
*/
- error = vfs_mountedon(devvp);
+ error = ronly ? 0 : vfs_mountedon(devvp);
if (error)
return (error);
+ nwritecount = vwritecount(devvp);
+ if (nwritecount)
+ return (EBUSY);
ncount = vcount(devvp);
-
- if (ncount 1 devvp != rootvp)
+ if (!ronly ncount 1 devvp != rootvp)
return (EBUSY);
- vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
- error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
- VOP_UNLOCK(devvp, 0, p);
- if (error)
- return (error);
+ if (ncount = 1) {
+ vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
+ error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
+ VOP_UNLOCK(devvp, 0, p);
+ if (error)
+ return (error);
+ }
/*
* Only VMIO the backing device if the backing device is a real
@@ -622,8 +627,8 @@
VOP_UNLOCK(devvp, LK_INTERLOCK, p);
}
- ronly = (mp-mnt_flag
Re: mounting a partition more than once
Matthew Dillon [EMAIL PROTECTED] wrote: :Tony Finch [EMAIL PROTECTED] wrote: : :Well, in the absence of any comments I hacked around a bit and ended :up with the following patch (against 3.3-RC), which permits the same :block device to be mounted read-only more than once. The motivation :for this is to permit multiple chrooted environments to share the same :/usr partition. Hmm... well, there is a problem here. I believe this will allow you to open the underlying block device read-only as well as mount the filesystem read-only. This will confuse the buffer cache badly. I don't think so -- spec_open checks whether the block device has been mounted in order to prevent this, and I made sure that that check remains in force except when spec_open is called by ffs_mountfs (by adding the FMOUNTING flag). I assumed that the buffer cache will handle multiple read-only mounts because it handles multiple userland reading file descriptors. Also, this may not be the best place to put the code. It make sense to be able to mount a block device multiple times in a read-only fashion, but the code should be in the open for the block device rather then in UFS/FFS, so it can be used with other filesystems and for other purposes. Yes, it's evident that this is true because I had to hack around essentially the same test in both spec_open and ffs_mountfs; removing the checks down from ffs_mountfs so it relies on spec_mount to DTRT would be neater, I think. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
Tony Finch f...@demon.net wrote:
Is there a reason for disallowing concurrent read-only mounts of the
same disk device? i.e. would things go pear-shaped if I added this
capability?
Well, in the absence of any comments I hacked around a bit and ended
up with the following patch (against 3.3-RC), which permits the same
block device to be mounted read-only more than once. The motivation
for this is to permit multiple chrooted environments to share the same
/usr partition.
Some things I wonder about this change is whether the mounts will share
the same pages in the buffer cache, and whether the resource
accounting is still right. I've subtly funted the meaning of
v_specmountpoint when multiple mounts happen; does this matter?
Tony.
--
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix
--- /usr/src/sys/sys/fcntl.h.orig Mon Sep 13 15:21:29 1999
+++ /usr/src/sys/sys/fcntl.hMon Sep 13 17:04:46 1999
@@ -93,6 +93,7 @@
#defineFMARK 0x1000 /* mark during gc() */
#defineFDEFER 0x2000 /* defer for next gc pass */
#defineFHASLOCK0x4000 /* descriptor holds advisory
lock */
+#defineFMOUNTING 0x8000 /* a block device is being
mounted */
#endif
/* Defined by POSIX 1003.1; BSD default, but must be distinct from O_RDONLY. */
--- /usr/src/sys/miscfs/specfs/spec_vnops.c.origMon Sep 13 17:11:17 1999
+++ /usr/src/sys/miscfs/specfs/spec_vnops.c Mon Sep 13 15:37:22 1999
@@ -229,7 +229,7 @@
* Do not allow opens of block devices that are
* currently mounted.
*/
- error = vfs_mountedon(vp);
+ error = (ap-a_mode FMOUNTING) ? 0 : vfs_mountedon(vp);
if (error)
return (error);
return ((*bdevsw[maj]-d_open)(dev, ap-a_mode, S_IFBLK, p));
--- /usr/src/sys/kern/vfs_subr.c.orig Mon Sep 13 11:44:59 1999
+++ /usr/src/sys/kern/vfs_subr.cMon Sep 13 11:55:06 1999
@@ -1886,6 +1886,39 @@
simple_unlock(spechash_slock);
return (count);
}
+
+/*
+ * Calculate the total number of writers on a special device.
+ */
+int
+vwritecount(vp)
+ register struct vnode *vp;
+{
+ struct vnode *vq, *vnext;
+ int count;
+
+loop:
+ if ((vp-v_flag VALIASED) == 0)
+ return (vp-v_writecount);
+ simple_lock(spechash_slock);
+ for (count = 0, vq = *vp-v_hashchain; vq; vq = vnext) {
+ vnext = vq-v_specnext;
+ if (vq-v_rdev != vp-v_rdev || vq-v_type != vp-v_type)
+ continue;
+ /*
+* Alias, but not in use, so flush it out.
+*/
+ if (vq-v_writecount == 0 vq != vp) {
+ simple_unlock(spechash_slock);
+ vgone(vq);
+ goto loop;
+ }
+ count += vq-v_writecount;
+ }
+ simple_unlock(spechash_slock);
+ return (count);
+}
+
/*
* Print out a description of a vnode.
*/
--- /usr/src/sys/ufs/ffs/ffs_vfsops.c.orig Mon Sep 13 11:21:07 1999
+++ /usr/src/sys/ufs/ffs/ffs_vfsops.c Mon Sep 13 17:08:23 1999
@@ -586,28 +586,33 @@
struct ucred *cred;
u_int64_t maxfilesize; /* XXX */
size_t strsize;
- int ncount;
+ int ncount, nwritecount;
dev = devvp-v_rdev;
cred = p ? p-p_ucred : NOCRED;
+ ronly = (mp-mnt_flag MNT_RDONLY) != 0;
/*
-* Disallow multiple mounts of the same device.
+* Only allow multiple read-only mounts of the same device.
* Disallow mounting of a device that is currently in use
* (except for root, which might share swap device for miniroot).
* Flush out any old buffers remaining from a previous use.
*/
- error = vfs_mountedon(devvp);
+ error = ronly ? 0 : vfs_mountedon(devvp);
if (error)
return (error);
+ nwritecount = vwritecount(devvp);
+ if (nwritecount)
+ return (EBUSY);
ncount = vcount(devvp);
-
- if (ncount 1 devvp != rootvp)
+ if (!ronly ncount 1 devvp != rootvp)
return (EBUSY);
- vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
- error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
- VOP_UNLOCK(devvp, 0, p);
- if (error)
- return (error);
+ if (ncount = 1) {
+ vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
+ error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
+ VOP_UNLOCK(devvp, 0, p);
+ if (error)
+ return (error);
+ }
/*
* Only VMIO the backing device if the backing device is a real
@@ -622,8 +627,8 @@
VOP_UNLOCK(devvp, LK_INTERLOCK, p);
}
- ronly = (mp-mnt_flag
Re: mounting a partition more than once
Matthew Dillon dil...@apollo.backplane.com wrote: :Tony Finch f...@demon.net wrote: : :Well, in the absence of any comments I hacked around a bit and ended :up with the following patch (against 3.3-RC), which permits the same :block device to be mounted read-only more than once. The motivation :for this is to permit multiple chrooted environments to share the same :/usr partition. Hmm... well, there is a problem here. I believe this will allow you to open the underlying block device read-only as well as mount the filesystem read-only. This will confuse the buffer cache badly. I don't think so -- spec_open checks whether the block device has been mounted in order to prevent this, and I made sure that that check remains in force except when spec_open is called by ffs_mountfs (by adding the FMOUNTING flag). I assumed that the buffer cache will handle multiple read-only mounts because it handles multiple userland reading file descriptors. Also, this may not be the best place to put the code. It make sense to be able to mount a block device multiple times in a read-only fashion, but the code should be in the open for the block device rather then in UFS/FFS, so it can be used with other filesystems and for other purposes. Yes, it's evident that this is true because I had to hack around essentially the same test in both spec_open and ffs_mountfs; removing the checks down from ffs_mountfs so it relies on spec_mount to DTRT would be neater, I think. Tony. -- f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
