subject:"lilo removal in squeeze \(or, \"please test grub2\"\)"

On Tue, Jun 1, 2010 at 5:32 AM, Stan Hoeppner s...@hardwarefreak.com wrote:
 Tom H put forth on 5/31/2010 1:04 AM:

 I have gone through various big changes in OSs, WinNT to Win2k, OS9 to
 OSX (although I was a Sol-Lin admin too so it wasn't as great a shock
 as for Mac-only admins [1. see OT anecdote below]), Sol8 to Sol10 and
 they created more dislocation than a bootloader change. At the risk of
 sounding like a late-night infomercial (!), a smooth transition from
 lilo to grub2 is just a question of being positive (the un-unwanted
 and un-unneeded of above) - and putting in some work (the learning
 curve of above) of course.

 From a seasoned sysadmin perspective, a vendor forced change away from
 something as critical as a bootloader, causes immediate push back.  In LILO's
 current state, and given the way I run kernels, I could likely used LILO 22.8
 for the next 10 years without a problem, without any code changes.  So it
 doesn't matter to me if it's currently maintained or not.

 The reason grub2 is being forced upon us all is the need of the desktop
 users who want a 20MB kitchen sink kernel and initrd that will support any
 piece of hardware on any machine they throw at it.  Many sysadmins don't want
 or need that, and we're being forced to change our bootloader due to the
 perceived needs of others.

 LILO isn't broken and it works well enough for may folks such as myself.  We
 should have the option of keeping it, as an installable package, until _we_
 feel we need to change to something else.  It's as much a philosophical issue
 as it is a practical one. There is no legitimate reason LILO can't be left in
 the distro as an optional package, just as it is now with Lenny.

 It's difficult to be positive when unnecessary change is being forced down
 one's throat.

Don't you think that lilo will be left in the repos but not available
at install time? You could then install lilo post-OS-install or
through pre-seeding.


 Thanks for the tips below.  I'll be hanging onto them until/if they're needed.
 grub2 basics--

You're welcome.


--
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/aanlktilnprnvodjzhoklujnoyji10zvdjsy-igxp7...@mail.gmail.com

Re: lilo removal in squeeze (or, please test grub2)

