Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #161932 > unrolled thread

Attempt to Move Root

Back to article view | Back to linux.debian.user

Contents

  Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-20 12:10 +0100
    Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-20 19:20 +0100
      Re: Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-20 22:00 +0100
        Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-20 22:40 +0100
    Re: Attempt to Move Root David Christensen <dpchrist@holgerdanske.com> - 2015-12-21 10:00 +0100
      Re: Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-21 11:00 +0100
        Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-21 16:30 +0100
          Re: Attempt to Move Root Lisi Reisz <lisi.reisz@gmail.com> - 2015-12-21 16:40 +0100
            Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-21 21:40 +0100
          Re: Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-21 16:40 +0100
            Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-21 21:00 +0100
              Re: Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-21 21:50 +0100
                Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-21 22:20 +0100
                  Re: Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-22 08:50 +0100
              Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-22 17:00 +0100
                Re: Attempt to Move Root John Hasler <jhasler@newsguy.com> - 2015-12-22 18:40 +0100
                  Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-22 18:40 +0100
                    Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-22 19:50 +0100
                      Re: Attempt to Move Root Sven Hartge <sven@svenhartge.de> - 2015-12-22 20:50 +0100
                        Re: Attempt to Move Root Brian <ad44@cityscape.co.uk> - 2015-12-22 21:20 +0100
                        Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-22 23:10 +0100
                          Re: Attempt to Move Root Sven Hartge <sven@svenhartge.de> - 2015-12-22 23:30 +0100
                            Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-23 10:40 +0100
                              Re: Attempt to Move Root Sven Hartge <sven@svenhartge.de> - 2015-12-24 02:20 +0100
                                Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-24 12:20 +0100
                              Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-12-27 14:10 +0100
                                Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-27 14:50 +0100
                                  Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-12-27 15:20 +0100
                                    Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-27 15:40 +0100
                                      Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-12-27 16:00 +0100
                                        Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-27 16:20 +0100
                                          Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-28 03:50 +0100
                                          Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-12-28 03:50 +0100
                                      Re: Attempt to Move Root Gene Heskett <gheskett@shentel.net> - 2015-12-27 16:10 +0100
                                        Re: Attempt to Move Root Petter Adsen <petter@synth.no> - 2016-01-01 10:20 +0100
                                          Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-01-01 11:40 +0100
                                Re: Attempt to Move Root Sven Hartge <sven@svenhartge.de> - 2015-12-28 03:50 +0100
                                  Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-12-28 03:50 +0100
                          Re: Attempt to Move Root Brian <ad44@cityscape.co.uk> - 2015-12-22 23:40 +0100
                        Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-25 17:10 +0100
                    Re: Attempt to Move Root John Hasler <jhasler@newsguy.com> - 2015-12-22 19:50 +0100
                      Re: Attempt to Move Root (SOLVED!!) David Baron <d_baron@012.net.il> - 2015-12-23 10:00 +0100
                        Re: Attempt to Move Root (SOLVED!!) Anders Andersson <pipatron@gmail.com> - 2015-12-23 12:50 +0100
                          Re: Attempt to Move Root (SOLVED!!) David Baron <d_baron@012.net.il> - 2015-12-23 13:20 +0100
                Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-25 16:40 +0100
                  Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-28 05:00 +0100
        Re: Attempt to Move Root David Christensen <dpchrist@holgerdanske.com> - 2015-12-21 20:00 +0100

Page 1 of 3  [1] 2 3  Next page →

#161932 — Attempt to Move Root

OK, mounted newrootpartition newroot
Did a cp -x /  newroot
Successful so far, elementary

Edited newroot/etc/fstab and newroot/etc/lilo.conf to point root to 
newrootpartition (by uuid)

mount --bind /dev newroot/dev
mount --bind /proc newroot/proc
as instructed in various posts, to enable lilo to run.

chroot newroot
lilo ...

Looked successful. Umounted everything and reboot.

Get boot menu (congratulations !?).
Chose the kernel.

Now got that lvm not ready business.. I usually get this once and then 
normally boot up. Now getting it over and again. BTW, if I control/C a few 
times, I end up inside initramfs>.

