customer is putting their installation repo on a local disk (on a RAID, in fact - but that's just a minor addition)
the partition with the repo is included in the target system setup (e.g. /service mountpoint)
the partitioner complains when it tries to mount that partition as it's already mounted as repo
but that's only the tip of the iceberg, internally it fails in numerous places
Analysis
In the case above the customer is trying to
(a) use an ISO in a subdirectory of some partition (e.g. /foo/sles.iso on /dev/sda1). You might also want to
(b) use an unpacked tree (/foo/sles on /dev/sda1) or to
(c) put the unpacked tree into the root dir of the partition (/ on /dev/sda1).
All three cases lead to different issues.
Here's what's happening with local media in the background.
linuxrc leaves local media mounted at /var/adm/mount when starting yast; it sets install.inf::Sourcemounted: 1
to indicate this
linuxrc keeps a reference to the medium to handle later extend requests
yast unmounts (or at least tries to) the local medium
yast/libzypp then re-mounts/unmounts the medium as needed during the repo initialization process in inst_complex_welcome.rb
yast runs extend (cracklib) and linuxrc will re-mount/unmount the medium as needed for that
installation starts and storage-ng commits the disk setup
yast/libzypp then re-mounts/unmounts the medium as needed for package installation
Notes
for (a) and sometimes for (b), two mountpoints are used (one for the partition, one for the file / subdir)
depending on whether you run in SLE15 or Tumbleweed, slightly different things happen (see below)
The problem(s)
5. still has some active media mountpoint and it will show up in the probed tree
7. may even see a different situation (mountpoint gone, in SLE15)
8. may mess up even further (unmount fail due to 'busy' error)
9. then breaks - because for one, storage-ng's mountpoint view differers from the actual situation and secondly,
because storage-ng will confuse mounts in the target system (with added /mnt prefix) and mounts in the installation
system (based in /); depending on the concrete situation storage-ng will show popups and/or remove broken mountpoints from the target fstab
10. may also break, even if you make it past 9.
yast keeps a file descriptor open on a file on the installation medium, preventing the unmounting (on Tumbleweed)
Solution
Don't leave local media around mounted.
In the AutoYaST workflow this seems to be the case already. Another explicit Pkg.SourceReleaseAll seems not necessary.
If needed, shortly before probe_storage looks like the place to go.
The manual workflow should be reviewed to ensure this or an explicit Pkg.SourceReleaseAll would have to be included shortly before the probing and before the proposal is run.
Implementation
linuxrc leaves the media mounted historically, there is no real need for it, change that
this also ensures extend does not rely on already mounted media and will mount/unmount as needed
in 7.: [not done, this is not the right place] detach all media (Pkg.SourceReleaseAll) and do a storage reprobe
there's also an issue where it's useful to wait a bit when extend -r reports mountpoint busy (don't know
why it happens, but it sometimes does - fixes issues in 8.)
yast package manager keeps a repo meta data file open accidentally, preventing media detaching, close it explicitly
fix libzypp to release ISO file media sources correctly
add workaround to libzypp to retry the media umount after waiting 1 second
The RAID issue
The original report uses a RAID to store the repo. You have to add autoassembly=1 to the boot options.
But linuxrc scans only 'physical' disks looking for installation media, not RAID volumes. But that's easily fixed by setting the list_md probing flag internally.
Better handling of local installation media during installation
The issue
/service
mountpoint)Analysis
In the case above the customer is trying to
(a) use an ISO in a subdirectory of some partition (e.g.
/foo/sles.iso
on/dev/sda1
). You might also want to(b) use an unpacked tree (
/foo/sles
on/dev/sda1
) or to(c) put the unpacked tree into the root dir of the partition (
/
on/dev/sda1
).All three cases lead to different issues.
Here's what's happening with local media in the background.
/var/adm/mount
when starting yast; it setsinstall.inf::Sourcemounted: 1
to indicate thisextend
requestsextend
(cracklib) and linuxrc will re-mount/unmount the medium as needed for thatNotes
The problem(s)
/mnt
prefix) and mounts in the installation system (based in/
); depending on the concrete situation storage-ng will show popups and/or remove broken mountpoints from the target fstabSolution
Don't leave local media around mounted.
In the AutoYaST workflow this seems to be the case already. Another explicit
Pkg.SourceReleaseAll
seems not necessary. If needed, shortly before probe_storage looks like the place to go.The manual workflow should be reviewed to ensure this or an explicit
Pkg.SourceReleaseAll
would have to be included shortly before the probing and before the proposal is run.Implementation
extend
does not rely on already mounted media and will mount/unmount as neededPkg.SourceReleaseAll
) and do a storage reprobeextend -r
reports mountpoint busy (don't know why it happens, but it sometimes does - fixes issues in 8.)The RAID issue
The original report uses a RAID to store the repo. You have to add
autoassembly=1
to the boot options.But linuxrc scans only 'physical' disks looking for installation media, not RAID volumes. But that's easily fixed by setting the
list_md
probing flag internally.Pull requests
SLE15-SP3
SLE15-SP4
Tumbleweed