[arch-general] Arch on SSD!
I bought a crucial M4 (128GB) for my laptop, and now the idea is to move the operating system and most of the data there, keeping the other disk in the cd-bay as second disk. I formatted the SSD disk like this: Disk /dev/sda: 128.0 GB, 128035676160 bytes, 250069680 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000ee70d Device Boot Start End Blocks Id System /dev/sda1 * 2048 411647 204800 83 Linux /dev/sda2 411648 250069679 124829016 83 Linux Where sda2 is a LVM volume, but the first thing which I'm not sure is if I got the alignment correct. I didn't find anywhere what should be the alignment for my disk, and a way to check that you actually got it right (some ways only for Windows funnily). Any hint? The second thing is that at the moment I should be able to boot both disks, but the SSD now fails to load, and I'm a bit lost in the new GRUB2 configuration: MENUENTRY 'Arch GNU/Linux, with Linux core repo kernel' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-core repo kernel-true-ad4103fa-d940-47ca-8506-301d8071d467' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos5' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5 ad4103fa-d940-47ca-8506-301d8071d467 else search --no-floppy --fs-uuid --set=root ad4103fa-d940-47ca-8506-301d8071d467 fi echo 'Loading Linux core repo kernel ...' linux /boot/vmlinuz-linux root=UUID=ad4103fa-d940-47ca-8506-301d8071d467 ro quiet echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux.img } All I need to do is boot from disk (hd0, 0) and then the / is on LVM /dev/ssd/root. I'm not sure, however, if this configuration is supposed to make sense or it's just autogenerated as a template.. The fstab for the SSD is this: /dev/mapper/ssd-root / ext4 rw,relatime,data=ordered,discard 0 2 # UUID=54d06c44-2b32-4969-be42-d98d2bf7e994 /dev/sda1 /boot ext4 rw,relatime,data=ordered,discard 0 2 but I've seen somewhere that ext4 might be a problem too, or is that fixed? Thanks a lot, Andrea
Am 21.10.2012 17:28, schrieb Andrea Crotti:
Where sda2 is a LVM volume, but the first thing which I'm not sure is if I got the alignment correct. I didn't find anywhere what should be the alignment for my disk, and a way to check that you actually got it right (some ways only for Windows funnily).
Any hint?
Your tools anticipate this situation nowadays - fdisk, lvm, fsck and almost anything else now aligns on 1MB boundaries, which should be big enough for everything.
Andrea. Im by no means an expert, but should the LVM partition be marked as ext4 in fstab? Good luck
From Gmail Android® http://cirrusminor.info
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Oct 22, 2012 at 02:11:23AM +0100, nailz wrote:
but should the LVM partition be marked as ext4 in fstab?
According to few sources (gentoo wiki, linuxconfig.org) on how fstab should be: they have the LVM volumes labeled as ext4 (or whatever the actual fs is) but the mountpoint is not /dev/sdx#, rather it uses the lvm dev mapping, or however you call it: from http://linuxconfig.org/Linux_lvm_-_Logical_Volume_Manager:
/dev/mynew_vg/vol01 /home/foobar/ ext3 yadda yadda
from http://wiki.gentoo.org/wiki/LVM#.2Fetc.2Ffstab:
/dev/vg0/lvol1 /mnt/data ext4 noatime 0 2
So whatever Andrea called their virtual group is what it must be set to. If you go to the Archwiki, it uses 'VolGroup00' as the volume group. Use vgdisplay to figure out the volume group name. Note: I do not use LVM myself, so please keep that in mind. This is just from my cursory research - -- John Hutchison Programmieren und Informatik-Abteilung Feiern Sie 20 Jahre Linux! gplus.to/athetius -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJQhLSuAAoJEHBEiaRYYPoW/aQH/3VQOXTFVj5MFcJKterDOgJ4 /t7izpQX+MpwLZnQTsWTaiuUpk/Gx5r0xFF2+SQXvGrEgF7Yf/9ABJHUu99p7mnK XsHDd1b8BII18M94DOBpnOCNlg/A68Y1oTlM8j9yltrrv6LXoFwqW3sJXDHRlH3b 6F+XHudkbRvSU6Yn7ycuybAMHlgAvjoYNauqoskdJNWMof2lHH/rwNVSjGnWjs9p As8CwRbrVrPpJQH1zis9+pb7H4uLjXOIZGxs1i3Ovhj8FO7EgJR6tjeFFG7VEs3m zPEDYgdY2Z82MPAFDoNjSDfDc9I3GSz34+U/cPUg/bqn499z65LtEvPO1MUJkF0= =cIu9 -----END PGP SIGNATURE-----
On 22-10-2012 03:51, John Hutchison wrote:
On Mon, Oct 22, 2012 at 02:11:23AM +0100, nailz wrote:
but should the LVM partition be marked as ext4 in fstab?
According to few sources (gentoo wiki, linuxconfig.org) on how fstab should be: they have the LVM volumes labeled as ext4 (or whatever the actual fs is) but the mountpoint is not /dev/sdx#, rather it uses the lvm dev mapping, or however you call it:
from http://linuxconfig.org/Linux_lvm_-_Logical_Volume_Manager:
/dev/mynew_vg/vol01 /home/foobar/ ext3 yadda yadda
from http://wiki.gentoo.org/wiki/LVM#.2Fetc.2Ffstab:
/dev/vg0/lvol1 /mnt/data ext4 noatime 0 2
Or better yet, use UUID, I've been using UUIDs for a long time and they never failed me, while every once in a while I see people with problem when using /dev/sd*, I don't recall seeing people with problems when using lvm though, maybe those know what they are doing a lot better :p
So whatever Andrea called their virtual group is what it must be set to. If you go to the Archwiki, it uses 'VolGroup00' as the volume group.
Use vgdisplay to figure out the volume group name.
Note: I do not use LVM myself, so please keep that in mind. This is just from my cursory research
-- John Hutchison Programmieren und Informatik-Abteilung Feiern Sie 20 Jahre Linux! gplus.to/athetius
-- Mauro Santos
On Monday 22 Oct 2012 10:34:48 Mauro Santos wrote:
Or better yet, use UUID, I've been using UUIDs for a long time and they never failed me, while every once in a while I see people with problem when using /dev/sd*, I don't recall seeing people with problems when using lvm though, maybe those know what they are doing a lot better :p
I always prefer LVM names to UUIDs. I use UUIDs for filesystems on raw partitions, but LVM is clever enough to always use the same name regardless of where the physical device is attached. After all, the point of LVM is to shield you from these sorts of details. I always use the form /dev/mapper/vg-lv, though. The /dev/vg/lv form sometimes isn't available in early boot. I think it depends of udev, and has certainly broken for me in the past. Paul
On 22-10-2012 10:57, Paul Gideon Dann wrote:
I always use the form /dev/mapper/vg-lv, though. The /dev/vg/lv form sometimes isn't available in early boot. I think it depends of udev, and has certainly broken for me in the past.
Paul
Would /dev/vg/lv be as reliable as /dev/mapper/vg-lv or is the latter preferable? -- Mauro Santos
Am 22.10.2012 12:57, schrieb Mauro Santos:
On 22-10-2012 10:57, Paul Gideon Dann wrote:
I always use the form /dev/mapper/vg-lv, though. The /dev/vg/lv form sometimes isn't available in early boot. I think it depends of udev, and has certainly broken for me in the past.
Paul
Would /dev/vg/lv be as reliable as /dev/mapper/vg-lv or is the latter preferable?
This is no longer the case. Actually, if something with udev fails, neither /dev/vg/lv nor /dev/mapper/vg-lv will exist, but only /dev/dm-N with some arbitrary number N. While LVM and udev still don't like each other, these problems have mostly been fixed now.
On 21/10/12||16:28, Andrea Crotti wrote:
I bought a crucial M4 (128GB) for my laptop, and now the idea is to move the operating system and most of the data there, keeping the other disk in the cd-bay as second disk.
I formatted the SSD disk like this:
Disk /dev/sda: 128.0 GB, 128035676160 bytes, 250069680 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000ee70d
Device Boot Start End Blocks Id System /dev/sda1 * 2048 411647 204800 83 Linux /dev/sda2 411648 250069679 124829016 83 Linux
Where sda2 is a LVM volume, but the first thing which I'm not sure is if I got the alignment correct. I didn't find anywhere what should be the alignment for my disk, and a way to check that you actually got it right (some ways only for Windows funnily).
Any hint?
The second thing is that at the moment I should be able to boot both disks, but the SSD now fails to load, and I'm a bit lost in the new GRUB2 configuration:
MENUENTRY 'Arch GNU/Linux, with Linux core repo kernel' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-core repo kernel-true-ad4103fa-d940-47ca-8506-301d8071d467' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos5' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5 ad4103fa-d940-47ca-8506-301d8071d467 else search --no-floppy --fs-uuid --set=root ad4103fa-d940-47ca-8506-301d8071d467 fi echo 'Loading Linux core repo kernel ...' linux /boot/vmlinuz-linux root=UUID=ad4103fa-d940-47ca-8506-301d8071d467 ro quiet echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux.img }
All I need to do is boot from disk (hd0, 0) and then the / is on LVM /dev/ssd/root.
I'm not sure, however, if this configuration is supposed to make sense or it's just autogenerated as a template..
The fstab for the SSD is this:
/dev/mapper/ssd-root / ext4 rw,relatime,data=ordered,discard 0 2
# UUID=54d06c44-2b32-4969-be42-d98d2bf7e994 /dev/sda1 /boot ext4 rw,relatime,data=ordered,discard 0 2
but I've seen somewhere that ext4 might be a problem too, or is that fixed?
Thanks a lot, Andrea
I used Gparted to format my SSD. It will deal by itself with alignmenets.
participants (7)
-
Andrea Crotti
-
Arno Gaboury
-
John Hutchison
-
Mauro Santos
-
nailz
-
Paul Gideon Dann
-
Thomas Bächler