Bug 27836

Forgot to tell that I install an 64 bit system from DVD-R.

Thank you for reporting this, and sorry for the angst.

Can you please say whether your system is MBR/BIOS, or EFI/GPT. Hopefully not mixed... Is there a hard disc as well as the SSD? MBR or GPT?

And what partitioning choices you made for the installation; for example, use entire 'disc', use free space, custom, etc. Were there partitions on the SSD you wanted preserved? What partitions were created for the installation?

Also please say at what point the error occurs. During the disc partitioning stage? Exactly how far it got. Does the installation simply stop then?

CC: (none) => lewyssmith

(In reply to Hans Micheelsen from comment #0)
> Description of problem:
> I'm installing Mageia 8b2 on a brand new Kingston SA400S37/480G SSD.
> After formatting the partitions the system says "Mounts partition UUID=..."
> and after some time it gives me the message: "Can't call method "val" on an
> undefined value
> 
> Version-Release number of selected component (if applicable):
> Mga 8 beta 2
> 
> How reproducible:
> Every time

I wonder if SSD device was already partitioned before attempt to install Mageia 8.

CC: (none) => ouaurelien

There is no other disk than the SSD. There were no partitions on the SSD when I started. It was brand new. Right out of the box!

1. On bootup from the DVD I chose EFI/GPT installation simply to see how it works.
2. I first chose entire 'disc' and pressed Continue.
3. It formatted with no error.
4. Then it used some time with a message: "Mounts partition UUID ...." (I didn't note the UUID-number) but came with an error message "Can't call method "val" on an undefined value".
5. I pressed Continue and it returned to the disk partitioning screen.
6. I tried several different partitionings. By still the same error message.
7. To see if its the SDD that's broken I installen Linux Mint. No problems
8. I tried again with Mga 8b2. This time with MBR/BIOS. And with various partitions. Still the
9. Then suddenly the system stated that I had to restart system after writing partition tabel. Strange indeed! And it didn't succeed in restarting - went to grub.

   Certainly very much angst!

Can it be related to https://bugs.mageia.org/show_bug.cgi?id=27839 ?

I made an USB-disk with the iso to try that. But got wrong signature message.

I succeeded in installing with the USB-disk. Maybe its my DVD-drive that's messing with the mount table - at first thought it seems unlikely, but...

Thank you for your responses and experiments.
Re comment 4, if you have an EFI box, and you are starting from scratch, always stick with EFI/GPT.

(In reply to Hans Micheelsen from comment #6)
> I succeeded in installing with the USB-disk. Maybe its my DVD-drive that's
> messing with the mount table - at first thought it seems unlikely, but...
Good. Normally DVD & USB installations are both tested, independant, & work.

We do have another identical bug which is moribund for want of information; it too was to SSD. It has advice about how to chase this if you want to, since you said it happens 'every time', so is reproduceable.
 https://bugs.mageia.org/show_bug.cgi?id=25229#c1
But you may want to leave your installation alone now.

If you do want to pursue this, that old bug can be made a duplicate of this new one, because it is more informative. If you do not wish to pursue it, this new bug will become a duplicate of the old one.

I'll certainly be happy to pursue this. I got mga running on another SSD where all the important stuff is still kept. The new SSD is for experiments.

Please tell me what to do

I just did! - the link in comment 7, Marja's advice:
> Press Ctrl+Alt+F2 to switch to tty2
> Insert a USB key
> Type:
>     bug
> Attach 'report.bug' that was written to the USB key, to this bug report
Thank you for your willingness to chase this.

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

CC: (none) => steffo76

Created attachment 12112 [details]
Bug report from installation failed after partition & format

Bug report as requested.

Line no 2729 is in danish but says that I chose "Wipe all disk and use it"

BTW: Why does it give me a swap of 4 Gb when I have 8 Gb RAM? Shouldn't that match?

Created attachment 12117 [details]
Bug report from installation

I borrowed an usb DVD-drive (lenovo PN-04x2176) and tried an installation with that. It gave similar behavour but the message was different: 
   An error occurred
   media.cfg not found

I did the installation both in danish and english. Same message (in two languages)

This is why I stopped replacing my dvd drives as the failed and do not
currently have one.

From the Bug report from installation attachment ...
<3>[   96.649657] blk_update_request: I/O error, dev sr1, sector 1848 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
<4>[   96.649703] ISOFS: unable to read i-node block

CC: (none) => davidwhodgins

And from the first report:

<3>[   91.500602] blk_update_request: I/O error, dev sr0, sector 7913224 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
<3>[  100.420581] blk_update_request: I/O error, dev sr0, sector 7913224 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

As you are getting errors with two different drives, I'd suspect the media.

CC: (none) => mageia

As I'm a heavy smoker, I found that dvd drives become unreliable after less
than a year. I stopped replacing them and stick to usb sticks. They are not
expensive and are faster than optical disks.

Thank you Dave & Martin for your comments, and Hans' co-operation.

I think we can close this, because the DVD is suspect, and the installation worked from USB. In fact at the beginning (because it was not apparently the issue) Hans did not say how the DVD was burned, was it verified in any way etc. You did say DVD-R, which is why I use DVD-RW - so you can re-do it!

Re-open the bug if you can re-produce it with a newly burned & verified DVD.
USB sticks are always preferable where they can be employed: simply so much handier. We really only still test DVD installation for old machines which can boot from DVD, but not USB.

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

All right with me. I haven't used DVD's for years because I always saw problems with Mageia DVD's. I only wantd to check if the problem persisted. And it did. And with several DVD's. I didn't only check this one. I also checked DVD+R. But that failed already in the burning proces.
What troubles me most is that I never say sismlar problem with other distros. I suspect that it has to do with the size of the ISO. I don't recall other distros having that big ISO's.

Maybe Mageia should make a disclaimer: Don't use DVD's ONLY USB's

> I suspect that it has to do with the size of the ISO. I don't recall other
> distros having that big ISO's.
This could have a bearing - reaching parts of the drive other distros do not!

It is likely that the Classic ISO DVD is bigger than other distributions for the simple reason that it includes so much: a wealth of desktops (I install them all) and applications. If you are only interested in KDE or Gnome or Xfce, those ISOs are much smaller.

Note what I said in comment 17: "We really only still test DVD installation for old machines which can boot from DVD, but not USB". Which are rare today. In the years I tested ISOs, I never had a persistent problem with DVDs. I am tempted to test your problem, but it would have to be 'custom' to a nominated real disc partition, not *exactly* the same...

(In reply to Hans Micheelsen from comment #18)
...
> 
> Maybe Mageia should make a disclaimer: Don't use DVD's ONLY USB's

I would not recommend simply re-burning optical media nor considering USB media to be inherently foolproof.  Either is subject to degradation, being initially flawed, or subject to the failure of any link(s) in the hardware/software chain of writing program, cables, devices, computer memory...

The downloaded iso should be first verified against the almost-always provided (or should be) checksum file.  For example,


[rolf@x570i xenial]$ ls
 writecd.cmp.log           'xenialpup64-7.5-uefi.iso.md5&sha256.txt'  'xenialpup-7.5-uefi.iso.md5&sha256.txt'
 xenialpup64-7.5-uefi.iso   xenialpup-7.5-uefi.iso

[rolf@x570i xenial]$ cat xenialpup-7.5-uefi.iso.md5\&sha256.txt 
# MD5
cd40febf96a102c9ade6b8e96a3a95c3  xenialpup-7.5-uefi.iso
# SHA1
705573d439055093ac73479ba5046722bbd8a205  xenialpup-7.5-uefi.iso
# SHA256
3d74b9ef0eba2508e1459829e098616c72160520a8c1dd0e49304273c65fb8e2  xenialpup-7.5-uefi.iso
# CRC32
5ec0db61  xenialpup-7.5-uefi.iso

[rolf@x570i xenial]$ md5sum xenialpup-7.5-uefi.iso
cd40febf96a102c9ade6b8e96a3a95c3  xenialpup-7.5-uefi.iso
[rolf@x570i xenial]$


The md5sum matches, other checksum utilities could be used, here, but I think the example is a sufficient minimum.  BTW, for a properly formatted checksum file, `md5sum -c' (or analogous for other sum types) against the file in the same directory containing the iso should return OK for a good iso.

In k3b, there is an option to verify written data that should be used to ensure the burned disc is a true copy of the verified iso.  For this example, I've used `dd' to write the iso to a micro SD card in a USB adapter.  For optical media as  well, `cmp' can verify the write to be valid or not.  In this example, media unmounted:

[rolf@x570i xenial]$ sudo cmp xenialpup-7.5-uefi.iso /dev/sdd
cmp: EOF on xenialpup-7.5-uefi.iso after byte 340531200, in line 1314604
[rolf@x570i xenial]$

"EOF" is a good message, meaning the entirety compares correctly.  Now is the time to attempt to use the media.

Aside:  For a long time, I would use `writecd -cmp' from 
Volker Kuhlmann's scriptutils Shell Scripts:  http://volker.top.geek.nz/soft/
Then, Martin or one of the Davids, I think, posted an example of `cmp', which did the same thing, albeit with a little less verbosity.
[rolf@x570i ~]$ rpm -qf `which cmp`
diffutils-3.7-1.mga7

So much user and developer time could be spared were some such policy of verifying the installation media be strongly suggested, at least, (as in the bug report template, linked wiki article, e.g.), even enforced.

But I repeat myself...