Bug 23819

Ah! that's where the missing text went! Ignore the duplication above :(

Created attachment 10457 [details]
final screen dropped to dracut prompt

Created attachment 10458 [details]
Earlier messages

Created attachment 10459 [details]
Earlier messages 2

Created attachment 10460 [details]
Earlier messages 3

Created attachment 10461 [details]
Initial screen before grub menu

The full spec on the laptop in question is here:
http://www.miniputer.com/Acer/Aspire_5315.html

That's a whole load of kernel faults...

Looks like a hardware problem to me. My first suggestion is to try again with a different USB stick, to rule out a bad copy and/or bad USB stick. Also, if that doesn't work, try a different USB socket on the laptop.

CC: (none) => mageia

(In reply to Martin Whitaker from comment #8)
> That's a whole load of kernel faults...
> 
> Looks like a hardware problem to me. My first suggestion is to try again
> with a different USB stick, to rule out a bad copy and/or bad USB stick.
> Also, if that doesn't work, try a different USB socket on the laptop.

Hi Martin,
It seems that the USB stick was written by a program called 'Rufus' and he used the 'recommended' 'Write in iso image mode' option from within a Windows system.
He has now re-written the stick using the 'DD image mode' option in Rufus and it now boots to a desktop.

While trying to install a program in the running LIVE session the machine shut down/crashed so maybe there is a memory/hardware issue.

Thanks for your input, closing as invalid for now, although if the 'Rufus'
recommended option does really always fail with Mageia, then maybe it should be mentioned in the installation docs.
Use of Rufus is mentioned in the Wiki but not which option to use.

I just found this: https://forums.mageia.org/en/viewtopic.php?f=7&t=9952

Cheers,
Barry

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Ah, Rufus again...

The need to use the DD option is highlighted here:

https://wiki.mageia.org/en/Dump_Mageia_ISO_on_a_USB_flash_drive_-_Alternative_tools

Did you find another place where it isn't?

Yes,
Here:
https://wiki.mageia.org/en/Mageia_in_dual_boot_with_Windows8_and_over#Creation_of_the_bootable_DVD_or_USB_stick

CC: (none) => yves.brungard_mageia

So it would seem that Rufus can be used with the classic installer ISOs. I'll take a look at why it isn't working with the Live ISOs.

Hi Martin,

I think you misunderstood, the LIVE *does* work with the Rufus DD mode, The user just followed the option in Rufus that had "(recommended)" after it without reading the Wiki - this was not the DD mode.

Barry

Hi Barry,

No, I just missed out a few words when writing my last comment :-( I meant to say "the Rufus ISO image mode can be used". The link Papoteur gave shows that mode being used to write a classical ISO - and I assume the person who wrote that page tried it.

Having done some experiments, I found that the latest version of Rufus itself suggests retrying in DD mode if you have problems booting after copying in ISO image mode. I also found the reason why the Live ISOs don't boot when copied in that mode, and have fixed that in cauldron. However, on testing a Mageia 7 Live ISO with Rufus, I then found that Rufus doesn't recognise the GRUB2 bootloader used on the new ISOs, so automatically falls back to DD mode anyway.

Quite why the Rufus author thinks that the sensible thing to do with an ISO image is to extract its contents and write it to a different filesystem (and then fiddle with the bootloader configuration because the volume label has changed), rather than just dumping it directly to the disk escapes me.

Hi Martin,
Thanks for the explanation, all understood. I think Rufus tries to do that to allow a stick to still be used for file storage, but I agree it's really pointless.

/OT
Still having issues with both Mga6 and Mga6.1 lives on the laptop in question, it boots fine and appears normal but then turns off poof! after a random period of use.
memtest86 has so far thrown up nothing, so I suggested switching USB ports to rule out USB controller/socket etc. I'm sure it's not the iso as it is happening with 6 and 6.1 but it has Windows installed and that does not die - strange!
He's going to try an install from live so we will see. Only snag with that is that it may die during the install :\
Cheers,
Barry

I did once have the opposite problem - Linux would boot and run fine, but Windows would crash and burn either during boot or shortly afterwards. That turned out to be a faulty DIMM. Because Linux allocates memory from top down, and Windows allocates memory from bottom up, Linux was never reaching the faulty memory locations. But MemTest86+ found that for me.

The errors in the attached photos all look to be in the graphics driver. Do the system logs capture anything similar just before the machine turns off?

Created attachment 10470 [details]
rdsosreport.txt

I seem to have hit the same issue attempting to boot the same 32 bit iso on a 64 bit machine, which I understand is allowed.

grub launches and selecting either boot or install produces the same result.

rdsosreport.txt is attached.

This flash drive was created in Cauldron using dd.

Resolution: INVALID => (none)
Status: RESOLVED => REOPENED

Comment on attachment 10470 [details]
rdsosreport.txt

It's not the same problem, even if it looks the same. We can see in the report

/dev/disk/by-label:
...
lrwxrwxrwx 1 root 0 10 Nov 13 23:18 Mageia-6.1-Xfce-LiveDVD -> ../../sde1

As per bug 3334, Linux incorrectly assigns the label to the partition rather than the raw device, but the mgalive dracut module is correcting for this:

+ mount -n -o ro /dev/sde /live/media
++ losetup -f
+ LOOPDEV=/dev/loop0
+ '[' -e /live/media/loopbacks/distrib-lzma.sqfs ']'
+ losetup -r /dev/loop0 /live/media/loopbacks/distrib-lzma.sqfs
+ mount -n -t squashfs -o ro /dev/loop0 /live/distrib
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error

So it has mounted the iso9660 filesystem on the raw device and located the distrib-lzma.sqfs file, but fails to mount that file as a loopback. That suggests file corruption to me.

I just tried the stick in my Lenovo laptop and it's the same result.
I'm guessing it's valid to dd the stick back to a file and re-check the md5sum? Not sure I ever did that before.

CCing Lebarhon who wrote the wiki section.

CC: (none) => lebarhon

(In reply to Barry Jackson from comment #20)
> I just tried the stick in my Lenovo laptop and it's the same result.
> I'm guessing it's valid to dd the stick back to a file and re-check the
> md5sum? Not sure I ever did that before.

When you dd back, it copies the full capacity of the stick, not the space occupied by the ISO image. If you truncate the file to the right size, it should work. Alternatively, try

  mkdir /mnt/iso
  mount /dev/sde /mnt/iso
  md5sum  /mnt/iso/loopbacks/distrib-lzma.sqfs

(replacing /dev/sde with wherever your USB stick currently appears)

For the Mageia-6.1-LiveDVD-Xfce-i586-DVD.iso, the result should be

9d2e762bc2ef27db0431d8aa1dd829cf  /mnt/iso/loopbacks/distrib-lzma.sqfs

In that page
https://github.com/pbatard/rufus/wiki/FAQ#GRUB

In the Grub/Using an UEFI bootable ISO based on grub, all I get is the grub prompt section, it is said:

"In this case, as Rufus explicitly advises you to do if you find that copying files in ISO-mode doesn't work properly, you can try recreating the USB and select DD-mode when prompted. Or you can voice your concerns directly to to the distro maintainers, so that they include FAT32 support in their GRUB EFI bootloader, as this is what they should have done from the start. "

What is Mga7 status?
Can we write to always use the DD-mode option, that means for Mga6, Mga7, Grub, Grub2 and Grub-efi?

(In reply to Martin Whitaker from comment #22)
> (In reply to Barry Jackson from comment #20)
> > I just tried the stick in my Lenovo laptop and it's the same result.
> > I'm guessing it's valid to dd the stick back to a file and re-check the
> > md5sum? Not sure I ever did that before.
> 
> When you dd back, it copies the full capacity of the stick, not the space
> occupied by the ISO image. If you truncate the file to the right size, it
> should work. Alternatively, try
> 
>   mkdir /mnt/iso
>   mount /dev/sde /mnt/iso
>   md5sum  /mnt/iso/loopbacks/distrib-lzma.sqfs
> 
> (replacing /dev/sde with wherever your USB stick currently appears)
> 
> For the Mageia-6.1-LiveDVD-Xfce-i586-DVD.iso, the result should be
> 
> 9d2e762bc2ef27db0431d8aa1dd829cf  /mnt/iso/loopbacks/distrib-lzma.sqfs

Yes, you were correct about the corrupt file, I'm guessing that I forgot to sync after the dd and maybe it was still writing (no led in the stick).
I re-wrote the stick from a checked iso and then checked the stick md5 as follows:

[baz@leno Downloads]$ sudo dd if=Mageia-6.1-LiveDVD-Xfce-i586-DVD.iso of=/dev/sdb bs=1M
1935+0 records in
1935+0 records out
2028994560 bytes (2.0 GB, 1.9 GiB) copied, 1093.27 s, 1.9 MB/s
[baz@leno Downloads]$ sync
[baz@leno Downloads]$ mkdir Mageia_test
[baz@leno Downloads]$ cd Mageia_test/
[baz@leno Mageia_test]$ sudo dd if=/dev/sdb of=Mageia-6.1-LiveDVD-Xfce-i586-DVD.iso bs=1M count=1935
1935+0 records in
1935+0 records out
2028994560 bytes (2.0 GB, 1.9 GiB) copied, 146.693 s, 13.8 MB/s
[baz@leno Mageia_test]$ md5sum Mageia-6.1-LiveDVD-Xfce-i586-DVD.iso
4121df29539b4b95969b8e6373676cac  Mageia-6.1-LiveDVD-Xfce-i586-DVD.iso
[baz@leno Mageia_test]$

...and this one works :)

Maybe that method of checking a stick should be mentioned in the wiki or somewhere?

Closing again as invalid

Status: REOPENED => RESOLVED
Resolution: (none) => INVALID

(In reply to Barry Jackson from comment #24)

> Yes, you were correct about the corrupt file, I'm guessing that I forgot to
> sync after the dd and maybe it was still writing (no led in the stick).
> I re-wrote the stick from a checked iso and then checked the stick md5 as
> follows:


Sync does not guarantee anything regarding dd as sync is a filesystem-level operation.

dd is done at block-level, and the way to ensure block level data is flushed out is to use eject

CC: (none) => tmb

/OT
@Martin
The original machine that started this bug report that was crashing randomly now runs the live fine with the stick in a different USB port and has been up for about 48 hours. He also says that the machine is now running almost cold where before it was hot. I thought you would be interested as I never came across a similar situation before. He is going to install to the internal drive now it's stable.

Barry

(In reply to Thomas Backlund from comment #25)

> 
> Sync does not guarantee anything regarding dd as sync is a filesystem-level
> operation.
> 
> dd is done at block-level, and the way to ensure block level data is flushed
> out is to use eject

Thanks Thomas,
I have used sync for years and it always seem to work fine with dd as the USB flashing light always stopped at (visibly) the same time as the sync completed and the prompt returned. Even when it was several minutes for the stick write to complete, sync returned to the CLI prompt at the same time.

I of course bow to your superior knowledge and will try to remember to use 'eject' in the future. :)

(In reply to André DESMOTTES from comment #23)
> In that page
> https://github.com/pbatard/rufus/wiki/FAQ#GRUB
> 
> In the Grub/Using an UEFI bootable ISO based on grub, all I get is the grub
> prompt section, it is said:
> 
> "In this case, as Rufus explicitly advises you to do if you find that
> copying files in ISO-mode doesn't work properly, you can try recreating the
> USB and select DD-mode when prompted. Or you can voice your concerns
> directly to to the distro maintainers, so that they include FAT32 support in
> their GRUB EFI bootloader, as this is what they should have done from the
> start. "

We do include FAT32 support in our GRUB2 bootloader. That's not the problem with copying files in ISO-mode. ISO-mode is a bit misleading - what it really does is extract the files from the ISO image and copy them into a FAT32 partition on the USB stick. There were two problems with this:

1) The workaround for bug 3334 causes dracut to try to mount the ISO filesystem from the base device (e.g. /dev/sdb) rather than from the first partition (e.g. /dev/sdb1). This doesn't work when the base filesystem no longer starts at sector 0.

2) On the Live ISOs, the bootloader passes the disk volume label as a kernel boot option, and dracut uses this to locate the device that contains the Live ISO filesystem. The volume label we use is longer than the maximum length allowed for a FAT32 volume, so Rufus truncates it (and converts it to all upper-case). This then requires the bootloader configuration files to be modified to use the new volume label. Rufus does try to do this, but with mixed success.

I've now fixed the first problem, but the second one may still exist.

> What is Mga7 status?
> Can we write to always use the DD-mode option, that means for Mga6, Mga7,
> Grub, Grub2 and Grub-efi?

Using DD-mode is always the safest option. That means the user is using what we have tested.