Mageia forum

My system is configured with /usr on it's own partition (old time unix habit...)

After getting the upgrade notification I went through the loop of starting to upgrade and rebooting with the upgrade prep boot loader entry. (I say loop, because each time it rebooted I got an upgrade notification and it asked me to reboot with the same option.)

Having read a little about what the upgrade prep is trying to do, I don't think it's possible to upgrade my system. Once /bin/mount is moved to /usr/bin/mount it won't be possible to mount /usr (because the mount command won't be on a mounted file system). Have I missed something?

Thanks,
Rob.

Looks right to me. I guess you have some organizational issues to decide. Of course you could edit the initrd and add the mount /usr command prior to the pivot_root.

It should all work fine. I've tested this exact setup several times and it it's always worked smoothly. So a separate /usr is still fully supported - the only difference to previously is that it's now the initrd's job to mount /usr (just like it mounts /) rather than the manually split, half-hearted OS that lived on /. So you can rest assured your setup is perfectly fine - assuming you have space!

Some questions:
1. Do you have enough room on your /usr partition to store the contents of /bin, /sbin and /lib (and /lib64 if on x86_64)?
2. Does your /etc/fstab specify a read-only mount for /usr?

If 1) then I'm not really sure how to proceed :s If 2) then just temporarily remove this and reboot into the preparation.

Something else to check is that you're definitely picking the correct option from the bootloader which will perform the migration (simple question I know but you'd be surprised... )

If all of this looks OK, then there may be a problem that's preventing the move, such as having a third party RPM package - typically a JRE - installed. See https://wiki.mageia.org/en/Mageia_3_Err ... ade_Issues

Finally, if all else fails, just try modifying the boot options (keeping the special ones added to do the conversion) and remove the "quiet" and "splash" options and adding "rd.break=pre-pivot" This should show you some error messages on screen.

Please let me know what you find so we can update the instructions if needed! All the best and good luck!

Col

Colin, are you the person who handles booting issues?

Hi Colin, thanks for the reply.

I should have plenty of space. df shows:

Code: Select all

Filesystem      Size  Used Avail Use% Mounted on
rootfs          2.0G  953M  909M  52% /
devtmpfs         12G  4.0K   12G   1% /dev
tmpfs            12G  1.4M   12G   1% /dev/shm
tmpfs            12G  3.0M   12G   1% /run
/dev/md0        2.0G  953M  909M  52% /
/dev/md2         20G   11G  7.5G  60% /usr
/dev/md3        4.9G  2.1G  2.6G  45% /var
tmpfs            12G     0   12G   0% /sys/fs/cgroup
none             12G   28K   12G   1% /tmp
/dev/md1        145M  135M  2.3M  99% /boot
/dev/md6        6.6T  3.0T  3.4T  47% /export2
/dev/md4        116G   82G   29G  75% /VirtualMachines
/dev/md5        385G  135G  231G  37% /export
/dev/sdg1       917G  361G  509G  42% /snapshot
/dev/md5        385G  135G  231G  37% /home/robt


Currently my /usr is mounted R/W so that shouldn't be a problem.

I did check /var/log/messages and saw that my boot command line was:

Code: Select all

Jul 14 14:00:48 jalapeno kernel: [    0.000000] Command line: BOOT_IMAGE=Mageia_3_Upgrade_Preparation root=900 nokmsboot rw rd.convertfs splash=silent resume=UUID=d30a6793-c9c7-4968-a5da-67d5a1cd22c2


So I guess this time I remembered to select the correct boot menu option. I don't blame you for asking, we can all have "off days"

I'll explore the other boot options to see if I can get an error message (there was nothing that I recognized as related in either dmesg or messages)

The reason for the initial problem with the upgrade preparation failing turned out to be due to a JRE - I had both a /bin/java and a /usr/bin/java. I used the DVD installer to find this. (I believe the java problem is a known issue).

Once I went through the upgrade from DVD (with the java conflict resolved), I got to a state where the upgrade claimed to have finished, but the system would no longer boot. The LILO bootstrap loaded and showed the correct choices but they would not boot (they started to load, but the system crashed/rebooted after about 3 seconds). I went through several iterations of using the rescue image & reinstalling the bootstrap and also tried remaking the initrd. None of this worked and I ended up having to restore my system to Mageia-2 (good test of the disaster recovery strategy...)

My guess... I noticed the initrd was about 15MB. I have previously found my system won't boot with a 15MB initrd - usually my initrd is about 8MB- I guess the extra utilities required to mount /usr may be to blame for the increased size.

I also noticed some issues with my current (software) raid being detected with different names than when it was initially created (probably with some version of Mandriva 10...). My system has /dev/md0 to /dev/md6, the installer wanted to call them /dev/md120 to /dev/md126 (but not in the same order) which caused some issues with /etc/fstab being wrong. The installer partially changed /etc/mdadm.conf to a mixture of the old and new names.

My plan now is to add a new SSD to the system, do a clean install to the SSD (one big partition) and migrate the system settings from the old installation (not trivial, I have a lot of customized services...)

Rob_T wrote:The reason for the initial problem with the upgrade preparation failing turned out to be due to a JRE - I had both a /bin/java and a /usr/bin/java. I used the DVD installer to find this. (I believe the java problem is a known issue).

FWIW, yes: https://wiki.mageia.org/en/Mageia_3_Err ... ade_Issues