Am Freitag, den 02.07.2010, 13:38 +0200 schrieb splotz90:
> Am 01.07.2010 22:29, schrieb Andrew Benton:
> > Which partition will grub choose?
> I have found some additional information about that:
>
> http://www.linuxquestions.org/questions/linux-software-2/how-does-grub2-find-the-grub-cfg-file-79
linux fan wrote:
> In long-param-notation that is:
> search --no-floppy --file=filename
>
> Thus it is technically incorrect to imply that "[ ... the search ...]
> command only sets an internal GRUB variable used to find the kernel
> image.
The text is correct for the search lines in the conte
FYI
A possible search usefulness:
Or, other search methods to deduce the root filesystem for the
kernel's "root=" parameter, or where the kernel is.
* Suppose that the grub directory is a subdirectory of boot
* Suppose that the boot directory is a subdirectory of root /
* Suppose that the kernel
On 7/2/10, Bruce Dubbs wrote:
>> ./configure --bla-bla-bla
>> make
>
> Try to do a simple ls in the grub top level directory after a build if
> you don't use a separate build directory. There are 2400 files, many of
Not saying that is the right way. Just that it succeeded and I didn't
see or un
linux fan wrote:
> One solution that worked is to NOT build in a separate build directory.
>
> E.g., instead of:
> mkdir build
> cd build
> ../configure --bla-bla-bla
> make
>
> Do:
> ./configure --bla-bla-bla
> make
Try to do a simple ls in the grub top level directory after a build if
you do
FYI
-
For grub-1.98 !!!
-
http://ubuntuforums.org/showthread.php?t=1195275
describes a way to save the last chosen boot option to default
Involved is /etc/default/grub file which must be user created:
==
cat > /etc/defau
Am 01.07.2010 22:29, schrieb Andrew Benton:
> Which partition will grub choose?
I have found some additional information about that:
http://www.linuxquestions.org/questions/linux-software-2/how-does-grub2-find-the-grub-cfg-file-794560/
The "grub-setup" command seems to add an information where
Am 02.07.2010 09:44, schrieb splotz90:
>Am 01.07.2010 23:11, schrieb linux fan:
>> My understanding (from experimentation and documentation) is that the
>> UUID is specifically generated for a specific file system. You would
>> need to use dd or similar utility to move the filesystem to a
>>
Am 01.07.2010 23:11, schrieb linux fan:
> My understanding (from experimentation and documentation) is that the
> UUID is specifically generated for a specific file system. You would
> need to use dd or similar utility to move the filesystem to a
> different partition if you wished to preserve th
Am 01.07.2010 22:29, schrieb Andrew Benton:
> Which partition will grub choose?
I think that I've found the answer ...
Have a look at
http://www.gnu.org/software/grub/manual/html_node/install.html
I know that it is a GRUB Legacy documentation, but I think that GRUB 2
works in a similarly way
On Thu, Jul 1, 2010 at 11:53 AM, Sebastian Plotz wrote:
> Am Donnerstag, den 01.07.2010, 18:52 +0200 schrieb Sebastian Plotz:
>> If the LFS-User changes the device of the /boot partition (NOT / partition),
>> the system will still boot (with help of the search line).
>
> I should better say:
>
> I
On 7/1/10, Sebastian Plotz wrote:
> If the LFS-User has moved the /boot partition (NOT / partition), the
> system will still boot (with help of the search line).
>
My understanding (from experimentation and documentation) is that the
UUID is specifically generated for a specific file system. You
On 01/07/10 18:00, Sebastian Plotz wrote:
>
> In this early stage, GRUB is able to read a file system. The fs driver
> is placed direct after the MBR.
>
> GRUB has to probe every partition to find a grub.cfg ...
>
> So I think moving the /boot partition is not a problem.
>
> Please correct me, if I
On 01/07/10 17:52, Sebastian Plotz wrote:
> Am Donnerstag, den 01.07.2010, 15:05 +0100 schrieb Andrew Benton:
>> Why would we say that? You've not shown any meaningful use for the
>> search lines on an LFS system.
>>
>> Andy
>
> I did ...
>
> 1. The search command is only useful if we're using a se
Am Donnerstag, den 01.07.2010, 18:52 +0200 schrieb Sebastian Plotz:
> If the LFS-User changes the device of the /boot partition (NOT / partition),
> the system will still boot (with help of the search line).
I should better say:
If the LFS-User has moved the /boot partition (NOT / partition), the
On 7/1/10, linux fan wrote:
> something about how the esoteric grub2 works to be meaningful. Anyone
> is welcome to disagree.
>
An alternative language might be that:
The search line is not required on a typical LFS system.
It could optionally be noted that there is an alternative to the use
of
Am Donnerstag, den 01.07.2010, 15:03 +0100 schrieb Andrew Benton:
> I think your first problem would be that if you move your /boot
> partition grub will not be able to find any of it's files and you will
> need to find a CD/USB stick to boot from to fix your now broken system.
> The fact that t
Am Donnerstag, den 01.07.2010, 15:05 +0100 schrieb Andrew Benton:
> Why would we say that? You've not shown any meaningful use for the
> search lines on an LFS system.
>
> Andy
I did ...
1. The search command is only useful if we're using a separate /boot
partition.
2. With help of the search
On 7/1/10, Andrew Benton wrote:
> Why would we say that? You've not shown any meaningful use for the
> search lines on an LFS system.
Rather than stating "The search lines are not meaningful ...",
this exercise has revealed that the next 2 lines are equivalent in their effect:
search --no-flop
On 01/07/10 11:13, splotz90 wrote:
>Am 01.07.2010 11:09, schrieb HouHongxun:
>> Even though /boot is a separate partition, we don't need to mount it.
>
> Ok, so we say "The search lines are only meaningful for LFS systems if a
> separate boot partition is used." ?
Why would we say that? You've
On 01/07/10 09:23, splotz90 wrote:
> Here is an example:
>
> /dev/sda1 --> LFS-system ( / partition)
> /dev/sda2 --> unformatted partition
> /dev/sda3 --> boot partition ( /boot)
>
> the fstab:
>
> ...
> /dev/sda1 /ext3defaults11
> /dev/sda3/bootext3defaults
On 6/30/10, Bruce Dubbs wrote:
>
> I'll ask the question again. How is search useful in an LFS environment
> where we don't have initrd available?
>
By using search, one can entirely avoid using the grub drive and
partition notation. e.g., (hd0,1)
I alone find that potentially useful.
--
htt
On 7/1/10, splotz90 wrote:
> Ok, so we say "The search lines are only meaningful for LFS systems if a
> separate boot partition is used." ?
A separate boot partition is not a necessity for using search. I works
for me with boot as a subdirectory on the root / partition.
I don't know how general
Am 01.07.2010 11:09, schrieb HouHongxun:
> Even though /boot is a separate partition, we don't need to mount it.
Ok, so we say "The search lines are only meaningful for LFS systems if a
separate boot partition is used." ?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.
On 2010年07月01日 16:23, splotz90 wrote:
>
> But if we are still using /dev/sda3 for /boot in fstab, the mount of the
> boot partition will fail (/dev/sda3 doesn't exist anymore).
>
> This fstab would be better:
>
> ...
> /dev/sda1
> /ext3defaults11
>
> # boot
Am 01.07.2010 09:27, schrieb Nathan Coulson:
> On Wed, Jun 30, 2010 at 11:24 PM, splotz90 wrote:
>> Am 01.07.2010 05:17, schrieb Bruce Dubbs:
>>> I'll ask the question again. How is search useful in an LFS
>>> environment where we don't have initrd available?
>> As I already said:
>>
>> The se
On Wed, Jun 30, 2010 at 11:24 PM, splotz90 wrote:
> Am 01.07.2010 05:17, schrieb Bruce Dubbs:
>> I'll ask the question again. How is search useful in an LFS
>> environment where we don't have initrd available?
> As I already said:
>
> The search command is only useful if we're using a seperate bo
Am 01.07.2010 08:24, schrieb splotz90:
> Am 01.07.2010 05:17, schrieb Bruce Dubbs:
>> I'll ask the question again. How is search useful in an LFS
>> environment where we don't have initrd available?
> As I already said:
>
> The search command is only useful if we're using a seperate boot
> par
Am 01.07.2010 05:17, schrieb Bruce Dubbs:
> I'll ask the question again. How is search useful in an LFS
> environment where we don't have initrd available?
As I already said:
The search command is only useful if we're using a seperate boot
partition ...
With help of the search line, GRUB can
linux fan wrote:
> At any rate, grub2 search line is not totally useless, and that is nice to
> know.
Yes, we know what it does. It sets a variable in
the GRUB environment based on UUID or LABEL.
The variable can be used to find the kernel image location, but
how is it useful in an LFS environ
On 6/30/10, Bruce Dubbs wrote:
> This is a catch-22. udev populates /dev which is needed to determine
> partitions. The only alternative is to do raw device searches and the
> number of different device types and filesystems on those devices makes
> this really prohibitive. GRUB does it, but t
On 2010年07月01日 09:01, linux fan wrote:
> On 6/30/10, Bruce Dubbs wrote:
>
>> The Linux kernel generally needs to be told what it's root partition is.
>> To the best of my knowledge, it understands root=/dev/ and
>> root=LABEL=label-name.
> I so wished that to be true that I grasped at straws,
linux fan wrote:
> On 6/30/10, Bruce Dubbs wrote:
>
>> The Linux kernel generally needs to be told what it's root partition is.
>> To the best of my knowledge, it understands root=/dev/ and
>> root=LABEL=label-name.
>
> I so wished that to be true that I grasped at straws, but kernel won't
> und
linux fan wrote:
> On 6/30/10, Stuart Stegall wrote:
>
>> ro is also unnecessary since around 2.2.x (I don't swear to that, it
>> could have been 2.1.x or 0.99.) The kernel is read-only by default.
>
> Confirmed.
> I requested a forced fsck by placing empty file with touch /forcefsck
> I boote
On 6/30/10, Bruce Dubbs wrote:
>
> The Linux kernel generally needs to be told what it's root partition is.
> To the best of my knowledge, it understands root=/dev/ and
> root=LABEL=label-name.
I so wished that to be true that I grasped at straws, but kernel won't
understand
root=LABEL=label-nam
On 6/30/10, Stuart Stegall wrote:
> ro is also unnecessary since around 2.2.x (I don't swear to that, it
> could have been 2.1.x or 0.99.) The kernel is read-only by default.
Confirmed.
I requested a forced fsck by placing empty file with touch /forcefsck
I booted as previously with no "ro" pa
On Wed, Jun 30, 2010 at 4:03 PM, Stuart Stegall wrote:
> On Wed, Jun 30, 2010 at 5:24 PM, Bruce Dubbs wrote:
>> Andrew Benton wrote:
>>> On 30/06/10 19:33, Stuart Stegall wrote:
Seems like it should be the simplest way possible. Personally I don't
like the grub-mkconfig - has failed to
On Wed, Jun 30, 2010 at 5:24 PM, Bruce Dubbs wrote:
> Andrew Benton wrote:
>> On 30/06/10 19:33, Stuart Stegall wrote:
>>> Seems like it should be the simplest way possible. Personally I don't
>>> like the grub-mkconfig - has failed to work for me a few times, and I
>>> believe it does that due t
> So, regardless if you search or not, or set root manually, this has no
> effect once the kernel boots.
That's my understanding too.
> You either need root=/dev/sda1, or you
> need to use rdev (used to be in util-linux) to set the root. I
> believe when you compile the kernel, rdev is set au
Andrew Benton wrote:
> On 30/06/10 19:33, Stuart Stegall wrote:
>> Seems like it should be the simplest way possible. Personally I don't
>> like the grub-mkconfig - has failed to work for me a few times, and I
>> believe it does that due to my host system.
>>
> grub-mkconfig has never worked for m
On Wed, Jun 30, 2010 at 2:10 PM, Andrew Benton wrote:
> On 30/06/10 19:33, Stuart Stegall wrote:
>>
>> Seems like it should be the simplest way possible. Personally I don't
>> like the grub-mkconfig - has failed to work for me a few times, and I
>> believe it does that due to my host system.
>>
>
On Wed, Jun 30, 2010 at 2:57 PM, Nathan Coulson wrote:
> On Wed, Jun 30, 2010 at 2:10 PM, Andrew Benton wrote:
>> On 30/06/10 19:33, Stuart Stegall wrote:
>>>
>>> Seems like it should be the simplest way possible. Personally I don't
>>> like the grub-mkconfig - has failed to work for me a few ti
On 30/06/10 21:09, Sebastian Plotz wrote:
> If the root parameter (in the linux command) is omitted, then the kernel
> will use the partition it was compiled on.
>
I think you're right. I've just tried what linux fan suggested and it
didn't work. The kernel panic message on the screen said it was
On 30/06/10 19:33, Stuart Stegall wrote:
>
> Seems like it should be the simplest way possible. Personally I don't
> like the grub-mkconfig - has failed to work for me a few times, and I
> believe it does that due to my host system.
>
grub-mkconfig has never worked for me as I use btrfs for my roo
linux fan wrote:
> On 6/30/10, Sebastian Plotz wrote:
>
>> "The search lines are only meaningful for LFS systems if a separate boot
>> partition and a LABEL or UUID entry for this partition in /etc/fstab is
>> used."
>>
>
>
> It booted me and mounted /dev/sdd10
Excellent. Can you try it witho
Am Mittwoch, den 30.06.2010, 15:20 -0400 schrieb linux fan:
> It booted me and mounted /dev/sdd10
>
> With this in grub.cfg
> =
> menuentry "GNU/Linux, with Linux 2.6.33 (search only)" {
> insmod ext2
> search --no-floppy --fs-uuid --set
> 11b62acd-ee91-43f7-a6
On 6/30/10, Sebastian Plotz wrote:
> "The search lines are only meaningful for LFS systems if a separate boot
> partition and a LABEL or UUID entry for this partition in /etc/fstab is
> used."
>
It booted me and mounted /dev/sdd10
With this in grub.cfg
=
menuentry "GNU/Linu
Sebastian Plotz wrote:
> Am Mittwoch, den 30.06.2010, 13:44 +0100 schrieb Andrew Benton:
>> But it won't boot very far. The kernel won't be able to mount its root
>> partition unless you manually edit the grub.cfg or compile the kernel
>> with an initramfs
>>
>> Andy
> Yes, and it will work if yo
On Wed, Jun 30, 2010 at 12:41 PM, Sebastian Plotz
wrote:
> Am Mittwoch, den 30.06.2010, 13:44 +0100 schrieb Andrew Benton:
>> But it won't boot very far. The kernel won't be able to mount its root
>> partition unless you manually edit the grub.cfg or compile the kernel
>> with an initramfs
>>
>> A
Am Mittwoch, den 30.06.2010, 19:41 +0200 schrieb Sebastian Plotz:
> Am Mittwoch, den 30.06.2010, 13:44 +0100 schrieb Andrew Benton:
> > But it won't boot very far. The kernel won't be able to mount its root
> > partition unless you manually edit the grub.cfg or compile the kernel
> > with an init
Am Mittwoch, den 30.06.2010, 13:44 +0100 schrieb Andrew Benton:
> But it won't boot very far. The kernel won't be able to mount its root
> partition unless you manually edit the grub.cfg or compile the kernel
> with an initramfs
>
> Andy
Yes, and it will work if you're using a separate boot part
On 6/30/10, Andrew Benton wrote:
>
> But it won't boot very far. The kernel won't be able to mount its root
> partition unless you manually edit the grub.cfg or compile the kernel
> with an initramfs
>
It needs to be tested if it will boot based on the search line when the
linux line omits the "r
On 30/06/10 12:15, splotz90 wrote:
>
> I think the search line makes sense ... I tried to explain it in my last
> comment (http://wiki.linuxfromscratch.org/lfs/ticket/2698#comment:6):
>
> GRUB can boot if the device has changed (for example hd0,1 --> hd1,1) or
> if a new filesystem was created (-->
I think the search line makes sense ... I tried to explain it in my last
comment (http://wiki.linuxfromscratch.org/lfs/ticket/2698#comment:6):
GRUB can boot if the device has changed (for example hd0,1 --> hd1,1) or
if a new filesystem was created (--> the UUID has changed).
My suggestion:
HouHongxun wrote:
> 于 2010/6/28 14:39, Bryan Kadzban 写é“:
>> HouHongxun wrote:
>>> "root=/dev/sda7" after kernel's image belongs to kernel's parameters.
>> Right, but irrelevant here, see below. :-)
>>
>>> I don't think grub cares about kernel's parameters. file systems'
>>> uuid and root v
于 2010/6/28 14:39, Bryan Kadzban 写道:
> HouHongxun wrote:
>> "root=/dev/sda7" after kernel's image belongs to kernel's parameters.
> Right, but irrelevant here, see below. :-)
>
>> I don't think grub cares about kernel's parameters. file systems'
>> uuid and root variable used by grub is irrelev
HouHongxun wrote:
> "root=/dev/sda7" after kernel's image belongs to kernel's parameters.
Right, but irrelevant here, see below. :-)
> I don't think grub cares about kernel's parameters. file systems'
> uuid and root variable used by grub is irrelevant to "root=/dev/sdax"
> or "root=UUID=xxx
On 2010年06月28日 10:51, Bruce Dubbs wrote:
>
> The discussion is made a bit complicated because the same term is used
> for grub's root (set root= or perhaps search) and the kernel's root
> (root=/dev/sda7 in this example).
"root=/dev/sda7" after kernel's image belongs to kernel's parameters.
It
HouHongxun wrote:
> In fact, this error had been pointed out by splotz90 in
> http://wiki.linuxfromscratch.org/lfs/ticket/2698
> and
> http://wiki.linuxfromscratch.org/lfs/ticket/2699
>
> but unfortunately all two tickets have been closed.
>
> so i decide to start a new thread.
Yes, that is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Jun 28, 2010 at 10:07:08AM +0800, HouHongxun wrote:
>
> At first, the set command set "root" variable to partition (hd0,15)
> which does not exist in my system. then grub uses search command to
> find which partition has uuid
> "ab00fa9d-6571-
In fact, this error had been pointed out by splotz90 in
http://wiki.linuxfromscratch.org/lfs/ticket/2698
and
http://wiki.linuxfromscratch.org/lfs/ticket/2699
but unfortunately all two tickets have been closed.
so i decide to start a new thread.
the page below explains what the search command d
61 matches
Mail list logo