On Tue, Jun 1, 2010 at 3:44 PM, Stephan Seitz
stse+deb...@fsing.rootsland.net wrote:
 On Mon, May 31, 2010 at 01:29:15AM +0300, Andrei Popescu wrote:

 Having /boot on a separate partition for robustness, security or
 advanced features (encrypted LVM and stuff) is one thing, but having it
 because the default bootloader doesn't support current (ext4) and future
 (btrfs) filesystems seems like a hack to me.

 But I don’t think that everyone will switch to ext4 with the next release,
 even if they install new systems. Does the squeeze installer support ext4 or
 is this the new filesystem if you don’t choose one?

 Besides we are not talking about having grub1 for all eternity. If grub2
 will support all features of grub1, we can replace the bootloader in squeeze
 + 1.

 software (Stephen's case), but we have to face it:
 * LILO is not developed anymore
 * Grub1 is not developed anymore

 Yes, but for now both bootloader are still working. They may not support
 ext4, but they do support things grub2 doesn’t.

 Unless there are people interested in further developing those code
 bases they will be gone sooner or later. And my feeling (as a

 Yes, but in the time for squeeze + 1, grub2 may get all missing features
 from grub1. Then we can at least through away grub1.

I've installed Squeeze a few times (from the bcard and netinst isos);
ext4 is available but there is no default. Maybe the larger isos
default to ext4 like Ubuntu and Fedora.

Anyway, if Debian wanted to have grub1 support ext4, it would simply
have to apply whatever patch Fedora has...

I can't think of a grub1 feature that grub2 doesn't have except the
howmany variable - and it doesn't look like it will be re-introduced.
On grub-devel, the idea was trashed (and, to a certain extent,
misunderstood). And in the Debian bug pages, the answer was we don't
want to deviate from upstream even though the grub1 howmany variable
was a Debian enhancement.


--
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/aanlktin4i3ugecv3c-qly36qiz_ad4rqltkt92c3m...@mail.gmail.com

Re: lilo removal in squeeze (or, please test grub2)

2010-06-02 Thread Stephen Powell

On Wed, 02 Jun 2010 09:06:56 -0400 (EDT), Tom H wrote:
 
 Don't you think that lilo will be left in the repos but not available
 at install time? You could then install lilo post-OS-install or
 through pre-seeding.

Not without an active upstream maintainer.  That's the critical need now.

-- 
  .''`. 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/268887301.224480.1275485450171.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

On Wed, Jun 2, 2010 at 9:30 AM, Stephen Powell zlinux...@wowway.com wrote:
 On Wed, 02 Jun 2010 09:06:56 -0400 (EDT), Tom H wrote:

 Don't you think that lilo will be left in the repos but not available
 at install time? You could then install lilo post-OS-install or
 through pre-seeding.

 Not without an active upstream maintainer. That's the critical need now.

I meant to say the Lenny repos (although I am curious to see whether
it will really disappear from the Squeeze repos once Squeeze is
released).

The difference between Lenny and Squeeze is:

 lilo  (1:22.8-8.1) unstable; urgency=low

   * Non-maintainer upload.
   * Fix pending l10n issues. Debconf translations:
 - Czech (Miroslav Kure).  Closes: #505912
 - Vietnamese (Clytie Siddall).  Closes: #513343
 - Spanish (Francisco Javier Cuadrado).  Closes: #523466
 - Italian (Luca Monducci).  Closes: #544597
 - Basque (Iñaki Larrañaga Murgoitio).  Closes: #545514
 - Finnish (Esko Arajärvi).  Closes: #545511
 - Dutch (Vincent Zweije).  Closes: #546509

 -- Christian Perrier bubu...@debian.org  Mon, 14 Sep 2009 19:54:16 +0200
lilo (1:22.8-8) unstable; urgency=low

   * Fix some more bashisms. (Closes: #535399)
   * debian/lilo.postinst: Add -H flag to only install to active MD arrays.
 (Closes: #507366)

 -- William Pitcock neno...@dereferenced.org  Sat, 01 Aug 2009 15:54:10 -0500


--
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/aanlktimwv73h5sox8inpoobw8te-6x9joqdjt0nul...@mail.gmail.com

Re: lilo removal in squeeze (or, please test grub2)

2010-06-02 Thread Stephen Powell

On Wed, 02 Jun 2010 09:55:58 -0400 (EDT), Tom H wrote:
 On Wed, Jun 2, 2010 at 9:30 AM, Stephen Powell zlinux...@wowway.com wrote:
 On Wed, 02 Jun 2010 09:06:56 -0400 (EDT), Tom H wrote:

 Don't you think that lilo will be left in the repos but not available
 at install time? You could then install lilo post-OS-install or
 through pre-seeding.

 Not without an active upstream maintainer. That's the critical need now.
 
 I meant to say the Lenny repos (although I am curious to see whether
 it will really disappear from the Squeeze repos once Squeeze is
 released).

If they pull it, they will probably pull it *before* squeeze becomes the
current stable release.  Once a release becomes the stable release, it's
almost impossible to pull a package from it.

-- 
  .''`. 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/1507702440.225881.1275487539953.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-06-02 Thread John Hasler

Tom H writes:
 I meant to say the Lenny repos (although I am curious to see whether
 [Lilo] will really disappear from the Squeeze repos once Squeeze is
 released).

If it has an RC bug at the time of the release it will be removed.
-- 
John Hasler


-- 
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/874ohlcy2t@thumper.dhh.gt.org

Re: lilo removal in squeeze (or, please test grub2)

On 30/05/2010 14:04, thib wrote:
 Like any dist upgrade, squeeze will have release notes with upgrade
 instructions and I'm quite confident everything concerning lilo will
 be covered.  There are probably many upgrade test patterns they'll
 have to try, that's true, but I would hope the transition goes
 smoothly for most systems. 
All the smoother with sufficient testing (which is what William was
requesting with the OP)


-- 
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/4c068101.5010...@debian.org

Re: lilo removal in squeeze (or, please test grub2)

On 01/06/2010 10:32, Stan Hoeppner wrote:
 The reason grub2 is being forced upon us all is the need of the desktop
 users who want a 20MB kitchen sink kernel and initrd that will support any
 piece of hardware on any machine they throw at it.  Many sysadmins don't want
 or need that, and we're being forced to change our bootloader due to the
 perceived needs of others.

 LILO isn't broken and it works well enough for may folks such as myself.  We
 should have the option of keeping it, as an installable package, until _we_
 feel we need to change to something else.  It's as much a philosophical issue
 as it is a practical one.  There is no legitimate reason LILO can't be left in
 the distro as an optional package, just as it is now with Lenny.
   
A perfectly legitimate reason is that there is one willing to maintain
it. Lots of hot air on -user, but nobody prepared to do the work. IMHO
the kernel size issue is just the straw that broke the camel's back.


-- 
Jon Dowland


-- 
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/4c0681df.6040...@debian.org

Re: lilo removal in squeeze (or, please test grub2)

On 24/05/2010 23:44, Stan Hoeppner wrote:
 So it would appear boot loaders in general have a lack of interested/committed
 developers?  Both LILO and GRUB.

 sarcasm So instead of just LILO, why didn't the Debian team just throw both
 bootloaders out the window and start over with committed devs? /sarcasm
   
There would indeed appear to be a manpower problem for grub2 and lilo
*within* Debian, but the key issue here is that there is also a manpower
problem for lilo *outside* Debian, too.

-- 
Jon Dowland


-- 
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/4c0682af.9030...@debian.org

Re: lilo removal in squeeze (or, please test grub2)

On 28/05/2010 17:39, Roger Leigh wrote:
 One obvious solution not already mentioned is to back up the bootloader
 *in Linux* as a normal file, so the backup software can then just back
 it up like any other file.  It's a simple enough workaround to the
 deficiencies in your backup software.

 dd if=dev/hda of=/boot/bootsector-backup bs=512 count=nnn

 Stick it in as a daily cron job and you're done.  When it comes to
 restoring, you can just dd it back and you're in business.
   
I don't think this is necessary. It doesn't solve Stephen's problem (a
machine restored from backup is not immediately bootable), and if you
boot the machine via some other method, you can just as easily run
update-grub (or whatever it's called) to re-create the boot.

The solution is to have an external boot system to hand. A set of
suitably configured USB keys would do it. They could even boot into a
special init environment that just ran update-grub so that the macine
was immediately recovered.

Just how often is a total restore-from-backup required, I wonder?

-- 
Jon Dowland

Re: lilo removal in squeeze (or, please test grub2)

On Wed, Jun 2, 2010 at 10:05 AM, Stephen Powell zlinux...@wowway.com wrote:
 On Wed, 02 Jun 2010 09:55:58 -0400 (EDT), Tom H wrote:
 On Wed, Jun 2, 2010 at 9:30 AM, Stephen Powell zlinux...@wowway.com wrote:
 On Wed, 02 Jun 2010 09:06:56 -0400 (EDT), Tom H wrote:

 Don't you think that lilo will be left in the repos but not available
 at install time? You could then install lilo post-OS-install or
 through pre-seeding.

 Not without an active upstream maintainer. That's the critical need now.

 I meant to say the Lenny repos (although I am curious to see whether
 it will really disappear from the Squeeze repos once Squeeze is
 released).

 If they pull it, they will probably pull it *before* squeeze becomes the
 current stable release.  Once a release becomes the stable release, it's
 almost impossible to pull a package from it.

I know. I chose the release as a check-point because I don't know at
what previous milestone such a move would take place.


--
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/aanlktinipihiivoosafdkzoighwxemc_ppdhyztuv...@mail.gmail.com

Re: lilo removal in squeeze (or, please test grub2)

2010-06-02 Thread Stephen Powell

On Tue, 01 Jun 2010 12:14:42 -0400 (EDT), John Hasler wrote:
 Stephen Powell writes:
 Actually, I've been tempted to volunteer to become the upstream
 maintainer for lilo myself.
 
 Please do so.

 However, although the SAPL is written in assembly language, it is
 written in s390 assembly language, which is totally different from x86
 assembly language.  I don't know x86 assembly language at all.
 
 Set up a Web site (I suggest tuxfamily.org for hosting) and ask for
 help.  You'll find that there are people who can and will do the coding
 but who don't want the hassle and responsibility of running the project.

I don't know.  I would at least want to be able to review the work of
my assistants and have some hope of being able to tell if it makes sense.
I appreciate the encouragement, but I'm just not qualified for something
like this yet.  If lilo is worth saving, surely someone who *is* qualified
will step up to the plate.  I sure wish I knew what in the world happened
to John Coffman though.  He was doing a great job.

-- 
  .''`. 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/770226811.246509.1275528114439.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-06-01 Thread Stan Hoeppner

Tom H put forth on 5/31/2010 1:04 AM:
 On Sat, May 29, 2010 at 11:46 PM, Stan Hoeppner s...@hardwarefreak.com 
 wrote:
 Tom H put forth on 5/28/2010 10:55 PM:
 On Fri, May 28, 2010 at 9:50 PM, Stan Hoeppner s...@hardwarefreak.com 
 wrote:
 Roger Leigh put forth on 5/28/2010 11:39 AM:

 For the most part, grub is a vast
 improvement over LILO, and except for the odd corner cases which
 grub doesn't cover,

 In what way is it a vast improvement over LILO? I've never had a problem 
 with
 LILO. It's always just worked, which is what a bootloader should do. So
 how exactly would grub be a better choice for me?

 The reverse argument can be made too. Both grub1 and grub2 just work.
 Unless you are continually installing dual- and triple-boot this or
 that, you are not going to be changing you config continually no
 matter what bootloader you use and you will therefore not be
 interacting with it that much. So, except for Stephen P's case, what's
 the big deal?

 I frequently roll new kernels from kernel.org source using the Debian
 installation method, once every couple of months. I'm very comfortable with
 using LILO for this. I've pretty much zero experience with Grub (any
 version). If something goes wrong converting from LILO to Grub2, I'm screwed.
  And I'll probably have an unwanted and unneeded learning curve while
 continuing my current practice of rolling kernels frequently.

 Please don't debate the merits of customs kernels. I have very valid reasons
 for doing so. Let's focus on why or why not Grub2 will work for my needs, and
 not hose my systems either during the migration from LILO to Grub2, or
 installing custom kernels after the fact.
 
 I have absolutely no problem with custom kernels. (What I don't
 understand is people who jump up and down on various lists when
 someone says that he/she compiles custom kernels!)

The reasons are very unflattering to the folks you point out, so I won't go
into detail and start a fire.

 I haven't used lilo for nine-ten years but I don't see how adding a
 custom kernel to grub rather than lilo should affect your kernel
 compilation. I don't use the Debian tools so after make install, I
 run update-initramfs ... and update-grub, and I'm done. I don't
 see how, if I were using lilo, I would have to follow a different
 procedure, except for setting editing lilo.conf and running lilo after
 update-initramfs. Am I missing something?

The part about that fact that I've never used grub, any of its variants.  It
may not present problems when installing my kernels.  I don't know.  That's
why I brought it up, hoping folks would share their experience.

 As I said in my previous post, I would install Squeeze's grub2 on a
 Lenny box and reboot to check that it is working before the upgrade to
 Squeeze.

Yep.

 I have gone through various big changes in OSs, WinNT to Win2k, OS9 to
 OSX (although I was a Sol-Lin admin too so it wasn't as great a shock
 as for Mac-only admins [1. see OT anecdote below]), Sol8 to Sol10 and
 they created more dislocation than a bootloader change. At the risk of
 sounding like a late-night infomercial (!), a smooth transition from
 lilo to grub2 is just a question of being positive (the un-unwanted
 and un-unneeded of above) - and putting in some work (the learning
 curve of above) of course.

From a seasoned sysadmin perspective, a vendor forced change away from
something as critical as a bootloader, causes immediate push back.  In LILO's
current state, and given the way I run kernels, I could likely used LILO 22.8
for the next 10 years without a problem, without any code changes.  So it
doesn't matter to me if it's currently maintained or not.

The reason grub2 is being forced upon us all is the need of the desktop
users who want a 20MB kitchen sink kernel and initrd that will support any
piece of hardware on any machine they throw at it.  Many sysadmins don't want
or need that, and we're being forced to change our bootloader due to the
perceived needs of others.

LILO isn't broken and it works well enough for may folks such as myself.  We
should have the option of keeping it, as an installable package, until _we_
feel we need to change to something else.  It's as much a philosophical issue
as it is a practical one.  There is no legitimate reason LILO can't be left in
the distro as an optional package, just as it is now with Lenny.

It's difficult to be positive when unnecessary change is being forced down
one's throat.

 grub2 basics--

Thanks for the tips below.  I'll be hanging onto them until/if they're needed.

-- Stan



 Setup
 
 Although grub2 sources a file in /usr/lib/grub when creating its
 config, the files that matter are /etc/default/grub and /etc/grub.d/*.
 You set various variables like the kernel options, the default entry,
 whether to create entries with single appended, ... in
 /etc/default/grub. When you run update-grub (which is a script that
 runs grub-mkconfig -o /boot/grub/grub.cfg), the grub2 menu's
 configuration,

Re: lilo removal in squeeze (or, please test grub2)

2010-06-01 Thread Stan Hoeppner

Stephen Powell put forth on 5/31/2010 8:57 PM:
 On Sun, 30 May 2010 03:48:50 -0400 (EDT), Andrei Popescu wrote:
 On Sat,29.May.10, 22:35:56, Stan Hoeppner wrote:

 My gut instinct is that due to the above reasons and possibly others, the 
 next
 dist upgrade is going to hose all my production servers whilst trying to
 forcibly convert them to Grub2.  Is my instinct correct?

 Worst case you'll have to pin lilo at 1001 and grub-pc at -1 before the 
 upgrade ;)
 
 Does anybody know what happened to John Coffman (the last known upstream
 maintainer for lilo)?  Did he get bored with maintaining lilo?  He was
 doing a great job.  I think he's the one that added lba32 support.
 He seems to have fallen off the face of the earth.  Did he die or what?

That's a good question.  I was just digging around (not very thoroughly) a few
minutes ago and I can't find any recent posts from him via Google.

-- 
Stan



-- 
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/4c04d533.8060...@hardwarefreak.com

Re: lilo removal in squeeze (or, please test grub2)

2010-06-01 Thread thib


Stan Hoeppner wrote:

LILO isn't broken and it works well enough for may folks such as myself.  We
should have the option of keeping it, as an installable package, until _we_
feel we need to change to something else.  It's as much a philosophical issue
as it is a practical one.  There is no legitimate reason LILO can't be left in
the distro as an optional package, just as it is now with Lenny.

It's difficult to be positive when unnecessary change is being forced down
one's throat.


In the worst case, people will maintain unofficial packages in unofficial 
repositories.  In fact, I'm not even sure there's still much to maintain 
with the package..  just keep it around.


It's very true, official support is best, but I wouldn't go as far as saying 
the change is forced.  This is all still open and hackable software, in 
the end, and hack here means pinning lilo and grub-pc, which should be it. 
 It will still be manageable by apt.


-t


--
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/4c051719.7080...@stammed.net

Re: lilo removal in squeeze (or, please test grub2)

2010-06-01 Thread Stephen Powell

On Tue, 01 Jun 2010 05:32:37 -0400 (EDT), Stan Hoeppner wrote:
 From a seasoned sysadmin perspective, a vendor forced change away from
 something as critical as a bootloader, causes immediate push back.  In LILO's
 current state, and given the way I run kernels, I could likely used LILO 22.8
 for the next 10 years without a problem, without any code changes.  So it
 doesn't matter to me if it's currently maintained or not.

Actually, I've been tempted to volunteer to become the upstream maintainer
for lilo myself.  I have worked on boot loaders before, on other platforms.
For example, I have made local modifications to the Stand Alone Program
Loader that ships with IBM's z/VM Operating System.  The SAPL is used as the
boot loader for the CP (Control Program) component of z/VM, as well as other
stand-alone programs such as DDR (DASD Dump / Restore)
and DSF (Device Support Facilities).  I won't go into the details of what
those local modifications are because they are not relevant here.
The point is that I've worked on boot loaders before, and I like working
on low-level stuff.

However, although the SAPL is written in assembly language, it is written
in s390 assembly language, which is totally different from x86 assembly
language.  I don't know x86 assembly language at all.  And I am just
learning C.  So reason prevails over emotion and I don't volunteer.  I
am simply not qualified.  Someday I may be, but not today.
 
 
 The reason grub2 is being forced upon us all is the need of the desktop
 users who want a 20MB kitchen sink kernel and initrd that will support any
 piece of hardware on any machine they throw at it.  Many sysadmins don't want
 or need that, and we're being forced to change our bootloader due to the
 perceived needs of others.

Actually, that is largely a myth.  Lilo's only release-critical bug turned
out not to be a bug at all.  It was this bug that gave rise to the belief
that stock kernels were getting too big for lilo to load.  But the problem
was that a new kernel was installed without lilo being run.  And this is
apparently the result of changes made to the stock kernel maintainer scripts
that cause do_bootloader = yes in /etc/kernel-img.conf to not be honored
anymore, as it once was.  Whether this is a bug or a feature in the kernel
maintainer scripts I am not sure.  But I am sure that this is not a lilo
bug.

To the best of my knowledge, even the largest of today's kitchen sink
kernel and initial RAM disk image combinations can be loaded by lilo with
no trouble at all if the large-memory option is used and the BIOS support
memory addressing above 16M, which is the case for almost all modern BIOS.
(The 16M limit is apparently a hold-over from the days of the 80286 chip.)
And if for some reason the BIOS do not support the large-memory option,
simply using MODULES=dep instead of MODULES=most in your initial RAM
file system is usually sufficient to allow lilo to work, even with these
large kernels.

(As a side note, it seems to me that the equivalent of the large-memory
option should be possible even if the BIOS do not support it by
asking the BIOS to read a block into storage below the 16M line and then
copying the block above the 16M line under program control.  Conceptually
at least, it seems to me that that shouldn't be too hard.  But I don't
know.)

 
 LILO isn't broken and it works well enough for may folks such as myself.  We
 should have the option of keeping it, as an installable package, until _we_
 feel we need to change to something else.  It's as much a philosophical issue
 as it is a practical one.  There is no legitimate reason LILO can't be left in
 the distro as an optional package, just as it is now with Lenny.
 
 It's difficult to be positive when unnecessary change is being forced down
 one's throat.

I agree.  But I also sympathize with the poor package maintainer who is
essentially functioning as both package maintainer and upstream support.
That cannot go on forever.  Someone has to step up to the plate and take
over upstream support.  I'd do it myself if I had the requisite skills.
But as of now, I just don't.

Perhaps one of the reasons that no-one has stepped up to the plate to take
over upstream support is the perception that lilo can't handle today's
large kernels and therefore we should just let it die.  That is simply not
true.  I use stock kernels most of the time.  And I use lilo.  And I've
never had a bit of trouble.  I just have to make sure by the use of hook
scripts that lilo actually gets run when a kernel is installed or updated.
And that's easy enough to do.

-- 
  .''`. 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/112473223.193825.1275402342029.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-06-01 Thread Stephen Powell

On Tue, 01 Jun 2010 10:20:09 -0400 (EDT), thib wrote:
 
 In the worst case, people will maintain unofficial packages in unofficial 
 repositories.  In fact, I'm not even sure there's still much to maintain 
 with the package..  just keep it around.
 
 It's very true, official support is best, but I wouldn't go as far as saying 
 the change is forced.  This is all still open and hackable software, in 
 the end, and hack here means pinning lilo and grub-pc, which should be it. 
 It will still be manageable by apt.

I am still hopeful that lilo will not be dropped from the distribution.
I think it would be a mistake, and I believe lilo has many more years
of useful life than most people think it does (or should have) at this point.
But if they drop it, I'm prepared.  I have already downloaded the source
code, and I will build my own packages if I have to.  For now at least,
I *have* to use lilo for reasons previously discussed.

-- 
  .''`. 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/1600857906.194739.1275403757931.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-06-01 Thread Daniel Barclay


Stan Hoeppner wrote:


The
problem, in and of itself, is booting.  Period.  There is [no] way to test it
but to replace LILO with Grub2 and see if the system boots afterward.  I
cannot do this on production servers, obviously.  Cloning drives to play with
on a lab machine would be a good idea, but I can't take production servers
offline to clone the disks.  


How about temporarily booting from an alternate partition, disk, etc?

For example:
1.  Install a second instance of your current LILO installation on some
other boot device.
  - Then boot from that device to make sure that booting from that
device can boot your system normally.  If not, boot from your normal
boot partition, try to fix that second LILO installation, and
try again.  Once it works, proceed to step 2.


2.  Install Grub2 on the main boot device.
  - Try booting.
  - If doesn't work, reboot from the device with the backup LILO
installation in step one and try to fix the Grub2 installation,
and try again.  Once it works, you're done.

Actually, you'd probably want to install the new loader (Grub2) on
an alternative device first, so your system by default would still
boot using the old boot loader setup.  Then, when you think you have
your Grub2 configuration worked out, create and test the LILO backup
boot device as above, and install Grub2 on your main boot device.  If
it works, you're done;  if it doesn't, you can reboot from the LILO
backup boot device to work on your main-device Grub2 installation.


That takes several reboots rather than just one, but then it means
you're never more than one reboot away from a working system, rather
than possibly dead in the water until you can figure out and fix
whatever the problem is (either by fixing the Grub2 problem or by
booting enough (viaa rescue disc) to re-install your LILO
configuration.


Daniel



--
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/4c051c29.60...@fgm.com

Re: lilo removal in squeeze (or, please test grub2)

2010-06-01 Thread John Hasler

Stephen Powell writes:
 Actually, I've been tempted to volunteer to become the upstream
 maintainer for lilo myself.

Please do so.

 However, although the SAPL is written in assembly language, it is
 written in s390 assembly language, which is totally different from x86
 assembly language.  I don't know x86 assembly language at all.

Set up a Web site (I suggest tuxfamily.org for hosting) and ask for
help.  You'll find that there are people who can and will do the coding
but who don't want the hassle and responsibility of running the project.
-- 
John Hasler


-- 
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/87mxved91p@thumper.dhh.gt.org

Re: lilo removal in squeeze (or, please test grub2)

2010-06-01 Thread Andrei Popescu

On Ma, 01 iun 10, 10:25:42, Stephen Powell wrote:
 
 Actually, I've been tempted to volunteer to become the upstream maintainer
 for lilo myself.  I have worked on boot loaders before, on other platforms.

[...]
 
 I agree.  But I also sympathize with the poor package maintainer who is
 essentially functioning as both package maintainer and upstream support.
 That cannot go on forever.  Someone has to step up to the plate and take
 over upstream support.  I'd do it myself if I had the requisite skills.
 But as of now, I just don't.
 
 Perhaps one of the reasons that no-one has stepped up to the plate to take
 over upstream support is the perception that lilo can't handle today's
 large kernels and therefore we should just let it die.  That is simply not
 true.  I use stock kernels most of the time.  And I use lilo.  And I've
 never had a bit of trouble.  I just have to make sure by the use of hook
 scripts that lilo actually gets run when a kernel is installed or updated.
 And that's easy enough to do.

Maybe it would be enough if you just take over the maintenance of the 
Debian package. After all, you are very familiar with lilo and run it on 
many machines. If the code is as stable as I've read in this thread it 
shouldn't be too difficult.

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

2010-06-01 Thread Stephan Seitz


On Mon, May 31, 2010 at 01:29:15AM +0300, Andrei Popescu wrote:

Having /boot on a separate partition for robustness, security or
advanced features (encrypted LVM and stuff) is one thing, but having it
because the default bootloader doesn't support current (ext4) and future
(btrfs) filesystems seems like a hack to me.


But I don’t think that everyone will switch to ext4 with the next 
release, even if they install new systems. Does the squeeze installer 
support ext4 or is this the new filesystem if you don’t choose one?


Besides we are not talking about having grub1 for all eternity. If grub2 
will support all features of grub1, we can replace the bootloader in 
squeeze + 1.



Is it just me or does this sound like the KDE3 - KDE4 debate all over
again?


I don’t know, I don’t use KDE. ;-)
But if I have to use KDE to help another user, I feel more comfortable 
with KDE3. KDE4 looks terribly and I don’t find anything.



software (Stephen's case), but we have to face it:
* LILO is not developed anymore
* Grub1 is not developed anymore


Yes, but for now both bootloader are still working. They may not support 
ext4, but they do support things grub2 doesn’t.



Unless there are people interested in further developing those code
bases they will be gone sooner or later. And my feeling (as a


Yes, but in the time for squeeze + 1, grub2 may get all missing features 
from grub1. Then we can at least through away grub1.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

2010-05-31 Thread Tom H

On Sat, May 29, 2010 at 11:46 PM, Stan Hoeppner s...@hardwarefreak.com wrote:
 Tom H put forth on 5/28/2010 10:55 PM:
 On Fri, May 28, 2010 at 9:50 PM, Stan Hoeppner s...@hardwarefreak.com 
 wrote:
 Roger Leigh put forth on 5/28/2010 11:39 AM:

 For the most part, grub is a vast
 improvement over LILO, and except for the odd corner cases which
 grub doesn't cover,

 In what way is it a vast improvement over LILO? I've never had a problem 
 with
 LILO. It's always just worked, which is what a bootloader should do. So
 how exactly would grub be a better choice for me?

 The reverse argument can be made too. Both grub1 and grub2 just work.
 Unless you are continually installing dual- and triple-boot this or
 that, you are not going to be changing you config continually no
 matter what bootloader you use and you will therefore not be
 interacting with it that much. So, except for Stephen P's case, what's
 the big deal?

 I frequently roll new kernels from kernel.org source using the Debian
 installation method, once every couple of months. I'm very comfortable with
 using LILO for this. I've pretty much zero experience with Grub (any
 version). If something goes wrong converting from LILO to Grub2, I'm screwed.
  And I'll probably have an unwanted and unneeded learning curve while
 continuing my current practice of rolling kernels frequently.

 Please don't debate the merits of customs kernels. I have very valid reasons
 for doing so. Let's focus on why or why not Grub2 will work for my needs, and
 not hose my systems either during the migration from LILO to Grub2, or
 installing custom kernels after the fact.

I have absolutely no problem with custom kernels. (What I don't
understand is people who jump up and down on various lists when
someone says that he/she compiles custom kernels!)

I haven't used lilo for nine-ten years but I don't see how adding a
custom kernel to grub rather than lilo should affect your kernel
compilation. I don't use the Debian tools so after make install, I
run update-initramfs ... and update-grub, and I'm done. I don't
see how, if I were using lilo, I would have to follow a different
procedure, except for setting editing lilo.conf and running lilo after
update-initramfs. Am I missing something?

As I said in my previous post, I would install Squeeze's grub2 on a
Lenny box and reboot to check that it is working before the upgrade to
Squeeze.

I have gone through various big changes in OSs, WinNT to Win2k, OS9 to
OSX (although I was a Sol-Lin admin too so it wasn't as great a shock
as for Mac-only admins [1. see OT anecdote below]), Sol8 to Sol10 and
they created more dislocation than a bootloader change. At the risk of
sounding like a late-night infomercial (!), a smooth transition from
lilo to grub2 is just a question of being positive (the un-unwanted
and un-unneeded of above) - and putting in some work (the learning
curve of above) of course.

grub2 basics--

Setup

Although grub2 sources a file in /usr/lib/grub when creating its
config, the files that matter are /etc/default/grub and /etc/grub.d/*.
You set various variables like the kernel options, the default entry,
whether to create entries with single appended, ... in
/etc/default/grub. When you run update-grub (which is a script that
runs grub-mkconfig -o /boot/grub/grub.cfg), the grub2 menu's
configuration, /boot/grub/grub.cfg, is built by running the scripts in
/etc/grub.d/.

I don't really like what the /etc/grub.d/ scripts do, so I chmod 644
them except for the last one, 40_custom, and I write my grub.cfg
there. It is a script of the form:
cat  EOF
my grub2 config
EOF
so my /boot/grub/grub.cfg ends up exactly like 40_custom except for
the first two lines and the last one.

The disadvantage of using this method is that I have to add and remove
kernels manually to 40_custom, whereas the standard way is that the
00_header, 10_linux, and 30_os-prober scripts populate the grub2 menu
automagically. The initial run of update-grub, after you install
grub2, will give you a good base to create 40_custom if that is the
way that you want to go.

Unsurprisingly, since all that a bootloader does is point to and loads
an initrd and kernel, /boot/grub/grub.cfg basically looks like
lilo.conf (for a reference lilo config file, I am looking at Stephen
P's kernel compilation page, which, btw, is included in the
documentation of kernel-package) with a different syntax.

There are global options (default entry, grub root partition,
console or gfxterm, timeout, ...) and per-image options where
menuentry corresponds to label, linux to image, and initrd to initrd.

As an added twist, grub2 is modular so both (possibly redundantly but
I have never tested this) the global and per-image sections have
insmod invocations for filesystems, raid, lvm, framebuffer, ...

Recovery

You only have to net-boot or cd-boot a grub2 install to correct it if
its first stage loader in the MBR is dead. If you net-boot or cd-boot
to re-write to the MBR, you have to

Re: lilo removal in squeeze (or, please test grub2)

2010-05-31 Thread Stefan Monnier

 Maybe, but ext4 support is not really crucial. Simply make /boot ext2.

Actually ext3 works fine.

 Having /boot on a separate partition for robustness, security or 
 advanced features (encrypted LVM and stuff) is one thing, but having it 
 because the default bootloader doesn't support current (ext4) and future 
 (btrfs) filesystems seems like a hack to me.

Until the bootloader is itself a Linux kernel (so it can directly use
Linux fs drivers), the bootloader will always be playing catch-up.
I've been using a /boot partition forever, because I have / on LVM.
Nowadays, I use Grub2 on several of my machines, so I could put /boot
directly in LVM, but why bother?

The thing that I would find more useful is to get rid of things like
update-grub, and instead have the bootloader generate the bootlist on
the fly.  I.e.: install the bootloader, and never touch it again.

 Also, the config has become so complicated you need another config
 file (/etc/default/grub) to configure how it will be generated :(

Yes, that sucks as well.

 * LILO is not developed anymore
 * Grub1 is not developed anymore

I've used Lilo a few times in the past and found it very useful because
of its simplicity: tell it where are the files to boot, and on which
drive to install itself, and that's it.

For Grub1 (and worse for Grub2), you have to worry about the difference
between where the files are now vs where the files will be when
I boot, then multiply that by the different sorts of files (Grub2
modules, Grub config file, kernel/initrd files) and then you have to add
the fact that the grub-install scripts try to hide these differences
from you.  E.g. I could never use Grub1's grub-install and be
confident of the result, so I always used /usr/sbin/grub to install
Grub1 instead.  With Grub2 this is not even an option, so I use
`grub-install' and then I just hope for the best.  Luckily, my setups
are usually simple.


Stefan


-- 
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/jwvr5ksxaf1.fsf-monnier+gmane.linux.debian.u...@gnu.org

Re: lilo removal in squeeze (or, please test grub2)

2010-05-31 Thread Stephen Powell

On Sun, 30 May 2010 03:48:50 -0400 (EDT), Andrei Popescu wrote:
 On Sat,29.May.10, 22:35:56, Stan Hoeppner wrote:
 
 My gut instinct is that due to the above reasons and possibly others, the 
 next
 dist upgrade is going to hose all my production servers whilst trying to
 forcibly convert them to Grub2.  Is my instinct correct?
 
 Worst case you'll have to pin lilo at 1001 and grub-pc at -1 before the 
 upgrade ;)

Does anybody know what happened to John Coffman (the last known upstream
maintainer for lilo)?  Did he get bored with maintaining lilo?  He was
doing a great job.  I think he's the one that added lba32 support.
He seems to have fallen off the face of the earth.  Did he die or what?

-- 
  .''`. 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/1734713713.184635.1275357460852.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Stan Hoeppner

Stephen Powell put forth on 5/29/2010 9:48 AM:

thorough explanation snipped

 As time goes on, these restrictions are getting more restrictive.
 And we are looking at alternatives to our existing backup software.
 But for now, I have to live within these restrictions.

Implement VMware ESX and VMware Consolidate Backup (or whatever their
marketing calls them today).  The price is high, but the capability for
platform consistent PIT backup is unmatched.  Of course, you need at bare
minimum a small FC or iSCSI SAN, preferably FC as it's over 4 times the
throughput and lower latency.  You can build such a SAN with a Qlogic 8 port
4Gb FC switch, FC HBAs for 4 or so servers, a Nexsan SATABoy storage array
w/2GB cache and 14x500GB drives in RAID6 for about $20k USD.  At least, *I*
could build and integrate this relatively low end FC SAN for that.  Add
about $5k for the VCB server hardware and its largish 6TB worth of initial
scratch space.  I assume you already have an appropriate tape library.

You'd have to contact a VMware rep for current ESX and VCB pricing.  If an
organization can afford it, it's the only way to fly, especially VCB.

-- 
Stan



-- 
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/4c02143f.1090...@hardwarefreak.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Andrei Popescu

On Sat,29.May.10, 22:35:56, Stan Hoeppner wrote:
 
 My gut instinct is that due to the above reasons and possibly others, the next
 dist upgrade is going to hose all my production servers whilst trying to
 forcibly convert them to Grub2.  Is my instinct correct?

Worst case you'll have to pin lilo at 1001 and grub-pc at -1 before the 
upgrade ;)

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread thib


Stan Hoeppner wrote:

My gut instinct is that due to the above reasons and possibly others, the next
dist upgrade is going to hose all my production servers whilst trying to
forcibly convert them to Grub2.  Is my instinct correct?


Like any dist upgrade, squeeze will have release notes with upgrade 
instructions and I'm quite confident everything concerning lilo will be 
covered.  There are probably many upgrade test patterns they'll have to try, 
that's true, but I would hope the transition goes smoothly for most systems.


-t


--
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/4c026266.8020...@stammed.net

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Paul E Condon

On 20100529_223556, Stan Hoeppner wrote:
 thib put forth on 5/28/2010 9:44 PM:
 
* If yes, should it still be presented as an expert option in d-i? 
  Why not, I guess.  If not, should extlinux be extensively tested to be
  provided as an alternative choice in d-i?  I really don't know how much
  work would be needed for this.
 
 I'm far more concerned at this point with distribution upgrades than new
 installs.  I've a number of production Lenny servers all using LILO.  What
 will happen to the bootloader config on these machines when I perform a dist
 upgrade after Squeeze becomes Stable?  These machines all use custom rolled
 kernels from kernel.org source (installed the Debian way), if that makes any
 difference.  Also, the kernel images are in /boot, not in / with the
 traditional symlinks.
 
 My gut instinct is that due to the above reasons and possibly others, the next
 dist upgrade is going to hose all my production servers whilst trying to
 forcibly convert them to Grub2.  Is my instinct correct?

Yes, but ...

I don't have anything as difficult to manage as you. But I am also far
less adept. Long ago I gave up on dist-upgrade as a thing I wanted to
do.  I think I stopped using it even before it was renamed to
dist-upgrade.  Instead, I devote a few GB of hard disk to multiple
partitions on which I can install successively newer releases of
Debian, but only the parts that change in the new release. Thanks to
HFS it is easy to determine which those are. I make a new clean
install in a newly formatted partion. If it doesn't work, I can reboot
back into what I had been running minutes before.  It took me a while
to work out all the kinks, but it is well worth the trouble.  As an
added benefit of this way, I mount the older root partition under a
special non-standard mount point in the new installation. If(When) I get
into trouble, I can refer to that partition to see how things were set up
before I started mucking about. 

I know this is a waste of disk space, but it is impossible to buy a HD
so small that it cannot hold several full installations of
Debian/GNU/Linux.

I suggest you rearrange your disks to make room for additional base-installs.
Practice doing Lenny to Lenny transitions to make sure you have your plan
fully worked out. And then, wait for Squeeze with the sure knowledge that
you can reboot back into your existing software. 

I cannot believe Grub2 will remain in its current state of disarray
when release of Squeeze finally happens. The module that finds
pre-existing installs and adds them to the boot menu seems to work but
when you do reboot at the end of the install process, the
installations that were listed as having been found are not there in
the boot menu. Just issue update-grub and reboot again. It is fixed.

Does this post give you warm fuzzies about the coming release?

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
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/20100530153745.ga29...@big.lan.gnu

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Stephan Seitz


On Fri, May 28, 2010 at 11:55:58PM -0400, Tom H wrote:

The reverse argument can be made too. Both grub1 and grub2 just work.


I accept this argument for grub1. Yes, I never had problems with grub1, 
but grub2 is simply not ready for prime time.


While grub2 works for simple workstations, it can’t redirect its output 
to serial console and monitor like grub1 and it doesn’t understand XEN 
hypervisor kernels.


As long as grub2 has so many missing features it should not be considered 
default bootloader in Debian.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Sven Joachim

On 2010-05-30 18:29 +0200, Stephan Seitz wrote:

 On Fri, May 28, 2010 at 11:55:58PM -0400, Tom H wrote:
The reverse argument can be made too. Both grub1 and grub2 just work.

 I accept this argument for grub1. Yes, I never had problems with
 grub1, but grub2 is simply not ready for prime time.

 While grub2 works for simple workstations, it can’t redirect its
 output to serial console and monitor like grub1 and it doesn’t
 understand XEN hypervisor kernels.

The main problem with grub1 is the same as with lilo: there is no
upstream maintainer, and crucial parts of the code are undocumented
and not understandable¹.

 As long as grub2 has so many missing features it should not be
 considered default bootloader in Debian.

So which bootloader should be the default?  Grub1 is also lacking
important features, albeit different ones than grub2 (e.g. ext4
support).

Sven


¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#237


-- 
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/87eigt5n7s@turtle.gmx.de

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Stan Hoeppner

Paul E Condon put forth on 5/30/2010 10:37 AM:
 On 20100529_223556, Stan Hoeppner wrote:

 I'm far more concerned at this point with distribution upgrades than new
 installs. snip

 My gut instinct is that due to the above reasons and possibly others, the 
 next
 dist upgrade is going to hose all my production servers whilst trying to
 forcibly convert them to Grub2.  Is my instinct correct?

 I don't have anything as difficult to manage as you. 

These systems are a breeze to manage currently, not difficult at all.

 But I am also far
 less adept. Long ago I gave up on dist-upgrade as a thing I wanted to
 do.  I think I stopped using it even before it was renamed to
 dist-upgrade.  Instead, I devote a few GB of hard disk to multiple
 partitions on which I can install successively newer releases of
 Debian, but only the parts that change in the new release. Thanks to
 HFS it is easy to determine which those are. I make a new clean
 install in a newly formatted partion. If it doesn't work, I can reboot
 back into what I had been running minutes before.

Herein lies the problem with changing bootloaders.  Your safe recovery
methodology (which is quite smart btw and I've used it myself over the years)
goes out the window in this case because the bootloader controls loading every
one of your parallel installations.  If the bootloader gets hosed, you can't
load any of them.  You're fscked.

 I know this is a waste of disk space, but it is impossible to buy a HD
 so small that it cannot hold several full installations of
 Debian/GNU/Linux.

Not a waste of space at all, but a very good use of a tiny percentage of the
space available on current drives.  With 500GB drives at ~$50 USD, and a
typical Debian install being ~5GB, you could have 10 parallel installations
using only 10% of the drive's space.  That's a smart investment in potential
severe headache prevention.  Ten parallel installs is extreme, but I'm simply
demonstrating the cost of storage aspect.

 I suggest you rearrange your disks to make room for additional base-installs.
 Practice doing Lenny to Lenny transitions to make sure you have your plan
 fully worked out. And then, wait for Squeeze with the sure knowledge that
 you can reboot back into your existing software. 

What you suggest here doesn't really come into play.  This isn't an issue of
going from Lenny to Squeeze.  This isn't about different package revs.  It's
not about Squeeze having problems and wanting to boot back into Lenny.  The
problem, in and of itself, is booting.  Period.  There is not way to test it
but to replace LILO with Grub2 and see if the system boots afterward.  I
cannot do this on production servers, obviously.  Cloning drives to play with
on a lab machine would be a good idea, but I can't take production servers
offline to clone the disks.  The only real way to test this is to build a
fresh Lenny test rig from scratch with LILO, tweak it to match my production
systems, then install Grub2 and see what, if anything, breaks, and figure out
how to get around the breakage.

 I cannot believe Grub2 will remain in its current state of disarray
 when release of Squeeze finally happens. The module that finds
 pre-existing installs and adds them to the boot menu seems to work but
 when you do reboot at the end of the install process, the
 installations that were listed as having been found are not there in
 the boot menu. Just issue update-grub and reboot again. It is fixed.

I hope it's ready for prime time by then.

 Does this post give you warm fuzzies about the coming release?

I'm not worried about the release.  I've taken these machines through four
live online apt upgrades all the way back from Woody to Lenny, 4 releases,
without major issues.  However, the bootloader never changed.  LILO all the
way through.  This upgrade will be radically different in this respect.

I guess I could start looking for an aftermarket bootloader to avoid this mess
altogether, although I'd rather use a FOSS solution.  Maybe extlinux.  From
what others have said here it shows some promise.

-- 
Stan


-- 
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/4c02c573.4070...@hardwarefreak.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Stephan Seitz


On Sun, May 30, 2010 at 07:11:19PM +0200, Sven Joachim wrote:

The main problem with grub1 is the same as with lilo: there is no
upstream maintainer, and crucial parts of the code are undocumented
and not understandable¹.


But at least grub1 is working in a wider field than grub2. And lilo is 
still working, too. Maybe not with the current Debian kernel, but it 
works for people building their own kernel.



So which bootloader should be the default?  Grub1 is also lacking
important features, albeit different ones than grub2 (e.g. ext4
support).


Maybe, but ext4 support is not really crucial. Simply make /boot ext2.

I would say, the default bootloader should be grub1, expert installation 
can offer grub2 as well. Lilo should be in the distribution as well, so 
people can switch after installation. At least for the next release.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Mark

On Sun, May 30, 2010 at 1:50 PM, Stephan Seitz 
stse+deb...@fsing.rootsland.net stse%2bdeb...@fsing.rootsland.net wrote:


 I would say, the default bootloader should be grub1, expert installation
 can offer grub2 as well. Lilo should be in the distribution as well, so
 people can switch after installation. At least for the next release.


I have a question related to this: recently the screen on a dual boot
(XP/Lenny) laptop got busted pretty badly (almost to the point where grub1's
blue splash screen menu is not visible at all), and since the primary
purpose of this laptop is now to boot to XP to use Netflix's Microsoft
Silverlight-based movie player while connected to an hdtv for on-line movie
watching, I just booted to Lenny, changed the default=0 value to
default=3 in /boot/grub/menu.lst so it now boots to XP by default.  My
limited experience with grub2 in Squeeze didn't appear to have this ability,
so what would I have done in this case?  Would I be fscked?

Thanks,
Mark

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Brian Marshall

On Sun, May 30, 2010 at 03:02:23PM -0700, Mark wrote:
   I just booted to Lenny, changed the default=0 value to
 default=3 in /boot/grub/menu.lst so it now boots to XP by default.  My
 limited experience with grub2 in Squeeze didn't appear to have this ability,
 so what would I have done in this case?  Would I be fscked?

It's still there, just moved. Edit /etc/default/grub, change
GRUB_DEFAULT to 3 and run update-grub.

Brian


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Mark

On Sun, May 30, 2010 at 3:12 PM, Brian Marshall bm...@sdf.lonestar.orgwrote:

 On Sun, May 30, 2010 at 03:02:23PM -0700, Mark wrote:
I just booted to Lenny, changed the default=0 value to
  default=3 in /boot/grub/menu.lst so it now boots to XP by default.  My
  limited experience with grub2 in Squeeze didn't appear to have this
 ability,
  so what would I have done in this case?  Would I be fscked?

 It's still there, just moved. Edit /etc/default/grub, change
 GRUB_DEFAULT to 3 and run update-grub.


Very helpful, thank you Brian.

Re: lilo removal in squeeze (or, please test grub2)

2010-05-30 Thread Andrei Popescu

On Sun,30.May.10, 22:50:44, Stephan Seitz wrote:
 On Sun, May 30, 2010 at 07:11:19PM +0200, Sven Joachim wrote:
 The main problem with grub1 is the same as with lilo: there is no
 upstream maintainer, and crucial parts of the code are undocumented
 and not understandable¹.
 
 But at least grub1 is working in a wider field than grub2. And lilo
 is still working, too. Maybe not with the current Debian kernel, but
 it works for people building their own kernel.
 
 So which bootloader should be the default?  Grub1 is also lacking
 important features, albeit different ones than grub2 (e.g. ext4
 support).
 
 Maybe, but ext4 support is not really crucial. Simply make /boot ext2.

Having /boot on a separate partition for robustness, security or 
advanced features (encrypted LVM and stuff) is one thing, but having it 
because the default bootloader doesn't support current (ext4) and future 
(btrfs) filesystems seems like a hack to me.

 I would say, the default bootloader should be grub1, expert
 installation can offer grub2 as well. Lilo should be in the
 distribution as well, so people can switch after installation. At
 least for the next release.

Is it just me or does this sound like the KDE3 - KDE4 debate all over 
again?

Don't get me wrong, I've had my part of headaches with grub2 (I switched 
quite early), but most are fixed, so grub2 does almost everything *I* 
need. Also, the config has become so complicated you need another config 
file (/etc/default/grub) to configure how it will be generated :(

I read grub2 is still missing features (like simultaneous display on a 
serial console and VGA), and it is (still?) incompatible with some 
software (Stephen's case), but we have to face it:

* LILO is not developed anymore
* Grub1 is not developed anymore

Unless there are people interested in further developing those code 
bases they will be gone sooner or later. And my feeling (as a 
non-programmer) is that they have become unmaintainable, or at least it 
has become too much work compared to writing something from scratch 
(grub2, extlinux, ...).

AFAICT, the only thing that we as users can do (short of putting up 
bounties) is to push for the missing features to be implemented and the 
bugs to be fixed. But none of this will happen unless we are at least 
willing to *test* the new stuff. At least the regulars on this list 
should know how to recover from an unbootable system, or not? 

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

2010-05-29 Thread Stephen Powell

On Fri, 28 May 2010 21:26:01 -0400 (EDT), Stan Hoeppner wrote:
 Stephen Powell put forth on 5/28/2010 9:45 AM:
 The problem can be circumvented by taking an image backup
 instead of a logical backup, but that gets into special backup
 requirements.
 
 Can you mix and match?  Does the image backup grab the entire disk or does it
 work at the partition level?  Can you, say, do an image backup of the MBR and
 boot sector and the /boot partition, and then use file backup on the rest of
 the disk.

I'm not sure.  But the whole point is for the backup people to be able
to backup and restore a Linux server using the same procedure as they
would for a Windows server.  And their standard method is to take a
logical backup of the entire disk.


 What backup software are you using that can take an image backup of a Linux
 boot disk?  Does it install a local agent for this?  Or are you booting from
 SAN?  If so, you should have all kinds of backup flexibility, depending on
 whose storage arrays you use.

The machine is backed up by doing a PXE network boot directly from the
hardware BIOS.  The backup client does not exist on the hard drive
that is being backed up.  It is downloaded over the network, just as
the netboot operating system is.  The backup itself is done by connecting to
a backup server and sending the data over the network.  There is no
local tape drive or anything of that nature.  The restore procedure
is similar.

Yes, there is backup
flexibility.  But the whole goal here is to make the backup process
standard for every server, regardless of whether it runs Windows or
Linux.  I don't want the backup people to have to make a decision.
OK, now let's see.  Is this a Linux server or a Windows server?
If it's a Linux server I have to remember to take the backup this
special way.  Otherwise, I do it the standard way.  They'll forget.
Or a new guy will come along who doesn't know to do it differently
for a Linux server and he won't do it right.  And then, if we have
to restore from the backup that wasn't taken the proper way, the machine
won't boot.  And then Linux looks bad.  I want the standard method that
they use for Windows machines to work for a Linux server too.  And as
long as I live within the restrictions of supported file systems and
boot loaders, the backup and restore software understands the file system
and can backup the disk on a file-by-file basis, and the restore software
knows how to patch the boot loader after the restore to make the machine
bootable.

As time goes on, these restrictions are getting more restrictive.
And we are looking at alternatives to our existing backup software.
But for now, I have to live within these restrictions.

-- 
  .''`. 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/115102933.148780.1275144536082.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-29 Thread Andreas Barth

* Stephen Powell (zlinux...@wowway.com) [100523 21:21]:
 On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
  After some discussion about lilo on #debian-devel in IRC, it has pretty
  much been determined that kernel sizes have crossed the line past where
  lilo can reliably determine the payload size.

We're speaking about #505609 I assume?


I'm not sure this bug requires an removal of lilo (see below), however
I think this means we should strongly discourage usage of lilo.


  (1) The release notes need to be updated to reflect that lilo is no
  longer a bootloader option;

The release notes should be updated in case we keep lilo that we
recommend to move to another boot loader now.


  (2) The debian-installer team needs to remove the lilo-installer udeb;

This should indeed happen - if someone activly requires lilo, then
doing it by hand should be ok-ish.



 I am not a Debian package maintainer or a Debian developer.  I am just an
 ordinary system administrator.  So I'm sure that my opinion will not count
 for much.  But I am opposed to the removal of lilo.  Both grub-legacy and
 grub-pc use sectors on the hard disk outside of the master boot record
 (cylinder 0, head 0, sector 1).  In other words they use cylinder 0, head 0,
 sector 2 and possibly subsequent sectors on cylinder 0 head 0.  This breaks
 the design of the backup software that my employer uses.  This backup software
 backs up the master boot record and all partitions; but since the extra
 sectors used by grub-legacy and grub-pc are outside the master boot record
 and are not part of any partition, they don't get backed up.  Consequently,
 if we have a hard drive failure and restore from a backup, we have an
 unbootable machine.  Lilo uses only the master boot record.  A lilo-booted
 machine can be backed up and restored with our existing backup software
 just fine.  Given these requirements, I wouldn't use grub-pc even if it
 were bug free and well documented.  (But neither is the case!)

Would it be possible to move (perhaps optionally) the extra grub sectors
into an (perhaps dummy) partition (this question is for the
grub2-people)? Would that be ok for you?


 As for the claims that kernels are too big now, I find that hard to
 believe, especially now that we have the large-memory option available.
 The standard stock Debian kernel image file that I use for Squeeze,
 vmlinuz-2.6.32-3-686, is currently 2234080 bytes.  Are you trying to tell
 me that there's no room for a 2M kernel below the start of the EBDA?
 
 I am able to load *both* the kernel *and* the initial RAM filesystem
 below the EBDA (i.e. the large-memory option is not used) if I use
 MODULES=dep instead of MODULES=most in the initial RAM filesystem
 under Lenny.  I'll bet I can do it with Squeeze too.

This sounds like we should add an wrapper around lilo that warns that
lilo is deprecated and warns if the images are too large.



Andi


-- 
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/20100529184041.gk13...@mails.so.argh.org

Re: lilo removal in squeeze (or, please test grub2)

2010-05-29 Thread Stephen Powell

On Sat, 29 May 2010 14:40:41 -0400 (EDT), Andreas Barth wrote:
 Stephen Powell wrote:
 On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
 After some discussion about lilo on #debian-devel in IRC, it has pretty
 much been determined that kernel sizes have crossed the line past where
 lilo can reliably determine the payload size.


 We're speaking about #505609 I assume?

I hope not.  Strictly speaking, 505609 is not a lilo bug.  The key is
that he was still able to boot his old kernel that had been de-installed.
That's a sure sign that lilo's map installer did not get run during the
kernel upgrade process.  It used to be that if

   do_bootloader = yes

was specified in /etc/kernel-img.conf that installing a new kernel would
cause lilo to be run.  That is no longer the case.  update-initramfs -u ... 
will cause lilo to be run if this option is set; but update-initramfs -c ...
(or mkinitramfs ...) which is what is run during installation of a new kernel,
will not.  I have created my own hook script to fix that problem on my system.
Strangely, though, do_bootloader = yes in /etc/kernel-img.conf still
causes zipl to be run during kernel installation on the s390 platform.
Something must have changed in the kernel maintainer script or in
update-initramfs that causes the lilo map installer to not be run anymore
under conditions that used to cause it to be run.

Look carefully at the console log.  There is no output from the map installer
until he manually runs lilo.  He apparently thinks that running lilo from
the command line simply lists the installed kernels.  No.  Running lilo
from the command line is what fixed the problem.

If there's a bug here, it's somewhere else in the kernel installation
process, not in lilo itself.  If this so-called bug in lilo is what
prompted the decision to drop lilo, then the decision was based on bad data.
lilo, at least in this case, is working as designed.  The problem is that
the lilo map installer did not get run during the kernel installation
process.  I've helped a number of people on debian-user with problems
like this, and in every case so far running lilo at the command line
fixed the problem.

-- 
  .''`. 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/267435255.153128.1275165812236.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-29 Thread Stan Hoeppner

thib put forth on 5/28/2010 9:44 PM:

   * If yes, should it still be presented as an expert option in d-i? 
 Why not, I guess.  If not, should extlinux be extensively tested to be
 provided as an alternative choice in d-i?  I really don't know how much
 work would be needed for this.

I'm far more concerned at this point with distribution upgrades than new
installs.  I've a number of production Lenny servers all using LILO.  What
will happen to the bootloader config on these machines when I perform a dist
upgrade after Squeeze becomes Stable?  These machines all use custom rolled
kernels from kernel.org source (installed the Debian way), if that makes any
difference.  Also, the kernel images are in /boot, not in / with the
traditional symlinks.

My gut instinct is that due to the above reasons and possibly others, the next
dist upgrade is going to hose all my production servers whilst trying to
forcibly convert them to Grub2.  Is my instinct correct?

-- 
Stan


-- 
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/4c01dd1c.1090...@hardwarefreak.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-29 Thread Stan Hoeppner

Tom H put forth on 5/28/2010 10:55 PM:
 On Fri, May 28, 2010 at 9:50 PM, Stan Hoeppner s...@hardwarefreak.com wrote:
 Roger Leigh put forth on 5/28/2010 11:39 AM:
 
 For the most part, grub is a vast
 improvement over LILO, and except for the odd corner cases which
 grub doesn't cover,

 In what way is it a vast improvement over LILO? I've never had a problem with
 LILO. It's always just worked, which is what a bootloader should do. So
 how exactly would grub be a better choice for me?
 
 The reverse argument can be made too. Both grub1 and grub2 just work.
 Unless you are continually installing dual- and triple-boot this or
 that, you are not going to be changing you config continually no
 matter what bootloader you use and you will therefore not be
 interacting with it that much. So, except for Stephen P's case, what's
 the big deal?

I frequently roll new kernels from kernel.org source using the Debian
installation method, once every couple of months.  I'm very comfortable with
using LILO for this.  I've pretty much zero experience with Grub (any
version).  If something goes wrong converting from LILO to Grub2, I'm screwed.
 And I'll probably have an unwanted and unneeded learning curve while
continuing my current practice of rolling kernels frequently.

Please don't debate the merits of customs kernels.  I have very valid reasons
for doing so.  Let's focus on why or why not Grub2 will work for my needs, and
not hose my systems either during the migration from LILO to Grub2, or
installing custom kernels after the fact.

-- 
Stan


-- 
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/4c01dfb1.8010...@hardwarefreak.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-29 Thread Mark Allums

For yet another view on this, Grub2 is pants.  I see no good reason to 
eliminate both lilo and GRUB at the same time.  Eliminate lilo or GRUB 
but not both, and let the user choose to use Grub2 or the older method. 
 When Grub2 matures some more, move to it, but it's not ready yet to 
take on the full responsibility of booting all of creation.


MAA


--
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/4c01ec35.6020...@allums.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-29 Thread Lisi

On Sunday 30 May 2010 05:40:21 Mark Allums wrote:
 For yet another view on this, Grub2 is pants.  I see no good reason to
 eliminate both lilo and GRUB at the same time.  Eliminate lilo or GRUB
 but not both, and let the user choose to use Grub2 or the older method.
   When Grub2 matures some more, move to it, but it's not ready yet to
 take on the full responsibility of booting all of creation.

 MAA

+1

I am accustomed to GRUB 1.  But if I have to change, I would rather change to 
LILO than to GRUB 2. :-(

Lisi


-- 
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/201005300606.34893.lisi.re...@gmail.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread Alan Greenberger

On 2010-05-23, William Pitcock neno...@dereferenced.org wrote:

 After some discussion about lilo on #debian-devel in IRC, it has pretty
 much been determined that kernel sizes have crossed the line past where
 lilo can reliably determine the payload size.

Could you explain what this boundary (line) is?  Is the problem the
absolute size or the determination of the uncompressed value?


-- 
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/slrnhvvhpb.tsb.ala...@archduke.router

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread Frank Van Damme

2010/5/23  bri...@aracnet.com:

 Furthermore asking people to test it is not exactly a minor request.
 When it doesn't work you get to break out the rescue disk and go
 through some relatively painful work to recover.  I know, because I had
 to do it.

Make it less painful: keep your old menu.lst and use super grub disk.
It'll find it in seconds. Barely slower than booting with a non-broken
bootloader ;-)

 I for one would really appreciate it if the lilo maintainer could write
 just a little bit about the scope of work required to fix it (to this
 list). It would be a real shame if lilo goes away.

Is it, by the way, true that using LILO allows you to put /boot on LVM?


-- 
Frank Van Damme
A: Because it destroys the flow of the conversation.
Q: Why is it bad?
A: No, it's bad.
Q: Should I top post in replies to mailing lists or on Usenet?


--
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/aanlktimgfhx_lqgktgwspo0d0t5cr9m2lv57pdh_s...@mail.gmail.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread Stephen Powell

On Tue, 25 May 2010 13:12:27 -0400 (EDT), Stephen Powell wrote:
Boyd Stephen Smith Jr. wrote:
No software is entirely without cost ...
volunteers work on whatever they like ...
your specific requirements may differ from their goals ...
volunteers are rarely concerned with market share ...

All excellent points, Boyd. Fortunately in this case, extlinux appears
to be a viable solution. I'll soon know ...

Unfortunately, logical backups of a Linux machine using the extlinux
boot loader do not work with our backup/restore software. The master boot
record and partition boot sector are restored correctly, but
/boot/extlinux/extlinux.sys will probably not be restored to the exact
same sectors from which it was backed up, and the restore software has no
special logic to remedy that situation. Therefore, after restore, the
machine will not boot. It *does* recognize lilo and has special logic
to patch lilo after the restore so that the machine will boot.

The problem can be circumvented by taking an image backup
instead of a logical backup, but that gets into special backup
requirements. Until we get newer backup software I must either use
lilo or ask for special backup procedures for my Linux servers.
I choose the former. Logical (file by file) backups have many advantages,
one of which is to avoid giving the Windows advocates an excuse to oppose
further deployment of Linux servers.

--
.''`. 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/1739612780.129666.1275057918173.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread Roger Leigh

On Fri, May 28, 2010 at 04:34:06PM +0200, Frank Van Damme wrote:
 
  I for one would really appreciate it if the lilo maintainer could write
  just a little bit about the scope of work required to fix it (to this
  list). It would be a real shame if lilo goes away.
 
 Is it, by the way, true that using LILO allows you to put /boot on LVM?

It's possible for a simple LVM setup.  However, it's also very
easy to get an unbootable system!  Since it's just storing
blocklists, any LVM changes have the potential to screw up
LILO, and (from experience) it's actually quite hard to rescue
once broken (due to difficulties getting the LVM/RAID up and
mounted and then running lilo in a chroot; I had issues with
the device numbers being wrong).

Nowadays I just use a separate /boot and then use GRUB2, and
it all works nicely.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread Josselin Mouette

Le vendredi 28 mai 2010 à 10:45 -0400, Stephen Powell a écrit :
 Unfortunately, logical backups of a Linux machine using the extlinux
 boot loader do not work with our backup/restore software.  The master boot
 record and partition boot sector are restored correctly, but
 /boot/extlinux/extlinux.sys will probably not be restored to the exact
 same sectors from which it was backed up, and the restore software has no
 special logic to remedy that situation.  Therefore, after restore, the
 machine will not boot.  It *does* recognize lilo and has special logic
 to patch lilo after the restore so that the machine will boot.

We have understood that your backup software is broken. It’s not the
only one. There’s nothing we can do to fix broken, proprietary backup
software.

If you want to become the new upstream for lilo because you need to cope
with broken backup software, please go ahead; I’m sure the effort will
be welcome. If not, I think you have made your point by now.

As a personal advice, I would recommend you to stop bothering with that
broken backup software, it doesn’t seem good for your health. Set up a
CIFS share on a backed-up Windows server, copy your data there using one
of the numerous solutions in Debian, and get done with it. Or just state
that you can’t backup modern Linux servers with it, and let them
struggle with Windows servers if they really decide to use this instead.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “A handshake with whitnesses is the same
  `- as a signed contact.”  -- Jörg Schilling


--
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/1275063080.4783.14.ca...@meh

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread Roger Leigh

On Fri, May 28, 2010 at 06:11:20PM +0200, Josselin Mouette wrote:
 Le vendredi 28 mai 2010 à 10:45 -0400, Stephen Powell a écrit :
  Unfortunately, logical backups of a Linux machine using the extlinux
  boot loader do not work with our backup/restore software.  The master boot
  record and partition boot sector are restored correctly, but
  /boot/extlinux/extlinux.sys will probably not be restored to the exact
  same sectors from which it was backed up, and the restore software has no
  special logic to remedy that situation.  Therefore, after restore, the
  machine will not boot.  It *does* recognize lilo and has special logic
  to patch lilo after the restore so that the machine will boot.
 
 We have understood that your backup software is broken. It’s not the
 only one. There’s nothing we can do to fix broken, proprietary backup
 software.

One obvious solution not already mentioned is to back up the bootloader
*in Linux* as a normal file, so the backup software can then just back
it up like any other file.  It's a simple enough workaround to the
deficiencies in your backup software.

dd if=dev/hda of=/boot/bootsector-backup bs=512 count=nnn

Stick it in as a daily cron job and you're done.  When it comes to
restoring, you can just dd it back and you're in business.

 As a personal advice, I would recommend you to stop bothering with that
 broken backup software, it doesn’t seem good for your health. Set up a
 CIFS share on a backed-up Windows server, copy your data there using one
 of the numerous solutions in Debian, and get done with it. Or just state
 that you can’t backup modern Linux servers with it, and let them
 struggle with Windows servers if they really decide to use this instead.

Very true.  The same software is likely also broken with GPT
partition tables, BSD partition tables etc., so it's not like it's
just grub at fault here!  For the most part, grub is a vast
improvement over LILO, and except for the odd corner cases which
grub doesn't cover, grub is a much better choice if you have the
choice.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread Stephen Powell

From now on I will post on this thread only to debian-user, since
it appears that the debian-devel and debian-boot lists are tired
of hearing about it.

On Fri, 28 May 2010 12:39:00 -0400 (EDT), Roger Leigh wrote:
 On Fri, May 28, 2010 at 06:11:20PM +0200, Josselin Mouette wrote:
 On Fri, May 28, 2010 at 10:45AM -0400, Stephen Powell wrote::
 Unfortunately, logical backups of a Linux machine using the extlinux
 boot loader do not work with our backup/restore software.  The master boot
 record and partition boot sector are restored correctly, but
 /boot/extlinux/extlinux.sys will probably not be restored to the exact
 same sectors from which it was backed up, and the restore software has no
 special logic to remedy that situation.  Therefore, after restore, the
 machine will not boot.  It *does* recognize lilo and has special logic
 to patch lilo after the restore so that the machine will boot.
 
 We have understood that your backup software is broken. It’s not the
 only one. There’s nothing we can do to fix broken, proprietary backup
 software.
 

I understand that.

 One obvious solution not already mentioned is to back up the bootloader
 *in Linux* as a normal file, so the backup software can then just back
 it up like any other file.  It's a simple enough workaround to the
 deficiencies in your backup software.
 
 dd if=dev/hda of=/boot/bootsector-backup bs=512 count=nnn
 
 Stick it in as a daily cron job and you're done.  When it comes to
 restoring, you can just dd it back and you're in business.

I think you're missing the point.  Let's say that a hard drive fails
on a production server.  A technician, who may not be Linux
literate, replaces the failed hard drive and then restores the server
from the saved backup image.  Upon restoring from the backup, the server
will not boot.  That's the problem.  I can boot a rescue CD and repair
the damaged boot loader, but the goal is to have the restored system
boot with no subsequent intervention, just as it does for a Windows
server.

 
 As a personal advice, I would recommend you to stop bothering with that
 broken backup software, it doesn’t seem good for your health. Set up a
 CIFS share on a backed-up Windows server, copy your data there using one
 of the numerous solutions in Debian, and get done with it. Or just state
 that you can’t backup modern Linux servers with it, and let them
 struggle with Windows servers if they really decide to use this instead.

 Very true.  The same software is likely also broken with GPT
 partition tables, BSD partition tables etc., so it's not like it's
 just grub at fault here!  For the most part, grub is a vast
 improvement over LILO, and except for the odd corner cases which
 grub doesn't cover, grub is a much better choice if you have the
 choice.

We are aware of the deficiencies of our backup software and we are looking
at possible alternatives.  Who knows, maybe I'll even have some input
into a possible replacement.  (But I'm not holding my breath.)  Until
that happens, however, I have to live withing its restrictions.  On
my home computers, I can run whatever I want.  But at work, I am
stuck with these restrictions for now.

-- 
  .''`. 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/396446454.134310.1275068497347.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread Stan Hoeppner

Stephen Powell put forth on 5/28/2010 9:45 AM:

 The problem can be circumvented by taking an image backup
 instead of a logical backup, but that gets into special backup
 requirements.

Can you mix and match?  Does the image backup grab the entire disk or does it
work at the partition level?  Can you, say, do an image backup of the MBR and
boot sector and the /boot partition, and then use file backup on the rest of
the disk.

What backup software are you using that can take an image backup of a Linux
boot disk?  Does it install a local agent for this?  Or are you booting from
SAN?  If so, you should have all kinds of backup flexibility, depending on
whose storage arrays you use.

-- 
Stan


-- 
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/4c006d29.7070...@hardwarefreak.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread Stan Hoeppner

Roger Leigh put forth on 5/28/2010 11:39 AM:

 For the most part, grub is a vast
 improvement over LILO, and except for the odd corner cases which
 grub doesn't cover, 

In what way is it a vast improvement over LILO?  I've never had a problem with
LILO.  It's always just worked, which is what a bootloader should do.  So
how exactly would grub be a better choice for me?

 grub is a much better choice if you have the
 choice.

What choice?  Apparently the Debian team have decided there will be no
bootloader choice when Squeeze becomes Stable.  Supposedly at that point it's
Grub2 or your system no longer boots.  That's not much of a choice is it?

-- 
Stan


-- 
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/4c007303.1000...@hardwarefreak.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread thib


Stan Hoeppner wrote:

In what way is it a vast improvement over LILO?  I've never had a problem with
LILO.  It's always just worked, which is what a bootloader should do.  So
how exactly would grub be a better choice for me?


Nobody should be arguing that it's a better choice for someone who doesn't 
*need* it, but it's certainly modular and possibly can make itself tiny 
enough for people without special requirements (about the second sector, 
usually).  Since there's few alternatives however, it should at least be 
considered by everyone.



[snip]

What choice?  Apparently the Debian team have decided there will be no
bootloader choice when Squeeze becomes Stable.  Supposedly at that point it's
Grub2 or your system no longer boots.  That's not much of a choice is it?


Since lilo is/will be incompatible with Debian stock kernels, I think 
there's no point in providing it in a standard d-i.


Now of course, we can still reasonably argue about two things:

  * Should it still be available and maintained in the official archive? 
This would mean adding big flashy debconf warnings stating that it's not 
compatible with a stock kernel.  It's about newbies confusion and time spent 
maintaining an obsolete piece of software (sorry if sounds bad, but it 
really looks like it is, considering its development).  I certainly hope 
it's a reasonable possibility.


  * If yes, should it still be presented as an expert option in d-i?  Why 
not, I guess.  If not, should extlinux be extensively tested to be provided 
as an alternative choice in d-i?  I really don't know how much work would be 
needed for this.


-thib


--
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/4c007f92@stammed.net

Re: lilo removal in squeeze (or, please test grub2)

2010-05-28 Thread Tom H

On Fri, May 28, 2010 at 9:50 PM, Stan Hoeppner s...@hardwarefreak.com wrote:
 Roger Leigh put forth on 5/28/2010 11:39 AM:

 For the most part, grub is a vast
 improvement over LILO, and except for the odd corner cases which
 grub doesn't cover,

 In what way is it a vast improvement over LILO? I've never had a problem with
 LILO. It's always just worked, which is what a bootloader should do. So
 how exactly would grub be a better choice for me?

The reverse argument can be made too. Both grub1 and grub2 just work.
Unless you are continually installing dual- and triple-boot this or
that, you are not going to be changing you config continually no
matter what bootloader you use and you will therefore not be
interacting with it that much. So, except for Stephen P's case, what's
the big deal?


 grub is a much better choice if you have the
 choice.

 What choice? Apparently the Debian team have decided there will be no
 bootloader choice when Squeeze becomes Stable. Supposedly at that point it's
 Grub2 or your system no longer boots. That's not much of a choice is it?

The lilo upstream devs have given up on lilo so blaming Debian is
unfair and irrational. If no DD wants to maintain lilo upstream
(whether because of increasing kernel size or lack of sexiness of
bootloader coding or whatever...), you can only hope that another
distribution's developer decides 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/aanlktimwezxhrktbedux_ufqq0o2mmiksdhtqqrhb...@mail.gmail.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-27 Thread Martin Buck

In gmane.linux.debian.devel.general Stephen Powell zlinux...@wowway.com wrote:
 But like lilo it stays out of unallocated (and therefore not backed up)
 sectors.  The boot block of extlinux is installed in the boot sector
 of a partition, and the second stage loader occupies a file within the
 partition.  It does not use the master boot record.  It relies on a
 master boot record program to chain load it from the partition boot
 sector.  (I use the mbr package for that.)

BTW, you can install grub exactly the same way. I usually do this because
I absolutely don't like the idea to install something as important as a
boot loader into unallocated sectors. Just do grub-install /dev/sda1
and Grub will adapt its installation procedure accordingly. It's a pity
that this isn't documented more prominently...

Martin


-- 
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/htl90g$hu...@dough.gmane.org

Re: lilo removal in squeeze (or, please test grub2)

2010-05-27 Thread Samuel Thibault

Stefan Monnier, le Thu 27 May 2010 00:58:14 -0400, a écrit :
   for much.  But I am opposed to the removal of lilo.
   Both grub-legacy and grub-pc use sectors on the hard disk outside
   of the master boot record (cylinder 0, head 0, sector 1).  In other
   words they use cylinder 0, head 0, sector 2 and possibly subsequent
   sectors on cylinder 0 head 0.
  Really?
  Yes.
 
 That sucks.
 
  and it sounds very odd: why would they do that when they can use
  sectors on specified partitions?
  Because the question is where?.
 
 Inside a file, like LILO does.
 
  The lilo approach is inside the filesystem, which can break.
  The grub approach is right after MBR, which needs room there.
 
 But you can install Grub in a partition (rather than the MBR), so how
 does it work then?

Grub1 could because it was small enough to fit in a well-known usable
area in the ext2fs filesystem, but grub2 can not any more.

  grub (legacy) can be installed in any partition. IIUC grub2 is limited to 
  being installed in the MBR.
  Due to the differing sizes, yes.
 
 Why does the size make any difference?

Because the availabnle well-known areas have limited size.

 At least for the Lilo-like technique, size is not an issue.

Yes, but the file moving in the filesystem is an issue.

Samuel


-- 
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/20100527081222.gb3...@const.famille.thibault.fr

Re: lilo removal in squeeze (or, please test grub2)

2010-05-27 Thread thib


Samuel Thibault wrote:

[snip]

Grub1 could because it was small enough to fit in a well-known usable
area in the ext2fs filesystem, but grub2 can not any more.


In the filesystem, you're sure?  I'm curious, what part?


 [snip]


-t


--
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/4bfe750d.6060...@stammed.net

Re: lilo removal in squeeze (or, please test grub2)

2010-05-27 Thread Ferenc Wagner

Samuel Thibault sthiba...@debian.org writes:

 Paul Vojta, le Thu 27 May 2010 00:47:14 +, a écrit :
 In article enjn8-64s...@gated-at.bofh.it,
 Ferenc Wagner  wf...@niif.hu wrote:

 Sorry, I don't trust in the future of LILO myself.  If there's anything
 which only LILO can do, I recommend you start complaining on the
 Syslinux and the Grub mailing lists.  I suppose it will be heard.
 
 Does either grub2 or syslinux allow for single-key booting?

 It is available in the experimental branch of grub2.

To quote upstream:

hpa: It's trivial to add support for it (just another MENU directive)

So if you really need it, it'll be in the next version.
And I assume that's why you asked, right? :)
-- 
Cheers,
Feri.


--
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/87vda9tnrx@tac.ki.iif.hu

Re: lilo removal in squeeze (or, please test grub2)

2010-05-27 Thread Praveen A

2010/5/26 Joachim Wiedorn ad_deb...@joonet.de:
 Harald Braumann ha...@unheit.net wrote on Tue, 25 May 2010:

 On simple standard system -- one disk, one kernel in /boot, no fancy
 stuff -- it works quite well.

 This is enough to use grub2 for new installing of Debian.

 On other systems it often breaks miserably. Updates leave my system
 unbootable every other time. One major problem are incompatible
 versions of the boot loader installed in the MBR and grub.cfg.

not strictly a grub2 issue, but os-prober creates unbootable menu's
when you have dual boot systems with same /boot.

Even during a new installation if the system already have another
GNU/Linux it will create unbootable entries for that. See #580736

Earlier with grub I remember these are correctly configured. Plus
without a single configuration file, it is much more difficult to get
it to work as you like.

Praveen
-- 
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
GPLv2 I know my rights; I want my phone call!
DRM What use is a phone call, if you are unable to speak?
(as seen on /.)


--
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/aanlktiki7z6_yww2eyduexw6vofd55aldmcu-2kdq...@mail.gmail.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-27 Thread consul tores

2010/5/26 thib t...@stammed.net:
 consul tores wrote:
 We have lost the posibility to install from disquette, we have to add
 an initrd, SElinux have been added by default because of Linus, Linus
 kernels define what to do, and ad infinitum.

 Linux is still extremely tweakable, and you are free to build the kernel
 whichever way you want to.  If you can't, maybe a specific distribution of
 it will fit your needs -- the fact that its default configuration doesn't
 [fit] doesn't necessarily mean Linus is evil, but that maybe the general
 needs of most people are shifting.  He doesn't have absolute power over
 everything.

Yes, Linux (kernel) is very tweakable, but normal users are not able
to compile their own kernel; i am more remembering when i could
install using 3 diskettes, and now i can not do it anymore.

If, we consider that the environment has changed; we have Red Hut,
Ubuntu and Suse; pushing to include every thing into the kernel, what
is the best for them, then we have a huge kernel; which is not the
best for older ordenators, but it is the best for newer boxes. As we
can see, Linus is been pushed to built a huger kernel.

If, Debian has a very tested own kernel (Hurd), it should be focused
to its users, who probably are using older hardware, and maybe are not
using non-free software. This is why, i think that having a Debian
kernel, the users could be covered against global decisions.

 Do you know how BSDs work? Have you try Hurd?

 Are you referring to the BSDs development model?  Anyway, progress on
 kfreebsd *is* impressive, and it indeed looks like it might become a very
 good alternative for Debian in the near future, but I wouldn't say the same
 for the Hurd.  It's actually very interesting, but currently lacks much
 needed traction.

No, not the development model; i am refering to the structure, a
monolitic base system, which is very small and stable.

Yes, i think in the same way, we need to test Hurd in an efective way.
it could help to manage the actual tendency to emulate Windows,
obtaning a sipler/efective/funtional OS. I could be wrong, but it
seems the most of us are prefering stability.

francisco
-- 
   Consultores Agropecuarios.
Administracion, Produccion, Capacitacion.


--
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/aanlktimygiy_1-bbtncku5rlrtwneiurdyub9mqoi...@mail.gmail.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-27 Thread Stefan Monnier

 If, we consider that the environment has changed; we have Red Hut,
 Ubuntu and Suse; pushing to include every thing into the kernel, what
 is the best for them, then we have a huge kernel; which is not the
 best for older ordenators, but it is the best for newer boxes.  As we
 can see, Linus is been pushed to built a huger kernel.

Actually, the Linux kernel has seen a lot of work done to make it
adaptable to small systems (think home-routers, embedded systems, cell
phones, ...).
It's just the desktop-distros that use big kitchen-sink kernels, because
that suits them better.


Stefan


-- 
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/jwvzkzk3jv2.fsf-monnier+gmane.linux.debian.u...@gnu.org

extlinux (was: Re: lilo removal in squeeze (or, please test grub2))

2010-05-26 Thread Bjørn Mork

Daniel Baumann dan...@debian.org writes:

 as of current git, you can now use EXTLINUX_UPDATE=false in
 /etc/default/extlinux to prevent having update-extlinux do anything.

That's the single feature I misseded.  Thanks.

Although it would be even better if it was possible to include some
fixed part in it, while keeping most of it auto updated.  I tested the
extlinux package after reading about it yesterday, and the missing
feature that immediately hit me was the ability to use a serial console.
This is of course as easy as with sys-/pxe-/mem-linux: just add 
serial 0 9600 0 or something similar to the config file.  But running
update-extlinux would remove it on every kernel upgrade. Anyway, I
understand that this issue is now solved.

It has puzzled me for a while that grub2 has been chosen over extlinux
as the default x86 bootloader, but didn't know until this discussion
came up that extlinux now was packaged separately from syslinux, with
the nice helper scripts. I guess we all know syslinux and pxelinux very
well from Linux installation procedures over the last 15 years (for
syslinux at least), and HPA has been an active upstream maintainer all
this time AFAIK.  This makes me very confident in extlinux.  While grub2
has already bitten me too much to be considered at all on the important
boxes...

Just comparing http://git.kernel.org/?p=boot/syslinux/syslinux.git with
http://bzr.savannah.gnu.org/r/grub/trunk/grub/ should IMHO give more
than enough information to choose extlinux over grub2

Thanks a lot for packaging extlinux!



Bjørn


-- 
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/87k4qrjbk2.fsf...@nemi.mork.no

Re: extlinux (was: Re: lilo removal in squeeze (or, please test grub2))

Bjørn Mork, le Wed 26 May 2010 10:45:49 +0200, a écrit :
 Just comparing http://git.kernel.org/?p=boot/syslinux/syslinux.git with
 http://bzr.savannah.gnu.org/r/grub/trunk/grub/ should IMHO give more
 than enough information to choose extlinux over grub2

I don't understand what you mean here.

Samuel


-- 
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/20100526085116.gw5...@const.bordeaux.inria.fr

Re: lilo removal in squeeze (or, please test grub2)

2010-05-26 Thread thib


consul tores wrote:

Could you say why?


I misunderstood you, or simply wasn't aware of the terminology, sorry.  I 
mistakenly thought you were suggesting the creation of an entirely new 
Debian kernel.



We have lost the posibility to install from disquette, we have to add
an initrd, SElinux have been added by default because of Linus, Linus
kernels define what to do, and ad infinitum.


Linux is still extremely tweakable, and you are free to build the kernel 
whichever way you want to.  If you can't, maybe a specific distribution of 
it will fit your needs -- the fact that its default configuration doesn't 
[fit] doesn't necessarily mean Linus is evil, but that maybe the general 
needs of most people are shifting.  He doesn't have absolute power over 
everything.


Beeing actually aware of what's going on there is also a must to understand 
the choices beeing taken.  I'm not strictly suggesting you aren't, but you 
must admit that going on a revolution because a full featured modern kernel 
*in its default configuration* won't fit a disquette lacks some sense.  They 
had their reasons to drop that feature.


I'm not sure you'd like to debate your other examples here, but to avoid any 
confusion:  no you don't *have* to use initrds -- complaints for using them 
by default even though you don't need them for your particular setup should 
go to the distributors, not Linus.  Not sure they would be valid though 
(they *are* necessary for many setups for technical reasons that don't have 
much to do with the kernel).



Do you know how BSDs work? Have you try Hurd?


Are you referring to the BSDs development model?  Anyway, progress on 
kfreebsd *is* impressive, and it indeed looks like it might become a very 
good alternative for Debian in the near future, but I wouldn't say the same 
for the Hurd.  It's actually very interesting, but currently lacks much 
needed traction.



Well you can see some reasons to built Debian kernels.


Absolutely, choice is always good.

-t


--
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/4bfd106a.8010...@stammed.net

Re: lilo removal in squeeze (or, please test grub2)

2010-05-26 Thread Stephen Powell

On Wed, 26 May 2010 00:23:04 -0400 (EDT), Daniel Baumann wrote:
 On 05/26/2010 03:36 AM, Stephen Powell wrote:
 ...
 That works for now; but if a package upgrade for extlinux is ever
 downloaded, I'm afraid that new versions of the hook scripts will
 be copied into these directories which are marked executable, and
 my hand-made configuration file will get wiped out.
 ...

 as of current git, you can now use EXTLINUX_UPDATE=false in
 /etc/default/extlinux to prevent having update-extlinux do anything.

That's good to know, thanks.  I'm looking forward to that feature
migrating into squeeze.

 Second, it is important that any script run as a hook script not
 produce any output at all to standard output.  I found that out the
 hard way when I was writing my own hook scripts for use with lilo.
 That's because they run under debconf, which has redirected standard
 output for its own purposes.  Thus, anything written to standard
 output is (1) never seen by the user and (2) has a good chance of
 messing up debconf, which is examining the output.  The invocation
 of update-extlinux should have a redirection on it to redirect
 output to standard error.  For example,
 
update-extlinux 2
 
 none of the hooks is doing this (initramfs-tools, grub, etc), might
 needs further convincing.

It is a little-known requirement, and often you can get away with it,
but not always.  I'm going from memory here, but I believe that
debconf redirects standard output, then calls the maintainer script
for the kernel, which calls the run-parts utility, which then calls
the hook script.  If the standard output produced by the hook script
matches something that debconf is looking for it can mess things up.

Sometimes the
failure will occur for one type of call, such as a purge, but not
for another type of call, such as a configure or a remove.  Manoj
Srivastava, author and Debian package maintainer of the kernel-package
package, mentions it in the man page for kernel-img.conf, and
I have personally been burned by it with one of my own hook scripts
that I wrote for use with lilo.  The hook script failed with a
non-zero return code, which caused the kernel installation process
to fail.  I could not figure out for the life of me what was wrong.
The script ran fine when invoked stand-alone, but not as a hook script.
Redirecting lilo output to standard error solved the problem.
It ran perfectly after that.  But even if the stuff written to
standard output does not mess up debconf, the user still won't
see it.  The safe (and informative) thing to do is for all hook
scripts to write all output to standard error.

-- 
  .''`. 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/375009335.66290.1274880285294.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-26 Thread Stefan Monnier

 for much.  But I am opposed to the removal of lilo.  Both grub-legacy and
 grub-pc use sectors on the hard disk outside of the master boot record
 (cylinder 0, head 0, sector 1).  In other words they use cylinder 0, head 0,
 sector 2 and possibly subsequent sectors on cylinder 0 head 0.

Really?  Never heard of it, and it sounds very odd: why would they do
that when they can (and do, AFAICT) use sectors on specified partitions?
Is that documented/discussed somewhere?


Stefan


-- 
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/jwvvdaa7cev.fsf-monnier+gmane.linux.debian.u...@gnu.org

Re: lilo removal in squeeze (or, please test grub2)

2010-05-26 Thread thib


Stefan Monnier wrote:

for much.  But I am opposed to the removal of lilo.  Both grub-legacy and
grub-pc use sectors on the hard disk outside of the master boot record
(cylinder 0, head 0, sector 1).  In other words they use cylinder 0, head 0,
sector 2 and possibly subsequent sectors on cylinder 0 head 0.


Really?  Never heard of it, and it sounds very odd: why would they do
that when they can (and do, AFAICT) use sectors on specified partitions?
Is that documented/discussed somewhere?


It is, yes.  At least I remember reading about it for grub1.  Actually you 
don't *have* to use that space, it's just that it's convenient to store an 
intermediary stage (called 1.5) there, which typically holds filesystem 
drivers.  The reason for this extra space is that traditionally, the first 
partition on a DOS partition table can only start at the second cylinder 
(correct me if I'm wrong), so boot loaders just used to use the remaining 
space from the first cylinder so they didn't have to ask anything to 
anybody, since it was always sufficient.


For grub1 at least, the 'install' command (not the same as the 
'grub-install' script) was well documented and allowed to tweak this by 
manually specifying an address for the next stage (be it 1.5 or directly 2) 
that you would allocate yourself with a partition just like you're 
suggesting (I think there is about zero tools helping you with this 
however).  Note that pointing to a stage2 file directly makes grub behave 
much like lilo;  you would put a filesystem on the partition and then you 
have tools to update the address in stage1 automatically when you upgrade.


Maybe someone can point to similar documentation for grub2, as I'd bet it 
still allows it.


So yes, the first cylinder situation is a mess, and silly backup software 
are not the only programs carelessly using the extra space in it without 
checking for bootloader stuff;  for example Windows stores information about 
its LDM thingy (Logical Disk Manager or Dynamic Disks, comparable to LVM 
and dmraid, but crappy) in there too, making dual-boot with software RAID a 
real PITA.  To be fair, there's never been an authority dictating that the 
space was reserved to boot loaders (AFAIK), so there's really no-one to blame.


Fortunately, GPT answers this with new conventions.  Each of these pieces of 
software can have their own partition and partition type and many already 
support it out of the box (grub2 included).  I think administrators should 
really consider GPT for their new setups now;  it has definitely more 
advantages than just allowing for big partitions, and it's darn simple 
(not sure how anybody could defend the I stick to what I know point here). 
 Note that this partition scheme doesn't need EFI hardware, it's entirely 
backward compatible with PC/BIOS systems (you can even have hybrid GUID/DOS 
partition tables if you're really stuck with crappy software).


-thib


--
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/4bfd754e.1050...@stammed.net

Re: lilo removal in squeeze (or, please test grub2)

2010-05-26 Thread Boyd Stephen Smith Jr.

On Wednesday 26 May 2010 13:23:44 Stefan Monnier wrote:
  for much.  But I am opposed to the removal of lilo.  Both grub-legacy and
  grub-pc use sectors on the hard disk outside of the master boot record
  (cylinder 0, head 0, sector 1).  In other words they use cylinder 0, head
  0, sector 2 and possibly subsequent sectors on cylinder 0 head 0.
 
 Really?  Never heard of it, and it sounds very odd: why would they do
 that when they can (and do, AFAICT) use sectors on specified partitions?
 Is that documented/discussed somewhere?

That's where the stage 1.5 is embedded, AFAIK.  Using sectors allocated to a 
partition would be extra bad -- not everything that consumes a block device 
avoids using the first so many bytes.  (XFS for one.)

If you know that the first part of a partition is not used by the file system 
on it (or LVM, or RAID, or whatever that consumes that block device), GRUB 1 
does support embedding the stage 1.5 in a partition.

GRUB's stage 1 is an MBR, and resides where it should.  GRUB's stage 1.5 is 
the code that understands the file system, and resides between the MBR and the 
first partition.  GRUB's Stage 2 does the menus, kernel/initrd loading, etc.  
It resides as a file on a file system.  That's my understanding how how GRUB 1 
works.

GRUB 2 is a different beast in some respects, but my understanding is that 
these stages still apply, conditionally.  Depending on the modules needed, the 
stage 1 may be able to load modules from the file system and boot directly.  
Failing that, a stage 1.5 is still used.  When using a DOS partition table, 
it is embedded between the table and the first partition; When using a GPT 
partition table, it is embedded in a dedicated partition--GPT uses the space 
between the table and the first partition.  The stage 1.5 is used to load 
modules from the file system.  In GRUB 2, there is no single stage 2; 
whatever modules are loaded from the file system fill that role.  I don't know 
if GRUB 2 still supports embedding the stage 1.5 at the beginning of a 
partition under a DOS partition table.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Re: lilo removal in squeeze (or, please test grub2)

2010-05-26 Thread Boyd Stephen Smith Jr.

On Wednesday 26 May 2010 14:23:58 thib wrote:
 I think
 administrators should really consider GPT for their new setups now;  it
 has definitely more advantages than just allowing for big partitions,
 and it's darn simple (not sure how anybody could defend the I stick to
 what I know point here). Note that this partition scheme doesn't need EFI
 hardware, it's entirely backward compatible with PC/BIOS systems 

I agree.  I think d-i onto an unpartitioned disk should probably use GPT by 
default.

 (you can
 even have hybrid GUID/DOS partition tables if you're really stuck with
 crappy software).

You do sacrifice one of your primary partitions to the GPT flag partition.  
If you have somehow gotten stuck with 3/4 OSes that only boot off of a primary 
partition, it may be quite difficult to move to GPT.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Re: lilo removal in squeeze (or, please test grub2)

Stefan Monnier, le Wed 26 May 2010 14:23:44 -0400, a écrit :
  for much.  But I am opposed to the removal of lilo.  Both grub-legacy and
  grub-pc use sectors on the hard disk outside of the master boot record
  (cylinder 0, head 0, sector 1).  In other words they use cylinder 0, head 0,
  sector 2 and possibly subsequent sectors on cylinder 0 head 0.
 
 Really?

Yes.

 Never heard of it,

It's called stage 1.5, which contains the code for the filesystem
support.

 and it sounds very odd: why would they do
 that when they can use sectors on specified partitions?

Because the question is where?.  The lilo approach is inside the
filesystem, which can break. The grub approach is right after MBR,
which needs room there.

Samuel


-- 
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/20100526223103.gd4...@const.famille.thibault.fr

Re: lilo removal in squeeze (or, please test grub2)

2010-05-26 Thread Frans Pop

On Thursday 27 May 2010, Samuel Thibault wrote:
 Because the question is where?.  The lilo approach is inside the
 filesystem, which can break. The grub approach is right after MBR,
 which needs room there.

grub (legacy) can be installed in any partition. IIUC grub2 is limited to 
being installed in the MBR. For me that's one of the major downsides of 
grub2 and one reason I still very much prefer grub.


-- 
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/201005270132.18407.elen...@planet.nl

Re: lilo removal in squeeze (or, please test grub2)

Frans Pop, le Thu 27 May 2010 01:32:17 +0200, a écrit :
 On Thursday 27 May 2010, Samuel Thibault wrote:
  Because the question is where?.  The lilo approach is inside the
  filesystem, which can break. The grub approach is right after MBR,
  which needs room there.
 
 grub (legacy) can be installed in any partition. IIUC grub2 is limited to 
 being installed in the MBR.

Due to the differing sizes, yes.

Samuel


-- 
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/20100527001659.gl4...@const.famille.thibault.fr

Re: lilo removal in squeeze (or, please test grub2)

Paul Vojta, le Thu 27 May 2010 00:47:14 +, a écrit :
 In article enjn8-64s...@gated-at.bofh.it,
 Ferenc Wagner  wf...@niif.hu wrote:
 
 Sorry, I don't trust in the future of LILO myself.  If there's anything
 which only LILO can do, I recommend you start complaining on the
 Syslinux and the Grub mailing lists.  I suppose it will be heard.
 
 Does either grub2 or syslinux allow for single-key booting?

It is available in the experimental branch of grub2.

Samuel


-- 
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/20100527013126.gr4...@const.famille.thibault.fr

Re: lilo removal in squeeze (or, please test grub2)

2010-05-25 Thread Harald Braumann

Hi,

On Sat, May 22, 2010 at 10:39:52PM -0500, William Pitcock wrote:
 (4) Users need to test grub2 now.

I've been using grub2 for quite some time now on several different
systems with mixed success.

On simple standard system -- one disk, one kernel in /boot, no fancy
stuff -- it works quite well.

On other systems it often breaks miserably. Updates leave my system
unbootable every other time. One major problem are incompatible
versions of the boot loader installed in the MBR and grub.cfg.

Currently, automatic installation of grub in the MBR is a no-go for me,
because of #554790 but I can't prevent grub from automatically
updating grub.cfg which leads to incompatible versions, hence an
unbootable system. 

On some systems the generated grub.cfg is useless for me. On each
update I have to check for changes and incorporate them in my own
hand-edited version.

It is my belief, that the whole automagic configuration system as it
is now is far to complex and convoluted. It is too inflexible to
support any requirements by the user the developers haven't thought
about and in this case you have to work actively against the system to
get what you want. See #578576. I'm not sure if this can be fixed or
if the whole system has to be rethought. Currently I'd tend to the
latter.

And because of the tight dependency between the loader and grub.cfg
and zero-tolerance of the loader to unknown parameters in grub.cfg, it
is far too fragile and very easily leads to an unbootable system.

Because of this, coupled with the many open bugs and the lack of
documentation, I'm not sure if grub2 is ready to be released to the
unsuspecting public.

Cheers,
harry



-- 
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/20100525090027.ga30...@sbs288.lan

Re: lilo removal in squeeze (or, please test grub2)

2010-05-25 Thread Mihamina Rakotomandimby

 William Pitcock neno...@dereferenced.org :
This bug *can* be fixed, but not without a significant rewrite of the
way that lilo's stage2 loader code works.  Given that there is no
active upstream and that the Debian lilo package carries many patches
for bug fixes that are alleviated by standardizing on grub2, this
seems like the best option for Debian.

Agreed: dead (and buggy) softwares must be out of the distribution.
Whatever happens. If LILO regains upstream coders, its return to the
distribution is quite easy.

-- 
   Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche  Developpement
 +261 3456 000 19


-- 
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/20100525140820.0bc36...@pbmiha.malagasy.com

Re: lilo removal in squeeze (or, please test grub2)

Ferenc Wagner wrote:
 Stephen Powell zlinux...@wowway.com writes:

 Both grub-legacy and grub-pc use sectors on the hard disk outside of
 the master boot record and outside of a partition ...

 You may want to try extlinux, it works much like LILO in this respect.

Well, I tried extlinux last night, and I am hopeful that this is going
to be a solution, at least for me.  extlinux seems to combine the best
parts of grub-pc and lilo.  Like grub-pc, extlinux understands the file
system, and can read the configuration file, kernel, and the initial
RAM file system image from the file system without needing a list of
specific blocks to read.  Thus, the boot loader does not need to be re-run
every time a kernel is installed or updated or an initial RAM file system
image is installed or updated.  The number of file systems it supports
is limited, but that's OK.  A separate /boot partition of the file system
type supported by the boot loader is acceptable.

But like lilo it stays out of unallocated (and therefore not backed up)
sectors.  The boot block of extlinux is installed in the boot sector
of a partition, and the second stage loader occupies a file within the
partition.  It does not use the master boot record.  It relies on a
master boot record program to chain load it from the partition boot
sector.  (I use the mbr package for that.)  It *does* support the
specification of an initial text video mode (vga option), though this
is not specifically documented.

Speaking of documentation, that seems to be its main weakness.
Documentation is sketchy and spread out over a number of different files.
I would have had a hard time configuring it if it weren't for
correct guesses based on my knowledge of how lilo is configured, which
newer users won't have.  It installs hook scripts that I don't want
(and that have bugs).  But after manual configuration and tweaking,
it works just fine.  Now, if it passes the backup / low-level-format /
restore test, I'll be good to go.  Stay tuned ...

-- 
  .''`. 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/1078928757.35141.1274793733671.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

On Tue, 25 May 2010 07:08:20 -0400 (EDT), Mihamina Rakotomandimby wrote:
 William Pitcock neno...@dereferenced.org wrote:
 This bug *can* be fixed, but not without a significant rewrite of the
 way that lilo's stage2 loader code works.  Given that there is no
 active upstream and that the Debian lilo package carries many patches
 for bug fixes that are alleviated by standardizing on grub2, this
 seems like the best option for Debian.
 
 Agreed: dead (and buggy) softwares must be out of the distribution.
 Whatever happens. If LILO regains upstream coders, its return to the
 distribution is quite easy.

By that standard, grub-pc should be removed from the distribution.
It may have upstream support, but based on other posts I've seen, it
effectively has no maintainer.  Which is worse, a package with
effectively no upstream support or a package with effectively no
maintainer?  And grub-pc is buggier than lilo.

I understand the need to remove packages with no upstream support.
But asking users to test a package with umpteen known release-critical
bugs, most of which have apparently been fixed upstream, but have
not been fixed in Debian because there is no maintainer to download
a new upstream version, is not a reasonable request in my humble
opinion.  Get a maintainer for it, fix the known bugs, and *then*
ask the users to test it.

-- 
  .''`. 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/1927842586.35924.1274795074336.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-25 Thread Ferenc Wagner

Stephen Powell zlinux...@wowway.com writes:

 Ferenc Wagner wrote:

 Stephen Powell zlinux...@wowway.com writes:

 Both grub-legacy and grub-pc use sectors on the hard disk outside of
 the master boot record and outside of a partition ...

 You may want to try extlinux, it works much like LILO in this respect.

 It does not use the master boot record.  It relies on a master boot
 record program to chain load it from the partition boot sector.  (I
 use the mbr package for that.)

The extlinux package itself also contains an mbr.bin, which you can use
(it's strong point is probably EBIOS support).

 Speaking of documentation, that seems to be its main weakness.
 Documentation is sketchy and spread out over a number of different files.

/usr/share/doc/extlinux.txt.gz references syslinux.txt, which is fairly
comprehensive according to my standards, at least as far as the core is
concerned.  What did you miss?  Some modules may be less well documented.

 It installs hook scripts that I don't want (and that have bugs).

I hope we can fix them soon (they are Debian specific additions).
-- 
Cheers,
Feri.


-- 
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/874ohwt3td@tac.ki.iif.hu

Re: Re (2): lilo removal in squeeze (or, please test grub2)

On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
 Stephen Powell wrote:
 (3) The need for special backup requirements will be 
 used by the opponents of Linux at my place of employment 
 to oppose further deployments of Linux, ...
 
 What about the carrot approach?  Find an even better 
 backup method, compatible with Grub 2 and appealing 
 to your management for its efficiency.

You're missing the point.  The main selling point to management
is that Linux is free.  If they have to buy new backup software
in order to accommodate Linux' backup requirements, that will
kill it on the spot.  Whatever boot loader I use must not
require new backup software or impose special backup requirements.
And its not just money.  As a rule, people like what they know.
The backup people are Windows people, and they'd love an
excuse to complain to management about the backup requirements
of my Linux servers.  grub-legacy and grub-pc are non-starters
for me for that reason.  Until now, only lilo, as far as I knew,
met all my requirements.  It now appears that extlinux may also
work.  I'll soon know.

-- 
  .''`. 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/351821928.39974.1274802154546.javamail.r...@md01.wow.synacor.com

Re: Re (2): lilo removal in squeeze (or, please test grub2)

2010-05-25 Thread Mark

On Tue, May 25, 2010 at 8:42 AM, Stephen Powell zlinux...@wowway.comwrote:

 On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
  Stephen Powell wrote:
  (3) The need for special backup requirements will be
  used by the opponents of Linux at my place of employment
  to oppose further deployments of Linux, ...
 
  What about the carrot approach?  Find an even better
  backup method, compatible with Grub 2 and appealing
  to your management for its efficiency.

 You're missing the point.  The main selling point to management
 is that Linux is free.  If they have to buy new backup software
 in order to accommodate Linux' backup requirements, that will
 kill it on the spot.  Whatever boot loader I use must not
 require new backup software or impose special backup requirements.
 And its not just money.  As a rule, people like what they know.
 The backup people are Windows people, and they'd love an
 excuse to complain to management about the backup requirements
 of my Linux servers.  grub-legacy and grub-pc are non-starters
 for me for that reason.  Until now, only lilo, as far as I knew,
 met all my requirements.  It now appears that extlinux may also
 work.  I'll soon know.


Clonezilla is free, and when using the saveparts option to save an image
of one partition and not the full hard drive, it includes the MBR and
associated data.  You can then drop that partition image onto a new/blank
disk, that does not have anything in the MBR, and once Clonezilla restores
the image to the new partition, will put the MBR in place and the machine
boots on its own the next time, with no extra work (I just did this last
week with a new hard drive).  This has been my experience with using
Clonezilla and Lenny, at least.  So it may help in your case.

Mark

Re: Re (2): lilo removal in squeeze (or, please test grub2)

2010-05-25 Thread Boyd Stephen Smith Jr.

On Tuesday 25 May 2010 10:42:34 Stephen Powell wrote:
 On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
  Stephen Powell wrote:
  (3) The need for special backup requirements will be
  used by the opponents of Linux at my place of employment
  to oppose further deployments of Linux, ...
  
  What about the carrot approach?  Find an even better
  backup method, compatible with Grub 2 and appealing
  to your management for its efficiency.
 
 You're missing the point.  The main selling point to management
 is that Linux is free.

No software is entirely without cost.  Free Software is no exception.  There 
are usually no up-front licening fees, sure.  However, volunteers work on 
whatever they like, and if no one volunteers to maintain and support your 
software you may have to pay for that.

Even with volunteers providing maintenance and support, your specific 
requirements may differ from their goals and that will require effort to 
resolve.

 If they have to buy new backup software
 in order to accommodate Linux' backup requirements, that will
 kill it on the spot.  Whatever boot loader I use must not
 require new backup software or impose special backup requirements.
 And its not just money.  As a rule, people like what they know.

If money is the issue, move to a free backup solution.  Amanda and Zmanda both 
support backing up a number of OSes, including Linux and Windows and are free 
software, last I checked.

You've already proven free solutions in your own servers.  Moving to a free 
solution for backups is a next logical step.

Also, volunteers are rarely concerned with market share, losing your 
management as users is not necessarily a concern to them.  If it is a concern 
for you, you may have to put forward some additional effort to address your 
management's issues.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Re: Re (2): lilo removal in squeeze (or, please test grub2)

On Tue, 25 May 2010 11:51:11 -0400 (EDT), Mark mamar...@gmail.com
 On Tue, May 25, 2010 at 8:42 AM, Stephen Powell zlinux...@wowway.comwrote:
 On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
 Stephen Powell wrote:
 (3) The need for special backup requirements will be
 used by the opponents of Linux at my place of employment
 to oppose further deployments of Linux, ...

 What about the carrot approach?  Find an even better
 backup method, compatible with Grub 2 and appealing
 to your management for its efficiency.

 You're missing the point.  The main selling point to management
 is that Linux is free.  ...

 Clonezilla is free, and when using the saveparts option to save an image
 of one partition and not the full hard drive, it includes the MBR and
 associated data.  You can then drop that partition image onto a new/blank
 disk, that does not have anything in the MBR, and once Clonezilla restores
 the image to the new partition, will put the MBR in place and the machine
 boots on its own the next time, with no extra work (I just did this last
 week with a new hard drive).  This has been my experience with using
 Clonezilla and Lenny, at least.  So it may help in your case.

Perhaps so.  But it's not what the backup people know.  They're very
comfortable with the backup software that they know and love for
backing up their Windows servers, which was purchased with Windows servers
in mind.  Do you think they're going to redo their whole backup architecture
just for a few Linux servers?  If I want to play in their sandbox, I have
to play by their rules.  That's the political reality.  At our shop, Linux
has a small beachhead on a vast continent controlled by Windows.  Over time,
the role of Linux may expand to the point where Linux is actually thought
about and planned for when decisions are made.  But that day is not today.

-- 
  .''`. 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/479605722.42620.1274806845480.javamail.r...@md01.wow.synacor.com

Re: Re (2): lilo removal in squeeze (or, please test grub2)

On Tue, 25 May 2010 12:03:17 -0400 (EDT), Boyd Stephen Smith Jr. wrote:
 Stephen Powell wrote:
 
 You're missing the point.  The main selling point to management
 is that Linux is free.
 
 No software is entirely without cost.  Free Software is no exception.  There 
 are usually no up-front licening fees, sure.  However, volunteers work on 
 whatever they like, and if no one volunteers to maintain and support your 
 software you may have to pay for that.
 
 Even with volunteers providing maintenance and support, your specific 
 requirements may differ from their goals and that will require effort to 
 resolve.
 ...
 Also, volunteers are rarely concerned with market share, losing your 
 management as users is not necessarily a concern to them.  If it is a concern 
 for you, you may have to put forward some additional effort to address your 
 management's issues.

All excellent points, Boyd.  Fortunately in this case, extlinux appears
to be a viable solution.  I'll soon know.  The guy I need to see about
setting a test server to test the backup and restore scenario
has been off work with a sick child for the past couple of days, but when
he gets back I'll try to prove that it is 100% compatible with our
backup software.

-- 
  .''`. 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/1557806589.43087.1274807547943.javamail.r...@md01.wow.synacor.com

Re: Re (2): lilo removal in squeeze (or, please test grub2)

2010-05-25 Thread consul tores

2010/5/24  peasth...@shaw.ca:
 From:   consul tores consultore...@gmail.c..
 Date:   Mon, 24 May 2010 15:32:49 -0700
 Again, and again; Debian depends of Linus Torvals;

 For curiosity, what distribution does he use?

I am not sure, but i read somewhere, that he usualy used Red Hut.

 maybe it is time to seriously think about Debian kernels!

 The Hurd?

Yes, we have it at hand, and it probably needs hard testing;but i
think that having Debian kernels, could be very easy keeping Debian
simple for every one. We all could understand how Debian really works
beeing part of it.

 Regards,         ... Peter E.

-- 
   Consultores Agropecuarios.
Administracion, Produccion, Capacitacion.

--
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/aanlktinm15o5liyinsa8s5d_cowzarpah4bmgtkzz...@mail.gmail.com

Re: lilo removal in squeeze (or, please test grub2)

2010-05-25 Thread Joachim Wiedorn

Harald Braumann ha...@unheit.net wrote on Tue, 25 May 2010:
 
 On simple standard system -- one disk, one kernel in /boot, no fancy
 stuff -- it works quite well.

This is enough to use grub2 for new installing of Debian.

 On other systems it often breaks miserably. Updates leave my system
 unbootable every other time. One major problem are incompatible
 versions of the boot loader installed in the MBR and grub.cfg.
 
 Currently, automatic installation of grub in the MBR is a no-go for me,
 because of #554790 but I can't prevent grub from automatically
 updating grub.cfg which leads to incompatible versions, hence an
 unbootable system. 

And these problems say, we still need an alternative - I would say: LiLO.

William Pitcock neno...@dereferenced.org wrote on Sat, 22 May 2010:
 
 After some discussion about lilo on #debian-devel in IRC, it has pretty
 much been determined that kernel sizes have crossed the line past where
 lilo can reliably determine the payload size.

But not all kernels are to large - especially the custom kernels - and
LiLO can be used for this special situation. Until which size of kernel 
is LiLO usable?

My suggestion / recommendation is now:

  a) using grub2 as default boot manager for new installations (d-i)
 and for updating grub.

  b) provide LiLO in squeeze as alternative for grub2. The
 limitations must be said while installing the lilo package.
 I think it must not be a proposal in d-i.