Put up the live DVD, regenerated the initramfs, but ... no change.
Put up the live DVD, mounted the old root partition,  went through the lilo 
process and back up.

So ... how do I do this??

[toc] | [next] | [standalone]

#161948

On Sun, 20 Dec 2015 05:58:47 -0500 (EST), David Baron wrote:
> 
> OK, mounted newrootpartition newroot
> Did a cp -x /  newroot
> Successful so far, elementary
> 
> Edited newroot/etc/fstab and newroot/etc/lilo.conf to point root to 
> newrootpartition (by uuid)
> 
> mount --bind /dev newroot/dev
> mount --bind /proc newroot/proc
> as instructed in various posts, to enable lilo to run.
> 
> chroot newroot
> lilo ...
> 
> Looked successful. Umounted everything and reboot.
> 
> Get boot menu (congratulations !?).
> Chose the kernel.
> 
> Now got that lvm not ready business.. I usually get this once and then 
> normally boot up. Now getting it over and again. BTW, if I control/C a few 
> times, I end up inside initramfs>.
> 
> Put up the live DVD, regenerated the initramfs, but ... no change.
> Put up the live DVD, mounted the old root partition,  went through the lilo 
> process and back up.
> 
> So ... how do I do this??

I have several thoughts.

First of all, the right way to copy the root filesystem under these conditions is

   cp -a -x /. newroot

That period after the forward slash is important!

Second, make sure that the initial RAM filesystem contains everything needed to
initialize a logical volume.  If you make a logical volume the root filesystem
in the Debian installer, the Debian installer *should* do whatever is necessary
to make sure that everything needed to mount a logical volume gets included
in the initial RAM filesystem.  I've never tried to do this, so I can't give you
a list of what files will be needed.  You can examine an existing inital RAM
filesystem to see what files are included by using lsinitramfs.

Third, although it is possible to make a logical volume the root filesystem,
/boot must not be part of this filesystem.  It must be a separate partition
on a physical volume.  (Furthermore, it must be a separate partition that is
accessible via the BIOS.)  The same goes for the boot sector.  (The "boot"
configuration record in /etc/lilo.conf.)  Usually, this is the first sector
on the /boot partition or else the master boot record.  And if it is not the
master boot record, then a generic MBR boot loader program must be installed
in the MBR and the /boot partition must be on that physical disk, and it must
be marked active in the partition table (and all other partitions marked inactive).
Finally, make sure that the BIOS is actually booting from this physical disk.

Although the specific subject of using an LVM2 logical volume as the root
filesystem is not specifically covered, you may find some useful lilo tidbits
on my lilo web page:

   http://www.stevesdebianstuff.org/lilo.htm

Finally, make sure that there are no duplicate UUIDs in the system that might
confuse the kernel during boot.

[toc] | [prev] | [next] | [standalone]

#161953

