Re: [OmniOS-discuss] On pkg(1) behavior in r151022

21 февраля 2017 г. 3:24:58 CET, Bob Friesenhahn пишет: >On Mon, 20 Feb 2017, Dan McDonald wrote: > >> >>> On Feb 20, 2017, at 6:17 PM, Bob Friesenhahn > wrote: >>> >>> If someone forgets to use -r the first time around, can the same

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

> On 2017-02-21, at 1.03, Dan McDonald wrote: > > a.) Accept "-r" as a requirement, and document to users that the behavior > between 014-020 and 022-beyond will change. I’m in favour of this change. It’s consistent and suits better with our usage patterns. Thanks, —

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

On Mon, 20 Feb 2017, Dan McDonald wrote: On Feb 20, 2017, at 6:17 PM, Bob Friesenhahn wrote: If someone forgets to use -r the first time around, can the same command be invoked again with the -r and then the zones get the updates as well? Yes. The pkg5

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

On Mon, 20 Feb 2017, Dan McDonald wrote: Also, the "-r" flag will be required for "update", "install", "uninstall", "change-facet", and "change-variant" subcommands as well. This is better than I understood since it is consistent. Copious documentation and alerts would be required. If

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

Also, the "-r" flag will be required for "update", "install", "uninstall", "change-facet", and "change-variant" subcommands as well. Right now, it appears we have two votes for "just accept -r and don't worry about making it implicit." Again, the two choices are: a.) Accept "-r" as a

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

> On Feb 20, 2017, at 5:37 PM, Theo Schlossnagle wrote: > > New behavior seems much more intuitive and self-consistent. IMHO in with the > new and out with the old. Just so we're clear: You do NOT want "implicit -r" and are okay with the behavior change for "pkg update"

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

On Mon, 20 Feb 2017, Dan McDonald wrote: Because of the least-suprise violation of new "pkg update" behavior, I'm wondering if we should make "-r" implicit. I'm working right now on an implicit "-r" solution, but am running into some problems with the pkg5 test suite I still need to sort

Re: [OmniOS-discuss] On pkg(1) behavior in r151022

New behavior seems much more intuitive and self-consistent. IMHO in with the new and out with the old. On Mon, Feb 20, 2017 at 5:28 PM, Dan McDonald wrote: > EXECUTIVE SUMMARY: As it stands, pkg(5) in bloody changes behavior from > 014-020 to something different. It also

[OmniOS-discuss] On pkg(1) behavior in r151022

EXECUTIVE SUMMARY: As it stands, pkg(5) in bloody changes behavior from 014-020 to something different. It also fixes a shortcoming in 014-020. Do we go completely with the new behavior and document it? Or do we minimize least-surprise at the risk of introducing bugs? I'm leaning toward the

Re: [OmniOS-discuss] MPT SAS Update

> On Feb 20, 2017, at 1:39 PM, Michael Talbott wrote: > > Sure. I'd love to volunteer to give it a go and report back what happens. > Thankfully this particular server is just a replica server so a few reboots > is no problem for me in this case. I'll take this off-list

Re: [OmniOS-discuss] MPT SAS Update

Sure. I'd love to volunteer to give it a go and report back what happens. Thankfully this particular server is just a replica server so a few reboots is no problem for me in this case. Michael Sent from my iPhone > On Feb 20, 2017, at 7:51 AM, Dan McDonald wrote: > >

Re: [OmniOS-discuss] No boot after pkg update

> On Feb 20, 2017, at 1:24 PM, Michael Rasmussen wrote: > > How many boot environments do you have on this server? > There is an upper limit which I cannot recall but it is somewhere in > between 20 to 30 BE's. Use this page to help you get out of your jam, if it's

Re: [OmniOS-discuss] No boot after pkg update

On Mon, 20 Feb 2017 19:11:38 +0100 qutic development wrote: > > Does anyone has an idea how to fix this? > How many boot environments do you have on this server? There is an upper limit which I cannot recall but it is somewhere in between 20 to 30 BE's. --

[OmniOS-discuss] No boot after pkg update

Hi List, after a pkg update to get the latest r151014 changes (which required a reboot) the supermicro server failed to boot with error [1]: failed to get ramdisk from boot Next I tried to boot from an older BEs. This failed too, but with another error [2]: null path krtld: failed to open

Re: [OmniOS-discuss] Ang: Re: Ang: Re: updating to openssh in ipkg zone

> On Feb 20, 2017, at 12:15 PM, Johan Kragsterman > wrote: > > Yeah, thanks, Dan, but the wrong one is on the release notes of 016, and I > took it wrongly from there, since I now see the right one is on the release > notes for 018... Phew! Okay, we did get

[OmniOS-discuss] Ang: Re: Ang: Re: updating to openssh in ipkg zone

Hi! -Dan McDonald skrev: - Till: Johan Kragsterman Från: Dan McDonald Datum: 2017-02-20 17:54 Kopia: omnios-discuss , Dan McDonald Ärende: Re: Ang: Re:

Re: [OmniOS-discuss] Ang: Re: updating to openssh in ipkg zone

> On Feb 20, 2017, at 11:50 AM, Johan Kragsterman > wrote: > > and the one that worked(Dan's) is this: > > > pkg install --no-backup-be --reject pkg:/network/ssh --reject > pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject >

[OmniOS-discuss] Ang: Re: updating to openssh in ipkg zone

Hi! Now it worked, and what was wrong was the string I copied from the wiki. It says this: pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh pkg:/network/openssh pkg:/network/openssh-server and the one that

Re: [OmniOS-discuss] MPT SAS Update

On Mon, 20 Feb 2017 11:22:54 -0500 Dan McDonald wrote: > I didn't say I wouldn't, I just said I wasn't sure. I misunderstood you. Sorry. > > Also, doing these device-driver updates causes systems to reboot, which some > of our LTS users really don't like doing. > If these

Re: [OmniOS-discuss] MPT SAS Update

> On Feb 20, 2017, at 11:17 AM, Michael Rasmussen wrote: > > On Mon, 20 Feb 2017 10:51:18 -0500 > Dan McDonald wrote: > >> >> This one is probably a good backport candidate. Given our next release is >> our next LTS, however, I'm not sure I'll be

Re: [OmniOS-discuss] MPT SAS Update

On Mon, 20 Feb 2017 10:51:18 -0500 Dan McDonald wrote: > > This one is probably a good backport candidate. Given our next release is > our next LTS, however, I'm not sure I'll be backporting it to r151014. > That is sad given that r151014 is still supported 1 year after

Re: [OmniOS-discuss] MPT SAS Update

> On Feb 19, 2017, at 9:13 PM, Michael Talbott wrote: > > > After some googling I found this which I thnk seems to have addressed the > underlying issue: > https://www.illumos.org/issues/5698 > via this commit: >

Re: [OmniOS-discuss] updating to openssh in ipkg zone

Silly question: Are your packages on this zone (even the ones you plan to get rid of) up to the latest versions? It sounds silly, but see what: pkg update -nv shows you first. If there's output, make sure you update the zone to latest things first, THEN try the update. BTW, I ran