Announcement

**oshunluvr** · May 04, 2014, 08:43 AM

I'm not an EFI user yet, but I believe you need to keep the EFI partition, but nothing else. Steve Riley has a whole How-To on EFI on this forum and recommends an alternate bootloader instead of grub - rEFInd. Search for that post.

Boy, they put a lot of crap on that SSD didn't they? I'm probably going to get myself a new Dell this year, so I am getting a glimpse of what to expect. Geez, what a mess. Since I'm required to use Windoze for a single app, I'll likely be making an image of the drive as delivered, then shrinking it to it's smallest footprint and installing a couple linux installs along side.

None of my business, but a swap of only 512mb, why bother? It's too small to hibernate to. I doubt you need one at all if you're not going to close the lid on it.

**Shaika-Dzari** · May 04, 2014, 08:49 AM

Hi oshunluvr,

I'll probably not create a swap this time. This laptop has 16g or RAM, so I don't think I'll need it.
And I don't hibernate... it's booting so fast...

That may sound stupid, but do I need to use UEFI? The SSD is 512g, could I boot in legacy mode like before?

**oshunluvr** · May 04, 2014, 10:54 AM

Depends on your BIOS, but likely you can. I'm not sure if there's any compelling reasons to choose one method over the other. Steve will tell you that grub sucks and rEFind is way better, so stay with EFI, but I have no experience with it.

**dibl** · May 04, 2014, 11:32 AM

If you require Windows, running it on a VM is definitely the way go, IMO -- way fewer issues than dual-booting. I'm a VMware user, but V-Box and KVM have their fans too. In recent installations I have been letting the OS have 15 - 20GB, and leaving /home there. Then the balance of the SSD or hdd, after swap, is a "DATA" partition, and I put a line in /etc/fstab to mount it under /mnt, and there I make the MUSIC, DOCS, VIDEOS, IMAGES, and BACKUPS folders, and symlink them into /home/user. That way, if you need to download the occasional ISO and otherwise have some buildup of stuff in /home/user, there's no panic about running out of space.

**mr_raider** · May 13, 2014, 12:00 PM

If you have no intention of keeping windows, there is no obligation to use EFI. You can disable EFI, boot in legacy mode (CSM is used as a term), and then install kubuntu with any partitioning scheme you see fit.

If you wish to install in EFI mode, make sure your boot the install media in EFI mode.

You will need to poke around your BIOS to see if it supports CSM or not.

As for the partitions, I suggest you boot in to windows 8, create a recovery USB, and then you can safely store that away. Feel free to nuke the partitions after that. I am big fan of destroying everything, inlcuding the EFI partition if possible. When you boot into kubuntu live CD, I would install gparted which can do the job better than the KDEs partitioning tool.

**SteveRiley** · May 17, 2014, 03:27 PM

Originally posted by mr_raider View Post

If you have no intention of keeping windows, there is no obligation to use EFI. You can disable EFI, boot in legacy mode (CSM is used as a term), and then install kubuntu with any partitioning scheme you see fit.

BIOS has outlived its usefulness, and that includes UEFI running in compatibility mode. There is no reason to delay the inevitable: learn how UEFI works, and start using GPT disks rather than MBR. UEFI is the future of firmware and doesn't rely on special hidden areas of the disk. GPT disks remove all the other constraints on MBR disks and does away with the awkward primary/extended partitioning thing.

Originally posted by mr_raider View Post

If you wish to install in EFI mode, make sure your boot the install media in EFI mode.

Correct. If you see /boot/efi/EFI/boot/bootx64.efi on the media, then it can boot the computer into UEFI mode.

Originally posted by mr_raider View Post

You will need to poke around your BIOS to see if it supports CSM or not.

A BIOS firmware does not have a CSM. CSM is the BIOS emulation capability of a UEFI firmware. All UEFIs have CSMs. But not all will expose the CSM in their configuration settings.

Originally posted by mr_raider View Post

When you boot into kubuntu live CD, I would install gparted which can do the job better than the KDEs partitioning tool.

