Bug 29043

Summary: Can't install configured kernel with 'make install' after the second time
Product: Base System Reporter: Roger Allan <rallan>
Component: confAssignee: Peter Pentchev <roam>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Roger Allan 2001-07-17 18:10:00 UTC
I reconfigured the kernel and installed it using "make isntall"
(from usr/src/sys/compile/ROOBAR). I reconfigured the kernel a second
time and got from the make command a:
chflags: /kernel: Operation not permitted
I tried all sorts of commands and variations of chflags, ch*, rm, mv,
etc and with no success.
There appears to be no way to remove a broken kernel from the system.

Fix: 

'chflags noschg /kernel' is not working at all.  Either avoid using the
"make install" or edit the makefile and remove the '-fschg' from the
install commands.  If this is too late, edit the /boot/loader.conf and
add the line: "kernel=<my-new-kernel>".
How-To-Repeat: configure a new kernel and build twice with a 'make install' from
/usr/src/sys/compile/<KERNEL-NAME>.  As install sets the schg flag on
the kernel and is unable to undo it.
Comment 1 Peter Pentchev 2001-07-18 07:48:32 UTC
On Tue, Jul 17, 2001 at 10:00:36AM -0700, Roger Allan wrote:
> 
> >Number:         29043
> >Category:       conf
> >Synopsis:       Can't install configured kernel with 'make install' after the second time
> >Organization:
> >Environment:
> FreeBSD roobar.jmorph.com 4.3-RELEASE FreeBSD 4.3-RELEASE #1: Tu Jul 17 23:26:41 CDT 2001   root@roobar.jmorph.com:/usr/src/sys/compile/ROOBAR	i386
> >Description:
> I reconfigured the kernel and installed it using "make isntall"
> (from usr/src/sys/compile/ROOBAR). I reconfigured the kernel a second
> time and got from the make command a:
> chflags: /kernel: Operation not permitted
> I tried all sorts of commands and variations of chflags, ch*, rm, mv,
> etc and with no success.
> There appears to be no way to remove a broken kernel from the system.
> 
> >How-To-Repeat:
> configure a new kernel and build twice with a 'make install' from
> /usr/src/sys/compile/<KERNEL-NAME>.  As install sets the schg flag on
> the kernel and is unable to undo it.
> >Fix:
> 'chflags noschg /kernel' is not working at all.  Either avoid using the
> "make install" or edit the makefile and remove the '-fschg' from the
> install commands.  If this is too late, edit the /boot/loader.conf and
> add the line: "kernel=<my-new-kernel>".

Are you running in a securelevel 1 or higher?  The init(8) manual page
(which is also brought up when you do 'man securelevel') clearly
documents that at securelevel 1, immutable flags cannot be turned off.

Try dropping to single-user mode, and doing chflags noschg /kernel,
then follow up to this PR (by sending mail to freebsd-gnats-submit@FreeBSD.org
with the same Subject line) with the results: did chflags(1) give
an error message, did ls -lo /kernel after the chflags still show
an schg flag, how did the 'make install' process go..

G'luck,
Peter

-- 
When you are not looking at it, this sentence is in Spanish.
Comment 2 Peter Pentchev freebsd_committer freebsd_triage 2001-07-18 07:58:11 UTC
State Changed
From-To: open->feedback

Trying to determine whether the chflags 'permission denied' error 
did not result from the submitter running it in securelevel >= 1. 


Comment 3 Peter Pentchev freebsd_committer freebsd_triage 2001-07-18 07:58:11 UTC
Responsible Changed
From-To: freebsd-bugs->roam

I'll take care of the feedback.
Comment 4 rallan9 2001-07-18 13:40:44 UTC
Yes, I was at a high level of security.  I brought it down to the lowest
level and
presto!  Please close this bug.

Thanks for the help  It is greatly appreciated!

Roger

----- Original Message -----
From: "Peter Pentchev" <roam@orbitel.bg>
To: "Roger Allan" <rallan@pobox.com>
Cc: <freebsd-gnats-submit@FreeBSD.org>
Sent: Wednesday, July 18, 2001 1:48 AM
Subject: Re: conf/29043: Can't install configured kernel with 'make install'
after the second time


> On Tue, Jul 17, 2001 at 10:00:36AM -0700, Roger Allan wrote:
> >
> > >Number:         29043
> > >Category:       conf
> > >Synopsis:       Can't install configured kernel with 'make install'
after the second time
> > >Organization:
> > >Environment:
> > FreeBSD roobar.jmorph.com 4.3-RELEASE FreeBSD 4.3-RELEASE #1: Tu Jul 17
23:26:41 CDT 2001   root@roobar.jmorph.com:/usr/src/sys/compile/ROOBAR i386
> > >Description:
> > I reconfigured the kernel and installed it using "make isntall"
> > (from usr/src/sys/compile/ROOBAR). I reconfigured the kernel a second
> > time and got from the make command a:
> > chflags: /kernel: Operation not permitted
> > I tried all sorts of commands and variations of chflags, ch*, rm, mv,
> > etc and with no success.
> > There appears to be no way to remove a broken kernel from the system.
> >
> > >How-To-Repeat:
> > configure a new kernel and build twice with a 'make install' from
> > /usr/src/sys/compile/<KERNEL-NAME>.  As install sets the schg flag on
> > the kernel and is unable to undo it.
> > >Fix:
> > 'chflags noschg /kernel' is not working at all.  Either avoid using the
> > "make install" or edit the makefile and remove the '-fschg' from the
> > install commands.  If this is too late, edit the /boot/loader.conf and
> > add the line: "kernel=<my-new-kernel>".
>
> Are you running in a securelevel 1 or higher?  The init(8) manual page
> (which is also brought up when you do 'man securelevel') clearly
> documents that at securelevel 1, immutable flags cannot be turned off.
>
> Try dropping to single-user mode, and doing chflags noschg /kernel,
> then follow up to this PR (by sending mail to
freebsd-gnats-submit@FreeBSD.org
> with the same Subject line) with the results: did chflags(1) give
> an error message, did ls -lo /kernel after the chflags still show
> an schg flag, how did the 'make install' process go..
>
> G'luck,
> Peter
>
> --
> When you are not looking at it, this sentence is in Spanish.
>
Comment 5 Peter Pentchev freebsd_committer freebsd_triage 2001-07-18 14:14:23 UTC
State Changed
From-To: feedback->closed

Pilot error: the system was running at a high securelevel.