Hi,
I just replaced Slackware64 14.1 running on my office's HP Proliant Microserver with a fresh installation of CentOS 7.
The server has 4 x 250 GB disks.
Every disk is configured like this :
* 200 MB /dev/sdX1 for /boot * 4 GB /dev/sdX2 for swap * 248 GB /dev/sdX3 for /
There are supposed to be no spare devices.
/boot and swap are all supposed to be assembled in RAID level 1 across 4 disks.
The / partition is supposed to be assembled in RAID level 5 across 4 disks.
With Slackware I created the arrays manually like this:
# mdadm --create /dev/md1 --level=1 --raid-devices=4 --metadata=0.90 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 # mdadm --create /dev/md2 --level=1 --raid-devices=4 --metadata=0.90 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2 # mdadm --create /dev/md3 --level=5 --raid-devices=4 --metadata=0.90 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
Using this setup, I had 650 MB of disk space on /dev/md3.
Now I tried to do the same thing with CentOS 7. Everything seemed to work at first, but here's what I got now:
[root@nestor:~] # df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/md127 226G 1,1G 213G 1% / devtmpfs 1,4G 0 1,4G 0% /dev tmpfs 1,4G 0 1,4G 0% /dev/shm tmpfs 1,4G 8,5M 1,4G 1% /run tmpfs 1,4G 0 1,4G 0% /sys/fs/cgroup /dev/md125 194M 80M 101M 45% /boot /dev/sde1 917G 88M 871G 1% /mnt
The root partition (/dev/md127) only shows 226 G of space. So where has everything gone?
[root@nestor:~] # cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md125 : active raid1 sdc2[2] sdd2[3] sdb2[1] sda2[0] 204736 blocks super 1.0 [4/4] [UUUU]
md126 : active raid1 sdd1[3] sdc1[2] sdb1[1] sda1[0] 4095936 blocks super 1.2 [4/4] [UUUU]
md127 : active raid5 sdc3[2] sdb3[1] sdd3[4] sda3[0] 240087552 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/1 pages [0KB], 65536KB chunk
unused devices: <none>
[root@nestor:~] # mdadm -D /dev/md127 /dev/md127: Version : 1.2 Creation Time : Wed Feb 18 06:49:01 2015 Raid Level : raid5 Array Size : 240087552 (228.97 GiB 245.85 GB) Used Dev Size : 80029184 (76.32 GiB 81.95 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed Feb 18 08:04:26 2015 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Layout : left-symmetric Chunk Size : 512K
Name : localhost:root UUID : cfc13fe9:8fa811d8:85649402:58c4846e Events : 4703
Number Major Minor RaidDevice State 0 8 3 0 active sync /dev/sda3 1 8 19 1 active sync /dev/sdb3 2 8 35 2 active sync /dev/sdc3 4 8 51 3 active sync /dev/sdd3
Apparently no spare devices have been created. So why do I only have 226 GB of disk space under CentOS, when I had roughly 650 GB under Slackware?
I'm a bit lost here. Any suggestions?
Cheers,
Niki
Le 18/02/2015 08:09, Niki Kovacs a écrit :
Apparently no spare devices have been created. So why do I only have 226 GB of disk space under CentOS, when I had roughly 650 GB under Slackware?
An idea just crossed my mind. Could it be that 'df' is reporting a wrong partition size on the RAID 5 array? And how can I check if this is the case?
On 02/18/2015 01:23 AM, Niki Kovacs wrote:
Le 18/02/2015 08:09, Niki Kovacs a écrit :
Apparently no spare devices have been created. So why do I only have 226 GB of disk space under CentOS, when I had roughly 650 GB under Slackware?
An idea just crossed my mind. Could it be that 'df' is reporting a wrong partition size on the RAID 5 array? And how can I check if this is the case?
i have not built any raid system in linux, but from reading, i saw that there is a little difference from unix.
also, between linux flavors, there can be a lot of difference.
in a way, case of...
who wrote the book and how whoever is reading it.
ie, Slackware and CentOS.
looking at question of 'reporting', 'df' has various ways of reporting size and might/may/could be what is causing difference.
so, until an exact reason/cause is replied...
besides '-h', what other arguments for 'df' did you try?
df --block-size=1000 df --block-size=1024 df --block-size=K df --block-size=M df --block-size=G df --si df -T
instead of reading
man df
have a look at
info coreutils 'df invocation'
you can also use 'lsblk', which i find it to be off a bit due to how it rounds of sizes, except when using '-b'
'disk utility', 'system monitor', 'kde info center', 'gparted', are other ways of viewing allocation.
much luck finding solution.
Hi Niki,
md127 apparently only uses 81.95GB per disk. Maybe one of the partitions has the wrong size. What's the output of lsblk?
Regards Michael
----- Ursprüngliche Mail ----- Von: "Niki Kovacs" info@microlinux.fr An: "CentOS mailing list" CentOS@centos.org Gesendet: Mittwoch, 18. Februar 2015 08:09:13 Betreff: [CentOS] CentOS 7: software RAID 5 array with 4 disks and no spares?
Hi,
I just replaced Slackware64 14.1 running on my office's HP Proliant Microserver with a fresh installation of CentOS 7.
The server has 4 x 250 GB disks.
Every disk is configured like this :
* 200 MB /dev/sdX1 for /boot * 4 GB /dev/sdX2 for swap * 248 GB /dev/sdX3 for /
There are supposed to be no spare devices.
/boot and swap are all supposed to be assembled in RAID level 1 across 4 disks.
The / partition is supposed to be assembled in RAID level 5 across 4 disks.
With Slackware I created the arrays manually like this:
# mdadm --create /dev/md1 --level=1 --raid-devices=4 --metadata=0.90 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 # mdadm --create /dev/md2 --level=1 --raid-devices=4 --metadata=0.90 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2 # mdadm --create /dev/md3 --level=5 --raid-devices=4 --metadata=0.90 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
Using this setup, I had 650 MB of disk space on /dev/md3.
Now I tried to do the same thing with CentOS 7. Everything seemed to work at first, but here's what I got now:
[root@nestor:~] # df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/md127 226G 1,1G 213G 1% / devtmpfs 1,4G 0 1,4G 0% /dev tmpfs 1,4G 0 1,4G 0% /dev/shm tmpfs 1,4G 8,5M 1,4G 1% /run tmpfs 1,4G 0 1,4G 0% /sys/fs/cgroup /dev/md125 194M 80M 101M 45% /boot /dev/sde1 917G 88M 871G 1% /mnt
The root partition (/dev/md127) only shows 226 G of space. So where has everything gone?
[root@nestor:~] # cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md125 : active raid1 sdc2[2] sdd2[3] sdb2[1] sda2[0] 204736 blocks super 1.0 [4/4] [UUUU]
md126 : active raid1 sdd1[3] sdc1[2] sdb1[1] sda1[0] 4095936 blocks super 1.2 [4/4] [UUUU]
md127 : active raid5 sdc3[2] sdb3[1] sdd3[4] sda3[0] 240087552 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/1 pages [0KB], 65536KB chunk
unused devices: <none>
[root@nestor:~] # mdadm -D /dev/md127 /dev/md127: Version : 1.2 Creation Time : Wed Feb 18 06:49:01 2015 Raid Level : raid5 Array Size : 240087552 (228.97 GiB 245.85 GB) Used Dev Size : 80029184 (76.32 GiB 81.95 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed Feb 18 08:04:26 2015 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Layout : left-symmetric Chunk Size : 512K
Name : localhost:root UUID : cfc13fe9:8fa811d8:85649402:58c4846e Events : 4703
Number Major Minor RaidDevice State 0 8 3 0 active sync /dev/sda3 1 8 19 1 active sync /dev/sdb3 2 8 35 2 active sync /dev/sdc3 4 8 51 3 active sync /dev/sdd3
Apparently no spare devices have been created. So why do I only have 226 GB of disk space under CentOS, when I had roughly 650 GB under Slackware?
I'm a bit lost here. Any suggestions?
Cheers,
Niki
Le 18/02/2015 09:24, Michael Volz a écrit :
Hi Niki,
md127 apparently only uses 81.95GB per disk. Maybe one of the partitions has the wrong size. What's the output of lsblk?
[root@nestor:~] # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 232,9G 0 disk ├─sda1 8:1 0 3,9G 0 part │ └─md126 9:126 0 3,9G 0 raid1 [SWAP] ├─sda2 8:2 0 200M 0 part │ └─md125 9:125 0 200M 0 raid1 /boot └─sda3 8:3 0 76,4G 0 part └─md127 9:127 0 229G 0 raid5 / sdb 8:16 0 232,9G 0 disk ├─sdb1 8:17 0 3,9G 0 part │ └─md126 9:126 0 3,9G 0 raid1 [SWAP] ├─sdb2 8:18 0 200M 0 part │ └─md125 9:125 0 200M 0 raid1 /boot └─sdb3 8:19 0 76,4G 0 part └─md127 9:127 0 229G 0 raid5 / sdc 8:32 0 232,9G 0 disk ├─sdc1 8:33 0 3,9G 0 part │ └─md126 9:126 0 3,9G 0 raid1 [SWAP] ├─sdc2 8:34 0 200M 0 part │ └─md125 9:125 0 200M 0 raid1 /boot └─sdc3 8:35 0 76,4G 0 part └─md127 9:127 0 229G 0 raid5 / sdd 8:48 0 232,9G 0 disk ├─sdd1 8:49 0 3,9G 0 part │ └─md126 9:126 0 3,9G 0 raid1 [SWAP] ├─sdd2 8:50 0 200M 0 part │ └─md125 9:125 0 200M 0 raid1 /boot └─sdd3 8:51 0 76,4G 0 part └─md127 9:127 0 229G 0 raid5 /
Any idea what's going on ?
Le 18/02/2015 09:59, Niki Kovacs a écrit :
└─sdd3 8:51 0 76,4G 0 part └─md127 9:127 0 229G 0 raid5 /
Any idea what's going on ?
Ooops, just saw it. /dev/sdd3 apparently has the wrong size.
As to why this is so, it's a mystery.
I'll investigate further into this. (Since this is the office's gateway, I'll take some time to respond eventually. No server = no Internet :oD)
Niki
Hi Niki,
in fact all of the sdX3 partitions are of size 76.4G. Maybe they were created by the installer as part of a partition scheme and you forget to resize them when removing other partitions from the scheme? Anyway, it should be fine if you recreate the partitions with the right size and then recreate the array.
Michael
----- Ursprüngliche Mail ----- Von: "Niki Kovacs" info@microlinux.fr An: centos@centos.org Gesendet: Mittwoch, 18. Februar 2015 10:01:49 Betreff: Re: [CentOS] CentOS 7: software RAID 5 array with 4 disks and no spares?
Le 18/02/2015 09:59, Niki Kovacs a écrit :
└─sdd3 8:51 0 76,4G 0 part └─md127 9:127 0 229G 0 raid5 /
Any idea what's going on ?
Ooops, just saw it. /dev/sdd3 apparently has the wrong size.
As to why this is so, it's a mystery.
I'll investigate further into this. (Since this is the office's gateway, I'll take some time to respond eventually. No server = no Internet :oD)
Niki
On 02/18/2015 03:01 AM, Niki Kovacs wrote:
Le 18/02/2015 09:59, Niki Kovacs a écrit :
└─sdd3 8:51 0 76,4G 0 part └─md127 9:127 0 229G 0 raid5 /
Any idea what's going on ?
Ooops, just saw it. /dev/sdd3 apparently has the wrong size.
As to why this is so, it's a mystery.
I'll investigate further into this. (Since this is the office's gateway, I'll take some time to respond eventually. No server = no Internet :oD)
actually, it looks like problem is with /dev/md3, not just /dev/sdd3, as _all_ drives are wrong in their 3rd partition.
i am going to sit the rest of this out and read Michael's "book". ;-)
Le 18/02/2015 09:24, Michael Volz a écrit :
md127 apparently only uses 81.95GB per disk. Maybe one of the partitions has the wrong size. What's the output of lsblk?
I just spent a few hours experimenting with the CentOS 7 installer in a VirtualBox guest with four virtual hard disks. I can now confirm this is a very stupid bug in the (very stupid) installer. Or at least one more random weirdness. Here goes.
The new installer is organized around mount points, which have to be defined first. OK, so I first define my mountpoint /boot, set it to 200 MB (which is enough), define it to be RAID level 1 across four disks with an ext2 filesystem. So far so good.
Next step is similar, swap mountpoint is 2 GB, also RAID level 1 across four disks.
Finally, the / (root partition) mountpoint is supposed to take up the full amount of remaining disk space. In my virtual guest, I defined 4 X 40 GB to fiddle with. The installer shows me something like 38.6 GB, which looks like the remaining space on each disk's partition.
Now I define RAID level 5 across four disks...
... and here it comes.
Once RAID level 5 is defined, I have to REDEFINE the maximum disk space by putting in a random large number, for example 4 X 40 GB = 160 GB. Because what is meant here is THE TOTAL RESULTING AMOUNT OF DISK SPACE IN THE RAID 5 ARRAY, AND NOT THE MAXIMUM SIZE OF A DISK PARTITION. So once I fill that field with 160 GB, the installer "automagically" sets it to 106.8 GB, which is in effect the maximum available disk space using RAID 5.
Usability anyone?
Cheers from the sunny South of France,
Niki Kovacs
On Wed, Feb 18, 2015 at 1:21 PM, Niki Kovacs info@microlinux.fr wrote:
Le 18/02/2015 09:24, Michael Volz a écrit :
md127 apparently only uses 81.95GB per disk. Maybe one of the partitions has the wrong size. What's the output of lsblk?
I just spent a few hours experimenting with the CentOS 7 installer in a VirtualBox guest with four virtual hard disks. I can now confirm this is a very stupid bug in the (very stupid) installer. Or at least one more random weirdness. Here goes.
The new installer is organized around mount points, which have to be defined first. OK, so I first define my mountpoint /boot, set it to 200 MB (which is enough), define it to be RAID level 1 across four disks with an ext2 filesystem. So far so good.
Next step is similar, swap mountpoint is 2 GB, also RAID level 1 across four disks.
Finally, the / (root partition) mountpoint is supposed to take up the full amount of remaining disk space. In my virtual guest, I defined 4 X 40 GB to fiddle with. The installer shows me something like 38.6 GB, which looks like the remaining space on each disk's partition.
Now I define RAID level 5 across four disks...
... and here it comes.
Once RAID level 5 is defined, I have to REDEFINE the maximum disk space by putting in a random large number, for example 4 X 40 GB = 160 GB. Because what is meant here is THE TOTAL RESULTING AMOUNT OF DISK SPACE IN THE RAID 5 ARRAY, AND NOT THE MAXIMUM SIZE OF A DISK PARTITION. So once I fill that field with 160 GB, the installer "automagically" sets it to 106.8 GB, which is in effect the maximum available disk space using RAID 5.
Usability anyone?
"installer is organized around mount points" is correct, and what gets mounted on mount points? Volumes, not partitions. So it's consistent with the UI that the size is a volume size, not a partition size.
The problem here, is that users are used to being involved in details like making specific partitions in a specific order with specific sizes. The new UI de-emphasizes the need to be involved in that level of detail. It ends up making things more consistent regardless of which "device type" you use: LVM, LVM thinp, standard, or Btrfs. If you emphasize partitions, then you have to emphasize the user needing to know esoteric things.
What is NOT obvious: for single device installs, if you omit the size in the create mount point dialog, the size of the resulting volume will consume all remaining space. But since there's no way to preset raid5 at the time a mount point is created (raid5 is set after the fact), there isn't a clear way to say "use all remaining space for this". There's just a size field for the volume, and a space available value in the lower left hand corner.
Le 18/02/2015 23:12, Chris Murphy a écrit :
"installer is organized around mount points" is correct, and what gets mounted on mount points? Volumes, not partitions.
Says who?
On Wed, Feb 18, 2015 at 3:37 PM, Niki Kovacs info@microlinux.fr wrote:
Le 18/02/2015 23:12, Chris Murphy a écrit :
"installer is organized around mount points" is correct, and what gets mounted on mount points? Volumes, not partitions.
Says who?
Because it's ambiguous. A partition might entirely contain a volume (a filesystem), but in your case none of your partitions contain a volume. They're members of md raid first, only once that's assembled is there a logical block device, which happens to contain the volume, and it is the volume you're mounting. All you have to do is check fstab, partitions aren't assigned mount points, volumes are.
On 2/18/2015 8:20 PM, Chris Murphy wrote:
On Wed, Feb 18, 2015 at 3:37 PM, Niki Kovacsinfo@microlinux.fr wrote:
Le 18/02/2015 23:12, Chris Murphy a écrit :
"installer is organized around mount points" is correct, and what gets mounted on mount points? Volumes, not partitions.
Says who?
Because it's ambiguous. A partition might entirely contain a volume (a filesystem), but in your case none of your partitions contain a volume. They're members of md raid first, only once that's assembled is there a logical block device, which happens to contain the volume, and it is the volume you're mounting. All you have to do is check fstab, partitions aren't assigned mount points, volumes are.
and I make my mdraid's PV's for lvm, and create LV's that are my file systems which I mount. so thats one MORE level of indirection.
disks -> partition(s) -> mdraid devices -> PVs -> VG -> LV -> file system. phew.
On Wed, Feb 18, 2015 at 9:25 PM, John R Pierce pierce@hogranch.com wrote:
disks -> partition(s) -> mdraid devices -> PVs -> VG -> LV -> file system. phew.
You might be a candidate for LVM integrated raid. It uses the md kernel code on the backend, but it's all LVM tools to create, manage and monitor. The raid level is defined per LV, instead of all LV's in a VG inheriting the underlying raid. It supports all levels of raid including 5/6.
It doesn't quite have all the features of mdadm. But the flexibility it offers for use cases where LV's are often being created and destroyed and different redundancy levels/types are desired, it's neat.
And eventually, one of these years, Btrfs. That is so much simpler to create and manage.
disk>no partition>Btrfsraid>subvolumes instead of partitions
It doesn't have all the features of mdadm or lvm, especially when it comes to VM images. But for general purpose data, it's nice. It'll use different sized drives in a raid56, no fuss, no having to tell it how to do that. Online addition of yet another (unlike sized) drive and it just starts using it with a single 'btrfs device add' command. No restripe/resilver needed.
On 2/18/2015 9:39 PM, Chris Murphy wrote:
You might be a candidate for LVM integrated raid. It uses the md kernel code on the backend, but it's all LVM tools to create, manage and monitor. The raid level is defined per LV, instead of all LV's in a VG inheriting the underlying raid. It supports all levels of raid including 5/6. ... ... ... ... ... btrfs ...
actually, I prefer zfs. I was just saying how I do it on CentOS, where zfs is not really an option.
# zpool create zbig mirror hd10 hd11 mirror hd12 hd13 mirror hd14 hd15 mirror hd16 hd17 mirror hd18 hd19 spare hd20 hd21 # zfs create -o mountpoint=/mystuff zbig/mystuff
done.
.... but, is that lvm integrated raid stuff available in RHEL/CentOS 6 or 7 yet ?
On 2/18/2015 11:06 PM, John R Pierce wrote:
.... but, is that lvm integrated raid stuff available in RHEL/CentOS 6 or 7 yet ?
/me scribbles postit note to self: google BEFORE hitting send....
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm...
ahhh, interesting. its in 6.3+
On Thu, Feb 19, 2015 at 12:06 AM, John R Pierce pierce@hogranch.com wrote:
On 2/18/2015 9:39 PM, Chris Murphy wrote:
You might be a candidate for LVM integrated raid. It uses the md kernel code on the backend, but it's all LVM tools to create, manage and monitor. The raid level is defined per LV, instead of all LV's in a VG inheriting the underlying raid. It supports all levels of raid including 5/6. ... ... ... ... ... btrfs ...
actually, I prefer zfs. I was just saying how I do it on CentOS, where zfs is not really an option.
It should be possible on CentOS 7, I know a couple people using ZoL in production on Fedora since circa Fedora 19. The ZoL implementation is not nearly as kernel version dependent as Btrfs is right now. But I think most anyone would say at the moment the implementation is much better on FreeBSD.
While ZFS is production stable, Btrfs comes with caveats. But already it requires far less resources than ZFS, can grow and shrink in ways ZFS can't, and I think snapshots are easier to understand, no parent-child type relationship.
.... but, is that lvm integrated raid stuff available in RHEL/CentOS 6 or 7 yet ?
Yes since CentOS 6.3.
Le 18/02/2015 23:12, Chris Murphy a écrit :
What is NOT obvious: for single device installs, if you omit the size in the create mount point dialog, the size of the resulting volume will consume all remaining space. But since there's no way to preset raid5 at the time a mount point is created (raid5 is set after the fact), there isn't a clear way to say "use all remaining space for this". There's just a size field for the volume, and a space available value in the lower left hand corner.
Well, maybe it's just me. I've started Linux on Slackware 7.1 and used pretty much every major and minor distribution under the sun. I know my way around Slackware, Debian, CentOS, FreeBSD, Gentoo, Arch and many more, and my favourite installer is - and will always be - Slackware's bone-headed NCurses installer that lets the admin do pretty much what he wants - and needs - to do. CentOS 5.x's text mode installer got pretty close, but then, for mysterious reasons, Red Hat decided to cripple it into oblivion. Go figure.
I love CentOS, been using it since 4.x. But frankly, CentOS 7's installer is an abomination.
All's well that ends well. It only took me a day and a half to figure out how to configure RAID 5 using the graphical assistant. Something I could have done in less than three minutes using fdisk and mdadm --create.
Cheers,
Niki
Niki Kovacs wrote:
Le 18/02/2015 23:12, Chris Murphy a écrit :
What is NOT obvious: for single device installs, if you omit the size in the create mount point dialog, the size of the resulting volume will consume all remaining space. But since there's no way to preset raid5 at the time a mount point is created (raid5 is set after the fact), there isn't a clear way to say "use all remaining space for this". There's just a size field for the volume, and a space available value in the lower left hand corner.
<snip>
close, but then, for mysterious reasons, Red Hat decided to cripple it into oblivion. Go figure.
One word: desktop. That's what they want to conquer next.
I love CentOS, been using it since 4.x. But frankly, CentOS 7's installer is an abomination.
All's well that ends well. It only took me a day and a half to figure out how to configure RAID 5 using the graphical assistant. Something I could have done in less than three minutes using fdisk and mdadm --create.
We don't want to use lvm - my manager doesn't like it, and given how much we hit our machines, we almost don't use vm's, either - we need all CPU cycles for some things (like heavy scientific computing).
We also pretty much don't use any drives under 1TB. The upshot is we had custom scripts for > 500GB, which made 4 partitions - /boot (1G, to fit with the preupgrade), swap (2G), / (497G - and we're considering downsizing that to 250G, or maybe 150G) and the rest in another partition for users' data and programs. The installer absolutely does *not* want to do what we want. We want swap - 2G - as the *second* partition. But if we use the installer, as soon as we create the third partition, of 497GB, for /, it immediately reorders them, so that / is second.
Duh....
The result is that we get to the screen to choose the drive, and say "custom partition"... then <alt-F2>, and use parted to make the partitions, then go back to the GUI and just assign the mount points and filesystem types.
And why would you *want* / to have everything? I want to be able to install a newer o/s, or whatever, and not have to worry about all the data, etc - I want that in a separate partition (no, don't format that, thank you).
mark
On Wed, Feb 18, 2015 at 4:20 PM, m.roth@5-cent.us wrote:
Niki Kovacs wrote:
Le 18/02/2015 23:12,
close, but then, for mysterious reasons, Red Hat decided to cripple it into oblivion. Go figure.
One word: desktop. That's what they want to conquer next.
OK well there's a really long road to get to that pie in the sky. I don't see it happening because it seems there's no mandate to basically tell people what they can't have, instead it's well, we'll have a little of everything.
Desktop OS that are the conquerers now? Their installers don't offer 100's of layout choices. They offer 1-2, and they always work rock solid, no crashing, no user confusion, essentially zero bugs. The code is brain dead simple, and that results in stability.
*shrug*
Long road. Long long long. Tunnel. No light. The usability aspects are simply not taken seriously by the OS's as a whole. It's only taken seriously by DE's and they get loads of crap for every change they want to make. Until there's a willingness to look at 16 packages as a whole rather than 1 package at a time, desktop linux has no chance. The very basic aspects of how to partition, assemble, and boot and linux distro aren't even agreed upon. Fedora n+1 has problems installing after Fedora n. And it's practically a sport for each distro to step on an existing distros installer. This is technologically solved, just no one seems to care to actually implement something more polite.
OS X? It partitions itself, formats a volume, sets the type code, writes some code into NVRAM, in order to make the reboot automatically boot the Windows installer from a USB stick. It goes out of it's way to invite the foreign OS.
We can't even do that with the same distro, different version. It should be embarrassing but no one really cares enough to change it. It's thankless work in the realm of polish. But a huge amount of success for a desktop OS comes from polish.
We also pretty much don't use any drives under 1TB. The upshot is we had custom scripts for > 500GB, which made 4 partitions - /boot (1G, to fit with the preupgrade), swap (2G), / (497G - and we're considering downsizing that to 250G, or maybe 150G) and the rest in another partition for users' data and programs. The installer absolutely does *not* want to do what we want. We want swap - 2G - as the *second* partition. But if we use the installer, as soon as we create the third partition, of 497GB, for /, it immediately reorders them, so that / is second.
I'm open to having my mind changed on this, but I'm not actually understanding why it needs to be in the 2nd slot, other than you want it there, which actually isn't a good enough reason. If there's a good reason for it to be in X slot always, for everyone, including anticipating future use, then that's a feature request and it ought to get fixed. But if it's a specific use case, well yeah you get to pre-partition and then install.
On 19.02.2015 06:28, Chris Murphy wrote:
On Wed, Feb 18, 2015 at 4:20 PM, m.roth@5-cent.us wrote:
Niki Kovacs wrote:
Le 18/02/2015 23:12,
close, but then, for mysterious reasons, Red Hat decided to cripple it into oblivion. Go figure.
One word: desktop. That's what they want to conquer next.
OK well there's a really long road to get to that pie in the sky. I don't see it happening because it seems there's no mandate to basically tell people what they can't have, instead it's well, we'll have a little of everything.
Desktop OS that are the conquerers now? Their installers don't offer 100's of layout choices. They offer 1-2, and they always work rock solid, no crashing, no user confusion, essentially zero bugs. The code is brain dead simple, and that results in stability.
*shrug*
Long road. Long long long. Tunnel. No light. The usability aspects are simply not taken seriously by the OS's as a whole. It's only taken seriously by DE's and they get loads of crap for every change they want to make. Until there's a willingness to look at 16 packages as a whole rather than 1 package at a time, desktop linux has no chance. The very basic aspects of how to partition, assemble, and boot and linux distro aren't even agreed upon. Fedora n+1 has problems installing after Fedora n. And it's practically a sport for each distro to step on an existing distros installer. This is technologically solved, just no one seems to care to actually implement something more polite.
OS X? It partitions itself, formats a volume, sets the type code, writes some code into NVRAM, in order to make the reboot automatically boot the Windows installer from a USB stick. It goes out of it's way to invite the foreign OS.
We can't even do that with the same distro, different version. It should be embarrassing but no one really cares enough to change it. It's thankless work in the realm of polish. But a huge amount of success for a desktop OS comes from polish.
I think the problem is that you simply have to draw a distinction between technology and product. The rise of the Linux desktop will never happen because Linux is not a product but a technology and as a result has to be a jack of all trades. The reason Apple is so successful I believe is because they understood more than others that people don't care about technology but want one specific consistent experience. They don't core how the harddisk is partitioned. So I can see the rise of the "X desktop" but only if X is willing to have its own identity an eschew the desire to be compatible with everything else or cater to both casual users and hard-core admin types. In other words the "X Desktop" would have to be a very opinionated product rather than a highly flexible technology.
We also pretty much don't use any drives under 1TB. The upshot is we had custom scripts for > 500GB, which made 4 partitions - /boot (1G, to fit with the preupgrade), swap (2G), / (497G - and we're considering downsizing that to 250G, or maybe 150G) and the rest in another partition for users' data and programs. The installer absolutely does *not* want to do what we want. We want swap - 2G - as the *second* partition. But if we use the installer, as soon as we create the third partition, of 497GB, for /, it immediately reorders them, so that / is second.
I'm open to having my mind changed on this, but I'm not actually understanding why it needs to be in the 2nd slot, other than you want it there, which actually isn't a good enough reason. If there's a good reason for it to be in X slot always, for everyone, including anticipating future use, then that's a feature request and it ought to get fixed. But if it's a specific use case, well yeah you get to pre-partition and then install.
When I was younger I cared about where exactly each partition was positioned but nowadays I refer to all my file systems using the uuid so I don't really care anymore if / is the second or fifth partition. The same is true for network interfaces. Since I mostly deal with physical interfaces on Hypervisors only these days and there I am more interested in bridges rather than the nics themselves I couldn't care less if the interface is named eth0 or enp2something. I tend to think more in terms of logical resources these days rather than physical ones.
Regards, Dennis
On Thu, Feb 19, 2015 at 5:47 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
I think the problem is that you simply have to draw a distinction between technology and product. The rise of the Linux desktop will never happen because Linux is not a product but a technology and as a result has to be a jack of all trades.
I'm unconvinced. True, Chromebooks uses the linux kernel, and thus it qualifies, sorta, as Linux desktop. But this is something analogous to OS X using a FOSS kernel and some other BSD stuff, but the bulk of it is proprietary. Maybe Chrome isn't quite that proprietary, but it's not free either. And Chrome OS definitely is not jack of all trades. What it can run is very narrow in scope right now.
The reason Apple is so successful I believe is because they understood more than others that people don't care about technology but want one specific consistent experience. They don't core how the harddisk is partitioned. So I can see the rise of the "X desktop" but only if X is willing to have its own identity an eschew the desire to be compatible with everything else or cater to both casual users and hard-core admin types. In other words the "X Desktop" would have to be a very opinionated product rather than a highly flexible technology.
Hmm, well Apple as a pretty good understanding what details are and aren't important to most people. That is, they discriminate. People do care about technologies like disk encryption, but they don't care about the details of how to enable or manage it. Hence we see both iOS and Android enable it by default now. Change the screen lock password, and it also changes the encryption unlock password *while removing* the previous password all in one step. On all conventional Linux distributions, this is beyond confusing and is totally sysadmin territory. I'd call it a bad experience.
OK so that's mobile vs desktop, maybe not fair. However, OS X has one button click full disk encryption as opt in post-install (and opt out after). This is done with live conversion. The user can use the computer normally while conversion occurs, they can put the system to sleep, and even reboot it, and will resume conversion when the system comes back up. Decrypt conversion works the same way. They are poised to make full disk encryption a default behavior, without having changed the user experience at all, in the next major release of the software. I don't know whether they'll do it, but there are no technical or usability impediments.
Linux distros experience on this front is terrible. Why? Linux OS's don't have a good live conversion implementation (some people have tried this and have hacks, but no distro has adopted this); but Ok the installer could just enable it by default, obviating conversion. But there's no one really looking at the big picture, looking at dozens of packages, how this affects them all from the installer password policy, to Gnome and KDE. You'd need the add user GUI tools to be able to change both user login and encryption passphrase passwords, to keep them in sync, and remove the old one. And currently LUKS has this 8 slot limit, which is probably not a big problem, but might be a sufficient barrier in enough cases that this needs extending.
And so on...
On 19.02.2015 19:41, Chris Murphy wrote:
On Thu, Feb 19, 2015 at 5:47 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
I think the problem is that you simply have to draw a distinction between technology and product. The rise of the Linux desktop will never happen because Linux is not a product but a technology and as a result has to be a jack of all trades.
I'm unconvinced. True, Chromebooks uses the linux kernel, and thus it qualifies, sorta, as Linux desktop. But this is something analogous to OS X using a FOSS kernel and some other BSD stuff, but the bulk of it is proprietary. Maybe Chrome isn't quite that proprietary, but it's not free either. And Chrome OS definitely is not jack of all trades. What it can run is very narrow in scope right now.
The reason Apple is so successful I believe is because they understood more than others that people don't care about technology but want one specific consistent experience. They don't core how the harddisk is partitioned. So I can see the rise of the "X desktop" but only if X is willing to have its own identity an eschew the desire to be compatible with everything else or cater to both casual users and hard-core admin types. In other words the "X Desktop" would have to be a very opinionated product rather than a highly flexible technology.
Hmm, well Apple as a pretty good understanding what details are and aren't important to most people. That is, they discriminate. People do care about technologies like disk encryption, but they don't care about the details of how to enable or manage it. Hence we see both iOS and Android enable it by default now. Change the screen lock password, and it also changes the encryption unlock password *while removing* the previous password all in one step. On all conventional Linux distributions, this is beyond confusing and is totally sysadmin territory. I'd call it a bad experience.
OK so that's mobile vs desktop, maybe not fair. However, OS X has one button click full disk encryption as opt in post-install (and opt out after). This is done with live conversion. The user can use the computer normally while conversion occurs, they can put the system to sleep, and even reboot it, and will resume conversion when the system comes back up. Decrypt conversion works the same way. They are poised to make full disk encryption a default behavior, without having changed the user experience at all, in the next major release of the software. I don't know whether they'll do it, but there are no technical or usability impediments.
Linux distros experience on this front is terrible. Why? Linux OS's don't have a good live conversion implementation (some people have tried this and have hacks, but no distro has adopted this); but Ok the installer could just enable it by default, obviating conversion. But there's no one really looking at the big picture, looking at dozens of packages, how this affects them all from the installer password policy, to Gnome and KDE. You'd need the add user GUI tools to be able to change both user login and encryption passphrase passwords, to keep them in sync, and remove the old one. And currently LUKS has this 8 slot limit, which is probably not a big problem, but might be a sufficient barrier in enough cases that this needs extending.
I'm not sure why you seem to disagree with what I wrote ("unconvinced") and then basically say what I was saying.
Linux with a thousand knobs is never going become popular. Instead somebody has to go and create an opinionated system where most knobs are removed and replaced by sane/good/useful defaults. Like Google with its Chromebooks.
Regards, Denis
Dennis Jacobfeuerborn dennisml@conversis.de
I'm not sure why you seem to disagree with what I wrote ("unconvinced") and then basically say what I was saying.
you: result has to be a jack of all trades.
me: Chrome is not jack of all trades (yet) yet is very successful/growing
But also I'm unconvinced in general. I don't know how this all plays out. But you and I are definitely on the same page with respect to "Linux with a thousand knobs" popularity contest.
Granted, Windows made this work along with an army of sysadmins, so there will be the cases where schools and governments (e.g. München, Brasilia, etc.) and some businesses can make that work. Hopefully there's enough understanding this is "freedom/libre software" and not "no cost" software. That former proprietary software license budget needs to somehow get divvied up to e.g. the Document Foundation, Linux Foundation, FSF, whatever. The concept that's important is not "no one owns the software" it's "everyone owns the software". I think it's really questionable having public dollars spend money on license fees especially when proprietary formats get used to store public data (all of it is public data ultimately).
But, overwhelmingly (obviously) where Linux OS's are popular are the totally sysadmin free ones that actually have polish: Chrome OS, Android/Cyanogen. I think it's the polish, not the fact they're mobile OS's, that make them successful.
Kinda jaw dropping is that Microsoft is starting to "get it" more than Apple when it comes to being a better citizen on multiple platform, and they've even been contributing to the linux kernel for a while, and open sourcing some of their own stuff, and cooperating with the Samba folks to make everything work better. Not perfect of course, but Apple, as much as they some things right, they really face plant in other areas. Most of their open source effort is languishing.
On Wed, Feb 18, 2015 at 3:59 PM, Niki Kovacs info@microlinux.fr wrote:
Well, maybe it's just me. I've started Linux on Slackware 7.1 and used pretty much every major and minor distribution under the sun. I know my way around Slackware, Debian, CentOS, FreeBSD, Gentoo, Arch and many more, and my favourite installer is - and will always be - Slackware's bone-headed NCurses installer that lets the admin do pretty much what he wants - and needs - to do.
I'm definitely not suggesting it's just you. I'm coming up with a plausible explanation for the confusion, and that's a misalignment between your expectations and the installer's presentation. I can tell you, having using this installer since Fedora 18, it has changed immensely from the initial versions.
My personal view on installers is extremely biased toward the user staying out of trouble, they shouldn't have to read documentation for a GUI installer. The entire point of a GUI installer is to protect the user from bad choices, non-standard or unsupportable choices, or having to read a volume of documentation, or become an expert for something that quite frankly happens rarely: OS installation.
And my very strong bias is affected by both the OS X and Windows installers, which are completely, utterly, brain dead. And I mean that in a good way. It's impossible for the user to get confused, there are almost no choices. It's next to impossible for there to be bugs, there are almost no choices. Every outcome of the installation is supportable, because the user wasn't allowed to create completely nutty layouts that make no sense.
Now, for various reasons Anaconda (the Fedora/RHEL/CentOS installer) is exceptionally more capable than almost any other GUI installer out there. And that makes it complex, prone to bugs, and prone to confusing users and subject to criticism. That's just the inevitable result of trying to do so many things.
I love CentOS, been using it since 4.x. But frankly, CentOS 7's installer is an abomination.
Having done many hundreds, possibly over a thousand installations with it, I'm well aware of how confusing it can be. So the criticism is almost certainly reasonable, no matter what. I'm just saying that once you understand the point of view of the installer (which arguably you should not have to do), things become much easier. That doesn't mean easy. Just easier.
All's well that ends well. It only took me a day and a half to figure out how to configure RAID 5 using the graphical assistant. Something I could have done in less than three minutes using fdisk and mdadm --create.
Right, but inevitably that failure is the result of misalignment of expectations between you and the installer. That's an explanation, not an assignment of blame. The reason why working directly with partitions is easy for you, and what you expect, is simply because that's how you've always done it, since that's how all other installers behave. Anaconda is really the first installer that deemphasizes that. And I think that's a bold move, and for a GUI installer that's necessarily taking on a lot of complexity I think it's probably a good idea overall. But it does have a lot of bugs still... it's definitely doing things that I don't like.
But any experienced sysadmin knows how users say "it should work like X" and how often they're wrong. They're just used to things that work like X and that's why they want this new problem to work that same way. So as a sysadmin or network engineer you ask questions to find out how to get the user from A to B, and the details of "how it should work" are your domain, your specialty, and ultimately they don't really care how it happens, they just want to get to B. And once that's well understood, you can get on with things.
And one problem is the installer can't really have that kind of diplomatic conversation about what its worldview is, so that the user expectations re-align with the end goal in mind, not how to get there.
Le 19/02/2015 05:43, Chris Murphy a écrit :
My personal view on installers is extremely biased toward the user staying out of trouble, they shouldn't have to read documentation for a GUI installer.
A *user* never has to even see - or use - an installer. A USER has to USE a computer, by which I mean the applications he or she needs to get some work done.
The person who gets to be confronted by an OS installer is not a user, it's an ADMIN, which is an entirely different thing. An ADMIN should RTFM (a lot) and know his way about what you call "esoteric things" earlier in this thread (disks, partitions, volumes).
My company (http://www.microlinux.fr) installs complete Linux-based networks for schools, town halls, public libraries etc. here in South France. For now, most of my server and desktop solutions are based on a highly modified version of Slackware Linux, with some CentOS and some RHEL here and there. I'm currently planning on migrating everything to CentOS in the long run.
One of the founding principles of my company is the constant SEPARATION BETWEEN USING A COMPUTER AND ADMINISTRATING IT. A user never ever has to worry about things that pertain to system administration, and it would be very wrong if he or she ever has to deal with such a thing as an installer. For what it's worth, some of my users don't even know that this thing that they're using every day is called Linux under the hood. To them, it's just the machine that's running things like their library management software, or whatever.
So, as an admin, what I want from an installer is FLEXIBILITY... and not an "assistant" that reminds me of Microsoft Office's infamous Clippy and expects me to jump through burning loops to configure the system as I want it.
Cheers,
Niki
On Thu, Feb 19, 2015 at 12:25 AM, Niki Kovacs info@microlinux.fr wrote:
A *user* never has to even see - or use - an installer. A USER has to USE a computer, by which I mean the applications he or she needs to get some work done.
This is a false dichotomy. I reject it. There's too much fact to the contrary. My mom has done an OS installation, she is most definitely not an admin.
The person who gets to be confronted by an OS installer is not a user, it's an ADMIN, which is an entirely different thing.
Well, you're wrong. I'd say you have never used a Windows or OS X installer, they're a piece of cake. My house plant could do an installation.
Anaconda isn't absurdly far behind that experience when it comes to automatic installs (to blank drives).
An ADMIN should RTFM (a lot) and know his way about what you call "esoteric things" earlier in this thread (disks, partitions, volumes).
Sure. But GUI installers are general purpose tools for admins and user use alike. If you care about things like partition tables and their type codes, you aren't very well suited for using a GUI installer.
My company (http://www.microlinux.fr) installs complete Linux-based networks for schools, town halls, public libraries etc. here in South France. For now, most of my server and desktop solutions are based on a highly modified version of Slackware Linux, with some CentOS and some RHEL here and there. I'm currently planning on migrating everything to CentOS in the long run.
One of the founding principles of my company is the constant SEPARATION BETWEEN USING A COMPUTER AND ADMINISTRATING IT. A user never ever has to worry about things that pertain to system administration, and it would be very wrong if he or she ever has to deal with such a thing as an installer. For what it's worth, some of my users don't even know that this thing that they're using every day is called Linux under the hood. To them, it's just the machine that's running things like their library management software, or whatever.
It sounds like a mobile device running cyanogen, except there is no clear line between user and administrating it.
I'm not a big fan of this separation between admin and computers when it comes to basic plumbing type stuff like getting a working OS installed. That should be something either really easy or totally unnecessary like a stateless machine that can be reset and self heal. The fact desktop haven't caught up to mobile in this regard, is sorta embarassing.
Actually, Windows 8 comes fairly close to having statelessness, once it's installed by a conventional installer. But not OS X. Notice how Android, cyanogen don't even have monolithic installers. I'm just not a fan of needing such a thing in the first place these days, it's antiquated.
So, as an admin, what I want from an installer is FLEXIBILITY... and not an "assistant" that reminds me of Microsoft Office's infamous Clippy and expects me to jump through burning loops to configure the system as I want it.
What you're describing is what kickstart is for. That's flexible and fairly bug free. GUI installers, the more complex you make them (flexibility) the buggier they are.
Fedora Atomic, one possible way of the future without any installer. Atomic updates, and rollback and rollfoward. http://www.projectatomic.io/
And another using btrfs send/receive images (not mentioned but could instead use seed devices): http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
Le 19/02/2015 11:03, Chris Murphy a écrit :
This is a false dichotomy. I reject it. There's too much fact to the contrary. My mom has done an OS installation, she is most definitely not an admin.
I'd say your mom is an admin in the sense that chickens fly and horses swim.
:o)
On Thu, Feb 19, 2015 at 3:28 AM, Niki Kovacs info@microlinux.fr wrote:
Le 19/02/2015 11:03, Chris Murphy a écrit :
This is a false dichotomy. I reject it. There's too much fact to the contrary. My mom has done an OS installation, she is most definitely not an admin.
I'd say your mom is an admin in the sense that chickens fly and horses swim.
It's a confusing analogy. Chickens don't fly. Horses do swim.
On 20 February 2015 at 05:25, Chris Murphy lists@colorremedies.com wrote:
I'd say your mom is an admin in the sense that chickens fly and horses swim.
It's a confusing analogy. Chickens don't fly. Horses do swim.
I have a couple of chickens, and yes, the buggers do fly if you don't clip their flight feathers. :-)
Kahlil Hodgson wrote:
On 20 February 2015 at 05:25, Chris Murphy lists@colorremedies.com wrote:
I'd say your mom is an admin in the sense that chickens fly and horses swim.
It's a confusing analogy. Chickens don't fly. Horses do swim.
I have a couple of chickens, and yes, the buggers do fly if you don't clip their flight feathers. :-)
I can't resist... "tie your kangaroos, er, chickens down, sport, tie your chickens down...
mark "old songs 'r' us"
On Thu, Feb 19, 2015 at 1:38 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
On 20 February 2015 at 05:25, Chris Murphy lists@colorremedies.com wrote:
I'd say your mom is an admin in the sense that chickens fly and horses swim.
It's a confusing analogy. Chickens don't fly. Horses do swim.
I have a couple of chickens, and yes, the buggers do fly if you don't clip their flight feathers. :-)
Ahh OK of course, short flights. Well nevertheless I do not at all consider my mom anything remotely approaching an admin just because she's done an OS installation...
-
Chris Murphy -
Dennis Jacobfeuerborn -
g -
John R Pierce -
Kahlil Hodgson -
m.roth＠5-cent.us -
Michael Volz -
Niki Kovacs