TLDR: Patched a separate boot environment to 11.4. Activated and rebooted the system only to have it boot loop and show 11.3 on the patched boot environment.
Bootloop process: The system went down, came up showing 11.3 then spewed bunch of errors and resetted. SEE BELOW FOR THE FINAL MSG BEFORE AUTO REBOOT
This is a normal process for us to create a new boot environment, patch it, activate it and then boot to it. The update process was clean with running the history command
against the mounted boot environment. Once we were sure all users we off the system, we rebooted. The system had a bunch of messages as below:
Code:
WARNING: mod_load: cannot load module 'dev'
Code:
Warning - stack not written to the dumpbuf
This portion below was the final msg before system auto reset/reboot
Code:
Deferred dump not available.
dump subsystem not initialised
rebooting...
Resetting...
So what we had to do was shut the system down from console, start it up and get to "OK" prompt to manually switch back to the original
boot environment. We did attempt to boot the be with 11.4 but ran into the same issues.
What was strange is when the 11.4 be was booted, it showed 11.3 instead of 11.4. When we were able to boot into original be and check
the version of failed be, it shows 11.4
There was more msg than that but, don't want to give any confidential information out. Currently having support look into this but, it was strange. Thinking, maybe we should've updated to a middle release of 11.4 then trying to go for the latest.
Last edited by samthewildone; 07-16-2019 at 08:03 PM..
Reason: cleanup
During the boot-up process *nix runs scripts linked into the runlevel directories rc#.d. What I'm wondering is, how do I control the environment that those scripts see? I need to set a couple environment variables, and I can NOT do it from within the scripts because it poses a maintenance nightmare... (1 Reply)
Ok, a couple weeks ago I was fixing a cron report about perl not happy with 'locale' info (LANG and LC not set). As a result, I was experimenting with setting the correct 'locale' in several areas (like /etc/sysconfig/i18n and who knows where). Somehow after a reboot, as soon as the OS starts... (3 Replies)
I 'm having a weired situation my system has 8 zones, running fine on solaris x86_u4. I installed the live upgrade bundle patch and did a live upgrade. The new BE was created but it missed one of the zone and now if i mount the new BE i do not see that zone in the environment so my question is how... (3 Replies)
Hi,
Is it possible to perform an luupgrade on the active boot environment in Solaris?
I want to perform this on BEAlpha - the disk that has BEOmega will be unavailable whilst performing the upgrade but I still want to install the patches using luupgrade.
Boot Environment Is... (4 Replies)
Hi all,
I'm fairly new to Solaris and am just getting to grips with using LU (Live Upgrade) for OS patching purposes.
worcester#uname -a
SunOS worcester 5.10 Generic_144488-12 sun4v sparc SUNW,SPARC-Enterprise-T5220I have successfully created and patched a new BE (boot environment) using the... (5 Replies)
I'm trying to automate the patching process using scripts and cronjobs in Solaris 11.
one of the things I'd like to do is cleanup the old boot environments.
unfortunately
beadm destroy
requires a response
:~$ pfexec beadm destroy -f solaris-13
Are you sure you want to destroy... (3 Replies)
My OS solarius 5.10 Generic_147148-2 i86
Error: please review new boots environments using options
1. Solution - show me the commands
Partition is full, try to remove some unneeded files,
then try to compress some other unneeded files.
man command creates a temp file under... (0 Replies)
fyi, I already have SR opened with Oracle.
We are looking to upgrade from S11.3 to S11.4 with the latest SRU.
Create new BE; success
Mount new BE; success
pkg -R /mnt update the updating of the global went fine until it touched local zone.
pkg: update failed (linked image... (2 Replies)
Discussion started by: samthewildone
2 Replies
LEARN ABOUT SUNOS
reboot
reboot(3C)reboot(3C)NAME
reboot - reboot system or halt processor
SYNOPSIS
#include <sys/reboot.h>
int reboot(int howto, char *bootargs);
The reboot() function reboots the system. The howto argument specifies the behavior of the system while rebooting and is a mask con-
structed by a bitwise-inclusive-OR of flags from the following list:
RB_AUTOBOOT The machine is rebooted from the root filesystem on the default boot device. This is the default behavior. See boot(1M) and
kernel(1M).
RB_HALT The processor is simply halted; no reboot takes place. This option should be used with caution.
RB_ASKNAME Interpreted by the bootstrap program and kernel, causing the user to be asked for pathnames during the bootstrap.
RB_DUMP The system is forced to panic immediately without any further processing and a crash dump is written to the dump device
(see dumpadm(1M)) before rebooting.
Any other howto argument causes the kernel file to boot.
The interpretation of the bootargs argument is platform-dependent.
Upon successful completion, reboot() never returns. Otherwise, -1 is returned and errno is set to indicate the error.
The reboot() function will fail if:
EPERM The {PRIV_SYS_CONFIG} privilege is not asserted in the effective set of the calling process.
intro(1M), boot(1M), dumpadm(1M), halt(1M), init(1M), kernel(1M), reboot(1M), uadmin(2)
22 Mar 2004 reboot(3C)
07-13-2019
