Re: Attempt to Move Root

[Pascal Hambourg]

Petter Adsen a écrit :
> Gene Heskett  wrote:
> 
>> I made the mistake of trying to install a wheezy derivitive on a 2T
>> drive that had been prepared using GPT partitions.  The installer
>> could not see them at all, so after 2 tries, I just let it go ahead
>> and do its own partitioning and formatting to ext4. The system has
>> actually worked well, on a drive that is said to be too big for MBR.
> 
> The max addressable size of a drive for MBR is 2TiB, AIUI.

Yes, assuming standard 512-byte sectors. A lot more with large 4096-byte
sectors ("4Kn" Advanced Format).

2 TiB > 2 TB, so GPT is not required for a 2 TB disk. However GPT has
other advantages over MSDOS than maximum addressable size.

Re: Attempt to Move Root

[Petter Adsen]

On Sun, 27 Dec 2015 10:07:13 -0500
Gene Heskett  wrote:

> I made the mistake of trying to install a wheezy derivitive on a 2T
> drive that had been prepared using GPT partitions.  The installer
> could not see them at all, so after 2 tries, I just let it go ahead
> and do its own partitioning and formatting to ext4. The system has
> actually worked well, on a drive that is said to be too big for MBR.

The max addressable size of a drive for MBR is 2TiB, AIUI.

> So I would like to be enlightened as to the real differences between
> the systems. URL's to the proponents sites would be fine.

You can take a look at this, for starters:

https://wiki.archlinux.org/index.php/GPT

The first couple of sections highlights the differences between MBR and
GPT, and there are links to more information at the bottom of the page.

Petter

-- 
"I'm ionized"
"Are you sure?"
"I'm positive."

Re: Attempt to Move Root

[Nicolas George]

Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
> I repeat : the point is not MBR/MSDOS vs GPT. It is that the GRUB
> installer handles *specially* one type of partition which exists only in
> GPT style : "BIOS Boot" aka "bios_grub".
> 
> Are you talking about the installer code run by grub-install or the
> bootloader code ? I am not aware that the installer code can handle any
> partition type other than the above type in the same way.

I am talking about the installer, of course. The algorithm used is:

1. embed in the disk if possible, otherwise:
2. embed in the filesystem if possible, otherwise:
3. write in a file and print a warning.

It seems that no options are present to control this finely, which means it
will try to use the first method that works, but all the infrastructure is
there.


signature.asc
Description: Digital signature

Re: Attempt to Move Root

[Gene Heskett]

On Sunday 27 December 2015 09:30:38 Nicolas George wrote:

> Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
> > There was nothing confusing in Sven's message until you mentionned
> > UEFI in response to "I love the GPT". Why did you start talking
> > about UEFI ?
>
> For the early stage of booting, there is no difference between
> MBR-style partitions (it is more accurate and less ambiguous than
> "MSDOS-style") and GPT-style partitions. There are only sectors
> accessed through a BIOS call. Therefore, if something makes booting
> easier, it's not GPT, it's UEFI.
>
> > Could you please give a concrete example ?
> > AFAIK, GRUB cannot use a partition in MSDOS format to store its core
> > image in the same way as it uses a BIOS boot partition in GPT
> > format.
>
> What makes you say that? There is nothing special about GPT
> partitions, they are intervals of sectors, just as MBR-style
> partitions.

I made the mistake of trying to install a wheezy derivitive on a 2T drive 
that had been prepared using GPT partitions.  The installer could not 
see them at all, so after 2 tries, I just let it go ahead and do its own 
partitioning and formatting to ext4. The system has actually worked 
well, on a drive that is said to be too big for MBR.

So I would like to be enlightened as to the real differences between the 
systems. URL's to the proponents sites would be fine.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Attempt to Move Root

[Pascal Hambourg]

Nicolas George a écrit :
> 
> In the meantime, I can tell what I saw in the code, and this is: GRUB makes
> no difference between MBR-style partitions (that it calls internally
> "msdos") and GPT.

I repeat : the point is not MBR/MSDOS vs GPT. It is that the GRUB
installer handles *specially* one type of partition which exists only in
GPT style : "BIOS Boot" aka "bios_grub".

Are you talking about the installer code run by grub-install or the
bootloader code ? I am not aware that the installer code can handle any
partition type other than the above type in the same way.

Re: Attempt to Move Root

[Pascal Hambourg]

Nicolas George a écrit :
> Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
>> You are confusing GPT (partition table format) and UEFI (firmware and
>> boot interface).
> 
> Quite the contrary, I am trying to de-confuse by using exactly the correct
> terms.

There was nothing confusing in Sven's message until you mentionned UEFI
in response to "I love the GPT". Why did you start talking about UEFI ?

>> Can you tell more ? AFAIK, there is no equivalent to the "BIOS boot"
>> partition in the MSDOS partition scheme.
> 
> What is there to tell more? You create a partition and decide it is for the
> bootloader, period.

Could you please give a concrete example ?
AFAIK, GRUB cannot use a partition in MSDOS format to store its core
image in the same way as it uses a BIOS boot partition in GPT format.
If you're talking about a partition mounted on /boot/grub, it is not the
same at all. If you're talking about another bootloader, please name it.

Re: Attempt to Move Root

[Nicolas George]

Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
> *Cough*
> At least it was supposed to. The more I mess with UEFI implementations,
> the more I feel dubious about its real advantages.

Six messages ago, I wrote "or would be if it was correctly implemented by
vendors"; you read it since you replied to it. Please try to keep up.

> My experience and the documentation I read.

If you manage to find usable documentation for GRUB, please share it.

In the meantime, I can tell what I saw in the code, and this is: GRUB makes
no difference between MBR-style partitions (that it calls internally
"msdos") and GPT.


signature.asc
Description: Digital signature

Re: Attempt to Move Root

[Sven Hartge]

Pascal Hambourg  wrote:
> Nicolas George a écrit :
>> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :

>>> And this is why I love the GPT. There is a defined space for the
>>> bootloader to be and no nether region of swirly unknowness between
>>> the MBR and the start of the first partition.

> Note that current partition tools leave a bigger gap than ~31 KB,
> typically ~1 MB to ensure partition alignment. So on a newer
> installation you would not face that problem again even with an MSDOS
> partition table.

Correct. But that space is still indefined and who knows what tries to
write data into that place.

S°

-- 
Sigmentation fault. Core dumped.

Re: Attempt to Move Root

[Pascal Hambourg]

Sven Hartge a écrit :
> Pascal Hambourg  wrote:
>>> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
> 
 And this is why I love the GPT. There is a defined space for the
 bootloader to be and no nether region of swirly unknowness between
 the MBR and the start of the first partition.
> 
>> Note that current partition tools leave a bigger gap than ~31 KB,
>> typically ~1 MB to ensure partition alignment. So on a newer
>> installation you would not face that problem again even with an MSDOS
>> partition table.
> 
> Correct. But that space is still indefined and who knows what tries to
> write data into that place.

You do know, if you only install and run open source software on this
machine. However that comment was just for completeness. I advocate and
favour GPT whenever I can.

Re: Attempt to Move Root

[Nicolas George]

Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
> There was nothing confusing in Sven's message until you mentionned UEFI
> in response to "I love the GPT". Why did you start talking about UEFI ?

For the early stage of booting, there is no difference between MBR-style
partitions (it is more accurate and less ambiguous than "MSDOS-style") and
GPT-style partitions. There are only sectors accessed through a BIOS call.
Therefore, if something makes booting easier, it's not GPT, it's UEFI.

> Could you please give a concrete example ?
> AFAIK, GRUB cannot use a partition in MSDOS format to store its core
> image in the same way as it uses a BIOS boot partition in GPT format.

What makes you say that? There is nothing special about GPT partitions, they
are intervals of sectors, just as MBR-style partitions.


signature.asc
Description: Digital signature

Re: Attempt to Move Root

[Nicolas George]

Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
> You are confusing GPT (partition table format) and UEFI (firmware and
> boot interface).

Quite the contrary, I am trying to de-confuse by using exactly the correct
terms.

> Can you tell more ? AFAIK, there is no equivalent to the "BIOS boot"
> partition in the MSDOS partition scheme.

What is there to tell more? You create a partition and decide it is for the
bootloader, period.

> I beg to differ.
> Upgrading the GRUB package will automatically try to reinstall the
> bootloader it is responsible for. If it fails, it will install the new
> modules in /boot/grub/ and leave the old boot image and core image,
> leading to a version mismatch.
> Also, the grub.cfg config file created by grub-mkconfig or update-grub
> may not be compatible with the bootloader installed by another version
> of GRUB because of changes in syntax or modules.
> 
> Of course you are correct if the GRUB package is not responsible for the
> active bootloader.

Agreed.


signature.asc
Description: Digital signature

Re: Attempt to Move Root

[Pascal Hambourg]

Nicolas George a écrit :
> Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
>> There was nothing confusing in Sven's message until you mentionned UEFI
>> in response to "I love the GPT". Why did you start talking about UEFI ?
> 
> For the early stage of booting, there is no difference between MBR-style
> partitions (it is more accurate and less ambiguous than "MSDOS-style") and
> GPT-style partitions. There are only sectors accessed through a BIOS call.

I agree, but a dedicated space on a partition is a safer location than
unallocated disk space or a filesystem.

> Therefore, if something makes booting easier, it's not GPT, it's UEFI.

*Cough*
At least it was supposed to. The more I mess with UEFI implementations,
the more I feel dubious about its real advantages.

>> AFAIK, GRUB cannot use a partition in MSDOS format to store its core
>> image in the same way as it uses a BIOS boot partition in GPT format.
> 
> What makes you say that?

My experience and the documentation I read. If you know a way to have
GRUB install its core image into an arbitrary partition, I'd love to
learn about it.

Re: Attempt to Move Root

[Stephen Powell]

On Fri, 25 Dec 2015 10:33:56 -0500 (EST), Stephen Powell wrote:
> On Tue, 22 Dec 2015 10:57:41 -0500 (EST), Nicolas George wrote:
>> ...
>> I noticed that LILO seems to be actually capable
>> of finding the sectors for files on LVM.
> 
> In the general case, the sectors of a file on an LVM2 logical volume may
> reside on multiple physical partitions on multiple physical disks.  But if
> all of those disks are addressable via the BIOS, and all of the sectors
> are accessible via the BIOS, then it may be theoretically possible for LILO
> to read the map file, the kernel image file, and the initial RAM file system
> image file from an LVM2 logical volume at boot time.  I guess I was making
> an implicit assumption that they would all have to be on the same physical
> device.  But maybe that's not true.  I'll have to look into that.

Looking at the source package for lilo, in src/geometry.c, I find the following:

if (lbm.lv_dev != geo->base_dev)
die("LVM boot LV cannot be on multiple PVs\n");

Therefore, it appears from a cursory examination that an LVM2 logical volume
may be used for /boot if the logical volume maps to a single
physical volume.  It is not clear to me from this cursory examination whether
this "physical volume" actually means a partition; or if it means a physical 
disk,
which may consist of multiple partitions.  In any case, I would not recommend
putting /boot on an LVM2 logical volume.  It's just one more layer of
complexity, and one more potential thing to go wrong.
  
-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: Attempt to Move Root

[Pascal Hambourg]

Nicolas George a écrit :
> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
>> And this is why I love the GPT. There is a defined space for the
>> bootloader to be and no nether region of swirly unknowness between the
>> MBR and the start of the first partition.

Note that current partition tools leave a bigger gap than ~31 KB,
typically ~1 MB to ensure partition alignment. So on a newer
installation you would not face that problem again even with an MSDOS
partition table.

> The UEFI boot system is indeed a great improvement, or would be if it was
> correctly implemented by vendors, but do not expect too much of it.

You are confusing GPT (partition table format) and UEFI (firmware and
boot interface).

> You can have already a partition dedicated to the bootloader with old-style
> MBR partitions.

Can you tell more ? AFAIK, there is no equivalent to the "BIOS boot"
partition in the MSDOS partition scheme.

> You seem to be missing something here: there is absolutely no requirement
> that the GRUB version installed as a package on the distribution is the same
> as the version installed as bootloader. You could have left the upgrade
> replace GRUB or even removed the package for GRUB, just leaving the old
> bootloader, that is not a problem.

I beg to differ.
Upgrading the GRUB package will automatically try to reinstall the
bootloader it is responsible for. If it fails, it will install the new
modules in /boot/grub/ and leave the old boot image and core image,
leading to a version mismatch.
Also, the grub.cfg config file created by grub-mkconfig or update-grub
may not be compatible with the bootloader installed by another version
of GRUB because of changes in syntax or modules.

Of course you are correct if the GRUB package is not responsible for the
active bootloader.

> The same thing would have worked with without GPT.

Yes, by leaving a bigger gap between the MBR and the first partition.

> Especially if you use a
> bios_grub partition instead of an EFI system partition.

A bios_grub (actually "BIOS boot") partition without GPT ? Please tell
me more !

Re: Attempt to Move Root

[Stephen Powell]

On Tue, 22 Dec 2015 14:44:31 -0500 (EST), Sven Hartge wrote:
> 
> 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.
> 

I can think of some other cases.  Back in the day when most BIOSes had
a head limit of 16, thus limiting the size of a hard disk addressable via
BIOS Int 13h functions 02h and 03h to 504MiB, programs such as Ontrack
Disk Manager could be installed to circumvent this restriction.  They
would hook the BIOS to increase the head limit to 255.  I believe this
was accomplished by putting the BIOS hook program in the boot sector
and moving the original boot sector to the second sector (CHS value
0:0:2).

Also, in the days of IBM 386 microchannel machines, such as the IBM
PS/2 model 70, IBM sold a memory board that initialized after POST
by using a similar boot hook.

Around that same time period, Novell Netware was known to also use an
unallocated sector, perhaps for licensing, copy protection, etc.
These schemes all conflicted with each other of course.  As I say in
my lilo web page, there are no rules for the use of unallocated sectors.

And grub-legacy and grub-pc (by default at least) now do a similar thing.
They store information in unallocated sectors.  That's one of the
reasons (but not the only reason) that I switched back to LILO.

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

Re: Attempt to Move Root

[Stephen Powell]

On Tue, 22 Dec 2015 10:57:41 -0500 (EST), Nicolas George wrote:
> 
> 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.

That depends on your point of view.  To lilo's map installer (the lilo command
that runs at a Linux shell prompt) they are files.  The LILO boot loader
itself reads an ordered list of sectors created for it by the map installer.
But it is still a file.  If what you mean is that the LILO boot loader,
at boot time, cannot determine which sectors to read based on examining
the file system structures, then yes, that is true.
> 
> 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.

In the general case, the sectors of a file on an LVM2 logical volume may
reside on multiple physical partitions on multiple physical disks.  But if
all of those disks are addressable via the BIOS, and all of the sectors
are accessible via the BIOS, then it may be theoretically possible for LILO
to read the map file, the kernel image file, and the initial RAM file system
image file from an LVM2 logical volume at boot time.  I guess I was making
an implicit assumption that they would all have to be on the same physical
device.  But maybe that's not true.  I'll have to look into that.
>
> 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.

As subsequent posts have indicated, the trouble was with an incorrect UUID.
It had nothing to do with the OP's choice of boot loader.
 
-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: Attempt to Move Root

[Nicolas George]

Le quartidi 4 nivôse, an CCXXIV, Sven Hartge a écrit :
> > The same thing would have worked with without GPT. Especially if you use a
> > bios_grub partition instead of an EFI system partition.
> Eh? I did use a bios_grub partition, because the server in question uses
> a legacy BIOS to boot.

