Prev: aoe - with freenas, openfiler
Next: ATI Radeon HD 4550 & HDMI : only stereo (with radeonhd) !!!
From: Carlos Davila on 11 Mar 2010 08:00 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 11 Mar 2010 08:50 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 11 Mar 2010 09:10 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 11 Mar 2010 10:00 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 11 Mar 2010 11:10 -----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
|
Next
|
Last
Pages: 1 2 3 4 Prev: aoe - with freenas, openfiler Next: ATI Radeon HD 4550 & HDMI : only stereo (with radeonhd) !!! |