*** Bug 739305 has been marked as a duplicate of this bug. ***

Still valid with Beta RC1, as the dupe shows.

Fred, we're going to need more information about the exact process you used for install, all I have so far is "Note that I was installing from USB from the DVD image." (which, BTW, is known to be a somewhat complicated case). What happens before you hit this bug?

Sure. 

So I went through a VM install to confirm the steps and tada tada, the VM install has 1 more screen which do not appear on the USB install:
Select installation language.

My process from USB install is:
- Use livecd-iso-to-disk from full DVD image to generate the USB disk
- Boot from USB
- 1st question is "Select keyboard type" in text mode (blue and red): I chose US
=> note that in the VM test above I had to chose a language first and both questions where in a graphical mode
- Prompts me that it's not production version: I select 'Install anyway'
- Next screen: Basic Storage
- Next screen: Fresh install
- next screen: hostname
=> then unexpected crash has happened...

Anything else you need me to do?

From the install guide:

"3.2.2.1. Creating Fedora USB Media in Fedora, Red Hat Enterprise Linux, and similar Linux distributions
Graphical and command-line tools are available to create Fedora USB media on computers that run Fedora, Red Hat Enterprise Linux, and Linux distributions derived from Red Hat Enterprise Linux. The graphical tool and the works only with the Fedora live image. To create Fedora USB media from the distribution image or minimal boot media image, use the command-line method described in Section 3.2.2.1.3, “Making Fedora USB Media with dd”. "

so, writing the DVD image to USB with livecd-iso-to-disk is not supported: only writing it with dd, apparently. How did you write it?

So that has changed for F16? 

I remember reading livecd-iso-to-disk working with full DVD image and that's how I did for F15 without any trouble. I'm trying to find the wiki page but it seems the wiki had a revamp.

Found it! Here is the link:
http://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#How_to_Make_a_bootable_USB_Drive_to_Install_Fedora_instead_of_using_a_physical_DVD
and the example is clearly using both livecd-iso-to-disk and the DVD image.

yeah, I was looking at the install guide, and it explicitly says that livecd-iso-to-disk only works with the live image, so they're in conflict.

There have been changes to livecd-iso-to-disk lately which may affect its use for writing the DVD image; are you on livecd-tools 16.6?

