Auto-remount of root file system, like read only

Hello, I'm a newbie compiling kernels, but wanna learn. (I came here bacause i don't know how to solve this or where to find an answer). I compiled some few... but, in the last days i'm suffering an strange auto-remount of the root fs "/", (remounts like read only) it's temporally fixed using fsck and rebooting. But a time later of reboot, i'm working, and suddenly the same error comes again. it's really disturbing, because force to reboot often.
I think that is not a physical error. I did not have problems with badblocks. Something creates logical errors, either the auto-remount did
Surely I have something bad on the kernel, and probably have more things there than i must.
On the other hand my /var/log/lastlog is always full of an strange ASCII and i can't see the boot info.
this is my fstab:
/dev/sda6 / ext4 noatime 0 1
/dev/sda3 /home ext3 noatime 0 2
/dev/sda5 none swap sw 0 0
/dev/sr0 /media/cdrom auto noauto,ro,user 0 0
#/dev/fd0 /media/floppy auto noauto 0 0 No hay unidad de disco flsexible
proc /proc proc defaults 0 0
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
And a summary of my dmesg report
[ 55.917194] EXT4-fs (sda6): re-mounted. Opts: commit=0
[10195.993335] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target
to attach helpers instead.
[10229.239298] ata1.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x0
[10229.239305] ata1.00: irq_stat 0x40000001
[10229.239318] ata1.00: cmd 60/80:00:a8:4d:6e/00:00:2d:00:00/40 tag 0 ncq 65536 in
[10229.239318] res 41/40:80:1e:4e:6e/00:00:2d:00:00/00 Emask 0x409 (media error) <F>
[10229.239330] ata1.00: cmd 60/20:08:b0:98:bb/00:00:07:00:00/40 tag 1 ncq 16384 in
[10229.239330] res 41/04:00:1e:4e:6e/00:00:2d:00:00/00 Emask 0x1 (device error)
[10229.239342] ata1.00: cmd 61/08:10:47:98:c0/00:00:37:00:00/40 tag 2 ncq 4096 out
[10229.239342] res 41/04:00:1e:4e:6e/00:00:2d:00:00/00 Emask 0x1 (device error)
[10229.239354] ata1.00: cmd 61/28:18:17:96:21/00:00:38:00:00/40 tag 3 ncq 20480 out
[10229.239354] res 41/04:00:1e:4e:6e/00:00:2d:00:00/00 Emask 0x1 (device error)
[10229.243923] ata1.00: configured for UDMA/133
[10229.243944] sd 0:0:0:0: [sda] Unhandled sense code
[10229.243948] sd 0:0:0:0: [sda]
[10229.243951] Result: hostbyte=0x00 driverbyte=0x08
[10229.243955] sd 0:0:0:0: [sda]
[10229.243957] Sense Key : 0x3 [current] [descriptor]
[10229.243963] Descriptor sense data with sense descriptors (in hex):
[10229.243966] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[10229.243980] 2d 6e 4e 1e
[10229.243988] sd 0:0:0:0: [sda]
[10229.243990] ASC=0x11 ASCQ=0x4
[10229.243995] sd 0:0:0:0: [sda] CDB:
[10229.243997] cdb[0]=0x28: 28 00 2d 6e 4d a8 00 00 80 00
[10229.244156] end_request: I/O error, dev sda, sector 935368775
[10229.244161] Buffer I/O error on device sda6, logical block 1336321
[10229.244164] lost page write due to I/O error on sda6
[10229.244177] sd 0:0:0:0: [sda]
[10229.244179] Result: hostbyte=0x00 driverbyte=0x08
[10229.244183] sd 0:0:0:0: [sda]
[10229.244185] Sense Key : 0xb [current] [descriptor]
[10229.244189] Descriptor sense data with sense descriptors (in hex):
[10229.244192] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[10229.244206] 2d 6e 4e 1e
[10229.244213] sd 0:0:0:0: [sda]
[10229.244215] ASC=0x0 ASCQ=0x0
[10229.244219] sd 0:0:0:0: [sda] CDB:
[10229.244221] cdb[0]=0x2a: 2a 00 38 21 96 17 00 00 28 00
[10229.244233] end_request: I/O error, dev sda, sector 941725207
[10229.244251] ata1: EH complete
[10229.244268] JBD2: Detected IO errors while flushing file data on sda6-8
[10229.244281] Aborting journal on device sda6-8.
[10229.439264] EXT4-fs error (device sda6): ext4_journal_start_sb:348: Detected aborted journal
[10229.439272] EXT4-fs (sda6): Remounting filesystem read-only
[10232.111686] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[10232.111692] ata1.00: irq_stat 0x40000008
[10232.111705] ata1.00: cmd 60/08:00:18:4e:6e/00:00:2d:00:00/40 tag 0 ncq 4096 in
[10232.111705] res 41/40:08:1e:4e:6e/00:00:2d:00:00/00 Emask 0x409 (media error) <F>
[10232.264635] ata1.00: configured for UDMA/133
[10232.264653] sd 0:0:0:0: [sda] Unhandled sense code
[10232.264657] sd 0:0:0:0: [sda]
[10232.264660] Result: hostbyte=0x00 driverbyte=0x08
[10232.264664] sd 0:0:0:0: [sda]
[10232.264666] Sense Key : 0x3 [current] [descriptor]
[10235.143085] Descriptor sense data with sense descriptors (in hex):
[10235.143088] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[10235.143103] 2d 6e 4e 1e
[10235.143110] sd 0:0:0:0: [sda]
[10235.143113] ASC=0x11 ASCQ=0x4
[10235.143117] sd 0:0:0:0: [sda] CDB:
[10235.143119] cdb[0]=0x28: 28 00 2d 6e 4e 18 00 00 08 00
[10235.143132] end_request: I/O error, dev sda, sector 762203678
[10235.143156] ata1: EH complete
Please, anybody could help me to undesrtand and solve this problem?
Is it a driver problem?
Regards