Then you confirm what I wrote: you could have done exactly the same with
legacy MBR partitions, GPT was not needed for that operation.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Attempt to Move Root (SOLVED!!)

[Anders Andersson]

On Wed, Dec 23, 2015 at 9:52 AM, David Baron  wrote:
> On reboot (to old system or otherwise), the UUID of the target partition was
> CHANGED!

Unlikely, how do you know? What would change them during a reboot?


> If the problem was not hidden behind a screenfull of lvm errors, I
> would/should have seen that right away, huh?

To my knowledge, lvm does not care about UUIDs. What were these errors?

Re: Attempt to Move Root (SOLVED!!)

[David Baron]

On Wednesday 23 December 2015 12:39:18 Anders Andersson wrote:
> On Wed, Dec 23, 2015 at 9:52 AM, David Baron  wrote:
> > On reboot (to old system or otherwise), the UUID of the target partition
> > was CHANGED!
> 
> Unlikely, how do you know? What would change them during a reboot?

When I resized the target partition, /dev/disk/by-uuid showed what I 
afterwards placed in fstab and lilo.conf.

Today, a desperate try, placed the new fstab on the old root and rebooted. 
Root could not be mounted and the original mounted read-only (correct behavior 
in this case). I, of course, could not fix it this way. When I tried to 
remount it or mount the new root over it, got error that the uuid could not be 
found.

listing the /dev/disk/by-uuid now showed a new uuid for the target partition. 
Mounted the new partition by /dev/sd..., placed the correct(ed) uuid in fstab 
and lilo.conf, went through the recommended procedure and voile.
> 
> > If the problem was not hidden behind a screenfull of lvm errors, I
> > would/should have seen that right away, huh?
> 
> To my knowledge, lvm does not care about UUIDs. What were these errors?

The lvm error on a functional boot up is once and spurious. This is a bug 
somewhere in the initramfs, I suppose.

The repeated lvm error meant it could not find incorrectly uuid'd partition.

I repeat, I am using no logical volumes. I did not notice the errant uuid as 
cited in the error messages. Might have indeed been but it did not catch my 
eye at the times.

Re: Attempt to Move Root

[Sven Hartge]

Nicolas George  wrote:
> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :

>> And this is why I love the GPT. There is a defined space for the
>> bootloader to be and no nether region of swirly unknowness between the
>> MBR and the start of the first partition.

>> Also this: Sit back kids, Uncle Sven tells a story from the trenches of
>> the 1st GRUB war.
>> 
>> I was upgrading a remote server from Squeeze to Wheezy. This server uses
>> LVM on top of an MD-RAID1, /boot is included in / which is a LV. so GRUB
>> needs to know about MD and LVM (and the filesystem of / of course).
>> 
>> With Squeeze everything was fine and dandy.
>> 
>> But after upgrading to Wheezy, GRUB would no longer install into the
>> 31744 byte-sized space after the MBR. Its core.img with all needed
>> componenents was 12 bytes to large, about 60 bytes bigger than the one
>> from Squeeze!
>> 

>> What to do? Using the old one from Squeeze? Psshht, needing to hold the
>> old package for ever, maybe making the system unbootable in the worst
>> moment? Not an option!

> You seem to be missing something here: there is absolutely no
> requirement that the GRUB version installed as a package on the
> distribution is the same as the version installed as bootloader. You
> could have left the upgrade replace GRUB or even removed the package
> for GRUB, just leaving the old bootloader, that is not a problem.

Yes, but I wanted to be sure that there will be no suprises for me or
another administrator in the future. Having no GRUB package installed
would have deviated from the norm, could cause strange side-effects with
other packages or the packages manager and keeping the old version
installed would have been ugly.

The idea was to have a system which fits one of the server templates
used and not create another special snowflake which needs manual
attention every time.

>> But we have a MD-RAID! I removed one disk from the RAID, repartitioned
>> it as GPT, added a bios_grub partition of the right (and future-proof!)
>> size before the data partition, readded this to the running half of the
>> RAID, let the RAID resync, repeated the whole procedure with the other
>> disk, installed GRUB to its new home, rebooted while hoping/praying and
>> ... tadaaa ... the system came right up.

