Description of problem: After making come changes (ex remove a physical partition between other, so it renumbers them then it say it need to reboot to proceed, and use have no other choice. In some cases it is a big problem, like for me because install using the DVD iso have too many bugs so i have to use boot.iso, and i have slow and expensive internet. I use urpmi-proxy and squid, but both refuse to cache the <architecture>/install/stage2/*.sqfs - totall leading to much grief: much waiting, and waste of limited GB/month. Questions: 1) does it really need to renumber partitions? 2) does it really need to reboot - it have not begun installing yet...? Version-Release number of selected component (if applicable): current today i believe; used mga2 boot.iso and it retrieved it How reproducible: Well, i have now rebooted 5 times because of other problems too... Steps to Reproduce: 1. During install i.e remove a partition between other so it need renumber partitions 2. Press proceed, and it asks to reboot
Hi, thanks for reporting this bug. Assigned to the package maintainer. (Please set the status to 'assigned' if you are working on it)
Keywords: (none) => TriagedCC: (none) => pterjanAssignee: bugsquad => thierry.vignaudSource RPM: current today i believe; used mga2 boot.iso and it retrieved it => drakx-installer-stage2
CC: (none) => djmarian4uSummary: Annoying and probably unnecessary reboot after partitionning => annoying and probably unnecessary reboot after partitionning
Partitions don't have a number, their number is their position. For primary partitions, there are 4 fixed slots (partitions 1 to 4) and number don't change if you remove one of them. For extended partition (>= 5), this is a list with each partition pointing to the next one. If you remove one in the middle, the position changes. It should however not ask to reboot unless the kernel refused to reload the partition table.
CC: djmarian4u => (none)
Thank you for the explanation. Is there a way to tell the cause why it want to reboot next time we see this happen?
Maybe because one was mounted
This was partitionning during install. I do not think i selected to mount anything. Does it mount by itself?
Assignee: thierry.vignaud => pterjan
I've seen it once with LVM and/or RAID. We would need logs from someone who can reproduce it. Just insert a floppy and type "bug" in tty2.
CC: (none) => thierry.vignaud
Created attachment 2119 [details] do call udevadm in installer Just a wild guess, but we still had two missing calls for udevadm (were done for diskdrake in standalone mode, but not in the installer). However now that we use udev in the installer too, we need to call it. I'll commit this tonight. Still having logs would help
Keywords: (none) => NEEDINFO, PATCH
I've commited the fix and a fixed installer should soon be uploaded. As for urpmi-proxy vs *.sqfs, please open a new bug report against the urpmi-proxy package.
Status: NEW => RESOLVEDResolution: (none) => FIXED
i'm just noting that the sqfs files change often for cauldrons, and thus the cache doesn't help since there's newer ones... if you would pull out the internet from the machine running the urpmi-proxy, it would use the cached version (HIT_AFTER_FAIL), in case of doubt, go check directly on your urpmi-proxy directory and see if the .sqfs is there.
CC: (none) => alien
Thank you Thierry. OK i found the sqfs files in cache.