[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    [gentoo-user] Re: SNAFU!!!! Boot drive modernization.
From:       Nikos Chantziaras <realnc () gmail ! com>
Date:       2017-01-25 18:56:12
Message-ID: o6asc9$84r$1 () blaine ! gmane ! org
[Download RAW message or body]

I had the same issue. I fixed it by disabling GRUB's automatic UUID 
kernel parameter and using my own.

/etc/default/grub:

GRUB_DISABLE_LINUX_UUID=true
GRUB_CMDLINE_LINUX="root=/dev/sda5 rootfstype=ext4"

Regenerate the grub config after editing it (grub-mkconfig).


On 01/25/2017 04:38 PM, Alan Grimes wrote:
> After 7 long years, the peace of mind feature on my Velociraptor HD had
> finally given up the ghost.
>
> So I get a new SSD, that's slightly smaller but still a large multiple
> of what I actually need the drive for. =P
>
> To be fully trendy (and finally wanting to put the 1980's to bed) I try
> to set up UEFI on gpt partitions, so the new boot partition, which is
> also excessively large, now has a EFI directory.
>
> ############################
>
> localhost new_uefi # tree -L 2
> .
> ├── config-4.6.7
> ├── EFI
> │   ├── BOOT
> │   └── gentoo
> ├── grub
> │   ├── default
> │   ├── device.map
> │   ├── e2fs_stage1_5
> │   ├── fat_stage1_5
> │   ├── ffs_stage1_5
> │   ├── fonts
> │   ├── grub.cfg
> │   ├── grubenv
> │   ├── i386-pc
> │   ├── iso9660_stage1_5
> │   ├── jfs_stage1_5
> │   ├── locale
> │   ├── minix_stage1_5
> │   ├── reiserfs_stage1_5
> │   ├── splash.xpm.gz
> │   ├── stage1
> │   ├── stage2
> │   ├──
> stage2_eltorito
>
> │   ├──
> themes
>
> │   ├──
> ufs2_stage1_5
>
> │   ├──
> vstafs_stage1_5
>
> │   ├──
> x86_64-efi
>
> │   └──
> xfs_stage1_5
>
> ├──
> memtest86plus
>
> │   ├──
> memtest
>
> │   └──
> memtest.netbsd
>
> ├──
> System.map-4.6.7
>
> └──
> vmlinuz-4.6.7
>
>
>
> 10 directories, 23
> files
>
> localhost new_uefi #
> ############################
>
> Okay,
>
> I copy GRUB into BOOT and test it, I unplugged the 'raptor to make it a
> good test. It got to the point of kernel loading where it stalled
> presumably because the kernel couldn't find root. But I had TESTED GRUB
> AND IT WORKED!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!11
>
> <catches breath>
>
> Okay...
>
> I then use a parted CD and tried to rsync my data across, got bitten by
> the goddamned trailing / missfeature, ended up using mv and fixed the
> directory entries instead of putting another 50gb of wear on my new drive.
>
> ****
> Side note: these boot CDs disable my mouse because it's using a USB port
> that's mapped to the same IO address space as another USB port and, due
> to my CPU/MOBO combination, I need about a dozen kernel parameters to
> unhose using IOMMU.
> ****
>
> So I've tested grub, it got to the kernel,
>
> Now I have a root filesystem so the kernel should work.
>
> Now to juggle the cables
>
> Grub now dies before accomplishing anything whatsoever complaining that
> it can't find a specific uuid.
>
> I have one thing to say about UUID's at this point:
>
> BURN
> -- IN --
> HELL.
>
> Before I had been indifferent because I could ignore them completely
> with no ill effects,
>
> Now it's failing in a way that I don't even know what's going on. jeez!
>
> So what I did was pray to almighty GooG and was provided with a grub
> boot repair disk.. Which wouldn't work because it refused to touch a
> UEFI system from a legacy-booted CD... So I reformatted my only CF disk
> (which was reserved for BIOS images) and got it to do the work. The
> keyboard input barely worked because there was almost no visible
> feedback of the cursor position when the gui was operated by keyboard...
> Anyway, I set the settings the way I wanted and it stopped dead at "plz
> wait a few minutes while botching up your kernels "... I came back the
> next morning and it was still frozen so I juggled the cables back and am
> therefore able to write this e-mail. =\
>



[prev in list] [next in list] [prev in thread] [next in thread]