Your drive must be dying.
You can use SMART tools to check it.

Similar Messages

Zerofree: Shrinking ARCH guest VMDK--'remount the root file-system'?

Hi!
[using ZEROFREE]
Getting great results with and extra ARCH install running as a VMDK in Workstation.
REALLY need tips on shrinking the VMDK. obviously have deleted unneeded files
and now rather urgently need to learn what's eluding me so far.
1) zerofree is install IN the virtual machine (VMDK)workstation running on windows 8.
2) Here's the instructions for zerofree:
filesystem has to be unmounted or mounted read-only for zerofree to
work. It will exit with an error message if the filesystem is mounted
writable.
To remount the root file-system readonly, you can first
switch to single user runlevel (telinit 1) then use mount -o remount,ro
filesystem.
As it a VMDK and it's running would the only/best option be to: "remount the root file-system readonly" ??
OR, could i add the VMDK to another running arch system that I do have and NOT mount the VMachine thereby
allowing zero free to run even better on that?
Are both method JUST as efficive at shrinking? My guess would be the remount root file-system as read only
would NOT be as efficient at shrinking.
I could really use a brief walk-through on this as all attempts have failed so far.
I boot the ARCH virtual machine and do what may I ask?
Last edited by tweed (2012-06-05 07:43:41)

How did you use/test unison? In my case, unison, of course, is used in the cpio image, where there are no cache files, because unison has not been run yet in the initcpio image, before it had a chance to be used during boot time, to generate them; and during start up is when it is used; when it creates the archives. ...a circular dependency. Yet, files changed by the user would still need to be traversed to detect changes. So, I think that even providing pre-made cache files would not guarantee that they would be valid at start up, for all configurations of installation. -- I think, though, that these cache files could be copied/saved from the initcpio image to the root (disk and RAM), after they have been created, and used next time by copying them in the initcpio image during each start up. I think $HOME would need to be set.
Unison was not using any cache previously anyway. I was aware of that, but I wanted to prove it by deleting any cache files remaining.
Unison, actually, was slower (4 minutes) the first time it ran in the VM, compared to the physical hardware (3:10s). I have not measured the time for its subsequent runs, but It seemed that it was faster after the first run. The VM was hosted on a newer machine than what I have used so far: the VM host has an i3-3227U at 1.9 GHz CPU with 2 cores/4 threads and 8 GB of RAM (4 GB ware dedicated to the VM); my hardware has a Pentium B940 at 2 GHz CPU with 2 cores/2 threads and 4 GB of RAM.
I could see that, in the VM, rsync and cp were copying faster than on my hardware; they were scrolling quicker.
Grub, initially complains that there is no image, and shows a "Press any key to continue" message; if you continue, the kernel panics.
I'll try using "poll_device()". What arguments does it need? More than just the device; also the number of seconds to wait?
Last edited by AGT (2014-05-20 16:49:35)

[Solved] Canot format MicroSD. File system is read-only

I formatted it for my special needs some time ago using fdisk.
Don't remember the partition table, but there was 1 fat32 and 1 ext4 partition.
Now I want to format it fat32 clean, but I get the errors.
When I open GParted, it says
GParted wrote:/dev/sdb contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table?
If I click yes - it shows partitions, but creating new partition table fails, as it is read-only.
If I click no - it does not show up in the device list.
Here's a picture of the structure of the device.
What also strange, I remember making 1 GiB ext4, and rest fat32. But it shows the opposite.
So I tried formatting it with fdisk
$ fdisk /dev/sdb
o
n
w
fdisk: cannot write disk label: Bad file descriptor
I made sure they are unmounted
umount: /dev/sdb1: not mounted
umount: /dev/sdb2: not mounted
Then I checked the filesystems. The second one appears to be read-only
# fsck /dev/sdb1
fsck from util-linux 2.23.2
fsck.fat 3.0.22 (2013-07-19)
/dev/sdb1: 18 files, 96978/698280 clusters
# fsck /dev/sdb2
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
fsck.ext4: Read-only file system while trying to open /dev/sdb2
Disk write-protected; use the -n option to do a read-only
check of the device.
# fsck -n /dev/sdb2
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
/dev/sdb2: clean, 860/65664 files, 56633/262144 blocks
Tried the zero trick, but failed as well.
# dd if=/dev/zero of=/dev/sdb
dd: failed to open ‘/dev/sdb’: Read-only file system
# dd if=/dev/zero of=/dev/sdb2
dd: failed to open ‘/dev/sdb2’: Read-only file system
Tried to disable the write-protection
# hdparm -r0 /dev/sdb
/dev/sdb:
setting readonly to 0 (off)
readonly = 0 (off)
After that, fdisk still fails to format.
In Windows 8, it mounts only the fat32 part.
diskpart can't erase partition table as well.
Last edited by Doctor Drive (2013-10-09 08:28:13)