> The same thing would have worked with without GPT. Especially if you use a
> bios_grub partition instead of an EFI system partition.

Eh? I did use a bios_grub partition, because the server in question uses
a legacy BIOS to boot.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Attempt to Move Root

[Nicolas George]

Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
> And this is why I love the GPT. There is a defined space for the
> bootloader to be and no nether region of swirly unknowness between the
> MBR and the start of the first partition.

The UEFI boot system is indeed a great improvement, or would be if it was
correctly implemented by vendors, but do not expect too much of it.

You can have already a partition dedicated to the bootloader with old-style
MBR partitions.

If dealing with programs that bypass the operating system and write outside
partitions, GPT will not help. It may even make things worse if the program
does not know it and gets confused.

The core of it is: no program, even an operating system, should ever write
outside partitions except at the direct request of the administrator. If
this rule is kept, then there is nothing to worry about, except mistakes,
and GRUB's hack works. If this rule is violated, then there is nothing to be
done, all hell can break loose at any time.

> Also this: Sit back kids, Uncle Sven tells a story from the trenches of
> the 1st GRUB war.
> 
> I was upgrading a remote server from Squeeze to Wheezy. This server uses
> LVM on top of an MD-RAID1, /boot is included in / which is a LV. so GRUB
> needs to know about MD and LVM (and the filesystem of / of course).
> 
> With Squeeze everything was fine and dandy.
> 
> But after upgrading to Wheezy, GRUB would no longer install into the
> 31744 byte-sized space after the MBR. Its core.img with all needed
> componenents was 12 bytes to large, about 60 bytes bigger than the one
> from Squeeze!
> 

> What to do? Using the old one from Squeeze? Psshht, needing to hold the
> old package for ever, maybe making the system unbootable in the worst
> moment? Not an option!

You seem to be missing something here: there is absolutely no requirement
that the GRUB version installed as a package on the distribution is the same
as the version installed as bootloader. You could have left the upgrade
replace GRUB or even removed the package for GRUB, just leaving the old
bootloader, that is not a problem.
> 
> But we have a MD-RAID! I removed one disk from the RAID, repartitioned
> it as GPT, added a bios_grub partition of the right (and future-proof!)
> size before the data partition, readded this to the running half of the
> RAID, let the RAID resync, repeated the whole procedure with the other
> disk, installed GRUB to its new home, rebooted while hoping/praying and
> ... tadaaa ... the system came right up.

The same thing would have worked with without GPT. Especially if you use a
bios_grub partition instead of an EFI system partition.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Attempt to Move Root (SOLVED!!)

[David Baron]

On reboot (to old system or otherwise), the UUID of the target partition was 
CHANGED!

If the problem was not hidden behind a screenfull of lvm errors, I 
would/should have seen that right away, huh?

Re: Attempt to Move Root

[Sven Hartge]

Nicolas George  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.

Re: Attempt to Move Root

[Nicolas George]

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


signature.asc
Description: Digital signature

Re: Attempt to Move Root

[Sven Hartge]

Nicolas George  wrote:
> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :

>> 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.

> I did not know that, it is simply disgusting. Well, if you have to
> deal with bad-behaved proprietary programs that fancy themselves more
> powerful than the operating system, then you can not use that feature
> of GRUB. That means you have to put its second stage in a partition;
> obviously, this is possible too.

> But when dealing with that level of stupidity, really there is nothing
> to do: we can not trust these proprietary programs will not decide to
> write anywhere on the disk just because they have decided they have
> the right to do so, or because they have a bug.

And this is why I love the GPT. There is a defined space for the
bootloader to be and no nether region of swirly unknowness between the
MBR and the start of the first partition.

Also this: Sit back kids, Uncle Sven tells a story from the trenches of
the 1st GRUB war.

I was upgrading a remote server from Squeeze to Wheezy. This server uses
LVM on top of an MD-RAID1, /boot is included in / which is a LV. so GRUB
needs to know about MD and LVM (and the filesystem of / of course).

With Squeeze everything was fine and dandy.

But after upgrading to Wheezy, GRUB would no longer install into the
31744 byte-sized space after the MBR. Its core.img with all needed
componenents was 12 bytes to large, about 60 bytes bigger than the one
from Squeeze!

What to do? Using the old one from Squeeze? Psshht, needing to hold the
old package for ever, maybe making the system unbootable in the worst
moment? Not an option!

But we have a MD-RAID! I removed one disk from the RAID, repartitioned
it as GPT, added a bios_grub partition of the right (and future-proof!)
size before the data partition, readded this to the running half of the
RAID, let the RAID resync, repeated the whole procedure with the other
disk, installed GRUB to its new home, rebooted while hoping/praying and
... tadaaa ... the system came right up.

This of course was only possible because the MD-RAID code allows for a
slight variation on the partition size so I had to be careful to stay
inside that margin but in the end it worked out fine with only 3 minutes
of downtime for the reboot.

And because of that experience I use only the GPT for physical servers,
even when booting in legacy mode. Because I have a known place of a
known size for the boot loader.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Attempt to Move Root

[John Hasler]

I wrote:
> "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.

Nicolas George writes:
> 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.

Think about multiboot home user systems.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Attempt to Move Root

[Brian]

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

> Nicolas George  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

Re: Attempt to Move Root

[Nicolas George]

Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
> 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.

I did not know that, it is simply disgusting. Well, if you have to deal with
bad-behaved proprietary programs that fancy themselves more powerful than
the operating system, then you can not use that feature of GRUB. That means
you have to put its second stage in a partition; obviously, this is possible
too.

But when dealing with that level of stupidity, really there is nothing to
do: we can not trust these proprietary programs will not decide to write
anywhere on the disk just because they have decided they have the right to
do so, or because they have a bug.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Attempt to Move Root

[Brian]

On Tue 22 Dec 2015 at 23:05:54 +0100, Nicolas George wrote:

> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
> > 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.
> 
> I did not know that, it is simply disgusting. Well, if you have to deal with
> bad-behaved proprietary programs that fancy themselves more powerful than
> the operating system, then you can not use that feature of GRUB. That means
> you have to put its second stage in a partition; obviously, this is possible
> too.

Doesn't Reed-Solomon error correction on the core image take care of
this issue? Bug #550702, Message #70:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550702

  This is yet another modification on crappy windows applications like
  Flexible Lies Manager. This is neither Debian nor GRUB bug, but of the
  windows application which improperly writes to MBR gap.
  However this is a relatively widespread issue, so in upstream we now
  write that part using Reed-Solomon so we're not affected by this
  misbehaviour other than the time needed to recover from corruption in
  Reed-Solomon.

Re: Attempt to Move Root

[Nicolas George]

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


signature.asc
Description: Digital signature

Re: Attempt to Move Root

[Nicolas George]

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.


signature.asc
Description: Digital signature

Re: Attempt to Move Root

[John Hasler]

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 
jhas...@newsguy.com
Elmwood, WI USA

Re: Attempt to Move Root

[David Christensen]

On 12/21/2015 01:50 AM, David Baron wrote:

On Monday 21 December 2015 00:50:43 David Christensen wrote:

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.


On 12/21/2015 07:36 AM, David Baron wrote:

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.



So, what do I do next?


You information regarding /boot is unclear. I will assume /boot and root 
are on the same file system in the same partition of the 80 GB IDE.



I would:

1.  Backup everything on the source and destination drives.

2.  Move everything off the destination drive.

3.  Run the factory diagnostics on the destination drive to verify it is 
good.


4.  Wipe the destination drive.

5.  dd the contents of the source drive from sector 0 through the last 
sector of the partition containing root to the destination drive.


6.  Alternative to #5, or if #5 doesn't produce good results, do a fresh 
install on the destination drive and restore/ configure.



David

Re: Attempt to Move Root

[Stephen Powell]

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.

Re: Attempt to Move Root

