On a test server there are two Samsung 960 Pro SSDs, exactly same maker, model and size. On both I've installed a fresh install of exactly the same OS, OmniOS r15026.
By pressing F8 at POST time, I can access the motherboard BOOT manager, and choose one of the two boot drives. Thus, I know which one the system booted from.
But how can one know programmatically, after boot, which is the boot disk?
It seems that is:
Not possible on Linux,
Not possible on FreeBsd
Possible on macOS.
Does Solaris/illumos offer some introspective hooks to determine which is the boot disk?
Is it possible to programmatically determine which is the boot disk on Solaris/illumos?
A command line tool would be fine too.
Edit 1: Thanks to #andrew-henle, I have come to know command eeprom.
As expected it is available on illumos, but on test server with OmniOS unfortunately it doesn't return much:
root#omnios:~# eeprom
keyboard-layout=US-English
ata-dma-enabled=1
atapi-cd-dma-enabled=1
ttyd-rts-dtr-off=false
ttyd-ignore-cd=true
ttyc-rts-dtr-off=false
ttyc-ignore-cd=true
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyd-mode=9600,8,n,1,-
ttyc-mode=9600,8,n,1,-
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
lba-access-ok=1
root#omnios:~# eeprom boot-device
boot-device: data not available.
Solution on OmniOS r15026
Thanks to #abarczyk I was able to determine the correct boot disk.
I had to use a slightly different syntax:
root#omnios:~# /usr/sbin/prtconf -v | ggrep -1 bootpath
value='unix'
name='bootpath' type=string items=1
value='/pci#38,0/pci1022,1453#1,1/pci144d,a801#0/blkdev#w0025385971B16535,0:b
With /usr/sbin/format, I was able to see entry corresponds to
16. c1t0025385971B16535d0 <Samsung-SSD 960 PRO 512GB-2B6QCXP7-476.94GB>
/pci#38,0/pci1022,1453#1,1/pci144d,a801#0/blkdev#w0025385971B16535,0
which is correct, as that is the disk I manually selected in BIOS.
Thank you very much to #abarczyk and #andrew-henle to consider this and offer instructive help.
The best way to find the device from which the systems is booted is to check prtconf -vp output:
# /usr/sbin/prtconf -vp | grep bootpath
bootpath: '/pci#0,600000/pci#0/scsi#1/disk#0,0:a'
On my Solaris 11.4 Beta system, there is a very useful command called devprop which helps answer your question:
$ devprop -s bootpath
/pci#0,0/pci1849,8c02#1f,2/disk#1,0:b
then you just have to look through the output of format to see what that translates to. On my system, that is
9. c2t1d0 <ATA-ST1000DM003-1CH1-CC47-931.51GB>
/pci#0,0/pci1849,8c02#1f,2/disk#1,0
Use the eeprom command.
Per the eeprom man page:
Description
eeprom displays or changes the values of parameters in the EEPROM.
It processes parameters in the order given. When processing a
parameter accompanied by a value, eeprom makes the indicated
alteration to the EEPROM; otherwise, it displays the parameter's
value. When given no parameter specifiers, eeprom displays the values
of all EEPROM parameters. A '−' (hyphen) flag specifies that
parameters and values are to be read from the standard input (one
parameter or parameter=value per line).
Only the super-user may alter the EEPROM contents.
eeprom verifies the EEPROM checksums and complains if they are
incorrect.
platform-name is the name of the platform implementation and can be
found using the –i option of uname(1).
SPARC
SPARC based systems implement firmware password protection with
eeprom, using the security-mode, security-password and
security-#badlogins properties.
x86
EEPROM storage is simulated using a file residing in the
platform-specific boot area. The /boot/solaris/bootenv.rc file
simulates EEPROM storage.
Because x86 based systems typically implement password protection in
the system BIOS, there is no support for password protection in the
eeprom program. While it is possible to set the security-mode,
security-password and security-#badlogins properties on x86 based
systems, these properties have no special meaning or behavior on x86
based systems.
Related
I have a car navigation system installed in my car and I figured out that it's running vxWorks 6.9.3.
What I'm trying to achieve is to change some hidden settings of the nav-system.
Small introduction: Nav system have ability to connect to internet via Bluetooth. I setup small web-server the only thing it can do is detect IP address of client. I opened that web-site from head unit browser and detected ip address of head unit. Than I'm able to scan for opened network ports of it.
It turned out that it has 23 port open. And I'm able to telnet there.
It didn't required any password or login and it report operation system info: Windriver vxWorks 6.9.3
I can run various commands here, inspect filesystem, etc.
But I don't know how I can change something. I even found the way to transfer files from USB-key from and to device.
I found that all settings which I want to change are stored in .sqlite files. Some of them are gzipped and have .inf file with check-sums. Algorithm of check-sum calculation is proprietary so I can't transfer .sqlite files from device to usb-key, change something, than gzip and calculate new check-sum.
I think OS can somehow interact with .sqlite files in-memory without ungzip them.
So, is there any ways to open sqlite shell on device using vxWorks kernel shell?
If yes, that would be perfect and enough to achieve anything I want.
If this can't be achieved, can somebody give me some advice of what possibilities I have from vxWorks kernel shell?
The commands available on the VxWorks shell depend on the loaded applications and the kernel itself. From the shell you can call all "public functions" loaded by VxWorks. You enter the function call in a C-like syntax and the shell parses the arguments pushes them onto the stack and jumps to the address of the function just like a normal function call in C.
A helpful function to check if a funtion exists is lkup "foo" which will lists all functions containing "foo" in their name (case sensitive!). But it doesn't tell you anything about the requested parameters. If you are not passing all parameters to the function via the shell, the intepreter pushes some zeroes onto the stack before executing the function call. This may lead to very strange results and may even damage your system (depending on the function)...
If you're able to load a program you may want to use the functions of symLib to iterate all symbols of the VxWorks sysSymTbl.
What's the UNIX command to see the processes table, remember that table contains:
process status
pointers
process size
user ids
process ids
event descriptors
priority
etc
The "process table" as such lives in the kernel's memory. Some systems (such as AIX, Solaris and Linux--which is not "unix") have a /proc filesystem which makes those tables visible to ordinary programs. Without that, programs such as ps (on very old systems such as SunOS 4) required elevated privileges to read the /dev/kmem (kernel memory) special device, as well as having detailed knowledge about the kernel memory layout.
Your question is open ended, and an answer to a specific question you may have had can be looked up in any man page as #Alfasin suggests in his answer. A lot depends on what you are trying to do.
As #ThomasDickey points out in his response, in UNIX and most of its' derivatives, the command for viewing processes being run in the background or foreground is in fact the ps command.
ps stands for 'process status', answering your first bullet item. But the command uses over 30 options and depending on what information you seek, and permissions granted to you by the systems administrator, you can get various types of information from the command.
For example, for the second bullet item on your list above, depending on what you are looking for, you can get information on 3 different types of pointers - the session pointer (with option 'sess'), the terminal session pointer (tsess), and the process pointer (uprocp).
The rest of your items that you have listed are mostly available as standard output of the command.
Some UNIX variants implement a view of the system process table inside of the file system to support the running of programs such as ps. This is normally mounted on /proc (see #ThomasDickey response above)
Typical reasons for understanding the working of the command include system-administration responsibilities such as tracking the origin of the initiated processes, killing runaway or orphaned processes, examining the file size of the process and setting limits where necessary, etc. UNIX developers can also use it in conjunction with ipc features, etc. An understanding of the process table and status will help with associated UNIX features such as the kvm interface to examine crash dump, etc. or to get or set the kernal state.
Hope this helps
Does every Unix flavor have same boot sequence code ? I mean there are different kernel version releases going on for different flavors, so is there possibility of different code for boot sequence once kernel is loaded? Or they keep their boot sequence (or code) common always?
Edit: I want to know into detail how boot process is done.
Where does MBR finds a GRUB? How this information is stored? Is it by default hard-coded?
Is there any block level partion architecture available for boot sequence?
How GRUB locates the kernel image? Is it common space, where kernel image is stored?
I searched a lot on web; but it shows common architecture BIOS -> MBR -> GRUB -> Kernel -> Init.
I want to know details of everything. What should I do to know this all? Is there any way I could debug boot process?
Thanks in advance!
First of all, the boot process is extremely platform and kernel dependent.
The point is normally getting the kernel image loaded somewhere in memory and run it, but details may differ:
where do I get the kernel image? (file on a partition? fixed offset on the device? should I just map a device in memory?)
what should be loaded? (only a "core" image? also a ramdisk with additional data?)
where should it be loaded? Is additional initialization (CPU/MMU status, device initialization, ...) required?
are there kernel parameters to pass? Where should they be put for the kernel to see?
where is the configuration for the bootloader itself stored (hard-coded, files on a partition, ...)? How to load the additional modules? (bootloaders like GRUB are actually small OSes by themselves)
Different bootloaders and OSes may do this stuff differently. The "UNIX-like" bit is not relevant, an OS starts being ostensibly UNIXy (POSIX syscalls, init process, POSIX userland,...) mostly after the kernel starts running.
Even on common x86 PCs the start differs deeply between "traditional BIOS" and UEFI mode (in this last case, the UEFI itself can load and start the kernel, without additional bootloaders being involved).
Coming down to the start of a modern Linux distribution on x86 in BIOS mode with GRUB2, the basic idea is to quickly get up and running a system which can deal with "normal" PC abstractions (disk partitions, files on filesystems, ...), keeping at minimum the code that has to deal with hardcoded disk offsets.
GRUB is not a monolithic program, but it's composed in stages. When booting, the BIOS loads and executes the code stored in the MBR, which is the first stage of GRUB. Since the amount of code that can be stored there is extremely limited (few hundred bytes), all this code does is to act as a trampoline for the next GRUB stage (somehow, it "boots GRUB");
the MBR code contains hard-coded the address of the first sector of the "core image"; this, in turn, contains the code to load the rest of the "core image" from disk (again, hard-coded as a list of disk sectors);
Once the core image is loaded, the ugly work is done, since the GRUB core image normally contains basic file system drivers, so it can load additional configuration and modules from regular files on the boot partition;
Now what happens depends on the configuration of the specific boot entry; for booting Linux, usually there are two files involved: the kernel image and the initrd:
initrd contains the "initial ramdrive", containing the barebones userland mounted as / in the early boot process (before the kernel has mounted the filesystems); it mostly contains device detection helpers, device drivers, filesystem drivers, ... to allow the kernel to be able to load on demand the code needed to mount the "real" root partition;
the kernel image is a (usually compressed) executable image in some format, which contains the actual kernel code; the bootloader extracts it in memory (following some rules), puts the kernel parameters and initrd memory position in some memory location and then jumps to the kernel entrypoint, whence the kernel takes over the boot process;
From there, the "real" Linux boot process starts, which normally involves loading device drivers, starting init, mounting disks and so on.
Again, this is all (x86, BIOS, Linux, GRUB2)-specific; points 1-2 are different on architectures without an MBR, and are are skipped completely if GRUB is loaded straight from UEFI; 1-3 are different/avoided if UEFI (or some other loader) is used to load directly the kernel image. The initrd thing may be not involved if the kernel image already bundles all that is needed to start (typical of embedded images); details of points 4-5 are different for different OSes (although the basic idea is usually similar). And, on embedded machines the kernel may be placed directly at a "magic" location that is automatically mapped in memory and run at start.
I am working on Error Detection module and was attempting to test using the error injection implementation mentioned in Intel® Xeon® Processor C5500/C3500 Series Datasheet, Volume 2 in section 4.12.40. It asks to program the MC_CHANNEL_X_ADDR_MATCH, MC_CHANNEL_X_ECC_ERROR_MASK and MC_CHANNEL_X_ECC_ERROR_MASK registers but attempting to write to this has no effect. Realized there is a lock for this space which is indicated by status in MEMLOCK_STATUS register (device 0: function 0: offset 88h), which in my case is reporting 0x40401 as the set value. This means MEM_CFG_LOCKED is set and I am not able to even unlock using the MC_CFG_CONTROL register (device 0:function 0: offset 90h). I am writing 0x2 to this register but that does not help to unlock the ECC injection registers for writing. How can I achieve this? I am running FreeBSD on the bare metal and not as a virtual machine.
To the best of my knowledge, the whole TXT thing that is necessary for this is not supported on FreeBSD.
But this a quite an arcane area. You might have more luck asking this on the freebsd-hackers mailing list.
Is that possible to achieve Inter process communication using any terminal or serial ports in AIX or Unix?
I would like to achieve this by using commands/scripting only where one process writes a string on terminal and another process reads same terminal and processes that string. I know that using pipe also this is possible but I do not have enough idea on that.
Also is there a way we can determine which all ports/terminals are available in AIX machine?
Or is it possible to create new terminal at run time (not the boot time) that will be used by only above two processes?
I think what you want are pty's? Or, another option would be unix domain sockets.
The answer to your first question is "no"... not really. When you write out to a tty, that output is sent out to the real device and not available to be read back.
The list of tty's on a system is: lsdev -Cctty
Creating tty's at run time is possible but not really what you want either. A tty is a child of a serial port and you can not add serial ports arbitrarily. They are real things. With AIX and Power systems, you can add devices while the system is up (hot swap) but that is getting (I'm assuming) way far off your original topic.
The basic different between a pty and a unix domain socket is a pty mimics the output and input process of a real tty in one direction. This is what telnet, rlogin, ssh, and many other daemons use when connections come in. It is easy to make ksh believe that it has a real tty by using pty's. If you don't need that, then they are added trouble that you don't need. Find a link on how to create and use a Unix domain socket and you will have what you need (or a pipe but a pipe requires a parent / child relationship which I assume you do not have).