Ubiquity, the installer, uses its own partitioning tool. All of Ubiquity is inherited from Ubuntu. Last time I checked (and it's been a wihle), Ubiquity didn't know how to create GPT disks. So yes, it's better to use a separate utility to create partitions first.

After you finish installing Kubuntu, get rid of GRUB. Oshun is correct -- I'm a huge fan of rEFInd. It's great on single-OS machines, and even better on multi-boot machines. And now it's in a PPA!

https://launchpad.net/~rodsmith/+archive/refind

After you install rEFInd, purge all GRUB-related files and os-prober. This process may also remove efibootmgr; if so, you will need to reinstall that package. Then, to prevent GRUB from reappearing on your machine, create the file /etc/apt/preferences.d/no-boot-loaders and paste the following into it:

Code:

Package: grub*
Pin: version 0.0
Pin-Priority: -1

Package: grub*:i386
Pin: version 0.0
Pin-Priority: -1

Package: lilo
Pin: version 0.0
Pin-Priority: -1

Package: lilo:i386
Pin: version 0.0
Pin-Priority: -1

Package: os-prober
Pin: version 0.0
Pin-Priority: -1

Package: os-prober:i386
Pin: version 0.0
Pin-Priority: -1

**mr_raider** · May 17, 2014, 03:50 PM

Originally posted by SteveRiley View Post

BIOS has outlived its usefulness, and that includes UEFI running in compatibility mode. There is no reason to delay the inevitable: learn how UEFI works, and start using GPT disks rather than MBR. UEFI is the future of firmware and doesn't rely on special hidden areas of the disk. GPT disks remove all the other constraints on MBR disks and does away with the awkward primary/extended partitioning thing.

Correct. If you see /boot/efi/EFI/boot/bootx64.efi on the media, then it can boot the computer into UEFI mode.

A BIOS firmware does not have a CSM. CSM is the BIOS emulation capability of a UEFI firmware. All UEFIs have CSMs. But not all will expose the CSM in their configuration settings.

Ubiquity, the installer, uses its own partitioning tool. All of Ubiquity is inherited from Ubuntu. Last time I checked (and it's been a wihle), Ubiquity didn't know how to create GPT disks. So yes, it's better to use a separate utility to create partitions first.

Linux can boot GPT disks just fine in legacy mode, UEFI is not needed. Windows however can not. This is a consideration in dual boot. I personally use GPT + UEFI when I can, even in single boot. In flaky UEFI implementations like my Gigabyte A75 board, I use lgacy mode + GPT.

Ubiquity (14.04) can create GPT disks. If you boot the live disk in EFI mode, and create a default install to a raw unformatted disk, ubiquity will create a GPT table, an EFI partition, as well as swap partition. If however you boot the live CD in legacy mode, and present ubiquity with a GPT disk, it will try to nuke the table and revert to MBR.

BTW, I was not advocating a legacy/MBR install. I was just pointing out that it is a necessary fallback sometimes.

**mr_raider** · May 17, 2014, 03:53 PM

Does reFIND support booting from btrfs partitions?

**SteveRiley** · May 17, 2014, 04:00 PM

Originally posted by mr_raider View Post

Linux can boot GPT disks just fine in legacy mode, UEFI is not needed. Windows however can not. This is a consideration in dual boot. I personally use GPT + UEFI when I can, even in single boot. In flaky UEFI implementations like my Gigabyte A75 board, I use lgacy mode + GPT.

You are correct about the limits of Windows. Whereas Windows enforces UEFI+GPT or BIOS+MBR pairings, Linux is more flexible. I disagree with your assertion that UEFI is not needed. Actually, if you have a machine with UEFI firmware, you don't have BIOS anymore. You can run in compatibility mode, which essentially makes UEFI look like BIOS. But why? Run in UEFI mode instead, and take the opportunity to learn more about modern firmware. Multiboot is astonishingly simple to set up and maintain when you understand how UEFI works, how to manipulate the NVRAM variables, and how to arrange boot loaders in the EFI system partition.

Originally posted by mr_raider View Post

Ubiquity (14.04) can create GPT disks. If you boot the live disk in EFI mode, and create a default install to a raw unformatted disk, ubiquity will create a GPT table, an EFI partition, as well as swap partition. If however you boot the live CD in legacy mode, and present ubiquity with a GPT disk, it will try to nuke the table and revert to MBR.

Good to know. I gave up on Ubiquity long ago. My preferred installation method is to use the Ubuntu server ISO and first install a basic command-line system. Then I add selected portions of kubuntu-desktop.

**SteveRiley** · May 17, 2014, 04:07 PM

Originally posted by mr_raider View Post

Does reFIND support booting from btrfs partitions?

Yes, if you have the driver file in the correct place on the EFI system partition:

Code:

steve@t520:~$ [B]ll /boot/efi/EFI/refind/drivers_x64/[/B]
total 104
drwxr-xr-x 2 root root  4096 May  4 14:01 ./
drwxr-xr-x 5 root root  4096 May 11 01:26 ../
-rwxr-xr-x 1 root root 55016 May 11 01:19 [COLOR="#B22222"]btrfs_x64.efi[/COLOR]*
-rwxr-xr-x 1 root root 39208 May  4 13:43 ext4_x64.efi*

I'm running with / as Btrfs now. The EFI system partition is still FAT-32, of course:

Code:

steve@t520:~$ [B]cat /etc/fstab[/B]
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>                               <dump>  <pass>
/dev/sda2       /               [COLOR="#B22222"]btrfs[/COLOR]   noatime,ssd,compress=lzo,[COLOR="#B22222"]subvol=@[/COLOR]       0       1
/dev/sda1       /boot/efi       vfat    noatime                                 0       1
/dev/sda2       /home           [COLOR="#B22222"]btrfs[/COLOR]   noatime,ssd,compress=lzo,[COLOR="#B22222"]subvol=@home[/COLOR]   0       2
/dev/sda3       none            swap    sw                                      0       0
tmpfs           /tmp            tmpfs   noatime,mode=1777                       0       0

You do need to tell the kernel where to find the root subvolume:

Code:

steve@t520:~$ [B]cat /boot/refind_linux.conf[/B]
"Boot to X"             "ro root=/dev/sda2 [COLOR="#B22222"]rootflags=subvol=@[/COLOR] nox2apic intel_pstate=enable pcie_aspm=force raid=noautodetect ipv6.disable=1 selinux=0 apparmor=0"
"Boot to single user"   "ro root=/dev/sda2 [COLOR="#B22222"]rootflags=subvol=@[/COLOR] nox2apic intel_pstate=enable pcie_aspm=force raid=noautodetect ipv6.disable=1 selinux=0 apparmor=0 single"
"Boot to recovery"      "ro root=/dev/sda2 [COLOR="#B22222"]rootflags=subvol=@[/COLOR] nox2apic nomodeset recovery --verbose"

And tell rEFInd where to scan for kernels:

Code:

steve@t520:~$ [B]cat /boot/efi/EFI/refind/refind.conf[/B]
[...]
[COLOR="#B22222"]also_scan_dirs + @/boot[/COLOR]
[...]

**mr_raider** · May 17, 2014, 04:15 PM

Originally posted by SteveRiley View Post

I'm running with / as Btrfs now. The EFI system partition is still FAT-32, of course:

Code:

steve@t520:~$ [B]cat /etc/fstab[/B]
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>                               <dump>  <pass>
/dev/sda2       /               [COLOR=#B22222]btrfs[/COLOR]   noatime,ssd,compress=lzo,[COLOR=#B22222]subvol=@[/COLOR]       0       1
/dev/sda1       /boot/efi       vfat    noatime                                 0       1
/dev/sda2       /home           [COLOR=#B22222]btrfs[/COLOR]   noatime,ssd,compress=lzo,[COLOR=#B22222]subvol=@home[/COLOR]   0       2
/dev/sda3       none            swap    sw                                      0       0
tmpfs           /tmp            tmpfs   noatime,mode=1777                       0       0

interesting that you specify the ssd option in your fstab. According to this:

https://btrfs.wiki.kernel.org/index.php/Mount_options

it should not be needed:

ssd
Turn on some of the SSD optimized behaviour within btrfs. This is enabled automatically by checking /sys/block/sdX/queue/rotational to be zero. This does not enable discard/TRIM!

**SteveRiley** · May 17, 2014, 04:18 PM

Old habit I guess, heh.

**Shaika-Dzari** · May 19, 2014, 07:45 PM

Sorry, I'm late!

Thanks for all the information everyone.
I'm old school and know my way with traditionnal partionning, mbr and grub. I guess I'll need to read a little bit longer before blowing my disk

As additionnal information.
I used 13.10 iso to install kubuntu and upgrade to 14.04.
The installer created a GPT table and used the EFI partition:

Code:

root@santanni:/home/shaika-dzari# parted /dev/sda print
Model: ATA SAMSUNG SSD SM84 (scsi)
Disk /dev/sda: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  525MB   524MB   fat32        EFI system partition          boot
 2      525MB   567MB   41.9MB  fat32        Basic data partition          hidden
 3      567MB   701MB   134MB                Microsoft reserved partition  msftres
 4      701MB   1215MB  514MB   ntfs         Basic data partition          hidden, diag
 5      1215MB  250GB   248GB   ntfs         Basic data partition          msftdata
 8      250GB   262GB   12.0GB  ext4
 9      262GB   262GB   512MB
10      262GB   496GB   234GB   ext4
 7      496GB   504GB   7494MB  ntfs         Microsoft recovery partition  hidden, diag
 6      504GB   512GB   8593MB               Basic data partition

Announcement

New partitioning, opinion please

New partitioning, opinion please

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment