Age | Commit message (Collapse) | Author |
|
|
|
This gives two advantages:
1) assurance the right package gets installed (and more explicit for user)
2) no need to ask for a bootloader again later in the process.
Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
|
|
find_usable_blockdevices returns a list of block devices such as those
exposed by SCSI/Sata, CCISS, IDA, LVM and Linux SOFT RAID; as well as
any partitions on top of those.
Devices in use by LVM and SOFT RAID are excluded.
Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
|
|
Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
|
|
|
|
* indentation fixes
* simplify label/uuid code
* simplify variable names
* remove some cruft
* fix/improve some code and spelling
|
|
Uses bash globbing and parameter expansion to find all of the slaves for
a raid device. This is a much better method then using ls. Also, by
looking at DEVNAME in the uevent file we provide support for block
device that are not in the root of /dev.
Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
|
|
again afterwards
|
|
device_is_raid now uses dev major number to determine if a device is a
raid device. A major ID of 8 is a /dev/sd? device whereas a major ID of
9 is a 'metadata' (raid) device.
Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
|
|
|
|
Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
|
|
Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
|
|
hd/sd partitions
|
|
|
|
|
|
|
|
Filesystems"
|
|
this was broken since 6d8f39a5e114755b67b86529e6f16b7d9ee752df
also, partinfo gathering is now in lib-blockdevices-filesystems.sh
|
|
some sizes not be shown
|
|
to echo"
|
|
|
|
|
|
make the finddisks and findblockdevices code more robust and somewhat
cleaner
|
|
Due do to some old remaining cruft, the API for
finddisks and findblockdevices was needlessly complicated.
The only thing really needed is some ability to control what goes
between entries. Al the other stuff (string at the end, control of
newlines) was pointless.
|
|
|
|
|
|
|
|
|
|
now the information about which setup programs for filesystems, label
programs, which FS'es can go on which blockdevices, need/can have
labels, can be mounted and FS friendly names are in a central place
in libs/lib-blockdevices-filesystems.sh.
This simplifies the code somewhat where you actually want to work with
the filesystems.
Also, we only check the available filesystem utilities once at program
startup, causing a performance improvement.
|
|
|
|
filesystem packages are scheduled to go out of base, hence
AIF must track which ones are needed and which are not by keeping an eye
open during the filesystems creation (and rollback) steps.
In the interactive procedure, the appropriate packages will be
preselected, in the automatic procedure, you're supposed to configure
the needed packages yourself now. This is reflected in the examples.
|
|
fs_opts. this should fix some bugs with filesystem creating failing when options were specified
|
|
|
|
ready in time. fixes http://mailman.archlinux.org/pipermail/arch-releng/2010-April/000974.html
|
|
|
|
Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
|
|
implemented yet
|
|
|
|
|
|
|
|
/etc/fstab
|
|
This causes some extra space to be saved for the MBR, which is needed for grub2 in some cases.
http://www.mail-archive.com/arch-general@archlinux.org/msg11100.html
|
|
|
|
target fstab won't harm anyone even if we couldnt mount it on the live env
|
|
|
|
|
|
Attached the extended patch, this replaced the one from my earlier mail.
* Fixed grub device mapping in automatic procedure
* Fixed bootdevice handling either if we use a seperate /boot or not in
automatic procedure.
* Added a hint to Luks passphrasing during process_filesystem
The test i have made:
a) automatic-lvm-dmcrypt-install-sda:
menu.lst ok, HOOKS ok, Boot is fine....
b) generic-install-sda:
menu.lst ok, HOOKs ok, boot ok
c) generic-install-sda (but without seperate /boot partiton, sda1=swap
sda2=/)
menu.lst ok, HOOKs ok, boot ok
d) fancy-install-on-sda
Fails on creating all filesystems/lvm-partitions here, but this is because my
Virtualbox VM has a too small disk
http://users.archlinux.de/~gerbra/tmp/fancy-install-sda.png
http://users.archlinux.de/~gerbra/tmp/fancy-install-sda-tty7.png
With this changes i build now a new local iso here and test again a
interactive install (no lvm,no crypt, only a normal install) to see if
we hurt something in interactive... But i guess not....
Gerhard
|
|
|
|
I have tested it:
- With raid1 and seperate /boot on an raid array
- With raid1 and no seperate /boot on an raid array
- Without raid and with/without seperate /boot
On all installs grub installs successfully and i could boot the system.
On the raid systems i could also boot from each HD in the array.
|
|
|