please do try with dd (I'm hoping the image is a hybrid this time...) and see if it changes things, that will help triage down the problem, regardless of whether it 'should' work with livecd-iso-to-disk.

I'm using livecd-tools-15.7-1.fc15.i686 (from F15). I'll try dd and revert back.
Thank you.

dd didn't work, the USB stick wouldn't boot. I will try to upgrade livecd-tools then and try again.

(can't get livecd-tools easily on F15). Thinking about it I think one of the Alpha RCs went a bit further but then failed later without the option to report a bug. I'm going to try with a live image and livecd-iso-to-disk available on F15

Downloaded the live CD Desktop version, used livecd-iso-to-disk and I'm getting an irrevocable error on the live desktop asking me to log out and try again:
=> trying again doesn't change anything. I copied over the .xsession-error.log and can attach it here (though it should be a different bug).

What do you recommend I do now?
Thank you

oh, that one's known - https://bugzilla.redhat.com/show_bug.cgi?id=738803. booting with 'enforcing=0' will work around it. For this one, we should wait for anaconda team to take a look and see what they think. thanks!

This doesn't seem to be an issue of s-c-date, as the issue seems to be that the language is never set up properly if this happens. Which component would be responsible for that in this case, livecd-tools, anaconda?

So yes, the installation language question is not asked, and the keyboard layout question is asked in text mode: a silent crash? I don't mind testing anything if it can be helpful.

Thank you.

anaconda, sorry, thought the bug was already assigned there.

fred: can you test if you hit this if you write the dvd installer to an actual dvd? and can you test if you hit it if you choose 'basic graphics' mode? just trying to check if this is actually related to writing to USB or if it's some quirk with your system or what. thanks!

Sorry for the delay, got some troubles with my internal DVD drive. So using an external drive I burnt a real DVD booted from it and all went fine (just like in the VM): got the installation language question in graphic mode, the keyboard layout, selected new install, time zone and root password. Anything else?

Language isn't asked, because you're doing a live install and the language should have been set up by the live environment.  Previously, this happened via gdm.  It sounds like this is no longer the case, and that some communication for what should be happening how did not happen.

@chris: the DVD I burnt is the full DVD install (not the live image, the one failing on the USB stick and not with a real DVD as a medium. So there is no live session at all. I am comparing apples with apples.

oops I realize my former response was less than clear, so let me try it again: the image I burnt on the physical disk and tried is the full DVD install. This bug is about this image not working using USB stick. Adam was asking me to test that same image with a physical media to be able to identify whether the problem was coming from the image itself or my machine.

So there is no live session, and while using the DVD I get installation language asked and can install, while when using the same image with a USB stick I do not get that question and the installation fails as mentioned previously (bug report was automatically generated at failure time).

I hope that's better worded.

can you attach anaconda's logs to the bug? after an install they should be present in /var/log/anaconda or as /var/log/anaconda*.log (I'm never quite sure which).

er, logs from the failure case, that is. logs from the success case to compare are optional, but might help. thanks!

Let me try to understand: in case of failure there is no install and I am left with a USB stick at the end of the bug report process. So the logs you want me to get would be on that USB stick and I should be able to get to a terminal to copy them over (or are they persistent files and can I find them at the next reboot on my machine by reading the USB stick)?

Thank you.

sorry, I may have been on crack with that last comment. or thinking of another bug. but hey, logs are always good.

when an install is in progress, i think the logs wind up in /tmp. you can hit ctrl-alt-f4 (I think it is) to get to a console. getting the logs out of the installer environment is an exercise left for the reader. =) you can probably mount a usb stick and copy them to that.

thanks! we should see if anyone else can reproduce this, too...

Created attachment 524127 [details]
anaconda.log

CTRL+F2 did the trick (CTRL+F4 didn't seem to give me a prompt)

Created attachment 524128 [details]
anaconda-tb-MTpkcD

There was also this file which looks like a temporary file. As you said any log can be good here it is

"04:58:49,574 ERR loader: unable to set to requested language en_US.utf8"

kinda jumps right out at you. No indication as to why not, though. I note my log - from an install with F15 - reads:

03:43:11,662 INFO anaconda: anaconda called with cmdline = ['/usr/sbin/anaconda', '--liveinst', '--method=livecd:///dev/mapper/live-osimg-min', '--lang', 'en_US.UTF-8'] - see the difference in case and the extra hyphen. I'm not sure exactly what generates that command, and how it decides on the language...but I do see:

04:58:46,292 INFO loader: kernel command line:
04:58:46,292 INFO loader:     initrd=initrd.img
04:58:46,292 INFO loader:     LANG=en_US.utf8

and:

/proc/cmdline:
initrd=initrd.img LANG=en_US.utf8 repo=hd:UUID=a934b6f9-b810-4a8e-9aa6-060152b1d5f5:/ quiet BOOT_IMAGE=vmlinuz 

so it seems that, somehow, it was on the kernel command line.

Just tried Beta RC2 and bug still in there. But I guess that was expected. Just wanted to follow up.

I'm still confused as to how you wound up with en_US.utf8 (instead of en_US.UTF-8) on the kernel command line. Can you check what it looks like at the bootloader screen before you boot the installer?

Kernel command line has en_US.UTF8. I tried to add the '-' between F and 8 but then it quickly ends up with 'BUG: kernel cannot handle NULL pointer dereference' or a similar message. Then there is a short trace on the screen and the system halts.

I'm curious, does it mean no one can reproduce the bug?

I haven't been able to, and I haven't seen anyone else report the same thing...

wow that's amazing. I also wonder how that command line gets UTF8 then. Could it be the --reset-mbr option from livecd-iso-to-disk? (my brain says no, but considering the situation I'm really puzzled now)

I'm downloading RC3 and will try again. I have little hope though now.

*** Bug 742355 has been marked as a duplicate of this bug. ***

RC4 came out before I could test RC3... so with RC4 same behaviour, same kernel command line (utf8). I'll try to add information if this can help.
1. I noticed I need to --reset-mbr each time or else the USB stick doesn't boot. This wasn't the case for F15.
2. What I typed exactly to generate the USB stick is:
sudo umount /dev/sdb1
sudo livecd-iso-to-disk --format --reset-mbr Fedora-16-BetaRC4-i386-DVD.iso /dev/sdb1
[..] <- image check
WARNING: THIS WILL DESTROY ANY DATA ON /dev/sdb!!!
Press Enter to continue or ctrl-c to abort

Waiting for devices to settle...
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=LIVE
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
489600 inodes, 1955328 blocks
97766 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2004877312
60 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
/home/fred/Downloads/Fedora-16-BetaRC4-i386-DVD.iso uses initrd.img w/o install.img
Size of DVD image: 3588
Size of isolinux/initrd.img: 128
Available space: 6992
Copying DVD image to target device.
Updating boot config file
Installing boot loader
/media/tgttmp.8DxHHP/syslinux is device /dev/sdb1
Target device is now set up with a Live image!

Further testing with the kernel command line editing (as I said above adding '-' didn't work) proved useful: totally removing 'LANG=en_US.utf8' from the command line later prompts for installation language (and keyboard choice) leading to a successful installation. 

While this is not a fix, it at least provides a workaround for people hit by this bug and not wanting to burn a DVD to install.

are you using --format when writing the USB stick, or not? I tend to use --format.

It's probably worth noting this in Common Bugs as we don't know what's causing it...

(In reply to comment #36)
> are you using --format when writing the USB stick, or not? I tend to use
> --format.

Yes I use both --format and --reset-mbr . It seems compulsory for F16 as otherwise the key doesn't boot. I don't think I had this issue with F15, but that's really not a problem imho (maybe documentation should be updated if confirmed though).

oh. so, i think i know what causes this now...

[adamw@adam ~]$ echo $LANG
en_US.utf8
[adamw@adam ~]$ cat /etc/fedora-release
Fedora release 16 (Verne)
[adamw@adam ~]$ 

and in /usr/bin/livecd-iso-to-disk :

echo "Updating boot config file"
# adjust label and fstype
if [ -n "$LANG" ]; then
    kernelargs="$kernelargs LANG=$LANG"

so it looks like livecd-iso-to-disk tries to write a language parameter based on the system on which the USB stick is created, and it's writing it in a form which the installer isn't happy with.

I'm not sure if it's right for livecd-iso-to-disk to this at all, frankly. Why should we assume the USB stick is going to be _used_ on the same system and by the same person as the ones where it's being _created_?

This dates back to:

commit 827cd5bb05fb45a6df1ae907e63b7213af5b8501
Author: Bill Nottingham <notting>
Date:   Sat Sep 11 13:09:50 2010 -0500

    Set default boot language for USB images to the current locale.
    
    Signed-off-by: Bruno Wolff III <bruno>

so I think it would be in F15 and F16, but then, I don't think this bug hit F15; maybe anaconda in F15 was more tolerant to the 'wrong' lang setting?

echo $LANG returns 'en_US.utf8' on 14, 15 and 16, so doesn't look like that's changed for a while...

*** Bug 742355 has been marked as a duplicate of this bug. ***

I am not really sure we support a usb stick created from the non-live dvd using the livecd-iso-to-disk tool. That simply is wrong and this might be closed as won't fix.

(In reply to comment #40)
> echo $LANG returns 'en_US.utf8' on 14, 15 and 16, so doesn't look like that's
> changed for a while...

Something did in fact, we now generate some of the locales data ourselves if loader is run (conversely on a livecd where loader doesn't run they are already present on the cd).

I will take a look at this, as this causes the installation to fail whenever someone passes lang=en_US.utf8 as the kernel boot line (which is what the livecd tools added there for us). However, note that this won't in any case guarantee usb sticks made in the described way are able to install anything. I think you need to use a different tool, perhaps just dd would do the trick?

(In reply to comment #42)
> I am not really sure we support a usb stick created from the non-live dvd using
> the livecd-iso-to-disk tool. That simply is wrong and this might be closed as
> won't fix.

Ales,

I am sorry but that statement is just absurd. Taking the standard DVD image
and putting it on a USB stick to avoid burning a DVD is one of the most
common ways of installing Fedora and has to be supported.

Live CDs are just CDs and not complete, there are many cases where you want
to do an install where you don't have net access or lousy net access, so
having to download the rest isn't an option.

Anaconda's handling of LANG needs to be fixed.

How about applying a LANG filter as anaconda is launched which converts
$LANG into any of the values anaconda supports?

Thanks,
Jes

well, just tested and I can reproduce this indeed, now I figured out the procedure exactly :/.

gonna have a look at f15 and see exactly what happens there.

ales: using livecd-iso-to-disk with the DVD has worked for a long time and is at least de facto supported. note that you can't, for instance, produce a USB stick which is EFI bootable with a simple dd, but you can with livecd-iso-to-disk .

We do reference this sometimes in documentation - https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB claims:

"The livecd-iso-to-disk method also works with DVD install iso images, even though these are not Live images."

and the ability to write the DVD was intentionally written into livecd-iso-to-disk by wtogami:

http://wtogami.livejournal.com/32343.html

I think overall we do kind of intend for this to work.

(In reply to comment #45)
> ales: using livecd-iso-to-disk with the DVD has worked for a long time and is
> at least de facto supported. note that you can't, for instance, produce a USB
> stick which is EFI bootable with a simple dd, but you can with
> livecd-iso-to-disk .

OK, I stand corrected. In that case we are actually good because once I fix the language problem the whole thing should work.

Proposing as NTH.

note that I think the 'incorrect' LANG variable comes from Live installs. It seems that if you boot an F14/F15/F16 live image (and install from it), you get LANG=en_US.utf8 , but if you install from the netinst or DVD, you get LANG=en_US.UTF-8 . I'll have to look into that and file a separate bug.

Some information/explanations for those involved in Anaconda locale settings:

1) because of its considerable size we no longer ship /usr/lib/locale/locale-archive on the installation ramdisk (lorax commit ee955f3ad1ae6b7b302da169d8528742b9df6abf), instead there are source files for all locales used by Anaconda.

2) depending on several factors (lang= boot arg, user choice, dvd installation etc.) we generate locale-archive using 'localedef'. We usually do so in loader but this has failed in the case of our bug.

3) skipping loader (dvd installs) without a lang= argument was causing problems before, that's why second point of locale generation was introduced in Anaconda (Anaconda commit eb7732732d579af57d194131b61e75f5750e19a6). This is indeed triggered in our case too and default en_US.UTF-8 locale is generated (despite the lang=en_US.utf8 paramter on the command line that we don't recognize at the moment). Unfortunately the way the locale module works is remembering the existing compiled locales at its initialization. So a later call to

 locale.setlocale(locale.LC_ALL, "")

 fails nontheless.

Fix posted for review: https://www.redhat.com/archives/anaconda-devel-list/2011-October/msg00021.html

Discussed at 2011-10-07 NTH review meeting. Accepted as NTH due to severity of impact, can break install without obvious workaround.

Fix pushed to f16-branch: 1af4774178adb994d20016509375e7569b7fc100, 572c04330dbd6185693fb556a9c6e46355d3bc66.

Fixed on master: 152149133732a45a13f3c8ab728de767536a09ab, fd6085f6c5812373d4b1bdbefd6a10aa9eff2e61.

Great. Thank you very much for all the efforts. What would be the best way to test a new image now (or should I say: where do I find an image to test)?

New .isos are put to pub/fedora/linux/development/16 on your favourite Fedora mirror. You'll have to wait around a week for the new Anaconda version to propagate there.

*** Bug 744029 has been marked as a duplicate of this bug. ***

Fixed in Alpha TC1 (command line still has the uft8 parameter but anaconda has no issue with it).

Can confirm it seems to survive for me in TC1 as well

Jes

Thanks for testing! Let's close this.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers