Hide Forgot
Description of problem:Running Rsunc causes blackscreen crash. Version-Release number of selected component (if applicable):3.0.8 How reproducible:Run Luckybackup Steps to Reproduce: 1.Boot to kernel 3.2.1.3 2.Boot to kernel 3.2.2.1 3.Run Luckybackup Actual results:Blackscreen causing one finger salute Expected results: Additional info:Still booting to kernel 3.1.9 which runs backup fine.
Louis, thank you for this report. But could you please send us any more specific information, like crash dump, backtrace etc.? It's very time-consuming to follow such steps to reproduce, like booting to other kernels. We would really appreciate something to the point, that we could immediately work with.. Moving to luckybackup component by the way, as it rather seems like a front-end issue. Mjg, can you please confirm that?
(In reply to comment #1) > Louis, thank you for this report. But could you please send us any more > specific information, like crash dump, backtrace etc.? It's very time-consuming > to follow such steps to reproduce, like booting to other kernels. We would > really appreciate something to the point, that we could immediately work with.. > > Moving to luckybackup component by the way, as it rather seems like a front-end > issue. Mjg, can you please confirm that? Well, when using luckybackup/rsync, where and how are you rsyncing from and to, i.e. local/ssh/... (transport), ext4/btrfs/... (file system on both ends). Is this all on one machine?
I don't know how to catch this in a dump or backtrace as the system just snaps into a blackscreen that looks like a failed bootup. This happens on three different machines-2 are newer Gigabyte boards and one is an older Supermicro setup. Backup is to an external USB drive. I tried an Rsync thru a terminal, not luckybacup and it does the same thing. All three will do an rsync with the older kernel to the USB. The Rsync makes it to the Proc folder, which does not match the original proc folder. The copy has more folders and files. After proc is the root folder which is empty as is all after it. If you can advise how to get what you need I will do it. This is the Rsync command I use: rsync -a -v -l // /media/13ea2749-74bd-4a72-9a5e-252258ce735brsync --exclude "/media"
Please move it to the kernel component if it is a kernel crash.
(In reply to comment #3) > I don't know how to catch this in a dump or backtrace as the system just snaps > into a blackscreen that looks like a failed bootup. > > This happens on three different machines-2 are newer Gigabyte boards and one is > an older Supermicro setup. Backup is to an external USB drive. With the new kernel, are there any good ways to use rsync, e.g. rsyncing from the internal drive to the internal drive? That would indicate a USB issue. (I take you're not doing any network backup, e.g. nfs/ssh/samba.) The machine info is valuable, it indicates it's not a board/controller issue. > I tried an Rsync thru a terminal, not luckybacup and it does the same thing. > All three will do an rsync with the older kernel to the USB. OK, so this is not luckybackup-specific, I'll change the component back to rsync before we know more. > The Rsync makes it to the Proc folder, which does not match the original proc > folder. The copy has more folders and files. After proc is the root folder > which is empty as is all after it. > If you can advise how to get what you need I will do it. > This is the Rsync command I use: > rsync -a -v -l // /media/13ea2749-74bd-4a72-9a5e-252258ce735brsync --exclude > "/media" Thanks. "mount" info about the external drive shows you the file system and mount options which could play a role. More testing that could help: - rsync only /usr (this excludes special files) - rsync to an internal file system or folder - check /var/log/messages for anything just before the new boot Thanks for hanging in!
Log sent as attachment Luckybackup usr only OK rsync to SDB internal drive fails
(In reply to comment #6) > Log sent as attachment That somehow did not make it through. > Luckybackup usr only OK Great! So it's not a USB issue. > rsync to SDB internal drive fails With the full tree I assume. This means that the problem comes from the special files you have under "/". You are excluding "/media" to prevent a recursion, but there are also special, temporary file systems like /proc, /dev, /sys, /run which don't lend themselves well to being backed up. Has this ever worked with previous versions? You can (and should) safely exclude these and still get a "full" backup. They all get recreated on reboot. OTOH, backing up stuff underneath /proc and /sys (and parts of /dev) means asking for trouble; they don't consist of "proper" files only, but also interface with volatile kernel/system data. Restoring them from a backup would even hurt you. I would suggest resolving as NOTABUG but will wait for conformation from the OP that this is not a regression (i.e. never worked before).
(In reply to comment #7) > I would suggest resolving as NOTABUG but will wait for conformation from the OP > that this is not a regression (i.e. never worked before). Uhm, reading comprehension: fail... It works with kernel 3.1.9 as the OP wrote. But still, backing up /proc, /sys, /dev, /run probably worked by accident only. Did hugepages or such come in after 3.1.9?
I ran a backup less the four folders you mention and it worked fine. These backed up with errors from Mandrake 2007 and I had no idea I should exclude them. The one restore I used rsync for was over a new install on different hardware which got me back to working order very well. That handles the device and system files. I have not set up hugepages. I will consider this "solved" as I was backing up incorrectly. I am not on OS/2 anymore. I do not know if this kernel difference affects anything else, but it seems fine otherwise so far. Thank you for the help. It is really appreciated. Louis
(In reply to comment #9) > I ran a backup less the four folders you mention and it worked fine. > These backed up with errors from Mandrake 2007 and I had no idea I should > exclude them. The one restore I used rsync for was over a new install on > different hardware which got me back to working order very well. That handles > the device and system files. > I have not set up hugepages. > I will consider this "solved" as I was backing up incorrectly. I am not on OS/2 > anymore. I do not know if this kernel difference affects anything else, but it > seems fine otherwise so far. > Thank you for the help. It is really appreciated. > > Louis Thank you for working with us by testing and reporting.