Master Boot Record question
 

Me bought a Dell Inspiron, the HDD was 320,

Me tried to install Slackware. Me first deleted every partition using GParted, created a Linux partition and then a swap partition, apparently there was nothing at all in the HDD, and then I installed Slackware 13.1 smoothly,

and next thing that happened was when I turned on my laptop on for the first time, it gave me a dual-boot. Windows or Linux? and when I logged onto the Windows, out of curiousity, it told me it does not have any file.

I deleted all the partitions again using GParted. and then I turned on. It still gave me the dual-boot screen.

It feels as though the MBR did not get deleted when I deleted all the partitions in the HDD.

What's happening?

thanks, Linux experts @ LQ~!

The MBR has nothing to do with the partitions on the drive. Changing the partitions or reformatting the partitions will not have any effect on the bootloader in the MBR.

To change or remove the bootloader, you need to actually install a new one by reinstalling Linux or Windows. If you are using Slackware, the installer will give you the option to install LILO to the MBR, which will remove the dual boot option (assuming you configure LILO properly).

Try editing /etc/lilo.conf as root and deleting the windows section and then running lilo again. lilo probably just thought there was something there when there wasn't.

Based on your reported results (not on any knowledge of Slackware) I conclude that the Slackware install software saw Windows when you started the installer, then didn't understand that you deleted Windows, so it tried to set up dual boot.

Slackware correctly connected the MBR to new boot code, then incorrectly set the config file for that new boot code to offer a choice for a Windows install that is no longer present.

I don't understand that part.

The MBR and the first four entries of the partition table are stored together in the first block of the disk. But code modifying the MBR is careful not to modify the partition table, while code modifying the partition table is careful not to modify the MBR code.

Microsoft standard MBR code uses one of the first four partition table entries to find the next stage of the bootstrap sequence. So if you modify the partition table, that modifies the behavior of the MBR even without modifying the code of the MBR.

Various Linux MBR code versions have various ways to get to the next stage of the bootstrap sequence, but they do not use the first four entries of the partition table for that. So zapping the partition table would not stop Linux MBR code from finding the next stage.

However, I would expect that zapping the partition table should stop some later stage of the boot up sequence from finding the config file from which to display the menu. So I don't understand your results.

But as long as it can find the config file, it can display the menu. The fact that the OS's pointed to by that menu no longer exist doesn't affect the display of the menu.

hkothari's advice is the ticket.

An entry in the boot menu is not a proof of an operating system exists. Lilo always checks it so doing a "lilo -b /dev/sda" will show the booting choice is now an error.

For Grub one can creates a 100+ booting entries "before" installing any of them!