Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
S_E_
Advisor
Jump to solution

R81.10 boot menu password

Hi,

to reboot of a Smart-1 appliance into maintenance mode prompts for admin password.
According to sk109047, it should be the expert password.
However, it does not seem to work for R81.10 HF110
Ho can I reset the boot menu password ?
A set grub2-password does not exist (only R81.20)

Thanks, Regards

Gaia R81.10
+-------------------------------------------------------------------------+
| Revert from other image |
| Reset to factory defaults - Gaia R80.10 |
| Reset to factory defaults - Gaia R77.30 |
| Start in 64bit no-debug mode |
| Start in maintenance mode 64bit |
| Start in 64bit online debug mode |
| Start in 64bit normal mode |
| HW Diagnostics |
+-------------------------------------------------------------------------+
Use the ^ and v keys to select an entry.
Press enter to choose the boot option.
Admin password: ********
Failed!

 


SMS> set user admin password
New password:
Verify new password:

SMS> set expert-password
Enter current expert password:
Enter new expert password:
Enter new expert password (again):
SMS> save config
SMS> reboot

 

Gaia R81.10
+-------------------------------------------------------------------------+
| Revert from other image |
| Reset to factory defaults - Gaia R80.10 |
| Reset to factory defaults - Gaia R77.30 |
| Start in 64bit no-debug mode |
| Start in maintenance mode 64bit |
| Start in 64bit online debug mode |
| Start in 64bit normal mode |
| HW Diagnostics |
+-------------------------------------------------------------------------+
Use the ^ and v keys to select an entry.
Press enter to choose the boot option.
Admin password: ******
Failed!
Press any key to continue...

0 Kudos
1 Solution

Accepted Solutions
JanV
Explorer

Hi guys, I experienced the same issue today, opened a TAC case where I was advised to remove "lock" attribute from grub.conf file. See below:

1. login to expert
2. vi /boot/grub/grub.conf
3. find [title Gaia maintenance mode x64] or similar title with maintenance mode. 
b. remove 'lock' item under the [title ~ maintenance mode]
c. save file and exit.
d. reboot Gaia and select [Gaia maintenance mode ~], it will not require password any more. 
e. optional, when finished all job in maintenace mode, restore [lock] option under [title maintenance ~] in file /boot/grub/grub.conf.

 

View solution in original post

29 Replies
Alex-
Advisor
Advisor
0 Kudos
S_E_
Advisor

hi, unfortunately no. I used a very easy temporary pw.

Thanks Regards

0 Kudos
_Val_
Admin
Admin

Are you using a non-English locale by any chance?

 

0 Kudos
the_rock
Legend
Legend

Maybe uranus?

Andy

0 Kudos
_Val_
Admin
Admin

Not BIOS password, Andy 🙂 

the_rock
Legend
Legend

Duh...sorry, thats what I was thinking of.

0 Kudos
_Val_
Admin
Admin

Check this SK please: sk180176

S_E_
Advisor

Hi,

I tried approach sk180176

The first time it stuck in the grub boot process (manual power reset required).

However, I tried again  sk180176 and it reboots properly. HAsh value was properly in grub.conf.

But navigating into the menu 'Maintenance mode' ended again up with Admin password: Failed!

Thanks

Regards

0 Kudos
the_rock
Legend
Legend

I wish I had R81.10 lab to check this, sorry mate. Just curious, what does below show on yours?

Andy

[Expert@CP-TEST-FIREWALL:0]# cd /etc
[Expert@CP-TEST-FIREWALL:0]# ls -lh grub
grub.d/ grub2-efi.cfg grub2.cfg

 

0 Kudos
S_E_
Advisor

Hi, some output...

b.t.w. it is not a show stopper for anything. I simply wanted to increase the boot partition size to have space for more than 1 snapshot.

Regards

 


[Expert@SMS:0]# pwd
/etc

[Expert@SMS:0]# ls -lh grub
ls: cannot access grub: No such file or directory
[Expert@SMS:0]#

[Expert@SMS:0]# ls -lh grub*
lrwxrwxrwx 1 admin root 22 Oct 9 06:04 grub.conf -> ../boot/grub/grub.conf


[Expert@SMS:0]# more ../boot/grub/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/hda2
# initrd /initrd-version.img
#boot=/dev/sda
default=6
timeout=0
hiddenmenu
machine=ST-110-00
menutitle=Gaia R81.10
background 777777
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal --silent --timeout=5 console serial
password --encrypted <...REMOVED>
splashimage=(hd0,0)/grub/splash.xpm.gz

title Revert from other image
lock
root (hd0,0)
configfile /grub/submenus/switch_to_backup.lst

title Reset to factory defaults - Gaia R80.10
confirm This will erase the entire configuration. Do you wish to continu
e [no]:
root (hd0,0)
kernel /fcd_GAIA/vmlinuz-x86_64 ro root=/dev/mapper/vg_splat-lv_fcd_GAIA
console=CURRENT restore fcd_GAIA single
initrd /fcd_GAIA/initrd-x86_64

title Reset to factory defaults - Gaia R77.30
confirm This will erase the entire configuration. Do you wish to continu
e [no]:
root (hd0,0)
kernel /fcd_R77.30/vmlinuz-x86_64 ro root=/dev/mapper/vg_splat-lv_fcd_R7
7.30 console=CURRENT restore fcd_R77.30 single
initrd /fcd_R77.30/initrd-x86_64
title Start in 64bit no-debug mode
root (hd0,0)
kernel /vmlinuz-x86_64 ro root=/dev/mapper/vg_splat-lv_current grub_mod
e=64bit-no-debug vmalloc=256M panic=15 console=SERIAL intel_idle.max_cstate=0 e
agerfpu=on spectre_v2=off nopti 3 quiet
initrd /initrd-x86_64

title Start in maintenance mode 64bit
lock
root (hd0,0)
kernel /vmlinuz-x86_64 ro root=/dev/mapper/vg_splat-lv_current vmalloc=2
56M grub_mode=64bit-maintenance panic=15 console=CURRENT eagerfpu=on spectre_v2=
off nopti debug 7 single
initrd /initrd-x86_64

title Start in 64bit online debug mode
root (hd0,0)
kernel /vmlinuz-x86_64 ro root=/dev/mapper/vg_splat-lv_current grub_mod
e=64bit-online-debug vmalloc=256M panic=15 console=tty1 console=CURRENT kgdboc=
kbd,ttyS0 crashkernel=0M-35G:280M,35G-250G:768M,250G-:1G intel_idle.max_cstate=0
eagerfpu=on spectre_v2=off nopti 3
initrd /initrd-x86_64

title Start in 64bit normal mode
root (hd0,0)
kernel /vmlinuz-x86_64 ro root=/dev/mapper/vg_splat-lv_current grub_mod
e=64bit-normal vmalloc=256M panic=15 console=SERIAL crashkernel=0M-35G:280M,35G
-250G:768M,250G-:1G intel_idle.max_cstate=0 eagerfpu=on spectre_v2=off nopti 3 q
uiet
initrd /initrd-x86_64

title HW Diagnostics
root (hd0,0)
kernel /hwdiag/vmlinuz-x86_64 ro vmalloc=256M root=/dev/mapper/vg_splat
-hwdiag panic=15 console=CURRENT 1 rmatool
initrd /hwdiag/initrd-x86_64

0 Kudos
the_rock
Legend
Legend

If I had R81.10 clean install, I would be able to compare that file. Sadly, I dont, only R81.20. I checked /boot dir and there is no grub sub-dir, ONLY grub2 and when I go there, I only see grub.cfg file, no grub.conf

Do you have grub.cfg at all?

Andy

0 Kudos
S_E_
Advisor

@the_rock wrote:

Do you have grub.cfg at all?

hi, no

Regards

0 Kudos
the_rock
Legend
Legend

K, let me think about this for a moment. Im wondering if I was to install R81.10 in the lab, maybe I could give you the grub.conf file, not sure that would solve your issue, but worth a try?

Andy

0 Kudos
the_rock
Legend
Legend

Since I really want to help you here, I will build exact same lab fw with version you have (totally clean, from scratch), slap basic password on it and send you the file once ready.

Please bear with me for a bit, as Im working on some Fortinet stuff, so will do this in parallel.

Andy

0 Kudos
the_rock
Legend
Legend

Ok...I built brand new R81.10, installed same jumbo and I attached grub.conf file. Password is abc123!!! if it asks, not sure if it will, if you decide to try replace the file, But, PLEASE, make sure to do backup and also backup the existing grub file before doing any of this.

Btw @S_E_ , as it would not let me attach the original file, since its conf format, I copied the content and attached it as notepad++ format, but I can email you original one if need be.

Andy

0 Kudos
the_rock
Legend
Legend

Hey @S_E_ 

Im on site today, but wanted to check in to see how goes it? Were you able to sort out the issue?

Andy

S_E_
Advisor

Hi,

Thanks a lot for your help.

I copied your file to my device.

steps:

cd /boot/grub

dos2unix grub.conf.txt

cp grub.conf grub.conf.ORIGINAL

cp grub.conf.txt grub.conf

Rebooted device and tried maintenance mode

Admin password:

abc123!!!

abc123!

abc123

 

Always same message

Admin password: *********
Failed!
Press any key to continue...

 

According the missing menu entries "Reset to factory defaults R77.30, Reset to factory defaults R80.10, your file was readable and it worked.

I was also able to run the box into standard 64 bit mode with your file. Normal boot does work.

It simply does not accept the password when trying to enter maintenance mode.

 

 

So it must be something different.

But again, thanks for your help.

Regards

 

 

 

 

 

 

 

 

 

0 Kudos
the_rock
Legend
Legend

Thats so odd...hm. I just tried it again and worked fine with abc123!!!. As per attached, I simply chose maintenance mode 64 bit mode.

Andy

0 Kudos
the_rock
Legend
Legend