Finally I found the solution
MicroSD adapter has a "lock" feature.
When I inserted the adapter, the lock always triggered to locked state.
So I fixed it in unlocked state using the ducktape.
http://kb.sandisk.com/app/answers/detai … -or-locked

A bad scare: root file system recovery [SOLVED]

Hi, everybody,
The trouble began with an odd message: KDE Daemon: new storage detected (hard disk): open in a new window, ignore. Unfortunately, the hard disk in question is statically mounted via /etc/fstab; should have been mounted all along.
# /etc/fstab: static file system information
# <file system> <dir> <type> <options> <dump> <pass>
none /dev/pts devpts defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/cdrom /mnt/cdrom iso9660 ro,user,noauto,unhide,iocharset=utf8 0 0
/dev/dvd /mnt/dvd udf ro,user,noauto,unhide,iocharset=utf8 0 0
/dev/fd0 /mnt/fd0 vfat user,noauto 0 0
/dev/sdb1 swap swap defaults 0 0
/dev/sdb2 / ext3 defaults 0 1
/dev/sdb3 /home ext3 defaults 0 1
#/dev/sda1 /home/alexey/mnt/a ext3 defaults 0 1
It's /dev/sda1, now commented. Real trouble began when I tried to reboot. The kernel told me there's no root file system on sdb2; it checked the disks unsuccessfully, with scary messages about bad device names and device blocks, advised me to use rootfstype=kernel option, etc. sda1 turned out "bad" too. In fallback mode the system booted, but with file systems mounted read only; not much use... Using some recovery disk I commented out the /dev/sda1 line in /etc/fstab on suspicion that sda is the real offender; tried to reboot, without much success, then rebooted again, and something clicked into place; the system is back to normal, but I fear to approach sda1 . What happened? Any suggestion/link is going to be appreciated. It was pure luck; next time it could be much worse.
Edit:
Looks like 'clicked into place' is just the fallback kernel; kernel-related issue? It ran smoothly after the initial upgrade for a couple of weeks.
Edit:
A relevant snippet from kernel.log:
Apr 23 19:52:25 stovepipebox ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
Apr 23 19:52:25 stovepipebox ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
Apr 23 19:52:25 stovepipebox ata2.00: ATAPI: _NEC DVD_RW ND-4550A, 1.06, max UDMA/33
Apr 23 19:52:25 stovepipebox ata2.00: configured for UDMA/33
Apr 23 19:52:25 stovepipebox scsi 1:0:0:0: CD-ROM _NEC DVD_RW ND-4550A 1.06 PQ: 0 ANSI: 5
Apr 23 19:52:25 stovepipebox sata_nv 0000:00:0e.0: version 3.5
Apr 23 19:52:25 stovepipebox ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
Apr 23 19:52:25 stovepipebox ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LSA0] -> GSI 23 (level, low) -> IRQ 16
Apr 23 19:52:25 stovepipebox PCI: Setting latency timer of device 0000:00:0e.0 to 64
Apr 23 19:52:25 stovepipebox scsi2 : sata_nv
Apr 23 19:52:25 stovepipebox scsi3 : sata_nv
Apr 23 19:52:25 stovepipebox ata3: SATA max UDMA/133 cmd 0xe800 ctl 0xe480 bmdma 0xe000 irq 16
Apr 23 19:52:25 stovepipebox ata4: SATA max UDMA/133 cmd 0xe400 ctl 0xe080 bmdma 0xe008 irq 16
Apr 23 19:52:25 stovepipebox ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Apr 23 19:52:25 stovepipebox ata3.00: ATA-6: ST3120827AS, 3.42, max UDMA/133
Apr 23 19:52:25 stovepipebox ata3.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 0/32)
Apr 23 19:52:25 stovepipebox ata3.00: model number mismatch 'ST3120827AS' != '3120827AS '
Apr 23 19:52:25 stovepipebox ata3.00: revalidation failed (errno=-19)
Apr 23 19:52:25 stovepipebox ata3: limiting SATA link speed to 1.5 Gbps
Apr 23 19:52:25 stovepipebox ata3.00: limiting speed to UDMA/133:PIO3
Apr 23 19:52:25 stovepipebox ata3: failed to recover some devices, retrying in 5 secs
Apr 23 19:52:25 stovepipebox ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Apr 23 19:52:25 stovepipebox ata3.00: configured for UDMA/133
Apr 23 19:52:25 stovepipebox ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Apr 23 19:52:25 stovepipebox ata4.00: ATA-7: ST3320620AS, 3.AAK, max UDMA/133
Apr 23 19:52:25 stovepipebox ata4.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
Apr 23 19:52:25 stovepipebox ata4.00: configured for UDMA/133
Apr 23 19:52:25 stovepipebox scsi 2:0:0:0: Direct-Access ATA ST3120827AS 3.42 PQ: 0 ANSI: 5
Apr 23 19:52:25 stovepipebox scsi 3:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0 ANSI: 5
This "model number mismatch 'ST3120827AS' != '3120827AS " looks like a result of a corrupted config (at least, I suspect so ). Any questions/suggestions?
Last edited by Llama (2008-05-02 20:20:04)

