Re: [indiana-discuss] opensolaris2009.06 slow boot
i tried the dtrace script, and i found that modunload is taking around 1 min. i have attached the chart generated and the log file. i tried disabling automount no success :( -- This message posted from opensolaris.org___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? You shouldn't be copying /usr/lib/isaexec into /opt/abcd/lib either. Yes, I know, which is the primary reason why I asked this question. isaexec works with hard links only. I have no way to guarantee, that /opt will not be a separate filesystem: it might be shared out via NFS from a different system, for instance; hard links cannot span filesystems, soft links do not work, copying isaexec does not work for several reasons, one of which is that IPS is a no scripting zone, and another, that by doing a one time copy in postinstall, the now private copy of isaexec in /opt would not get patched like the one in /usr/lib/ would. Do you have any concrete suggestions, other than your software is incorrectly packaged for OpenSolaris 200x? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] opensolaris2009.06 slow boot
i tried the dtrace script, and i found that modunload is taking around 1 min. i have attached the chart generated and the log file. Hmm, some of the hald commands show a strange delayed start of about one minute... Does your system have a ps/2 floppy drive, or is one configured in the bios? Could this be similar to bug 4714? HALD takes more than 60 seconds to start http://defect.opensolaris.org/bz/show_bug.cgi?id=4714 -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
One solution is to create a little program that utilizes the isaexec API and accepts a pathname to an executable. See isaexec(3C). Thanks Moinak. I did exactly what you told me, and it worked, except that I replicated /usr/lib/isaexec functionality. As it turns out, a hard link is needed because of getexecname(3C), as follows: return(isaexec(getexecname(), argv, envp)); getexecname(3C) follows a symbolic link, so isaexec(3C) now has a wrong argument for *path. If I were to follow this approach, a small program with either a hardcoded path return(isaexec(/opt/abcd/bin/bla, argv, envp)); would have to be compiled for every single binary of every single product I deliver (think of it as one copy of isaexec(3C) per binary), or I would use one such isaexec in /opt/abcd/lib, but then I'm back to the hard links cannot span filesystems problem. Finally, a third approach would be to build my own parser similar to getexecname(3C), which would return the name of the symbollic link instead of the name of the target file, but this would require path reconstruction in order to pass to isaexec(3C) correctly. Any other ideas? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
[indiana-discuss] zio_read_data failed in GRUB while trying to boot from compact flash (CF)
I am trying to get OpenSolaris 2009.06 to run from my 32 GB Kingston compact flash drive attached to a standard Sil 0680 IDE controller. The installer detects the card and install successfully. Upon reboot, GRUB drops to a grub prompt. Any attempts to read menu.lst fail with: grub root (hd0,0,a) Filesystem type is zfs ... grub find /rpool/boot/grub/menu.lst zio_read_data failed Error 15: File not found However, I have no problem importing/mounting rpool from the livecd and it scrubs fine: # zpool status pool: rpool state: ONLINE scrub: scrub completed after 0h20m with 0 errors on Thu Jun 4 03:48:38 2009 config: NAMESTATE READ WRITE CKSUM rpool ONLINE 0 0 0 c7d0s0ONLINE 0 0 0 errors: No known data errors Here's the zdb output if it helps: # zdb rpool version=14 name='rpool' state=0 txg=2260 pool_guid=1956317138649872688 hostid=4513662 hostname='opensolaris' vdev_tree type='root' id=0 guid=1956317138649872688 children[0] type='disk' id=0 guid=3886586958467541694 path='/dev/dsk/c7d0s0' devid='id1,c...@aelite_pro_cf_card_32gb=200812051b70/a' phys_path='/p...@0,0/pci8086,2...@1e/pci-...@0/i...@0/c...@0,0:a' whole_disk=0 metaslab_array=23 metaslab_shift=28 ashift=9 asize=31975014400 is_log=0 DTL=85 Any idea why this would fail in GRUB but work when booted from a livecd? Thanks. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
UNIX admin wrote: The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Alternatively, you can deliver your own copy of isaexec. isaexec works with hard links only. I have no way to guarantee, that /opt will not be a separate filesystem: it might be shared out via NFS from a different system, for instance; hard links cannot span filesystems, soft links do not work, copying isaexec does not work for several reasons, one of which is that IPS is a no scripting zone, and another, that by doing a one time copy in postinstall, the now private copy of isaexec in /opt would not get patched like the one in /usr/lib/ would. Do you have any concrete suggestions, other than your software is incorrectly packaged for OpenSolaris 200x? See above. Your last alternative is to contribute the work to fix isaexec. I think you'll find that many engineers feel that it has several design issues, such as the one you've discovered, that need to be resolved. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] zio_read_data failed in GRUB while trying to boot from compact flash (CF)
James Lee wrote: I am trying to get OpenSolaris 2009.06 to run from my 32 GB Kingston compact flash drive attached to a standard Sil 0680 IDE controller. The installer detects the card and install successfully. Upon reboot, GRUB drops to a grub prompt. Any attempts to read menu.lst fail with: grub root (hd0,0,a) Filesystem type is zfs ... grub find /rpool/boot/grub/menu.lst zio_read_data failed Error 15: File not found However, I have no problem importing/mounting rpool from the livecd and it scrubs fine: # zpool status pool: rpool state: ONLINE scrub: scrub completed after 0h20m with 0 errors on Thu Jun 4 03:48:38 2009 config: NAMESTATE READ WRITE CKSUM rpool ONLINE 0 0 0 c7d0s0ONLINE 0 0 0 errors: No known data errors Here's the zdb output if it helps: # zdb rpool version=14 name='rpool' state=0 txg=2260 pool_guid=1956317138649872688 hostid=4513662 hostname='opensolaris' vdev_tree type='root' id=0 guid=1956317138649872688 children[0] type='disk' id=0 guid=3886586958467541694 path='/dev/dsk/c7d0s0' devid='id1,c...@aelite_pro_cf_card_32gb=200812051b70/a' phys_path='/p...@0,0/pci8086,2...@1e/pci-...@0/i...@0/c...@0,0:a' whole_disk=0 metaslab_array=23 metaslab_shift=28 ashift=9 asize=31975014400 is_log=0 DTL=85 Any idea why this would fail in GRUB but work when booted from a livecd? Thanks. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss With rpool imported/mounted can you cat the contents of the GRUB menu.lst file? What does it contain? e.g.: % cat /rpool/boot/grub/menu.lst This question should probably be posted to install-disc...@opensolaris.org Joe ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Shawn Walker wrote: UNIX admin wrote: The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Uh, Shawn... you're conflating things **Sun** had not delivered to /usr/bin and instead used /usr/gnu with software **others**, who are not part of the distro, want to deliver to OpenSolaris. None of the documents you've referenced above indicate third parties should start delivering software to the UNIX system repository (/usr). In fact the ARC guidelines _specify_ /opt, /var/opt, /etc/opt and friends for Add-on system software or applications: http://opensolaris.org/os/community/arc/policies/install-locations/ Respectfully, I believe you are quite wrong on this. - Matt ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Matt Ingenthron wrote: Shawn Walker wrote: UNIX admin wrote: The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Uh, Shawn... you're conflating things **Sun** had not delivered to /usr/bin and instead used /usr/gnu with software **others**, who are not part of the distro, want to deliver to OpenSolaris. None of the documents you've referenced above indicate third parties should start delivering software to the UNIX system repository (/usr). In fact the ARC guidelines _specify_ /opt, /var/opt, /etc/opt and friends for Add-on system software or applications: http://opensolaris.org/os/community/arc/policies/install-locations/ Respectfully, I believe you are quite wrong on this. I disagree. For many of the same reasons stated in PSARC/2005/185, I believe even third-party software belongs in /usr. Otherwise, some of the same problems stated in there are going to occur with third-party software. It is my belief that most new users are going to expect to be able to user their software right away when they install it without modifying their $PATH. Others are free to interpret as they like, but that is my view. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Shawn Walker wrote: Matt Ingenthron wrote: Shawn Walker wrote: UNIX admin wrote: The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Uh, Shawn... you're conflating things **Sun** had not delivered to /usr/bin and instead used /usr/gnu with software **others**, who are not part of the distro, want to deliver to OpenSolaris. None of the documents you've referenced above indicate third parties should start delivering software to the UNIX system repository (/usr). In fact the ARC guidelines _specify_ /opt, /var/opt, /etc/opt and friends for Add-on system software or applications: http://opensolaris.org/os/community/arc/policies/install-locations/ Respectfully, I believe you are quite wrong on this. I disagree. For many of the same reasons stated in PSARC/2005/185, I believe even third-party software belongs in /usr. Could you reference where this was communicated? (I don't think you can) What you've supplied thus far has to do with software Sun has bundled. I've referenced where Sun has specified otherwise. Please use the ARC community to get this documented correctly if you're so sure of the change. Otherwise, some of the same problems stated in there are going to occur with third-party software. It is my belief that most new users are going to expect to be able to user their software right away when they install it without modifying their $PATH. Others are free to interpret as they like, but that is my view. Cheers, ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] zio_read_data failed in GRUB while trying to boot from compact flash (CF)
Joseph J VLcek wrote: With rpool imported/mounted can you cat the contents of the GRUB menu.lst file? What does it contain? e.g.: % cat /rpool/boot/grub/menu.lst This question should probably be posted to install-disc...@opensolaris.org Joe Yes, I can cat the file just fine once booted into the livecd: # zpool import rpool # cat /rpool/boot/grub/menu.lst splashimage /boot/grub/splash.xpm.gz background 215ECA timeout 30 default 0 #-- ADDED BY BOOTADM - DO NOT EDIT -- title OpenSolaris 2009.06 findroot (pool_rpool,0,a) bootfs rpool/ROOT/opensolaris splashimage /boot/solaris.xpm foreground d25f00 background 115d93 kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=graphics module$ /platform/i86pc/$ISADIR/boot_archive #-END BOOTADM Unfortunately, GRUB never gets to a point where it can. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] zio_read_data failed in GRUB while trying to boot from compact flash (CF)
Hi James, No answers from me, just some information. The ability to boot from a disk greater than 1 TB integrated last fall and this support is in the OpenSolaris 2009.06 release. I see the same zio_read_data error (boot from install okay, but not from the disk) in this CR: 6843138 can not boot off of a 2.2TB and zfs root The root cause seems to be that the that BIOS is not reporting correct capacity. This CR is fixed in Nevada, build 117. If someone can get you the stage2 binary from build 117, then we would know for sure that is bug is your issue. Cindy James Lee wrote: Joseph J VLcek wrote: With rpool imported/mounted can you cat the contents of the GRUB menu.lst file? What does it contain? e.g.: % cat /rpool/boot/grub/menu.lst This question should probably be posted to install-disc...@opensolaris.org Joe Yes, I can cat the file just fine once booted into the livecd: # zpool import rpool # cat /rpool/boot/grub/menu.lst splashimage /boot/grub/splash.xpm.gz background 215ECA timeout 30 default 0 #-- ADDED BY BOOTADM - DO NOT EDIT -- title OpenSolaris 2009.06 findroot (pool_rpool,0,a) bootfs rpool/ROOT/opensolaris splashimage /boot/solaris.xpm foreground d25f00 background 115d93 kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=graphics module$ /platform/i86pc/$ISADIR/boot_archive #-END BOOTADM Unfortunately, GRUB never gets to a point where it can. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] zio_read_data failed in GRUB while trying to boot from compact flash (CF)
James Lee wrote: Joseph J VLcek wrote: With rpool imported/mounted can you cat the contents of the GRUB menu.lst file? What does it contain? e.g.: % cat /rpool/boot/grub/menu.lst This question should probably be posted to install-disc...@opensolaris.org Joe Yes, I can cat the file just fine once booted into the livecd: # zpool import rpool # cat /rpool/boot/grub/menu.lst splashimage /boot/grub/splash.xpm.gz background 215ECA timeout 30 default 0 #-- ADDED BY BOOTADM - DO NOT EDIT -- title OpenSolaris 2009.06 findroot (pool_rpool,0,a) bootfs rpool/ROOT/opensolaris splashimage /boot/solaris.xpm foreground d25f00 background 115d93 kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=graphics module$ /platform/i86pc/$ISADIR/boot_archive #-END BOOTADM Unfortunately, GRUB never gets to a point where it can. What was in /tmp/install_log after the install but before the reboot? Were there any errors? If there are errors you could enter a new bug report at: http://defect.opensolaris.org/bz/ Development/Installer Component: gui (If you are using the GUI) Please attach the Install log. Joe ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Thu, Jun 04, 2009 at 11:15:45AM -0700, Matt Ingenthron wrote: Shawn Walker wrote: Matt Ingenthron wrote: Shawn Walker wrote: As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. There's no mention whatsoever of /opt in the opinion for PSARC/2005/185, and none in the final spec for PSARC/2007/048. /opt/sfw was never an official location -- the companion CD was not a product in ARC parlance. /usr/sfw *is* obsolete, and everything in there is moving out into /usr. Therefore /opt is still the location that 3rd parties should use _as far as the ARC is concerned. http://opensolaris.org/os/community/arc/policies/install-locations/ Respectfully, I believe you are quite wrong on this. Agreed. I disagree. For many of the same reasons stated in PSARC/2005/185, I believe even third-party software belongs in /usr. You do (and I might, as you can see below), but the ARC clearly does not. Now, it's possible that for OpenSolaris we'd want to change that, and to the extent that changes for OpenSolaris haven't all been reviewed by the ARC, it's possible that what you say is, in fact, correct for OpenSolaris. If so, that would one more change to document to the ARC eventually, and also, that would be a change that should be communicated to OpenSolaris developers ASAP, including, for example, by making sure that filesystem(5) is different on OpenSolaris than on Nevada. I myself am not sure where third-party pkgs should install into. FOSS could always be integrated directly into OpenSolaris via the consolidation process, or perhaps via /contrib, in which case it will end up in /usr -- to me this argues for third parties packaging FOSS to install into /usr, and I'm not sure why non-FOSS should be treated differently in this regard. Right now I lean towards third parties installing code into /usr. Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Matt Ingenthron wrote: Shawn Walker wrote: Matt Ingenthron wrote: Shawn Walker wrote: UNIX admin wrote: The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Uh, Shawn... you're conflating things **Sun** had not delivered to /usr/bin and instead used /usr/gnu with software **others**, who are not part of the distro, want to deliver to OpenSolaris. None of the documents you've referenced above indicate third parties should start delivering software to the UNIX system repository (/usr). In fact the ARC guidelines _specify_ /opt, /var/opt, /etc/opt and friends for Add-on system software or applications: http://opensolaris.org/os/community/arc/policies/install-locations/ Respectfully, I believe you are quite wrong on this. I disagree. For many of the same reasons stated in PSARC/2005/185, I believe even third-party software belongs in /usr. Could you reference where this was communicated? (I don't think you can) My point was that for some of the same reasons that Sun is moving software from /usr/sfw, etc. to /usr are equally applicable to third-party software. What you've supplied thus far has to do with software Sun has bundled. I've referenced where Sun has specified otherwise. Please use the ARC community to get this documented correctly if you're so sure of the change. You're certainly welcome to do so; I have plenty of other things to do :) Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Nicolas Williams wrote: I myself am not sure where third-party pkgs should install into. FOSS could always be integrated directly into OpenSolaris via the consolidation process, or perhaps via /contrib, in which case it will end up in /usr -- to me this argues for third parties packaging FOSS to install into /usr, and I'm not sure why non-FOSS should be treated differently in this regard. Right now I lean towards third parties installing code into /usr. Which is why I believe it belongs in /usr. Again, I have no idea what ARC has or has not decided beyond the serendpituous discovery cases, etc. All I know is that the reasons stated for moving stuff from /usr/sfw, etc. seem equally applicable regardless of who provides the software. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
a b wrote: ...many bits of software are moving to /usr :) Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Consider that if I deliver my software in /usr (as a 3rd party unbundled applications vendor), I run an extremely high risk of: a) being overwritten by IPS, respectively your own updates b) my software overwriting your software. Work is scheduled to alter packaging system to prevent a user from installing packages with conflicting resources. It is actually desirable that some software delivers into the same place to allow it to replace another component. It appears that these architectural issue have not been thought throughly. The OpenSolaris distribution, as you are aware, is experimenting with changes that have not yet made it through ARC. Regardless, I don't see the issue here. Ubuntu, et al. are quite successful despite the lack of adherence to the Sys V filesystem specification from a user perspective. I won't debate the merits, etc. of this with your nor comment on what should or should not be done architecturally as that isn't my responsibility. I'll just simply say that I see no issue with packaging for /usr as most packages are moving towards, and that I believe most users will expect that. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
...many bits of software are moving to /usr :) Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Consider that if I deliver my software in /usr (as a 3rd party unbundled applications vendor), I run an extremely high risk of: a) being overwritten by IPS, respectively your own updates b) my software overwriting your software. Death to /opt/sfw, /usr/sfw, etc. It appears that these architectural issue have not been thought throughly. You know, System V filesystem specification and /opt, exist for a reason. So do things like /usr/openwin, /usr/dt, /usr/sfw, and so on. The engineers didn't put them under separate directories out of wanton arrogance, but out of necessity. It is impractical to assume that every single entity, be it a person or an organization will actually be willing to go through the hoops to integrate into Indiana. What are commercial vendors going to do? Take Oracle, SAP, Legato NetWorker, Veritas and so on. A lot of these vendors deliver utilities which would overlap with the operating system applications and utilities. It is impractical to deliver into /usr; and delivering into /usr/product would create PATH hell, where one would have to have a discrete PATH added for every 3rd party / commercial product, which is impractical. Did you even consider these issues before you cried out Death to /opt/sfw? See above. Your last alternative is to contribute the work to fix isaexec. I think you'll find that many engineers feel that it has several design issues, such as the one you've discovered, that need to be resolved. I very well might, but fixing isaexec(3C) is not going to fix a no scripting zone issue, nor will it fix the architectural issues I described above. Indiana has a problem. And not just any problem, it has several serious architectural issues, and those are the worst kind of problems. I cannot simply solve these architectural issues with just code. Some consideration is needed as well, and not just on my part. _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
I disagree. For many of the same reasons stated in PSARC/2005/185, I believe even third-party software belongs in /usr. If you don't mind, would you please explain how software which enhances the OS yet works in a different way (such as for example 3rd party clustering software) would be able to deliver the payload, without overwriting binaries found in /usr/bin and /usr/lib, if the software were delivered into /usr? Are you saying that you expect a company like SAP or Symantec (or any other commercial vendor) to go through the integration into Indiana? Otherwise, some of the same problems stated in there are going to occur with third-party software. It is my belief that most new users are going to expect to be able to user their software right away when they install it without modifying their $PATH. It is my belief that Indiana will have an even bigger problem if it is architecturally incapable of supporting commercial applications. Do you also expect startups to bundle their commercial software, which might also require a paid-for license, into Indiana? _ Windows Live™: Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Thu, Jun 04, 2009 at 04:34:52PM -0500, Shawn Walker wrote: Nicolas Williams wrote: I myself am not sure where third-party pkgs should install into. FOSS could always be integrated directly into OpenSolaris via the consolidation process, or perhaps via /contrib, in which case it will end up in /usr -- to me this argues for third parties packaging FOSS to install into /usr, and I'm not sure why non-FOSS should be treated differently in this regard. Right now I lean towards third parties installing code into /usr. Which is why I believe it belongs in /usr. Again, I have no idea what ARC has or has not decided beyond the serendpituous discovery cases, You surely can know: read the case materials/opinions. (They say nothing about /opt being deprecated.) etc. All I know is that the reasons stated for moving stuff from /usr/sfw, etc. seem equally applicable regardless of who provides the software. Maybe. The difference between third-party and ARC-reviewed software is this: the ARC manages the namespace to prevent conflicts, while third parties don't. Of course, there can be conflicts in /opt, but those are unlikely, particularly if third-parties use the stock symbol prefix tradition. Right now our only namespace management for things in /usr (in /usr/bin, ...) is this: first one there wins, and to win you need to a) ARC, b) integrate. If third parties can deliver straight into /usr/bin and friends then what should users do when conflicts arise? How will two parties resolve the conflict over a desirable name? Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Thu, Jun 04, 2009 at 04:37:51PM -0500, Shawn Walker wrote: a b wrote: It appears that these architectural issue have not been thought throughly. The OpenSolaris distribution, as you are aware, is experimenting with changes that have not yet made it through ARC. Regardless, I don't see the issue here. Ubuntu, et al. are quite successful despite the lack of adherence to the Sys V filesystem specification from a user perspective. No, that is the issue. Being outside the ARC process, guidance beyond what's in filesystem(5) (which comes from a product, Solaris, that's developed in the ARC process), is needed. I won't debate the merits, etc. of this with your nor comment on what should or should not be done architecturally as that isn't my responsibility. I'll just simply say that I see no issue with packaging for /usr as most packages are moving towards, and that I believe most users will expect that. I want to say the same thing, but for now I can't quite agree. The namespace issues are important. At the very least IPS needs to deal sanely with: - two or more pkgs in one repository with actions - a user trying to install one or more pkgs whose actions would conflict with those a pkg that's already installed Additionally we could use a namespace registry (preferably one that could be used by Linux distros too). Even then we'd need rules as to whether new conflicts can be created, and conflict resolution. E.g., what happens if a project wants to deliver /bin/foo directly with OpenSolaris, via a consolidation, and a third-party has already registered that name? Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] zio_read_data failed in GRUB while trying to boot from compact flash (CF)
James Lee wrote: I am trying to get OpenSolaris 2009.06 to run from my 32 GB Kingston compact flash drive attached to a standard Sil 0680 IDE controller. The installer detects the card and install successfully. Upon reboot, GRUB drops to a grub prompt. Any attempts to read menu.lst fail with: grub root (hd0,0,a) Filesystem type is zfs ... grub find /rpool/boot/grub/menu.lst zio_read_data failed Error 15: File not found However, I have no problem importing/mounting rpool from the livecd and it scrubs fine: ... Any idea why this would fail in GRUB but work when booted from a livecd? You didn't by chance turn on gzip-compression for the file systems on this, did you? Dave ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] zio_read_data failed in GRUB while trying to boot from compact flash (CF)
Dave Miner wrote: You didn't by chance turn on gzip-compression for the file systems on this, did you? Dave No. I'm not using any compression. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Thu, Jun 04, 2009 at 08:11:48PM +0200, a b wrote: Consider that if I deliver my software in /usr (as a 3rd party unbundled applications vendor), I run an extremely high risk of: a) being overwritten by IPS, respectively your own updates b) my software overwriting your software. I agree. This has to be avoided. That does not mean that there's no way to enable third-party delivery into /usr (see my other reply). Death to /opt/sfw, /usr/sfw, etc. It appears that these architectural issue have not been thought throughly. PSARC certainly has discussed these issues at length. This is the first I hear that where third-party software goes is different for Nevada than for OpenSolaris. And I'm not sure that that's anything other than Shawn's opinion -- documentation is needed. See above. Your last alternative is to contribute the work to fix isaexec. I think you'll find that many engineers feel that it has several design issues, such as the one you've discovered, that need to be resolved. I very well might, but fixing isaexec(3C) is not going to fix a no scripting zone issue, nor will it fix the architectural issues I described above. Different issue. Indiana has a problem. And not just any problem, it has several serious architectural issues, and those are the worst kind of problems. I cannot simply solve these architectural issues with just code. Some consideration is needed as well, and not just on my part. I'm not sure I agree because I'm not sure that what Shawn said about /opt is anything other than personal opinion. IMO if IPS can deal sanely with conflicts, and preferably a registry is provided, then recommending /usr over /opt may be a good idea, but deprecating /opt wouldn't be a good idea for a long time yet. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Nicolas Williams wrote: On Thu, Jun 04, 2009 at 04:37:51PM -0500, Shawn Walker wrote: a b wrote: [snip] I won't debate the merits, etc. of this with your nor comment on what should or should not be done architecturally as that isn't my responsibility. I'll just simply say that I see no issue with packaging for /usr as most packages are moving towards, and that I believe most users will expect that. I want to say the same thing, but for now I can't quite agree. The namespace issues are important. At the very least IPS needs to deal sanely with: - two or more pkgs in one repository with actions I assume you mean actions which overlap? This may or may not be an issue, depending on what packages a user wants to install. It would be nice if we could (optionally) catch this at publication time and that's something we may work towards in the future. Of course, this doesn't solve the problem of third party software delivering conflicting actions, but at least we could be self-consistent. - a user trying to install one or more pkgs whose actions would conflict with those a pkg that's already installed Known bug: http://defect.opensolaris.org/bz/show_bug.cgi?id=3822 One thing that's holding this up is that there are issues with the current nevada pacakges delivering conflicts (see the dependent bugs of that bug). Until we deliver a self-consistent set of packages, IPS is somewhat constrained on what we can do. Brock Additionally we could use a namespace registry (preferably one that could be used by Linux distros too). Even then we'd need rules as to whether new conflicts can be created, and conflict resolution. E.g., what happens if a project wants to deliver /bin/foo directly with OpenSolaris, via a consolidation, and a third-party has already registered that name? Nico ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] gdm/X does not start
William Headrick wrote: Anil Jangity wrote: See attachments. /var/adm/messages: May 5 16:27:57 sjc gdm-binary[588]: [ID 702911 daemon.warning] WARNING: Failed to start X server several times in a short time period; disabling display :0 ... oh, I forgot to plug the mouse in when I captured these logs, still the same issue with mouse in. According to those logs, your X server started and is running on your AST service processor/remote KVM. Alan, I believe that I am running into the same issue on a Sun Fire x2270. I've got the service processor on the machine as well. The machine boots, but the text prompt is all that is displayed at the console. How would I make the X server start on the regular display if I am having the same issue? Is there any other display on these machines? Sorry, but I'm not familiar with the hardware, and don't really know. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] gdm/X does not start
opensola...@myspamfilter.fastmail.fm wrote: On Thu, 04 Jun 2009 20:29 -0700, Alan Coopersmith According to those logs, your X server started and is running on your AST service processor/remote KVM. Alan, I believe that I am running into the same issue on a Sun Fire x2270. I've got the service processor on the machine as well. The machine boots, but the text prompt is all that is displayed at the console. How would I make the X server start on the regular display if I am having the same issue? Is there any other display on these machines? Sorry, but I'm not familiar with the hardware, and don't really know. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering There is a VGA connector on the back of the machine (that I have a monitor plugged into). This page lists the video and graphics controller: http://sunsolve.sun.com/handbook_pub/validateUser.do?target=Systems/SunFireX2270/spec Video One VGA 16MB - 1600x1200 @ 60Hz Graphics controller ASPEED AST2000 - 2D graphics controller embedded in Service Processor Support remote console at a resolution up to 1600x1200x16b...@60hz So that sounds like it's the same video chipset that drives the remote console/service processor, not a separate device, just another output for that same device. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] opensolaris2009.06 slow boot
problem solved! actually i had not disabled the floppy drive in the BIOS (i don't have a floppy drive). The hal daemon was trying to access the floppy drive because it was enabled in BIOS. the same thing was probably happening in the older version of OpenSolaris. But in this release, hal was added as a dependency to the gdm. so i couldn't get the login screen until hald returned unsuccessfully. this bug was reported long back: http://bugs.opensolaris.org/view_bug.do?bug_id=6294851 thanks to everyone who helped... regards, Nischal E Rao -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
