On Mon, Mar 18, 2013 at 3:55 PM, David C. Rankin <drankinatty@xxxxxxxxxxxxxxxxxx> wrote: > All, > > Just a note. After working through the update that brought in systemd, a final > issue is that somehow the drive designation for grub (legacy) for the windows > partition was changed from (hd0,0) to (hd0,1). This box is a simple old dell box > with a single 500G drive. Windows has 80G and the rest in Arch. The dual boot > for windows definition in grub menu.lst has always been: > > title Windows > rootnoverify (hd0,0) > makeactive > chainloader +1 > > 'cat /proc/partitions' showed sda and then sda2 as the first primary > partition. sda1 was no longer created by the system. Is there some reason that > sda1 would be completely missing on the system where it had always been there > before? This required the corresponding change of the menu.lst definition to: > > title Windows > rootnoverify (hd0,1) > makeactive > chainloader +1 > > While the fix is simple, what caused the loss of sda1 in the first place? > This box has booted Arch and then XP as (hd0,0) since 2009. Now it requires > (hd0,1). Is this related to the same udev issue that caused eth0 -> enp2s0? If > so, can I rely on it staying sda2 going forward or do I need another softlink in > /etc/udev/rules.d to make it so? Since both grub and linux (which are independent) show the issue, something altered your disk's partition table, moving partition 1 (which grub calls 0) to partition 2 (which grub calls 1). You can read the table(s) with "sfdisk -l". This has nothing to do with systemd or udev.
