Bug 32783 - Live installer does not find internal SSD, only the install medium
Summary: Live installer does not find internal SSD, only the install medium
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: 9
Hardware: All Linux
Priority: Normal normal
Target Milestone: Mageia 10
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-01-26 07:48 CET by Ben McMonagle
Modified: 2024-01-28 03:53 CET (History)
2 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
C I install on this hardware. (189.97 KB, application/x-xz)
2024-01-26 07:53 CET, Ben McMonagle
Details
file manager screenshot from Live system (79.18 KB, image/png)
2024-01-26 21:05 CET, Ben McMonagle
Details
screenshot showing dropdown list of available storage media to install to. (69.05 KB, image/png)
2024-01-26 21:12 CET, Ben McMonagle
Details

Description Ben McMonagle 2024-01-26 07:48:38 CET
Description of problem:attempting to install from Live media fails as the installer is unable to find internal SSD. It only finds the install media.

Classical installer installs ok.

Net-installer fails to find any C.I isos stored on SSD, so only able to complete online install.

$ inxi -D
Drives:
  Local Storage: total: 491.38 GiB used: 0 KiB (0.0%)
  ID-1: /dev/sda vendor: TeamGroup model: T-FORCE 512GB size: 476.94 GiB
  ID-2: /dev/sdb type: USB model: USB Flash Memory size: 14.44 GiB

lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0     7:0    0   3.6G  1 loop /run/mgalive/ovlsize
sda       8:0    0 476.9G  0 disk 
├─sda1    8:1    0   299M  0 part 
├─sda2    8:2    0  48.8G  0 part 
├─sda3    8:3    0   7.8G  0 part 
├─sda4    8:4    0  48.8G  0 part 
├─sda5    8:5    0   9.8G  0 part 
├─sda6    8:6    0   9.8G  0 part 
├─sda7    8:7    0   9.8G  0 part 
├─sda8    8:8    0   9.8G  0 part 
├─sda9    8:9    0  97.7G  0 part 
├─sda10   8:10   0  19.5G  0 part 
└─sda11   8:11   0  48.8G  0 part 
sdb       8:16   1  14.4G  0 disk 
└─sdb1    8:17   1  14.4G  0 part 
sr0      11:0    1  1024M  0 rom  



Version-Release number of selected component (if applicable):
Mageia-9 Live (Xfce, Gnome & plasma)

How reproducible: always on this hardware.


Steps to Reproduce:
1. boot to Live install media.
2. Attempt to install.
3.
Comment 1 Ben McMonagle 2024-01-26 07:53:22 CET
Created attachment 14309 [details]
C I install on this hardware.
Ben McMonagle 2024-01-26 07:59:03 CET

Target Milestone: --- => Mageia 10

Comment 2 Lewis Smith 2024-01-26 20:18:12 CET
Ben, it would help if you describe "unable to find internal SSD". Do you mean it does not show up at the partioning stage?
Even if from another system on the same machine, please post the output of:
 #fdisk -l /dev/sda     ?    [or gdisk]
and 
 inxi -MDop

Also, of course, if the Live system boots to a working desktop - does *it* see the 'disk' that its Installer does not?

CC: (none) => lewyssmith

Comment 3 Ben McMonagle 2024-01-26 20:41:45 CET
(In reply to Lewis Smith from comment #2)
> Ben, it would help if you describe "unable to find internal SSD". Do you
> mean it does not show up at the partioning stage?
correct, only shows the install media USB partitions.

> Even if from another system on the same machine, please post the output of:
>  #fdisk -l /dev/sda     ?    [or gdisk]
lsblk was from the live system.
will do

> and 
>  inxi -MDop
inxi -D was also from the live system. 
will do

> 
> Also, of course, if the Live system boots to a working desktop - does *it*
> see the 'disk' that its Installer does not?

yes. can read from and write to.

Also, this system had a failed SSD. The old one was able to be installed  to without issue.
The replacement SSD has the issue.
Comment 4 Ben McMonagle 2024-01-26 21:04:47 CET
(In reply to Lewis Smith from comment #2)

> Even if from another system on the same machine, please post the output of:
>  #fdisk -l /dev/sda     ?    [or gdisk]

# fdisk -l /dev/sda
Disk /dev/sda: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: T-FORCE 512GB   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CA6E1D44-3708-42C3-A8F2-CB2AEBFA4D4B

Device         Start        End   Sectors  Size Type
/dev/sda1       2048     614433    612386  299M BIOS boot
/dev/sda2     616448  103014433 102397986 48.8G Linux filesystem
/dev/sda3  103016448  119398433  16381986  7.8G Linux swap
/dev/sda4  119400448  221798433 102397986 48.8G Linux filesystem
/dev/sda5  221800448  242278433  20477986  9.8G Linux filesystem
/dev/sda6  242280448  262758433  20477986  9.8G Linux filesystem
/dev/sda7  262760448  283238433  20477986  9.8G Linux filesystem
/dev/sda8  283240448  303718433  20477986  9.8G Linux filesystem
/dev/sda9  795416576 1000215182 204798607 97.7G Linux filesystem
/dev/sda10 303720448  344678433  40957986 19.5G Linux filesystem
/dev/sda11 344680448  447094817 102414370 48.8G Linux filesystem


> and 
>  inxi -MDop
> 
as root, does it matter?

Machine:
  Type: Laptop System: TOSHIBA product: PORTEGE R930 v: PT331A-0DD04301
    serial: 7D040465H
  Mobo: TOSHIBA model: PORTEGE R930 v: Version A0 serial: C0D730RT
    BIOS: TOSHIBA v: Version 6.70 date: 04/04/2013
Drives:
  Local Storage: total: 491.38 GiB used: 0 KiB (0.0%)
  ID-1: /dev/sda vendor: TeamGroup model: T-FORCE 512GB size: 476.94 GiB
  ID-2: /dev/sdb type: USB model: USB Flash Memory size: 14.44 GiB
Partition:
  Message: No partition data found.
Unmounted:
  ID-1: /dev/sda1 size: 299 MiB fs: N/A
  ID-2: /dev/sda10 size: 19.53 GiB fs: ext4
  ID-3: /dev/sda11 size: 48.83 GiB fs: ext4
  ID-4: /dev/sda2 size: 48.83 GiB fs: ext4
  ID-5: /dev/sda3 size: 7.81 GiB fs: swap
  ID-6: /dev/sda4 size: 48.83 GiB fs: ext4
  ID-7: /dev/sda5 size: 9.76 GiB fs: btrfs
  ID-8: /dev/sda6 size: 9.76 GiB fs: btrfs
  ID-9: /dev/sda7 size: 9.76 GiB fs: btrfs
  ID-10: /dev/sda8 size: 9.76 GiB fs: btrfs
  ID-11: /dev/sda9 size: 97.66 GiB fs: ext4
  ID-12: /dev/sdb1 size: 3.77 GiB fs: iso9660
  ID-13: /dev/sdb2 size: 4 MiB fs: vfat

> Also, of course, if the Live system boots to a working desktop - does *it*
> see the 'disk' that its Installer does not?
Comment 5 Ben McMonagle 2024-01-26 21:05:39 CET
Created attachment 14311 [details]
file manager screenshot from Live system
Comment 6 Lewis Smith 2024-01-26 21:10:20 CET
Can you navigate in occupied partitions on the SSD (perhaps mount first)?
Comment 7 Ben McMonagle 2024-01-26 21:12:40 CET
Created attachment 14312 [details]
screenshot  showing dropdown list of available storage media to install to.
Comment 8 Ben McMonagle 2024-01-26 21:15:44 CET
(In reply to Lewis Smith from comment #6)
> Can you navigate in occupied partitions on the SSD (perhaps mount first)?

mounted sda4.
started the installer.
filemanager response ( because installer unmounts all partitions ):
Current location changed, ‘/run/media/live/160a65af-ec38-449d-8a0f-f68db51e6339’ is no longer accessible.
Comment 9 Ben McMonagle 2024-01-26 21:19:44 CET
(In reply to Lewis Smith from comment #6)
> Can you navigate in occupied partitions on the SSD (perhaps mount first)?

yes,can read from and write to all partitions.
Comment 10 Lewis Smith 2024-01-27 21:28:11 CET
Thank you for the comprehensive evidence.
So the Live system can see all the SSD partitions, and their contents; but the Live Installer cannot. Pity tmb is not here to give his view.
It is very significant that the same Installer 'saw' a previous SSD on the same machine; which makes a H/W reason likely.

Clearly the moment to ask Martin.

CC: (none) => mageia

Comment 11 Martin Whitaker 2024-01-28 01:11:31 CET
From the file manager screenshot and also from the CI log, we can see that Ben has used the same volume names for partitions on the SSD as are used on the Live ISOs. The Live installer protects against installing onto the Live media, but it uses the volume name to do that. With two identical volume names in the system, it's pot luck which one it picks.
Comment 12 Ben McMonagle 2024-01-28 01:25:00 CET
(In reply to Martin Whitaker from comment #11)
> From the file manager screenshot and also from the CI log, we can see that
> Ben has used the same volume names for partitions on the SSD as are used on
> the Live ISOs. The Live installer protects against installing onto the Live
> media, but it uses the volume name to do that. With two identical volume
> names in the system, it's pot luck which one it picks.

Thanks Martin, spot on.

renaming the partition that was the same as the Live fixed that issue.

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

Comment 13 sturmvogel 2024-01-28 03:53:52 CET
Nothing was done on Mageia side to fix. So changing resolution to invalid.

Resolution: FIXED => INVALID


Note You need to log in before you can comment on or make changes to this bug.