zfs discuss - Jan 2010 - cannot attach c5d0s0 to c4d0s0: device is too small

cannot attach c5d0s0 to c4d0s0: device is too small

So I guess I installed OpenSolaris onto the smallest disk. Now I cannot
create a mirrored root, because the device is smaller.
What is the best way to correct this except starting all over with two
disks of the same size (which I don''t have)?

Do I zfs send the stream to the smallest disk and will the bigger one
attach itself? Or is there another way. I need redundency, so I hope to
get answers soon. ;-)

Hi Dick,

Based on this message:
cannot attach c5d0s0 to c4d0s0: device is too small

c5d0s0 is the disk you are trying to attach so it must be smaller than
c4d0s0.

Is it possible that c5d0s0 is just partitioned so that the s0 is smaller 
than s0 on c4d0s0?

On some disks, the default partitioning is not optimal and you have to
modify it so that the bulk of the disk space is in slice 0.

I would confirm this first as its the easiest solution by far.

Another thought is that a recent improvement was that you can attach a
disk that is an equivalent size, but not exactly the same geometry.
Which OpenSolaris release is this?

Thanks,

Cindy

On 01/27/10 15:26, dick hoogendijk wrote:
> cannot attach c5d0s0 to c4d0s0: device is too small
> 
> So I guess I installed OpenSolaris onto the smallest disk. Now I cannot
> create a mirrored root, because the device is smaller.
> What is the best way to correct this except starting all over with two
> disks of the same size (which I don''t have)?
> 
> Do I zfs send the stream to the smallest disk and will the bigger one
> attach itself? Or is there another way. I need redundency, so I hope to
> get answers soon. ;-)
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Cindy Swearingen wrote:
> On some disks, the default partitioning is not optimal and you have to
> modify it so that the bulk of the disk space is in slice 0.
Yes, I know, but in this case the second disk indeed is smaller ;-(
So I wonder, should I reinstall the whole thing on this smaller disk and
thren let the bigger second attach? That would mean opening up the case
and all that, because I don''t have a DVD player built in.
So I thought I''d go the zfs send|recv way. What are yout thoughts about
this?
> Another thought is that a recent improvement was that you can attach a
> disk that is an equivalent size, but not exactly the same geometry.
> Which OpenSolaris release is this?
b131
And this only works if the difference is realy (REALLY) small. :)

-- 
Dick Hoogendijk -- PGP/GnuPG key: F86289CE
+http://nagual.nl/ | SunOS 10u7 05/09 ZFS+

Hi Dick,

Yes, you can use zfs send|recv to recreate the root pool snapshots on
the other disk in addition to the other steps that are needed for full
root pool recovery is my assessment. See the link below, following the
steps for storing the root pool snapshots as snapshots rather than
files. I should attempt a similar migration to see how it goes since
I''ve only tested this recovery going from a local-->remote system
and
back, but not having two potential root pools on the same system. (?)

Maybe someone else can advise better but to me your choices are to
recreate the root pool on the second disk or reinstall. Or, if
possible, connect another larger disk and attach it to the original root 
disk or even replace the smaller root pool disk with the larger disk.

Thanks,

Cindy

http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide

ZFS Root Pool Recovery



On 01/28/10 07:55, dick hoogendijk wrote:
> Cindy Swearingen wrote:
> 
>> On some disks, the default partitioning is not optimal and you have to
>> modify it so that the bulk of the disk space is in slice 0.
> 
> Yes, I know, but in this case the second disk indeed is smaller ;-(
> So I wonder, should I reinstall the whole thing on this smaller disk and
> thren let the bigger second attach? That would mean opening up the case
> and all that, because I don''t have a DVD player built in.
> So I thought I''d go the zfs send|recv way. What are yout thoughts
about this?
> 
>> Another thought is that a recent improvement was that you can attach a
>> disk that is an equivalent size, but not exactly the same geometry.
>> Which OpenSolaris release is this?
> 
> b131
> And this only works if the difference is realy (REALLY) small. :)
>

On 28.01.2010 15:55, dick hoogendijk wrote:
> 
> Cindy Swearingen wrote:
> 
>> On some disks, the default partitioning is not optimal and you have to
>> modify it so that the bulk of the disk space is in slice 0.
> 
> Yes, I know, but in this case the second disk indeed is smaller ;-(
> So I wonder, should I reinstall the whole thing on this smaller disk and
> thren let the bigger second attach? That would mean opening up the case
> and all that, because I don''t have a DVD player built in.
> So I thought I''d go the zfs send|recv way. What are yout thoughts
about this?
> 
>> Another thought is that a recent improvement was that you can attach a
>> disk that is an equivalent size, but not exactly the same geometry.
>> Which OpenSolaris release is this?
> 
> b131
> And this only works if the difference is realy (REALLY) small. :)
> 
have you considered creating an alternate boot environment on the
smaller disk, rebooting into this new boot environment, and then
attaching the larger disk after destroy the old boot environment?

beadm might do this job for you...

Thomas,

Excellent and much better suggestion... :-)