[Stephen Powell]

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.

Re: Attempt to Move Root

[David Baron]

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

Re: Attempt to Move Root

[Stephen Powell]

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
 : :'  :
 `. `'`
   `-

Re: Attempt to Move Root

[David Christensen]

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

Re: Attempt to Move Root

[David Baron]

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?

Re: Attempt to Move Root

[David Baron]

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.

Re: Attempt to Move Root

[Lisi Reisz]

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.

Re: Attempt to Move Root

[David Baron]

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.

Re: Attempt to Move Root

[Stephen Powell]

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.

Re: Attempt to Move Root

[Stephen Powell]

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.

Re: Attempt to Move Root

[Stephen Powell]

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.

Re: Attempt to Move Root

[Ron]

On Sun, 20 Dec 2015 12:58:47 +0200
David Baron  wrote:

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

Have you tried getting rid of the UUID crap in both newroot/etc/fstab and 
newroot/etc/lilo.conf, and mount them the old way, as /dev/something ? 
 
Cheers,
 
Ron.
-- 
  Work is the curse
   of the drinking classes.
   -- Mike Romanoff

   -- http://www.olgiati-in-paraguay.org --
 

Re: Attempt to Move Root

[David Baron]

On Sunday 20 December 2015 08:07:31 Renaud OLGIATI wrote:
> On Sun, 20 Dec 2015 12:58:47 +0200
> 
> David Baron  wrote:
> > Edited newroot/etc/fstab and newroot/etc/lilo.conf to point root to
> > newrootpartition (by uuid)
> 
> Have you tried getting rid of the UUID crap in both newroot/etc/fstab and
> newroot/etc/lilo.conf, and mount them the old way, as /dev/something ?
> 

Could do this, but only is his "deprecated" and not recommended anywhere else, 
but my goal is to remove and older 80gig IDE disk from the system. As soon as 
I unplug it, those /dev/somethings are invalid. Which is why using UUID is 
recommended.

Re: Attempt to Move Root

[Anders Andersson]

>> David Baron  wrote:
>> > Edited newroot/etc/fstab and newroot/etc/lilo.conf to point root to
>> > newrootpartition (by uuid)
>>
>> Have you tried getting rid of the UUID crap in both newroot/etc/fstab and
>> newroot/etc/lilo.conf, and mount them the old way, as /dev/something ?
>>
>
> Could do this, but only is his "deprecated" and not recommended anywhere else,
> but my goal is to remove and older 80gig IDE disk from the system. As soon as
> I unplug it, those /dev/somethings are invalid. Which is why using UUID is
> recommended.

This is correct, and there should be no problem using UUID, but if you
actually have your devices on LVM logical volumes, then it is IMO
safer to use something like /dev/vg00/rootfs instead of UUID. Safer
for at least two reasons:
1) Less chance of copying the wrong UUID to fstab
2) Taking a snapshot of the filesystem (duplicate UUIDs) won't confuse the boot

However, if your new root is not on LVM, this advice does not apply. :)

Re: Attempt to Move Root

[Lisi Reisz]

On Sunday 20 December 2015 11:36:18 David Baron wrote:
> On Sunday 20 December 2015 08:07:31 Renaud OLGIATI wrote:
> > On Sun, 20 Dec 2015 12:58:47 +0200
> >
> > David Baron  wrote:
> > > Edited newroot/etc/fstab and newroot/etc/lilo.conf to point root to
> > > newrootpartition (by uuid)
> >
> > Have you tried getting rid of the UUID crap in both newroot/etc/fstab and
> > newroot/etc/lilo.conf, and mount them the old way, as /dev/something ?
>
> Could do this, but only is his "deprecated" and not recommended anywhere
> else, but my goal is to remove and older 80gig IDE disk from the system. As
> soon as I unplug it, those /dev/somethings are invalid. Which is why using
> UUID is recommended.

You could use /dev/something or other to get it going, then substitute the 
UUIDs once it works, and before doing the unplugging..

Lisi

Re: Attempt to Move Root

[David Baron]

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?