Qemu Access Network help
Hello Group i running with Netbsd 6.0.1, and i have install Qemu 2.0 with one VM Server installed with Microsft Srv, but i become (with dhcp) IP Adress 0.0.0.0. Syntax: qemu-system-x86_64 -m 2048 -hda /usr/Srv2003.img -net nic,model=e1000 if running command without "net nic" i have a valid from Qemu-DHCP Address 10.0.2.15/24 here i can only ping me own address :-) bridge, and brconfig done but without success, me aspect are that me Windows machine can ping from bothside me network and reach the internet. Please can you give me more help to see me misake? Thanks Mauri hp7900# dmesg | grep wm0 wm0 at pci0 dev 25 function 0: 82567LM-3 LAN Controller (rev. 0x02) wm0: interrupting at ioapic0 pin 19 wm0: PCI-Express bus wm0: FLASH wm0: Ethernet address 00:24:81:04:3e:0c hp7900$ ifconfig -a wm0: flags=8843 mtu 1500 capabilities=7ff80 enabled=0 address: 00:24:81:04:3e:0c media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.0.103 netmask 0xffe0 broadcast 192.168.0.127 inet6 fe80::224:81ff:fe04:3e0c%wm0 prefixlen 64 scopeid 0x1 lo0: flags=8049 mtu 33648 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 bridge0: flags=41 mtu 1500 tap0: flags=8943 mtu 1500 address: f2:0b:a4:81:1b:04 media: Ethernet autoselect inet 192.168.0.105 netmask 0xff00 broadcast 192.168.0.255 inet6 fe80::f00b:a4ff:fe81:1b04%tap0 prefixlen 64 scopeid 0x4 hp7900$ brconfig -a bridge0: flags=41 Configuration: priority 32768 hellotime 2 fwddelay 15 maxage 20 ipfilter disabled flags 0x0 Interfaces: tap0 flags=3 port 4 priority 128 Address cache (max cache: 100, timeout: 1200): hp7900$
Re: LD_PRELOAD and mixed architectures
"Gary Duzan" writes: >Just a thought, but have you tried putting a 32-bit version of > the library under /emul/netbsd32 ? Great idea. Binaries running under emulation will look in /emul/netbsd32 first (prepended to the file path), so that should work.
Re: LD_PRELOAD and mixed architectures
In Message <53a6f6d7.5040...@grammatech.com>, Dave Vitek wrote: =>Hi all, => =>I'm on an amd64 machine that has a mixture of i386 and amd64 binaries =>present. I want to build a shared object file and use LD_PRELOAD to =>inject it into every process in some process tree. The executables in =>the tree could be a mixture of amd64 and i386 executables. Many other =>operating systems have a way of using LD_PRELOAD in a mixed architecture =>environment, but I'm not seeing a path to victory on netbsd. => =>I had a look at the source code for ld.so (the elf one anyway). It =>doesn't search search LD_LIBRARY_PATH -- it just tries to open() the =>filename in LD_PRELOAD relative to CWD and blows up if the architecture =>doesn't match the process. Other operating systems facilitate this sort =>of thing in various ways: => =>Solaris: LD_PRELOAD_32 and LD_PRELOAD_64 =>Linux: Search LD_LIBRARY_PATH, only fail if every attempt fails. Also, =>"$LIB" is magical. =>Mac OS X: Universal binaries => =>One (ugly) thought I had is to have the shared object file hook every =>function in the "exec" family and fix LD_PRELOAD so it points at the =>architecture of the binary about to be exec'd before delegating to the =>real exec. Anyone have a less ugly alternative that doesn't require =>modifying system files (e.g., adjusting ld.so)? Just a thought, but have you tried putting a 32-bit version of the library under /emul/netbsd32 ? Gary Duzan
LD_PRELOAD and mixed architectures
Hi all, I'm on an amd64 machine that has a mixture of i386 and amd64 binaries present. I want to build a shared object file and use LD_PRELOAD to inject it into every process in some process tree. The executables in the tree could be a mixture of amd64 and i386 executables. Many other operating systems have a way of using LD_PRELOAD in a mixed architecture environment, but I'm not seeing a path to victory on netbsd. I had a look at the source code for ld.so (the elf one anyway). It doesn't search search LD_LIBRARY_PATH -- it just tries to open() the filename in LD_PRELOAD relative to CWD and blows up if the architecture doesn't match the process. Other operating systems facilitate this sort of thing in various ways: Solaris: LD_PRELOAD_32 and LD_PRELOAD_64 Linux: Search LD_LIBRARY_PATH, only fail if every attempt fails. Also, "$LIB" is magical. Mac OS X: Universal binaries One (ugly) thought I had is to have the shared object file hook every function in the "exec" family and fix LD_PRELOAD so it points at the architecture of the binary about to be exec'd before delegating to the real exec. Anyone have a less ugly alternative that doesn't require modifying system files (e.g., adjusting ld.so)? - Dave
Re: specs for a netbsd build system?
On Sun, Jun 22, 2014 at 08:34:10AM -0400, Greg Troxel wrote: > > Mayuresh Kathe writes: > > > i have no idea about what kind of hardware would be required for > > performing an entire netbsd build within acceptable time-frames, > > say 1 hour (without x win). > > > > may i please get advice on rough specifications for the same? > > stuff like; > > 1. preferable processor (intel! amd!), > > 2. processing power (clock rate, number of cores, cache, etc), > > 3. memory (size and type), > > 4. hard disk (space and type), > > > > i have a budget of around us$600. > > Building all of NetBSD (with build.sh) takes some amount of time when > starting from scratch. Doing an update build (-u) means that most > things don't get rebuilt if nothing has changed, and is much faster. > > At this point, given that you want something PCish, you definitely want > to get something that can run in amd64 mode, so it can have more memory. > > I think as long as you have 50G of disk to devote to src/obj and 4G of > RAM, and a processor from the last 5 years, you'll be fine, assuming you > are just building only a few branch/arches. I can't see you wanting > more than 200G for NetBSD itself. (pkgsrc bulk builds are piggier; > there are ~1E4 packages.) > > As a concrete datapoint, I have a system (probably 1.5 years old): > > cpu0 at mainbus0 apid 0: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz, id 0x206a7 > cpu1 at mainbus0 apid 2: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz, id 0x206a7 > cpu2 at mainbus0 apid 4: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz, id 0x206a7 > cpu3 at mainbus0 apid 6: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz, id 0x206a7 > [hyperthreading disabled; note the even APID values] > total memory = 3569 MB > avail memory = 3497 MB > > running NetBSD/i386 for historical reasons, even though the box has > 16G of RAM. That's a clue that using only 3.5 of 16G has not annoyed > me enough to switch. But you should definitely start out in amd64 mode. > > 128G SSD for root/usr > 1T regular disk for other stuff > > This computer cost about $1100, with a nice case and power supply, > already built/tested (it's at work), but I don't really remember - it > might have been only $900. It's far more than you need, though. > > It does a full release build (all the way to ISO), including X, with -u > (and a previous build done) of the i386 sources in about 24 minutes. My > belief is that even if the very first time takes 8 hours, that's ok, > because you'll be doing -u most of the time. I think it takes one to a > few hours to do the first build, but I don't really know/remember > because it happens so rarely. I just start a script to build several > arches and check it the next day. > > I have source trees for 4/5/6/current, and obj/tooldir/destdir/releasedir > for multiple architectures, a total of 16 combinations. This is all > fitting in a 1T disk without really noticing it. My /usr/obj (which has > releasedir/destdir/tooldir in it also) for NetBSD-current and 7 > architectures is 58G. You definitely want to leave those and use -u. > > We also have a box with 12 real CPUs and 12G of RAM: > > cpu11 at mainbus0 apid 52: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, > id 0x206c2 > > and some SSD and some hardware raid scsi. It's definitely a lot faster > - I think it can do a full build with no objdir in 25 minutes -- but > it's way too expensive for your price point, rackmount, power-hungry, > etc. and also totally unnecessary. > > A further datapoint is that I have also used a machine with 1 CPU (with > hyperthreading) and 2G of RAM: > > cpu0 at mainbus0 apid 0: Intel 686-class, 3400MHz, id 0xf43 > > This was new in 2006. It would probably be a little too slow for you, > but I bet it would do. I built netbsd on it until a few years ago, and > stopped because I wanted to maintain fewer source trees with my > private tweaks, more than I wanted to avoid building on it. > > > Given that you said $600, I would try to get a 1T disk, 8G of RAM, and a > 4-core processor, backing away from the very top speeds that seem to > cost way extra, and put it together yourself. I haven't priced things > lately, so I don't know if that fits. The increase in speed lately has > been slowing, but newer motherboards do have faster memory that the > older ones, and caches are often bigger. But you may be able to get > some gamer friend's 3 year old system which is probably just fine. > > > The big question is getting a motherboard where the builtin graphics > works well with X, if you want to run that. thanks for the fantastic advice, your detailed mail is really helpful. i will not be going with x-win, i dislike it to the point of once leading a team which built a graphical operating environment running atop the linux graphics framebuffer (directly). we called it the "nevyos" effort. :) thanks again, ~mayuresh
Re: specs for a netbsd build system?
Mayuresh Kathe writes: > i have no idea about what kind of hardware would be required for > performing an entire netbsd build within acceptable time-frames, > say 1 hour (without x win). > > may i please get advice on rough specifications for the same? > stuff like; > 1. preferable processor (intel! amd!), > 2. processing power (clock rate, number of cores, cache, etc), > 3. memory (size and type), > 4. hard disk (space and type), > > i have a budget of around us$600. Building all of NetBSD (with build.sh) takes some amount of time when starting from scratch. Doing an update build (-u) means that most things don't get rebuilt if nothing has changed, and is much faster. At this point, given that you want something PCish, you definitely want to get something that can run in amd64 mode, so it can have more memory. I think as long as you have 50G of disk to devote to src/obj and 4G of RAM, and a processor from the last 5 years, you'll be fine, assuming you are just building only a few branch/arches. I can't see you wanting more than 200G for NetBSD itself. (pkgsrc bulk builds are piggier; there are ~1E4 packages.) As a concrete datapoint, I have a system (probably 1.5 years old): cpu0 at mainbus0 apid 0: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz, id 0x206a7 cpu1 at mainbus0 apid 2: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz, id 0x206a7 cpu2 at mainbus0 apid 4: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz, id 0x206a7 cpu3 at mainbus0 apid 6: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz, id 0x206a7 [hyperthreading disabled; note the even APID values] total memory = 3569 MB avail memory = 3497 MB running NetBSD/i386 for historical reasons, even though the box has 16G of RAM. That's a clue that using only 3.5 of 16G has not annoyed me enough to switch. But you should definitely start out in amd64 mode. 128G SSD for root/usr 1T regular disk for other stuff This computer cost about $1100, with a nice case and power supply, already built/tested (it's at work), but I don't really remember - it might have been only $900. It's far more than you need, though. It does a full release build (all the way to ISO), including X, with -u (and a previous build done) of the i386 sources in about 24 minutes. My belief is that even if the very first time takes 8 hours, that's ok, because you'll be doing -u most of the time. I think it takes one to a few hours to do the first build, but I don't really know/remember because it happens so rarely. I just start a script to build several arches and check it the next day. I have source trees for 4/5/6/current, and obj/tooldir/destdir/releasedir for multiple architectures, a total of 16 combinations. This is all fitting in a 1T disk without really noticing it. My /usr/obj (which has releasedir/destdir/tooldir in it also) for NetBSD-current and 7 architectures is 58G. You definitely want to leave those and use -u. We also have a box with 12 real CPUs and 12G of RAM: cpu11 at mainbus0 apid 52: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, id 0x206c2 and some SSD and some hardware raid scsi. It's definitely a lot faster - I think it can do a full build with no objdir in 25 minutes -- but it's way too expensive for your price point, rackmount, power-hungry, etc. and also totally unnecessary. A further datapoint is that I have also used a machine with 1 CPU (with hyperthreading) and 2G of RAM: cpu0 at mainbus0 apid 0: Intel 686-class, 3400MHz, id 0xf43 This was new in 2006. It would probably be a little too slow for you, but I bet it would do. I built netbsd on it until a few years ago, and stopped because I wanted to maintain fewer source trees with my private tweaks, more than I wanted to avoid building on it. Given that you said $600, I would try to get a 1T disk, 8G of RAM, and a 4-core processor, backing away from the very top speeds that seem to cost way extra, and put it together yourself. I haven't priced things lately, so I don't know if that fits. The increase in speed lately has been slowing, but newer motherboards do have faster memory that the older ones, and caches are often bigger. But you may be able to get some gamer friend's 3 year old system which is probably just fine. The big question is getting a motherboard where the builtin graphics works well with X, if you want to run that. pgpNmRtv_80Ss.pgp Description: PGP signature
Re: specs for a netbsd build system?
Mayuresh Kathe wrote: > i would be going for a new machine, primarily with the intent of > custom building netbsd for a particular tinkering project. > > i have no idea about what kind of hardware would be required for > performing an entire netbsd build within acceptable time-frames, > say 1 hour (without x win). > > may i please get advice on rough specifications for the same? > stuff like; > 1. preferable processor (intel! amd!), > 2. processing power (clock rate, number of cores, cache, etc), > 3. memory (size and type), > 4. hard disk (space and type), > > i have a budget of around us$600. I'm building on a two-year-old Intel Core i5-2500 quad-core machine with 16 GB RAM, with the source, object, and tools directories on tmpfs. I just did a full release build with the command build.sh -j 6 -D /tmp/bracket/build/2014.06.22.09.48.20-amd64/destdir -R /bracket/amd64/test/2014.06.22.09.48.20/release -T /tmp/bracket/build/2014.06.22.09.48.20-amd64/tools -O /tmp/bracket/build/2014.06.22.09.48.20-amd64/obj -m amd64 -U release iso-image and it took about 40 minutes: 2433.35 real 6561.26 user 1435.98 sys I think pretty much any recent quad-core Intel desktop or server CPU should meet your requirement provided you don't build on a hard disk - either get enough RAM to build on tmpfs, or get an SSD. Regards, -- Andreas Gustafsson, g...@gson.org
Re: install fails at newfs
On Sun, Jun 22, 2014 at 05:11:45PM +0530, Mayuresh Kathe wrote: > a wedge! i'll have to read up on it. > in the meanwhile, is it possible to eliminate the wedge and do a normal > install > on the wd0 device? Just use the dk0 device for the installation, it basically just is an alias for "wd0a". Martin
Re: install fails at newfs
On 2014-06-22 16:55, Martin Husemann wrote: On Sun, Jun 22, 2014 at 04:50:52PM +0530, Mayuresh Kathe wrote: i wonder what that "dk0" thing is. This is your problem. Auto-discovery code created a wedge for you - dmesg should tell you more details. this wedge covers parts of your wd0 drive (probably exactly wd0a), and makes the wd0 device "busy". If you use dk0 instead of wd0a everything should work fine. a wedge! i'll have to read up on it. in the meanwhile, is it possible to eliminate the wedge and do a normal install on the wd0 device? ~mayuresh
Re: install fails at newfs
On Sun, Jun 22, 2014 at 04:50:52PM +0530, Mayuresh Kathe wrote: > i wonder what that "dk0" thing is. This is your problem. Auto-discovery code created a wedge for you - dmesg should tell you more details. this wedge covers parts of your wd0 drive (probably exactly wd0a), and makes the wd0 device "busy". If you use dk0 instead of wd0a everything should work fine. Martin
Re: install fails at newfs
On 2014-06-22 16:36, Martin Husemann wrote: On Sun, Jun 22, 2014 at 04:21:12PM +0530, Mayuresh Kathe wrote: "ls -l /dev/rwd0a" reports the following; crw-r- 1 root operator 3, 0 Jun 22 10:14 /dev/rwd0a This all looks fine. Are you working with a custom kernel? What does sysctl hw.disknames say? no, it's just the generic kernel on the 6.1.4 install cd iso i got off the netbsd.org site. sysctl hw.disknames reports; hw.disknames = wd0 dk0 cd0 i wonder what that "dk0" thing is. thanks, ~mayuresh
Re: install fails at newfs
On Sun, Jun 22, 2014 at 04:21:12PM +0530, Mayuresh Kathe wrote: > "ls -l /dev/rwd0a" reports the following; > crw-r- 1 root operator 3, 0 Jun 22 10:14 /dev/rwd0a This all looks fine. Are you working with a custom kernel? What does sysctl hw.disknames say? Martin
Re: install fails at newfs
On 2014-06-22 15:39, Martin Husemann wrote: On Sun, Jun 22, 2014 at 03:36:23PM +0530, Mayuresh Kathe wrote: i tried re-running 'newfs' as below; /sbin/newfs -V2 -O 2 -b 32768 -f 4096 /dev/rwd0a it gave the same error as before (below); newfs: /dev/rwd0a: open for read: Device busy Interesting - what does "disklabel wd0" report? And just as a sanity check, "ls -l /dev/rwd0a"? "disklabel wd0" reports the following; # /dev/rwd0d: type: unknown disk: WDC WD5000AZRX- label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 969021 total sectors: 976773168 rpm: 3600 interleave: 1 track skew: 0 cylinder skew: 0 lread switch: 0 # microseconds track-to-track seek: 0 # microseconds drive data: 0 16 partitions: #size offset fstype [fsize bsize cpg/sgs] a: 968999472 63 4.2BSD4096 32768 0 # (Cyl. 0*- 961309*) b: 7773633 968999535swap# (Cyl. 961309*- 969020) c: 976773105 63 unused 0 0 # (Cyl. 0*- 969020) d: 976773168 0 unused 0 0 # (Cyl. 0*- 969020) "ls -l /dev/rwd0a" reports the following; crw-r- 1 root operator 3, 0 Jun 22 10:14 /dev/rwd0a thanks, ~mayuresh
Re: specs for a netbsd build system?
On Sun, Jun 22, 2014 at 8:54 AM, Mayuresh Kathe wrote: > hello, > > looks like my current machine is dying, hence all the problems with > even installing netbsd 6.1.4 on it. > > i would be going for a new machine, primarily with the intent of > custom building netbsd for a particular tinkering project. > > i have no idea about what kind of hardware would be required for > performing an entire netbsd build within acceptable time-frames, > say 1 hour (without x win). I am not exactly sure how long a full build takes on my various machines, of that order. The biggest improvement is to do incremental builds, or if it suits what you are doing to use rump kernel (10 minute full build). > may i please get advice on rough specifications for the same? > stuff like; > 1. preferable processor (intel! amd!), > 2. processing power (clock rate, number of cores, cache, etc), Basically you get roughly what you pay for here, but in a non linear way, so paying twice as much might give you say a 20% speed up. Cores help, but my 4 core fast machine (Xeon 3.5GHz) is a bit faster than my 8 core slower machine (Atom 2.4GHz) in compiling overall. > 3. memory (size and type), Builds do not need all that much memory, you wont see much benefit over say 4GB. The more cores you have the more memory you will need as you can do more parallel builds. > 4. hard disk (space and type), SSDs do give a performance increase, and are much cheaper now, especially if you do not need that much space. > > i have a budget of around us$600. Not sure what things cost in US... but I usually recommend spending a reasonably balanced amount on the different components.
Re: GPT questions - gpt reliability, wedge naming, and filesystem scaling.
On Sat, 21 Jun 2014, John Nemeth wrote: [snip] } See above. The thing I find annoying is that wedges/gpt partitions cannot } be resized. For this reason, when I move the relevant machines to -6 I'll } use lvm. GPT partitions can be resized in -current. However, there is no kernel support for resizing wedges, so you need to dkctl delwedge first, then dkctl addwedge afterwards. And, of course, there has to be space after the end of the wedge in order to increase the size. gpt(8) will not move data around by itself. OK, some improvement then, but still work to do. BTW, there is an issue in the LVM code somewhere when it comes to handling large volumes. I tried to create a large LV (I think around 6T) and if I recall right it got truncated down to 2T. Yes, I saw sommthing similar and had to specify the size manually. I think this was when resizing from <2TB to >2TB. In general though, I have had no problems with LV > 2TB and using resize_ffs. -- Stephen
Re: install fails at newfs
On Sun, Jun 22, 2014 at 03:36:23PM +0530, Mayuresh Kathe wrote: > i tried re-running 'newfs' as below; > /sbin/newfs -V2 -O 2 -b 32768 -f 4096 /dev/rwd0a > > it gave the same error as before (below); > newfs: /dev/rwd0a: open for read: Device busy Interesting - what does "disklabel wd0" report? And just as a sanity check, "ls -l /dev/rwd0a"? Martin
Re: install fails at newfs
On 2014-06-22 15:33, Martin Husemann wrote: On Sun, Jun 22, 2014 at 03:25:05PM +0530, Mayuresh Kathe wrote: did, here's the output; root_device on / type cd9660 (read-only, local) tmpfs on /dev type tmpfs (union, local) tmpfs on /tmp type tmpfs (local) tmpfs on /var type tmpfs (local) tmpfs on /etc type tmpfs (union, local) And in this state, can you re-run the newfs? I suppose something(tm) went wrong before and left the device mounted eroneously, which then caused further fallout. i tried re-running 'newfs' as below; /sbin/newfs -V2 -O 2 -b 32768 -f 4096 /dev/rwd0a it gave the same error as before (below); newfs: /dev/rwd0a: open for read: Device busy ~mayuresh
Re: install fails at newfs
On Sun, Jun 22, 2014 at 03:25:05PM +0530, Mayuresh Kathe wrote: > did, here's the output; > root_device on / type cd9660 (read-only, local) > tmpfs on /dev type tmpfs (union, local) > tmpfs on /tmp type tmpfs (local) > tmpfs on /var type tmpfs (local) > tmpfs on /etc type tmpfs (union, local) And in this state, can you re-run the newfs? I suppose something(tm) went wrong before and left the device mounted eroneously, which then caused further fallout. Martin
Re: install fails at newfs
On 2014-06-22 14:19, Martin Husemann wrote: On Sun, Jun 22, 2014 at 11:04:15AM +0530, Mayuresh Kathe wrote: it gave me the following error; newfs: /dev/rwd0a: open for read: Device busy You should check the output of mount in this case - it is probably already mounted somewhere. did, here's the output; root_device on / type cd9660 (read-only, local) tmpfs on /dev type tmpfs (union, local) tmpfs on /tmp type tmpfs (local) tmpfs on /var type tmpfs (local) tmpfs on /etc type tmpfs (union, local) as a check for hardware problems, i installed ubuntu 14.04 followed by openbsd 5.4, both installed quite successfully and smoothly. post that, retried installing netbsd 6.1.4, and dang, it failed at exactly the same point. any advice, suggestions and/or pointers to a solution would be more than welcome. thanks, ~mayuresh
Re: install fails at newfs
On 2014-06-22 14:19, Martin Husemann wrote: On Sun, Jun 22, 2014 at 11:04:15AM +0530, Mayuresh Kathe wrote: it gave me the following error; newfs: /dev/rwd0a: open for read: Device busy You should check the output of mount in this case - it is probably already mounted somewhere. will do, just can't figure how it can get mounted somewhere without being asked to. ~mayuresh
Re: GPT questions - gpt reliability, wedge naming, and filesystem scaling.
Date:Sun, 22 Jun 2014 07:23:26 +0100 From:Gerard Lally Message-ID: <20140622072322.94d6.280fc...@netmail.ie> | Luckily enough I came upon the instructions below, and booting worked | for me without issue: | | http://wiki.netbsd.org/users/jakllsch/gptboot/ Yes, that's what I used as a guide too. But I did it on a drive that was completely new, never partitioned by anything before, and that didn't work (where it did work fine on another drive that I initially set up the old way with MBR partitioning). I suspect that the GPT setup stuff is failing to set one (or more) of the MBR flags - or something like that - and the BIOS decides there's nothing bootable there (NetBSD doesn't yet support the newer boot partition method of booting.) But when it converts an existing MBR to a PMBR, it just changes the type and begin/end of partition 1, but leaves the rest of it alone, so we get the benefits of the initial fdisk setup. That's what I meant when I said you had kind of fluked on it - you did the MBR partitioning (for an entirely unrelated reason) and that allowed the GPT boot method to work. If I knew enough about MBRs and PC booting I'd see if I could produce a patch, but, alas, I don't ... | Aside: are you the same Robert | Elz who was involved from the outset in FFS? I have been involved with BSD since long before FFS, so in a sense, yes, however, also no, as I really had nothing to do with FFS, that's all Kirk McKusick's work. kre
Re: install fails at newfs
On Sun, Jun 22, 2014 at 11:04:15AM +0530, Mayuresh Kathe wrote: > it gave me the following error; > newfs: /dev/rwd0a: open for read: Device busy You should check the output of mount in this case - it is probably already mounted somewhere. Martin
specs for a netbsd build system?
hello, looks like my current machine is dying, hence all the problems with even installing netbsd 6.1.4 on it. i would be going for a new machine, primarily with the intent of custom building netbsd for a particular tinkering project. i have no idea about what kind of hardware would be required for performing an entire netbsd build within acceptable time-frames, say 1 hour (without x win). may i please get advice on rough specifications for the same? stuff like; 1. preferable processor (intel! amd!), 2. processing power (clock rate, number of cores, cache, etc), 3. memory (size and type), 4. hard disk (space and type), i have a budget of around us$600. thanks, ~mayuresh
