opensuse
[Arriba] [Todas las Listas]

Re: [opensuse] Control doble: /bota en REDADA 1

To: opensuse@xxxxxxxxxxxx
Subject: Re: [opensuse] Control doble: /bota en REDADA 1
From: dwgallien <dwgallien@xxxxxxxxx>
Date: Sat, 8 Oct 2011 17:47:43 -0400
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 08 Oct 2011 17:48:28 -0400
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <20111008170539.GC6296@blinkenlights.visv.net>
List-archive: <http://lists.opensuse.org/opensuse/>
List-help: <mailto:opensuse+help@opensuse.org>
List-owner: <mailto:opensuse+owner@opensuse.org>
List-post: <mailto:opensuse@opensuse.org>
List-subscribe: <mailto:opensuse+subscribe@opensuse.org>
List-unsubscribe: <mailto:opensuse+unsubscribe@opensuse.org>
Mailing-list: contact opensuse+help@xxxxxxxxxxxx; run by mlmmj
References: <20110930205915.GB10004@blinkenlights.visv.net> <4E894A7B.9030404@aljex.com> <20111008170539.GC6296@blinkenlights.visv.net>
User-agent: KMail/1.13.6 (Linux/3.0.3-1-desktop; KDE/4.6.0; x86_64; ; )
> En *Mon, *Oct 03, Brian *K. El Blanco escribió:
>  
> > *Yast no instalará el 2*nd *mbr.
> > 
> > *Yast Correrá *grub, y *grub , suponiendo quieres tener *grub etapa 
> > propia1 en el *mbr y no un genérico *mbr.
> > 
> > Justo tienes que tener líneas así en /*etc/*grub.*conf, El cual puedes editar directamente fuera de de *yast, o en *yast hay unas opciones adelantadas 
> > que incluye una opción para editar el mismo archivo de dentro de *yast.
> > 
> > *setup (*hd0) (*hd0,0)
> > *setup (*hd1) (*hd1,0)
> 
> *Hmm. Mi /*etc/*grub.*conf Tiene (sin mi intervención)
> 
> *setup --etapa2=/bota/*grub/etapa2 --fuerza-*lba (*hd0) (*hd0,0)
> *setup --etapa2=/bota/*grub/etapa2 --fuerza-*lba (*hd1,0) (*hd0,0)
> *quit
> 

*Re *YaST, mientras te lata dentro de la Bota *Loader el módulo a mano edita el /*etc/*grub.*conf Archivo, dependiendo a vuestro *setup, cuándo vuelves a las pantallas anteriores *YaST cambiará el archivo.  Por ejemplo, si editaste la segunda línea para ser (*hd1) (*hd1,0) o (*hd1) (*hd0,0) para instalar *grub al *MBR del segundo disco, después de que pegaste *OK que te regresa para Chutar *Loader Instalación, aquella línea será sacada por *YaST porque el módulo no apoya instalando a un segundo disco *MBR.  Así que esta instalación necesitaría ser hecha de la línea de orden.

Esto levanta la cuestión pregunté anteriormente que no vi una respuesta puesto que.  En vuestro original *msg, apareció quisiste tener *grub bota del segundo disco en el acontecimiento el primer *disco* fallado, y todavía tener un "sistema laborable".  Esta cuestión no puede ser contestada sin saber cómo la raíz es montada en el disco(*s) y qué tipo de REDADA estás utilizando.  Aparte del manual instala, es normalmente trivial de conseguir el *bios para llamar *grub del segundo disco.  Pero  también quieres cargar el OS del segundo disco, desde el primer disco ha fallado?  Aquello es un asunto diferente *altogether.  

> > La primera línea encima pone *grub etapa1 y 1.5 al *mbr de paseo 0 (*hd0),
> > y consigue la etapa1 y 1.5 imágenes de /*grub o /bota/*grub en partición 
> > 0 de paseo 0 (*hd0,0)
> > 
> > La segunda línea es todo igual pero en paseo 1.
> > 

Aquella segunda línea no es igual porque (*hd1,0) (*hd0,0), instala *grub etapa1 al sector de bota de la primera partición en el segundo disco, señalándolo para encontrar etapa2 en la primera partición del primer disco; la primera línea está instalando etapa1 al *MBR del primer disco.  Si quieres *grub en el segundo disco para ser llamado por el *bios, lo instala al *MBR del segundo disco, *i.*e., cambio (*hd1,0) a (*hd1).  El encima segunda línea (*hd1,0) *syntax puede ser utilizado si genérico *MBR el código ha sido instalado y *sdb1 la bandera activa ha sido puesta.  El *remainder de la línea, (*hd0,0), es correcto sólo si estás llamando etapa2 del primer disco.  Llamando etapa2 y el *kernel del segundo disco sería (*hd1,1).  Pero, otra vez, ver mi cuestión encima.

> > Una vez pusiste que 2*nd (o 3*rd 4*th *etc...) Líneas en *grub.*conf, consiguen 
> > ejecutados cada tiempo *yast o *zypper o *rpm hace un *kernel actualizar o cualquier 
> > tiempo tú a mano corrido *grub-instalar o *grub --lote </*etc/*grub.*conf
> 

Un punto de *clarification *re el encima "*grub-instalar".  En *openSUSE, aquel guión no es igual cuando el guión del mismo nombre que viene con el *vanilla *grub paquete.  En *openSUSE, todo este guión  es corrido la orden de lote encima.  En *vanilla *grub, los intentos de guión para hacer mucho más, esencialmente lo que *YaST está haciendo.  El *vanilla *grub-instalar el guión es todavía en *openSUSE, pero bajo el nombre "*grub-instalar.*unsupported".

> Mientras respetando vuestros comentarios (y útil *url) con respecto a *RTFM, lo es 
> seguro de correr cualquiera del encima *grub órdenes mientras corriendo un sistema 
> normalmente, o tener que yo  él de un disco de rescate o intentar caer a un *grub
> puntual en un *reboot?
> 
> > Para un sencillo *setup con sólo un par de paseos, probablemente no te tienes que preocupar sobre hacer seguro "*hd1" significa lo que lo piensas significa. Probablemente 
> > *yast bota poblada /automáticamente/*grub/dispositivo.Mapa con cada paseo en 
> > vuestro sistema, pero podrías querer al menos tomar una mirada en él y satisfacer 
> > tú mira bien. Aquellas líneas en *grub.*conf  No _realmente_ 
> > malo cualquier cosa por ellos. "*hd0" y *hd1 "" es totalmente definido en 
> > dispositivo.Mapa
> 
> *Yeah, su justo dos discos, y /bota/*grub/dispositivo.Miradas de mapa bien.
>

Desde vuestro sistema sólo tiene 2 discos, el resultado probablemente será el mismo a toda costa de de dónde instalas *grub.  Aquello dijo, nota que el *grub pela que hace el instalar, sólo utiliza dispositivo.Mapa cuándo está siendo corrido de un OS montado.  Si te corrido el pelar fuera del OS o de un disco de rescate que no monta la raíz, intentará para determinar la secuencia de bota del disco por hacer una llamada de consulta al *bios.  En aquel caso puede o no puede imaginar fuera de la secuencia que depende en el *bios.  Tan cuando fuera del corriendo OS es siempre una idea buena de utilizar el *grub "encuentra" orden para ser seguro estás trabajando con el disco(*s) pretendes ser. 

> 
> > Realmente hay no respuestas sencillas a cuestiones sobre cómo para montar 
> > *grub. Tú (no justo tú personalmente, cualquiera que quiere saber cómo para hacerlo trabajo) tener que sencillamente leído el *grub manual. Explica cómo las partes 
> > trabajan juntas y tiene vínculos a explicaciones sobre los problemas 
> > inevitables del OS no realmente siendo capaz de saber lo que el BIOS hará 
> > o cómo el BIOS "ve" los paseos o lo que lo conduce incluso ve o lo que 
> > lo ordena les ve dentro o lo que los paseos pueden haber sido a mano puesto para chutar 
> > primer o último o totalmente ignorado. Todas las  cuestiones son ya contestado allí.
> > 
> > *http://Www.gnu.org/software/*grub/manual/*legacy/*grub.*html#*setup
> 
> *Thanks Otra vez.
> 
> 
> 
> Michael
> 
-- 
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
para contactar el dueño, *e-correo: *opensuse+owner@xxxxxxxxxxxx


> On Mon, Oct 03, Brian K. White wrote:
>  
> > Yast won't install the 2nd mbr.
> > 
> > Yast will run grub, and grub will, assuming you want to have grub's own 
> > stage1 in the mbr and not a generic mbr.
> > 
> > You just have to have lines like this in /etc/grub.conf, which you can 
> > edit directly outside of yast, or in yast there is an advanced options 
> > that includes an option to edit the same file from within yast.
> > 
> > setup (hd0) (hd0,0)
> > setup (hd1) (hd1,0)
> 
> Hmm. My /etc/grub.conf has (without my intervention)
> 
> setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0,0)
> setup --stage2=/boot/grub/stage2 --force-lba (hd1,0) (hd0,0)
> quit
> 

Re YaST, while you can within the Boot Loader module manually edit the /etc/grub.conf file, depending upon your setup, when you go back to the previous screens YaST will change the file.  For example, if you edited the second line to be (hd1) (hd1,0) or (hd1) (hd0,0) in order to install grub to the MBR of the second disk, after you hit OK which returns you to Boot Loader Installation, that line will be removed by YaST because the module does not support installing to a second disk MBR.  So this installation would need to be done from the command line.

This raises the question I asked previously which I didn't see a reply for.  In your original msg, it appeared you wanted to have grub boot from the second disk in the event the first *disk* failed, and still have a "working system".  This question can't be answered without knowing how the root is set up on the disk(s) and what type of RAID you are using.  Aside from the manual install, it's usually trivial to get the bios to call grub from the second disk.  But do you also want to load the OS from the second disk, since the first disk has failed?  That's a different matter altogether.  

> > The first line above puts grub stage1 and 1.5 into the mbr of drive 0 (hd0),
> > and gets the stage1 and 1.5 images from /grub or /boot/grub on partition 
> > 0 of drive 0 (hd0,0)
> > 
> > The second line is all the same but on drive 1.
> > 

That second line is not the same because (hd1,0) (hd0,0), installs grub stage1 to the boot sector of the first partition on the second disk, pointing it to find stage2 on the first partition of the first disk; the first line is installing stage1 to the MBR of the first disk.  If you want grub on the second disk to be called by the bios, install it to the MBR of the second disk, i.e., change (hd1,0) to (hd1).  The above second line (hd1,0) syntax can be used if generic MBR code has been installed and sdb1's active flag has been set.  The remainder of the line, (hd0,0), is correct only if you are calling stage2 from the first disk.  Calling stage2 and the kernel from the second disk would be (hd1,1).  But, again, see my question above.

> > Once you put that 2nd (or 3rd 4th etc...) lines in grub.conf, they get 
> > executed every time yast or zypper or rpm does a kernel update or any 
> > time you manually run grub-install or grub --batch </etc/grub.conf
> 

A point of clarification re the above "grub-install".  In openSUSE, that script is not the same as the script of the same name which comes with the vanilla grub package.  In openSUSE, all this script does is run the batch command above.  In vanilla grub, the script attempts to do much more, essentially what YaST is doing.  The vanilla grub-install script is still in openSUSE, but under the name "grub-install.unsupported".

> While respecting your comments (and helpful url) regarding RTFM, is it 
> safe to run either of the above grub commands while running a system 
> normally, or should I do it from a rescue disk or try to drop into a grub
> prompt at a reboot?
> 
> > For a simple setup with only a couple of drives, you probably don't have 
> > to worry about making sure "hd1" means what you think it means. Probably 
> > yast automatically populated /boot/grub/device.map with every drive in 
> > your system, but you might want to at least take a look at it and 
> > satisfy yourself it looks right. Those lines in grub.conf don't _really_ 
> > mean anything by themselves. "hd0" and "hd1" are totally defined in 
> > device.map
> 
> Yeah, its just two disks, and /boot/grub/device.map looks right.
>

Since your system only has 2 disks, the result will probably be the same regardless of from where you install grub.  That said, note that the grub shell which does the install, only uses device.map when it is being run from a mounted OS.  If you run the shell outside the OS or from a rescue disk that does not mount the root, it will attempt to determine the disk boot sequence by making a query call to the bios.  In that case it may or may not figure out the sequence depending on the bios.  So when outside the running OS it's always a good idea to use the grub "find" command to be sure you are working with the disk(s) you intend to be. 

> 
> > Really there are no simple answers to questions about how to set up 
> > grub. You (not just you personally, anyone who wants to know how to make 
> > it work) must simply read the grub manual. It explains how the parts 
> > work together and has links to explanations about the unavoidable 
> > problems of the OS not really being able to know what the BIOS will do 
> > or how the BIOS "sees" the drives or what drives it even sees or what 
> > order it sees them in or what drives may have been manually set to boot 
> > first or last or totally ignored. All questions are already answered there.
> > 
> > http://www.gnu.org/software/grub/manual/legacy/grub.html#setup
> 
> Thanks again.
> 
> 
> 
> Michael
> 
-- 
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx


<Anterior por Tema] Tema Actual [Siguiente por Tema>