[lug] problem compiling Ubuntu kernel

[Bear Giles]

In the past I've put /, /boot and /var/log on one disk and /home and the
server directories on a second disk.  I could then physically swap out the
system.  In fact that's what I did yesterday since I installed 9.10 on an
old 40GB disk and will keep the other disk around for the other partitions.
I just haven't bothered recently since I was tracking Debian's 'testing'
distro prior to making the jump to Ubuntu.

Bear


On Mon, Jan 25, 2010 at 7:54 AM, Davide Del Vento <
davide.del.vento at gmail.com> wrote:

> Since you are reinstalling, let me give you my 0.02cent.
> I always install from scratch, and I mean always. Updates sometimes
> work, but when they don't it's much more painful, as you have
> experienced here. I do the "install-from-scratch" without overwriting
> the old system, so If anything goes wrong with the new, I can always
> boot the old and be 100% productive.
>
> So my recommendation is to plan ahead and use a partition scheme that
> would make a full install easy in future. In my case that simply means
> having a separate / and /home, plus something that I call /old. When I
> install a new release, I install it on /old, which in the new
> installation is becomes / (and the "old" / becomes /old). Probably
> you'll need something more complex, but I'm sure you can figure that
> our yourself. Note: I also be sure that the new installation does not
> (over)writes in the "old" directories in /home, so I start with some
> test usernames different from the "old" ones. Only when everything is
> working fine, sometimes I allow the new installation to write into the
> old homes (but some other times, I even decide that it's not worth
> this risk, and I copy the settings and data by hand: slower, but more
> control, less things that goes wrong and if any does easier to figure
> out what it is).
>
> You might see the slowness of this manual few-steps-at-a-time approach
> as a drawback. It's not: the old installation is always just a reboot
> away (yes, I can screw up the bootloader, but that's easy to fix with
> a live disk from the old distro that I keep it handy from the
> beginning of this "update"). And hopefully the old system was working
> fine when I started, so there is no need to rush. And if I don't rush,
> it's less likely that I make mistakes or try risky shortcuts "becase
> it's late and I need this machine to be productive in half hour": the
> machine is productive right now, if it's really needed by somebody.
> With this workflow, a distro with very long overlap among subsequent
> releases is highly desirable (mine is Ubuntu LTS), so there is even
> another less reason to rush (the old distro will be supported for
> months, no need to fix the new one this week, I can go to the beach
> and relax as scheduled)
>
> And yes, this approach require more disk space, but not much more
> (most of my space is eaten by /home anyway), and in any case disk
> space is very cheap today.
>
> Hope this help you in future.
> ;Dav
>
> On Sun, Jan 24, 2010 at 11:03, bgiles <bgiles at coyotesong.com> wrote:
> > Thanks for the help everyone but I'm calling the disk unrecoverable.  It
> > doesn't make sense to keep putting effort into this when there's
> > multiple problems and I can just reinstall the latest distro from
> > scratch.  Reconfiguring the servers is a pain but will still only take a
> > few hours.
> >
> > Bear
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
> >
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20100125/e16d81cb/attachment.html>