Re: [OpenIndiana-discuss] Migrating to smaller root pool
30 марта 2014 г. 5:27:09 CEST, Reginald Beardsley pulask...@yahoo.com пишет: I'm trying to migrate to a smaller root pool so I can put /export in a RAIDZ1 and use a 3 way mirror for the root pool. So far I've been soundly thrashed. I copied the rpool contents over to npool w/ zfs send -R and installed grub. When I boot the new disk, grub comes up with the menu, but then complains it can't find the filesystem. I used a dedicated Solaris disk and a 100 GB s0 slice. This is an existing system that I don't want to rebuild, so the way I built my N40L won't work until I get the first bootable pool. Hints or suggestions? This is very similar to doing a bare metal recovery, so I have a strong interest in figuring this out. Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss I believe there may be a couple of things easy to miss: 1) did you bring over the non-default (local) attributes of the zpool, including 'bootfs' and perhaps 'failmode'? 2) how is the 'npool' ultimately called and how is a bootfs referenced in the new copy of the grub menu (still 'rpool'?) Note that to rename the rootpool you might use a live media and zpool import-export trick, with a renaming import. 3) is the rootfs and dataset hierarchy leading to it compressed in a way grub can't read (i.e. gzip)? I believe it only permits uncompressed and lz4... HTH, //Jim -- Typos courtesy of K-9 Mail on my Samsung Android ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Migrating to smaller root pool
Thanks! I'd failed to set the bootfs property on the new pool. Setting that was all it took. BTW Long ago I created a pool which got trashed (it was probably OK, but I didn't know that at the time) by unplugging the power to the USB disk. I created a new pool on the disk, but the system still remembers that corrupted pool. Any idea how to clear that? On Sun, 3/30/14, Jim Klimov jimkli...@cos.ru wrote: Subject: Re: [OpenIndiana-discuss] Migrating to smaller root pool To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org, Reginald Beardsley pulask...@yahoo.com, oi openindiana-discuss@openindiana.org Date: Sunday, March 30, 2014, 2:51 AM 30 марта 2014 г. 5:27:09 CEST, Reginald Beardsley pulask...@yahoo.com пишет: I'm trying to migrate to a smaller root pool so I can put /export in a RAIDZ1 and use a 3 way mirror for the root pool. So far I've been soundly thrashed. I copied the rpool contents over to npool w/ zfs send -R and installed grub. When I boot the new disk, grub comes up with the menu, but then complains it can't find the filesystem. I used a dedicated Solaris disk and a 100 GB s0 slice. This is an existing system that I don't want to rebuild, so the way I built my N40L won't work until I get the first bootable pool. Hints or suggestions? This is very similar to doing a bare metal recovery, so I have a strong interest in figuring this out. Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss I believe there may be a couple of things easy to miss: 1) did you bring over the non-default (local) attributes of the zpool, including 'bootfs' and perhaps 'failmode'? 2) how is the 'npool' ultimately called and how is a bootfs referenced in the new copy of the grub menu (still 'rpool'?) Note that to rename the rootpool you might use a live media and zpool import-export trick, with a renaming import. 3) is the rootfs and dataset hierarchy leading to it compressed in a way grub can't read (i.e. gzip)? I believe it only permits uncompressed and lz4... HTH, //Jim -- Typos courtesy of K-9 Mail on my Samsung Android ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Migrating to smaller root pool
On Sun, Mar 30, 2014 at 4:27 AM, Reginald Beardsley pulask...@yahoo.comwrote: I'm trying to migrate to a smaller root pool so I can put /export in a RAIDZ1 and use a 3 way mirror for the root pool. So far I've been soundly thrashed. I copied the rpool contents over to npool w/ zfs send -R and installed grub. When I boot the new disk, grub comes up with the menu, but then complains it can't find the filesystem. I used a dedicated Solaris disk and a 100 GB s0 slice. This is an existing system that I don't want to rebuild, so the way I built my N40L won't work until I get the first bootable pool. Hints or suggestions? This is very similar to doing a bare metal recovery, so I have a strong interest in figuring this out. There are 3 steps in doing this (and in any installation or upgrade, come to that. 1. Set up the pool correctly, some or most of this will be picked up by the zfs send, but you want failmode=continue set on the pool, and you need to set the bootfs property on the new pool to be the name of the dataset containing your root file system 2. Create the boot sign. On a normal rpool it would be touch /rpool/boot/grub/bootsign/pool_rpool echo pool_rpool /rpool/etc/bootsign and you will need to change both of those if you change the name of the pool. 3. Have grub match the boot sign you set in 2, in particular the findroot and bootfs lines have to match. For example, with the pool called rpool and the boot sign called pool_rpool, they say: findroot (pool_rpool,0,a) bootfs rpool/ROOT/openindiana So if you change the pool name from rpool to npool, you'll probably have to: /usr/sbin/zpool set bootfs=npool/ROOT/openindiana npool rm /npool/boot/grub/bootsign/pool_rpool touch /npool/boot/grub/bootsign/pool_npool echo pool_npool /npool/etc/bootsign and replace any rpool with npool in /npool/boot/grub/menu.lst -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with OpenIndiana Upgrade
Hi, gdk-pixbuf package was splitted in a9 from gtk2 package (because of upstream changes). Could you send output of pkg publisher command, please? Best regards, Milan On so, 2014-03-29 at 18:46 +, russell wrote: Hi, When I try to upgrade my normal OpenIndiana environment I get the following message These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/share/gtk-doc/html/gdk-pixbuf/gdk-pixbuf-gdk-pixbuf-rendering.html: pkg://openindiana.org/library/desktop/gtk2@2.20.1,5.11-0.151.1.8:20130406T215741Z pkg://openindiana.org/library/desktop/gdk-pixbuf@0.5.11,5.11-0.151.1.9:20140117T202422Z Now I have checked and the pkg://openindiana.org/library/desktop/gdk-pixbuf@0.5.11,5.11-0.151.1.9:20140117T202422Z is not listed when I run pkg list -v I have removed the OpenSolaris packages, removed the repository, performed pkg rebuild-index and forced a package refresh but the mystery package is still complained about. If I try to remove it with pkg uninstall it can not be found. How can I upgrade to the latest release? TIA ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] sd-config-list= vid/pid string syntax in sd.conf
On 29/03/2014 21:15, Reginald Beardsley wrote: The string matching logic in sd_sdconf_id_match() in sd.c is odd and seems to cause a good bit of confusion. In particular it does not conform to shell wildcard rules which I think is what most people would expect. Can anyone point to why the current syntax and semantics were chosen? Does anyone know a reason why it should not conform to shell wildcard rules? The alternative is full regular expressions, but that seems a bit overkill and possibly confusing as well. Usually done to limit the potential stack usage in the kernel, which is a much more limited resource than in user space where RE and shell matching are found. -- Andrew ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] sd-config-list= vid/pid string syntax in sd.conf
Given the size limits on vid/pid I don't think shell style wildcards would consume any more space. RE probably would and would certainly require significant text segment space. The present implementation does a substring match but only if both the first and last character of the string in sd.conf are * which is very counter to expectations. Reg On Sun, 3/30/14, Andrew Gabriel illu...@cucumber.demon.co.uk wrote: Subject: Re: [OpenIndiana-discuss] sd-config-list= vid/pid string syntax in sd.conf To: openindiana-discuss@openindiana.org Date: Sunday, March 30, 2014, 11:55 AM On 29/03/2014 21:15, Reginald Beardsley wrote: The string matching logic in sd_sdconf_id_match() in sd.c is odd and seems to cause a good bit of confusion. In particular it does not conform to shell wildcard rules which I think is what most people would expect. Can anyone point to why the current syntax and semantics were chosen? Does anyone know a reason why it should not conform to shell wildcard rules? The alternative is full regular expressions, but that seems a bit overkill and possibly confusing as well. Usually done to limit the potential stack usage in the kernel, which is a much more limited resource than in user space where RE and shell matching are found. -- Andrew ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [discuss] which to use: smb/server or samba
On Thu, Mar 27, 2014 at 09:53:16PM -0700, Richard Elling wrote: NB, it appears as though the fine folks at Nexenta have put their SMB2 source up at https://github.com/Nexenta/illumos-nexenta Knowing Gordon, I'm sure it is of high quality and scalability. Definitely looking forward to that showing up in omnios someday; hopefully somebody will have the desire, time, and expertise to integrate Nexenta's changes into upstream illumos-gate sometime soon :). ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