You can use beadm to specify another root pool by using the -p option.
The beadm operation will set the bootfs pool property and update the
GRUB entry.

Dick, you will need to update the BIOS to boot from the smaller disk.

Thanks,

Cindy



On 01/28/10 08:52, Thomas Maier-Komor wrote:
> On 28.01.2010 15:55, dick hoogendijk wrote:
>> Cindy Swearingen wrote:
>>
>>> On some disks, the default partitioning is not optimal and you have
to
>>> modify it so that the bulk of the disk space is in slice 0.
>> Yes, I know, but in this case the second disk indeed is smaller ;-(
>> So I wonder, should I reinstall the whole thing on this smaller disk
and
>> thren let the bigger second attach? That would mean opening up the case
>> and all that, because I don''t have a DVD player built in.
>> So I thought I''d go the zfs send|recv way. What are yout
thoughts about this?
>>
>>> Another thought is that a recent improvement was that you can
attach a
>>> disk that is an equivalent size, but not exactly the same geometry.
>>> Which OpenSolaris release is this?
>> b131
>> And this only works if the difference is realy (REALLY) small. :)
>>
> 
> have you considered creating an alternate boot environment on the
> smaller disk, rebooting into this new boot environment, and then
> attaching the larger disk after destroy the old boot environment?
> 
> beadm might do this job for you...

Op 28-1-2010 16:52, Thomas Maier-Komor schreef:
> have you considered creating an alternate boot environment on the
> smaller disk, rebooting into this new boot environment, and then
> attaching the larger disk after destroy the old boot environment?
>
> beadm might do this job for you...
>    
What a great idea. Are there any special preparations I have to do on 
the second smaller disk before I can create this ABE? It sounds like the 
simplest option after installing new hardware. ;-) I guess it''s enough 
if the disk has a sun partitionon it?

Op 28-1-2010 17:35, Cindy Swearingen schreef:
> Thomas,
>
> Excellent and much better suggestion... :-)
>
> You can use beadm to specify another root pool by using the -p option.
> The beadm operation will set the bootfs pool property and update the
> GRUB entry.
>
> Dick, you will need to update the BIOS to boot from the smaller disk.
Yes yes yes. It''s a great idea. So, I first create thsi new root pool
on
the smaller disk and then I use beadm?
I can''t use the same name (rpool) I guess.

Op 28-1-2010 17:35, Cindy Swearingen schreef:
> Thomas,
>
> Excellent and much better suggestion... :-)
>
> You can use beadm to specify another root pool by using the -p option.
> The beadm operation will set the bootfs pool property and update the
> GRUB entry.
>
> Dick, you will need to update the BIOS to boot from the smaller disk.
It''s not that great an idea after all. Creating a new ABE in the new 
root pool goes wel, BUT all other files systems on rpool (rpool/export, 
export/home, etc) don''t get transfered. So, attaching is not possible 
because ''/export/home/me'' is busy ;-)

On 01/28/10 12:05, Dick Hoogendijk wrote:
> Op 28-1-2010 17:35, Cindy Swearingen schreef:
>> Thomas,
>>
>> Excellent and much better suggestion... :-)
>>
>> You can use beadm to specify another root pool by using the -p option.
>> The beadm operation will set the bootfs pool property and update the
>> GRUB entry.
>>
>> Dick, you will need to update the BIOS to boot from the smaller disk.
> It''s not that great an idea after all. Creating a new ABE in the
new
> root pool goes wel, BUT all other files systems on rpool 
> (rpool/export, export/home, etc) don''t get transfered. So,
attaching
> is not possible because ''/export/home/me'' is busy ;-)
But those could be copied by send/recv from the larger disk (current 
root pool) to the smaller disk (intended new root pool).  You won''t be 
attaching anything until you can boot off the smaller disk and then it 
won''t matter what''s on the larger disk because attaching the
larger disk
to the root  mirror will destroy the contents of the larger disk anyway.

lori


> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Thu, 2010-01-28 at 12:34 -0700, Lori Alt wrote:
> But those could be copied by send/recv from the larger disk (current 
> root pool) to the smaller disk (intended new root pool).  You
won''t be
> attaching anything until you can boot off the smaller disk and then it 
> won''t matter what''s on the larger disk because attaching
the larger disk
> to the root  mirror will destroy the contents of the larger disk anyway.
You are right of course.
Are these right values for amd64 swap/dump:
zfs create -V 2G rpool/dump
zfs create -V 2G -b 4k rpool/swap
Are these -b 4k values OK?

On 01/28/10 14:08, dick hoogendijk wrote:
> On Thu, 2010-01-28 at 12:34 -0700, Lori Alt wrote:
>   
>> But those could be copied by send/recv from the larger disk (current 
>> root pool) to the smaller disk (intended new root pool).  You
won''t be
>> attaching anything until you can boot off the smaller disk and then it 
>> won''t matter what''s on the larger disk because
attaching the larger disk
>> to the root  mirror will destroy the contents of the larger disk
anyway.
>>     
>
> You are right of course.
> Are these right values for amd64 swap/dump:
> zfs create -V 2G rpool/dump
> zfs create -V 2G -b 4k rpool/swap
> Are these -b 4k values OK?
>
>   
I suggest that you set the sizes of the dump and swap zvols to match the 
zvols created by install on your original boot disk (the dump zvold size 
is particular difficult to get right because install calls the kernel to 
determine the optimal value).