I had this same damn thing happen. The problem is in the way the kernel gets its info from the bios. The bios has a nasty habit of switching the drives around even when sda is connected to sata1. This became a problem when libata came about and changed all drives to sdxX naming convention.
To fix the no booting problem and the stupid rootfstype= error thing, u need to use Persistent block naming device scheme. Here on the wiki is a page dedicated to this... http://wiki.archlinux.org/index.php/Per … ice_naming
Try it and see if it helps. I used the /dev/by-uuid.

Mounting the Root File System into RAM

Hi,
I had been wondering, recently, how can one copy the entire root hierarchy, or wanted parts of it, into RAM, mount it at startup, and use it as the root itself. At shutdown, the modified files and directories would be synchronized back to the non-volatile storage. This synchronization could also be performed manually, before shutting down.
I have now succeeded, at least it seems, in performing such a task. There are still some issues.
For anyone interested, I will be describing how I have done it, and I will provide the files that I have worked with.
A custom kernel hook is used to (overall):
Mount the non-volatile root in a mountpoint in the initramfs. I used /root_source
Mount the volatile ramdisk in a mountpoint in the initramfs. I used /root_ram
Copy the non-volatile content into the ramdisk.
Remount by binding each of these two mountpoints in the new root, so that we can have access to both volumes in the new ramdisk root itself once the root is changed, to synchronize back any modified RAM content to the non-volatile storage medium: /rootfs/rootfs_{source,ram}
A mount handler is set (mount_handler) to a custom function, which mounts, by binding, the new ramdisk root into a root that will be switched to by the kernel.
To integrate this hook into a initramfs, a preset is needed.
I added this hook (named "ram") as the last one in mkinitcpio.conf. -- Adding it before some other hooks did not seem to work; and even now, it sometimes does not detect the physical disk.
The kernel needs to be passed some custom arguments; at a minimum, these are required: ram=1
When shutting down, the ramdisk contents is synchronized back with the source root, by the means of a bash script. This script can be run manually to save one's work before/without shutting down. For this (shutdown) event, I made a custom systemd service file.
I chose to use unison to synchronize between the volatile and the non-volatile mediums. When synchronizing, nothing in the directory structure should be modified, because unison will not synchronize those changes in the end; it will complain, and exit with an error, although it will still synchronize the rest. Thus, I recommend that if you synch manually (by running /root/Documents/rootfs/unmount-root-fs.sh, for example), do not execute any other command before synchronization has completed, because ~/.bash_history, for example, would be updated, and unison would not update this file.
Some prerequisites exist (by default):
Packages: unison(, cp), find, cpio, rsync and, of course, any any other packages which you can mount your root file system (type) with. I have included these: mount.{,cifs,fuse,ntfs,ntfs-3g,lowntfs-3g,nfs,nfs4}, so you may need to install ntfs-3g the nfs-related packages (nfs-utils?), or remove the unwanted "mount.+" entires from /etc/initcpio/install/ram.
Referencing paths:
The variables:
source=
temporary=
...should have the same value in all of these files:
"/etc/initcpio/hooks/ram"
"/root/Documents/rootfs/unmount-root-fs.sh"
"/root/.rsync/exclude.txt" -- Should correspond.
This is needed to sync the RAM disk back to the hard disk.
I think that it is required to have the old root and the new root mountpoints directly residing at the root / of the initramfs, from what I have noticed. For example, "/new_root" and "/old_root".
Here are all the accepted and used parameters:
Parameter Allowed Values Default Value Considered Values Description
root Default (UUID=+,/dev/disk/by-*/*) None Any string The source root
rootfstype Default of "-t <types>" of "mount" "auto" Any string The FS type of the source root.
rootflags Default of "-o <options>" of "mount" None Any string Options when mounting the source root.
ram Any string None "1" If this hook sould be run.
ramfstype Default of "-t <types>" of "mount" "auto" Any string The FS type of the RAM disk.
ramflags Default of "-o <options>" of "mount" "size=50%" Any string Options when mounting the RAM disk.
ramcleanup Any string None "0" If any left-overs should be cleaned.
ramcleanup_source Any string None "1" If the source root should be unmounted.
ram_transfer_tool cp,find,cpio,rsync,unison unison cp,find,cpio,rsync What tool to use to transfer the root into RAM.
ram_unison_fastcheck true,false,default,yes,no,auto "default" true,false,default,yes,no,auto Argument to unison's "fastcheck" parameter. Relevant if ram_transfer_tool=unison.
ramdisk_cache_use 0,1 None 0 If unison should use any available cache. Relevant if ram_transfer_tool=unison.
ramdisk_cache_update 0,1 None 0 If unison should copy the cache to the RAM disk. Relevant if ram_transfer_tool=unison.
This is the basic setup.
Optionally:
I disabled /tmp as a tmpfs mountpoint: "systemctl mask tmp.mount" which executes "ln -s '/dev/null' '/etc/systemd/system/tmp.mount' ". I have included "/etc/systemd/system/tmp.mount" amongst the files.
I unmount /dev/shm at each startup, using ExecStart from "/etc/systemd/system/ram.service".
Here are the updated (version 3) files, archived: Root_RAM_FS.tar (I did not find a way to attach files -- does Arch forums allow attachments?)
I decided to separate the functionalities "mounting from various sources", and "mounting the root into RAM". Currently, I am working only on mounting the root into RAM. This is why the names of some files changed.
Of course, use what you need from the provided files.
Here are the values for the time spend copying during startup for each transfer tool. The size of the entire root FS was 1.2 GB:
find+cpio: 2:10s (2:12s on slower hardware)
unison: 3:10s - 4:00s
cp: 4 minutes (31 minutes on slower hardware)
rsync: 4:40s (55 minutes on slower hardware)
Beware that the find/cpio option is currently broken; it is available to be selected, but it will not work when being used.
These are the remaining issues:
find+cpio option does not create any destination files.
(On some older hardware) When booting up, the source disk is not always detected.
When booting up, the custom initramfs is not detected, after it has been updated from the RAM disk. I think this represents an issue with synchronizing back to the source root.
Inconveniences:
Unison needs to perform an update detection at each startup.
initramfs' ash does not parse wild characters to use "cp".
That's about what I can think of for now.
I will gladly try to answer any questions.
I don't consider myself a UNIX expert, so I would like to know your suggestions for improvement, especially from who consider themselves so.
Last edited by AGT (2014-05-20 23:21:45)

How did you use/test unison? In my case, unison, of course, is used in the cpio image, where there are no cache files, because unison has not been run yet in the initcpio image, before it had a chance to be used during boot time, to generate them; and during start up is when it is used; when it creates the archives. ...a circular dependency. Yet, files changed by the user would still need to be traversed to detect changes. So, I think that even providing pre-made cache files would not guarantee that they would be valid at start up, for all configurations of installation. -- I think, though, that these cache files could be copied/saved from the initcpio image to the root (disk and RAM), after they have been created, and used next time by copying them in the initcpio image during each start up. I think $HOME would need to be set.
Unison was not using any cache previously anyway. I was aware of that, but I wanted to prove it by deleting any cache files remaining.
Unison, actually, was slower (4 minutes) the first time it ran in the VM, compared to the physical hardware (3:10s). I have not measured the time for its subsequent runs, but It seemed that it was faster after the first run. The VM was hosted on a newer machine than what I have used so far: the VM host has an i3-3227U at 1.9 GHz CPU with 2 cores/4 threads and 8 GB of RAM (4 GB ware dedicated to the VM); my hardware has a Pentium B940 at 2 GHz CPU with 2 cores/2 threads and 4 GB of RAM.
I could see that, in the VM, rsync and cp were copying faster than on my hardware; they were scrolling quicker.
Grub, initially complains that there is no image, and shows a "Press any key to continue" message; if you continue, the kernel panics.
I'll try using "poll_device()". What arguments does it need? More than just the device; also the number of seconds to wait?
Last edited by AGT (2014-05-20 16:49:35)

How to add more disk space into /   root file system

Hi All,
Linux 2.6.18-128
can anyone please let us know how to add more disk space into "/" root file system.
i have added new hard disk with space of 20GB,
[root@rac2 shm]# df -h
Filesystem            Size Used Avail Use% Mounted on
/dev/hda1             965M 767M 149M 84% /
/dev/hda7             1.9G 234M 1.6G 13% /var
/dev/hda6             2.9G   69M 2.7G   3% /tmp
/dev/hda3             7.6G 4.2G 3.0G 59% /usr
/dev/hda2              18G   12G 4.8G 71% /u01
LABLE=/               2.0G     0 2.0G   0% /dev/shm
/dev/hdb2             8.9G 149M 8.3G   2% /vm
[root@rac2 shm]#

Dude! wrote:
I would actually question whether or not more disks increase the risk of a disk failure. One disk can break as likely as one of two of more disks.
Simple stats. Buying 2 lottery tickets instead of one, gives you 2 chances to win the lottery prize. Not 1. Even though the odds of winning per ticket remains unchanged.
2 disks buy you 2 tickets in The-Drive-Failure lottery.
Back in the 90's, BT (British Telecom) had a 80+ node OPS cluster build with Pyramid MPP hardware. They had a dedicated store of scsi disks for replacing failed disks - as there were disk failure fairly often due to the number of disks. (a Pryamid MPP chassis looked like a Xmas tree with all the scsi drive LEDs, and BT had several)
In my experience - one should rather expect a drive failure sooner, than later. And have some kind of contingency plan in place to recover from the failure.
The use of symbolic links instead of striping the filesystem protects from the complete loss of the enchilada if a volume member fails, but it does not reduce the risk of loosing data.
I would rather buy a single ticket for the drive failure lottery for a root drive, than 2 tickets in this case. And using symbolic links to "offload" non-critical files to the 2nd drive means that its lottery ticket prize is not a non-bootable server due to a toasted root drive.

Sol10 u8 installed on a ZFS Root File System have different swap needs?

Does Sol10 u8 installed on a ZFS Root File System have different swap needs/processes?
Information:
I've installed Solaris 10 (10/09 s10s_u8wos_08a SPARC, Assembled 16 September 2009) on a half dozen servers and every one of them no longer mount swap at boot.
The install program commented out the old swap entry and created this one:
# grep swap /etc/vfstab
swap - /tmp tmpfs - yes -
Everything works like a champ. I didn't discover the issue until I tried to install some patches and the install failed. It didn't fail because of lack of swap - it refused to run because it found "No swap devices configured".
Here are the symptoms:
# swap -s
total: 183216k bytes allocated + 23832k reserved = 207048k used, 13600032k available
# swap -l
No swap devices configured
# mount | grep swap
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev=5ac0001 on Mon Apr 19 08:06:45 2010
/tmp on swap read/write/setuid/devices/xattr/dev=5ac0002 on Mon Apr 19 08:07:40 2010
/var/run on swap read/write/setuid/devices/xattr/dev=5ac0003 on Mon Apr 19 08:07:40 2010
#

Hi Nitabills,
I assume that you create a zfs entry for swap with the commande zfs create -V $size
did you launch the command :
swap -a /dev/zvol/dsdk/$ZPOOL/swap
Try this entry below in the vfstab :
/dev/zvol/dsdk/$ZPOOL/swap - - swap - no -

Device id of the root file system changes

I have noticed that sometimes the device id of the root file system changes (it typically get incremented by one). This seems to happen after an abnormal shutdown. After a normal shutdown and reboot the device id reverts back to what it was previously.
/ is on a local disk (not NFS or anything like that) and I'm talking about the device id you can obtain via the following command:
stat / | cut -d' ' -f1
Any idea why this is happening?

boot up a (any) live CD, cp -a, generate a new grub.cfg/adjust menu.lst and don't forget to update your fstab - done.
Just done it myself.

[SOLVED]Root file system changed

I'm currently using ArchLinux
I'm not sure what went wrong, but now when I login as root and "cd" I don't see the root file system. Instead i see
[root@aspect ~]# ls -al
total 36
drwxr-x--- 7 root root 4096 Apr 13 16:29 .
drwxr-xr-x 17 root root 4096 Apr 13 08:18 ..
-rw------- 1 root root 2849 Apr 13 16:27 .bash_history
drwxr-xr-x 2 root root 4096 Apr 13 10:35 .config
drwx------ 3 root root 4096 Apr 13 10:34 .dbus
-rw------- 1 root root 49 Apr 13 10:35 .directory
drwxr-xr-x 3 root root 4096 Apr 13 10:34 .kde4
drwxr-xr-x 3 root root 4096 Apr 13 10:35 .local
drwx------ 3 root root 4096 Apr 13 16:29 .nv
If I cd to ".." I can see the root file system from there.
Also When I drag files into terminal, it can't locate them. I Used a java folder I had in downlaods as an example. But it's like this everywhere.
[aspect@aspect ~]$ file:///home/aspect/Downloads/jre bash: file:///home/aspect/Downloads/jre: No such file or directory
Last edited by aspectratio (2015-04-13 22:05:33)

ewaller wrote:
aspectratio wrote:I've already done all of this. What makes you think I was running KDE as root?
drwxr-xr-x 3 root root 4096 Apr 13 10:34 .kde4
Sometime today a hidden directory containing kde files was created in the /root being owned by root. That's how
So the problem here is I came from debian. And aparently there when you cd as root, it will bring you to the atual file system.
Fair enough.
I was told to edit /etc/passwd and change the root dir to just / from /bin/bash
Now I can no longer login as root. I will try to boot recue mode and chroot into the system to fix the file.
That would be the way to fix it. You may not need to actually chroot, just mount the root partition at /mnt and edit /mnt/etc/passwd.
As to not running desktop environments as root -- it is a pet peeve of mine. I am not saying this about you, you understand the issue; but I have had arguments with people in the past about not running GUI DEs as root, and them insisting on it being their machines and they can do what they want. They are absolutely correct. But they can also fend for themselves.
Edit: If you do have another user in wheel, and if wheel can gain root privileges, just log in as that user and use sudo to fix it.
Yeah it's a security risk.
I've fixed the file. But I'm just not sure why I can't drag and drop paths anymore. It apears as though it's not a common thing anyways.

Root File system is reporting that it's full [SOLVED]

My root file system is reporting as full, and I'd like some ideas on how to track the problem. I've tried a number of things like searching for the largest directory, searching for the largest file, and all that jazz. I'm obviously missing something. /dev/sda3 should be at 50%.
One note. The computer started what seemed like normal today. I converted my second hard drive to ext4, rebooted, and started to notice that things that needed the /tmp directory couldn't start. I made some quick space to get operational by removing 56M of stuff from pacman's cache, but that's a quick hack. I don't know if this is related or not. I am running testin

skottish wrote:
MoonSwan wrote:
You're a dork who solved this issue and will know better next time. How is this a bad thing? I'm sure someone around here has done worse Skottish, so don't feel too stupid. (Won't name names but I'm sure as well that I've done worse somewhere...)
In the meantime, while you're down...*bonks skottish with the dork-stick*
Thanks for the kind words MoonSwan.
This happened because of the way my system is set up. I have rsync making backups of /home and /etc to /backup on close. It turns out that rsync created the /backup directory instead of using the existing one. Why? Because /dev/sdb1 wasn't mounted when I restarted after the conversion. Doh!
no shame in that. i totally freaked out once when i was still in school because i couldn't find a paper that was due. turned out i had /home unmounted when i saved the file, but had /home mounted when i went looking for it.
it was hiding under the mounted filesystem the whole time!

SOLVED: kernel loads, but doesn't have a root file system

Hi,
The system is an Asus X202E. It does UEFI and has a GPT partition system. I've gotten through that part. And it is clear to me that the kernel loads.
It's the next step that's giving me grief. I've tried this with two bootloaders: gummiboot and rEFInd.
With gummiboot, the kernel panics because it can't mount the root file system. With rEFInd, it gets to the intial ramdisk and then drops me to a shell, apparently because the root file system is set to null, and it obviously can't mount that as "real root".
Here is what I posted on the Arch mailing list, documenting that I have indeed specified the correct root (I'm copying this from the email, eliding the unfortunate line wraps):
bridge-live# cat /boot/loader/entries/arch.conf
Title Arch Linux
linux /vmlinuz-linux
initrc /initramfs-linux.img
options root=PARTUUID=d5bb2ad1-9e7d-4c75-b9b6-04865dd77782
bridge-live# ls -l /dev/disk/by-partuuid
total 0
lrwxrwxrwx 1 root root 10 Apr 15 19:26 0ab4d458-cd09-4bfb-a447-5f5fa66332e2 -> ../../sda6
lrwxrwxrwx 1 root root 10 Apr 15 19:26 3e12caeb-1424-451c-898e-a4ff05eab48d -> ../../sda7
lrwxrwxrwx 1 root root 10 Apr 15 19:26 432a977b-f26d-4e75-b9ee-bf610ee6f4a4 -> ../../sda3
lrwxrwxrwx 1 root root 10 Apr 15 19:26 95a1d2c2-393a-4150-bbd2-d8e7179e7f8a -> ../../sda2
lrwxrwxrwx 1 root root 10 Apr 15 19:26 a4b797d9-0868-4bd1-a92d-f244639039f5 -> ../../sda4
lrwxrwxrwx 1 root root 10 Apr 15 19:26 d5bb2ad1-9e7d-4c75-b9b6-04865dd77782 -> ../../sda8
lrwxrwxrwx 1 root root 10 Apr 15 19:26 ed04135b-bd79-4c7c-b3b5-b0f9c2fe6826 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 15 19:26 f64f82a7-8f2b-4748-88b1-7b0c61e71c70 -> ../../sda5
The root partition is supposed to be /dev/sda8, that is:
lrwxrwxrwx 1 root root 10 Apr 15 19:26 d5bb2ad1-9e7d-4c75-b9b6-04865dd77782 -> ../../sda8
So the correct PARTUUID followed by the one I have specified in
arch.conf is:
d5bb2ad1-9e7d-4c75-b9b6-04865dd77782
d5bb2ad1-9e7d-4c75-b9b6-04865dd77782
I'm guessing that this is really the same problem with both gummiboot and with rEFInd, but don't really know. It's clear to me that the initrd is not being correctly constructed. So I removed /etc/mkinitcpio.conf and did, as per the Arch wiki,
pacman -Syyu mkinitcpio linux udev
No joy.
I don't even know which way to go at this point. If I even knew how to tell it where the real disk is in the initial ram disk shell, that would help. Better of course, would be actually solving the problem.
Thanks!
Last edited by n4rky (2013-04-17 21:41:36)

I have made extremely limited progress on this issue.
My previous attempt to specify the root partition in mkinitcpio.conf was insufficient. Furthermore, this is no place--despite the documentation--for the orthodoxy about using UUIDs rather than the straight /dev/sdx. In my case:
root=/dev/sda8
and run
mkinitcpio -p linux
It still drops me into the shell at boot. I can do
mount /dev/sda8 /new_root/
and exit the shell. It still won't believe it has the root device and drops me back in. I just exit.
At this point, for a very brief moment, things look promising. It appears to be starting normally. Then, gdm.service, NetworkManager.service, and dbus.service all fail to start. There may be others but the screen goes by too quickly. At this point, it hangs trying to initialize the pacman keyring and all I can do is CTRL-ALT-DEL.
It occurred to me that this might extend to the rEFInd configuration and so I modified it to also use /dev/sda8 rather than the UUID, but this made no difference. Trying to boot via gummiboot still yields the previously specified kernel panic.

Change ZFS root dataset name for root file system

Hi all
A quick one.
I accepted the default ZFS root dataset name for the root file system during Solaris 10 installation.
Can I change it to another name afterward without reinstalling the OS? For example,
zfs rename rpool/ROOT/s10s_u6wos_07b rpool/ROOT/`hostname`
zfs rename rpool/ROOT/s10s_u6wos_07b/var rpool/ROOT/`hostname`/var
Thank you.

Renaming the root pool is not recommended.

Solaris 10:unable to mount a solaris root file system

Hi All,
I am trying to install Solaris 10 X86 on a Proliant DL385 Server it has a Smart array 6i, I have download the driver from the HP web site, on booting up the installation CD 1, adding the device driver, it sees the device but now says it can��t mount the device. Any clues what I need to do?
Screen Output:
Unable to mount a Solaris root file system from the device
DISK: Target 0, Bios primary drive - device 0x80
on Smart Array 6i Controller on Board PCI bus 2, at Dev 4
Error message from mount::
/pci@0,0/pci1022,7450@7/pcie11,4091@4/cmdk@0,0:a: can't open - no vtoc
any assistence would be appreciated.

Hi,
I read the Message 591 (Agu 2003) and the problem is quite the same. A brief description: I have aLaptop ASUS with HDD1 60GB and a USB storage HDD (in next HDD2) 100GB. I installed Solaris 10 x86 on HDD2 (partition c2t0d0s0). At the end of installation I removed the DVD and using BIOS features I switched the boot to HDD2. All ok; I received the SUN Blue Screen and I choose the active Solaris option; but at the beginning of the boot I received the following error message
Screen Output:
Unable to mount a Solaris root file system from the device
DISK: Target 0: IC25N060 ATMR04-0 on Board ....
Error message from mount::
/pci@0,0/pci-ide2,5/ide@1/cmdk@0,0:a: can't open
any assistence would be appreciated.
Regards

Unbootable Solaris 10 x86 installed on ZFS root file system

Hi all,
I have unbootable Solaris 10 x86 installed on ZFS root file system. on an IDE HDD
The bios keep showing the msg
DISK BOOT FAILURE , PLEASE INSERT SYSTEM BOOT DISK
please note :
1- the HDD is connected properly and recognized by the system
2- GRUB don't show any messages
is there any guide to recover the system , or detail procedure to boot system again
Thanks,,,

It's not clear if this is a recently installed system that is refusing to boot OR if the system was working fine and crashed.
If it's the former, I would suggest you check the BIOS settings to make sure it's booting from the right hard disk. In any case, the Solaris 10 installation should have writting the GRUB stage1 and stage2 blocks to the beginning of the disk.
If the system crashed and is refusing to boot, you can try to boot from a Solaris 10 installation DVD. Choose the single user shell option and see if it can find your system. You should be able to use format/devfsadm/etc to do the actual troubleshooting. If your disk is still responding, try a `zpool import` to see if there is any data that ZFS can recognize (it usually has many backup uberblocks and disk labels scattered around the disk).

Programmatic interface to get zone's root file system

Hi,
I am a newcomer to solaris zones. Is there any programmatic (C API) way to know the path to root file system of a zone given its name, from the global zone?
Thanks!

A truss of zoneadm list -cv shows a bunch of zone related calls like:
zone_lookup()
zone_list()
zone_getattr()
Using the truss output as an example and including /usr/include/sys/zones.h and linking to libzonecfg
(and maybe libzoneinfo) seems like a fairly straight-forward path to getting the info you are looking for.
You could also parse /etc/zones/index
which is (on my s10_63 machine) a colon seperated flat file containing [zone:install state:root path] that looks like:
global:installed:/
demo1:installed:/zones/demo1
demo2:installed:/zones/demo2
demo3:installed:/zones/demo3
foo:installed:/zones/foo
ldap1:installed:/zones/ldap1
Neither of these methods are documented, so they are certainly subject to change or removal.
Good luck!
-William Hathaway

Auto-remount of root file system, like read only

Similar Messages

Maybe you are looking for