On Sunday 20 December 2015 13:18:09 Stephen Powell wrote:
> On Sun, 20 Dec 2015 05:58:47 -0500 (EST), David Baron wrote:
> > OK, mounted newrootpartition newroot
> > Did a cp -x /  newroot
> > Successful so far, elementary
> > 
> > Edited newroot/etc/fstab and newroot/etc/lilo.conf to point root to
> > newrootpartition (by uuid)
> > 
> > mount --bind /dev newroot/dev
> > mount --bind /proc newroot/proc
> > as instructed in various posts, to enable lilo to run.
> > 
> > chroot newroot
> > lilo ...
> > 
> > Looked successful. Umounted everything and reboot.
> > 
> > Get boot menu (congratulations !?).
> > Chose the kernel.
> > 
> > Now got that lvm not ready business.. I usually get this once and then
> > normally boot up. Now getting it over and again. BTW, if I control/C a few
> > times, I end up inside initramfs>.
> > 
> > Put up the live DVD, regenerated the initramfs, but ... no change.
> > Put up the live DVD, mounted the old root partition,  went through the
> > lilo
> > process and back up.
> > 
> > So ... how do I do this??
> 
> I have several thoughts.
> 
> First of all, the right way to copy the root filesystem under these
> conditions is
> 
>    cp -a -x /. newroot
> 
> That period after the forward slash is important!
> 
> Second, make sure that the initial RAM filesystem contains everything needed
> to initialize a logical volume.  If you make a logical volume the root
> filesystem in the Debian installer, the Debian installer *should* do
> whatever is necessary to make sure that everything needed to mount a
> logical volume gets included in the initial RAM filesystem.  I've never
> tried to do this, so I can't give you a list of what files will be needed. 
> You can examine an existing inital RAM filesystem to see what files are
> included by using lsinitramfs.
> 
> Third, although it is possible to make a logical volume the root filesystem,
> /boot must not be part of this filesystem.  It must be a separate partition
> on a physical volume.  (Furthermore, it must be a separate partition that
> is accessible via the BIOS.)  The same goes for the boot sector.  (The
> "boot" configuration record in /etc/lilo.conf.)  Usually, this is the first
> sector on the /boot partition or else the master boot record.  And if it is
> not the master boot record, then a generic MBR boot loader program must be
> installed in the MBR and the /boot partition must be on that physical disk,
> and it must be marked active in the partition table (and all other
> partitions marked inactive). Finally, make sure that the BIOS is actually
> booting from this physical disk.
> 
> Although the specific subject of using an LVM2 logical volume as the root
> filesystem is not specifically covered, you may find some useful lilo
> tidbits on my lilo web page:
> 
>    http://www.stevesdebianstuff.org/lilo.htm
> 
> Finally, make sure that there are no duplicate UUIDs in the system that
> might confuse the kernel during boot.

Thanks for the detailed explanation!

I am not now using logical volumes. (When I did in the past, boot was indeed 
separate.) Do not need the layer of complication and unless one is careful to 
leave unallocated areas, the whole thing becomes locked up anyway.
 
I did not know about the /. so will definitely try it this way.

The first time I did this, moving from the tiny partition to the old IDE 
partition, I did not do any of this. I did the copy, edited the files in situ 
(old root), ran lilo and it booted up. But ... the old root was still active 
because the newroot files were not the edited copies (i.e., old fstab). So 
once I fixed that, it simply played, no fuss, no muss.

So ... do I need the chroot and the binds and all this at all?

[toc] | [prev] | [next] | [standalone]

#161954

On Sun, 20 Dec 2015 15:51:22 -0500 (EST), David Baron wrote:
> 
> So ... do I need the chroot and the binds and all this at all?

That's the recommended way.  Make sure that the edited copies of
/etc/lilo.conf, /etc/fstab, and /etc/initramfs-tools/conf.d/resume,
in the chrooted environment, all make sense for the new setup,
especially the "boot" and "root" configuration file records in
/etc/lilo.conf.  /etc/initramfs-tools/conf.d/resume must specify
the UUID of the swap partition.

I have another web page that may be helpful to you.  It shows an
example of copying a root file system for a virtual machine running
under z/VM in the s390x environment.  That is not your situation,
of course; but portions of it are applicable to your environment.
You may be able to separate the wheat from the chaff and figure out
what applies to your situation and what doesn't.  Then again, it may
only confuse you.  So I give you the link with some hesitation.
The parts that apply are the copying of the file system(s), and
setting up the chroot environment.  I hope it does more good than
harm.  Here it is:

   http://www.stevesdebianstuff.org/diag250.htm
 
The s390x environment uses a boot loader called zIPL, not LILO; but
zIPL's design is similar to LILO in that it does not understand the
structure of a Linux file system.  It simply reads a predetermined
list of blocks from the file system at boot time.

Also note that /boot must not use the btrfs filesystem.  This is an
undocumented restriction for both zIPL and LILO.  I recommend ext2
for /boot.  (If the partition size is small enough, you pretty much have
to use ext2.  ext3 and ext4 require a journal, and that in turn requires
a certain minimum partition size.)  Good luck.

[toc] | [prev] | [next] | [standalone]

#161960

On 12/20/2015 02:58 AM, David Baron wrote:
> So ... how do I do this??

On 12/20/2015 03:36 AM, David Baron wrote:
 > my goal is to remove and older 80gig IDE disk from the system

Debian version?


What drive is root on?  How is the drive partitioned?  RAID?  LVM? LUKS? 
  Other?  What is the file system type?   How big?


Where do you want to move root?


What else is on the same drive as root?  Boot?  Swap?  Do you want to 
move these?  Where?


David

[toc] | [prev] | [next] | [standalone]

#161961

On Monday 21 December 2015 00:50:43 David Christensen wrote:
> On 12/20/2015 02:58 AM, David Baron wrote:
> > So ... how do I do this??
> 
> On 12/20/2015 03:36 AM, David Baron wrote:
>  > my goal is to remove and older 80gig IDE disk from the system
> 
> Debian version?
Sid
> 
> 
> What drive is root on?  How is the drive partitioned?  RAID?  LVM? LUKS?
>   Other?  What is the file system type?   How big?
Currently on partition of old IDE drive. Nothing  else remaining on this 
drive. Partition is 10gig
> 
> 
> Where do you want to move root?
To an available partition of similar size on the first SATA drive.
> 
> 
> What else is on the same drive as root?  Boot?  Swap?  Do you want to
> move these?  Where?
These are currently on first and second SATA drives, all set up and working.

> initramf-tools/conf.d/resume
This was NOT copied in the cp -x -a /. newroot!
So copied in manually. Points to current swap on 1st SATA.

Went through all the motions, both ways: On native and chroot. Results were 
the same. Get in that loop of lv not ready messages. Difference: Native 
attempt still needs the IDE plugged in or I get 99 99 99 ... , chroot does 
not.

So, what do I do next?

[toc] | [prev] | [next] | [standalone]

#161964

On Mon, 21 Dec 2015 04:50:00 -0500 (EST), David Baron wrote:
> 
> Went through all the motions, both ways: On native and chroot. Results were 
> the same.  Get in that loop of lv not ready messages.  Difference: Native 
> attempt still needs the IDE plugged in or I get 99 99 99 ... , chroot does 
> not.
> 
> So, what do I do next?

Obviously, the LILO map file is on the IDE drive.  Is your /boot partition
on the IDE drive?  If so, you cannot remove it.  The /boot partition must
be a partition on a physical drive, but obviously it cannot be on the drive
that you want to remove.

The "volume not ready" messages would indicate that LVM2, or some file(s) needed
by it, are not included in the initial RAM file system.

[toc] | [prev] | [next] | [standalone]

#161965

On Monday 21 December 2015 15:25:15 Stephen Powell wrote:
> On Mon, 21 Dec 2015 04:50:00 -0500 (EST), David Baron wrote:
> > Went through all the motions, both ways: On native and chroot. Results
> > were the same.  Get in that loop of lv not ready messages.  Difference:
> > Native attempt still needs the IDE plugged in or I get 99 99 99 ... ,
> > chroot does not.
> >
> > So, what do I do next?
>
> Obviously, the LILO map file is on the IDE drive.  Is your /boot partition
> on the IDE drive?  If so, you cannot remove it. 

Could he not dd them onto another drive?  Obviously not - but why not??

Lisi

> The /boot partition must 
> be a partition on a physical drive, but obviously it cannot be on the drive
> that you want to remove.
>
> The "volume not ready" messages would indicate that LVM2, or some file(s)
> needed by it, are not included in the initial RAM file system.

[toc] | [prev] | [next] | [standalone]

#161972

On Mon, 21 Dec 2015 10:31:54 -0500 (EST), Lisi Reisz wrote:
> 
> Could he not dd them onto another drive?
> ...
He can copy the /boot data to another drive, not necessarily
with dd.  In fact, if he wants to be able to remove the
existing IDE drive, he must.  But he cannot copy it to an
LVM2 logical volume.  The data in /boot (after copying)
must be on a partition on a physical disk which is accessible
via the BIOS and not on the old IDE drive which he wishes
to remove.  The / filesystem can be an LVM2 logical volume,
provided the initial RAM filesystem contains sufficient files
to mount an LVM2 logical volume, but the filesystem which
gets mounted on /boot must be made on a partition of a *real*
disk which is not scheduled to be removed from the system.

