I did an install yesterday and i too had / mounted as read only (syslinux) I triple boot and Arch is on HDD3 so i use Sabayons grub to boot into arch , after messin with the fstab it was all good , is this another new "feature of Arch" ? seems there's more spanners flying than at a scaffolders convention of late , still i enjoy the challenge . On 20 September 2012 09:02, Jude DaShiell <jdashiel@shellworld.net> wrote:
/mnt/etc/fstab in all installation attempts. One thing not explained on the beginners guide is what does labels buy you as opposed to what does uid's buy you with genfstab. Also, I did learn syslinux does not support xfs the root of the disk could not be found whenever I used xfs. Grub-legacy I think is gone and grub-bios didn't work and neither did
I neglected to mention when I did a genfstab I used genfstab -p -L /mnt lilo. I can try more things later but not without some suggestions and sighted assistance to tell me what the next failing boot screen produces.
On Tue, 18 Sep 2012, David C. Rankin wrote:
On 09/18/2012 03:53 AM, P .NIKOLIC wrote:
On Tue, 18 Sep 2012 03:47:26 -0400 (EDT) Jude DaShiell<jdashiel@shellworld.net> wrote:
Whenever does an install of archlinux, they also do a big update so it's safe to say I got nailed by this problem too. I'm not going to dismiss out of hand the probability that util-linux is at fault, but when I tried the installs this past weekend I suspected mkinitcpio or perhaps syslinux-install_update might be at fault. However if in this update process neither of those utilities were used, then both of them are cleared. It seems when util-linux finishes running after install or update it fails to set the sticky bits on partitions and lesser components in the linux file system at least in ext4 which is what I used to try the installs this past weekend in line with the installation guide on the archlinux wiki. HUmmmm you got me wondering now that could well be both partitions that have the problem are ext4 why i did not change them to my more normal XFS i dont know ..
I may have to back a lot up and rebuild but this time i will let my normal hate of the entire EXT file system rule and go XFS never been let down there ..
Pete .
Pete,
I have run Arch on several filesystems and I've been lucky I guess. Currently on this box, I have ext3, ext4 and reiser (old SuSE 10.0 partition). This box has been running since mid-2009 and updates are usually weekly (sometimes I go a couple of weeks if I can't risk a break due to workload) I have not had any of the mount ro weirdness even after several multi-gigabyte updates. The current partitions I have are:
/dev/sdc5 on / type ext3 (rw,relatime,data=ordered) /dev/sdc7 on /home type ext4 (rw,relatime,data=ordered) /dev/sda2 on /mnt/pv type reiserfs (rw,relatime) /dev/sdb2 on /mnt/win type fuseblk
(rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
I don't know what is doing it in your case, but it seems like we
should be
able to figure out where mount ro/rw logic for the resides (I picture something like the following buried somewhere):
if [conditional]; then mount -o rw [whatever] else mount -o ro [whatever] fi
I suspect this may be complicated by the fact that mounting (or remounting) takes place in several different places/processes during the boot. Anybody familiar with this off-hand or any idea where Pete might look to rule-in or rule-out the different parts of boot that could effect this? Sorry I don't have more, I just haven't had the need to dissect the boot mount process to that level before...
I guess you are just lucky :)
--------------------------------------------------------------------------- jude <jdashiel@shellworld.net> Adobe fiend for failing to Flash
-- www.cirrusminor.info <http://cirrusminor.info> <http://www.cirrusminor.info/> <http://www.cirrusminor.info/> <http://www.cirrusminor.info/>