From: Carlos Davila on
I deleted the following files from /:

initrd.img initrd.img.old vmlinuz vmlinuz.old

and I deleted all files in /boot:

config-2.6.26-2-686 initrd.img-2.6.26-2-686 System.map-2.6.26-2-amd64
config-2.6.26-2-amd64 initrd.img-2.6.26-2-amd64 vmlinuz-2.6.26-2-686
grub System.map-2.6.26-2-686 vmlinuz-2.6.26-2-amd64

Yet linux still boots. I am using Lenny and grub. Where is the kernel
actually stored then?

cd


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/ddd4daee1003110441p773f58bfwf6254d3da9488f4(a)mail.gmail.com
From: thib on
Carlos Davila wrote:
> Yet linux still boots. I am using Lenny and grub. Where is the kernel
> actually stored then?

Ha.

What I can think of:
* You were using block-lists to reference the second stage file of grub1
from the first stage in the boot sector, and you didn't store filesystem
drivers (stage1_5 files) in /boot/grub. I don't even know if that's
possible, but if it's smart enough, it may then have referenced the kernel
and initrd files with block-lists too. This way, assuming you didn't wiped
the volume, the files are still there, just unlinked. (That's a very long
shot.)
* If grub is really smart, it may store block-lists automatically as a
fallback for this very case when the filesystem won't provide the file (I'm
not sure I'd really want it to do that if it does).
* You messed up at some point by failing to mount the /boot filesystem,
assuming it's on a separate volume. An upgrade may have repopulated the
/boot directory on the main filesystem (mounted on /). Now you have two
copies of the directory, depending on if you re-updated grub stage1 to load
the second stage on the separate filesystem or not, you may have deleted the
unused copy of the files. (Still, quite a long shot.)

-thib


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4B98F404.5080707(a)stammed.net
From: Ron Johnson on
On 2010-03-11 06:41, Carlos Davila wrote:
> I deleted the following files from /:
>
> initrd.img initrd.img.old vmlinuz vmlinuz.old
>
> and I deleted all files in /boot:
>
> config-2.6.26-2-686 initrd.img-2.6.26-2-686 System.map-2.6.26-2-amd64
> config-2.6.26-2-amd64 initrd.img-2.6.26-2-amd64 vmlinuz-2.6.26-2-686
> grub System.map-2.6.26-2-686 vmlinuz-2.6.26-2-amd64
>
> Yet linux still boots. I am using Lenny and grub. Where is the kernel
> actually stored then?
>

I think I've seen the installer put them in /.

Anyway, it would be *much* easier to diagnose the problem if we had
listings of the *complete* contents of /boot, / and your grub
config file.

Toss them onto some web server and send us the links.

--
Ron Johnson, Jr.
Jefferson LA USA

"If God had wanted man to play soccer, he wouldn't have given
us arms." Mike Ditka


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4B98F95F.7040009(a)cox.net
From: Robert Brockway on
On Thu, 11 Mar 2010, Carlos Davila wrote:

> Yet linux still boots. I am using Lenny and grub. Where is the kernel
> actually stored then?

Hi Carlos. This is actually the expected behaviour with lilo. I've seen
it myself many times with lilo.

This is because lilo maps the blocks of the kernel directly rather than
passing through the filesystem.

As thib notes, Grub actually has a similar capability so it looks like
you're using it.

In any case the best way to get rid of a bootloader is to map in another
bootloader.

MS-Windows used to have an undocumented switch "fdisk /mbr" which would
remap the MBR and erase any copy of lilo or grub present. I don't know if
they still have that option.

You can use dd to erase the MBR too. Commands to do this can be found
with a little RTFM. If you do device to erase the MBR using dd then make
sure you back up all important data first.

My preference has always been to get rid of one bootloader by replacing it
with another.

Cheers,

Rob


--
Email: robert(a)timetraveller.org
IRC: Solver
Web: http://www.practicalsysadmin.com
Open Source: The revolution that silently changed the world


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/alpine.DEB.1.10.1003110927210.11921(a)castor.opentrend.net
From: Clive McBarton on
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carlos Davila wrote:
> I deleted the following files from /:
>
> initrd.img initrd.img.old vmlinuz vmlinuz.old
>
> and I deleted all files in /boot:
>
> config-2.6.26-2-686 initrd.img-2.6.26-2-686 System.map-2.6.26-2-amd64
> config-2.6.26-2-amd64 initrd.img-2.6.26-2-amd64 vmlinuz-2.6.26-2-686
> grub System.map-2.6.26-2-686 vmlinuz-2.6.26-2-amd64
>
> Yet linux still boots. I am using Lenny and grub.

Interesting. You seem to have figured out some secret "block mode" of
grub, which I have been looking for but didn't find. Can you post your
boot sector here? Typing the following (as root) will print the boot
sector in ASCII, which you can post here.

dd if=/dev/sda bs=512 count=1|uuencode bootsector

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuZFFIACgkQ+VSRxYk4409cEACgoqH85Fzht3YmUAZdb0JW/X78
PHAAoNDpwjnH6NKi/EXRDhlJMOd48Dhu
=1irS
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4B991452.2050902(a)web.de