this is coming up when trying to boot a new install of Limey Linux last time I checked, e2fsck is for EXT2 and other Linux extensions, not FAT. Booting comes to a dead halt when the e2fsck checktime has been reached. Any way around this, or disable this checking when booting? ~Benjamin KB9LFZ
On 11/18/2013 07:44 AM, Benjamin L. Naber wrote:
this is coming up when trying to boot a new install of Limey Linux
last time I checked, e2fsck is for EXT2 and other Linux extensions, not FAT.
Booting comes to a dead halt when the e2fsck checktime has been reached.
Any way around this, or disable this checking when booting?
I'm no expert on Limey Linux, but last I checked, when Linux formats and prepares a drive, it is most certainly -not- in a FAT format. e2fsck is probably checking your drive on -every- bootup because there's an issue with the drive. From 'man e2fsck' : DESCRIPTION e2fsck is used to check a Linux second extended file system (ext2fs). E2fsck also supports ext2 filesystems containing a journal, which are also sometimes known as ext3 filesystems, by first applying the journal to the filesystem before continuing with normal e2fsck processing. After the journal has been applied, a filesystem will normally be marked as clean. Hence, for ext3 filesystems, e2fsck will normally run the journal and exit, unless its superblock indicates that further checking is required. device is the device file where the filesystem is stored (e.g. /dev/hdc1). Note that in general it is not safe to run e2fsck on mounted filesystems. The only exception is if the -n option is specified, and -c, -l, or -L options are not specified. However, even if it is safe to do so, the results printed by e2fsck are not valid if the filesystem is mounted. If e2fsck asks whether or not you should check a filesystem which is mounted, the only correct answer is ‘‘no’’. Only experts who really know what they are doing should consider answering this question in any other way. 73 = Best Regards, -Geoff/W5OMR
That's what it appears to me. A ham this morning told me the problem maybe the person making the distro images is using a windows machine, not linux, and he is making the .img files for FAT when they *should* be ext2 I've been trying everything that I can find to do the filesystem check, but every embedded distro I've tried doesn't support checking DOS or FAT files systems. ~Benjamin, KB9LFZ allstar node 28569 On Mon, 2013-11-18 at 09:37 -0600, Geoff wrote:
On 11/18/2013 07:44 AM, Benjamin L. Naber wrote:
this is coming up when trying to boot a new install of Limey Linux
last time I checked, e2fsck is for EXT2 and other Linux extensions, not FAT.
Booting comes to a dead halt when the e2fsck checktime has been reached.
Any way around this, or disable this checking when booting?
I'm no expert on Limey Linux, but last I checked, when Linux formats and prepares a drive, it is most certainly -not- in a FAT format.
e2fsck is probably checking your drive on -every- bootup because there's an issue with the drive.
From 'man e2fsck' :
DESCRIPTION e2fsck is used to check a Linux second extended file system (ext2fs). E2fsck also supports ext2 filesystems containing a journal, which are also sometimes known as ext3 filesystems, by first applying the journal to the filesystem before continuing with normal e2fsck processing. After the journal has been applied, a filesystem will normally be marked as clean. Hence, for ext3 filesystems, e2fsck will normally run the journal and exit, unless its superblock indicates that further checking is required.
device is the device file where the filesystem is stored (e.g. /dev/hdc1).
Note that in general it is not safe to run e2fsck on mounted filesystems. The only exception is if the -n option is specified, and -c, -l, or -L options are not specified. However, even if it is safe to do so, the results printed by e2fsck are not valid if the filesystem is mounted. If e2fsck asks whether or not you should check a filesystem which is mounted, the only correct answer is ‘‘no’’. Only experts who really know what they are doing should consider answering this question in any other way.
73 = Best Regards, -Geoff/W5OMR
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
On 11/18/2013 10:45 AM, Benjamin L. Naber wrote:
That's what it appears to me.
A ham this morning told me the problem maybe the person making the distro images is using a windows machine, not linux, and he is making the .img files for FAT when they *should* be ext2
I've been trying everything that I can find to do the filesystem check, but every embedded distro I've tried doesn't support checking DOS or FAT files systems.
it shouldn't matter what platform is used to burn an image. There -might- be an issue in putting the image on a thumb-drive. I'm not sure what the native format of a thumb-drive is, but I'd venture that 99% of 'em are FAT32.
Oh good grief!! The image on the CF is a DOS FAT filesystem that the bootloader reads to load the kernel and RAM image for the filesystem. I wouldn't be too terribly concerned about a RAM filesystem that thinks it needs to be fsck-ed. Jim
Date: Mon, 18 Nov 2013 11:24:24 -0600 From: ars.w5omr@gmail.com To: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] e2fsck
On 11/18/2013 10:45 AM, Benjamin L. Naber wrote:
That's what it appears to me.
A ham this morning told me the problem maybe the person making the distro images is using a windows machine, not linux, and he is making the .img files for FAT when they *should* be ext2
I've been trying everything that I can find to do the filesystem check, but every embedded distro I've tried doesn't support checking DOS or FAT files systems.
it shouldn't matter what platform is used to burn an image.
There -might- be an issue in putting the image on a thumb-drive. I'm not sure what the native format of a thumb-drive is, but I'd venture that 99% of 'em are FAT32.
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
Benjamin L. Naber wrote:
this is coming up when trying to boot a new install of Limey Linux
last time I checked, e2fsck is for EXT2 and other Linux extensions, not FAT.
Booting comes to a dead halt when the e2fsck checktime has been reached.
Any way around this, or disable this checking when booting?
I've never used any of these AllStar distro's - but I have admin's Linux servers for over 15 years and am just starting to play with AllStar. With that in mind, I can offer the following more generic Linux info... CD-ROM images are always in the iso9660 filesystem format - which is completly different than FAT/EXT2/3/4/etc. Doesn't matter what OS was used to create the img - or burn the CD. That format is only on the optical disc (or local loopback of the image file if you install that way). Typical thumb-drive images I've seen have a small FAT filesystem that boots and mounts the install iso image as lookback. The installer, as part of system setup/install formats the local storage device (typically /dev/hda or /dev/sda) in a Linux file format. These days either EXT2 (non-journaled) or EXT3/4 for journaling. This has no relation to the install media! If the init scripts detect a problem on any of the file systems which are to be mounted (i.e. system disks), as outlined in /etc/fstab they will abort and drop you to a single-user mode shell. This is the same as typing in "linux 1" on the grub boot line (or LILO on old distro's). The point is to leave the main system disks unmounted and allow you to repair them. Typically just running fsck will repair them. You will need to do this for each partition (logical or physical) that has a problem. It will typically prompt you about problems it finds - pay attention as fsck runs - you might have to answer "yes" many times! Might be good idea to run fsck on all filesystems while your in there. Afterwords, when you type "exit" from the single-user shell, the system will automatically reboot - and if all is well will boot back to Runlevel 3 or 5 depending on your init setup with your repaired filesystems mounted properly. This is full multi-user/normal mode of operation your used to. In some cases, if the file system is too damaged to even load the ramdisk - it will just die on boot. In that case you will need a rescue disk to boot from. Most distro's install disks offer a "rescue mode"... so just download/burn a current copy of Fedora/CentOS/etc and you can use them as a rescue tool - and don't need to even have that same distro installed! Just look at the install menu and see if they offer a rescue mode. Typically you just type "rescue" and hit enter. It will then load up a minimal system into a ramdisk with most drivers installed that will detect your disk controller and other devices. When it asks if you want to have it mount filesystems answer "N". Then once it drops you to a shell start "fsck.ext2 /dev/hda1"/etc on EACH of your filesystems. Finally, most filesystems in EXTx format are set to do full checking after so many months of being mounted and/or after X many boots. Those limits/trigger points are set using the "tune2fs" tool. Just run "man tune2fs". Joel N7GLV
tune2fs does not work either. Says could not find superblock. on another linux machine, I typed in info tune2fs and it states it is for Linux file systems. I don't care about that. I'd like to disable the file system checking altogether so I can at least get the thing to boot. presently, it still comes to a dead halt when the e2fsck warning comes up. Is there something I can modify in the SYSLINUX.cfg? -or- When it does get stuck on the e2fsck checktime warning, how long does it *usually* take to let whatever program do it's job and then continue booting? -or- when it does get stuck, beside mashing the power button and smoking a cigarette, is there a key sequence I can use to troubleshoot or force the machine to continue booting? ~Benjamin, KB9LFZ On Mon, 2013-11-18 at 10:25 -0800, Joel wrote:
Benjamin L. Naber wrote:
this is coming up when trying to boot a new install of Limey Linux
last time I checked, e2fsck is for EXT2 and other Linux extensions, not FAT.
Booting comes to a dead halt when the e2fsck checktime has been reached.
Any way around this, or disable this checking when booting?
I've never used any of these AllStar distro's - but I have admin's Linux servers for over 15 years and am just starting to play with AllStar. With that in mind, I can offer the following more generic Linux info...
CD-ROM images are always in the iso9660 filesystem format - which is completly different than FAT/EXT2/3/4/etc. Doesn't matter what OS was used to create the img - or burn the CD. That format is only on the optical disc (or local loopback of the image file if you install that way). Typical thumb-drive images I've seen have a small FAT filesystem that boots and mounts the install iso image as lookback. The installer, as part of system setup/install formats the local storage device (typically /dev/hda or /dev/sda) in a Linux file format. These days either EXT2 (non-journaled) or EXT3/4 for journaling. This has no relation to the install media!
If the init scripts detect a problem on any of the file systems which are to be mounted (i.e. system disks), as outlined in /etc/fstab they will abort and drop you to a single-user mode shell. This is the same as typing in "linux 1" on the grub boot line (or LILO on old distro's). The point is to leave the main system disks unmounted and allow you to repair them. Typically just running fsck will repair them. You will need to do this for each partition (logical or physical) that has a problem. It will typically prompt you about problems it finds - pay attention as fsck runs - you might have to answer "yes" many times! Might be good idea to run fsck on all filesystems while your in there. Afterwords, when you type "exit" from the single-user shell, the system will automatically reboot - and if all is well will boot back to Runlevel 3 or 5 depending on your init setup with your repaired filesystems mounted properly. This is full multi-user/normal mode of operation your used to.
In some cases, if the file system is too damaged to even load the ramdisk - it will just die on boot. In that case you will need a rescue disk to boot from. Most distro's install disks offer a "rescue mode"... so just download/burn a current copy of Fedora/CentOS/etc and you can use them as a rescue tool - and don't need to even have that same distro installed! Just look at the install menu and see if they offer a rescue mode. Typically you just type "rescue" and hit enter. It will then load up a minimal system into a ramdisk with most drivers installed that will detect your disk controller and other devices. When it asks if you want to have it mount filesystems answer "N". Then once it drops you to a shell start "fsck.ext2 /dev/hda1"/etc on EACH of your filesystems.
Finally, most filesystems in EXTx format are set to do full checking after so many months of being mounted and/or after X many boots. Those limits/trigger points are set using the "tune2fs" tool. Just run "man tune2fs".
Joel N7GLV
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
Never seen a e2fsck problem. I don’t know what but you’ve got something else wrong. Are you using the right CPU architecture? -- Tim :wq On Nov 18, 2013, at 7:59 PM, Benjamin L. Naber <benjamin@kb9lfz.com> wrote:
tune2fs does not work either. Says could not find superblock.
on another linux machine, I typed in info tune2fs and it states it is for Linux file systems.
I don't care about that. I'd like to disable the file system checking altogether so I can at least get the thing to boot.
presently, it still comes to a dead halt when the e2fsck warning comes up.
Is there something I can modify in the SYSLINUX.cfg?
-or-
When it does get stuck on the e2fsck checktime warning, how long does it *usually* take to let whatever program do it's job and then continue booting?
-or- when it does get stuck, beside mashing the power button and smoking a cigarette, is there a key sequence I can use to troubleshoot or force the machine to continue booting?
~Benjamin, KB9LFZ
On Mon, 2013-11-18 at 10:25 -0800, Joel wrote:
Benjamin L. Naber wrote:
this is coming up when trying to boot a new install of Limey Linux
last time I checked, e2fsck is for EXT2 and other Linux extensions, not FAT.
Booting comes to a dead halt when the e2fsck checktime has been reached.
Any way around this, or disable this checking when booting?
I've never used any of these AllStar distro's - but I have admin's Linux servers for over 15 years and am just starting to play with AllStar. With that in mind, I can offer the following more generic Linux info...
CD-ROM images are always in the iso9660 filesystem format - which is completly different than FAT/EXT2/3/4/etc. Doesn't matter what OS was used to create the img - or burn the CD. That format is only on the optical disc (or local loopback of the image file if you install that way). Typical thumb-drive images I've seen have a small FAT filesystem that boots and mounts the install iso image as lookback. The installer, as part of system setup/install formats the local storage device (typically /dev/hda or /dev/sda) in a Linux file format. These days either EXT2 (non-journaled) or EXT3/4 for journaling. This has no relation to the install media!
If the init scripts detect a problem on any of the file systems which are to be mounted (i.e. system disks), as outlined in /etc/fstab they will abort and drop you to a single-user mode shell. This is the same as typing in "linux 1" on the grub boot line (or LILO on old distro's). The point is to leave the main system disks unmounted and allow you to repair them. Typically just running fsck will repair them. You will need to do this for each partition (logical or physical) that has a problem. It will typically prompt you about problems it finds - pay attention as fsck runs - you might have to answer "yes" many times! Might be good idea to run fsck on all filesystems while your in there. Afterwords, when you type "exit" from the single-user shell, the system will automatically reboot - and if all is well will boot back to Runlevel 3 or 5 depending on your init setup with your repaired filesystems mounted properly. This is full multi-user/normal mode of operation your used to .
In some cases, if the file system is too damaged to even load the ramdisk - it will just die on boot. In that case you will need a rescue disk to boot from. Most distro's install disks offer a "rescue mode"... so just download/burn a current copy of Fedora/CentOS/etc and you can use them as a rescue tool - and don't need to even have that same distro installed! Just look at the install menu and see if they offer a rescue mode. Typically you just type "rescue" and hit enter. It will then load up a minimal system into a ramdisk with most drivers installed that will detect your disk controller and other devices. When it asks if you want to have it mount filesystems answer "N". Then once it drops you to a shell start "fsck.ext2 /dev/hda1"/etc on EACH of your filesystems.
Finally, most filesystems in EXTx format are set to do full checking after so many months of being mounted and/or after X many boots. Those limits/trigger points are set using the "tune2fs" tool. Just run "man tune2fs".
Joel N7GLV
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
Tim, et al: Here's what I'm doing, the same way I've done it before, which much success. The machine is a neoware thin client, CA-22, with 1GHz processor, 1GB RAM, 256MB flash. on my allstar node 28569, same physical setup, using Limey Linux for i686. the distro VIA version did not work at all. I'm using DamnSmallLinux on a thumbdrive on the designated machine to cfdisk the Disk-on-module, not compact flash or another USB thumbdrive, to delete what was on it, and format for FAT16. I tried also EXT2. If I had a USB to laptop IDE adapter with pins on it, I'd just connect the DOM to it and see what the main machine says with gparted or the other disk utility program. DamnSmallLinux and Puppy Linux do not have dosfsck support. I've been trying to get TinyCore to work, but that is not being my friend today. I have TinyCore that works fine for me on a few other thin client boxes with 128MB RAM and 65MB flash. anyway, I digress, I go right away into console when DSL boots. I "sudo su" then cd to the folders I have the Limey linux, or other embedded Linux .img files are in. the command I have used before was "dd if=cfimg-1.1.4_i686 of=/dev/hda" I've tried using "dd if=cfimg-1.1.4_i686 of=/dev/hda bs=16k" as that works for other embedded distro versions, but did not work here. I've never seen the e2fsck error before, even after reformatting the drive to be used. ~Benjamin, KB9LFZ On Mon, 2013-11-18 at 20:32 -0800, Tim Sawyer wrote:
Never seen a e2fsck problem. I don’t know what but you’ve got something else wrong. Are you using the right CPU architecture? -- Tim :wq
On Nov 18, 2013, at 7:59 PM, Benjamin L. Naber <benjamin@kb9lfz.com> wrote:
tune2fs does not work either. Says could not find superblock.
on another linux machine, I typed in info tune2fs and it states it is for Linux file systems.
I don't care about that. I'd like to disable the file system checking altogether so I can at least get the thing to boot.
presently, it still comes to a dead halt when the e2fsck warning comes up.
Is there something I can modify in the SYSLINUX.cfg?
-or-
When it does get stuck on the e2fsck checktime warning, how long does it *usually* take to let whatever program do it's job and then continue booting?
-or- when it does get stuck, beside mashing the power button and smoking a cigarette, is there a key sequence I can use to troubleshoot or force the machine to continue booting?
~Benjamin, KB9LFZ
On Mon, 2013-11-18 at 10:25 -0800, Joel wrote:
Benjamin L. Naber wrote:
this is coming up when trying to boot a new install of Limey Linux
last time I checked, e2fsck is for EXT2 and other Linux extensions, not FAT.
Booting comes to a dead halt when the e2fsck checktime has been reached.
Any way around this, or disable this checking when booting?
I've never used any of these AllStar distro's - but I have admin's Linux servers for over 15 years and am just starting to play with AllStar. With that in mind, I can offer the following more generic Linux info...
CD-ROM images are always in the iso9660 filesystem format - which is completly different than FAT/EXT2/3/4/etc. Doesn't matter what OS was used to create the img - or burn the CD. That format is only on the optical disc (or local loopback of the image file if you install that way). Typical thumb-drive images I've seen have a small FAT filesystem that boots and mounts the install iso image as lookback. The installer, as part of system setup/install formats the local storage device (typically /dev/hda or /dev/sda) in a Linux file format. These days either EXT2 (non-journaled) or EXT3/4 for journaling. This has no relation to the install media!
If the init scripts detect a problem on any of the file systems which are to be mounted (i.e. system disks), as outlined in /etc/fstab they will abort and drop you to a single-user mode shell. This is the same as typing in "linux 1" on the grub boot line (or LILO on old distro's). The point is to leave the main system disks unmounted and allow you to repair them. Typically just running fsck will repair them. You will need to do this for each partition (logical or physical) that has a problem. It will typically prompt you about problems it finds - pay attention as fsck runs - you might have to answer "yes" many times! Might be good idea to run fsck on all filesystems while your in there. Afterwords, when you type "exit" from the single-user shell, the system will automatically reboot - and if all is well will boot back to Runlevel 3 or 5 depending on your init setup with your repaired filesystems mounted properly. This is full multi-user/normal mode of operation your used to .
In some cases, if the file system is too damaged to even load the ramdisk - it will just die on boot. In that case you will need a rescue disk to boot from. Most distro's install disks offer a "rescue mode"... so just download/burn a current copy of Fedora/CentOS/etc and you can use them as a rescue tool - and don't need to even have that same distro installed! Just look at the install menu and see if they offer a rescue mode. Typically you just type "rescue" and hit enter. It will then load up a minimal system into a ramdisk with most drivers installed that will detect your disk controller and other devices. When it asks if you want to have it mount filesystems answer "N". Then once it drops you to a shell start "fsck.ext2 /dev/hda1"/etc on EACH of your filesystems.
Finally, most filesystems in EXTx format are set to do full checking after so many months of being mounted and/or after X many boots. Those limits/trigger points are set using the "tune2fs" tool. Just run "man tune2fs".
Joel N7GLV
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
(ala Mythbusters) "Well *THERE's* your problem!!" Try the VIA release rather then the i686. Jim
From: Benjamin@kb9lfz.com To: tim.sawyer@mac.com Date: Tue, 19 Nov 2013 00:07:43 -0500 CC: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] e2fsck..... halted during boot
Tim, et al:
Here's what I'm doing, the same way I've done it before, which much success.
The machine is a neoware thin client, CA-22, with 1GHz processor, 1GB RAM, 256MB flash.
on my allstar node 28569, same physical setup, using Limey Linux for i686. the distro VIA version did not work at all.
I'm using DamnSmallLinux on a thumbdrive on the designated machine to cfdisk the Disk-on-module, not compact flash or another USB thumbdrive, to delete what was on it, and format for FAT16. I tried also EXT2.
If I had a USB to laptop IDE adapter with pins on it, I'd just connect the DOM to it and see what the main machine says with gparted or the other disk utility program.
DamnSmallLinux and Puppy Linux do not have dosfsck support. I've been trying to get TinyCore to work, but that is not being my friend today. I have TinyCore that works fine for me on a few other thin client boxes with 128MB RAM and 65MB flash.
anyway, I digress, I go right away into console when DSL boots. I "sudo su" then cd to the folders I have the Limey linux, or other embedded Linux .img files are in.
the command I have used before was "dd if=cfimg-1.1.4_i686 of=/dev/hda" I've tried using "dd if=cfimg-1.1.4_i686 of=/dev/hda bs=16k" as that works for other embedded distro versions, but did not work here. I've never seen the e2fsck error before, even after reformatting the drive to be used.
~Benjamin, KB9LFZ
On Mon, 2013-11-18 at 20:32 -0800, Tim Sawyer wrote:
Never seen a e2fsck problem. I don’t know what but you’ve got something else wrong. Are you using the right CPU architecture? -- Tim :wq
On Nov 18, 2013, at 7:59 PM, Benjamin L. Naber <benjamin@kb9lfz.com> wrote:
tune2fs does not work either. Says could not find superblock.
on another linux machine, I typed in info tune2fs and it states it is for Linux file systems.
I don't care about that. I'd like to disable the file system checking altogether so I can at least get the thing to boot.
presently, it still comes to a dead halt when the e2fsck warning comes up.
Is there something I can modify in the SYSLINUX.cfg?
-or-
When it does get stuck on the e2fsck checktime warning, how long does it *usually* take to let whatever program do it's job and then continue booting?
-or- when it does get stuck, beside mashing the power button and smoking a cigarette, is there a key sequence I can use to troubleshoot or force the machine to continue booting?
~Benjamin, KB9LFZ
On Mon, 2013-11-18 at 10:25 -0800, Joel wrote:
Benjamin L. Naber wrote:
this is coming up when trying to boot a new install of Limey Linux
last time I checked, e2fsck is for EXT2 and other Linux extensions, not FAT.
Booting comes to a dead halt when the e2fsck checktime has been reached.
Any way around this, or disable this checking when booting?
I've never used any of these AllStar distro's - but I have admin's Linux servers for over 15 years and am just starting to play with AllStar. With that in mind, I can offer the following more generic Linux info...
CD-ROM images are always in the iso9660 filesystem format - which is completly different than FAT/EXT2/3/4/etc. Doesn't matter what OS was used to create the img - or burn the CD. That format is only on the optical disc (or local loopback of the image file if you install that way). Typical thumb-drive images I've seen have a small FAT filesystem that boots and mounts the install iso image as lookback. The installer, as part of system setup/install formats the local storage device (typically /dev/hda or /dev/sda) in a Linux file format. These days either EXT2 (non-journaled) or EXT3/4 for journaling. This has no relation to the install media!
If the init scripts detect a problem on any of the file systems which are to be mounted (i.e. system disks), as outlined in /etc/fstab they will abort and drop you to a single-user mode shell. This is the same as typing in "linux 1" on the grub boot line (or LILO on old distro's). The point is to leave the main system disks unmounted and allow you to repair them. Typically just running fsck will repair them. You will need to do this for each partition (logical or physical) that has a problem. It will typically prompt you about problems it finds - pay attention as fsck runs - you might have to answer "yes" many times! Might be good idea to run fsck on all filesystems while your in there. Afterwords, when you type "exit" from the single-user shell, the system will automatically reboot - and if all is well will boot back to Runlevel 3 or 5 depending on your init setup with your repaired filesystems mounted properly. This is full multi-user/normal mode of operation your used to .
In some cases, if the file system is too damaged to even load the ramdisk - it will just die on boot. In that case you will need a rescue disk to boot from. Most distro's install disks offer a "rescue mode"... so just download/burn a current copy of Fedora/CentOS/etc and you can use them as a rescue tool - and don't need to even have that same distro installed! Just look at the install menu and see if they offer a rescue mode. Typically you just type "rescue" and hit enter. It will then load up a minimal system into a ramdisk with most drivers installed that will detect your disk controller and other devices. When it asks if you want to have it mount filesystems answer "N". Then once it drops you to a shell start "fsck.ext2 /dev/hda1"/etc on EACH of your filesystems.
Finally, most filesystems in EXTx format are set to do full checking after so many months of being mounted and/or after X many boots. Those limits/trigger points are set using the "tune2fs" tool. Just run "man tune2fs".
Joel N7GLV
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
Hello everyone. This is Jared and some of you who talk to me on air know me as KD2ERF. BUT MY NEW CALL SIGN is KB2JIP On Tuesday, November 19, 2013, Jim Duuuude wrote:
(ala Mythbusters) "Well *THERE's* your problem!!"
Try the VIA release rather then the i686.
Jim
From: Benjamin@kb9lfz.com <javascript:_e({}, 'cvml', 'Benjamin@kb9lfz.com');> To: tim.sawyer@mac.com <javascript:_e({}, 'cvml', 'tim.sawyer@mac.com');> Date: Tue, 19 Nov 2013 00:07:43 -0500 CC: app_rpt-users@ohnosec.org <javascript:_e({}, 'cvml', 'app_rpt-users@ohnosec.org');> Subject: Re: [App_rpt-users] e2fsck..... halted during boot
Tim, et al:
Here's what I'm doing, the same way I've done it before, which much success.
The machine is a neoware thin client, CA-22, with 1GHz processor, 1GB RAM, 256MB flash.
on my allstar node 28569, same physical setup, using Limey Linux for i686. the distro VIA version did not work at all.
I'm using DamnSmallLinux on a thumbdrive on the designated machine to cfdisk the Disk-on-module, not compact flash or another USB thumbdrive, to delete what was on it, and format for FAT16. I tried also EXT2.
If I had a USB to laptop IDE adapter with pins on it, I'd just connect the DOM to it and see what the main machine says with gparted or the other disk utility program.
DamnSmallLinux and Puppy Linux do not have dosfsck support. I've been trying to get TinyCore to work, but that is not being my friend today. I have TinyCore that works fine for me on a few other thin client boxes with 128MB RAM and 65MB flash.
anyway, I digress, I go right away into console when DSL boots. I "sudo su" then cd to the folders I have the Limey linux, or other embedded Linux .img files are in.
the command I have used before was "dd if=cfimg-1.1.4_i686 of=/dev/hda" I've tried using "dd if=cfimg-1.1.4_i686 of=/dev/hda bs=16k" as that works for other embedded distro versions, but did not work here. I've never seen the e2fsck error before, even after reformatting the drive to be used.
~Benjamin, KB9LFZ
On Mon, 2013-11-18 at 20:32 -0800, Tim Sawyer wrote:
Never seen a e2fsck problem. I don’t know what but you’ve got something else wrong. Are you using the right CPU architecture? -- Tim :wq
On Nov 18, 2013, at 7:59 PM, Benjamin L. Naber <benjamin@kb9lfz.com> wrote:
tune2fs does not work either. Says could not find superblock.
on another linux machine, I typed in info tune2fs and it states it is for Linux file systems.
I don't care about that. I'd like to disable the file system checking altogether so I can at least get the thing to boot.
presently, it still comes to a dead halt when the e2fsck warning comes up.
Is there something I can modify in the SYSLINUX.cfg?
-or-
When it does get stuck on the e2fsck checktime warning, how long does it *usually* take to let whatever program do it's job and then continue booting?
-or- when it does get stuck, beside mashing the power button and smoking a cigarette, is there a key sequence I can use to troubleshoot or force the machine to continue booting?
~Benjamin, KB9LFZ
On Mon, 2013-11-18 at 10:25 -0800, Joel wrote:
Benjamin L. Naber wrote:
this is coming up when trying to boot a new install of Limey Linux
last time I checked, e2fsck is for EXT2 and other Linux extensions, not FAT.
Booting comes to a dead halt when the e2fsck checktime has been reached.
Any way around this, or disable this checking when booting?
I've never used any of these AllStar distro's - but I have admin's Linux servers for over 15 years and am just starting to play with AllStar. With that in mind, I can offer the following more generic Linux info...
CD-ROM images are always in the iso9660 filesystem format - which is completly different than FAT/EXT2/3/4/etc. Doesn't matter what OS was used to create the img - or burn the CD. That format is only on the optical disc (or local loopback of the image file if you install that way). Typical thumb-drive images I've seen have a small FAT filesystem that boots and mounts the install iso image as lookback. The installer, as part of system setup/install formats the local storage device (typically /dev/hda or /dev/sda) in a Linux file format. These days either EXT2 (non-journaled) or EXT3/4 for journaling. This has no relation to the install media!
-- Sent From My Iphone 5 On AT&Ts 4G LTE Network
participants (6)
-
Benjamin L. Naber -
Geoff -
Jared Paxton -
Jim Duuuude -
Joel -
Tim Sawyer