[toc] | [prev] | [next] | [standalone]

#161966

On Monday 21 December 2015 10:25:15 Stephen Powell wrote:
> On Mon, 21 Dec 2015 04:50:00 -0500 (EST), David Baron wrote:
> > Went through all the motions, both ways: On native and chroot. Results
> > were
> > the same.  Get in that loop of lv not ready messages.  Difference: Native
> > attempt still needs the IDE plugged in or I get 99 99 99 ... , chroot does
> > not.
> > 
> > So, what do I do next?
> 
> Obviously, the LILO map file is on the IDE drive.  Is your /boot partition
> on the IDE drive?  If so, you cannot remove it.  The /boot partition must
> be a partition on a physical drive, but obviously it cannot be on the drive
> that you want to remove.
>
The boot is not a separate partition but is a directory on the root so travels 
with it. Copy on both old and new directories.
 
> The "volume not ready" messages would indicate that LVM2, or some file(s)
> needed by it, are not included in the initial RAM file system.
I always get one of those on boot up, then things proceed. I have no lv's. 
Maybe fix-include in initramfs anyway?

The loop that I get is something more problematic.

[toc] | [prev] | [next] | [standalone]

#161969

On Mon, 21 Dec 2015 10:36:48 -0500 (EST), David Baron wrote:
> 
> On Monday 21 December 2015 10:25:15 Stephen Powell wrote:
>> 
>> Obviously, the LILO map file is on the IDE drive.  Is your /boot partition
>> on the IDE drive?  If so, you cannot remove it.  The /boot partition must
>> be a partition on a physical drive, but obviously it cannot be on the drive
>> that you want to remove.
> 
> The boot is not a separate partition but is a directory on the root so
> travels with it.  Copy on both old and new directories.

No, that won't work.  If the root filesystem is an LVM2 logical volume, then
/boot *cannot* be part of the root filesystem.  To be more rigorous, there will
be a /boot directory in the / filesystem, but it must be an *empty* directory,
so that another filesystem can be mounted on that directory.  Another
filesystem must get mounted on the /boot directory in the root filesystem,
and that filesystem must be made on a partition of a *real* disk which is
accessible via the BIOS.  It cannot be an LVM2 logical volume.  The boot
partition contains the LILO map file (by default, /boot/map) as well as the
kernel image file and the initial RAM filesystem image file.  LILO reads these
files at boot time via BIOS calls, and the BIOS does not support LVM2 logical
volumes.  You can have a physical disk with two partitions on it, one partition
of which is an LVM2 physical volume which is part of an LVM2 logical volume,
and the other one of which is a stand-alone partition which is mounted on /boot.
But the filesystem which gets mounted on /boot must *not* be an LVM2 logical
volume.  I thought I made that clear before.  Also, the LILO boot sector must
be either on the MBR of a *real* disk, or the first sector of a partition on
a *real* disk.
> 
> The loop that I get is something more problematic.

Agreed.  As I said before, there is probably something missing from the initial
RAM file system that needs to be there for the kernel to mount an LVM2 logical
volume.

[toc] | [prev] | [next] | [standalone]

#161973

