I tried out today's boot.iso and things got further. It appears that the install was successful using encrypted raid 1 partitions. (This used to fail.) But when I tried to boot the system, I wasn't asked for a password. During the boot process /dev/root couldn't be mounted. Things continued for a short while and then hung up after some usb devices were detected. For a problem like this, what component should be used?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Bruno Wolff III wrote:
I tried out today's boot.iso and things got further. It appears that the install was successful using encrypted raid 1 partitions. (This used to fail.) But when I tried to boot the system, I wasn't asked for a password. During the boot process /dev/root couldn't be mounted. Things continued for a short while and then hung up after some usb devices were detected. For a problem like this, what component should be used?
As installation has succeeded I think that's either initrd's fault or some init scripts.
On Thu, Feb 28, 2008 at 10:10:52 +0100, Alexander Todorov atodorov@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Bruno Wolff III wrote:
I tried out today's boot.iso and things got further. It appears that the install was successful using encrypted raid 1 partitions. (This used to fail.) But when I tried to boot the system, I wasn't asked for a password. During the boot process /dev/root couldn't be mounted. Things continued for a short while and then hung up after some usb devices were detected. For a problem like this, what component should be used?
As installation has succeeded I think that's either initrd's fault or some init scripts.
Possibly. I did see the same message after doing an alpha install to try to clean things up afterward, which I hadn't seen before. Maybe this was some other intermittant problem showing up. I should get a chance to try out today's boot.iso.
On Thu, 2008-02-28 at 08:00 -0600, Bruno Wolff III wrote:
On Thu, Feb 28, 2008 at 10:10:52 +0100,
As installation has succeeded I think that's either initrd's fault or some init scripts.
Possibly. I did see the same message after doing an alpha install to try to clean things up afterward, which I hadn't seen before. Maybe this was some other intermittant problem showing up. I should get a chance to try out today's boot.iso.
It's a mkinitrd bug. wwoods filed it last night (I don't have the # off-hand) and hopefully we'll get to the bottom of it today.
Jeremy
On Feb 28, 2008, at 9:44 AM, Jeremy Katz wrote:
On Thu, 2008-02-28 at 08:00 -0600, Bruno Wolff III wrote:
On Thu, Feb 28, 2008 at 10:10:52 +0100,
As installation has succeeded I think that's either initrd's fault or some init scripts.
Possibly. I did see the same message after doing an alpha install to try to clean things up afterward, which I hadn't seen before. Maybe this was some other intermittant problem showing up. I should get a chance to try out today's boot.iso.
It's a mkinitrd bug. wwoods filed it last night (I don't have the # off-hand) and hopefully we'll get to the bottom of it today.
It's bug 435228.
Encryption doesn't make a difference - it's mkinitrd + LVM partitions listed as "LABEL=" or "UUID=". You can work around this by editing / etc/fstab to use device names (e.g. /dev/VolGroup00/LogVol00) and re- creating the initrd.
See http://wwoods.fedorapeople.org/rawhide.html for more rawhide status info.
-w
On Thu, Feb 28, 2008 at 12:17:27 -0500, Will Woods wwoods@redhat.com wrote:
It's bug 435228.
Encryption doesn't make a difference - it's mkinitrd + LVM partitions listed as "LABEL=" or "UUID=". You can work around this by editing / etc/fstab to use device names (e.g. /dev/VolGroup00/LogVol00) and re- creating the initrd.
See http://wwoods.fedorapeople.org/rawhide.html for more rawhide status info.
Thanks, I'll take a look at this and see if I can get it working today.
On Thu, Feb 28, 2008 at 12:17:27 -0500, Will Woods wwoods@redhat.com wrote:
It's bug 435228.
I took a look at the info you had, and will try to figure out some way to use it. Unfortunately on a fresh install, you can't (as far as I can tell) get a vt after the install is complete (before rebooting) in order to rerun mkinitrd.
Today's rawhide isn't out yet, so I am going to take a look and see if I can figure out if a patch got applied already. It might be easier to just wait for the rawhide push if that's the case. Otherwise there probably is a way to do it with a rescue disk.
On Fri, 2008-02-29 at 10:59 -0600, Bruno Wolff III wrote:
On Thu, Feb 28, 2008 at 12:17:27 -0500, Will Woods wwoods@redhat.com wrote:
It's bug 435228.
I took a look at the info you had, and will try to figure out some way to use it. Unfortunately on a fresh install, you can't (as far as I can tell) get a vt after the install is complete (before rebooting) in order to rerun mkinitrd.
VT switch was working for me on Wednesday -- has it been broken (... again)?
Today's rawhide isn't out yet, so I am going to take a look and see if I can figure out if a patch got applied already. It might be easier to just wait for the rawhide push if that's the case. Otherwise there probably is a way to do it with a rescue disk.
The patch hasn't been pushed into mkinitrd yet and there was still some back and forth as to what works and what doesn't I believe...
Jeremy
On Fri, Feb 29, 2008 at 20:47:59 -0500, Jeremy Katz katzj@redhat.com wrote:
On Fri, 2008-02-29 at 10:59 -0600, Bruno Wolff III wrote:
On Thu, Feb 28, 2008 at 12:17:27 -0500, Will Woods wwoods@redhat.com wrote:
It's bug 435228.
I took a look at the info you had, and will try to figure out some way to use it. Unfortunately on a fresh install, you can't (as far as I can tell) get a vt after the install is complete (before rebooting) in order to rerun mkinitrd.
VT switch was working for me on Wednesday -- has it been broken (... again)?
I couldn't use it at the end of an install, I had been able to switch during and install, but I am not sure if it was the same image though. It may be that that particular image had a problem that would be there now.
Unfortunately I could wait around work for the install to finish today, but it should be at the reboot prompt when I get in on Monday and I can try it again.
Today's rawhide isn't out yet, so I am going to take a look and see if I can figure out if a patch got applied already. It might be easier to just wait for the rawhide push if that's the case. Otherwise there probably is a way to do it with a rescue disk.
The patch hasn't been pushed into mkinitrd yet and there was still some back and forth as to what works and what doesn't I believe...
That's the conclusion I came to after checking koji. Koji is pretty neat. I won't be able to try again until Monday.
On Thu, Feb 28, 2008 at 12:17:27 -0500, Will Woods wwoods@redhat.com wrote:
It's bug 435228.
Encryption doesn't make a difference - it's mkinitrd + LVM partitions listed as "LABEL=" or "UUID=". You can work around this by editing / etc/fstab to use device names (e.g. /dev/VolGroup00/LogVol00) and re- creating the initrd.
See http://wwoods.fedorapeople.org/rawhide.html for more rawhide status info.
I was able to do an encrypted install today and successfully boot. The install iso was broken, but as suggested (by Jeremy I think) I was able to use the vmlinuz and initrd.img files and changed an existing grub.conf to point to them. There were some other new odd things but they weren't specifically related to this. Tomorrow I'll trying doing a more complicated case (encryption over raid) and if that works, probably end up just updating that (rather than reinstalling) until F9 is released.
On Thu, Feb 28, 2008 at 10:10:52 +0100, Alexander Todorov atodorov@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Bruno Wolff III wrote:
I tried out today's boot.iso and things got further. It appears that the install was successful using encrypted raid 1 partitions. (This used to fail.) But when I tried to boot the system, I wasn't asked for a password. During the boot process /dev/root couldn't be mounted. Things continued for a short while and then hung up after some usb devices were detected. For a problem like this, what component should be used?
As installation has succeeded I think that's either initrd's fault or some init scripts.
It looks like encryption over LVM has the same problem. I will test just encryption without any stacking and see if that works.
-
Alexander Todorov -
Bruno Wolff III -
Jeremy Katz -
Will Woods