{"id":228,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:39","modified_gmt":"2020-08-22T20:26:39","slug":"this-is-the-page-title-toplevel-63","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=228","title":{"rendered":"The Boot Process"},"content":{"rendered":"\nThe Boot Process<\/title>\n<concept id=\"\" description=\"The process of turning on your computer and having it jump through hoops to bring up the operating system is called 'booting'\" \/>\n<p>\nThe process of turning on your computer and having it jump through hoops to bring up the\noperating system is called <glossary term=\"boot\">booting<\/glossary>, which derives from the term\n<i>bootstrapping<\/i>. This is an allusion to the idea that a computer pulls\nitself up by its bootstraps, in that smaller pieces of simple code start larger,\nmore complex pieces to get the system running.<\/p>\n<p>\nThe process a computer goes through is similar among different computer types, whether it is a PC,\nMacintosh, or SPARC Workstation. In the next section, I will be talking\nspecifically about the PC, though the concepts are still valid for other\nmachines.\n<\/p>\n<concept id=\"\" description=\"When a PC starts the first thing it does is a Power-On Self-Test.\" \/>\n<question id=\"103\" text=\"What is typically the first step when your computer boots?\" \/>\n<question id=\"104\" text=\"Where is hardware information stored that the system uses when booting?\" \/>\n<p>\nThe first thing that happens is the Power-On Self-Test (<glossary>POST<\/glossary>).\nHere the hardware checks itself to see that things are all right. It compares\nthe hardware settings in the <glossary>CMOS<\/glossary>\n(Complementary Metal Oxide Semiconductor) to\nwhat is physically on the system. Some errors, like the floppy types not\nmatching, are annoying, but your system still can <glossary>boot<\/glossary>.\nOthers, like the lack of a video card, can keep the boot process from continuing. Often, there is nothing to indicate what the problem is, except for a few little “beeps.” or perhaps an LED on the fron of the computer.\n<\/p>\n<p>\nNewer computers are somewhat more verbose in terms of the information provided when POST errors occur. Some computers have a small display panel on the front the machine. This is typically not large enough to display more than a few characters at a time (often the text is scrolled). However, an error code like “EOB42” is easier to google for than “two short beeps followed by a long beep”. Whether beeps or information on a display panel, this information is typically available in the manual provided by the computer or motherboard, as well as the manufacturers web site.\n<\/p>\n<p>\nTypically you can configure your BIOS to automatically perform different tests when the system boots. If you system reboots on its own, it may be wise to have more detailed test performed. On the other hand, this does take longer, so you might want to configure the BIOS to perform only a minimal test to get the system up and running faster.\n<\/p>\n<p>\nOnce the <glossary>POST<\/glossary> is\ncompleted, the hardware jumps to a specific, predefined location in <glossary>RAM<\/glossary>.\nThe\ninstructions located here are relatively simple and basically tell the hardware\nto go look for a <glossary>boot<\/glossary>\ndevice. Depending on how your <glossary>CMOS<\/glossary>\nis configured, the\nhardware first checks your floppy and then your hard disk.\n<\/p>\n<question id=\"105\" text=\"Where is the master boot record located?\" \/>\n<concept id=\"113\" description=\"The master boot record located first sector on the hard disk.\" \/>\n<concept id=\"\" description=\"The code in the master boot record is smart enough to read the partition table and find the active partition.\" \/>\n<concept id=\"\" description=\"Once it finds the active partition, the code in the master boot record executes the instructions contained within the first block.\" \/>\n<p>\nWhen a boot device is found (let’s assume that it’s a hard disk), the hardware is told to go\nto the 0th (first) <glossary>sector<\/glossary>\n(<glossary>cylinder<\/glossary> 0, <glossary>head<\/glossary> 0, sector 0), then load and execute\nthe instructions there. This is the master <glossary>boot<\/glossary>\nrecord, or <glossary>MBR<\/glossary>\nfor you DOS-heads (sometimes also called the master <glossary>boot<\/glossary>\nblock.) This code is small enough to fit\ninto one block but is intelligent enough to read the <glossary>partition<\/glossary>\ntable (located just past the master <glossary>boot<\/glossary>\nblock) and find the <glossary>active partition<\/glossary>.\nOnce it finds the active partition,\nit begins to read and execute the instructions contained within the first block.\n<\/p>\n<question id=\"106\" text=\"Virus can typically only affect Linux if the attack the master boot record.\" \/>\n<concept id=\"\" description=\"Viruses can infect the masterbook block of a Linux system just as easier as Windows system.\" \/>\n<p>\nIt is at this point that viruses can\naffect\/infect Linux systems. The master <glossary>boot<\/glossary>\nblock has the same format for essentially all PC-based operating systems and all it does\nis find and execute code at the\nbeginning of the <glossary>active partition<\/glossary>. But if the master boot\nblock contains code\nthat tells it to go to the very last <glossary>sector<\/glossary> of the hard disk\nand execute the code there, which then tells the system to execute code at\nthe beginning of the active partition, you would never know anything was wrong.\n<\/p>\n<p>\nLet’s assume that the instructions at the\nvery end of the disk are larger than a single 512-byte <glossary>sector<\/glossary>.\nIf the instructions took up a couple of kilobytes, you could get some fairly\ncomplicated code. Because it is at the end of the disk, you would probably never\nknow it was there. What if that code checked the date in the <glossary>CMOS<\/glossary>\nand, if the\nday of the week was Friday and the day of the month was 13, it would erase the\nfirst few kilobytes of your hard disk? If that were the case, then your system\nwould be infected with the Friday the 13th virus, and you could no longer boot\nyour hard disk.\n<\/p>\n<concept id=\"\" description=\"Viruses which infect the master book record are called 'boot viruses'.\" \/>\n<p>\nViruses that behave in this way are called “boot\nviruses,” as they affect the master <glossary>boot<\/glossary>\nblock and can only damage your\nsystem if this is the disk from which you are booting. These kinds of viruses\ncan affect all PC-based systems. Some computers will allow you to configure them\n(more on that later) so that you cannot write to the master <glossary>boot<\/glossary>\nblock. Although this is a good safeguard against older viruses, the newer ones can\nchange the <glossary>CMOS<\/glossary>\nto allow writing to the master boot\nblock. So, just because you have enabled this feature does not mean your system is safe.\nHowever, I must point out that boot\nviruses can only affect Linux systems if you boot from an\ninfected disk. This usually will be a floppy, more than likely a <glossary>DOS<\/glossary>\nfloppy. Therefore, you need to be especially careful when booting from floppies.\n<\/p>\n<p>Now back to our story… <\/p>\n<p>\nAs I mentioned, the code in the master boot block finds the <glossary>active partition<\/glossary>\nand begins executing the code there. On an\nMS-DOS system, these are the IO.SYS and MSDOS.SYS files. On an Linux system,\nthis is often the <glossary>LILO<\/glossary> or Linux loader “program.” Although IO.SYS and\nMSDOS.SYS are “real” files that you can look at and even remove if you\nwant to, the LILO program is not. The LILO program is part of the <glossary>partition<\/glossary>,\nbut not part of the file system; therefore, it is not a “real” file. Regardless of what\nprogram is booting your system and loading the kernel, it is generally referred to as a\n“boot loader”.\n<\/p>\n<p>\nA good bootloader, like those provided with LInux, allows you to select the image you want to boot from. Being able to select a specific image (including different boot parameters) allows\nyou to not only boot various Linux kernels on the same system, but allows you to boot different operating systems, as well.\n<\/p>\n<p>\nOften, LILO is installed in the master <glossary>boot<\/glossary>\nblock of the hard disk itself. Therefore, it will be the first code to run when your system is booted.\nIn this case, LILO can be used to start other operating systems. On one machine,\nI have teh bootloader start either <glossary>Windows XP<\/glossary>\nor one of two different versions of Linux.\n<\/p>\n<concept id=\"\" description=\"LILO can be installed in the master boot record or the boot sector of a partition.\" \/>\n<question id=\"\" type=\"TF\" text=\"LILO must be installed in the master boot record.\" \/>\n<p>\nIn other cases, <glossary>LILO<\/glossary> is installed in the <glossary>boot<\/glossary>\n<glossary>sector<\/glossary>\nof a given partition. In this case, it is referred to as a “secondary” boot\nloader and is used just to load the Linux installed on that <glossary>partition<\/glossary>.\nThis is useful if you have another <glossary>operating system<\/glossary>\nsuch as Windows XP or 2000 and you use the boot\nsoftware from that OS to load any others. However, neither of these\nwas designed with Linux in mind. Therefore, I usually have LILO loaded in the master boot\nblock and have it do all the work.\n<\/p>\n<question id=\"503\" text=\"LILO uses the system BIOS to access the hard disk.\" \/>\n<p>\nAssuming that LILO has been written to the master boot record and is, therefore, the master\nboot record, it is loaded by the system BIOS into a specific memory location (0x7C00) and\nthen executed.\nThe primary boot loader then uses the system BIOS to load the secondary boot loader into a\nspecific memory (0x9B000). The reason that the BIOS is still used at this point is that by\nincluding the\ncode necessary to access the hardware, the secondary boot loader would be extremely large\n(at least by comparison to its current size.) Furthermore, it would need to be able to recognize and\naccess different hardware types such as IDE and EIDE, as well as SCSI, and so forth.\n<\/p>\n<concept id=\"\" description=\"LILO and the secondary boot loader cannot access cylinders on the hard disk that are above 1023.\" \/>\n<question id=\"\" type=\"\" text=\"LILO and the secondary boot loader cannot access cylinders on the hard disk that are above 1023.\" \/>\n<p>\nThis limits <glossary>LILO<\/glossary>, because it is obviously dependant on the\n<glossary>BIOS<\/glossary>. As a result, LILO and\nthe secondary boot loader cannot access cylinders on the hard disk that are above 1023. In fact,\nthis is a problem for other PC-based operating systems, as well. There are two solutions to this problem.\nThe original solution is simply to create the partitions so that the LILO and the secondary boot loader\nare at cylinder 1023 or below. This is one reason for the moving the boot files into the <directory>\/boot<\/directory>\ndirectory which is often on a separate file system, that lies at the start of the hard disk.\n<p>\nThe other solution is something called “<glossary>Logical Block Addressing<\/glossary>” (LBA). With LBA, the <glossary>BIOS<\/glossary>\n“thinks” there are less sectors than there actually are. Details on LBA can be found in the <tutorial id=\"126\">section on hard disks<\/tutorial>.\n<\/p>\n<p>\nContrary to common belief, it is actually the secondary boot loader that provides the prompt and accepts the various options. The secondary boot loader is what reads the <file type=\"\">\/boot\/map<\/file> file to determine the location of <glossary>kernel<\/glossary> image to load.\n<\/p>\n<p>\nYou can configure <glossary>LILO<\/glossary> with a wide range of options. Not only can you <glossary>boot<\/glossary>\nwith different operating systems, but with Linux you can <glossary>boot<\/glossary>\ndifferent versions of the <glossary>kernel<\/glossary>\nas well as use different root file systems. This is useful if you are a developer because you\ncan have multiple versions of the <glossary>kernel<\/glossary>\non a single system. You can then boot them and test your product in different environments.\nWe’ll go into details about configuring LILO in the section on\n<tutorial id=\"92\">Installing your Linux kernel<\/tutorial>.\n<\/p>\n<p>\nIn addition, I might have as many as three copies of my <glossary>kernel<\/glossary>\non the system and have configured <glossary>LILO<\/glossary> to\nbe able to <glossary>boot<\/glossary>\nany one of them. The first copy is the current <glossary>kernel<\/glossary>\nI am using. When I rebuild a new <glossary>kernel<\/glossary>\nand install it, it gets copied to <file type=\"\">\/vmlinuz.old<\/file>, which is the second <glossary>kernel<\/glossary>\nI can access. I then have a copy called\n<file type=\"\">\/vmlinuz.orig<\/file>, which is the original kernel\nfrom when I installed that\nparticular release. This, at least, contains the drivers necessary to <glossary>boot<\/glossary>\nandaccess my hard disk and <glossary>CD-ROM<\/glossary>. If I can get that far, I can reinstall what I\nneed to.\n<\/p>\n<p>\nNote that in recent years, I have found it uncessary to maintain multiple copies of the kernel. In fact, Linux has gottten so good at recognizing hardware that typically everything I need is installed by\ndefault. It has been a long time since I have had to explicitely add a driver to my system and then create a new kernel.\n<\/p>\n<concept id=\"\" description=\"Typically on newer Linux versions, the kernel is stored in the \/boot directory.\" \/>\n<question id=\"\" type=\"TF\" text=\"Typically on newer Linux versions, the kernel is stored in the \/boot directory.\" \/>\n<p>\nTypically, the <glossary>kernel<\/glossary> is no longer stored in the root directory, but rather in the <directory>\/boot<\/directory> directory. Also, you will find that it is common that the version number of the respective kernel is added onto the end. For example, <file type=\"binary\">\/boot\/vmlinuz.2.4.18<\/file>, which would indicate that this kernel is version 2.4.18. What is important is that the kernel can be located when the system boots and not what it is called.\n<\/p>\n<p>\nBecause I write about various products on different Linux distributions, I have more\nthan one distribution of Linux installed on my system. It was very useful to see\nwhether the <glossary>application<\/glossary> software provided with one release\nwas compatible with the <glossary>kernel<\/glossary> from a different distribution.\nUsing various options to <glossary>LILO<\/glossary>, I could boot one kernel\nbut use the root file system from a different version. This was also useful on at least one\noccasion when I had one version that didn’t have the correct drivers in the\n<glossary>kernel<\/glossary> on the hard disk and I couldn’t even boot it.\n<\/p>\n<p>\nBoth LILO and GRUB allow you to interactively controll the boot process. That is you have a relatively simplistics menuing system whereby you can define\ndifferent kernels or different parameters with to use during the boot processes. You can then select the specific entry when the system boots. For example, you might\nhave different memory parameters which if you want to test how a specific application behaves under different conditions. If you only want to test the system once with\nspecific parameters, both boot loaders allow you to define various parameters when the system boots.\n<\/p>\n<p>\nOnce your system boots, you will see the <glossary>kernel<\/glossary>\nbeing loaded and started. As it is loaded and begins to execute, you will see screens\nof information flash past. For the uninitiated, this is overwhelming, but after\nyou take a closer look at it, most of the information is very straightforward.\n<\/p>\n<question id=\"107\" text=\"Errors encountered as the system boots can be found in which file?\" \/>\n<concept id=\"114\" description=\"Errors encountered as the system boots can be found in \/var\/log\/messages.\" \/>\n<question id=\"108\" text=\"What is the system logging daemon?\" \/>\n<concept id=\"115\" description=\"The system logging daemon is syslogd.\" \/>\n<p>\nOnce you’re booted, you can see this information in the file\n<file type=\"\">\/usr\/adm\/messages<\/file>. Depending on your system, this file might\nbe in <directory>\/var\/adm<\/directory> or even\n<directory>\/var\/log<\/directory>, although <directory>\/var\/log<\/directory> seems to be the most common as of this writing. In the messages file, as well as during the <glossary>boot<\/glossary>\nprocess, you’ll see several types of information that the system logging <glossary>daemon<\/glossary>\n(<command>syslogd<\/command>) is writing. The syslogd daemon\nusually continues logging as the system is running, although you can turn it off if you\nwant. To look at the kernel messages messages after the system boots, you can use the\n<command>dmesg<\/command> command.\n<\/p>\n<p>The general format for the entries is:<\/p>\n<concept id=\"\" description=\"The standard format of syslogd entries is 'time hostname program: message'.\" \/>\n<question id=\"\" type=\"MC\" text=\"What is the standard format of syslogd entries?\" \/>\n<p>\n<screenoutput>\ntime hostname program: message\n<\/screenoutput>\n<\/p>\n<p>\nwhere time is the system time when the message is generated, <glossary>hostname<\/glossary>\nis the <glossary>host<\/glossary> that generated the message, program is the\nprogram that generated the message, and message is the text\nof the message. For example, a message from the <glossary>kernel<\/glossary>\nmight look like this:\n<\/p>\n<p>\n<screenoutput>\nMay 13 11:34:23 localhost kernel ide0: do_ide_reset: success\n<\/screenoutput>\n<\/p>\n<p>\nAs the system is booting, all you see are the messages themselves and not the other information. Most of\nwhat you see as the system boots are messages from <glossary>kernel<\/glossary>,\nwith a few other things, so you would see this message just as\n<\/p>\n<p>\n<screenoutput>ide0: do_ide_reset: success<\/screenoutput>\n<\/p>\n<p>\nMuch of the information that the syslogd <glossary>daemon<\/glossary>\nwrites comes from device drivers that perform any initialization routines. If you have hardware problems\non your system, this is <i>very<\/i> useful information. One example I encountered was with two pieces of hardware that were both software-configurable. However, in both cases, the software wanted to configure\nthem as the same <glossary>IRQ<\/glossary>. I could then change the source code and recompile so that\none assigned a different <glossary>IRQ<\/glossary>.\n<\/p>\n<p>\nYou will also notice the <glossary>kernel<\/glossary> checking the existing hardware for specific capability, such as whether an <glossary>FPU<\/glossary> is present,\nwhether the <glossary>CPU<\/glossary> has the hlt (halt)\ninstruction, and so on. <\/p>\n<question id=\"109\" text=\"What file is used to configure the system logger daemon?\" \/>\n<p>\nWhat is logged and where it is logged is based on\nthe <file type=\"\">\/etc\/syslog.conf<\/file> file. Each entry is\nbroken down into facility.priority,\nwhere facility is the part of the system such as the <glossary>kernel<\/glossary>\nor printer spooler and <glossary>security<\/glossary>\nand priority indicate the severity of the message. The\nfacility.priority ranges from none, when no messages\nare logged, to emerg, which represents\nvery significant events like <glossary>kernel<\/glossary>\npanics. Messages are generally logged to one\nfile or another, though emergency messages should be displayed to everyone\n(usually done by default). See the syslog.conf <glossary>man-page<\/glossary>\nfor details.\n<\/p>\n<question id=\"110\" text=\"What is the first process started?\" \/>\n<question id=\"111\" text=\"What is the configuration file for the init program?\" \/>\n<concept id=\"116\" description=\"The first process started is init.\" \/>\n<concept id=\"117\" description=\"The configuration file for the init program is stored in the file \/etc\/inittab.\" \/>\n<p>\nOne last thing that the <glossary>kernel<\/glossary>\ndoes is start the <command>init<\/command> process, which reads the\n<file type=\"\">\/etc\/inittab<\/file> file. It looks for any entry that should\nbe run when the system is initializing (the entry has a\nsysinit in the third field) and then executes the\ncorresponding command. (I get into details about different run-levels in another section.)<\/p>\n<p>\nThe first thing <glossary>init<\/glossary> runs out of the inittab is the script\n<file type=\"\">\/etc\/rc.d\/rc.sysinit<\/file>. As with everything else under <directory>\/etc\/rc.d<\/directory>, this is a shell script, so <site id=\"67\">you can take a look<\/site> at it if\nyou want. Actually, I feel that looking through and becoming familiar with\nwhich scripts does what and it what order is a good way of learning about\nyour system.\n<\/p>\n<p>\nAmong the myriad of things done here are checking and <glossary term=\"mount\">mounting<\/glossary> file systems, removing old lock and <glossary>PID<\/glossary> files, and enabling the swap space.\n<\/p>\n<p>\nNote that if the file system check notes some serious problems, the rc.sysinit will stop and bring you to a\nshell prompt, where you can attempt to clean up by hand. Once you exit this\nshell, the next command to be executed (aside from an echo) is a reboot. This is\ndone to ensure the validity of the file systems.\n<\/p>\n<question id=\"114\" text=\"What entry in the inittab file determines the (system's) run level for a normal boot?\" \/>\n<question id=\"116\" text=\"What is typically the default run level for Linux?\" \/>\n<p>\nNext, <glossary>init<\/glossary> looks through inittab for the line with initdefault in the third field. The initdefault entry tells the system what <glossary>run-level<\/glossary>\nto enter initially, normally run-level 3\n(without <glossary>X<\/glossary>\nWindows) or run-level 5 (with X Windows). Other systems have the\ndefault run-level 1 to bring you into single-user or\n<glossary>maintenance mode<\/glossary>.\nHere you can perform certain actions without worrying users or too many other things\nhappening on your system. (Note: You can keep users out simply by creating the file\n\/etc\/nologin. See the nologin <glossary>man-page<\/glossary>\nfor details.)\n<\/p>\n<p>\nWhat kind of actions can you perform here? The action with the most\nimpact is adding new or updating software. Often, new software will affect old\nsoftware in such a way that it is better not to have other users on the system.\nIn such cases, the installation procedures for that software should keep you\nfrom installing unless you are in <glossary>maintenance mode<\/glossary>.\n<\/p>\n<p>\nThis is also a good place to configure hardware that you added or otherwise change the <glossary>kernel<\/glossary>. Although these actions rarely impact users, you will have to do a <glossary>kernel<\/glossary> rebuild. This takes up a lot of system resources and degrades overall\nperformance. Plus, you need to reboot after doing a <glossary>kernel<\/glossary>\nrebuild and it takes longer to reboot from <glossary>run-level<\/glossary> 3 than from run-level 1.\n<\/p>\n<question id=\"112\" text=\"Which run level would shut down the system\" \/>\n<concept id=\"118\" description=\"Run-level 0 is used to shutdown the system.\" \/>\n<p>\nIf the changes you made do not require you to rebuild the <glossary>kernel<\/glossary>\n(say, adding new software), you can go directly from single-user to\n<glossary>multi-user<\/glossary>\nmode by running <commandexample>init 3<\/commandexample>.\nThe argument to <glossary>init<\/glossary> is simply the <glossary>runlevel<\/glossary> you want to go\ninto, which, for most purposes, is <glossary>run-level<\/glossary> 3. However, to shut down the system, you could bring the system to run-level 0 or 6. (See the init <glossary>man-page<\/glossary>\nfor more details.)\n<\/p>\n<p>\n<command>Init<\/command> looks for any entry that has a 3 in the second field. This 3 corresponds to the\nrun-level where we currently are. Run-level 3 is the same as <glossary>multi-user<\/glossary>\nmode.\n<\/p>\n<p>\nWithin the <glossary>inittab<\/glossary>, there is a line for every <glossary>runlevel<\/glossary>\nthat starts the script <file type=\"\">\/etc\/rc.d\/rc<\/file>, passing the runlevel as an\n<glossary>argument<\/glossary>. The <file type=\"\">\/etc\/rc.d\/rc<\/file> script,\nafter a little housekeeping, then starts the scripts for that runlevel.\nFor each runlevel, there is a directory underneath <directory>\/etc\/rc.d<\/directory>,\nsuch as rc3.d, which contains the scripts that will be run for that runlevel.<\/p>\n<question id=\"113\" text=\"The two kinds of rc-scripts are\" \/>\n<p>\nIn these directories, you may find two sets of scripts. The scripts beginning with K are\nthe kill scripts, which are used to shutdown\/stop a particular subsystem. The S\nscripts are the start scripts. Note that the kill and start scripts are links to\nthe files in <directory>\/etc\/rc.d\/init.d<\/directory>. If there are K and S scripts with the same\nnumber, these are both linked to the same file. <\/p>\n<p>\nThis is done because the scripts are started with an <glossary>argument<\/glossary>\nof either start or stop. The script itself\nthen changes its behavior based on whether you told it to start or stop.\nNaming them something (slightly) different allows us to start only the K scripts\nif we want to stop things and only the S scripts when we want to start things.\n<\/p>\n<p>\nWhen the system changes to a particular <file type=\"\">runlevel<\/file>, the first scripts\nthat are started\nare the K scripts. This stops any of the processes that should not be running in\nthat level. Next, the S scripts are run to start the processes that should be\nrunning.\n<\/p>\n<p>\nLet’s look at an example. On most systems, <glossary>run-level<\/glossary> 3 is\n<i>almost<\/i> the same as run-level 2. The only difference is that in\nrun-level 2, <glossary>NFS<\/glossary> is not running. If you were to change from\nrun-level 3 to run-level 2, NFS would go down. In run-level 1 (maintenance mode),\nalmost everything is stopped.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The Boot Process The process of turning on your computer and having it jump through hoops to bring up the operating system is called booting, which derives from the term bootstrapping. This is an allusion to the idea that a … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=228\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-228","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/228","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=228"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/228\/revisions"}],"predecessor-version":[{"id":734,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/228\/revisions\/734"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=228"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}