Enlarging a (virtual) disk
I've tried to build NetBSD-current at various points in the past few
months, and always hit one of two bugs: -current blows up with
a gcc Internal Compiler Error when crossbuilding on Mac OS X,
and kernel panics with native NetBSD builds with sources on NFS.
This stinks, and I've successfully managed to do a successful
-current build with sources on (local) disk. With NetBSD
running within VMware Fusion on Mac OS X.
To go on from there, I found that my NetBSD VM's only disk
was too small to do anything useful. Options for enlarging
that came to mind:
Option #3 was it, and after removing all VMware snapshots, enlarging the
disk was easy with VMware Fusion, going from 10GB to 20GB.
After growing the disk itself, the next question was how to use the
newly gained disk. Of course some file system needs to use it,
and in theory there are the following options:
- NFS - see 'panic' above, no go.
- Adding another (virtual) disk - easily doable, but I felt like not adding one
- Extending the existing disk - adventure time!
The disk was resized from 10GB to 20GB. The partition table
(disklabel) was created by a standard NetBSD install, and first
had the root file system, followed by the swap partition.
From that, adding 10GB more swap was not useful,
so I've decided to change the disklabel to add the new disk space
as a new partition behind the existing partitions.
This is also an excuse to not frob with
growfs and resize_ffs. (And of course I'm ignoring the option of backing up the full file system, doing a full rebuild of the filesystem
and then doing a restore :-)
- Enlarge the last file system on disk
- Fix the partition table to add another partition for the new space
For those in a similar situation, here are the steps to use
the newly gained space on an enlarged (virtual) disk:
Now let's see if I get things far enough to get a build
of g4u going... wish me luck!
- Prepare: save the old output of "dmesg" (/var/run/dmesg.boot is OK)
- Enlarge - VMware Fusion wants a shutdown for that, you cannot suspend
- After booting, run a diff on the saved "dmesg" output, to learn
what the old and new size of the disk is, in sectors. My diff looks
like this, note the size change in sectors:
-wd0: 10240 MB, 22192 cyl, 15 head, 63 sec, 512 bytes/sect x 20971520 sectors
+wd0: 20480 MB, 44384 cyl, 15 head, 63 sec, 512 bytes/sect x 41943040 sectors
- Backup the existing/old disklabel, just in case: disklabel wd0 >disklabel.BAK
- Edit the disklabel: disklabel -e wd0
- In the editor, adjust the disk size in sectors from 20971520 to 41943040:
total sectors: 41943040
- Partition 'd' is the full disk on i386/amd64, it starts at sector 0
and is 41943040 sectors big
# size offset fstype [fsize bsize cpg/sgs]
d: 41943040 0 unused 0 0 # (Cyl. 0 - 44384*)
- Partition 'c' is the NetBSD part of the disk. As this VM only has NetBSD, all the usable space is used. Note that "usable" space excludes the first 63 sectors of the disk (mbr etc.), i.e. it is 41943040 - 63 = 41942977 sectors:
# size offset fstype [fsize bsize cpg/sgs]
c: 41942977 63 unused 0 0 # (Cyl. 0*- 44384*)
- After this everything is in sync with the new disk again, and the remaining/new space can be used for new partition 'e'. As the new space starts where
the disk used to end, its offset is the old size, 20971520 sectors.
The size of the new partition expands from the offset sector 20971520
to the end of the disk at sector 41943040, i.e. the partition size is:
% expr 41943040 - 20971520
In total, this gives for the new partition:
# size offset fstype [fsize bsize cpg/sgs]
e: 20971520 20971520 4.2BSD 2048 16384 0 # (Cyl. 22192*- 44384*)
- Last, create file system, mount and populate:
# newfs /dev/rwd0e
# mkdir /disk2
# echo '/dev/wd0e /disk2 ffs rw,log 2 2' >>/etc/fstab
# mount /disk2
# cd /usr ; pax -rw -pe -v stuff /disk2
# rm -fr stuff ; ln -s /disk2/stuff .
P.S.: I'm offering choccolate to anyone fixing crossbuilding of
NetBSD-current from Mac OS X. Any takers?
[Tags: disklabel, fusion, g4u, vmware]
Digest: ssshfs, NAMP VMware image, Segvguard, BSDtalk and a daemonic bag
OK, I'm too lazy to put this into separate items, so here's
the stuff from today in one digest:
- There was some progress on puffs, the userland filesystem
stemming from last year's Google SoC, some time ago.
More example userland filesystems are now available with
sysctlfs and ssshfs, see
Rumours say that ssshfs works pretty well, which is
a final reason to ditch the (abandoned first cut of the) netbsd-4
branch and make a -current kernel to play with this. BTW, for those
wondering what ssshfs is, see
* simple sshfs
* (silly sshfs? stupid sshfs? snappy sshfs? sucky sshfs? seven sshfs???)
* (sante sshfs? severed (dreams) sshfs? saucy sshfs? sauerkraut sshfs?)
- People complained that there's no ready-made VMware image
with NetBSD available, and this has changed now.
The #NetBSD blog
points at a
NAMP (NetBSD + Apache + MySQL + PostgreSQL + PHP)
image that has quite a lot of software installed in
187MB size. See the
for more information on NAMP.
- Elad, chief security hacker of NetBSD's infrastructure has proposed
to add PaX Segvguard as yet another building stone in NetBSD's
PaX Segvguard monitors the number of segfaults in a program
per-user, in an attempt to detect on-going exploitation attempts
and possibly prevent them. One common attack PaX Segvguard can
help mitigate is when an attacker tries to brute-force a function
return address, when wanting to perform a return-to-lib attack.
See Elad's proposal
for more details! Note that a start of the implementation is
but that this is still work-in-progress.
did an interview with
pkgsrc developer Johnny Lam (jlam@), it's available in
- Last, if you don't know what to wish for Xmas, there's something
for the average BSD geek: a
(which is probably not really authorized by the Daemon owner,
[Tags: bsdtalk, images, puffs, Security, segvguard, ssh, vmware]
There were a number of interesting items in the past week or so
that I didn't manage to put here so far. Instead of putting them
into seperate entries, I'll take the liberty to assemble them
into one entry here:
So much for now. Enjoy!
- The Newsforge article
"Which distro should I choose?"
refers us to a
Comparison between NetBSD and OpenBSD,
the website apparently allows other comparisons.
``powerful, easy to use, cost effective desktop virtualization solution that empowers PC users with the ability to create completely networked, fully portable, entirely independent virtual machines on a single physical machine.''
In other words "something like VMware".
In contrast to the leading(?) product in that area,
Parallels supports NetBSD as guest OS officially.
is a PC-like computer from NEC that has a Intel CPU and that was
only sold in Japan. Due to some subtle differences from
the "original" (IBMesque) PC architecture, it can't run
NetBSD/i386 and was so far supported e.g. by FreeBSD/PC98.
Now, Kiyohara Takashi has made patches and a floppy image
available for a NetBSD/pc98 port - see
Kiyohara's mail to tech-kern for more details,
and also some discussion about further abstraction of the
current x86 architecture to support machines with Intel
CPUs that can't run NetBSD/i386.
- Staying on the technical side, David Young has a need to tunnel
packets through consumer-grade (and consumer-intelligence)
devices, which are unlikely to cope with anything outside of
the IP protocol. As such, he has posted patches to
tunnel gre(4) over UDP.
Now let's hope this works as a foundation for
Teredo (tunneling IPv6 over UDP)... :-)
- Verified Exec
is a security subsystem inside NetBSD that verified
fingerprints of binaries before loading them. This prevents
binaries from being changed unnoticed, e.g. by trojan horses.
Now when NetBSD runs such a system and memory becomes tight,
only the process' data is paged to disk, the executables text
is simply discarded with the assumption that it can be paged
in from the disk again when needed.
Of course this assumes that the binary won't change, which
may not be true in a networked scenario with NFS or a
disk on a fiber channel SAN that may be beyond control of the
local system administrator. To prevent attacks of this kind,
Brett Lymn has worked to generate per-page fingerprints that
are kept in memory even when the executable pages are freed,
for later verification when they are paged in from storage
The code is currently under review and available as a patch
set - see
Brett's mail to tech-kern
for all the details!
- While talking about security subsystems, Elad Efrat, who also
worked on veriexec previously continued his work to factor out
authentication inside the kernel: After introducing the
framework and replacing all manual checks for
"am I running as root" or "does the current secure level allow
this operating" with calls to it, the next step is to
seperate the the place where those calls are made from
a back-end implementation that will determine what is allowed
and what is not, who is privileged and what is not, etc.
While these questions are traditionally answered via special
user ids (0, root), group membership or secure levels,
other methods like capability databases could be imagined.
Elad has been working along these lines, and he has posted
the next step in his work, outlining the upcoming
security model abstraction - see
Elad's mail to tech-security
for details & code references.
- NetBSD 3.1 is around the corner, which will be an update to
NetBSD 3.0 with lots of bugfixes and some minor feature enhancements
like new drivers and also support for Xen 3 DomainU.
NetBSD 3.1 Release Candidate 1
available - be sure to have a look!
- FWIW, I've also updated the
overview of NetBSD release branches
a few days ago, as I still see a lot of people that are
confused over NetBSD's three lines of release branches
(well, counting the development branch NetBSD-current as release
branch :), and the differences between what a branch and what
a release is.
With NetBSD 3.0, 3.0.1 and 3.1 this sure makes my little head spin...
- But there's more than NetBSD 3.x! If you've watched the above
link, you will understand that the next release after the
NetBSD 3.x set of releases is NetBSD 4.x.
The release cycle for NetBSD 4.0 has started a few days
ago, and there's also
an announcement about the start of the NetBSD 4.0 release process
by the NetBSD 4.0 release engineer Jef Rizzo which has information
on schedule, how YOU can help and getting beta binaries and sources.
- The working period of the Google Summer of Code is over, and
while mentors are still evaluating the code submitted by students,
there are some public status reports:
Alwe MainD'argent about the status of the 'ipsec6' project
Sumantra Kundu about the 'congest' project
- Sysjail 1.0 has been released!
Includes some interesting
- As reported in the #NetBSD Community Blog,
an alpha version of
was released: It's a NetBSD-based system for easy installation
on USB sticks and CF cards.
[Tags: Articles, google-soc, gre, kauth, networking, openbsd, parallels, pc98, releases, sbsd, Security, sysjail, veriexec, vmware]
NetBSD on VMware ESX 3.0 RC1 VM with 2 VCPUs
Stephan 'kobold' Gehring mentioned on IRCnet #NetBSD that
NetBSD 3.0 runs nicely inside a VMware ESX 3.0 RC1 VM with 2 VCPUs
(virtual CPUs within VMware). The
dmesg output he posted
contains both the devices found by the INSTALL kernel
as well as by the GENERIC.MP, which properly recognizes
Do you want NetBSD support for VMware?
If so, voice your desire!
[Tags: polls, software, vmware]
Grab the RSS-feed,
or go back to my regular NetBSD page
Disclaimer: All opinion expressed here is purely my own.
No responsibility is taken for anything.