On Monday 21 December 2015 14:53:16 Stephen Powell wrote:
> On Mon, 21 Dec 2015 10:36:48 -0500 (EST), David Baron wrote:
> > On Monday 21 December 2015 10:25:15 Stephen Powell wrote:
> >> Obviously, the LILO map file is on the IDE drive.  Is your /boot
> >> partition
> >> on the IDE drive?  If so, you cannot remove it.  The /boot partition must
> >> be a partition on a physical drive, but obviously it cannot be on the
> >> drive
> >> that you want to remove.
> > 
> > The boot is not a separate partition but is a directory on the root so
> > travels with it.  Copy on both old and new directories.
> 
> No, that won't work.  If the root filesystem is an LVM2 logical volume, then
> /boot *cannot* be part of the root filesystem.  To be more rigorous, there
> will be a /boot directory in the / filesystem, but it must be an *empty*
> directory, so that another filesystem can be mounted on that directory. 
> Another filesystem must get mounted on the /boot directory in the root
> filesystem, and that filesystem must be made on a partition of a *real*
> disk which is accessible via the BIOS.  It cannot be an LVM2 logical
> volume.  The boot partition contains the LILO map file (by default,
> /boot/map) as well as the kernel image file and the initial RAM filesystem
> image file.  LILO reads these files at boot time via BIOS calls, and the
> BIOS does not support LVM2 logical volumes.  You can have a physical disk
> with two partitions on it, one partition of which is an LVM2 physical
> volume which is part of an LVM2 logical volume, and the other one of which
> is a stand-alone partition which is mounted on /boot. But the filesystem
> which gets mounted on /boot must *not* be an LVM2 logical volume.  I
> thought I made that clear before.  Also, the LILO boot sector must be
> either on the MBR of a *real* disk, or the first sector of a partition on a
> *real* disk.
> 
> > The loop that I get is something more problematic.
> 
> Agreed.  As I said before, there is probably something missing from the
> initial RAM file system that needs to be there for the kernel to mount an
> LVM2 logical volume.

> ===========================
> 
> Could he not dd them onto another drive?
> ...
>He can copy the /boot data to another drive, not necessarily
>with dd.  In fact, if he wants to be able to remove the
>existing IDE drive, he must.  But he cannot copy it to an
>LVM2 logical volume.  The data in /boot (after copying)
>must be on a partition on a physical disk which is accessible
>via the BIOS and not on the old IDE drive which he wishes
>to remove.  The / filesystem can be an LVM2 logical volume,
>provided the initial RAM filesystem contains sufficient files
>to mount an LVM2 logical volume, but the filesystem which
>gets mounted on /boot must be made on a partition of a *real*
>disk which is not scheduled to be removed from the system.


Repeat: NO LV's

[toc] | [prev] | [next] | [standalone]

#161974

On Mon, 21 Dec 2015 15:43:54 -0500 (EST), David Baron wrote:
> 
> Repeat: NO LV's

Oh.  Sorry.  Looking back over the thread, I guess I got the idea from Anders Andersson
that you were using LVM2 logical volumes.  My mistake.  Yes, if / is a partition on a
real disk, then /boot can be part of the same filesystem.  I've been on the wrong track
for several posts now.  Please excuse the noise.
 
-- 
  .''`.     Stephen Powell    <zlinuxman@wowway.com>
 : :'  :
 `. `'`
   `-

[toc] | [prev] | [next] | [standalone]

#161985

On Monday 21 December 2015 16:15:48 Stephen Powell wrote:
> On Mon, 21 Dec 2015 15:43:54 -0500 (EST), David Baron wrote:
> > Repeat: NO LV's
> 
> Oh.  Sorry.  Looking back over the thread, I guess I got the idea from
> Anders Andersson that you were using LVM2 logical volumes.  My mistake. 
> Yes, if / is a partition on a real disk, then /boot can be part of the same
> filesystem.  I've been on the wrong track for several posts now.  Please
> excuse the noise.
Help greatly appreciated, regardless.

[toc] | [prev] | [next] | [standalone]

#161991

[Multipart message — attachments visible in raw view] — view raw

Le primidi 1er nivôse, an CCXXIV, Stephen Powell a écrit :
> No, that won't work.  If the root filesystem is an LVM2 logical volume, then
> /boot *cannot* be part of the root filesystem.  To be more rigorous, there will
> be a /boot directory in the / filesystem, but it must be an *empty* directory,
> so that another filesystem can be mounted on that directory.  Another
> filesystem must get mounted on the /boot directory in the root filesystem,
> and that filesystem must be made on a partition of a *real* disk which is
> accessible via the BIOS.  It cannot be an LVM2 logical volume.  The boot
> partition contains the LILO map file (by default, /boot/map) as well as the
> kernel image file and the initial RAM filesystem image file.  LILO reads these
> files at boot time via BIOS calls, and the BIOS does not support LVM2 logical
> volumes.

What you write is slightly inaccurate. The core of your inaccuracy is this:
LILO does not use the BIOS to read FILES, but SECTORS. How to map files to
sectors is entirely LILO's problem.

IIRC, the mapping is computed when (re)installing LILO on the boot-sector
and hard-coded in the boot-sector itself, with one level of indirection (the
map file). After a quick glance at the sources, it uses the FIBMAP ioctl and
various others to ask the kernel the blocks used by a file and converts to
sectors. At the same time, I noticed that LILO seems to be actually capable
of finding the sectors for files on LVM.

This is how LILO works. GRUB, for example, works in a completely different
way: it has code to decode partition tables, logical volumes and various
filesystems, and uses it to find files at runtime. This is way more robust
than LILO. On the other hand, the code for that is quite large and does not
fit on the 512- octets of a boot-sector: GRUB must cheat, it has a second
stage, and just like LILO's map file, it hard-codes the sectors for the
second stage in the boot-sector image. Still, GRUB's second stage is much
smaller than a kernel image (about fifty kilo-octets) and changes very
infrequently. To avoid troubles with filesystems, GRUB tries to put its
second stage in the unused space between the partition table and the
boot-sector.

I have not read this thread carefully, so maybe it has already been
addressed, but all this suggest that the OP should install GRUB instead of
LILO and be done with that kind of trouble.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#161993

Nicolas George writes:
> To avoid troubles with filesystems, GRUB tries to put its second stage
> in the unused space between the partition table and the boot-sector.

"Unused" is the problem with this design.  The space is unused on by
accident.  There is no standard (even an informal one) that reserves it.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#161994

[Multipart message — attachments visible in raw view] — view raw

Le duodi 2 nivôse, an CCXXIV, John Hasler a écrit :
> "Unused" is the problem with this design.  The space is unused on by
> accident.  There is no standard (even an informal one) that reserves it.

This is theoretical. In practice, it works pretty well, because people (at
least competent sysadmins and authors of installers) do not mess randomly
with their partition table.

[toc] | [prev] | [next] | [standalone]

#161996

[Multipart message — attachments visible in raw view] — view raw

Le duodi 2 nivôse, an CCXXIV, John Hasler a écrit :
> Think about multiboot home user systems.

Multiboot or no multiboot, once the system(s) is/are installed, nobody
writes outside the partitions.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#161998

Nicolas George <george@nsup.org> wrote:
> Le duodi 2 nivôse, an CCXXIV, John Hasler a écrit :
>> Think about multiboot home user systems.

> Multiboot or no multiboot, once the system(s) is/are installed, nobody
> writes outside the partitions.

In ye olde days (pre-Windowsm 98) some programs (I think Photoshop did
it.) wrote licence data into that space, because it was unused. The copy
protection scheme of some games also tried to hide information there.

So "nobody" is not quite right. "nobody with the right mind" would be a
better description.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#161999

On Tue 22 Dec 2015 at 20:44:31 +0100, Sven Hartge wrote:

> Nicolas George <george@nsup.org> wrote:
> > Le duodi 2 nivôse, an CCXXIV, John Hasler a écrit :
> >> Think about multiboot home user systems.
> 
> > Multiboot or no multiboot, once the system(s) is/are installed, nobody
> > writes outside the partitions.
> 
> In ye olde days (pre-Windowsm 98) some programs (I think Photoshop did
> it.) wrote licence data into that space, because it was unused. The copy
> protection scheme of some games also tried to hide information there.
> 
> So "nobody" is not quite right. "nobody with the right mind" would be a
> better description.

However (whoever is "right"), Debian developers are aware of this
problem and are willing to fix it if it happens:

  http://www.chiark.greenend.org.uk/~cjwatson/blog/windows-applications-making-grub2-unbootable.html

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web