Hi,
I have a little issue with updating my OI servers.
Each time I do a pkg update, it (re)downloads and (re)installs
the same updates, over and over...
-
OpenIndiana (powered by illumos) SunOS 5.11 oi_151a7 October 2012
root@s5:~# pkg update
WARNING: The boot environment being
Le 2014/03/27 10:20 +0100, John Doe a écrit:
If I do another pkg update, it will redo the whole thing again.
The server has been up for 326 days.
Is it because I am forced to reboot to activate all the new updates and
not just the kernel related ones?
Yes. It's how IPS/pkg was designed to work:
On 2014-03-27 10:02, John Doe wrote:
If I do another pkg update, it will redo the whole thing again.
The server has been up for 326 days.
Is it because I am forced to reboot to activate all the new updates and
not just the kernel related ones?
-
OpenIndiana (powered by illumos)SunOS
From: Laurent Blume laurent...@elanor.org
Yes. It's how IPS/pkg was designed to work: by default, it does not
update the current environment, it creates a new one, and update that
one. So your updates won't be used until you reboot to the new environment.
Ah, thanks to both for the
Le 2014/03/27 11:47 +0100, John Doe a écrit:
Ah, thanks to both for the confirmation.
Coming from linux, I am used to just reboot for kernel updates.
And, since I cannot easily reboot, guess updates will have to wait...
Yup, welcome to Windows 95, err, IPS.
last question, when I see Boot
On 03/27/14 03:36 AM, John Doe wrote:
From: Laurent Blume laurent...@elanor.org
Yes. It's how IPS/pkg was designed to work: by default, it does not
update the current environment, it creates a new one, and update that
one. So your updates won't be used until you reboot to the new environment.
Hello Reginald Beardsley and List,
On März, 26 2014, 14:43 Reginald Beardsley wrote in [1]:
# echo ::walk sd_state | ::grep '.!=0' | ::print struct sd_lun
un_sd |::print struct scsi_device sd_inq | ::print struct
scsi_inquiry inq_vid inq_pid | mdb -k
inq_vid = [ Toshiba ]
inq_pid = [
What's the correct way to recover from loss of power to a USB disk based pool?
I cleverly unplugged the wrong wall wart from the power strip behind my monitor
and dropped power to a USB disk that was being written to. The system stayed
up, but any attempt to restart or kill the write operation
On 27 March 2014 18:28, Reginald Beardsley pulask...@yahoo.com wrote:
What's the correct way to recover from loss of power to a USB disk based
pool?
I cleverly unplugged the wrong wall wart from the power strip behind my
monitor and dropped power to a USB disk that was being written to. The
Hello all,
Since upgrading to oi_151a8 on an older server we'veat least twice lost the
ability to connect via ssh to a particular local zone. New connections are just
quickly refused with no sun-ssh banner (including tests from localhost), while
old sessions work and restarts of the daemon
Hi,
Are you sure the * is not allowed?
We had several posts on this list a while back about wildcarding entries in
sd.conf to get around drives with strange names (my SanDisk SSD is an example)
that are incorrectly parsed by the sd driver.
I know for sure you can wildcard both the vendor and
Le 2014/03/27 22:23 +0100, Jonathan Adams a écrit:
on a positive note, taking an unreliable old USB ZFS pool off of a
misbehaving Solaris 10 box and plugging into an Ubuntu with ZFS allowed the
USB drive to work flawlessly for a long time thereafter ... Ubuntu ZFS
seems a lot more stable and
*Toshiba* is certainly allowed (cf. line 4480 of sd.c). It's pretty natural
for a user to think they were getting shell semantics which they are not. *
has to be the first and last character but I don't think that's the issue here.
The behavior is the same if the string is Toshiba
On Friday, March 28, 2014 07:05 AM, Ray Van Dolson wrote:
On Thu, Mar 27, 2014 at 01:06:00PM -0400, Harry Putnam wrote:
Running oi -b 151_a8
I'm having a problem with smb/server in that it falls into
maintenance mode and logs say:
[...]
smbd: kernel bind error: Address already in use
14 matches
Mail list logo