Because I still use LiLO for all my systems, I could support the
maintaining of LiLO. Would this a way for you, William?

Fondest regards,
 Joachim Wiedorn



signature.asc
Description: PGP signature

Re: lilo removal in squeeze (or, please test grub2)

2010-05-25 Thread Stan Hoeppner

Joachim Wiedorn put forth on 5/25/2010 2:37 PM:

 Because I still use LiLO for all my systems, I could support the
 maintaining of LiLO.

Same here.  The last thing I need is for my next distribution upgrade to try
to forcibly remove LILO and the current MBR, and then install Grub2, bricking
my servers in the process.  Or, just as bad, leaving the MBR in tact, but
removing LILO from the system, and thus giving me no way of installing a new
kernel down the road without manually installing/configuring Grub2, which I
have zero experience with, and no guarantee such a process would work.

It all boils down to this:  In my environment, LILO works very well, is not
broken, nor will it be broken in any foreseeable future due to kernel size.  I
use small custom kernels, no initrd, only the drivers built in for the
specific hardware in the box.

If someone can guarantee me that a dist upgrade process where LILO gets
replaced by Grub2 is seamless, and won't brick my systems under any
circumstances, then I might have an open mind on this.  As things stand now,
from everything I've read, I fear replacing LILO with Grub2 during an upgrade.

-- 
Stan


-- 
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/4bfc5659.1030...@hardwarefreak.com

Re: Re (2): lilo removal in squeeze (or, please test grub2)

2010-05-25 Thread owens

 Original Message 
From: zlinux...@wowway.com
To: debian-de...@lists.debian.org, debian-user@lists.debian.org,
debian-b...@lists.debian.org
Subject: Re: Re (2): lilo removal in squeeze (or, please test
grub2)
Date: Tue, 25 May 2010 13:00:45 -0400 (EDT)

On Tue, 25 May 2010 11:51:11 -0400 (EDT), Mark mamar...@gmail.com
 On Tue, May 25, 2010 at 8:42 AM, Stephen Powell
zlinux...@wowway.comwrote:
 On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote:
 Stephen Powell wrote:
 (3) The need for special backup requirements will be
 used by the opponents of Linux at my place of employment
 to oppose further deployments of Linux, ...

 What about the carrot approach?  Find an even better
 backup method, compatible with Grub 2 and appealing
 to your management for its efficiency.

 You're missing the point.  The main selling point to management
 is that Linux is free.  ...

 Clonezilla is free, and when using the saveparts option to save
an image
 of one partition and not the full hard drive, it includes the MBR
and
 associated data.  You can then drop that partition image onto a
new/blank
 disk, that does not have anything in the MBR, and once Clonezilla
restores
 the image to the new partition, will put the MBR in place and the
machine
 boots on its own the next time, with no extra work (I just did
this last
 week with a new hard drive).  This has been my experience with
using
 Clonezilla and Lenny, at least.  So it may help in your case.

Perhaps so.  But it's not what the backup people know.  They're very
comfortable with the backup software that they know and love for
backing up their Windows servers, which was purchased with Windows
servers
in mind.  Do you think they're going to redo their whole backup
architecture
just for a few Linux servers?  If I want to play in their sandbox, I
have
to play by their rules.  That's the political reality.  At our shop,
Linux
has a small beachhead on a vast continent controlled by Windows. 
Over time,
the role of Linux may expand to the point where Linux is actually
thought
about and planned for when decisions are made.  But that day is not
today.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

+1
I have been where Steven is and agree with his approach.
Larry
-- 
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/479605722.42620.1274806845480.JavaM
ail.r...@md01.wow.synacor.com

--
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/380-220105225234210...@netptc.net

Re: lilo removal in squeeze (or, please test grub2)