Hi Folks, As usual, trust me to come up with the unusual. I''m planning ahead for future expansion and running tests. Unfortunately until 2010-2 comes out I''m stuck with 111b (no way to upgrade to anything than 130, which gives me problems) Anyway, here is the situation. Initial installation drive is a 40gig drive given over to Open Solaris. Second drive is an 80 gig drive. The aim is to mirror the operating system in a way that I can remove the 40gig drive form the system and have the 80 gig drive boot. At this point, you''re probably thinking that you''ve heard it all before. I believe that the drive size difference is causing a problem. I kill the EFI partition and set up a Solaris partition. Yes, I even reboot the box to ensure that the Solaris partition has stuck. I run the usual ... prtvtoc /dev/rdsk/c4t0d0s2 | fmthard -s ? /dev/rdsk/c4t1d0s2 ... command and it is here that I think something is going wrong ... ... because when I add the drive to the zpool, it flips the partition back to EFI, which means my grub installation is useless. Some extra information is that I can''t add c19d0s0 - I have to add c19d0. This could be one point where it is reverting it to EFI. If I try to add c19d0s0 I get, "cannot open ''/dev/dsk/c19d0s0'': No such device or address" ... which makes me think that the fmthard is putting wrong information on to the 80gig drive because the "slice" sizes will be different. Have I reached the right conclusion? If so, how do I get around this? Do I have to somehow manually slice the drive up? -- This message posted from opensolaris.org
A bit more information... this is what I''ve used the all free hog to generate.... Part Tag Flag Cylinders Size Blocks 0 unassigned wm 3 - 9725 74.48GB (9723/0/0) 156199995 1 unassigned wm 0 0 (0/0/0) 0 2 backup wu 0 - 9725 74.50GB (9726/0/0) 156248190 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wm 0 0 (0/0/0) 0 8 boot wu 0 - 0 7.84MB (1/0/0) 16065 9 alternates wm 1 - 2 15.69MB (2/0/0) 32130 ...and when I attempt to add c19d0s0 to the pool, I get... mich at cougar:~# zpool attach rpool c7d0s0 c19d0s0 invalid vdev specification use ''-f'' to override the following errors: /dev/dsk/c19d0s0 overlaps with /dev/dsk/c19d0s2 Is it OK for me to use the -f or have I got something critically wrong here? -- This message posted from opensolaris.org
Hi Michelle, Your previous mail about the disk label reverting to EFI makes me wonder whether you used the format -e option to relabel the disk, but your disk label below looks fine. This also might be a known bug (6419310), whose workaround is to use the -f option to zpool attach. An interim test would be to create a test pool with c19d0s0, like this: # zpool create test c19d0s0 If that works, then destroy the test pool and try to attach it to the root pool. If it complains again, then use the -f option. Thanks, Cindy On 01/28/10 15:29, Michelle Knight wrote:> A bit more information... this is what I''ve used the all free hog to generate.... > Part Tag Flag Cylinders Size Blocks > 0 unassigned wm 3 - 9725 74.48GB (9723/0/0) 156199995 > 1 unassigned wm 0 0 (0/0/0) 0 > 2 backup wu 0 - 9725 74.50GB (9726/0/0) 156248190 > 3 unassigned wm 0 0 (0/0/0) 0 > 4 unassigned wm 0 0 (0/0/0) 0 > 5 unassigned wm 0 0 (0/0/0) 0 > 6 unassigned wm 0 0 (0/0/0) 0 > 7 unassigned wm 0 0 (0/0/0) 0 > 8 boot wu 0 - 0 7.84MB (1/0/0) 16065 > 9 alternates wm 1 - 2 15.69MB (2/0/0) 32130 > > ...and when I attempt to add c19d0s0 to the pool, I get... > > mich at cougar:~# zpool attach rpool c7d0s0 c19d0s0 > invalid vdev specification > use ''-f'' to override the following errors: > /dev/dsk/c19d0s0 overlaps with /dev/dsk/c19d0s2 > > Is it OK for me to use the -f or have I got something critically wrong here?
On Jan 28, 2010, at 2:23 PM, Michelle Knight wrote:> Hi Folks, > > As usual, trust me to come up with the unusual. I''m planning ahead for future expansion and running tests. > > Unfortunately until 2010-2 comes out I''m stuck with 111b (no way to upgrade to anything than 130, which gives me problems) > > Anyway, here is the situation. > > Initial installation drive is a 40gig drive given over to Open Solaris. > Second drive is an 80 gig drive. > > The aim is to mirror the operating system in a way that I can remove the 40gig drive form the system and have the 80 gig drive boot. > > At this point, you''re probably thinking that you''ve heard it all before. > > I believe that the drive size difference is causing a problem. > > I kill the EFI partition and set up a Solaris partition. Yes, I even reboot the box to ensure that the Solaris partition has stuck. > > I run the usual ... prtvtoc /dev/rdsk/c4t0d0s2 | fmthard -s ? /dev/rdsk/c4t1d0s2 ... command and it is here that I think something is going wrong ...Don''t do that. You are basically copying the label for a 40 GB drive onto an 80 GB drive, which magically transforms the 80 GB drive into (presto change-o!) a 40 GB drive. Use format(1m) and setup the SMI label and partitions as you need. [I consider prtvtoc | fmthard to be a virus :-(] On Jan 28, 2010, at 2:29 PM, Michelle Knight wrote:> A bit more information... this is what I''ve used the all free hog to generate.... > Part Tag Flag Cylinders Size Blocks > 0 unassigned wm 3 - 9725 74.48GB (9723/0/0) 156199995 > 1 unassigned wm 0 0 (0/0/0) 0 > 2 backup wu 0 - 9725 74.50GB (9726/0/0) 156248190 > 3 unassigned wm 0 0 (0/0/0) 0 > 4 unassigned wm 0 0 (0/0/0) 0 > 5 unassigned wm 0 0 (0/0/0) 0 > 6 unassigned wm 0 0 (0/0/0) 0 > 7 unassigned wm 0 0 (0/0/0) 0 > 8 boot wu 0 - 0 7.84MB (1/0/0) 16065 > 9 alternates wm 1 - 2 15.69MB (2/0/0) 32130 > > ...and when I attempt to add c19d0s0 to the pool, I get... > > mich at cougar:~# zpool attach rpool c7d0s0 c19d0s0 > invalid vdev specification > use ''-f'' to override the following errors: > /dev/dsk/c19d0s0 overlaps with /dev/dsk/c19d0s2 > > Is it OK for me to use the -f or have I got something critically wrong here?This is annoying protectionism. If the disk does not currently contain data you care about, go ahead and use -f. -- richard
Many thanks, I''ll try that tonight. -- This message posted from opensolaris.org
I have to admit that fmthard does appear to be a bit of a sledgehammer in this case. I thought I was doing wrong with that, but you''ve confirmed that now. -- This message posted from opensolaris.org
Hey Msknight, Try following the steps posted at this blog and tell me if they work for you: http://darkstar-solaris.blogspot.com/2008/09/zfs-root-mirror.html -- This message posted from opensolaris.org
Hi System5, They look like the steps I followed here... http://letsgetdugg.com/2009/10/18/zfs-boot-mirror-setup/ ...which didn''t work. I''m going to use the -f option and see what happens. -- This message posted from opensolaris.org
Well, I nearly got there. I used -f to force the overwrite and then installed grub to slice 8 (which seemed to have the boot) but when I boot from the larger hard disk I get ... GNU GRUB version 0.97 (688.... [ Minimal BASH-like line editing is supported... lists possible command completions... competions of a device/filename. ] grub> ...and I don''t know enough about grub commands to go further than this. For reference, here is the finished partition table ... everything was put on there automatically except for the free hog on slice 0... Total disk cylinders available: 9726 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 unassigned wm 3 - 9725 74.48GB (9723/0/0) 156199995 1 unassigned wm 0 0 (0/0/0) 0 2 backup wu 0 - 9725 74.50GB (9726/0/0) 156248190 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wm 0 0 (0/0/0) 0 8 boot wu 0 - 0 7.84MB (1/0/0) 16065 9 alternates wm 1 - 2 15.69MB (2/0/0) 32130 ...and the command I used to install GRUB was... installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c19d0s8 ...which I used because slice 8 appeared to be the book in the partition table. -- This message posted from opensolaris.org
Hi Michelle, You''re almost there, but install the bootblocks in s0: # installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c19d0s0 Thanks, Cindy On 01/29/10 11:10, Michelle Knight wrote:> Well, I nearly got there. I used -f to force the overwrite and then installed grub to slice 8 (which seemed to have the boot) but when I boot from the larger hard disk I get ... > > GNU GRUB version 0.97 (688.... > [ Minimal BASH-like line editing is supported... > lists possible command completions... > competions of a device/filename. ] > grub> > > ...and I don''t know enough about grub commands to go further than this. > > For reference, here is the finished partition table ... everything was put on there automatically except for the free hog on slice 0... > > Total disk cylinders available: 9726 + 2 (reserved cylinders) > > Part Tag Flag Cylinders Size Blocks > 0 unassigned wm 3 - 9725 74.48GB (9723/0/0) 156199995 > 1 unassigned wm 0 0 (0/0/0) 0 > 2 backup wu 0 - 9725 74.50GB (9726/0/0) 156248190 > 3 unassigned wm 0 0 (0/0/0) 0 > 4 unassigned wm 0 0 (0/0/0) 0 > 5 unassigned wm 0 0 (0/0/0) 0 > 6 unassigned wm 0 0 (0/0/0) 0 > 7 unassigned wm 0 0 (0/0/0) 0 > 8 boot wu 0 - 0 7.84MB (1/0/0) 16065 > 9 alternates wm 1 - 2 15.69MB (2/0/0) 32130 > > ...and the command I used to install GRUB was... > > installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c19d0s8 > > ...which I used because slice 8 appeared to be the book in the partition table.
Hi Cindy, Won''t I have a problem putting the grub in slice 0 when it is also allocated to the zpool? Or do the two co-exist? I''ve been trying to shift the boot partition from slice 8 to slice 0, and then make slice 1 the hog, but I just can''t get to grips with the partition command in order to make that happen ... or have I got it all wrong? Michelle. -- This message posted from opensolaris.org
Well blow me down with a feather ... it worked!!!! Many thanks folks. I''m going to make a little video about this process on You Tube and hope it helps someone else. -- This message posted from opensolaris.org
Michelle, Yes, the bootblocks and the pool coexist, even happily sometimes. In general, you shouldn''t have to deal with the boot partition stuff that you see in the disk format output. If I could hide all this low- level stuff from you, I would, because its so dang confusing. Looks like you got it to work. Thanks for hanging in there. Cindy ----- Original Message ----- From: Michelle Knight <michelle at msknight.com> Date: Saturday, January 30, 2010 6:34 am Subject: Re: [zfs-discuss] zfs rpool mirror on non-equal drives To: zfs-discuss at opensolaris.org> Hi Cindy, > > Won''t I have a problem putting the grub in slice 0 when it is also > allocated to the zpool? Or do the two co-exist? > > I''ve been trying to shift the boot partition from slice 8 to slice 0, > and then make slice 1 the hog, but I just can''t get to grips with the > partition command in order to make that happen ... or have I got it > all wrong? > > Michelle. > -- > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Sat, Jan 30, 2010 at 2:02 AM, Cindy Swearingen <Cindy.Swearingen at sun.com> wrote:> Hi Michelle, > > You''re almost there, but install the bootblocks in s0: > > # installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c19d0s0One question. I thought "-m" installs in MBR (thus not really installing in "s0", like your description)? Shouldn''t it be fine without "-m"? -- Fajar
Another question ... I did this as a test because I am aware that zpools don''t like drives switching controlers without being exported first. The question was, what would a rpool boot drive do if it was put on a different controller and then booted? I shut down, took away c7 and hooked c19 up to the SATA cable that I used to connect c7 to ... just out of interest to see what would happen. I was half expecting it to have a problem booting, and half expecting it to come up as c7 ... but it still came up as c19 in the zpool status. Any idea why? -- This message posted from opensolaris.org
On Jan 30, 2010, at 10:27 AM, Michelle Knight wrote:> Another question ... > > I did this as a test because I am aware that zpools don''t like drives switching controlers without being exported first. The question was, what would a rpool boot drive do if it was put on a different controller and then booted?It does the right thing.> I shut down, took away c7 and hooked c19 up to the SATA cable that I used to connect c7 to ... just out of interest to see what would happen. > > I was half expecting it to have a problem booting, and half expecting it to come up as c7 ... but it still came up as c19 in the zpool status. Any idea why?During boot, grub will locate the pool and get it started. Did you notice that the grub menu does not mention specific disks and uses findroot instead? :-) -- richard
I did notice the findroot command, but I don''t know what I''m doing when it comes to Grub. The video is up http://www.youtube.com/watch?v=tpzsSptzmyA - just me droning on for ten minutes and it is aimed at people following me, so I do a lot of explaining the basics. I have to agree with a previous poster in that I''d rather use fdisk and partition, than the fmthard command. In general I have problems reading the man pages because they are a documentation of the commands and their options; as a beginner I can''t understand them ... which is why forums like this are a life saver for people like me. Thanks to all for the help. -- This message posted from opensolaris.org
Richard already addressed this process, but I do this basic concept all the time (moving to a larger disk or new computer). I simply create the partition on the new disk with format, then "zpool attach -f" the larger drive. Once done mirroring, use installgrub as normal. Remove the smaller drive and you''re done. You get the new, larger capacity in my experience. I''ve done this several times without an issue. This is a bit of an abbreviation, but don''t overthink it. I''ve also used this to migrate to a new computer with larger disks. The only caveat I''ve run into is you need to move from SATA/AHCI to the same, or SATA/IDE to the same. They can be different controllers, but for me they have to match their AHCI mode. I''m sure someone has a method to address that issue. -- This message posted from opensolaris.org
This comment has only to do with booting an old drive on a different computer--a bit of a tangent to this discussion: I''ve also used this to migrate to a new computer with larger disks. The only caveat I''ve run into is you need to move from SATA/AHCI to the same, or SATA/IDE to the same. They can be different controllers, but for me they have to match their AHCI mode. I''m sure someone has a method to address that issue. -- This message posted from opensolaris.org
On January 30, 2010 10:27:41 AM -0800 Michelle Knight <michelle at msknight.com> wrote:> I did this as a test because I am aware that zpools don''t like drives > switching controlers without being exported first.They don''t mind it at all. It''s one of the great things about zfs. What they do mind is being remounted on a system with a different hostid without having been exported first. -frank
You are correct. Should be fine without -m. Thanks, Cindy On 01/30/10 09:15, Fajar A. Nugraha wrote:> On Sat, Jan 30, 2010 at 2:02 AM, Cindy Swearingen > <Cindy.Swearingen at sun.com> wrote: >> Hi Michelle, >> >> You''re almost there, but install the bootblocks in s0: >> >> # installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c19d0s0 > > One question. I thought "-m" installs in MBR (thus not really > installing in "s0", like your description)? Shouldn''t it be fine > without "-m"? >