The block size for rpool/dump should 128k .  The block size for swap 
zvols should be 4k for x86 (or amd64)  platforms and 8k for sparc platforms.

Lori


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100128/08dd4e21/attachment.html>

On 01/28/10 14:19, Lori Alt wrote:
> On 01/28/10 14:08, dick hoogendijk wrote:
>> On Thu, 2010-01-28 at 12:34 -0700, Lori Alt wrote:
>>   
>>> But those could be copied by send/recv from the larger disk
(current
>>> root pool) to the smaller disk (intended new root pool).  You
won''t be
>>> attaching anything until you can boot off the smaller disk and then
it
>>> won''t matter what''s on the larger disk because
attaching the larger disk
>>> to the root  mirror will destroy the contents of the larger disk
anyway.
>>>     
>>
>> You are right of course.
>> Are these right values for amd64 swap/dump:
>> zfs create -V 2G rpool/dump
>> zfs create -V 2G -b 4k rpool/swap
>> Are these -b 4k values OK?
>>
>>   
> I suggest that you set the sizes of the dump and swap zvols to match the 
> zvols created by install on your original boot disk (the dump zvold size 
> is particular difficult to get right because install calls the kernel to 
> determine the optimal value).
> 
> The block size for rpool/dump should 128k .  The block size for swap 
> zvols should be 4k for x86 (or amd64)  platforms and 8k for sparc
platforms.
> 
> Lori
> 
> 
The 128k block size for rpool/dump should be set by default starting in 
build 102 due to integration of CR 6725698.

cs

On Thu, 2010-01-28 at 08:44 -0700, Cindy Swearingen
wrote:
> Or, if possible, connect another larger disk and attach it to the original
root
> disk or even replace the smaller root pool disk with the larger disk.
I go for that one. But since it''s a smoewhat older system I only have
IDE and SATA(150) connections. IDE disks are rare these days.

Question: do SATA2 disks work on SATA(1) connections?

I think the SATA(2)-->SATA(1) connection will negotiate correctly,
but maybe some hardware expert will confirm.

cs


On 01/28/10 15:27, dick hoogendijk wrote:
> On Thu, 2010-01-28 at 08:44 -0700, Cindy Swearingen wrote:
>> Or, if possible, connect another larger disk and attach it to the
original root
>> disk or even replace the smaller root pool disk with the larger disk.
> 
> I go for that one. But since it''s a smoewhat older system I only
have
> IDE and SATA(150) connections. IDE disks are rare these days.
> 
> Question: do SATA2 disks work on SATA(1) connections?
>

Op 28-1-2010 17:35, Cindy Swearingen schreef:
> Thomas,
>
> Excellent and much better suggestion... :-)
>
> You can use beadm to specify another root pool by using the -p option.
> The beadm operation will set the bootfs pool property and update the
> GRUB entry.
It turns out not to be excellent at all. Beadm does create a new ABE in 
the new zpool, but the old zpool remains the leading zpool. This means 
you can not destroy it from within the newly booted BE plus /export/... 
comes from the "main" original zpool. The latter can be solved by 
umounting with the -f option and remounting the /export from the new BE, 
but the main issue is that the old zpool remains in charge. I''m gonna 
try booting off an USB stick later this evening and if that fails will 
go the way of restoring the system like Cindy mentions in her wonderful 
ZFS manual.

http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide

Dick

Hi Dick,

I have an OpenSolaris release running on my laptop with one disk
so I can''t confirm your results below. But before you go the
snapshot route, let me see if I can get some info on the beadm
solution.

I have done similar transitions with LU on Nevada releases and
I can easily boot from either BE in either pool. I thought beadm
would be similar, but let me find out.

Thanks,

Cindy

On 01/29/10 11:07, Dick Hoogendijk wrote:
> Op 28-1-2010 17:35, Cindy Swearingen schreef:
>> Thomas,
>>
>> Excellent and much better suggestion... :-)
>>
>> You can use beadm to specify another root pool by using the -p option.
>> The beadm operation will set the bootfs pool property and update the
>> GRUB entry.
> 
> It turns out not to be excellent at all. Beadm does create a new ABE in 
> the new zpool, but the old zpool remains the leading zpool. This means 
> you can not destroy it from within the newly booted BE plus /export/... 
> comes from the "main" original zpool. The latter can be solved by
> umounting with the -f option and remounting the /export from the new BE, 
> but the main issue is that the old zpool remains in charge. I''m
gonna
> try booting off an USB stick later this evening and if that fails will 
> go the way of restoring the system like Cindy mentions in her wonderful 
> ZFS manual.
> 
> http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide
> 
> Dick