HEADS up on HEAD

YONETANI Tomokazu qhwt+dfly at les.ath.cx
Fri May 18 23:04:51 PDT 2007


On Fri, May 18, 2007 at 10:15:46PM -0700, Matthew Dillon wrote:
> 
> :I'm a long-time follower of HEAD, but I admit I don't understand the
> :implications of your warning.
> :
> :If I build world+kernel now, what kind of tasks should I expect to have
> :trouble with?
> :
> :To be specific, I'm running DF from an extended partition (a bit out
> :of the ordinary) /dev/ad1s9a.  Should I expect problems if I update
> :just now?
> :
> :Thanks!
> 
>     Well.  I've done my best to test things so hopefully nobody will get
>     blown up.  I did test a simple extended partition so it should be ok.
> 
>     But, it might be a good idea to do a backup first, just in case.  I am
>     messing with the low level disk partitioning code after all!
> 
>     Here's what I would do.
> 
>     * cp /kernel /kernel.bak
> 
>     * buildkernel blah blah, installkernel blah blah, reboot
> 
>     It should be able to reboot, the mount device minors don't change,
>     only the master raw device and the slice devices, so the new kernel
>     should be able to mount everything up even though the devices in /dev
>     haven't been upgraded yet.
> 
>     If it reboots and mounts the hard disks ok, try the rest of the update.
> 
>     * buildworld, installworld, make upgrade
> 
>     * I don't think make upgrade will go that deep into the disk devices,
>       so after you make upgrade you will have to finish adding the devices
>       manually.  Here's a cute trick:
> 
>     cd /dev
>     ./MAKEDEV ad*s*a
> 
>     I still have a bunch more to do.  Only one major piece left that can
>     potentially blow things up, but after that the disklabel will be 
>     disconnected enough from the disk management code that I can abstract
>     it out into a pluggable API and start working on GPT.

As you expected, my ccd partitions(/var/obj and /home) no longer mount.
Do I need to dump & restore filesystems on a ccd device after the changes
to ccd device?
Anyway, here's my /etc/ccd.conf:
  ccd0 1152 none /dev/ad0s1e /dev/ad1s1e
  ccd1 16 CCDF_MIRROR,CCDF_UNIFORM /dev/ad0s1g /dev/ad1s1g
and /etc/fstab:
  /dev/ad0s1b	none		swap	sw		0	0
  /dev/ad1s1b	none		swap	sw		0	0
  /dev/ad0s1h	/		ufs	rw		1	2
  /dev/ad0s1a	/D		ufs	rw,noauto	1	1
  /dev/ad1s1d	/var		ufs	rw		2	1
  /dev/ad0s1f	/u		ufs	rw		2	3
  /dev/ccd0a	/var/obj	ufs	rw		2	4
  /dev/ccd1a	/home		ufs	rw		2	5
  /dev/ad1s1f	/home/source	ufs	rw		2	2
  /dev/acd0c	/cdrom		cd9660	ro,noauto	0	0
  proc		/proc		procfs	rw		0	0

and the boot message relavant to CCD configuration (some of the message
from fsck are mixed up because it thinks ccd0 and ccd1 are diffent devices?):

  Configuring CCD devices.
  ccdconfig: open: /dev/ccd0: Invalid argument
  ccdconfig: open: /dev/ccd1: Invalid argument
  ad1s1: type 0xa5, start 63, end = 117226304, size 117226242 : OK
  swapon: adding /dev/ad1s1b as swap device
  Starting file system checks:
  /dev/ad0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS
  /dev/ad0s1a: clean, 197090 free (3930 frags, 24145 blocks, 0.8% fragmentation)
  /dev/ad0s1d: FILESYSTEM CLEAN; SKIPPING CHECKS
  /dev/ad0s1d: clean, 463893 free (325 frags, 57946 blocks, 0.1% fragmentation)
  ccd0t127: reading primary partition table: error writing offset 000000000000 for 512
  ccd1t127: reading primary partition table: error writing offset 000000000000 for 512
  Can't open /dev/ccd0a: Input/output error
  Can't open /dev/ccd1a: Input/output error
  /dev/ccd0a: /dev/ccd1a: CAN'T CHECK FILE SYSTEM.CAN'T CHECK FILE SYSTEM.
  /dev/ccd1a: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

  /dev/ccd0a: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
  /dev/ad0s1h: FILESYSTEM CLEAN; SKIPPING CHECKS
  /dev/ad0s1h: clean, 202415 free (4151 frags, 24783 blocks, 0.8% fragmentation)
  /dev/ad1s1f: FILESYSTEM CLEAN; SKIPPING CHECKS
  /dev/ad1s1f: clean, 4980795 free (240339 frags, 592557 blocks, 3.0% fragmentation)
  /dev/ad0s1f: FILESYSTEM CLEAN; SKIPPING CHECKS
  /dev/ad0s1f: clean, 5801971 free (19355 frags, 722827 blocks, 0.3% fragmentation)
  THE FOLLOWING FILE SYSTEMS HAD AN UNEXPECTED INCONSISTENCY;
	  /dev/ccd1a (/home), /dev/ccd0a (/var/obj)

I haven't seen any other issues.  I can post any other information on request.
Cheers.





More information about the Kernel mailing list