Re: Loadlin and Squeeze kernel 2.6.32
On Tue, 31 Jul 2012 17:34:01 +0100, Brian wrote: > On Tue 31 Jul 2012 at 10:56:09 -0400, Tom H wrote: > >> On Mon, Jul 30, 2012 at 11:35 AM, Camaleón wrote: >> > >> > Yes, I read about it. But this warning has to be new or at least I >> > don't recall GRUB legacy showing this notice when you were going to >> > install GRUB into a partition instead the MBR :-? >> >> "I'm demonizing them" should've been "I'm NOT demonizing them"... >> >> I have no idea why the grub developers have decided to label the >> installation to a PBR a bad thing given that it works just as well (or >> as badly, depending on your point of view) with grub2 as grub1. > > Section 3.4 of > >http://www.gnu.org/software/grub/manual/grub.html > > discusses the issues and offers a recommendation. Which completely differs from their last doc: http://www.gnu.org/software/grub/manual/legacy/grub.html#Installing-GRUB-natively > Also, message #16 at > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542424 > > touches on the reason why there is now a more visible warning. He! I have to solidarize with the bug reporter >:-) > > With grub-legacy it's exactly the same. We just decided to make > > it more clear in grub2 that blocklists aren't that great. So finally it discloses as a simple "recommendation". Fine then. The warning also states that using blocklists is the only way in some disk layouts. > The proposal to introduce the warning may be seen here: > >http://lists.gnu.org/archive/html/grub-devel/2009-05/msg4.html *** This patch improves error messages in grub-setup, and adds a few warnings when requested to install in odd layouts. *** I wonder what they consider an "odd layout". Four primary partitions and the bootloader installed at the first boot sector of the second partition, for instance? I hope no :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jv93od$gv6$1...@dough.gmane.org
Re: Loadlin and Squeeze kernel 2.6.32
On Tue 31 Jul 2012 at 10:56:09 -0400, Tom H wrote: > On Mon, Jul 30, 2012 at 11:35 AM, Camaleón wrote: > > > > Yes, I read about it. But this warning has to be new or at least I don't > > recall GRUB legacy showing this notice when you were going to install > > GRUB into a partition instead the MBR :-? > > "I'm demonizing them" should've been "I'm NOT demonizing them"... > > I have no idea why the grub developers have decided to label the > installation to a PBR a bad thing given that it works just as well (or > as badly, depending on your point of view) with grub2 as grub1. Section 3.4 of http://www.gnu.org/software/grub/manual/grub.html discusses the issues and offers a recommendation. Also, message #16 at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542424 touches on the reason why there is now a more visible warning. > With grub-legacy it's exactly the same. > We just decided to make it more clear in grub2 that > blocklists aren't that great. The proposal to introduce the warning may be seen here: http://lists.gnu.org/archive/html/grub-devel/2009-05/msg4.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120731163401.GZ6660@desktop
Re: Loadlin and Squeeze kernel 2.6.32
On Mon, Jul 30, 2012 at 11:35 AM, Camaleón wrote: > On Sun, 29 Jul 2012 16:03:12 -0400, Tom H wrote: > >> On Sun, Jul 29, 2012 at 10:29 AM, Camaleón wrote: >>> On Sun, 29 Jul 2012 06:50:44 -0400, Tom H wrote: On Mon, Jul 16, 2012 at 10:41 AM, Camaleón wrote: >> >> > I'm not sure to had get it (sorry, I must be a bit dense...). Can you > provide a user case for someone using block lists and another case > when they're not in use? I've explained twice (IIRC; I'm replying quite late to this thread because I've been busy...) and I'm not sure that I'm going to do a better job a third time but I'll try. >>> >>> Yes, sorry, but what you call "block lists" is what I've been using >>> since many years with no problem. That's why I find strange this is >>> being "demonized" :-? >> >> I'm demonizing them but the grub developers certainly do given the >> message that you get when you install grub to a PBR/VBR. > > Yes, I read about it. But this warning has to be new or at least I don't > recall GRUB legacy showing this notice when you were going to install > GRUB into a partition instead the MBR :-? "I'm demonizing them" should've been "I'm NOT demonizing them"... I have no idea why the grub developers have decided to label the installation to a PBR a bad thing given that it works just as well (or as badly, depending on your point of view) with grub2 as grub1. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=swqokd9o-xv15can0x0wx4cmlc1+y-xvxhmgyhc5id...@mail.gmail.com
Re: Loadlin and Squeeze kernel 2.6.32
On Sun, 29 Jul 2012 16:03:12 -0400, Tom H wrote: > On Sun, Jul 29, 2012 at 10:29 AM, Camaleón wrote: >> On Sun, 29 Jul 2012 06:50:44 -0400, Tom H wrote: >>> On Mon, Jul 16, 2012 at 10:41 AM, Camaleón wrote: > > I'm not sure to had get it (sorry, I must be a bit dense...). Can you provide a user case for someone using block lists and another case when they're not in use? >>> >>> I've explained twice (IIRC; I'm replying quite late to this thread >>> because I've been busy...) and I'm not sure that I'm going to do a >>> better job a third time but I'll try. >> >> Yes, sorry, but what you call "block lists" is what I've been using >> since many years with no problem. That's why I find strange this is >> being "demonized" :-? > > I'm demonizing them but the grub developers certainly do given the > message that you get when you install grub to a PBR/VBR. (...) Yes, I read about it. But this warning has to be new or at least I don't recall GRUB legacy showing this notice when you were going to install GRUB into a partition instead the MBR :-? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jv69jt$ltk$1...@dough.gmane.org
Re: Loadlin and Squeeze kernel 2.6.32
On Sun, Jul 29, 2012 at 10:29 AM, Camaleón wrote: > On Sun, 29 Jul 2012 06:50:44 -0400, Tom H wrote: >> On Mon, Jul 16, 2012 at 10:41 AM, Camaleón wrote: >>> I'm not sure to had get it (sorry, I must be a bit dense...). Can you >>> provide a user case for someone using block lists and another case when >>> they're not in use? >> >> I've explained twice (IIRC; I'm replying quite late to this thread >> because I've been busy...) and I'm not sure that I'm going to do a >> better job a third time but I'll try. > > Yes, sorry, but what you call "block lists" is what I've been using since > many years with no problem. That's why I find strange this is being > "demonized" :-? I'm demonizing them but the grub developers certainly do given the message that you get when you install grub to a PBR/VBR. >> The block lists are used when grub's installed in a PBR because there's >> no space for a stage 1.5/core.img (which can read some filesystems) so >> the next step in the boot process has to be encoded and found using the >> blocks that it occupies on the disk. > > Then I have to conclude that block lists are only used when the booloader > is installed in the first sector of a disk partition, right? Yes, AFAIK; although there might be way to install grub to an MBR and use block lists. When multi-booting Linux and Windows, installing grub in the MBR *can* be hazardous to your health and that of your box... >>> >>> Yes, the problem arises when windows is being reinstalled afterwards, >>> users will then need to reinstall GRUB all over again. >> >> More than that. Some Windows licensing and anti-virus/malware software >> installs stuff into the post-MBR gap so grub, on an msdos-labeled disk >> has to fight for space there... > > Yet another reason for leaving untouched the MBR when using those tools. Very true, but I think that the grub developers have found a way around that. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=swotjemtvscfbr6cz8ccza4j97cmf7q1mmqmd5bn4h...@mail.gmail.com
Re: Loadlin and Squeeze kernel 2.6.32
On Sun, 29 Jul 2012 06:50:44 -0400, Tom H wrote: > On Mon, Jul 16, 2012 at 10:41 AM, Camaleón wrote: >> I'm not sure to had get it (sorry, I must be a bit dense...). Can you >> provide a user case for someone using block lists and another case when >> they're not in use? > > I've explained twice (IIRC; I'm replying quite late to this thread > because I've been busy...) and I'm not sure that I'm going to do a > better job a third time but I'll try. Yes, sorry, but what you call "block lists" is what I've been using since many years with no problem. That's why I find strange this is being "demonized" :-? > The block lists are used when grub's installed in a PBR because there's > no space for a stage 1.5/core.img (which can read some filesystems) so > the next step in the boot process has to be encoded and found using the > blocks that it occupies on the disk. Then I have to conclude that block lists are only used when the booloader is installed in the first sector of a disk partition, right? (...) >>> When multi-booting Linux and Windows, installing grub in the MBR *can* >>> be hazardous to your health and that of your box... >> >> Yes, the problem arises when windows is being reinstalled afterwards, >> users will then need to reinstall GRUB all over again. > > More than that. Some Windows licensing and anti-virus/malware software > installs stuff into the post-MBR gap so grub, on an msdos-labeled disk > has to fight for space there... Yet another reason for leaving untouched the MBR when using those tools. (...) >>> 2) OpenSUSE does this because it doesn't believe in installing grub in >>> the MBR (but its installer allows you to do so). >> >> That can be indeed the reason although their installer defaults change >> over the time, I can't say what's the current proposed setup, if >> installing GRUB into the MBR or dropping the bootloader into a >> partition. Or maybe they just adjust this value "on the fly" based on >> the user's disk layout, I can't recall... what I remeber from the >> openSUSE installer is that: >> >> 1/ It was very powerful and fully customizable (from a user's point of >> view). >> >> 1/ It still provided GRUB Legacy (openSUSE delayed the migration to >> GRUB2 precisely because of this, the integration between YaST and GRUB2 >> was not an easy task). > > I don't see why providing grub1 is a plus. It's not seen as a plus but it required time and resources to migrate to GRUB2 because of the YasT tool which is in the end what manages most aspects of the openSUSE core system. I can't say for sure but I can put my hand in the fire that delaying the integration of GRUB2 was mainly based on technicallities and because of their userbase, to avoid them from many problems and unwanted situations. > This autumn'll be the 3-year anniversary of Ubuntu defaulting to grub2. > It was a premature release except for the use of 9.10 as a grub2 "have > fun, hit some bugs, and file bug reports" step for 10.04 LTS. The v1.98 > that ships in Squeeze and 10.04 isn't as good or as featureful as the > latest grub2 but it's good. Debian derived distributions lead the migration to GRUB2, which is fine, but for the rest of the distributions with non-rolling release cycles which also have a reduced number of users (in comparison to Debian-based ones) the migration step had to be done with lot of careful. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jv3hcg$vb5$8...@dough.gmane.org
Re: Loadlin and Squeeze kernel 2.6.32
On Mon, Jul 16, 2012 at 10:41 AM, Camaleón wrote: > On Sun, 15 Jul 2012 12:14:10 -0400, Tom H wrote: >> On Sun, Jul 15, 2012 at 10:12 AM, Camaleón wrote: >>> Which, generally speaking, it translates into...? I mean, what are >>> those "block lists" and how are they effectively affecting the boot >>> process from a user's point of view? >> >> Let's assume that grub1/grub2 have to load "/boot/grub/camaleon" in >> order to boot. >> >> If they're using block lists, they'll locate that file as starting on >> xxx block of yyy partition. >> >> If they're using an intermediate stage (grub1's stage 1.5 or grub2's >> core.img), they'll locate that file by name. >> >> Block lists are supposed to be less reliable/more fragile/(fill in with >> the negative flavor that suits you). > > I'm not sure to had get it (sorry, I must be a bit dense...). Can you > provide a user case for someone using block lists and another case when > they're not in use? I've explained twice (IIRC; I'm replying quite late to this thread because I've been busy...) and I'm not sure that I'm going to do a better job a third time but I'll try. The block lists are used when grub's installed in a PBR because there's no space for a stage 1.5/core.img (which can read some filesystems) so the next step in the boot process has to be encoded and found using the blocks that it occupies on the disk. >>> On systems with multiple operating systems in the same hard disk I've >>> always found a more dangerous approach to install GRUB (or any other >>> bootloader) in the MBR that inside a partition because you completely >>> relay on the bootloder capabilities to boot all of the installed >>> systems and also the MBR could be always overwritten when you install a >>> Windows system. >> >> When multi-booting Linux distributions, there's no problem installing >> grub in the MBR. I have a netbook on which quantal, rawhide, and sid are >> installed and grub's uninstalled in rawhide and sid and installed in the >> MBR via quantal. > > Booting multiple linux or *nix flavours can be also tricky when using > GRUB legacy with different filesystems (that is, GRUB legacy cannot > directly boot from ext4 unless it has been patched, IIRC). > >> When multi-booting Linux and Windows, installing grub in the MBR *can* >> be hazardous to your health and that of your box... > > Yes, the problem arises when windows is being reinstalled afterwards, > users will then need to reinstall GRUB all over again. More than that. Some Windows licensing and anti-virus/malware software installs stuff into the post-MBR gap so grub, on an msdos-labeled disk has to fight for space there... >>> Why does openSUSE provide such option while others no and what kind of >>> changes generates? As I said, I don't know, maybe option a) writes >>> specific GRUB code into the MBR while option b) uses generic bootstrap >>> data. Differences between the two? That a) does not need the bootable >>> flag to be present while b) does? Who knows :-? >> >> No worries. >> >> I've done some googling... >> >> 1) The generic boot code's the DOS MBR code that >> fdisk/fixmbr/bootrec/bootsect writes to the MBR with the right >> option(s). The DOS MBR code's less sophisticated that grub's; it simply >> loads the partition marked active. > > Ah, thanks for confirming. You're welcome. >> 2) OpenSUSE does this because it doesn't believe in installing grub in >> the MBR (but its installer allows you to do so). > > That can be indeed the reason although their installer defaults change > over the time, I can't say what's the current proposed setup, if > installing GRUB into the MBR or dropping the bootloader into a partition. > Or maybe they just adjust this value "on the fly" based on the user's > disk layout, I can't recall... what I remeber from the openSUSE installer > is that: > > 1/ It was very powerful and fully customizable (from a user's point of > view). > > 1/ It still provided GRUB Legacy (openSUSE delayed the migration to GRUB2 > precisely because of this, the integration between YaST and GRUB2 was not > an easy task). I don't see why providing grub1 is a plus. This autumn'll be the 3-year anniversary of Ubuntu defaulting to grub2. It was a premature release except for the use of 9.10 as a grub2 "have fun, hit some bugs, and file bug reports" step for 10.04 LTS. The v1.98 that ships in Squeeze and 10.04 isn't as good or as featureful as the latest grub2 but it's good. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=syf5wysfaouyt5fkudy530g-v6gdhaoyoesehbmf2u...@mail.gmail.com
Re: Loadlin and Squeeze kernel 2.6.32
On Sun, Jul 15, 2012 at 11:41 AM, Stephen Powell wrote: > On Sat, 14 Jul 2012 19:11:41 -0400 (EDT), Tom H wrote: >> >> Thanks for the info and the links. You've misunderstood me. I didn't >> say that Linux could boot without a bootloader. I said that I didn't >> understand the purpose of the "Generic Boot Code" since other >> distributions don't use it when installing grub to a PBR. > > I realize that your remarks above are directed to Camaleón, but some > kind of boot code has to be in the Master Boot Record (MBR). Otherwise, > the BIOS cannot boot from the hard disk. If you install GRUB2 (or any > other boot loader for that matter) to a Volume Boot Record, then > some kind of generic boot code, boot code which chain loads whichever > partition is marked active, must be installed in the Master Boot Record. > Either other distributions install such boot code without asking, or > they either assume or verify that such boot code is already there. > > For example, an install of Linux on a hard disk that already has Windows > (and only Windows) installed on it would not need to install "generic > boot code", since it is already there by means of Windows. On the other > hand, if you have a hard disk that has been wiped clean by DBAN, or > something similar, then there is no generic boot code in the MBR. > If you have previously installed a Linux boot loader to the hard disk's > MBR, then you probably need to install generic boot code in the MBR > to wipe out whatever boot loader used to be there if you now want > to install GRUB2 (or any other Linux boot loader) to a VBR. Very true. I should've known better given that I was bitten by this (or bit myself!) when installing Debian or Ubuntu in the past using debootstrap, installed grub to a PBR/VBR, and had to chroot to fix the MBR. Apologies... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=sxdndb+3rpgilzs8tvxmhls-jnyn51lcvpmkpsedva...@mail.gmail.com
Re: Loadlin and Squeeze kernel 2.6.32
On Mon, 16 Jul 2012 17:09:54 +0100, Dom wrote: > On 16/07/12 15:41, Camaleón wrote: >> On Sun, 15 Jul 2012 12:14:10 -0400, Tom H wrote: (...) >>> Block lists are supposed to be less reliable/more fragile/(fill in >>> with the negative flavor that suits you). >> >> I'm not sure to had get it (sorry, I must be a bit dense...). Can you >> provide a user case for someone using block lists and another case when >> they're not in use? >> >> > As I understand it, when GRUB is installed in the MBR it installs a bit > more code in the "spare" space between the MBR and the first partition. > This includes code that recognises various file system formats (read > only), so it can work out where "/boot/vmlinux-xxx" is. > > When installed on a partition boot sector it doesn't have that spare > space, so needs to have the location of the kernel/initrd hard-coded in > to it as a list of physical disk blocks. > > If, for any reason the files moved (say you resize the partition > containing /boot, or backup/delete/restore /boot), then that block list > won't match the actual location of the files *unless* you run > update-grub. > > In practice this won't happen very often, if at all. Thanks for the clarification :-) As I use to install the boot loader either into the MBR (in single OS installs) and inside a partition (on "/" instead a separated "/boot") I never noticed any problem. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ju1km5$5et$1...@dough.gmane.org
Re: Loadlin and Squeeze kernel 2.6.32
On Mon 16 Jul 2012 at 17:09:54 +0100, Dom wrote: > On 16/07/12 15:41, Camaleón wrote: > > > >I'm not sure to had get it (sorry, I must be a bit dense...). Can you > >provide a user case for someone using block lists and another case when > >they're not in use? > > > > As I understand it, when GRUB is installed in the MBR it installs a > bit more code in the "spare" space between the MBR and the first > partition. This includes code that recognises various file system > formats (read only), so it can work out where "/boot/vmlinux-xxx" > is. > > When installed on a partition boot sector it doesn't have that spare > space, so needs to have the location of the kernel/initrd hard-coded > in to it as a list of physical disk blocks. > > If, for any reason the files moved (say you resize the partition > containing /boot, or backup/delete/restore /boot), then that block > list won't match the actual location of the files *unless* you run > update-grub. > > In practice this won't happen very often, if at all. It only has to done once for you to be presented with the delightful GRUB rescue prompt. You might even think the warning about installing GRUB to a partition being unreliable was not so out of place after all. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716175204.GI19079@desktop
Re: Loadlin and Squeeze kernel 2.6.32
On 16/07/12 15:41, Camaleón wrote: On Sun, 15 Jul 2012 12:14:10 -0400, Tom H wrote: On Sun, Jul 15, 2012 at 10:12 AM, Camaleón wrote: Which, generally speaking, it translates into...? I mean, what are those "block lists" and how are they effectively affecting the boot process from a user's point of view? Let's assume that grub1/grub2 have to load "/boot/grub/camaleon" in order to boot. If they're using block lists, they'll locate that file as starting on xxx block of yyy partition. If they're using an intermediate stage (grub1's stage 1.5 or grub2's core.img), they'll locate that file by name. Block lists are supposed to be less reliable/more fragile/(fill in with the negative flavor that suits you). I'm not sure to had get it (sorry, I must be a bit dense...). Can you provide a user case for someone using block lists and another case when they're not in use? As I understand it, when GRUB is installed in the MBR it installs a bit more code in the "spare" space between the MBR and the first partition. This includes code that recognises various file system formats (read only), so it can work out where "/boot/vmlinux-xxx" is. When installed on a partition boot sector it doesn't have that spare space, so needs to have the location of the kernel/initrd hard-coded in to it as a list of physical disk blocks. If, for any reason the files moved (say you resize the partition containing /boot, or backup/delete/restore /boot), then that block list won't match the actual location of the files *unless* you run update-grub. In practice this won't happen very often, if at all. -- Dom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50043cd2.4050...@rpdom.net
Re: Loadlin and Squeeze kernel 2.6.32
On Sun, 15 Jul 2012 12:14:10 -0400, Tom H wrote: > On Sun, Jul 15, 2012 at 10:12 AM, Camaleón wrote: >> Which, generally speaking, it translates into...? I mean, what are >> those "block lists" and how are they effectively affecting the boot >> process from a user's point of view? > > Let's assume that grub1/grub2 have to load "/boot/grub/camaleon" in > order to boot. > > If they're using block lists, they'll locate that file as starting on > xxx block of yyy partition. > > If they're using an intermediate stage (grub1's stage 1.5 or grub2's > core.img), they'll locate that file by name. > > Block lists are supposed to be less reliable/more fragile/(fill in with > the negative flavor that suits you). I'm not sure to had get it (sorry, I must be a bit dense...). Can you provide a user case for someone using block lists and another case when they're not in use? I have installed GRUB in both (MBR and boot sectors) since many years and have not experienced any difference nor problem with this. In fact, this has been the recommended method when windows is already installed. >> On systems with multiple operating systems in the same hard disk I've >> always found a more dangerous approach to install GRUB (or any other >> bootloader) in the MBR that inside a partition because you completely >> relay on the bootloder capabilities to boot all of the installed >> systems and also the MBR could be always overwritten when you install a >> Windows system. > > When multi-booting Linux distributions, there's no problem installing > grub in the MBR. I have a netbook on which quantal, rawhide, and sid are > installed and grub's uninstalled in rawhide and sid and installed in the > MBR via quantal. Booting multiple linux or *nix flavours can be also tricky when using GRUB legacy with different filesystems (that is, GRUB legacy cannot directly boot from ext4 unless it has been patched, IIRC). > When multi-booting Linux and Windows, installing grub in the MBR *can* > be hazardous to your health and that of your box... Yes, the problem arises when windows is being reinstalled afterwards, users will then need to reinstall GRUB all over again. (...) >> Why does openSUSE provide such option while others no and what kind of >> changes generates? As I said, I don't know, maybe option a) writes >> specific GRUB code into the MBR while option b) uses generic bootstrap >> data. Differences between the two? That a) does not need the bootable >> flag to be present while b) does? Who knows :-? > > No worries. > > I've done some googling... > > 1) The generic boot code's the DOS MBR code that > fdisk/fixmbr/bootrec/bootsect writes to the MBR with the right > option(s). The DOS MBR code's less sophisticated that grub's; it simply > loads the partition marked active. Ah, thanks for confirming. > 2) OpenSUSE does this because it doesn't believe in installing grub in > the MBR (but its installer allows you to do so). That can be indeed the reason although their installer defaults change over the time, I can't say what's the current proposed setup, if installing GRUB into the MBR or dropping the bootloader into a partition. Or maybe they just adjust this value "on the fly" based on the user's disk layout, I can't recall... what I remeber from the openSUSE installer is that: 1/ It was very powerful and fully customizable (from a user's point of view). 1/ It still provided GRUB Legacy (openSUSE delayed the migration to GRUB2 precisely because of this, the integration between YaST and GRUB2 was not an easy task). Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ju196m$5et$3...@dough.gmane.org
Re: Loadlin and Squeeze kernel 2.6.32
On Sun, Jul 15, 2012 at 10:12 AM, Camaleón wrote: > On Sat, 14 Jul 2012 19:11:41 -0400, Tom H wrote: >> On Sat, Jul 14, 2012 at 4:14 PM, Camaleón wrote: >>> Reading from GRUB's legacy documentation¹, I see none listed. However, >>> GRUB2 manual² does not even mention the possibility of installing GRUB2 >>> into the first boot sector of a partition, maybe something has changed >>> between the two versions :-? >> >> Nothing's changed except that you have to use the "--force" option to >> install grub2 into a PBR. The drawback, according to grub, is that you >> have to use block lists rather than use an intermediate step (grub1's >> stage 1.5 or grub2's core.img) that understands filesystems. > > Which, generally speaking, it translates into...? I mean, what are those > "block lists" and how are they effectively affecting the boot process > from a user's point of view? Let's assume that grub1/grub2 have to load "/boot/grub/camaleon" in order to boot. If they're using block lists, they'll locate that file as starting on xxx block of yyy partition. If they're using an intermediate stage (grub1's stage 1.5 or grub2's core.img), they'll locate that file by name. Block lists are supposed to be less reliable/more fragile/(fill in with the negative flavor that suits you). > On systems with multiple operating systems in the same hard disk I've > always found a more dangerous approach to install GRUB (or any other > bootloader) in the MBR that inside a partition because you completely > relay on the bootloder capabilities to boot all of the installed systems > and also the MBR could be always overwritten when you install a Windows > system. When multi-booting Linux distributions, there's no problem installing grub in the MBR. I have a netbook on which quantal, rawhide, and sid are installed and grub's uninstalled in rawhide and sid and installed in the MBR via quantal. When multi-booting Linux and Windows, installing grub in the MBR *can* be hazardous to your health and that of your box... Are you sure about the "generic boot code"? >>> >>> Yes :-) >>> >>> *** >>> Write Generic Boot Code to MBR >>> Replaces the current MBR with generic, operating system independent >>> code. *** >>> >>> Why this option? I can't tell and I don't know (because I have not >>> directly tested) if there's any difference between choosing this and >>> installing no bootloader at all. To be sincere, I don't know if by >>> selecting no bootloader you can boot at all, I mean, directly from your >>> hard disk with no other helpers :-? >> >> Thanks for the info and the links. You've misunderstood me. I didn't say >> that Linux could boot without a bootloader. I said that I didn't >> understand the purpose of the "Generic Boot Code" since other >> distributions don't use it when installing grub to a PBR. > > You're right. > > Yes, what I should have say is that the difference between a) installing > GRUB into the first section of a partition or b) installing GRUB into the > first section of a partition *and* writing generic boot code to MBR is > unknown to me. > > Why does openSUSE provide such option while others no and what kind of > changes generates? As I said, I don't know, maybe option a) writes > specific GRUB code into the MBR while option b) uses generic bootstrap > data. Differences between the two? That a) does not need the bootable > flag to be present while b) does? Who knows :-? No worries. I've done some googling... 1) The generic boot code's the DOS MBR code that fdisk/fixmbr/bootrec/bootsect writes to the MBR with the right option(s). The DOS MBR code's less sophisticated that grub's; it simply loads the partition marked active. 2) OpenSUSE does this because it doesn't believe in installing grub in the MBR (but its installer allows you to do so). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SzMsDoJdhn+RX2U9- __eheuu1ssy3uhjsz54esk...@mail.gmail.com
Re: Loadlin and Squeeze kernel 2.6.32
On Sat, 14 Jul 2012 19:11:41 -0400 (EDT), Tom H wrote: > > Thanks for the info and the links. You've misunderstood me. I didn't > say that Linux could boot without a bootloader. I said that I didn't > understand the purpose of the "Generic Boot Code" since other > distributions don't use it when installing grub to a PBR. I realize that your remarks above are directed to Camaleón, but some kind of boot code has to be in the Master Boot Record (MBR). Otherwise, the BIOS cannot boot from the hard disk. If you install GRUB2 (or any other boot loader for that matter) to a Volume Boot Record, then some kind of generic boot code, boot code which chain loads whichever partition is marked active, must be installed in the Master Boot Record. Either other distributions install such boot code without asking, or they either assume or verify that such boot code is already there. For example, an install of Linux on a hard disk that already has Windows (and only Windows) installed on it would not need to install "generic boot code", since it is already there by means of Windows. On the other hand, if you have a hard disk that has been wiped clean by DBAN, or something similar, then there is no generic boot code in the MBR. If you have previously installed a Linux boot loader to the hard disk's MBR, then you probably need to install generic boot code in the MBR to wipe out whatever boot loader used to be there if you now want to install GRUB2 (or any other Linux boot loader) to a VBR. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/587618271.293683.1342366893455.javamail.r...@md01.wow.synacor.com
Re: Loadlin and Squeeze kernel 2.6.32
On Sat, 14 Jul 2012 19:11:41 -0400, Tom H wrote: > On Sat, Jul 14, 2012 at 4:14 PM, Camaleón wrote: (...) >> Reading from GRUB's legacy documentation¹, I see none listed. However, >> GRUB2 manual² does not even mention the possibility of installing GRUB2 >> into the first boot sector of a partition, maybe something has changed >> between the two versions :-? > > Nothing's changed except that you have to use the "--force" option to > install grub2 into a PBR. The drawback, according to grub, is that you > have to use block lists rather than use an intermediate step (grub1's > stage 1.5 or grub2's core.img) that understands filesystems. Which, generally speaking, it translates into...? I mean, what are those "block lists" and how are they effectively affecting the boot process from a user's point of view? On systems with multiple operating systems in the same hard disk I've always found a more dangerous approach to install GRUB (or any other bootloader) in the MBR that inside a partition because you completely relay on the bootloder capabilities to boot all of the installed systems and also the MBR could be always overwritten when you install a Windows system. (...) >>> Are you sure about the "generic boot code"? >> >> Yes :-) (...) >> *** >> Write Generic Boot Code to MBR >> Replaces the current MBR with generic, operating system independent >> code. *** >> >> Why this option? I can't tell and I don't know (because I have not >> directly tested) if there's any difference between choosing this and >> installing no bootloader at all. To be sincere, I don't know if by >> selecting no bootloader you can boot at all, I mean, directly from your >> hard disk with no other helpers :-? (...) > Thanks for the info and the links. You've misunderstood me. I didn't say > that Linux could boot without a bootloader. I said that I didn't > understand the purpose of the "Generic Boot Code" since other > distributions don't use it when installing grub to a PBR. You're right. Yes, what I should have say is that the difference between a) installing GRUB into the first section of a partition or b) installing GRUB into the first section of a partition *and* writing generic boot code to MBR is unknown to me. Why does openSUSE provide such option while others no and what kind of changes generates? As I said, I don't know, maybe option a) writes specific GRUB code into the MBR while option b) uses generic bootstrap data. Differences between the two? That a) does not need the bootable flag to be present while b) does? Who knows :-? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jtuj3k$83b$7...@dough.gmane.org
Re: Loadlin and Squeeze kernel 2.6.32
On Sat, Jul 14, 2012 at 4:14 PM, Camaleón wrote: > On Sat, 14 Jul 2012 15:31:36 -0400, Tom H wrote: >> On Sat, Jul 14, 2012 at 9:26 AM, Camaleón wrote: > AFAIK this calls for block list based installation of GRUB 2 which is > not recommended cause it introduces the same issues than map file in > LILO. >>> I don't know what you mean here. Installing GRUB in the first sector of >>> a partition instead the MBR has been always possible (also documented) >>> and nothing to be avoided "per se". Can you expand this? >> When you install grub1/grub2 to a PBR, you cannot embed stage >> 1.5/core.img in the gap between the first sector and the start of a >> partition as you would do when you install grub1/grub2 to an MBR. The >> stage 1/boot.img then has to use block lists to load stage 2/core.img. > And what are the drawbacks for that? > > Reading from GRUB's legacy documentation¹, I see none listed. However, > GRUB2 manual² does not even mention the possibility of installing GRUB2 > into the first boot sector of a partition, maybe something has changed > between the two versions :-? Nothing's changed except that you have to use the "--force" option to install grub2 into a PBR. The drawback, according to grub, is that you have to use block lists rather than use an intermediate step (grub1's stage 1.5 or grub2's core.img) that understands filesystems. Cameleon: You can choose to install grub2 to a PBR by refusing to install it to the MBR. d-i'll prompt you to provide a device - and it accepts a partition. >>> >>> Yes, I know. >>> >>> But AFAICT, installing nothing in the MBR (e.g., from a low level >>> formatted hard disk) is not the same than having "generic boot code" >>> here. >> >> I've never heard of "generic boot code". I don't see why SUSE uses it; >> it must be unnecessary since none of the other distributions that I've >> used use it. >> >> Are you sure about the "generic boot code"? > > Yes :-) > > I've been installing several (open)SUSEs since many years and this option > has been always there. Let me search to grab some docs... okay, here it > is³ the official paper. The option comes from the installer, when you > first select to install GRUB you can then cherry pick some advanced > options like the usuals (set bootable flag, etc...) and this one: > > *** > Write Generic Boot Code to MBR > Replaces the current MBR with generic, operating system independent code. > *** > > Why this option? I can't tell and I don't know (because I have not directly > tested) if there's any difference between choosing this and installing no > bootloader at all. To be sincere, I don't know if by selecting no bootloader > you can boot at all, I mean, directly from your hard disk with no other > helpers > :-? > > ¹http://www.gnu.org/software/grub/manual/legacy/grub.html#Installing-GRUB-natively > ²http://www.gnu.org/software/grub/manual/grub.html#Installing-GRUB-using-grub_002dinstall > ³http://doc.opensuse.org/documentation/html/openSUSE/opensuse-reference/cha.grub.html#sec.boot.yast2.config.advanced Thanks for the info and the links. You've misunderstood me. I didn't say that Linux could boot without a bootloader. I said that I didn't understand the purpose of the "Generic Boot Code" since other distributions don't use it when installing grub to a PBR. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=Sy4R-6j=_fiBrO7tSLMfEN45f6-i01aYawQ7GaBf16n=a...@mail.gmail.com
Re: Loadlin and Squeeze kernel 2.6.32
On Sat, 14 Jul 2012 16:14:47 -0400 (EDT), Camaleón wrote: > > *** > Write Generic Boot Code to MBR > Replaces the current MBR with generic, operating system independent code. > *** > > Why this option? I can't tell and I don't know (because I have not directly > tested) if there's any difference between choosing this and installing no > bootloader at all. To be sincere, I don't know if by selecting no bootloader > you can boot at all, I mean, directly from your hard disk with no other > helpers > :-? Perhaps you (and others) may find my LILO web page helpful in this regard. http://users.wowway.com/~zlinuxman/lilo.htm Although it is LILO-specific and Debian-specific, there is nonetheless some discussion about the boot process in general which may shed some light on this subject. HTH -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/232428642.287040.1342298632191.javamail.r...@md01.wow.synacor.com
Re: Loadlin and Squeeze kernel 2.6.32
On Sat, 14 Jul 2012 15:31:36 -0400, Tom H wrote: > On Sat, Jul 14, 2012 at 9:26 AM, Camaleón wrote: (...) AFAIK this calls for block list based installation of GRUB 2 which is not recommended cause it introduces the same issues than map file in LILO. >> >> I don't know what you mean here. Installing GRUB in the first sector of >> a partition instead the MBR has been always possible (also documented) >> and nothing to be avoided "per se". Can you expand this? > > When you install grub1/grub2 to a PBR, you cannot embed stage > 1.5/core.img in the gap between the first sector and the start of a > partition as you would do when you install grub1/grub2 to an MBR. The > stage 1/boot.img then has to use block lists to load stage 2/core.img. And what are the drawbacks for that? Reading from GRUB's legacy documentation¹, I see none listed. However, GRUB2 manual² does not even mention the possibility of installing GRUB2 into the first boot sector of a partition, maybe something has changed between the two versions :-? >>> Cameleon: You can choose to install grub2 to a PBR by refusing to >>> install it to the MBR. d-i'll prompt you to provide a device - and it >>> accepts a partition. >> >> Yes, I know. >> >> But AFAICT, installing nothing in the MBR (e.g., from a low level >> formatted hard disk) is not the same than having "generic boot code" >> here. > > I've never heard of "generic boot code". I don't see why SUSE uses it; > it must be unnecessary since none of the other distributions that I've > used use it. > > Are you sure about the "generic boot code"? Yes :-) I've been installing several (open)SUSEs since many years and this option has been always there. Let me search to grab some docs... okay, here it is³ the official paper. The option comes from the installer, when you first select to install GRUB you can then cherry pick some advanced options like the usuals (set bootable flag, etc...) and this one: *** Write Generic Boot Code to MBR Replaces the current MBR with generic, operating system independent code. *** Why this option? I can't tell and I don't know (because I have not directly tested) if there's any difference between choosing this and installing no bootloader at all. To be sincere, I don't know if by selecting no bootloader you can boot at all, I mean, directly from your hard disk with no other helpers :-? ¹http://www.gnu.org/software/grub/manual/legacy/grub.html#Installing-GRUB-natively ²http://www.gnu.org/software/grub/manual/grub.html#Installing-GRUB-using-grub_002dinstall ³http://doc.opensuse.org/documentation/html/openSUSE/opensuse-reference/cha.grub.html#sec.boot.yast2.config.advanced Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jtsjvm$36q$2...@dough.gmane.org
Re: Loadlin and Squeeze kernel 2.6.32
On Sat, Jul 14, 2012 at 9:26 AM, Camaleón wrote: > On Sat, 14 Jul 2012 09:06:55 -0400, Tom H wrote: >> On Sat, Jul 14, 2012 at 8:18 AM, Martin Steigerwald >> wrote: Am Samstag, 7. Juli 2012 schrieb Camaleón: Thanks for the explanation. I asked because if what you wanted is keeping things separate (e.g., windows and linuxes boxes) there is another approach to consider (at least this was possible with openSUSE that allowed to install "generic code" into the MBR -I miss this option from Debian installer though-): install each GRUB in its own partition (instead the MBR) and mark with the "bootable" flag the desired partition with GRUB on it. This way you have as many GRUBs as linuxes installed to boot (thus if one fails you can go with the rest) and Windows is happy with this because you don't have to reinstall all over again the bootloader when (re)installing the system. >>> >>> AFAIK this calls for block list based installation of GRUB 2 which is >>> not recommended cause it introduces the same issues than map file in >>> LILO. > > I don't know what you mean here. Installing GRUB in the first sector of a > partition instead the MBR has been always possible (also documented) and > nothing to be avoided "per se". Can you expand this? When you install grub1/grub2 to a PBR, you cannot embed stage 1.5/core.img in the gap between the first sector and the start of a partition as you would do when you install grub1/grub2 to an MBR. The stage 1/boot.img then has to use block lists to load stage 2/core.img. >> Cameleon: You can choose to install grub2 to a PBR by refusing to >> install it to the MBR. d-i'll prompt you to provide a device - and it >> accepts a partition. > > Yes, I know. > > But AFAICT, installing nothing in the MBR (e.g., from a low level > formatted hard disk) is not the same than having "generic boot code" > here. I've never heard of "generic boot code". I don't see why SUSE uses it; it must be unnecessary since none of the other distributions that I've used use it. Are you sure about the "generic boot code"? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SxLNPg5Tx4CJovQNJyvHtWDq9TCgFafbGijM=ireh8...@mail.gmail.com
Re: Loadlin and Squeeze kernel 2.6.32
On Sat, 14 Jul 2012 09:06:55 -0400, Tom H wrote: > On Sat, Jul 14, 2012 at 8:18 AM, Martin Steigerwald > wrote: >>> Am Samstag, 7. Juli 2012 schrieb Camaleón: (...) >>> Thanks for the explanation. I asked because if what you wanted is >>> keeping things separate (e.g., windows and linuxes boxes) there is >>> another approach to consider (at least this was possible with openSUSE >>> that allowed to install "generic code" into the MBR -I miss this >>> option from Debian installer though-): install each GRUB in its own >>> partition (instead the MBR) and mark with the "bootable" flag the >>> desired partition with GRUB on it. This way you have as many GRUBs as >>> linuxes installed to boot (thus if one fails you can go with the rest) >>> and Windows is happy with this because you don't have to reinstall all >>> over again the bootloader when (re)installing the system. >> >> AFAIK this calls for block list based installation of GRUB 2 which is >> not recommended cause it introduces the same issues than map file in >> LILO. I don't know what you mean here. Installing GRUB in the first sector of a partition instead the MBR has been always possible (also documented) and nothing to be avoided "per se". Can you expand this? (...) > Cameleon: You can choose to install grub2 to a PBR by refusing to > install it to the MBR. d-i'll prompt you to provide a device - and it > accepts a partition. Yes, I know. But AFAICT, installing nothing in the MBR (e.g., from a low level formatted hard disk) is not the same than having "generic boot code" here. I don't know if Windows (or any other operating system) will be happy to boot from no man's land. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jtrs24$36q$8...@dough.gmane.org
Re: Loadlin and Squeeze kernel 2.6.32
On Sat, Jul 14, 2012 at 8:18 AM, Martin Steigerwald wrote: >> Am Samstag, 7. Juli 2012 schrieb Camaleón: >>> >>> Because it works for me. I've kept installs of previous versions of >>> Debian on separate partitions for reference as well as the fact that >>> by doing so I'll have a working install while getting a newer version >>> setup. Also when I first started using Linux I had Redhat, Slackware >>> and Debian all installed at the same time and would switch from one >>> to another while still keeping my DOS install working for the >>> important stuff. It wasn't 'til I installed Solaris and a couple of >>> BSD variants that I used a boot loader in the mbr and when that >>> drive died I never felt the need to go back to Lilo or grub. If >>> loadlin were able to launch the kernel installed with Squeeze I >>> still wouldn't be using grub. >> >> Thanks for the explanation. I asked because if what you wanted is >> keeping things separate (e.g., windows and linuxes boxes) there is >> another approach to consider (at least this was possible with openSUSE >> that allowed to install "generic code" into the MBR -I miss this >> option from Debian installer though-): install each GRUB in its own >> partition (instead the MBR) and mark with the "bootable" flag the >> desired partition with GRUB on it. This way you have as many GRUBs as >> linuxes installed to boot (thus if one fails you can go with the rest) >> and Windows is happy with this because you don't have to reinstall all >> over again the bootloader when (re)installing the system. > > AFAIK this calls for block list based installation of GRUB 2 which is not > recommended cause it introduces the same issues than map file in LILO. Martin: Installing grub2 to a PBR (with "grub-install --force /dev/sdXY) and therefore using block lists is theoretically less robust than installing grub2 to an MBR but there are enough people using block lists with grub and lilo that this claim seems to be almost-FUD... Cameleon: You can choose to install grub2 to a PBR by refusing to install it to the MBR. d-i'll prompt you to provide a device - and it accepts a partition. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=SwwB64zkroN47=3m4v+uxre1d-toe-abo5ryijl9ey...@mail.gmail.com
Re: Loadlin and Squeeze kernel 2.6.32
Am Samstag, 7. Juli 2012 schrieb Camaleón: > > Because it works for me. I've kept installs of previous versions of > > Debian on separate partitions for reference as well as the fact that > > by doing so I'll have a working install while getting a newer version > > setup. Also when I first started using Linux I had Redhat, Slackware > > and Debian all installed at the same time and would switch from one > > to another while still keeping my DOS install working for the > > important stuff. It wasn't 'til I installed Solaris and a couple of > > BSD variants that I used a boot loader in the mbr and when that > > drive died I never felt the need to go back to Lilo or grub. If > > loadlin were able to launch the kernel installed with Squeeze I > > still wouldn't be using grub. > > Thanks for the explanation. I asked because if what you wanted is > keeping things separate (e.g., windows and linuxes boxes) there is > another approach to consider (at least this was possible with openSUSE > that allowed to install "generic code" into the MBR -I miss this > option from Debian installer though-): install each GRUB in its own > partition (instead the MBR) and mark with the "bootable" flag the > desired partition with GRUB on it. This way you have as many GRUBs as > linuxes installed to boot (thus if one fails you can go with the rest) > and Windows is happy with this because you don't have to reinstall all > over again the bootloader when (re)installing the system. AFAIK this calls for block list based installation of GRUB 2 which is not recommended cause it introduces the same issues than map file in LILO. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207141418.46871.mar...@lichtvoll.de
Re: Loadlin and Squeeze kernel 2.6.32
On 2012-07-06, Mike McClain wrote: > I've used loadlin.exe for years but with my recent install of > Squeeze loadlin reboots the computer rather than launching Debian. I am able to boot linux from DOS using a boot loader from Gujin where loadlin has failed with big kernels. See http://gujin.sourceforge.net/ Download from http://sourceforge.net/projects/gujin/files/standard/ Regards, Howard E. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/a6cp0gflc...@mid.individual.net
Re: Loadlin and Squeeze kernel 2.6.32
El 2012-07-07 a las 10:01 -0700, Mike McClain escribió: (resending to the list) > Hello, > > I've noted from your posts that you're pretty savvy so I'm sorry > you have no experience in this area but I'm happy to answer your > questions. Thanks for your kind words; experience is a rank and helps a lot. > On Sat, Jul 07, 2012 at 01:33:27PM +, Camale?n wrote: > > On Fri, 06 Jul 2012 16:19:20 -0700, Mike McClain wrote: > > > > > I've used loadlin.exe for years but with my recent install of > > > Squeeze loadlin reboots the computer rather than launching Debian. > > > > I never used loadlin before so I can't be of much help here. But, just > > out of curiosity, may I ask you about the reasons for still using it > > today? :-? > > Because it works for me. I've kept installs of previous versions of > Debian on separate partitions for reference as well as the fact that > by doing so I'll have a working install while getting a newer version > setup. Also when I first started using Linux I had Redhat, Slackware > and Debian all installed at the same time and would switch from one > to another while still keeping my DOS install working for the important > stuff. It wasn't 'til I installed Solaris and a couple of BSD variants > that I used a boot loader in the mbr and when that drive died I never > felt the need to go back to Lilo or grub. If loadlin were able to > launch the kernel installed with Squeeze I still wouldn't be using grub. Thanks for the explanation. I asked because if what you wanted is keeping things separate (e.g., windows and linuxes boxes) there is another approach to consider (at least this was possible with openSUSE that allowed to install "generic code" into the MBR -I miss this option from Debian installer though-): install each GRUB in its own partition (instead the MBR) and mark with the "bootable" flag the desired partition with GRUB on it. This way you have as many GRUBs as linuxes installed to boot (thus if one fails you can go with the rest) and Windows is happy with this because you don't have to reinstall all over again the bootloader when (re)installing the system. Another usual option would be using a small separate partition for the bootloader (as you do with loadlin) but having GRUB (or another multi-system and supported bootloader) in there. The key here IMO is the status of the bootloader that has to deal with different OSes and thus has to be up-to-date and in continous development. > > > The flip side of the issue is that grub2 resets the computer > > > trying to launch kernels that loadlin launches with no problem. > > > > (thinking out loud...) > > > > I'm not about the behaviour you are getting... is that a) you boot from > > loadlin and as soon as it passes the control to GRUB2 is rebooted, b) you > > reach the GRUB2's menu, select the Debian entry and then it reboots, c) > > none of the above, because loadlin is capable to directly boot a linux > > system and thus omitting the bootloader (GRUB2, LILO, etc...) installed > > or d) other? :-) > > loadlin bypasses grub. Is c) then, okay, thanks for the aclaration, I was somehow confused by your comment "the issue is that grub2 resets the computer...". > loadlin.exe is a DOS program so the way I've been using it is to boot into > DOS then run loadlin on a kernel kept in c:\boot with a command like: > c:\boot\loadlin c:\boot\nvmlinuz.d40 root=/dev/hdb8 ro > this boots an Etch install from DOS. It sounds that simple that looks very nice :-) > grub won't boot that same kernel when it's on /dev/[hs]db8 but reboots the > computer. > In order to get into Etch I must boot DOS from grub then boot Etch with > loadlin. > The same is true of a Sarge install. > > update-grub doesn't even find the DOS partition I'm used to booting here sda2. Ugh! Okay, I see the mess now :-( > > > Can anyone point me at info other than the sources (over my head) > > > to explain the problem and/or a solution? > > > > I would try (just for testing purposes) if you can boot the system with > > SuperGrub2Disk, for instance. > > Thanks for your thoughts. > Hope I've answered your questions adequately. Yes, and thanks a bunch for the detailed reply, very much appreciated. I hope you can finally bypass this issue and keep loadlin as your bootloader partner for some more time :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120707175609.ga7...@stt008.linux.site
Re: Loadlin and Squeeze kernel 2.6.32
On Fri, 06 Jul 2012 19:19:20 -0400 (EDT), Mike McClain wrote: > > I've used loadlin.exe for years but with my recent install of > Squeeze loadlin reboots the computer rather than launching Debian. > > The flip side of the issue is that grub2 resets the computer > trying to launch kernels that loadlin launches with no problem. > > Can anyone point me at info other than the sources (over my head) > to explain the problem and/or a solution? If I recall correctly, LOADLIN tries to load both the kernel and the initial RAM file system below the 15M line, and with modern Linux kernels, there just isn't enough room down there. You may be able to extend the life of LOADLIN by creating a stripped-down initrd. For example, create or edit a file called /etc/initramfs-tools/conf.d/driver-policy and specify MODULES=dep in there, then re-build your initial RAM file system with update-initramfs -uk $(uname -r) Do this while the kernel of interest is running. Then shutdown and boot DOS, then try LOADLIN again. But I don't know if LOADLIN is being actively maintained anymore. If I were you, I'd switch to LILO. That is what I use. My LILO web page may be helpful to you in that regard. http://users.wowway.com/~zlinuxman/lilo.htm -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/234756348.144406.1341676936310.javamail.r...@md01.wow.synacor.com
Re: Loadlin and Squeeze kernel 2.6.32
On Fri, 06 Jul 2012 16:19:20 -0700, Mike McClain wrote: > I've used loadlin.exe for years but with my recent install of > Squeeze loadlin reboots the computer rather than launching Debian. I never used loadlin before so I can't be of much help here. But, just out of curiosity, may I ask you about the reasons for still using it today? :-? > The flip side of the issue is that grub2 resets the computer > trying to launch kernels that loadlin launches with no problem. (thinking out loud...) I'm not about the behaviour you are getting... is that a) you boot from loadlin and as soon as it passes the control to GRUB2 is rebooted, b) you reach the GRUB2's menu, select the Debian entry and then it reboots, c) none of the above, because loadlin is capable to directly boot a linux system and thus omitting the bootloader (GRUB2, LILO, etc...) installed or d) other? :-) > Can anyone point me at info other than the sources (over my head) > to explain the problem and/or a solution? I would try (just for testing purposes) if you can boot the system with SuperGrub2Disk, for instance. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jt9dr6$2af$8...@dough.gmane.org
Loadlin and Squeeze kernel 2.6.32
Howdy, I've used loadlin.exe for years but with my recent install of Squeeze loadlin reboots the computer rather than launching Debian. The flip side of the issue is that grub2 resets the computer trying to launch kernels that loadlin launches with no problem. Can anyone point me at info other than the sources (over my head) to explain the problem and/or a solution? Thanks, Mike PS: Linux playground 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux Squeeze is on sdb5 PIII on Intel mobo MM -- Satisfied user of Linux since 1997. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706231920.GB2351@playground
