Windows versions put CR/LF line terminators in text files.

Bug #322905 reported by bboyle on 2009-01-29
4
Affects Status Importance Assigned to Milestone
UNetbootin
Undecided
Geza Kovacs

Bug Description

The Windows installer will create a LiveUSB drive that sometimes will not boot. I have determined that this is likely due to the fact that it terminates lines in text files (configuration files, etc) that it generates with a CR/LF instead of the Linux/Unix LF terminator. This has caused some distributions to fail to boot at all, though if the Linux version of UNetbootin is used it will, or sometimes simply fail to finish the boot and leave the user in a limited text command-line shell. For example, the /syslinux.cfg file is corrupted in that it is a DOS, not a Linux file.

This was reported to the bug tracker accessible from http://sourceforge.net/projects/unetbootin/ but those bugs do not appear to be linked here. The bug ID was 2498946.

Geza Kovacs (gezakovacs) wrote :

Yes the software does put Windows-style line terminators in the syslinux.cfg but nevertheless it shouldn't ever matter; syslinux supports reading from text files with either newline style. All other files are copied verbatim from the ISO so it won't affect those. Since you're reaching a busybox shell rather than hanging on a syslinux error it means that it read syslinux.cfg and loaded the kernel just fine, just that Ubuntu is unable to locate filesystem.squashfs because it for some reason can't mount the USB drive or something, the issue is something entirely other than an issue with the syslinux.cfg or ldlinux.sys files. Try reformatting the USB drive under Windows if possible, perhaps Ubuntu is having issues with detecting your USB drive.

Changed in unetbootin:
assignee: nobody → gezakovacs

Did that (reformat under Windows) and had the same problem. It seems
to be time-dependent because a day later I was able, using the exact
same steps, produce a bootable USB drive. I had similar problems with
other distributions as well, and I see that I am not the only one with
these problems. Perhaps the CR/LF differences are not the root cause
of this, but there is a problem non-the-less.

FYI, I have over 25 years experience in the development of complex,
distributed, real-time systems software. If it has a chip in it, I
wrote a large part of the code that built the chip. This isn't my
imagination, and it is related to the OS the LiveUSB is generated on.

Sincerely,

William Boyle
President
Application Frameworks and Systems, Inc.
Vice Chairman
IEEE Chicago-Rockford Consultants' Network

On Thu, Jan 29, 2009 at 4:59 PM, Geza Kovacs <email address hidden> wrote:
> Yes the software does put Windows-style line terminators in the
> syslinux.cfg but nevertheless it shouldn't ever matter; syslinux
> supports reading from text files with either newline style. All other
> files are copied verbatim from the ISO so it won't affect those. Since
> you're reaching a busybox shell rather than hanging on a syslinux error
> it means that it read syslinux.cfg and loaded the kernel just fine, just
> that Ubuntu is unable to locate filesystem.squashfs because it for some
> reason can't mount the USB drive or something, the issue is something
> entirely other than an issue with the syslinux.cfg or ldlinux.sys files.
> Try reformatting the USB drive under Windows if possible, perhaps Ubuntu
> is having issues with detecting your USB drive.
>
> ** Changed in: unetbootin
> Assignee: (unassigned) => Geza Kovacs (gezakovacs)
>
> --
> Windows versions put CR/LF line terminators in text files.
> https://bugs.launchpad.net/bugs/322905
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Geza Kovacs (gezakovacs) wrote :

Do you encounter the same issue when you load SliTaz rather than Ubuntu on your USB drive? If yes, do you still encounter it when you boot the Windows-generated SliTaz Live USB on another computer?

I'm trying to narrow down this issue, and if my hunch serves me well this is some USB drive detection and mounting issue, that is it shouldn't occur with distributions like SliTaz that load entirely into RAM via the initrd.

I would assume the reason it's occurring in Windows and not Linux would be because of perhaps differences in their FAT32 formatting utilities or drivers - unfortunately I've never encountered anything like this myself so I can't yet think of anything beyond that.

bboyle (woboyle) wrote :
Download full text (4.9 KiB)

Thanks for the feedback. I'll try something out this weekend to see if
we can duplicate the problem. FYI, the system I am testing this on is
a Dell D630 laptop, 4GB ram, nvidia graphics, wireless, 160GB sata
drive. That is the Windows system I am using to test UNetbootin
Windows version on. It is running WinXP SP2. The Linux system I am
using is a custom workstation with the following equipment:

Intel S5000XVN motherboard w/ 2 E5450 3GHz Xeon quad-core CPUs
8GB ECC RAM
~4TB disc space (4x500MB sata, 1x1.5TB esata, 1x320GB sata removable boot drive)
nVidia 8800GT video w/ 2 displays
CentOS 5.2 operating system
KDE 3.5.4

The systems are connected to a gigabit LAN switch. I keep the Linux
ISO images that I am using to build the thumb drives on an external
NAS RAID that is also attached to the LAN switch, so both systems are
building from the same image file (not simultaneously, however). When
this happened, I tried to rebuild again from Windows on the same thumb
drive, as well as on another, and the behaviour was the same. Then I
rebuilt on both drives from the Linux system and both booted just
fine. I was able to rebuild again on Windows, and the boot failed as I
mentioned, into a minimal shell.

The next day, I tried Windows again, but with a new drive - actually I
use 2GB micro-sd cards in an Iogear usb reader that looks and acts
like a thumb drive, made for the micro-sd cards - and there was no
problem at all. I use the same make/model card for all my testing, and
when I go from distribution to distribution I reformat the card and
install the Windows boot loader again, just to be consistent.

Anyway, I ran a checksum on the good (linux) / bad (windows) runs and
the deltas were reported to the bug tracker on SourceForge in my
comments.

I am using the laptop to test the LiveUSB drives.

FWIW, I used the successful builds in my presentation Monday night to
the IEEE Consultants' Network and it was very well received. There was
a lot of interest in this means of easily building system recovery
tools and live Linux USB drives. For my presentation I built the drive
with the newest version, 3.07 on the Windows system. It booted and ran
Ubuntu just fine.

One final datum. When I was having these problems, I noticed that
sometimes (not always) the drive would become disabled during the
Laptop's POST and the F12 key to bring up the 1-time boot options (hd,
usb, cd, network) would bring up the menu, but the USB would be
missing. I could switch to another USB port and reboot and it would
see and boot the drive. It hasn't done that again, so I don't have any
way to tell if there is some other problem with the system. If I went
ahead and rebooted into windows, the USB port was enabled again. Go
figure. Is it possible that something in the boot loader was giving
the system indigestion?

So, I think we'd agree that the jury is still out with regard to
whether this was an issue with the sd card or reader I was using, or
UNetbootin. That said, others have experienced similar problems, or so
they have recounted to me on the linux.com forums and in the bug
tracker on SF, so we don't know enough yet to establish a root cause
of my problem. I do know that some ...

Read more...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers