LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 08-21-2013, 11:00 AM   #1
henryyao
LQ Newbie
 
Registered: Jul 2013
Posts: 23

Rep: Reputation: 0
how to set boot delay using bash shell


I know how to achieve that in the u-boot.
However, is there a way to do this in the linux terminal using bash shell, or just modify some system env?
 
Old 08-21-2013, 11:53 AM   #2
rtmistler
Moderator
 
Registered: Mar 2011
Location: Sutton, MA. USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu
Posts: 4,484
Blog Entries: 10

Rep: Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643
I think what you're asking is how you can change boot parameters when Linux is up and running already.

You have to edit your boot environment. Typically the boot environment is on flash in protected sectors. Therefore you'd have to make a routine to un-protect the flash, read it, do the modifications you require, then save back to flash and re-protect the sectors. Some stuff may already exist. We had to do this long ago when using this bootloader because we needed to option it for booting between different images which were at different disk locations. What we chose to do actually was to have the bootloader load a fixed environment which depended on variables, we established those variables first by reading a totally separate sector in flash. This way our active Linux (upgrade process) would edit solely the "content" of the boot variables, but not the integrity of the bootloader environment. For instance, we'd establish a variable; such as BOOT_DELAY, and the bootloader environment used

Code:
bootdelay=$BOOT_DELAY
Our setup prior to reading the boot environment would establish either these variables as read from our "settings" flash location, or use defaults. I.e. we'd establish defaults; read the "settings" location and if the checksum was OK, we'd modify any variables which were included in the "settings" location. Then read the boot environment; which was always consistent in using the variables. This way we ran less of a chance of corrupting our boot environment; we could corrupt the "settings" location, but we had a checksum of it and started with defaults. In fact, part of certain upgrades where we wanted to force defaulting of the box, we'd force that checksum to be an impossible value and thus cause a rewrite of the settings sector to be a default.

Sorry, I'm half-recalling more and more as I've written here. The main points were that we were concerned that even though we could edit the boot environment from our operational image, we felt it was risky, so we figured a way to do this where we could encounter one or more of the potential problems we foresaw and still work.
 
1 members found this post helpful.
Old 08-22-2013, 04:08 PM   #3
henryyao
LQ Newbie
 
Registered: Jul 2013
Posts: 23

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by rtmistler View Post
I think what you're asking is how you can change boot parameters when Linux is up and running already.

You have to edit your boot environment. Typically the boot environment is on flash in protected sectors. Therefore you'd have to make a routine to un-protect the flash, read it, do the modifications you require, then save back to flash and re-protect the sectors. Some stuff may already exist. We had to do this long ago when using this bootloader because we needed to option it for booting between different images which were at different disk locations. What we chose to do actually was to have the bootloader load a fixed environment which depended on variables, we established those variables first by reading a totally separate sector in flash. This way our active Linux (upgrade process) would edit solely the "content" of the boot variables, but not the integrity of the bootloader environment. For instance, we'd establish a variable; such as BOOT_DELAY, and the bootloader environment used

Code:
bootdelay=$BOOT_DELAY
Our setup prior to reading the boot environment would establish either these variables as read from our "settings" flash location, or use defaults. I.e. we'd establish defaults; read the "settings" location and if the checksum was OK, we'd modify any variables which were included in the "settings" location. Then read the boot environment; which was always consistent in using the variables. This way we ran less of a chance of corrupting our boot environment; we could corrupt the "settings" location, but we had a checksum of it and started with defaults. In fact, part of certain upgrades where we wanted to force defaulting of the box, we'd force that checksum to be an impossible value and thus cause a rewrite of the settings sector to be a default.

Sorry, I'm half-recalling more and more as I've written here. The main points were that we were concerned that even though we could edit the boot environment from our operational image, we felt it was risky, so we figured a way to do this where we could encounter one or more of the potential problems we foresaw and still work.


It's a very good idea. Thanks. But for me(newbie) its too complicated. Thanks a lot anyway.
 
Old 08-22-2013, 04:12 PM   #4
rtmistler
Moderator
 
Registered: Mar 2011
Location: Sutton, MA. USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu
Posts: 4,484
Blog Entries: 10

Rep: Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643Reputation: 1643
I realize that, but given that you're using u-boot you're likely on an embedded platform. I'd consider it if you're creating a product. But do agree that if this is merely experimentation or a personal project, then you're just better off editing it once, saving the environment and leaving it at that.

When you break into u-boot, you can print the environment, via printenv, and you can change the boot delay setting there, then you can save the environment, via saveenv and it should stay that way for each recurring boot.
 
Old 08-22-2013, 04:20 PM   #5
henryyao
LQ Newbie
 
Registered: Jul 2013
Posts: 23

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by rtmistler View Post
I realize that, but given that you're using u-boot you're likely on an embedded platform. I'd consider it if you're creating a product. But do agree that if this is merely experimentation or a personal project, then you're just better off editing it once, saving the environment and leaving it at that.

When you break into u-boot, you can print the environment, via printenv, and you can change the boot delay setting there, then you can save the environment, via saveenv and it should stay that way for each recurring boot.

Ye. Setting in the u-boot would be easier.. I will take a good look at your method when I have enough time, its defninitly a very good idea to solve this kind of problems.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
ssh from solaris 9 with a bash shell of 2.0 to suse 3.2 bash shell slufoot80 Solaris / OpenSolaris 3 09-19-2012 04:06 PM
ssh from solaris 9 with a bash shell of 2.0 to suse 3.2 bash shell slufoot80 Solaris / OpenSolaris 1 09-19-2012 02:19 PM
Slackware 64 1337, slight delay when processing commands using Bash shell hyperhead Slackware 7 04-26-2011 04:05 AM
How to set the environment variables in BASH shell (RHEL) madhusudaniyaar Linux - Newbie 2 06-04-2009 05:41 AM
how-to: repeat OR iterate shell OR bash command delay OR interval admarshall Linux - General 5 07-18-2005 11:47 PM


All times are GMT -5. The time now is 05:50 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration