Bugzilla – Bug 1559
mkmenu needs to detect and adjust for installs from USB
Last modified: 2008-12-05 03:34:11 UTC
You need to log in before you can comment on or make changes to this bug.
I have windows installed on my laptop and install Indiana. After the installation, grub shows the entry of Windows, but when I press "enter" on the Windows, entry, it says the disk does not exist. press "e" to edit the boot entry, I change (hd1,0) to (hd0,0), before windows can successfully started. However, I have to do this everytime.
You can of course edit /rpool/boot/grub/menu.lst to get the entry pointing to the correct disk. mkmenu apparently is coming up with the wrong disk. Was the install here done from CD or USB?
Yes, I knew it can be changed :) thanks. I installed with an USB. :)
OK, problem here is that mkmenu doesn't adjust for the USB drive being see as disk 0 during the installation process, which isn't surprising since it's designed to be run from a CD install. This is really an enhancement that's needed. Modifying summary and type.
When OpenSolaris is installed from a USB stick, the grub entry for Windows is not generated correctly. To fix this, one needs to edit the /rpool/boot/grub/menu.lst and modify the rootnoverify entry. Typically a USB installed system will have the following entry: rootnoverify (hd1,0) This should be changed to rootnoverify (hd0,0) #---------- ADDED BY BOOTADM - DO NOT EDIT ---------- title Windows rootnoverify (hd0,0) chainloader +1 #------------------- END BOOTADM -------------------- If a diagnostic partition exists, a similar change is required.
*** Bug 4733 has been marked as a duplicate of this bug. ***
This looks to be a duplicate of 1129 (or vice versa).
This issue persists with OpenSolaris 2008.11 release candidate.
Working on the devid_get() bug with Sanjay, it occurred to us that perhaps USB sticks (which don't get devid's) may be able to be discriminated against via that difference from a USB hard disk?
*** Bug 1129 has been marked as a duplicate of this bug. ***
USB devices can be (verbosely) identified with: cfgadm -lv -s "select=class(usb)" ... usb3/4 connected configured ok Mfg: USB 2.0 Product: USB Flash Drive NConfigs: 1 Config: 0 : iCfg unavailable usb-storage n /devices/pci@0,0/pci108e,5347@2,1:4 ... This displays only the physical device ID for all USB devices: cfgadm -l -s "select=class(usb),cols=physid" Phys_Id ... /devices/pci@0,0/pci108e,5347@2,1:4 ... The raw device partition 0 links can be resolved with ls -l ctds0: lrwxrwxrwx 1 root root 59 Nov 6 15:42 /dev/dsk/c3t0d0s0 -> ../../devices/pci@0,0/pci108e,5347@2,1/storage@4/disk@0,0:a Cross-referencing the device names should indicate whether a device is USB, although it is not an exact match.
*** Bug 5346 has been marked as a duplicate of this bug. ***
bootadm update-menu is run in an ICT to create the grub menu for the target disk. It invokes /sbin/biosdev, which determines the BIOS order of devices, which mkmenu uses. When the USB drive is booted, this order is temporarily disrupted, displacing all other disk numbers by 1 in that order, so it no longer matches the normal order when the USB drive is removed and the computer is rebooted. mkmenu could easily determine this by checking for the presence of /.liveusb and then decrement the number for all Windows disks, which would solve the problem.
Pushed in changeset 368:5bc047079ea5
*** Bug 6110 has been marked as a duplicate of this bug. ***