I also attempted something else, but sadly nothing : - (. What I did was backup the file (grub.conf) and then edit original grub file, remove password encrypted line, saved, rebooted into maintenance mode, but then it does not even let me click an option to go into maintenance. Once I put all the way it was, lets me log in with abc123!!! password

Sorry mate, Im totally out of ideas 😞

Andy

0 Kudos
S_E_
Advisor

Don't worry. Thanks for your help.

Regards

0 Kudos
the_rock
Legend
Legend

Not worries, just feel bad about it, cause I have a feeling its something so stupid or small we are missing...

Andy

0 Kudos
JanV
Explorer

Hi All,

I experience the same issue today where admin/expert password failed in maintenance mode. Unbelievable, I've already opened TAC case, let's see what they will find out. I will keep you posted. 

0 Kudos
JanV
Explorer

Hi guys, I experienced the same issue today, opened a TAC case where I was advised to remove "lock" attribute from grub.conf file. See below:

1. login to expert
2. vi /boot/grub/grub.conf
3. find [title Gaia maintenance mode x64] or similar title with maintenance mode. 
b. remove 'lock' item under the [title ~ maintenance mode]
c. save file and exit.
d. reboot Gaia and select [Gaia maintenance mode ~], it will not require password any more. 
e. optional, when finished all job in maintenace mode, restore [lock] option under [title maintenance ~] in file /boot/grub/grub.conf.

 

S_E_
Advisor

hi

Thanks for sharing. This did the trick!!

Best Regards

 

# and prompt leads me to the next issue. Unable to reduce/modify log partition and to increase current partition. Original idea was to have more than 2 snapshots at a time.

LVM overview
============
Size(GB) Used(GB) Configurable Description
hwdiag 1 1 no Snapshot volume
lv_R8110HF110_2      53   53    no Snapshot volume
lv_R8110HF110_3      55   55    no Snapshot volume
lv_current                   50   48     yes Check Point OS and products
lv_fcd_GAIA                  7     7     no Factory defaults volume
lv_fcd_R77.30              7     7      no Factory defaults volume
lv_log                      1600   90      yes Logs volume
upgrade reserved     55   N/A    no Reserved space for version upgrade
swap                           33   N/A    no Swap memory volume
unallocated space      0   N/A    no Unused space
------- ----
total 1862 N/A no Total size

There is not enough available space in the system.
press ENTER to continue.

 

 

 

0 Kudos
Bob_Zimmerman
Authority
Authority

If this system has been upgraded in place since R77.30 (and the presence of lv_fcd_R77.30 indicates it has been), the filesystem is likely ext3. Delete your two snapshots, and you may be able to shrink lv_log. I would try to make it 100 GB just to free up the 1.6 TB, then I would expand it to be maybe 500 GB max. It's also worth deleting some of the data in lv_log so you don't need quite so much buffer space to resize it.

Separately, your lv_current is abnormally large, and a lot of space is consumed. Is this an MDS?

S_E_
Advisor

@Bob_Zimmerman wrote:

If this system has been upgraded in place since R77.30 (and the presence of lv_fcd_R77.30 indicates it has been), the filesystem is likely ext3.


correct : ext3


@Bob_Zimmerman wrote:

 Delete your two snapshots, and you may be able to shrink lv_log.

Does not allow me to shrink, only expand..

LVM overview
============
Size(GB) Used(GB) Configurable Description
hwdiag 1 1 no Snapshot volume
lv_current 75 48 yes Check Point OS and products
lv_fcd_GAIA 7 7 no Factory defaults volume
lv_fcd_R77.30 7 7 no Factory defaults volume
lv_log 1600 133 yes Logs volume
upgrade reserved 83 N/A no Reserved space for version upgrade
swap 33 N/A no Swap memory volume
unallocated space 56 N/A no Unused space
------- ----
total 1862 N/A no Total size

Resizing lv_log Logical Volume
==============================
lv_log size can be between 1601G to 1656G.
Enter the new size(GB) or leave blank to cancel:

 

 


@Bob_Zimmerman wrote:

Separately, your lv_current is abnormally large, and a lot of space is consumed. Is this an MDS?


No, just a SmartCenter with a very small policy. But basically a test system where we test API calls (see thread with API ) , which then might be used for MDS. MDS has above 100 GB lv_current

 

Thanks!

Regards

 

0 Kudos
Bob_Zimmerman
Authority
Authority

48 GB used in lv_current is extremely high. None of my production SmartCenters is above 20 GB used. You should look into what is consuming all that space. Snapshots take up a bit more space than is used in lv_current, so reducing how much of lv_current you use will make your snapshots smaller.

0 Kudos
the_rock
Legend
Legend

I second what @Bob_Zimmerman said. In my opinion, 48GB used in lv_current is indeed high.

Andy

0 Kudos
the_rock
Legend
Legend

Thanks for sharing that tip @JanV 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Wed 01 May 2024 @ 02:00 PM (EDT)

    South US: HTTPS Inspection Best Practices

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Wed 01 May 2024 @ 02:00 PM (EDT)

    South US: HTTPS Inspection Best Practices

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events